Tuesday, April 17

TJX Breach at $1.6 Billion, points to poor key management

This article estimates the cost of the TJX breach to be about $1.6 Billion. That's a big number. It also points to this article which suggests the core of the compromise may be related to poor encryption key management. Read that last sentence again. $1.6 Billion because of poor encryption key management. That's amazing to me.

I've spent nearly a decade building identity and access management solutions some of which seem very complex. In addition to identity and access management, security infrastructures have perimeter security (firewalls), intrusion detection, anti-virus, anti-spam, anti-malware, etc.. How often have you heard people focused on building strong encryption key management? Probably not enough. I have to admit that I didn't think much about key management before a key management solution became part of my portfolio. It's a very interesting organizational challenge. It's frightening how insecure systems can be -- even if they have strong data encryption. How the encryption keys are managed is probably more important than the strength of the encryption itself. Yet again, prior to joining RSA I never heard IT managers talking about their encryption key management projects. And it seems like such a simple thing.

Think about it. If all of the data for 45.7 million users is protected with a single encryption key and the key is stored in plain text somewhere on the network. Then, the strong 2048-bit AES algorithm used to encrypt the data really can't be that effective. And each place where encryption is happening throughout an organization probably has another key sitting somewhere -- on a dev server? on a cd in a drawer? in a spreadsheet? Not good. If your organization has this problem, get your arms around it. Solutions are available that allow you to use strong keys, rotate keys regularly, distribute keys securely and ensure that you'll have the right key when you need it for decryption (even years down the road).

Friday, April 13

Jeff Bohren's blog

I'm a little late, but Jeff Bohren of BMC started blogging back in February. I met Jeff briefly while I was working with OpenNetwork technologies (since acquired by BMC). Jeff is a bright guy and I suspect his blog will be worth reading. Jeff has hard core real-world experience building and deploying solutions - which I think is an especially useful background to bring to the blogging world.

Thursday, April 12

What is a Directory? ...LDAP, AD and ADAM

Note: This is not content for LDAP professionals. This is
content for the LDAP-confused. Proceed with caution.

An LDAP directory is simply a type of database that is hierarchical in structure. LDAP is the protocol used to interact with that database. So, when you hear someone refer to putting data into LDAP, what they really mean is using the LDAP protocol to put data into a directory (a hierarchical database that communicates via LDAP).

Relational Databases

The databases used most frequently across today's IT landscape (Oracle, SQL Server, MySQL, etc.) are relational in structure. That is, data is stored in tables and data is connected to other data by way of relationships between tables. For example:

In this sample database, we see that Joe Johnson is a Clerk that reports to John Smith. Joe's job title is not in the same table as his name, but we know what it is because of the relationship between the tables. This is a relational data structure and it's the structure that's commonly used when we use the term database.

LDAP Directory Structure

An LDAP directory is hierarchical in structure. Joe's data would look like this in a directory:A directory uses the concept of an object to represent Joe's data. The directory schema defines the type of objects that will be allowed in this directory and what attributes are associated to those objects. Above we see that an object exists for Joe Johnson with attributes for employee number, first name, last name, job title and manager.

Directory Servers

There are a number of directory servers available on the market, including but not limited to:

  • Sun Directory Server
  • Novell eDirectory
  • Oracle Internet Directory
  • IBM Tivoli Directory Server
  • OpenLDAP
  • Fedora Directory Server
Note: I purposely left Microsoft off this list because I'll
cover AD and ADAM in the next section.

Each of the directory servers listed above (and most others) support a common protocol for storing, accessing, modifying and managing data. This protocol is LDAP. By standardizing on a common protocol, application developers can write their applications to store data in any LDAP compliant directory server. Organizations can choose to implement whichever directory server they prefer and feel fairly confident that an LDAP-ready application will be able to consume or interact with their data.

Vendor-neutrality is theoretically achievable with relational database servers as well. I say theoretically because the big database vendors provide add-ons to the standard SQL language that are convenient for developers but sometimes challenging for portability. The main reasons the industry moved away from relational and toward directories for some uses are as follows:

  • Query Speed: LDAP directories typically provide faster query response times
  • Ease of Management: LDAP's hierarchical structure makes it easy to assign rights and privileges to subsets of users as well as to enable delegated administration over portions of the directory tree.
  • There are probably others, but I believe these are the two big ones - please let me know if I'm missing anything here.

Microsoft Active Directory

With the release of Windows 2000 and the migration from Windows NT as their business networking platform, Microsoft introduced Active Directory (AD). AD is an LDAP directory at its core but it doesn't necessarily play by all the same rules. Because AD is used to manage a network environment - authentication, access rights, user management, etc., AD needed to be much more than just a database.

Note: AD is a predominant part of most IT organizations today. As I travelled to various organizations as an IdM consultant, I almost never encountered an organization that didn't have a mature AD environment containing some of the most up-to-date employee data in the entire organization. Based on my experience, AD has become the de-facto enterprise directory for most organizations.

As the identity management market grew throughout 2000 and 2001, organizations realized the need to leverage LDAP directories more and more. Because AD was already widely deployed and held good data, many organizations wanted to leverage AD -- or at least AD data -- for their identity infrastructure. AD administrators however recognized the need to protect their AD infrastructure and most decided against using AD for anything outside of its core network management role. This is why Microsoft introduced ADAM.

Microsoft ADAM

ADAM (Active Directory Application Mode) is based on the same core LDAP technology on which AD is based. But ADAM installs without all the overhead of the OS and network management capabilities that AD provides. ADAM is a stand-alone LDAP directory store similar to those provided in the list above. ADAM does not require AD to run -- it's not an extension of a given AD environment. But, it can be used to augment the functionality of AD. For example, some organizations use ADAM to store employee information for white pages or other applications that they prefer not to query AD directly. Other organizations use ADAM to store non-employee data while relying on AD for employee information. One interesting use of ADAM is as an authentication proxy. You can send an authorization request to ADAM and have it pass the request to AD - thereby leveraging AD credentials while disallowing applications to connect directly to AD.


A directory is just a type of database. LDAP is a way to communicate with a directory. ADAM is a stand-alone directory and not a feature of AD. There are lots of LDAP directory varieties to choose from.

Let me know if I should include additional info here. My main point was to tackle the simple points made in the conclusion. I run into confusion on those topics quite often.