Friday, January 19

re: Synchronization versus Virtualization

In his entry on Novell’s Cool Blogs, Volker Scheuber discusses the use-cases for virtual directories versus metadirectories and asks for input. Considering my number of previous posts on this topic, I felt an obligation to respond.

I've done a significant amount of services work around both metadirectory and virtual directory technologies. My last company had both and my current company offers neither. The bottom line is that if I were designing an IdM solution, I would want both options to be available. As with any enterprise technology, there's usually more than one way to accomplish a given goal. Most IdM data integration requirements can be met with either meta or virtual technologies. However, there are some scenarios that, for all practical purposes, require one or the other. A while back, I posted some common scenarios where a virtual directory can be really useful.

Even for some of these scenarios though, you may be able to achieve a similar result by standing up another data store and setting up data sync rules with a metadirectory. But it often requires a significant amount of programming that would need to be maintained in addition to the new data store (LDAP or other) and related infrastructure.

Here’s an example:

Let’s say you were deploying a COTS application for insurance claim processing and security is important. The app uses an Oracle database for system data and is built to leverage an enterprise LDAP store (eDirectory, Active Directory, etc.) for authentication. Each employee that needs access to the system already has an account and credentials in the enterprise directory (ED). The system leverages the ED’s groups to grant or deny access. And of course the ED user needs to be enabled.

Due to the sensitive nature of the material, a requirement is made that the system should not allow access to the app unless the employee is punched-in to the company time-clock system. So, if an employee were to piggy back off of a manager’s home VPN connection, they could not access the system unless physically punched-in at work where all claim processing personnel are monitored. The time-clock system has a MySQL database with both system and user data. The APIs for the claim system and the time-clock system are both difficult to work with and complex to maintain.

What are the various ways to meet this requirement?

You could potentially try to work with the API’s and write a custom authentication module that would connect to the time-clock system and verify that a user is punched in before granting access. This would require some internal training, development time and will need to be maintained as either vendor releases new versions in the future.

You could implement a metadirectory solution that sets the ED user as disabled each time status changes in the time-clock system. This may require some custom code, but should be fairly easy to implement. However, we don’t want to disable users in the ED each time they’re punched out. They still need access to HR benefit info and other systems. Not to mention that disabling a user in the ED may trigger other unwanted events to occur (de-provisioning).

You could have the metadirectory solution switch to a different attribute instead of disabling the user, but you’re back to writing a custom authentication module. Also, these metadirectory options will likely introduce some latency because metadirectory sync jobs are typically scheduled. So, there may be some window of time between when the user punches out and when the system denies access. This time window can be exploited to circumvent the intended security controls.

Or – you could have the claims app connect to a virtual directory that is configured to join data from the ED and the MySQL database in a way that is transparent to the claims app. The app sees the virtual directory as an enterprise LDAP directory, but when the user is not punched in, the user appears to be disabled. This is generally a very simple thing to configure for a virtual directory. And if the claims app expects a single group to grant or deny access but the ED groups are arranged differently, the virtual directory can display group memberships however is most appropriate for the app.

Let’s further suppose that the business rules are changed to grant restricted access for the user when punched in but at an alternate location. The virtual directory can be easily configured to set a flag indicating restricted access based on the requestor’s IP address. This is not easily accomplished with a metadirectory solution.

And it’s a plus that the same virtual directory can be used to display user data differently for any number of systems that need access to it – and without altering or moving the data. As we move toward increased regulations and encrypting sensitive data where it lives, reducing the number of data stores that need to be managed and encrypted is an advantage in itself.

Having said all that, I can come up with a number of examples where a metadirectory is clearly a better option than a virtual directory, but I think those are generally easier to see.

Hope this is useful.

Tuesday, January 9

2007: Encryption Everywhere and Phishing Attacks

Encryption Everywhere

In this article from CNET News, Jon Oltsik describes 10 things to know about info security in '07. Number 5 on his list is encryption everywhere. I agree. I admit that I didn't think much about it until joining RSA on the day that it became the security division for EMC, but there's an advancement happening in information security that shifts the focus from perimeter security to information-centric security (an EMC term). Data encryption, therefore, seems to be on everyone's hotlist for 2007. It's about protecting data where it lives -- not just in transit or while being used by a particular app.

Will Sturgeon in his article posted on silicon.com supports the premise that data needs to be protected from inside the perimeter. He quotes Jay Heiser, research VP at Gartner, as saying:

"For many organisations, the biggest risk will be insiders, not outsiders. The fact is that a significant amount of proprietary and regulated data walks out the door everyday"
In this article from Information Security magazine, Marcia Savage lays out IT priorities for 2007. She points out that in 2007 IT managers will shift toward focusing on the inside threat.

All of this data encryption will present significant challenges for Identity and Access Management professionals as well as application developers. Encrypting data means use of encryption keys which need to be managed. And determining who should have the ability to unencrypt data. And making sure that users who have rights revoked are no longer capable of performing unencryption tasks. It should present a lot of interesting discussions.

Phishing Attacks

Another commonly mentioned priority for 2007 is the prevention of Phishing attacks. For vulnerable organizations, Anti-Phish efforts will be critical.

At RSA's Phishing Reports site, you can download a copy of December's On-Line Fraud Intel Report. A quote from the report:
The number of institutions coming under attack rose to an all-time high the final month of the year, surpassing the previous high of 195 set in July. This was largely a result of fraudsters stepping up the use of security-upgrade-related cover stories in advance of the FFIEC guidance deadline in the U.S. That said, the number of brands being phished is not expected to fall off markedly in Q1 ’07.
That's nearly 200 different organizations in a single month reporting phishing scams. That means that someone you know is likely being phished for information (if you're in the U.S.).

Here's a place to find more fraud stories from the FBI and NW3C.

Happy 2007!

Monday, January 8

Yikkes! Bad Security

Dave Birch (Hyperion) posted about an administrator at a large financial firm who encourages his user population to tether their RSA SecurID tokens to their laptops. All I could really say is Yiikes! ...and I don't think I've ever used that word before. Imagine the look on his or her face when the CIO (or other IT manager) who approved the 2-factor authentication project in order to achieve greater security got that email.

Apparently, some of the employees of this organization complained about having to carry a token with them. I can understand that, but there are certainly other options -- think Blackberry or Mobile Phone token, software token, browser toolbar token, just to name a few. And even the latest token design is less bulky on your key chain if you elect to stay with physical tokens.

So, if this message gets back to the SecurID administrator who posted that message, please reach out to us. We can make life easier AND more secure. It's not an either-or scenario. These users can install a soft token on their mobile device and then leave their hardware token at home where they use it most.

The proposed tethered-token solution really minimizes the organization's security investment. And I can only guess that this practice would have a negative affect on a security or compliance audit.

[Addendum: Dave was pointing to another article.]

Wednesday, January 3

Some Identity and Password Reading

As Ash already mentioned, Jackson Shaw is now blogging. I remember Jackson from a time when MIIS was my tool of choice. He's been doing the identity thing for a while, so he might be worth a read.

Here's a few other useful articles I've recently come across:

...I guess that's all I've got right now.