Rare is the case when a determined penetration tester or attacker fails to trick his targets into releasing sensitive information. The usefulness of the information and the difficulty of obtaining it depend on the organization's security controls. If you are not incorporating social engineering into your assessment arsenal, you are ignoring a threat vector that may dramatically affect your company's risk exposure.
Plan carefully -- too much is at stake
It is easy to overstep your bounds during a social engineering test: pushing the targeted employee too far during a phone conversation, asking an overly personal question in a phishing campaign, walking into an area that is off-limits during a physical security examination. That is why careful planning is critical to the project's success.
What are you testing?
Clearly defined objectives are a must for a useful social engineering test. "Obtain sensitive information" is usually too vague, and presents opportunities for blame, hurt feelings and lawsuits. Consider tying your goals to the controls the organizations defined in its security program.
For example:
- The security awareness presentation explains how to identify phishing scams. Test what percentage of targeted employees will click on a link in a phishing-like email you send out.
- Help desk training materials outline procedures for resetting a caller's forgotten password. Test whether help desk personnel follow protocol when you call impersonating a colleague who cannot log in.
- The security policy warns employees against strangers walking into the building behind an employee who swiped his badge at the entrance. Test how employees will react when you try to follow them through the door they opened.
Without specific goals, the social engineering test might conjure some war stories, but it will not produce actionable recommendations for improving the organization's security posture.
Research and design a scenario
You can get creative with scenarios that help achieve your goals, whether performing the test via email, phone, postal mail, instant messenger or in person. You will need to research the organization if you do not already understand its business, jargon, corporate hierarchy and social structure.
Next, you will need to think like an attacker, exploiting people's psychological inclinations such as:
- People want something for nothing: "You won the office raffle! Click here to claim your gift."
- People empathize with those in trouble: "Please reset my password. My boss will kill me if I don't submit the time sheet in time!"
- People reciprocate a favor: You picked up the papers the person dropped; he holds the door to let you in.
- Your scenario should specify the individuals or groups designated for social engineering, timing of the test, location, and persuasion tactics. Account for laws, contractual commitments, policies, and the company's culture. Also consider the possibility of something going wrong, and define back-out and escalation procedures.
A word of caution
Consider how targeted individuals will react to being deceived. If you have to work with them afterward, the good will you may lose could cost you. For this reason, companies tend to err on the side of caution, often selecting impersonal email-based scenarios in place of confrontations by phone or in person.
You can easily get in trouble without a written approval for the scenario from your manager or client, and preferably from their manager as well. If you are a consultant, you will be wise to seek a lawyer's perspective before accepting the project.
Conduct the test and analyze the results
Take notes during tests. You might get lost when communicating with multiple people. In particular, pay attention to the indicators that affect the controls you are testing. This may involve monitoring the data collected by a phishing-style form, maintaining a journal of your phone conversations, or photographing the physical space around you. With the right metrics at hand, you can gage the effectiveness of people-centric controls that are difficult to test via traditional assessment approaches.
About the author:
Lenny Zeltser is the New York security consulting leader at SAVVIS, Inc. He is also a senior faculty member at SANS Institute, where he teaches a course on reverse-engineering malware.
