I was looking over the definition of secure the other day and found the following entry:

v. fix or attach (something) firmly so that it cannot be moved or lost

And then I applied it to security initiatives within IT. The goal aligns well; you want to fix (read: configure) your network so that the security controls you put in place doesn’t are not “moved or lost” – that is, in our case, allowing someone to bypass those controls.

But, for most organizations, the idea of giving someone elevated privileges is given little focus, other than to consider whether the person in question needs the permissions. So, in essence, you simply choose to trust the person and likely, never give their use of permissions a second thought.

Now look at the definition of trust:

n. firm belief in the reliability, truth, ability, or strength of someone or something

Focusing (for the sake of the security context here) on the reliability part of the definition, if we were talking about your firewall settings, you’d likely check to see if the settings were in place (which defines how the firewall acts). If you think about it, what you’re really validating on the firewall isn’t whether some specific port is open or closed; you’re actually checking to see if the firewall is behaving the way you expect it to.

So, how about that user given elevated privileges? Do you apply the same level of scrutiny? No, I’m not talking about the permissions you assigned; I’m talking about whether you check to see if they are behaving the way you expect them to!

People, like the firewall, are “configured” to act a certain way – permissions are given, expectations are set, and then, in the case of an act of trust the user… nothing. They’re never checked again. It’s important that you put the same level of inquiry around a person’s behavior as you would your firewall.

Even the most trusted individual in your organization (could even be you) can go through a life event that suddenly makes data theft, fraud, etc. not so unrealistic. While you can’t simply ask a user “are you embezzling from us?” or “have you stolen any data lately” (you won’t get an honest answer, right?), you still need to put forth an equal level of effort to determine what a user has done with the privileges granted (that is, their behavior).

To learn more, download the whitepaper, Insider Threats: Trust isn’t a Security Strategy.