D-kriptik Blog

And, here is part three. I’d wager that our feed readership has dropped from ~40 people daily to ~5. To those ~5, well, enjoy!

-

Where was I? Oh yeah, rambling about security and the human factor.

There is this big word we have all said before, trust. Trust can mean lots of things, but, at its heart, trust implies risk or vulnerability. Trust is about having faith that someone or something will act a certain way when it counts. While you may be able to influence that someone or something to act that certain way, in the end, the actions are out of your total control.

Trust is often at the root of an attack. For example, we trust that piece of software by running it on our system. That software could, in reality, be a trojan. Or, it could have a buffer overflow that results in an attacker gaining full access to our system. Or, it could just eat CPU cycles and do nothing in return.

Social engineering is often tied to trust. You get people’s trust, and then you exploit that trust. This involves overcoming people’s fears and concerns over assuming risks and exposing vulnerabilities. Sometimes overcoming such things is easy, sometimes not. Responsibility is often a key factor in determining the difficulty involved.

(Interestingly, I recently observed someone use a different tactic for social engineering. Rather than trying to gain trust, they took the approach of being underestimated. With their motives and capabilities completely underestimated by their target, their target deemed them harmless. I watched this person use such techniques to glean a ton of information from an unsuspecting individual.

What really caught my attention about this was the question of whether such an attack relies on trust. Instead of trying to overcome concerns about assuming risk, this person bypassed the whole issue by not being a risk at all. No need to trust someone when they pose no threat. And, no, this is not simply a terminology discussion. Under certain circumstances, I think the effort expended using an underestimation technique may be less than trying to build trust in more explicit ways.)

So, what are we to do about all this?

First off, we need a threat model. We need to figure out what we want to protect, its value, the potential attacks, the likelihood of those attacks, and the potential damage of those attacks. Determine the risks, and then mitigate them. Very important here is figuring out who needs to be held responsible for what mitigations and countermeasures. And, this threat model has to be reviewed periodically to keep it up to date. The assets that need to be protected change, the way business is done changes, the risks change, the mitigations change. Security is not static.

With that (and building that is certainly not trivial), we have these people, you, me, our parents, that are part of this threat model. They pose risks, and they help to mitigate risks. We need to minimize the former and maximize the latter. To do this right, I think we need people to feel responsible for security. To build this sense of responsibility, we need these security responsibilities audited and we need effective training to convey and reinforce these responsibilities – the combination of these two may be a linchpin to people security.

So, we talk to people about our threat model. Not only do we teach it, but we get feedback on it. And, we make sure everyone understands that threat model, and their place in it. To do this, we bring vivid examples from security audits into our security education, which help to build security training programs that provide exactly that which we learn the most from, experience.

What exactly should these examples be?

Well, lets look at a bad example you may have considered at some point. As part of your security presentation on passwords, an IT person runs a crackers against people’s password hashes and shows how trivial it is to crack weak passwords. Is this effective? Well, I tried it at one point, and, no, it failed. One reason was that people felt I already had access to their passwords, which made the whole thing silly to begin with. This was the stuff I had to deal with, not them. Another reason was that password hashes, dictionary attacks, and cracking in general really have no meaning to most people. Which meant, this demonstration was not about the people being trained, it was about me, and so it did not hit home, it could not serve as real life experience.

Now, lets look at a much better example. In preparation for security training, you have someone sit outside your organization auditing whether people were taking off their ID badges before leaving work, as was mandatory. As part of this audit, the auditor photographs the ID badge of someone leaving the offices still still wearing their ID badge. The next day, that person comes to work to find you sitting at their desk wearing an ID badge with their name but your face. Now, that would make an impact.

Keeping with this scenario, lets say you use that photo to create a fake ID, and then try to get through security with that ID. Say you make it through security. Well, now the security staff becomes part of the demonstration. And, say, sitting at this employees desk, no one stops you to question why you are there. Or, perhaps they do stop and talk to you, and you talk you way out of their questioning. Well, more for the demonstration. And, lets say you are caught at some point during this process. Great, more for the demonstration. I didn’t say the failures were necessary, just that we needed real world experiences to which people could relate.

Of course, that may be considered an elaborate setup, and maybe it goes beyond your threat model. Maybe you want to keep it very simple. Perhaps a bit of dumpster diving could be used. Or, maybe have a stranger walk into the office building and wander around. Did they get through security? Did anyone stop them? Did they talk their way out of it?

Now, pull the results of these attacks into your security training. Will there be an impact?

Well, I think so. You don’t quickly forget seeing yourself and/or those around you up in lights, as it were, and the attacks can certainly be used to increase the sense of responsibility felt by every employee. The demonstrations hit home because they can be related to – the attacks happened to you, your neighbors, your community. Whether the attacks succeed or fail, they amount to a shared experience for the organization, and teach people their importance to the security of their organization.

I think people would feel like their security responsibilities are not just words but actual obligations which have real consequences to the security of an organization. The threat model lays this out, but the experience drives it home. Also, people would be aware that their organization takes security seriously and is willing to proactively audit that security. And, those audits involve real life employees, doing the right thing and maybe even the wrong thing. It lets people know that they are at the root of security.

Anyway, this ramble seems like a good research area these days, and I think there is a lot to (re)learn about security from these vantage points, at least, for me. It’s vintage, sure, but, hey, I know lots of people that wear vintage. And it looks good.

And, that is where this ramble ends.

This entry was posted on Thursday, February 22nd, 2007 at 9:46 pm and is filed under Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.