Risk ROI for –Some– Provisioning Solutions…

Today I ran into an interesting post on Matt Flynn’s Identity Management Blog entitled Extending the ROI on Provisioning in which he discusses the fact that, in addition to the “traditional” value propositions centered around increased efficiency and cost reduction, there are also significant risk management and oversight capabilities that can be had.

All provisioning solutions provide some facilities for:

• Reduction of paper-based processes in favor of electronic requests and work flows
• Reduction of manual updates in favor of automated entitlement updates

All provisioning solution providers strive to have a compelling story for these items. Additionally, these were the focus of the first generation of solutions which emerged in the ’90s.

For the Identity Management programs with which I have been involved, automation and risk management have been equally important. This is somewhat reflected in the definition I use for provisioning:

Provisioning is the processes and systems which:

• Manage the entire Lifecycle of an Entitlement from request, through approval processes, onto issuance, and eventual revocation

• Provide transparent views of the status and history of each step in the Entitlement Lifecycle through the creation of durable and detailed records, which include all the information required to provide non-repudiation and event reconstruction for each step in an Entitlement Lifecycle

Note: Fulfilling these objectives always involves a mix of manual and automated activities, technical and procedural controls.

Based on my experiences, having prepared several product selection scorecards in this space, there are two major approaches (philosophies), that provisioning products take in this space:

The provisioning system “sees itself as”…

• Coordinating identity and entitlement activities among systems with the objective of providing automation

– – – OR – – –

• Maintaining a single centralized record of reference for identity and entitlement, as well as providing tools to automate approval, issuance, revocation, and reconciliation

The “Centralized Record of Reference” concept is the watershed between these two. The systems that are designed purely for automation tend to focus on “Coordination” of external events. These systems often do not contain an internal store of entitlements. The systems that maintain a “Centralized Record of Reference” approach have the ability, through reconciliation, to validate that the entitlements in the “wild” (e.g., in AD, LDAP, within local applications, etc.) match the “official” state (which they maintain). This enables these systems to detect changes and take action (e.g., drop the privilege, report the discrepancy, trigger a follow-up work flow, etc.)

Which system is right for you?

This really depends on what percentage of your systems require tight oversight. If you are in an industry with low-IT regulation, and the data of your core business is low risk, then it may make more sense to invest in routine manual audits of a few systems, rather than monitoring your entire IT world. On the other hand, if you are in an industry that is highly regulated, with high-risk data, then the automated oversight and reconciliation capabilities are likely a good fit for you.

FYI, last week I co-taught a one-day class on Identity and Access Management Architecture at RSA 2008. For the last 3rd of the class, Dan Houser and I had a list of advanced topics for the class to vote on. I prepared a module on Provisioning, but alas it was number 4 out of 7 options, and we only had time to cover 3… As a result, a Provisioning slidecast is “coming soon” to the Art of Information Security podcast.

Cheers, Erik

Got Entropy ?

So I have been planning a series of podcasts on Cryptographic Controls. In the process of this planning, I fell into one of the classic traps that crypto-geeks fall into: obsessing about random number generators (RNGs).

(FYI, for the impatient, click here.)

There are two ways to generate random numbers on computers: (1) use a software program called a Pseudorandom Number Generator (PRNG) or (2) use a hardware random number generator. A Pseudorandom Number Generator uses a seed value to generate a sequence of numbers that appear random. The problem is that the same seed generates the same random sequence. The hardware based RNG observes and samples some physical phenomenon which is random, such as cosmic rays, RF noise, etc. (aka Entropy).

RNGs are important in Information Security because they are used to generate encryption keys, salts, etc. Historically, attacking RNGs has proven effective, such as the defeat of Netscape’s HTTPS sessions.

Most operating systems utilize a hybrid approach, implementing a PseudoRandom Number Generator that has a seed that is regularly updated through the collection of random hardware events. This process is called Entropy Collection or Entropy Harvesting. For most applications, this approach should be completely sufficient. However, one of the key assumptions is that the operating system has been up and running long enough for the seed value itself to become hard to predict through the collection of Entropy. Also, many of the Entropy collecting events come from properties of hardware devices, such as the minor variations in hard drive rate of rotation. As such, there are a few circumstances where the OS RNG may not be good enough for strong cryptographic key generation:

• Live Boot CD ( The start state of the RNG may be predictable. )
• Virtualized Hosts ( OS may be dependent on simulated events for randomness. )

( Given the exploding popularity of virtualization, this is an area worthy of research. Stay tuned. )

Design of the Got Entropy Service

Many RNGs (such as the one included in Linux, as well as OpenSSL’s) allow the addition of entropy from outside sources. So I started looking to Entropy sources I could use to bolster the RNGs on my virtual hosts (and other uses…). While I was looking into this, it occurred to me that I had an unused TV tuner card, a PVR-350.

When a TV is tuned to a channel with no local station, the ‘snow’ on the screen is RF noise (the same as the static between stations on AM radios). But, for reasons beyond our scope, you never use a direct physical observation as the RNG. You have to ‘de-skew and whiten’ the data prior to sampling it. Here is the process that I use:

1. Collect about 3 minutes of video ( about 130 MB data ).
2. Using a random key and IV, encrypt the data ( using openssl & AES-128-CBC ).
3. Discard the first 32k of the file.
4. Use each of the following 32k blocks as samples.
5. Compress each sample with SHA-256.
6. Discard the last block.

• Steps 2 and 3 remove any patterns, such as MPEG file formatting, from the data.
• Steps 4 and 5 generate a 32-byte random value ( 1024 to 1 compression in the hash ).

Check it out at http://gotentropy.artofinfosec.com

Can an Attacker Broadcast a Signal to Undermine This?

Such an attacker could not remove RF noise from the received signal. Our eyes and brains are good at filtering out the noise in the TV video, but there is a lot of it. Part of the noise comes from the atmospheric background RF, but there are also flaws (noise) in the tuner’s radio and analog-to-digital capture circuitry.

I think this is a pretty strong RNG, and I have provided an interface for pulling just the values.

Also, I have written a script ( getEntropy.sh ) that will pull Entropy from the service and seed it into /dev/random on Linux.

Results from ENT

Here are results, from a sample run of the Got Entropy, analyzed by ENT ( A Pseudorandom Number Sequence Test Program provided by John Walker of http://www.fourmilab.ch – Thanks, John! ).

• Entropy = 7.999987 bits per byte
• Optimum compression would reduce the size of this 13366112 byte file by 0 percent.
• Chi square distribution for 13366112 samples is 233.85, and randomly would exceed this value 82.48 percent of the time.
• Arithmetic mean value of data bytes is 127.4767 (127.5 = random).
• Monte Carlo value for Pi is 3.143054786 (error = 0.05 percent).
• Serial correlation coefficient is -0.000078 (totally uncorrelated = 0.0).

Resources for the Curious…

• Wikipedia – Pseudo-random Number Generator
• Wikipedia – Hardware Random Number Generator
• NIST – Random Numbers Page
• Netscape RNG Attack
• van Heusden Video Rand

Cheers, Erik