Improved Security on the Identity Infrastructure

I wanted to expand on my earlier post about Extending the ROI of Provisioning. Here's a visual aide to help the discussion:

There's nothing new in this illustration. It simply shows that the provisioning engine connects to multiple identity data stores. As we know, provisioning systems have the potential to do a very good job at providing work flow and business rules around creation and management of user accounts across multiple systems. They may even have some additional capabilities around Separation of Duties enforcement, user attestation, user self-service password management, reporting on rights (based on its view), and more.

The Gap

What it doesn't do, however, is protect the connected data stores against direct access. For example, the DBA still has direct access to the database and the Directory Administrator still has direct access to the directory. They can create new accounts, view information, and change permissions. The system may be able to see when new user accounts are created during its next scheduled run, but that capability isn't always enough. I'll give an example.

One of these LDAPs is not like the other

I purposely shaded the Network Directory so that it stands out from the others. That's because it is different. Since the market for the Network Directory consists almost entirely of just two vendors (Microsoft and Novell) and one has a much larger percentage of the market (Microsoft), I'll just use Microsoft's Active Directory (AD) as the example.

Now, back to the gaps:

• Scheduling: When provisioning systems connect to AD, the connection and sync processes are often scheduled. And AD has a time lag in replication (usually 15 minutes). S0, if the sync is done hourly against a particular DC, the total time that a new account may be in existence on a different DC without being noticed by the provisioning system is a little more than an hour. Can you do damage in an hour? I could create an account, make it a domain admin, log onto servers, change rights, access files, and remove my trail from the logs within an hour.


• Coverage Scope: The connection may be made to a particular portion of the AD tree. So, if you created an account in a portion of the tree that isn't monitored by the provisioning system, it wouldn't get picked up.


• Source: Some provisioning systems use AD as the source. So, in that scenario a new account in AD would potentially create accounts and/or rights across multiple other systems. So, by specifying rights or group memberships, an AD administrator could grant himself rights to other connected systems (perhaps in between attestation cycles).


• Account Type: Provisioning systems generally only look at user accounts based on object type. So, you could create an iNetOrgPerson instead of a User object.


• Activity Scope: Provisioning systems don't even try to monitor failed logon attempts or failed user creates at the local systems. They also don't watch file open activity or file changes. What if the provisioning system pulls a feed from a text file and someone modifies that file? There's no knowledge of activity other than a particular type of account being created.

All of these can be applied to other connected data stores as well. For example, scope is an issue for relational database tables. The provisioning system may only watch specific tables or may completely ignore local accounts in the RDBMS itself. Likewise, if AD is not the source, the HR database is likely the source which yields the same issue for the HR DBA.

Conclusion

My point isn't that provisioning systems are weak. They do what they do very well. But, you can improve the overall security posture of the environment by including localized protection on the connected data stores as well. Encrypt the database. Monitor DBA activity and Directory Administrator activity. Watch directories for failed attempts to create or modify accounts. Watch for failed authentication attempts. In a nutshell, ensure that accounts and permissions are being managed through the provisioning system into which you've built the business rules and work flow to ensure that rights are being managed effectively.

And if you have to respond to auditors for compliance reasons, you can say you're certain that accounts are only being created according to policy; instead of you hope that to be the case.

I've heard the argument that this might be overkill (admittedly an over-simplified characterization of the argument). OK. In some scenarios, maybe you don't need tighter security. You only care about work flow efficiency and cost cutting. Or you're OK with the level of improvement in your security posture that traditional user provisioning systems provide. I'm not saying that anyone should ignore the risk analysis process. But, if compliance is an issue and you want to prove compliance beyond reasonable doubt or just simplify the audit process, solutions that locally monitor the connected systems may provide value.

And if you can demonstrate that 100% of your user and rights management processes are funneled through the provisioning system with appropriate work flows, I think you could justify claiming a much improved ROI on the overall solution with minimal additional investment.

Disclaimer? Yes, NetVision can help with reporting and monitoring on your Network Directories (both major vendors) and related file systems. But that's no reason for me not to talk about it!