It’s Not Hacking If You Let Them In

Right now, I have administrator-level access to at least nine resources that are related to contracts I no longer work on. I never signed an agreement that defined how I would use that access. And I never signed anything saying I wouldn’t access it in the future.

If I worked for you at some point in the past, those three sentences should have you scrambling to check your corporate security, because I’m probably not the only person who shouldn’t have access. Based on a recent ruling, there’s a reasonable chance I could use my access with no repercussions.

How could I “get away” with accessing data that I no longer have a need for? If I was given access to data and given no explicit guidance about how I may or may not use the data, then it appears I may be free to do whatever I want with my access. The Computer Fraud and Abuse Act (CFAA) allows a civil lawsuit against someone who obtains information from another’s computer “without authorization.” Give that someone authorization and the rules change.

WEC Carolina Energy Solutions, LLC v. Miller ruled that the CFAA doesn’t necessarily protect employers from misappropriation of information. I’m stretching that a bit further and speculating that giving anyone access without defining their boundaries is a huge mess, but I’m probably not that far off.

If you deal with identity management issues, it’s high time to rethink how permission is given and what measures are taken to revoke that permission. If you give access to someone, even if that access was granted by mistake, claiming that they hacked into your network is probably not going to work as a remedy.

Remember your towel and don’t panic. It’s far better to establish an audit trail so you can see when user behavior falls outside their normal scope, while simultaneously creating an audit system to that regularly checks to see which users need to have access to any given resource.

As Rafal Los (aka Wh1t3Rabbit) puts it, 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)

How will you change your security policies knowing that giving access will change the way you need to think about security?