Over the last several years we have seen a real ramp up in the percentage of our engagements that include some level of social engineering. We view social engineering as a distinct and far less technical form of penetration testing that emulates the activities of a malicious user and the variety of techniques used to gain information that further aids the progress of their attack. Generally speaking there are three primary drivers to Social Engineering:
- We have invested a lot of time/effort/money in Security Awareness training and we want to see if it worked
- We think that we are vulnerable and we want to validate it to justify funding a Security awareness initiative
- We have a third-party who is requiring us to do it (e.g., FDIC Auditor or customer)
So what form of social engineering (e.g. what activities) are best? Not surprisingly the right answers differ with the three scenarios above.
- We want to know if our Security Awareness Training is working – Hopefully your Security Awareness Training initiatives focused on those areas of highest risk to your organization. For example, a co-location facility would likely focus its training on Physical Security and ensuring that all parties seeking access to the facility are properly vetted and treated in accordance with policies, standards and procedures. In this case a physical social engineering exercise intended to validate the effectiveness of physical security controls would be most likely to achieve the objective.
- We want to prove we are vulnerable to justify Security Awareness Training – In this case, aligning the test with a known area of vulnerability is likely the best scenario. We recently did a very simple password reset attack that yielded access to a hospital’s EMR system and data that was subject to HIPAA. Funding was shortly thereafter available.
- We need to do it for a Third Party – Ideally the third-party was specific about the testing they are looking for you to do (unfortunately that is rarely the case – even after asking for clarification). So, you either fall back to one of the two scenarios above to drive as much value as you can from the test OR you do as little testing as possible to keep your cost down and maximize the likelihood of ending up with a clean assessment report.
However, that (the what) is the easy part of scoping a Social Engineering/Security Awareness test, the hard part is the how. This is especially true because the how also significantly alters the cost and the likely outcome as well.
We recently were contracted to do a basic “Vishing” attack (dialing in to garner access to information that should not be available to an unauthenticated caller) for an entity that provides outsourced service to the financial services community. The CISO’s primary reason to do the exercise was a customer requirement but he also had some concerns whether his security awareness training was working. So we discussed a range of alternatives from a very simple and inexpensive attack to a more sophisticated and expensive attack.
- Very simple attack: One of our employees would pose as one of the client’s employees requiring a password reset to a public facing application due to technical problems with their browser. While this would not provide a high degree of assurance it would be inexpensive and likely result in a clean report to hand off to the customer.
- More sophisticated attack: Several of our employees working together would make multiple calls to the help desk at different points in time. Initially many of the calls would not actually be intended to get the passwords reset – but rather to understand who worked at what points in time, understand the authentication protocol, determine the help desk’s ability to detect location/phone numbers/system configuration, and/or build rapport. We would ensure that we had a good understanding of the standard desktop build and the technology stack that was in place including browser/VPN. We would use Facebook, LinkedIn and Jigsaw to research employees including their locations, work travel schedules, bosses, and projects they work on.
So which test do you think he chose? Would you be surprised that we did both? He did the sophisticated attack because he wanted to know whether he was vulnerable to a malicious individual with a high degree of intent. Unfortunately, they were very vulnerable. He did the simple attack afterwards in order to have a clean report to hand off to the customer.
So when you think Social Engineering, remember it’s a broad swath of information security testing. Be sure to think through to the “end game” (what you want/what you need) to determine the ultimate “how”.
MAR
A Best-Practices Guide to Information Security Attestation
Risky Business Blog
Techno Blog
In The News
RSS Feed
About the Author:
John Verry (CISA, 27001 Certified Lead Auditor, CCSE, CRISC) is Pivot Point's resident "Security Sherpa". He is lucky enough to spend most of his day helping clients develop a road map to address security, compliance, and attestation requirements.