Protecting People

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.

How do you handle phone surveys now? A seemingly innocuous survey about your organization's business practices or computing environment might actually be a carefully crafted social engineering attack. A good privacy policy explains how surveys can expose an organization to unnecessary risk and dictate that all such surveys be forwarded to the security department or simply ignored. If your employees are allowed to disclose certain bits of information, make sure the policy contains an escalation procedure in case the requester starts asking for more than what employees are normally allowed to divulge.

Security Awareness

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. [13] 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.

[13] This is merely observation, of course. Neither of your esteemed authors is guilty of such time-wasting, weight-rebalancing, mind-numbing behavior. Yeah, right.

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:

  • Refusal by the caller to give his or her own contact information

  • Rushing through the conversation

  • Dropping names that seem important but out of place

  • Intimidating or harassing behavior

  • Odd questions that typically aren't asked in similar conversations or that request information typically not allowed to be disclosed

  • Misspellings (on printed or e-mailed attacks)

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:

Help desk: "Help desk, thank you for calling, may I have your name please ?"

Vice-president Roisterdoister: "Ralph Roisterdoister."

H. D.: "How may I help you, Mr. Roisterdoister?"

R. R.: "I need my password reset. I'm onsite at our largest customer and I need to get access to the latest project plan and sales projections right now."

H. D.: "Of course, Mr. Roisterdoister. I can help you with that. Oh, how is your daughter ? I understand she was injured recently in an accident ?"

Now the conversation can go in one of two directions. If it goes this way:

R. R.: "I don't have a daughter." or "She wasn't in an accident."

H. D.: "Oh, my apologies, I must be mistaken, I have your password ready, it's ."

Then the caller has passed the test. However, if the conversation goes this way:

R. R.: "Ah yes, well she's much better now. Thank you for asking."

H. D.: "Certainly. Mr. Roisterdoister, would you mind holding for a moment? I'll be right back."

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 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. [14] Native Intelligence's Web site is a pleasure to spend time perusing.

[14] We suggest the interior surface of toilet stall doors. We guarantee occupants will read anything posted there.

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.

Resistance Training

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. [15]

[15] "Dispelling the illusion of invulnerability: The motivators and mechanisms of resistance to persuasion," by Brad J. Sagarin et al., in The Journal of Personality and Social Psychology , volume 83(3), September 2002.

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, [16] 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.

[16] Spend a little time perusing http://www. snopes .com for some real whoppers.

Protect Your Windows Network From Perimeter to Data
Protect Your Windows Network: From Perimeter to Data
ISBN: 0321336437
EAN: 2147483647
Year: 2006
Pages: 219 © 2008-2017.
If you may any questions please contact us: