Landmark Ruling: Insiders Aren't Hacking if You Gave them Access

Monday, October 08, 2012

Rafal Los


How many systems, applications, or servers do you have access to right now in your organization?

Right now, do you know which systems you're supposed to have access to? More importantly, do you have access to those and only those?

Right now, I have access to something like 100+ things inside the organization, give or take a dozen. I've been here almost 5 years, and have accumulated access to applications from HR to payroll, to some obscure health-related apps I don't even have more than a faint memory of, to the expense system I begrudgingly use regularly.

Additionally, my single sign-on profile probably gives me access to a few dozen things I don't know I have access to, then there's the file-level and folder-level permissions on various shares I've needed or used throughout the years. Of course all of this isn't counting the SharePoints, communities, internal and external partner sites and the list goes on, and on, and on, and... you get the point.

Now you try.

Make a list of all the stuff you're supposed to have access to, and then ask yourself if you can get a good guess about all the things you should have had your rights revoked to that probably never happened.

What happens if you go perusing through your corporate file-share lists, applications directories and such... and find some interesting stuff that you aren't technically supposed to have access to yet the controls in place have no problem giving you permission? Does anyone notice?

What if you were relieved of your duties... how quickly would you lose access to all those little apps and portals internally or externally to your organization?

I bring this up because there was a landmark case recently (cited here and here) that basically set the precedent that you can't charge someone with 'hacking' if they have proper access to the applications, systems, or data, even if they shouldn't.

This is, as I said, a landmark ruling.

When IdM (Identity Management) became the big hot topic a few years ago one of the things we were big on is making sure we can delegate AND revoke access quickly and efficiently. The problem we're running into today is continued sprawl from VMs to application environments and now we have the cloud to make it even more complicated. Few (large) organizations are prepared to completely erase every trace of an employee at the push of a button, on command. The reality is, this problem worsens with every tick of the clock.

Let's say you've gone to great length to have account provisioning working like clockwork. Let's further even say that your applications access is 75% done through a single directory of single sign-on and rights access management. This only typically covers the easy part - access. Developers are still largely missing the AuthN vs.. AuthZ point, and once you've given access it's (still) quite difficult to provision role-based attributes for specific use cases.

Sure you have access to the time-card system as an employee - but what does that give you the right to DO? Unless your organization has properly outlined the roles (employee, manager, auditor, etc) you are stuck with a difficult task if you're the provisioning person.

Some organizations turn to outsourced user-access management of their IdM systems, but still need to make sure that their applications are designed correctly, and enforce role-based access and honor provision/de-provision requests in a timely manner. Unfortunately web applications are notorious for this... here's why.

When you stand up a web app, you generally have multiple environments (dev, dev-test, UAT, production, etc) and user-access systems have to be applied to those various environments. Unfortunately when applications are in test environments sometimes they user real data in the database, which can include real-user rights to data. In the mix of provision, load data, test and all the other things going on in the miraculous dance to get an application out the door it's not uncommon for steps to be missed, access rights granted "just this one time for testing", and forgotten about.

In light of the new, and sure to be cited I'm sure, case law that says if an employee has access to something - even if mistakenly - you can't charge them with "hacking" how many organizations will now be scrambling to audit their system, application and data access rights? You may be one of them... so if you're thinking about this and maybe a little bit of panic washes over you, here are some things to remember:

  • Regular auditing of user rights should be a function of the security organization, to audit and govern/enforce access rights set out previously in your guidance
  • Your organization should have an acceptable lead-time for provisioning and de-provisioning access. Is it 15 minutes, or 24 hours that your organization is comfortable with? This needs to be outlined in your security policy if it isn't already
  • Now that you have established the acceptable time for account changes, you should regularly audit/test this to make sure that it works as prescribed
  • Because mistakes and lapses happen, you should have a central platform that can tell you everything a specific user ID did during the course of a day, and then be set to alert you when something 'anomalous' or unwelcome happens (as defined by their job roles)

Managing rights, access and provisioning/de-provisioning of those rights is a tricky business. Companies have spent millions on software packages and consultants to have it work right - but until you've experienced a critical event, or tested your organization's performance you may never know how whether the whole machine works well or not. If you're not sure, run an audit. You don't have to audit every account, every system and every application to get an idea of how well you're doing ... a reasonable sample size will do.

The not-so-secret is - know your business, know what your users have access to. Manage and monitor closely - because case law is starting to turn against organizations who are lazy and try to falsely accuse employees of "hacking".

Cross-posted from Following the White Rabbit

Possibly Related Articles:
Network Access Control
General Legal
Legal Access Control Data Loss Prevention Policies and Procedures
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.

Most Liked