I think we are closing in on violent agreement

Reconciliation can add tremendous value to the provision solution, if tight management of “privilege drift” is risk appropriate. And of course, the trust one can have in any control system is limited by the trust inspired by the integrity controls for the platform those controls run on.

- Erik

AD, for example, generally takes 15 minutes to replicate. So, even if the provisioning system sync’s every 2 minutes to a DC, there may be a 15 minute window where an account could be created, used and deleted — and then the logs cleared. That’s just an example. Another is that provisioning system logs can’t tell you WHO created a rogue account in one of the connected systems or that a DBA opened a table to review identity data in Oracle.

My point is that we should look at extending the reach of the overall systems to protect against additional attack vectors - encrypt the database, monitor the database for local changes, record who makes those changes, etc.. It provides additional security, audit ability and deterence.

Dan - logging isn’t bad by itself, but we need logs of what’s happening at the connected stores in addition to logs of what the provisioning systems are doing.

Am I way off base here? Are you saying that there are no holes or that there’s no need to fill them? I thought I heard a little of both of those arguments. I know you both by reputation and appreciate your input.

Whoa — if you find a system that can guarantee 100% accuracy with all provisioning activities, buy it (and buy the company!!).

I have designed systems that ensure that no one can mess with the logs of what was reported to have happened, sufficient for evidentiary controls. However, it’s a completely different problem to ensure that everything that actually happens gets logged. There are too many opportunities for collusion, malicious admin, failure in update, and other issues that will cause events to go unlogged.

Fortunately, for those of us in the private sector that don’t deal with nuclear materials or secrets, that level of rigor usually is not needed. 99.999% logging is good enough for most business applications, and probably for nearly any court case you’d need to prosecute, since that log isn’t the only point for forensic evidence. I’ve only seen a few systems that were capable of 100% logging, and those spent millions on aircraft engines and diesel tanks for tertiary power alone. Most of us don’t need perfection.

What we do need to do is to show reasonable due diligence at implementing and manage preventive and detective controls commensurate with risk. For nearly all of us, that risk doesn’t require 100% accuracy.

ddh

Reconciliation is a detective control, not a preventative one.

The goal is to detect when the other controls have failed and to detect that quickly. How quickly? This generally depends on the kind of connectivity between the Provisioning system and the entitlements store. Generally, you can achieve very tight oversight over directories (such as AD, LDAP, etc.), knowing within minutes that an change has occurred. Systems that require data extracts of the privileges will obvious be reviewed on a schedule.

As to what action to take…

Reporting and alerting are generally the best options. There are systems that support immediate revocation of a suspect privilege - but I personally see the operational risks of that outweighing the security risks of taking a day or two to run down the discrepancy.

As to your other questions, no control is prefect. Compare this kind of Reconciliation to the Reconciliation of business checking accounts. Do you reconcile all accounts on the same cycles? Is there additional oversight on accounts with higher risk transactions? You see, it’s not a question of appeasing an auditor, it should be a question of identifying and managing risk.

Did I come close to addressing your questions?

Cheers, Erik

Are you saying that the provisioning systems themselves provide sufficient non-repudiable evidence that the access rights stored in the connected systems is totally within policy 100% of the time? What about when they’re changed?

What if an account was found to have been given elevated rights through a back channel (direct admin access). Does the provisioning system tell you who granted those new permissions? Is a third party auditor satisfied with the provisioning system logs?

These aren’t meant to be sarcastic or trick questions. My experience is that provisioning systems alone aren’t enough because they don’t see past their own arms. The DBA still has control over the database. There are often practical limitations to the systems abillity to even capture the most basic information. …maybe the connector is tied to a specific portion of AD rather than the entire domain or maybe it checks for updates every hour or even every fifteen minutes. There just seem to be holes.

But, I sincerely appreciate hearing alternate viewpoints - I just wanted to clarify that I’m hearing you right.