As you might imagine, it starts with policy. We covered policy in Chapter 4, "Developing Security Policies." It's important that your policy include elements related to social engineering. Social engineers target people who have the job of answering questions. They need to know how to behave when faced with questionable requeststhe policy should help them feel as if they have no choice but to resist. Don't put users in situations in which they have to ponder whether they should divulge certain information.
Although you would probably never write a "social engineering policy," the information security polices you have should include elements that address common tactics social engineers use. For example, good password policies specify periodic changes; if someone divulges a password to a social engineer, that password is good only until the next password change interval. Of course, this doesn't mean the system isn't vulnerable, but it does mean that the attacker's time is limited. Similarly, consider the vulnerability present when an administrator is granting an access privilege request. Is the request legitimate ? Is there documentation supporting the requester's need for such access and how that access supports his or her job function? Think about ways in which access requests could be misused.
People are generally unaware that they are part of the security of any computer or network. Properly "configuring" your peoplethat is, making them aware of how important their decisions and actions arebrings about major improvements in your security stance. You've put a lot of effort into succinct information security policies, including explanations of why compliance is important. Now use that to train and motivate your people so that they know how to respond to requests.
Awareness is more than just telling people not to give out their passwords. Passwords are personal, and although few social engineers simply call and ask for them, some can contrive very convincing reasons why someone should reveal a password. Most people won't fall for blatant requests for passwords in the right situation sitting at their desk, in front of their computer, answering the phone. But consider the earlier examples of people revealing their passwords when walking out of a subway or when given a bribe on the street. Here the social engineer contrived a non-computer-like situation, so the majority of people forget the value of their passwords here.
Extend this idea to situations that don't involve passwords but are password-like. For instance, most credit card companies require you to verify your identity if you call the issuer to discuss your account. But what if the credit card issuer calls you? This has happened to us. We received a call from a credit card company, claiming a need to discuss a billing issue. But first the caller requested that we recite the account number and associated social security number "for verification." "Sorry," we replied, "but we don't know who you are. We'll call you back at the number printed on the card." When we called that number, we learned the card issuer had no billing problems with our account. Obviously, then, the call we received was a scam. How many people do you know might have fallen for it? Would you have?
Help your people know what has value and what the value is. Your policy is the foundation of thisgood policies explain the value of information to the organization, its business, its customers, and its employees. Security awareness campaigns can help emphasize this. Create scenarios: what would happen if suddenly all information were lost because of a dead hard drive? Or a successful attack? At least such an exercise helps people understand that the projects they've been working on for the last three years are important and have value to the organization.
It has become fashionable, especially among the younger generation, to spend hours online communicating with total strangers over instant messengers and in chat rooms.  Friendships can form between people who never meet each other IRL ("in real life"). Alas, friends aren't always friends . Friendships made over the phone or in chat rooms could have completely ulterior motives. Just because someone seems friendly doesn't mean he or she should be allowed to possess confidential information or get answers to questions about privileged knowledge. Depending on what a social engineer is after, it could take months or even years of building trust through elaborate convincing measures before that trust will be exploited.
Recognizing an Attack
Everyone in your organization should know what kinds of information social engineers try to acquire and what kinds of conversations are suspicious. If employees know how to identify confidential information, what their responsibility is to protect it, and when they might be under a social engineer's attack, they are better equipped to resist. Social engineering attacks include these signs:
All your people need the authority to say "no" when their suspicions become aroused. Sometimes it might offend, occasionally it might be the wrong response, but usually it thwarts a social engineering attack. Help management in your organization realize this and empower all people to trust their instincts and deny requests that have any appearance of being malicious.
The Help Desk
Help desks are particularly dangerous places. Their function, after all, is to help and social engineers attempt to exploit this to its fullest. Help desk staffers are trained to be friendly, to give out information, and to provide answers, not to question the validity of every call that comes in. They receive minimal (if any) security training, they don't get paid much, and often are goaled on how many calls they complete per hour . Because a help desk staffer's objective is to get the person off the phone and get to the next call, help desks create huge vulnerabilities in your people defenses.
Be very thorough in your policies and procedures around help desk operations. At minimum, you should build in a multifactor verification mechanism, perhaps answers to three questions stored in the user account database. Better would be to use caller ID or to implement required callbacks. When callers request password resets or anything that seems questionable, the staffer should call the person back at the telephone number of that person as listed in the corporate phone book ( not the person's mobile phone). This defeats PBX tricks where an external caller manages to get the call transferred internally. If you implement callbacks, never allow for an exception. Period.
Another technique is to require all such calls to be placed on hold. This accomplishes two things. First, the help desk person can take the time to consider the request and its circumstances, and perhaps even consult with a co-worker. It removes the pressure associated with solving the problem right there with the person on the phone. Second, if the caller is in fact illegitimate, he or she just might hang up and move on to some other victim.
Our favorite technique is the bogus question. A bogus question implies false information and gives the caller a chance to either correct this information or build on it. Although it gives a social engineer a chance to have a bit of fun and make up some answers on-the-fly , it doesn't matter at this point: the criminal's already been outfoxed. Consider the following dialogue:
Now the conversation can go in one of two directions. If it goes this way:
Then the caller has passed the test. However, if the conversation goes this way:
Then the caller has obviously failed the test. The help desk person should immediately notify security and follow whatever the policy states the next step should be. Combine this technique with something else (such as additional questions or callback) and you've got a virtually foolproof verification mechanism.
And be sure that your help desk staff, like all your employees, knows the signs of an attack. Help desk staff, alas, are lowly involved people. Be a catalyst for change in your organization and turn them into highly involved people: get your management to give them the power to say "no" the moment they believe something is wrong.
Ongoing Education and Training
Education begins with an awareness campaign structured around many of the ideas in this section. A campaign helps reinforce your security policies and the procedures that derive from your policies. Just publishing polices and procedures isn't enoughfew people will read and follow them. Instead, consider building a brief "indoctrination" training course for all current staff and for new employees. Update it periodically as new technologies and threats emergethis helps employees remain up-to-date and reinforces the importance of your message. Even regulations now recognize the importance of awareness training; HIPPA, for example, includes four components : security reminders, protection from malicious software, login monitoring, and password management.
To keep your campaign ongoing, there are the usual things such as e-mailed memos, pretty four- color brochures (that, sadly, no one reads anymore; when's the last time you fired up some rusty desktop publishing program?), staff and group meetings, or screen savers. These work to some extent. Better: throw a party. If there's something that you want the entire organization to learn quickly and retain for a while, at Microsoft we've discovered that work-hour parties, which we call "fests," are vastly superior to other forms of information dissemination . Let people take a couple hours away from their desks, satiate their hunger and slake their thirst (yes, all you need is some cheap pizza and beer), and feed them information along with the vittles. It's amazing how effective this is at opening their minds to your message and improving retention.
We've become fans of the work produced by Native Intelligence, Inc. (see them at http://www.nativeintelligence.com). They offer courses on security awareness for end users and managers, classified data basics, and personnel safety. They also sell some pretty amazing posters you can purchase and display around your facility. Using eye-catching designs, these posters remind your people of the dangers of e-mail attachments, to regularly change and not share passwords, to be on the lookout for Dumpster divers, and not to piggyback through access-controlled doors, to name just four examples. Purchase several of their posters and place them in locations where you know you have a captive audience.  Native Intelligence's Web site is a pleasure to spend time perusing.
Don't forget periodic auditing. There will be some expense, in time and money, to launch and update an ongoing security education campaign. You need to check the effectiveness of your educational program by conducting actual tests, perhaps by using some of the techniques described in this chapter. It's really the only way you'll know whether your indoctrination to the dangers of social engineering is taking root in the minds of your people and that inoculation has in fact occurred.
Consider further training for those who are more likely to be the targets of social engineering attacks: help desk and customer service staff, secretaries and receptionists and administrative assistants, and system administrators and engineers. Include everyone whose job is to assist others (especially the public) or whose access usually includes elevated rights and permissions. The field of social psychology has demonstrated that certain resistance-training techniques can help harden people against the techniques of persuasion that social engineers typically use. 
An effective resistance-training program incorporates three techniques. The first is inoculation exposing people to the very arguments that social engineers employ as they attempt to hack their marks. Each argument is accompanied by a potential refutational argument that can combat the attack. Inoculation is a long- lasting technique but does require that you know, or can find out, the kinds of arguments that social engineers typically make.
A second technique is forewarning , in which targets are warned in advance of both the content and persuasive intent commonly used by social engineers in electronic communications such as e-mails and phone mails . Use very plain language here: social engineers (" attackers ") are criminals, their arguments are manipulative and deceptive and insincere, and their only intent is to steal information from people in the organization. The more you can inform your people and the more you can instill confidence in your people that they are part of the organization's need to protect information and systems, the less likely they will fall prey to the tactics of social engineering.
Security awareness training sometimes fails because it lacks a reality check , the third resistance-training technique. People are poor perceivers of risk and often underestimate real but seemingly mundane and ordinary risks while overestimating popular and sensationalized but false nonrisks. People almost always underestimate their own ability to be fooled,  but a demonstration of personal susceptibility can be the most effective way to change minds. Just telling people that social engineers are lurking about isn't enough: it's got to be experienced to really be completely absorbed. How to conduct such a demonstration is up to you; perhaps a training class in which one person reveals how much he or she learned about the participants before the class started, or a script on a Web page that pops up a system-like dialog explaining the network connection is lost and requires re-authentication. The point here is to show participants just how easy it is to be fooled, to have people personalize the training and thus reduce the "invulnerability complex" so many people have.