Waiting at a Station

by Deborah Volk on May 13th, 2009

In a blog post a few days ago, I wrote about the parallels between Security Information and Event Management (SIEM) and Identity Administration solutions. In both cases, when an event comes in from an external system, there are rules that evaluate the event. If the event is deemed to imply a threat (in SIEM case) or a compliance issue such as a rogue account that could lead to a threat (in Identity Administration case), I wondered about possible actions that could be taken without involving a human. In this blog I'd like to examine a related premise and do it from a gentler, kindler perspective of a business process known as attestation where humans play an important role.
Before identity administration tools grew up to be 6 feet tall and started sneaking out at night, attestation the process had already graduated from college, bought a car, got promoted to sous-chef and was about to pass the baton to the next generation. The term attestation came from legal jargon in accounting. In the accounting world, attestation refers to "an assertion about subject matter that is the responsibility of another party", someone vouching for you, in other words. Given the love affair in management consulting between accounting and IT, attestation infiltrated the fertile field of IT audits. There, the definition of attestation stretched out to encompass the entire process of gathering information about stuff and having people sign on the dotted line that the stuff is indeed good stuff.
As identity administration products matured and gathered steam, attestation went up into their crosshairs and reasonably so. Attestation is a recurring process, typically quarterly but sometimes as frequent as monthly, involving people from multiple departments, not to mention a sizeable IT data collection and correlation exercise that relies on a myriad of spreadsheets and scripts. Instead of hearing soothing words such as "accretive acquisition" a CIO or CFO would hear "recurring expense" and "can you give us directions to the tree that grows money". This is like waving a red flag in front of a charging bull. Reducing the expense of an IT audit, attestation being one of the key processes backing the audit, is every CFO's dream.
How do you reduce the expense of attestation? The top expense is human labor so you want to automate many of the attendant tasks done by humans, such as data collection and reconciliation from external systems in audit's scope. Automation is best done by an identity administration tool such as Oracle Identity Manager. The data collected can be anything but it's typically user accounts and associated entitlements. Once the reconciliation is done, someone has to attest to the fact that Barry O. Bama is still an employee and he still needs his superuser account on a UNIX server whitehouse.gov. That someone is typically the person's manager although if segregation of duties is implemented in a strict fashion, the attester is not the manager. (Look at Barry, he's got nine attesters that are not his managers). Taken together, if an employee has 20 accounts with 5 of those are on auditable systems and there are 5000 employees, that's 25,000 attestation events every quarter. Big, expensive headache.
It is, therefore, desirable to reduce the scope of attestation. You can't decrease the number of auditable systems but perhaps there's a way to decrease the number of user accounts or entitlements to attest. Instead of doing a blind sweep of everyone and their pet koala (only at Google, folks), we could consider dividing our population into two segments: active users and dormant users. Dormant users would be defined by an audit-blessed policy such as "everyone who hasn't accessed the system since the last attestation". The active users is a riskier segment, who knows what they've been up to on a target system. The dormant users have been vetted and if they haven't been naughty since the last outing, why require a check?

One reason to check dormant accounts is to have a human attester verify that the user is still alive and well and he still needs the account or entitlement. If he isn't alive or he no longer needs the account, the attester could choose to trigger the disable workflow. This is a good but unnecessary reason from a risk perspective. After all, attestation is about mitigating risk and if the user hasn't uttered a peep since the last attestation, there has been no plausible increase in risk (digging tunnels a la the Count of Monte Cristo excluded). Disabling the account might free up some infrastructure resources but the expense of the entire process that leads to the disable event is much greater than the benefit gained. Unfortunately, most IT auditors view dormant accounts as a riskier segment than active accounts although the rationale behind such view is not clear to me.
If dormant/active is our (admittedly simple) segmentation strategy, how can we place users into either segment? Some auditable systems may not keep track of when the user was last seen on the system. In my next blog I will examine some practical approaches to recording and extracting data related to users accessing the system.


Posted in Oracle Identity Manager    Tagged with oim, attestation, audit


0 Comments


Leave a Comment
Search

Subscribe

follow on

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)