Social Engineering: Why Employees Are Your Security

Imagine this situation: A coworker calls you in a panic. He’s facing a fast-approaching deadline, and you are the only person who can help him succeed in getting some critical task done. This hypothetical coworker explains to you what he’s working on and how it’s critical to the success of the organization in some way; he’s at his wits’ end in trying to accomplish a portion of that task (say, downloading a critical file from an internal file server), and he’s asking you in desperation to help him out. Would you help him?

Of course, right? Most of us wouldn’t even stop to think about it. And most of the time, helping out a coworker like this would be the right thing to do. Not only would it benefit the person asking for help, but it would benefit the organization as well. It’s no question why: Our success as a species has always been made possible by our natural proclivity to assist each other in a pinch. For eons, we’ve helped each other till the fields, build shelters, herd animals, fight off invaders and so forth. The desire to help our neighbors and community members is a powerful driving force that’s arguably hard-wired in to our psyche — by helping our communities succeed, we help ourselves.

But there are certain situations where this feature of human behavior can be turned against us. Social engineering, a style of attack that leverages trickery to gain information from our organizations’ employees, involves gaining sensitive information by basically just asking for it. In other words, attackers can and do attempt to coerce employees into divulging important information through “pretexts” — false scenarios that leverage our employees’ human nature to lead to compromise. And, as you can probably imagine, it’s highly effective.

To illustrate just how effective the strategy is, consider the recently held, highly controversial social engineering challenge conducted at the annual DEFCON hacker convention in Las Vegas. The parameters of the challenge were as follows: Given about a half-hour of telephone time, attempt to gain sensitive (but non-harmful) information from large-scale organizations across a wide swath of industry.

How successful were they in gaining this information? Would it surprise you to learn that it was close to 100 percent?

Weakest Point, but Least Addessed

So the DEFCON challenge succeeded in demonstrating empirically (and quite dramatically) something security professionals have known for a while but are seldom able to do much about. Specifically, the challenge demonstrated that employees are a huge weak point when it comes to information security and also that most organizations aren’t doing enough to address these types of issues.

The truth of the matter is that every employee in our organization — from the CEO on down to the humblest temporary worker — knows enough to put us at risk to one degree or another. So these employees need to be protected from attack in much the same way that technical resources are. A technical resource, like a Web server or network file server, is shielded from attack by multiple layers of technical security countermeasures: Firewalls restrict access, antimalware software filters out known hostile software, intrusion detection systems watch vigilantly for attacks, and audit logs keep a record of who does what. All of these technical controls work together to reduce the attack surface against our technical resources and make sure that if something does occur, an investigation is facilitated. But how many of us have similar defenses in place to keep attackers from engaging our employees in human-directed attacks? Not many.

The reason for this lack of controls on the human side is twofold: cost effectiveness and business impact. From a cost perspective, defenses against social engineering are expensive. It is a relatively straightforward matter to deploy a technical control to address particular types of electronic threats, but social engineering defenses need to work within the parameters of human memory and employee attrition. Training, for example, is the control most often cited as a defense against social engineering. But training is costly to perform, and employees need to be re-engaged in an ongoing fashion — remember that employees quit and people forget things — so keeping employees trained over time is expensive. As far as impact to the business goes, remember that employees, while they are being trained, are unavailable to actually do their jobs.

Prevention Strategies

So what are some effective strategies to prevent social engineering? First of all, it’s important to assign ownership of this issue and make sure that there’s no ambiguity about who is going to own what aspects of it. In many organizations, the technical-level security we’re all familiar with is within the IT organization, while protecting against human-directed threats (including social engineering) is not. In that case, ownership of defending against this type of problem might be located somewhere outside the security office, potentially within human resources. So the first step is to make sure you’re positioned to be effective. This can be as simple as a partnership with whomever currently owns the problem to help develop joint a solution.

Once you are in position to take action, the question arises of what action specifically to take. The most often recommended defense against social engineering involves a combination of policy and employee education. Briefly, the intent of this type of training is to prohibit via policy the dissemination of certain types of information and then education of the employee to inform them of the policy and make sure they are aware of it — and even of potential attacks. This is a useful first step.

However, it’s important to note that you can’t train an employee out of being human — meaning, many employees will still bend (or outright break) the rules to help someone that they perceive to be in trouble. In other words, many employees will knowingly do the “wrong thing” (act in a manner contrary to policy) if they think they are acting in the overall best interests of the organization to do so.

This can have unintended effects in a social engineering situation. Therefore, it’s useful to start with training and policy as a first step, but “automate” the enforcement of the policy.

For example, consider the problem of helpdesk personnel giving away passwords. In the short term, refine the policy to preclude help desk personnel from providing passwords over the phone, and train the helpdesk personnel on this policy to make them aware of it. But don’t stop there. Enforce the policy by updating the systems that the helpdesk personnel use to not display the password in the first place — take away the ability of the personnel in question to act in a manner inconsistent with policy. In short, look for ways to adjust the processes you follow so that lone employees can’t “strike out” on their own to put the organization at risk.