Let’s face it: Social engineering — attacking an organization through deception by “tricking” internal users into sharing inappropriate levels of access — isn’t a topic that comes up very much in most IT shops. This isn’t because social engineering is ineffective or because organizations aren’t susceptible to it.
To the contrary: Although direct, quantifiable evidence about social engineering is difficult to come by, what statistics we do have (for example, the 90+ percent success rate at Defcon 18‘s Social Engineering “Capture the Flag” contest) suggest that success rates for social engineering attacks are disproportionately high relative to attacks against technological components within our infrastructures.
Instead, it tends not to come up in many cases because it’s not perceived as an “IT problem.” Since there’s relatively little we can do at the technical level to prevent social engineering — and it doesn’t require deep technical skills to pull off — it’s sometimes viewed as not the job of IT to address.
And it’s no wonder it’s so effective. When we look objectively at controls that ostensibly prevent it, we find they don’t work very well. Traditional countermeasures to social engineering — awareness, education, and policy — are less effective than we usually care to admit. Why? Because they rely on human memory (users have to “remember” to do the right thing), and they ask users to act contrary to human nature (users are asked to view requests for assistance with distrust). Can you imagine asking a passerby on the street for directions only to receive a challenge about “what kind of scam we’re trying to pull?” in reply? Not likely to happen, right? But isn’t that akin to what we ask our users to do when we ask them to be alert for and respond to social engineering attempts in their interactions with users?
So the question remains: What can organizations do to make incremental improvements in defending against social engineering without breaking the bank? It turns out there are few things that we can do that don’t cost a lot to help.
1: Identify Your Targets and Make a List
Anybody in the organization can be a target of social engineering. An attacker, for example, could potentially contact any employee utilizing a false pretext, like claiming to be a member of the IT support team who needs the user’s password. It could happen any time to any member of the organization. This ubiquity of targets is part of what makes social engineering so difficult to defend against.
But there are some targets that are more tempting to an attacker than others: help desk operations, call centers, or anywhere else in the organization that has elevated access and is also expected to interface with the outside world. From a prevention standpoint, “arming yourself” with foreknowledge of where these places are is extremely helpful. While it’s true that an attacker could target anybody, they’re most likely to start with the lowest-hanging fruit. This is why having a place to focus your efforts is a useful idea.
2: Recognize and Address User Limitations
Say you have a help desk where support staff perform password resets for users for a particular application. This is an extremely tempting vector for a social engineer to attack, and it’s probably a place you’d identify as you create your target list. Going back and changing the existing process would be a struggle … but what if you were to set up a new process today? Say, for a different application, or as part of a migration effort for the existing one? There are things you could do differently, right?
You might choose, for example, to build steps into the process to take decisions about access (and access to security-sensitive parameters like the password) out of the hands of support staff. You might choose to automate technical compliance with a user authorization process (like a password reset “security word”). It’s tough to go back and undo bad decisions made in the past, but you can stay focused on making good decisions going forward.
3: Informally Test and Evaluate
Structured testing of security is always valuable. However, it tends to be expensive and time-consuming to undertake. But since social engineering doesn’t necessarily require deep technical knowledge to conduct, it’s relatively easy (and cheap) to conduct impromptu “drills” using personnel you already have staffed. It’s quite possible, for example, to conduct testing and training exercises using other staff .
For everything but the very smallest organizations (i.e., organizations where help desk personnel are likely to recognize every person they speak with) IT personnel can informally mimic a social engineering attack scenario. They can do this to attempt to informally ferret out where pain points and area of risk might be — as well as to also improve their resiliency to those types of attack. Leveraging staff outside of IT to help in this effort can be effective as well. For example, engaging staff who are paid to be convincing (like sales or relationship managers) can be an effective strategy in getting this done.
4: Get In Their Face
One of the reasons that traditional “awareness-based” countermeasures are less effective than they could be is due to the fact that users tend to forget over time what you’ve told them. Annual awareness training is both hated by participants and almost completely ineffective days after it happens.
Reminders, however, are cheap and effective. Hanging a colorful, attention-seeking sign or poster (the louder the color scheme and the more garish the picture the better) in a highly visible location (like directly above the coffee pot across the hall from the help desk) is a cheap but effective way to build awareness.
5: Develop a Plan
Lastly, if you’re not thinking about social engineering currently, ask yourself why that is. It’s a topic that’s easy to forget about, but one that’s very difficult to defend against. Develop a roadmap for the future that includes a specific budget for social engineering, both testing for obvious problems in your defensive posture as well as for building countermeasures going forward. Additionally, map out how existing processes could be refined to minimize exposure. This is not an easy topic to address, but it is a serious issue. Address it with the same attention, careful planning, and thoroughness as you would a high-risk technical vulnerability.
And if you think it isn’t IT’s job? Ask yourself who’s worrying about it if not IT. The answer is probably “nobody.”
Loading ...
Love the paper, rarely have I seen a social engineering talk that actually teaches me how to go about the process one this year at the IOActive suite at Blackhat did just that taught us how attackers are calling and what they do when doing social engineering engagements one of the gentlemen speaking, Mike Ridpath, is the leading expert in the world on Social engineering phone calls stepped live through his process when calling clients. I AM hoping to fly him in for training our staff this is AM azing stuff keep up the good work.