Rogue Accounts – Now Legally Challenging As Well
The impact that judicial courts are having on the world of tech has been in the news recently, whether it be an Italian judge ruling that content sites are liable for user uploaded content, or the class action lawsuit that Google Buzz faces over privacy issues. But another legal opinion was brought to my attention (thanks to Ashraf Motiwala) that has implications for anyone trying to run an IdM program at an enterprise.
Kurt Johnson at Courion blogged about a ruling in a case (LVRC Holdings v. Brekka) regarding wrongful use of enterprise accounts by an employee after being terminated. Read his post for a more detailed description of the case and the ruling, but it basically boils down to this: It is the employer’s responsibility to terminate access, and therefore the (terminated) employee did no wrong by using it since their access was not taken away.
I’ll stay out of the moral/ethical implications here, but what this means to a business is that making sure you take away access from your employees/contractors when they shouldn’t have it any more has suddenly become a much higher priority. Because if that person uses their accounts to do anything when you no longer want them to, it is not their fault, it’s yours. It could become a legal issue for you, the kind people look to learn more here, which can be awful in the long run. Ensuring prompt revocation of access was always good business practice, but now it becomes a business imperative because your legal protections (employee contract be damned) are greatly weakened.
When compliance became a bigger driver for IAM than IT efficiency, the approach to rolling out identity management projects did evolve to reflect this kind of thinking. But this case is as good a reason as any to reiterate what we have been preaching for years now – that your IAM deployment must have both proactive and detective controls in place to ensure compliance. The proactive control in this instance is Deprovisioning, while the detective control is Attestation.
A common best practice staged approach (thought not the only one) to IAM projects that incorporates this idea is:
- Start by building up your Who-Has-What database (either in your provisioning product or in your identity governance product)
- Put in place a periodic attestation process to force review and sign-off of user access by those in the know (managers, application owners)
- Create a deprovisioning project. Start off with manual processes that are triggered off your HR and Contractor management systems. Evolve to an automated process over time, which should include linking your attestation process to your deprovisioning process for handling rogue accounts
- Start rolling out request-based provisioning for application access. Start with manual processes and evolve to automated processes in a phased manner
- Start working on a role management project as a way to implement role-based provisioning. Again, follow a phased approach.
The stakes in the IAM game just got a little bit harder. Make sure your project has these goals in its sights.
The actual court decision does not appear to be based at all on the account not being disabled. The allegation that the former employee had used the non-disabled account without authorization was apparently dimissed due to lack of sufficient evidence that it had been used by the ex-employee.