One of the nice-to-have benefits of implementing an identity management solution is the ability to know what's going on inside a target system. If someone creates an account on the target and the account violates an IT policy or procedure (thou shall not create accounts directly without going through Oracle Identity Manager), this fact is quickly discovered during reconciliation (if it's smart enough!) and/or subsequent review of reports. This problem of so-called rogue accounts is encountered very often and we've engineered many a solution for it for customers. (Naturally all of our solutions are very smart).
Rogue accounts may carry a linguistic negative charge but in the context of identity administration, a rogue account is not necessarily malicious, it's simply something that shouldn't be there based on some rules. The rules may be formal (IT policy) or informal (that guy with a scythe and a pitchfork said so). Many rogue accounts are not created by evil insiders seeking to materially alter the company's financial statements, they're mistakes or what I call oops-conveniences of operators. Identifying a rogue account is easy in programmatic terms. The challenge lies in flushing out the business rules and a myriad of exceptions for various accounts that illegitimately exist on the target system and naturally are declared VERY IMPORTANT TO THE BUSINESS. It doesn't matter that last time they were used was in 1984, they're there just in case a nuclear attack happens and we all have to go to the bunker. When we emerge from the bunker 20 years later, the accounts are alive and well, voila!
Let's pretend we've got all the rules and exceptions documented, we run a reconciliation and oopsie daisy, we've got a rogue account! This is a Las Vegas moment when you've hit the jackpot - bulbs start flashing, floor is shaking, music is blasting, people running with fire extinguishers and throughout this cacophony you have to remember to scoop your winnings and go on living. What do you do with the rogue account, what action do you take? (If this was Vegas, I'd surely double down). Opinions radically diverge from this point.
One approach is to notify people, usually send an email to a mailing list hoping that someone is going to be awake at 3am and burning with desire to investigate. This approach is boring but safe...or is it? Consider the now infamous case of Fannie Mae. One of their contractors was terminated on a weekday at 1:30pm. He wasn't even walked out of the building although that's a subject for a different post. Not only he was still in the building with his laptop, his access wasn't revoked until later in the evening on the same day, giving him plenty of time to launch an attack. What does termination have to do with rogue accounts? If immediatley revoking someone's access upon termination is considered a best practice, why should rogue accounts that carry as much (some might even say more) destructive potential be left untouched after discovery.
This leads to another approach: automatically shut off the account upon discovery. This approach is not very popular because of what-ifs. What if the account belongs to a VIP (who asked the administrator to circumvent a policy and create one just for him..) ? What if the account is used by a REXX script for talking to a mainframe noone even knows exists (yet it runs the company's payroll..) ? What if, what if, what if. The root cause of what-if-itis is company culture. Many organizations blindly preaching the mantra of "IT is at the service of the business" don't realize the hidden cost of saying "yes" without reservations to any business request. What would you prefer - a mechanic that will gladly replace your transmission with a new one (since you asked about the knocking noise) or one who will try to convince you that some noise is to be expected, all you need is a tune-up.
Fortunately or unfortunately, safe but boring (amplified by what-if-itis) trumps aggressive any day of the week in just about every business...unless you're Fannie Mae. This is where insurers make their money by weighing the odds but they've got statistics and past history whereas we're operating on very few data points, the rest is heuristics. What's more risky - increase the likelyhood of an insider attack by leaving rogue accounts up to somebody in operations and hope lightning doesn't strike or shut off the account and hope you still get to attend the free yoga class in the morning after that angry VIP finds out it was you.
Is there a middle ground between these two extremes? Yes..but it's hard to navigate. This blog post was brought on by several threads about SIEM tools and their ability to automatically respond to threats. Marketing: SIEM threat response is the best thing since sliced bread. Reality: very few deployments use the automatic defense response mechanism because of issues, false positives being #1. False positives exist because there's either not enough data to make a decision, not enough semantic power in the threat model (rules, analytics, what have you) or simply not enough knowledge contained in the threat model.
This introduces the question: given the ample information stored in the identity administration tool's repository about one's identity, resources that belong to the identity and history of events across the resources for this identity, is it possible to create a threat model that would allow for a low false positive rate when shutting off rogue accounts? Discuss in comments.
by Deborah Volk on May 5th, 2009
Posted in Identity Management, Access Management Tagged with siem, insider threat, reconciliation, rogue accounts
Leave a Comment
Access Management (19)
Ask Identigral (6)
Change Management (10)
Data Quality (4)
Identity Management (27)
Passlogix v-GO (3)
Sun OpenSSO (3)
Sun Role Manager (3)
11g 3rd bday JavaOne SAML academia accuracy active directory adapters administrative agilent ask identigral attestation audit bpel bpmn bpm business case cdi cloud computing connectors contextual search data masking data quality deployment dip entitlements federation gartner groups gtc guests insider threats insider threat java jca jms lifecycle limericks linux mashup mdm messaging migration nabaztag oaam oam oas obiee oc4j oel off-boarding ohs oid oif oim oow09 opensso operations osso ovd owsm passwords patching performance phi privileged accounts provisioning queues reconciliation risk rocks rogue accounts rsa10 semantics siem sim sjsds sod solaris suncle thermodynamics twitter virtual reality vpd waveset webinar whitepapers