The Social Engineering Engagement
Richard Ackroyd, Senior Security Engineer, RandomStorm Limited
Security issues within an organization extend far beyond the realms of firewalls and anti-virus, and into the weaknesses surrounding how your people conduct themselves on a day-to-day basis. This chapter will walk you through the process and associated challenges of engaging a third party to perform social engineering work. The challenges are how to manage the delivery of this work according to typically strict timelines while still setting and achieving realistic goals.
Keywords
Compliance and Security Standards; Payment Cards Industry; The Computer Misuse Act; The Police and Justice Act; The Human Rights Act; get out of jail free
Information in this chapter
• The business need for social engineering testing
• Compliance and security standards:
• Payment Cards Industry Data Security Standard (PCI DSS)
• International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) Information Security Document Sets (27000 Series)
• Social engineering operational considerations and challenges
• Dealing with unrealistic time frames
• The Computer Misuse Act 1990 (UK)
• Section 1—Unauthorized access to computer material
• Section 2—Unauthorized access with intent to commit or facilitate commission of further offenses
• Section 3—Unauthorized acts with intent to impair, or with recklessness as to impairing, operation of computer, etc.
• The Police and Justice Act 2006 (UK)
• Making, supplying or obtaining articles for use in computer misuse offenses
• Regulation of Investigatory Powers Act 2000 (UK)
• The Human Rights Act 1998 (UK)
• Computer Fraud and Abuse Act—United States
• Social engineering frameworks
Introduction
Up until this point the chapters of this book have covered the various techniques social engineers use to obtain information and manipulate their target. The intention of this book is not to scare the reader into never answering a phone again, but if you aren’t at least a little concerned about your own posture, that of your business or even friends and family, then they probably should be. This leads smoothly into the present chapter, where the topic of how you would go about identifying these very same flaws in your own people and processes will be covered.
Luckily, addressing these risks need not be a particularly stressful exercise. The reader could invest in social engineering professional services to assess their business and report the findings. Many clients find this an eye opening experience, and in most cases a genuinely intriguing and exciting exercise.
The aim of this chapter is to cover social engineering services from the point of view of the client and the social engineer(s).
As a client, they may be struggling to identify the need for social engineering professional services. The drivers for this type of work include compliance programs such as the PCI DSS (Payment Cards Industry Data Security Standard) or ISO/IEC (International Organization for Standardization/International Electrotechnical Commission) 27001, or it can be driven purely from the point of view of strengthening general security and protecting sensitive data.
Once the need for social engineering has been identified, consideration needs to be made regarding how the work should be commissioned, and how to identify who can be trusted to get the job done in a professional manner. This chapter will provide the reader with some general guidelines and recommendations that can be applied when choosing appropriate people for work of such a sensitive nature.
An organization has chosen to engage in social engineering testing and have chosen their vendor and are now ready to kick the project off; what’s next?
The first step must be the planning stage, commencing with the need to build a framework for social engineering engagements. This ensures that both the client and the social engineer remain on the same page throughout the project. A key part of THIS is the identification of common prerequisites for any engagement that will protect both parties, such as get out of jail free cards and approved contacts.
While scoping documents may not seem like the most exciting of topics, they target some truly vital points when it comes to social engineering. The document will not only cover the objectives of the assessment, but what is acceptable during the course of the test. Does an organization want to allow lock picking or not? Is it ok for the social engineer to attempt to recover sensitive data from the site, or even take company property such as laptops? Is the engineer going to be allowed to clone door entry cards?
Everything from the very basics of where the testing will occur through to who to call when things go wrong should be clearly defined within the scoping documents.
Leave no stone unturned, now is the time to ask the questions, not half way through an engagement when there is a social engineer dangling precariously on a rope at the window of the boss’s office!
The business need for social engineering
The business need for social engineering can be rooted in a multitude of different drivers. One thing is for certain; most businesses will completely overlook social engineering when it comes to allocating their security budget. Instead they will choose to focus their efforts around traditional security services and products, such as firewalls, IPS, and anti-virus. While each of these technologies clearly has a place in any modern environment, they can all be taken completely out of the equation by a motivated and devious social engineer. Why go over the mountain if it can be circumvented?
Unfortunately this means that the vast majority of businesses and individuals are ill-prepared to deal with malicious social engineers, which ultimately will mean data loss, embarrassment, or in the case of compliance, massive fines and increased workload for all involved.
Anybody who has been in the security space for any length of time will know that it has often been difficult to get approval for large security spends, especially in comparison to infrastructure and software budgets. Security was always seen as the insurance policy that never made any return, and for that reason was left in a state of neglect.
Thankfully, the situation has changed quite dramatically over the last 5–10 years. High profile compromises and compliance regulations have driven massively increased spend in this sector. Unfortunately this doesn’t often apply to social engineering.
In general, the experience has been that social engineering is seen as a real luxury; the sort of service that would be at the very bottom of a very long list of things that need to be addressed. The sad reality is that the amount of damage that can be done by a committed social engineer can often vastly outweigh anything that a virus or hack could, and will likely go completely unnoticed. Organizations may never know that it happened at all.
How does a business justify social engineering services to the budget holders? How can the importance of the exercise be impressed on the decision makers? Let’s take a look at some of the more common business drivers that can be seen on a day-to-day basis, maybe they will fit your business needs too!
Compliance and security standards
Ultimately, all compliance standards are designed to provide a benchmark against which to measure an organization’s information security state. The greater an organization adheres to these “best practices”; the greater their risk mitigation against various legislative infringements, even where there is no direct mention of it within those standards.
A recent example highlights the consequences of legislative breaches of this type. In April 2011, Sony Computer Entertainment Europe suffered a breach of its playstation network. Usernames, passwords, and personal data were taken during the attack. Encrypted credit card data was also taken, although no mention has been made of the strength of the encryption since.
Sony was subsequently fined £250,000 by the Information Commissioner’s Office (ICO) in January 2013. Sony had intended to appeal this decision but have more recently accepted the fine.
£250,000 may be pocket change to Sony, but it certainly isn’t to the vast majority of organizations. The financial penalties cannot possibly match the embarrassment and damage to reputation suffered due to this fiasco.
Sony is not the only organization to fall foul of the legal ramifications of poor information security, so don’t be lulled into the idea that it can’t happen to your organization.
The European Union’s proposed General Data Protection Regulation (GDPR) makes it plain that things are not going to get easier anytime soon. The idea of the GDPR is to bring coherence to Data Protection Law in Europe by providing a single authority that will deal with the legally binding decisions made against corporations, as opposed to the multitude that we have currently. Along with it comes the potential for vast financial penalties based directly upon the organization’s annual sales. For Sony, this figure is going to be orders of magnitude more than £250,000.
The GDPR still may not make it through ratification, but it is obvious that clearer laws with stricter penalties for information breaches are on the horizon.
How does social engineering help to improve the information security state and avoid litigation? Any worthwhile information assurance industry standard will make provision for the concerns that social engineering can help directly with. Common concerns and issues identified by these standards are as follows:
• The human element of security
• Proactive testing of physical security
• Proactive testing of incident response
• Proactive testing of processes—call handling or visitor access.
How do these standards address some of these elements?
Payment Cards Industry Data Security Standard
The PCI Security Standards Council offers robust and comprehensive standards and supporting materials to enhance payment card data security. These materials include a framework of specifications, tools, measurements and support resources to help organizations ensure the safe handling of cardholder information at every step. The keystone is the PCI Data Security Standard (PCI DSS), which provides an actionable framework for developing a robust payment card data security process—including prevention, detection and appropriate reaction to security incidents.
At the time of writing we are at version 3 of the PCI DSS, which as noted above, is a standard dedicated to the protection of cardholder data. If a business stores, transmits, or processes credit card information then they are subject to the PCI DSS remit.
How does social engineering testing help to ensure that businesses are adequately protecting payment card data and ensuring that they are meeting the spirit of the PCI DSS (version 1) requirements?
Requirement 9 of PCI DSS covers the restriction of physical access to cardholder data. While the testing procedures can be carried out by a PCI DSS Qualified Security Assessor (QSA), it could be argued that engaging with a social engineering consultant as a side project could provide more relevant and accurate results. As an example, it is almost always going to be the case that any visit to a particular business by a QSA will be known about by all of the technical staff. What the assessment is unlikely to address is what is happening during day-to-day operations. Granted, they may well pass the PCI assessment on that specific date but that does not mean that the organization will be protected from payment card security breaches for the remainder of the year. The QSA assessment is much like a Ministry of Transport test.1
Even small merchants can be fined tens of thousands of dollars if they are found to be noncompliant postbreach. While compliance sets a bar for security, it is not wise to merely scrape over it and hope for the best. Consistent and proactive testing of the policies and procedures is the only way to ensure that all is being done to reduce the risk of a breach. Engaging a team of social engineers to attempt physical access on a regular basis will not only help to ensure that the security is working as advertised but can also be very useful when it comes to staff awareness and education.
Requirement 12 of PCI DSS addresses security policies and procedures, including staff training and security awareness programs. The most relevant subsection for social engineers is 12.6. Requirement 12.6 covers the development and delivery of effective staff awareness training and is covered extensively in Chapter 15.
The real benefit of including social engineering, as a part of a staff awareness training, is IMPACT! Let’s be honest, the second PowerPoint is fired up, probably 30% of the audience is lost. Unfortunately as PCI DSS tries to address the three arms of information security – technology, people, and process – having an ineffective security awareness program may meet the mandated annual awareness training, but it does not provide the most effective method of addressing the people factor. Therefore the best way to ensure that the training is “fit for purpose” is to make it relevant to the audience. If a person was to be asked if they could be duped out of sensitive information over the phone, they would not believe it possible. To them the principal is silly, does not affect them, and is therefore not relevant.
Of course, social engineers know differently. Imagine the impact of announcing to staff that an unauthorized individual gained physical access to the premises as a result of a few well-placed phone calls or that the same individual tailgated a member of staff into a secure area. Immediately the penny will start to drop. Yes these sorts of things can happen, and probably are happening all the time, but at this point there is likely to be an increase in the amount of people paying close attention to the slides, asking questions, and probably an increase in the worried looks on faces around the room. Each person is now wondering if they were responsible for allowing a tailgater into the building, or if they arranged for access over the phone.
Effective awareness training must break through the “it will never happen” mentality as quickly as possible if you want to really engage your staff and make the session more valuable. Fear and paranoia need not always be negative, they can also be catalysts for positive change when it comes to security.
Section 12.9 of PCI DSS covers the testing of incident response plans. What better way to test them than to create an incident? Better yet, the incident will be controlled, executed according to specific parameters, and can be stopped at anytime. The same cannot be said of a real incident!
It is a common practice, as in many social engineering engagements, to only have a handful of people in-the-know when it comes to these incident simulations. There is little value in telling incident responders that something is going to happen.
ISO/IEC 27000 information security series
The breadth of the ISO 27000 series of standards is vast in scope. With the increasing pressure to improve their information security practices, businesses often choose to adopt the implementation of these standards. Therefore it is almost certain that personnel will come into contact with them at some point, and increasingly so as the standards develop. In fact, after more than eight years, the latest version (ISO/IEC 27001:2013) has been released bringing it in line with modern practices and to better prepare us for the sophistication of modern attacks.
Again, the key points within ISO/IEC 27001:2005 relate to education of staff through awareness programs and the control of physical security perimeters.
The vast majority of relevant sections of ISO/IEC 27001:2005 sit within Domain 8—Human Resource Security and Domain 9—Physical and Environmental Security.
Human Resource Security, Domain 8
This section identifies the need for information security awareness, education, and training. The awareness of security threats and concerns cannot possibly be discussed without reference to social engineering. As discussed in other chapters, social engineering is one of the biggest threats to information security. A quick browse through various mainstream news sites quickly highlights the nature of the threats in the current landscape. When massive security organizations like RSA are being successfully targeted by social engineering attacks it is definitely time to switch our thinking.
Social engineering professional services can feed directly into policy and education, and as mentioned before really does lend impact to proceedings that would otherwise be lacking. With any luck, they will help us to avoid becoming the next RSA.
Physical and Environmental Security, Domain 9
This section covers the process of preventing unauthorized access to an organization’s premises. It covers some of the following issues:
• Ensuring that security perimeters are physically sound.
• Ensuring that all external doors are secured against unauthorized access.
• Ensuring that doors and windows are locked when unattended.
• Physical barriers are in place to prevent unauthorized access.
• Intruder detection systems should be installed and monitored.
• Fire doors should be alarmed, monitored, and tested.
• Ensuring that employees and visitors are wearing visible identification.
• Any unescorted visitors should be immediately reported to security.
• Ensuring that third parties are granted restricted access to secure areas only when required.
This is social engineering territory down to the core! These are the type of controls that are regularly tested and in many cases circumvented.
Organizations that are truly serious about physical security will regularly and proactively test these controls by involving social engineers. It is highly likely that these exercises will identify weak areas that weren’t even known to exist.
A great idea for this sort of testing, and one that is often undertaken, is basically a low fat social engineering assessment. The customer contact will meet the team at reception, signing them into the building. They will be given typical visitor passes and restricted door access cards as well as a meeting room to work from. Several objectives will be given and they are left to escalate their level of physical privileges. The objective may be to gain access to the server room or to filing cabinets in a restricted area. No other employees will be told that the organization is being tested during that day.
This is a great all-round security test just as it is, but compare it against the compliance standards, the sheer volume of controls being tested makes it great value as an awareness exercise.
This test could literally be performed over a few days, and in terms of ISO/IEC 27001:2005 would test a sizeable portion of Domain 9. From the second someone leaves the safe haven of that meeting room, they are already testing several sections of Domain 9.1.2—for example, are they challenged as an unescorted visitor? Were they able to gain access to areas where sensitive information is stored or processed? If they remove their visitor badges, are they challenged by staff? How long does it take? It is also a great test of the security education of employees, and the level of empowerment they have been granted to challenge visitors.
This sort of exercise is augmented by a washup meeting with the client, or better yet, by conducting this testing in the run up to a staff awareness session, so that the social engineers can be present to give advice and go through their findings. The idea is not to guilt or shame employees, but to show them how real the threat is and how easily breaches can occur.
At the end of the exercise, a written report stating that their controls were strong, along with supporting evidence can only lend weight to the accreditation process, not to mention increasing peace of mind.
Having only looked at two standards, it is plain to see that social engineering has a place in improving any organization’s security state. The tie in with compliance standards as a result of this is plain. Having realized the need for social engineering services, let’s take a look at how the engagement works, what the challenges look like and what is delivered at the end of the project.
Social engineering operational considerations and challenges
Social engineering gigs come with their own unique set of challenges; this is very much guaranteed. It is a common occurrence that social engineers turn up to a site, only to realize that every single employee had been told they were coming on that day. Talk about the quickest test ever! Similarly, there have been occasions where social engineers have been detained by security and interrogated at length, despite acknowledging the “get out of jail free” letter!
Issues like this can usually be avoided by ensuring that the social engineering team regularly consults with the client in the buildup to a test.
Let’s take a run through some of the challenges, both from the point of view of the social engineers and that of a client looking to engage with them.
Challenges for the social engineers
Less mission impossible, more mission improbable
One of the bigger challenges in engaging with a client is getting to the root of their security concerns and developing a realistic scope. If the client is expecting to see the social engineer stuck to the 16th floor window using nothing but a pair of plungers, then they are probably going to need some help shaping their expectations. Ideally, the client should undergo a consultation process to allow them to talk about their worst fears and scariest what-ifs. From here, a realistic threat model can be built, and from that, a realistic scope. The earlier the involvement in this process, the sooner any kinks can be ironed out that may hinder the assessment down the line. Plenty more on this topic in Chapter 6 which is entirely dedicated to threat modeling.
Dealing with unrealistic time scales
Sometimes, no matter how much a client is guided toward a realistic goal, they just don’t have the budget to perform a thorough assessment. The challenge now becomes to identify as many potential issues as possible in the short time frame allowed. It is genuinely difficult to not compromise the ability to deliver a valuable service in these instances, and sometimes it is just better to walk away and maintain integrity. A frequent occurrence is when new projects are raised with half a day assigned to test the physical security of a site. These projects are typically tick-box exercises for the client who wants to know that someone cannot just walk in off the street. Unfortunately there is very little value in them for all involved, so do try to avoid being drawn down this path. The client’s time would be far better spent by having a member of the team on-site to give half a day’s training. In that time, they could cover off some of the more common attack types, give some real world examples, and finish off with some defense strategies.
How about sitting around a laptop with the client and showing them how much information can be gathered about them in a couple of hours using common tools? Stripping metadata from documents almost always raises a few eyebrows around the room, purely because it is typically overlooked by most organizations.
This sort of approach is very likely to have a positive impact. Not only will they win their respect and trust for guiding them down a more appropriate path for the timescale, but they will be more likely to end up calling the team back to assess them properly in repeat business.
Dealing with unrealistic time frames
Frequently, social engineering teams are involved in quite a lot of tests that have quite a short turnaround time for completion. Often this is taken out of their hands for any number of reasons. Unfortunately this can result in them having to test several geographically separate sites back to back within a few days. There have been several instances where they have found that security at one site has tipped off security at the other sites, including descriptions of the social engineers that so callously violated them on the previous day. It is recommended to always try and persuade the customer to avoid back to back tests and instead spread them out over longer time frames. Where this is not possible, try to ensure that different testers and pretexts are used for each site. Don’t forget that just because the team didn’t get made on day 1, it doesn’t mean that they didn’t raise suspicions. The security team may have reviewed CCTV footage and decided they were up to no good. As a result, the security across the entire business is at DEFCON 1 and anything that is tried just isn’t going to stick.
The best compromise in these situations, with a large enough team, is to deploy all operators simultaneously. Some level of centralized coordination is going to have to take place for this to come off, but there is significantly less chance of the entire team being burnt as a result of consecutive tests. The chances of security being this coordinated across all sites are fairly slim. By the time one site has figured out what is going on, the other assessments will either be well under a way or complete.
Taking one for the team
This challenge sits squarely in the social engineers court. The fact of the matter is social engineering, one of the most exciting jobs that anyone could wish to have.
The reason for this level of excitement is quite simply that there are risks involved that also make social engineering pretty tough on the guys and girls who do it for a living.
First of all, especially in the beginning, and assuming the social engineer isn’t a crook, they will be fighting a lifetime of social conditioning. Their parents no doubt brought them up to listen to people in authority, not to trespass or steal, and not to get into trouble with the police above all else. No doubt they never specifically mentioned picking locks, impersonating people, or conning people over the phone but this provides an idea. It is these reservations and anxieties that make social engineering challenging.
During social engineering engagements, there will be incidents where members of the team are collared by security guards and police, interrogated, surrounded and in some cases tackled to the ground during the course of the task. There’ll be the need to climb, scramble, and jump in order to achieve your objective. There’ll be times when there’s a requirement to dig around in the trash on many occasions too. It is for this reason that team members have to be willing to take one or sometimes two for the team. These are the occupational hazards of this industry!
Name and shame
One of the most common topics that we discuss with the clients is the policy of not naming and shaming individuals, even though this is very frequently requested. When a client has the circumstances explained to them, they will often find that they too would have probably fallen foul of the same tricks. If an employee has not been educated in how to identify and defend against social engineering attacks, how can they be expected to prevent them? There are some instances in which it is unavoidable to indirectly identify someone. The client will have a full timeline of events, so it is not a leap to find the security guard that was on the rota that day. Always try to steer the conversation down the road of education and training, not punishment. The security guard that just got duped is far less likely to let it happen again anytime soon!
Project management
Social engineering projects present something unique from a project management point of view that most people would probably overlook. This is simply that the client shouldn’t always be told what days the team will be on-site. This will be a foreign concept to project managers whose day-to-day job is to ensure smooth delivery of services to a client and to maintain seamless communication. Instead of specifying a day (or days) for your visit, choose to give the client a window during which the breach will be attempted and that window could be weeks or even months in length. Not taking the time to explain the subtleties of social engineering engagements to the members of the team often leads to the inevitability that the cover will be blown. Always ensure that the education about social engineering takes place within the social engineer’s business as well as your clients.
Challenges for the client
A common belief is that all the hard work lies with the social engineer, but there are important issues that need to be addressed before and during the engagement, as there is with any other type of project. One of the biggest challenges for a client is finding people that can be trusted to do the job properly. This includes acting with integrity at all times.
Getting the right people
This could probably be categorized as being the most difficult task in the entire assessment. It is difficult enough to find good people to come and fix a boiler, so how on earth does someone start looking for people in such a niche field?
Recommendations are a good starting point. What other organizations in the industry have engaged with social engineers? A reference via word of mouth is always a good start. It would be wise to try and get some detail from the individual such as the type of assessment and how the testers conducted themselves throughout the process. The only problem with word of mouth and recommendations is that the results of a social engineering assessment are likely to be a closely guarded secret for most organizations. As a result of this, it is unlikely that the level of detail could be achieved that would provide peace of mind.
Accreditations and certifications can also lend credibility to an organization, but these are not likely to be directly related to social engineering. It is likely that they will be information security related certifications and are likely to be related to penetration testing and other technology types. A few good certifications to look out for are things such as CESG’s CHECK qualifications; team member, team leader (Infrastructure), and team leader (Web App). ISO certifications or affiliations with other information security bodies can also be a good indicator. Unfortunately as none of these are directly related to social engineering, they can help provide peace of mind that you are dealing with people who have a proven track record of dealing with highly sensitive information and scenarios.
It can also be worthwhile to speak with existing providers of security services. It is very common for penetration testing outfits to also offer social engineering, purely because there is a lot of technology and skill overlap. It is worthwhile to set up a call or meeting with one of the team members to get them to walk through some example assessments. This should provide a flavor of their level of experience, fairly easily.
Lastly, take a look around at people who have published work in the field. Maybe they have delivered talks at Industry events or released tools to support social engineering or information gathering work.
If there’s still some uncertainty at this point, it might be a good idea to engage with the chosen provider in a short assessment. A reconnaissance exercise or capture the flag can often prove insightful. When presented with social engineering, some clients have stated that they didn’t feel that social engineering was a risk to them, because their staff would never give out sensitive information. This would usually result in them being asked to carry out a small challenge, and if it was met it then maybe they would consider further work down the line. As the client, they have the prerogative to flip this and challenge the vendor to see what they are made of. Ask them to find out some key pieces of information that shouldn’t be public knowledge and see how far they get. The results might be very surprising.
Legislative considerations
Staying on the right side of the law is especially tricky when it comes to social engineering and sometimes even penetration testing on the whole. It is exceptionally important to have a grasp of the laws that apply to the profession, in order to ensure that any issues are avoided.
Penetration testing actually fits into social engineering, almost as a subskill, which is why it is often found that penetration testing providers often provide social engineering services too. It is not uncommon to have an objective that calls for physical access to a premises followed by plugging into the network and attempting to exfiltrate data. It may be that there is a task to gain access to a server room and perform this task using a KVM (keyboard, video, mouse). In either case there is a need to be aware of several laws, each of which will briefly touch upon next.
The Computer Misuse Act 1990 (UK)—http://www.legislation.gov.uk/ukpga/1990/18
The Computer Misuse Act (CMA) is split into three main sections.
Section 1—Unauthorized access to computer material
This section covers the act of gaining access to a system without prior authorization. The maximum penalty under conviction is a two-year imprisonment and a fine. Two years in jail! Now it is starting to become apparent why getting the scope signed off by the right people is so important. During a penetration test, staying within scope is a relatively straightforward affair. During social engineering engagements, the engineer won’t necessarily have been shown to the network point by their contact. As a result, the infrastructure that is being plugged into could belong to the people that manage the building that the client is in, and worse yet this may be on entirely the wrong floor and be plugging into another business network! This is where the time spent doing the reconnaissance is paramount to ensure that the engineer stays on the straight and narrow. Try and make sure that the client’s floor is identified and look for business identifiers before doing anything that may mean that any law infringements take place.
Section 2—Unauthorized access with intent to commit or facilitate commission of further offenses
Having gained access to the server, retrieved some credit card data, and then used those credit card details to buy goods, the attacker is likely to be subject to this law. It is clear that the seriousness of this type of crime is reflected in its sentencing. It is fair to say that this law should never apply to a legitimate assessment, but what about the misidentified host scenario from Section 1? What if an engineer mistakenly plugs into somebody else’s network point and hacks their way onto a server? What if they then use information from that server, such as hashed credentials, to access other systems on the network further down the line? This could be classed as a breach of this section which, as already mentioned, comes with very stiff penalties.
Section 3—Unauthorized acts with intent to impair or with recklessness as to impairing, operation of computer, etc.
Denial of Service is probably the biggest area covered in this section, however it also covers the manipulation or destruction of data. This could include changing values in databases, such as prices or defacing a corporate web presence. The maximum sentencing for this section is 10 years.
The Police and Justice Act 2006 (UK)—http://www.legislation.gov.uk/ukpga/2006/48/contents
The Police and Justice Act makes several important amendments to the CMA that are relevant to security testers. First of all, increased penalties were included which have already been noted in the CMA section.
It also makes the following illegal.
Making, supplying, or obtaining articles for use in computer misuse offenses
This is a real grey area for security testers at the moment. It basically outlaws the use, distribution, or possession of pretty much every tool, script, or application that we use. It is also worth noting that extreme care should be taken with regards to responsible disclosure of vulnerabilities. Exploit code should not be released into the wild without having first followed the proper procedure of disclosing to and working with the vendor of the affected systems.
We have yet to see the prosecution of a legitimate penetration tester under the CMA section.
The openrightsgroup.org has further comments on this particular aspect.
The current Home Office line appears to be a balance of probabilities argument, that a court decide whether it is more likely than not each individual instance of the article will be used to commit an offence, i.e. the offence is only committed if it will be used criminally more than legally.
http://www.openrightsgroup.org/blog/2006/computer-misuse-act-potential-disaster-avoided
An interpretation of what this is saying is that common sense is going to be applied to any case that arises. In other words, as a legitimate penetration tester you should not run into any issues. It would be wise to seek professional legal advice in any case.
Regulation of Investigatory Powers Act 2000 (UK)—http://www.legislation.gov.uk/ukpga/2000/23/introduction
An Act to make provision for and about the interception of communications, the acquisition and disclosure of data relating to communications, the carrying out of surveillance, the use of covert human intelligence sources and the acquisition of the means by which electronic data protected by encryption or passwords may be decrypted or accessed; to provide for Commissioners and a tribunal with functions and jurisdiction in relation to those matters, to entries on and interferences with property or with wireless telegraphy and to the carrying out of their functions by the Security Service, the Secret Intelligence Service and the Government Communications Headquarters; and for connected purposes.
While Regulation of Investigatory Powers Act (RIPA) has often been covered in other materials relating to penetration testing and social engineering, it is worth noting that its scope is limited to public authorities, www.gov.uk offers some insight.
RIPA is the law governing the use of covert techniques by public authorities. It requires that when public authorities, such as the police or government departments, need to use covert techniques to obtain private information about someone, they do it in a way that is necessary, proportionate, and compatible with human rights.
RIPA’s guidelines and codes apply to actions such as
• intercepting communications, such as the content of telephone calls, emails or letters;
• Acquiring communications data: the “who, when, and where” of communications, such as a telephone billing or subscriber details;
• conducting covert surveillance, either in private premises or vehicles (intrusive surveillance) or in public places (directed surveillance);
• the use of covert human intelligence sources, such as informants or undercover officers;
• access to electronic data protected by encryption or passwords.
RIPA applies to a wide range of investigations in which private information might be obtained. Cases in which it applies include:
Given that this is the case, the only realistic reasons that anyone needs to be concerned about RIPA are as follows:
• You are providing consultancy for one of the aforementioned public authorities.
• You are being asked to give up your encryption key, which in turn compromises client data.
Further information is available at https://www.gov.uk/surveillance-and-counter-terrorism.
The Human Rights Act 1998 (UK)—http://www.legislation.gov.uk/ukpga/1998/42/contents
The Human Rights Act came into force in the UK in 2000. Its scope regarding penetration testing and social engineering is mostly related to privacy of an individual data. Article 8 is our only real area of focus.
Right to respect for private and family life
1. Everyone has the right to respect for his private and family life, his home, and his correspondence.
2. There shall be no interference by a public authority with the exercise of this right except such as is in accordance with the law and is necessary in a democratic society in the interests of national security, public safety, or the economic well-being of the country, for the prevention of disorder or crime, for the protection of health or morals, or for the protection of the rights and freedoms of others.
I have seen Article 8 mentioned in relation to penetration testing and social engineering on several occasions, but I have to say, determining its relevance is quite difficult. For example, in private organizations the employer actually has the right to monitor what its staff are doing via various means, as long as it is stated in the employee contract or employee handbook. This can include CCTV, reading an employee’s email, or even bag searches. The employees have to be informed that this is happening in almost all cases and the employer has to have suitable cause to monitor. As far as the penetration testing section of a social engineering engagement goes, there are limited areas of risk. These areas almost always apply to the accidental interception of personal communications. This could happen if you were performing a Man-In-The-Middle (MITM) attack via ARP poisoning as an example. In my opinion, this is a massive stretch, and the reason I say this is that I would absolutely never ARP poison or MITM on a physical engagement where I had to gain access to a facility and then plug-in and “hack.” The best approach is to always try to avoid ARP poisoning on physical penetration tests. It can be massively disruptive. A social engineering engagement may need to move in a real hurry, disconnecting from whatever network point that is plugged into without gracefully ending whatever is being worked on. In the case of ARP poisoning or other MITM attacks, this is going to mean an outage for the client for however long the switches are configured to time out the ARP entries.
An alternative to ARP poisoning would be to perform the Karma wireless attack. The Karma attack is where an attacker/penetration tester listens for a client, which is probing for known wireless networks. The attacker responds to the client claiming to be that access point, at which point the client connects. The typical scenario here is to sit in the middle of this session, capturing passwords and other data, and forwarding any traffic out onto the Internet. This gives a seamless experience to the client who never even suspects that the attack has happened.
This kind of attack is especially effective where an open wireless network is deployed by the organization for guest access. There is likely to be nothing stopping corporate laptops and devices from connecting to open networks, meaning it could provide some especially useful information during a social engineering engagement. Coming back onto the topic of the Human Rights Act, the engineer will likely be capturing other users data throughout this entire attack, some of whom may not even be employed by the client.
To sum up, there is only a slim chance of getting caught up in the Human Rights Act, and this is generally through indiscriminate MITM attack captures or when drifting outside of scope.
Computer Fraud and Abuse Act—United States
The Computer Fraud and Abuse Act (CFAA) is essentially an equivalent to the CMA as previously described. There are some key differences, most notably that it applies to “protected computers” only.
Looking into US law via law.cornell.edu defines the meaning of “protected computer.”
the term ‘protected computer’ means a computer—
(A) exclusively for the use of a financial institution or the United States Government, or, in the case of a computer not exclusively for such use, used by or for a financial institution or the United States Government and the conduct constituting the offence affects that use by or for the financial institution or the Government or
(B) which is used in or affecting interstate or foreign commerce or communication, including a computer located outside the United States that is used in a manner that affects interstate or foreign commerce or communication of the United States.
The crimes covered under the CFAA are extensively documented at law.cornell.edu, but we will touch upon them briefly here for reference.
• Accessing a computer without authorization or exceeding authorized access.
• Accessing a computer without authorization and gaining access to financial records, any information from departments of the US Government or information from any protected computer.
• Accessing a protected computer and conducting further fraud.
• Transmitting malicious code or commands, which cause damage to a protected computer.
The maximum sentence for crimes committed that are covered by the CFAA is 20 years imprisonment. While we are at risk of repeating this, accurately defining a proper scope and understanding the work to be undertaken should ensure that the correct path is followed. Application of a level of common sense is always going to help too. Ensure that there is a signed off scope from a person in authority before accessing a computer so that the “without authorization” becomes a non-issue. The rest of the CFAA should not apply to a tester as it covers truly malicious acts, destructive, and otherwise.
To summarize the Legislative Concerns section, get a signed off scope! This chapter has covered most of the laws that could apply to this profession each of which rely heavily on the unauthorized access aspect. Ensure that the task is signed off by a person who has the authority to do so, and then the scope is stuck to religiously. It is a good idea to raise any potential risks upfront so that the client is aware of any potential for legal ramifications.
Social engineering frameworks
Social engineering like penetration testing follows a lifecycle throughout any engagement. Unlike penetration testing, there aren’t a lot of published frameworks out there, likely down to the fact that social engineering is a niche business that hasn’t yet taken off to the extent that penetration testing has.
Luckily, the general concepts across these two fields marry up quite nicely in most respects, which can really help you in defining your own process to follow during an engagement.
Further information can be found in the Penetration Testing Execution Standard or PTES—http://www.pentest-standard.org/index.php/Main_Page.
PTES is designed to provide guidelines that can be implemented during the entire lifecycle of a test. It does cover social engineering techniques to a certain extent, but is primary for penetration testers.
Here is an insight into the main sections and how they can be tweaked to build specific frameworks for testing;
It is clear to see that with a few amendments here and there, the above framework could be modified to fit more or less any kind of work, not just social engineering. In fact, many parts of this chapter could directly map across to one of these headings. The order in which these sections are applied may change, some may merge into others, but the concepts are directly applicable.
Of course, PTES goes into far more detail regarding each point, so here is how each steps map across to social engineering.
Pre-engagement interactions
This section covers all of the issues and challenges that are faced before the assessment begins.
We have already covered a lot of these topics in this chapter, but it is interesting just how applicable this is. Getting the scope right can also be merged to contain the goals of the assessment in many cases. Establishing the lines of communication is going to help ensure adequate protection during assessments and that the information is delivered to the right people, after all, it will often be very sensitive.
The Rules of Engagement section is also key in this line of work and could be included as a part of the scoping exercise.
Intelligence gathering
This section actually makes mention of social engineering, although it is more from the point of view of gathering intelligence to support a penetration test.
While some of the technologies and techniques may change, intelligence gathering during a social engineering engagement is probably the most significant phase, and it will build a foundation for the remainder of the test.
At this phase of a test, example exercises include gathering corporate email addresses from search engines and social networks, parsing document metadata from publicly available corporate documentation, and establishing contact details such as phone numbers for switch boards and receptions.
These topics are discussed in more detail in Chapter 8.
Threat modeling
This section covers the identification of key assets within an organization, and the impact that would result from a compromise of said assets. An asset, for the purpose of social engineering, could be a person, a system, or a piece of key data, such as credit card numbers or passwords.
Threat modeling during social engineering is more likely to be an interactive process with the client, undertaken during the scoping exercise, as already covered in the Engagement section. For the purposes of this section, Vulnerability Analysis will be collapsed under the same heading. Chapter 6 will cover effective threat modeling.
Exploitation
The exploitation phase could just as easily be called the execution phase where social engineering is concerned. It is here that all of that gathered reconnaissance information and the previously built pretexts are executed in order to meet the objectives.
The execution or exploitation of the predefined plan could come in several forms. This could involve being expected to retrieve sensitive data from a dumpster, gain physical access to a building, or determine the alarm code purely by making targeted phone calls. Everything leads up to this phase and it feeds everything following on from it. These topics will be covered throughout the book in greater detail.
Post exploitation
Post exploitation/execution covers everything that should be performed, following on from a successful exploitation. For example, a successful exploitation may have been to gain physical access to the building by tailgating. The post execution task may be to gather up sensitive information and exfiltrate without being caught or noticed. It could be that the task is to connect to the network and enumerate as much information as possible from corporate hosts. The execution and post execution phases would often be collapsed into one and other during most engagements, but it isn’t uncommon to have primary and secondary objectives.
Primary objective (exploitation)
Secondary objectives (post exploitation)
• Remove corporate property such as a laptop or iPad.
• Gain access to a restricted area of the building.
The main area of concern is considered a primary objective, which in this instance is gaining access to the building. The secondary objectives are considered a bonus, but often help to identify operational shortcomings. For example, the engineer shouldn’t be able to plug a dropbox into the network if ports are properly secured.
Reporting
Reporting would cover both the written report as well as a verbal debrief with the client. These are covered briefly in this chapter but are covered in detail during Chapter 13.
The purpose of this section wasn’t to go into detail on each individual topic, as they are covered throughout the book already. The purpose was to build a framework for social engineering assessments, which could be applied to each engagement. Without digging into the detail of PTES, its concepts can be applied to build our framework, which will hopefully improve the operational efficiency and effectiveness of the social engineering projects.
For further information on frameworks, take a look at the table of contents of this book. A great deal of what has been covered can be transferred across, quite easily. The table of contents is actually a framework for social engineering in its own right.
Assessment prerequisites
Regardless of the type of work being carried out, ensuring that a consistent set of prerequisites are met is critical to the success of a project. Social engineering, however, has one or two unique requirements that we will cover in this section. In a standard IT project, for example, installing a firewall, improper handling of prerequisites can cause severe inconvenience to the engineer carrying out the work. Improper handling during a social engineering project can lead to issues with security or even the police. Take a look at some of the more common prerequisites that will help avoid jail in the process.
Scoping documents
It is critical to any social engineering engagement that a scoping document has been signed off by the client, and equally important that it is validated by a social engineer long before the project kicks off.
While the scoping document will obviously need to be customized to fit the needs, here are some examples of what should be included.
Contact details
A primary and secondary contact should be agreed. The importance of this cannot be underestimated, as these are the people that are called in the event of getting caught during the physical portion of an assessment. It is vital that both contacts are available on the test days. It is recommended that the contacts are the only people aware of the assessment. The more people that are kept in the loop, the more chance there is that the assessment will fail.
If more people are included, a list of any and all people that have been made aware of the upcoming test should also be within the document. This can help avoid any embarrassing situations where attempts to extract information are made from somebody who knows that the test is being carried out.
Type of testing
It may be the case that boiler plate test types are offered, as well as more bespoke offerings as a social engineer. However, it can be a good idea to offer both. Not only will it help the supporting sales force, but it can also work as a menu, for clients, enabling them to pick or choose what they feel would benefit them as a business. That is not to say that customers shouldn’t be steered toward what would be more beneficial to them, after all, the social engineer is well experienced in this field. There will be more on this topic in Chapter 6, which deals with effective threat modeling. In any case, this section would document what is required, including any special or custom requirements. This may include specific departments or resources to target. A good example often used is to attempt to “borrow” a corporate laptop and leave the building. This kind of task should definitely result in the engineer scrambling around for that get out of jail free letter, which is covered at the end of this section.
Scope limitations
This section offers the client the ability to identify items that are totally off limits. Lock picking is a good example.
Usually there are tick boxes in this section with a list of things that are likely to do on a typical test. This makes the process a little simpler for the client, but is not a replacement for consulting with the client prior to the scope sign off.
The scoping document will contain some fairly critical information and will hopefully help keep the engineer out of trouble during the assessment. What happens if the engineer gets busted though? Engineers often find themselves surrounded by security guards on tests and ending up sat in police interview rooms for extended periods before now. These are the breaks in this game. What stops the engineer being arrested?
The answer here is “get out of jail free letters.”
Get out of jail free
Unlike monopoly, this is not a license to commit crime with impunity, merely a letter of authority in the event that the engineers are caught or challenged during an assessment. It is a letter to the challenger asking them to call the designated contact and explaining that this is part of a legitimate audit.
Usually this would include a section about treating the bearer of the letter with courtesy and respect. Unfortunately there is no guarantee that this will be followed. Again, this is just the nature of the game in some instances.
Key deliverables
The deliverables of any project can vary from engagement to engagement, but there are some items that are constants throughout any piece of work.
Frequently, it is found that the results of any engagement can be delivered in different ways, and those methods must be accessible and understandable by staff at all levels within a business. The aim of any social engineer should be to deliver the results in a way that creates lasting impact. The goal at the end of any project is to have helped to secure an organization against future attacks of this type.
Consequently, the results can be broken down into two clear categories: a written report and a verbal debriefing, each complimenting the other. There is likely to be overlap between the two, but this does not make the method any less useful to the client.
The debrief
The debrief is typically a sit-down chat with the clients to go through the results of the assessment, along with a run through any evidence or collateral you have gathered. There have been several instances where during a social engineering engagement the engineers have gained physical access to a client site, and just turned up at their office for the debrief, or called them from one of their board room phones. While this kind of thing certainly adds impact to proceedings, there certainly is a need to know the audience before trying it. The last thing needed is to cause offense or appear to be showboating.
During the debrief, it is useful to bring along any evidence that has been gathered throughout the assessment. Photographs and videos are always interesting to the client and can really emphasize the points being made. A detailed timeline of events is also crucial to the debrief. It is worth pointing out that gathering this evidence while performing the assessment can be very difficult, but certain types of technology, such as hidden cameras and microphones, can make it far easier.
There are many ways to deliver this, either with the breakout of PowerPoint slides or as an informal chat. Either way the formalities can be covered in the written report that follows.
It is essential that the awareness of the emotional state of the people being debriefed is understood. It is not uncommon for people to be shocked or even angry that they were breached and immediately start blame storming. The information has to be delivered with tact throughout the process. Avoid naming names or pointing fingers at individuals. Embarrassing or belittling people, even unintentionally, is not helpful to the process and is likely to cause resistance and resentment toward you and your findings. This is why splitting the deliverables between a debrief and a report works so well. The debrief allows the client to come to terms with what has happened, while explaining that the issues identified were procedural and not a fault of an individual, which is almost always true. By the time the written report arrives, likely a week later, things have settled down a little and the report can be looked upon in a more constructive manner.
The debrief is not just a delivery of results, it is also the responsibility as a professional to ensure that the client does not go postal during the process. The only way to do this is to educate them as to the holes within their processes and procedures and not to look at these issues as individual mistakes, which they almost always are not.
As well as going through the individual issues that were identified during testing, time should be dedicated toward addressing remediation. In the vast majority of cases, the remediation is purely educational in nature. The advice should ideally find its way into the next round of staff awareness training to ensure that significant improvements are made. The security as a lifecycle mentality works well here with constant re-education and re-testing contributing toward a far healthier posture.
It is also during the debrief that we would return anything that we had purloined during the assessment. It is not uncommon to have to remove pieces of data, records, or even equipment during testing. This obviously is only ever done with the express consent of the contact prior to the engagement and is limited to corporate property.
Debrief key points
• Know the audience before trying anything to add impact that could be misconstrued.
• Take the client through the evidence that has been collected, including timelines.
• Be clear about what led to the breach—typically procedural flaws.
• Don’t name names. Don’t shame people. Don’t embarrass people.
• Make the process as interactive as possible, encourage client participation.
• Deliver the debrief immediately following completion of the breach stage of the assessment.
• Give clear guidance on how best to address the issues that have been identified.
• Return any equipment that was taken during testing.
• Hand over your get out of jail free cards. These do not want to end up in the wrong hands.
The report
The written report, as previously noted, will have some content overlap with the debrief, but will go into far greater detail on many fronts. It is very likely that the written report will find its way to the desks of people at all levels within an organization. This means that the report will have to cater to each of those individuals. High-level summaries for management as well as deep-dive technical information should both be covered within the report to ensure that the results gain the necessary buy-in at all levels of the business. After all, what is the point of the exercise if the results are not actioned? Exercises in futility are as frustrating for the social engineer as they are for the client, everybody needs to able to see the value in what they do!
The initial sections of the report will largely be standardized across the board and come from stock templates. These sections will include background information on the social engineers as a business and as individuals. It will include relevant qualifications and experience within the business and information about the methodology applied to the testing. Information obtained during the scoping stages and from the scoping document will also feed into these initial sections. A statement of the objectives of the testing and any limitations on the scope should be mentioned.
The way in which the report is now laid out is largely down to personal preference. The most logical way to format the report is according to the methodology that has been followed. This layout should also naturally end up showing the chronology starting with the reconnaissance/information gathering phase.
Each section should have a summary of findings, any additional detail included, and any supporting evidence such as photographs, video, or sound recordings. It should finish by offering remediation advice that can help the client address the flaw(s).
Included is an example from a reconnaissance effort during testing.
During information gathering exercises, the consultants were able to harvest corporate information from publicly available document metadata. Metadata is included when a document is created, but is often hidden from the end user during the process. In this instance, the data recovered included usernames, email addresses and locally installed software packages. In the wrong hands, this kind of information can be exceptionally damaging. As an example, the email addresses gathered can be used in targeted attacks known as Phishing. Phishing, in its most basic form, is the process of targeting individuals within an organisation in the hope that they will click a malicious link within an Email, or open a malicious attachment. In this event, the user’s computer could be completely compromised, which could lead to the loss of sensitive corporate data. The system could then become a platform for further attacks against other systems within the network. The locally installed software packages information can also be used by allowing an attacker to target software packages that are known to be vulnerable.
It is recommended that all published document’s are cleansed of all metadata other than generic information prior to being released, and that all existing documents are subjected to the same treatment.
This example has clearly laid out the issues, the associated risks, and a clear path for remediation. However this stopped short of recommending individual products for the cleaning of metadata, but this could go down to that level, if appropriate, as there are plenty of tools available. It also avoided getting too technical or using too much technical jargon at this stage. Further detail on each successful attack will be available further into the report. If a phishing attack was successful, reference the metadata issue as a starting point of the attack. Then include some screenshots of the email that was crafted, along with shots of the amount of clicks that it generated within the user base, the impact of that section of the report would be greatly increased. Having visual aids within a report makes a big difference for most readers, it really highlights the proof of concept and breaks up the wall of text that the report could otherwise become.
Chapter 13 will cover written reports in detail, so we will wrap up this section with a few key points before moving on.
Written report key points
• Know the audience and cater to them. Management and Technical sections should be included.
• Include a timeline of events. Tip—Use EXIF data from photographs to track exact times!
• Include information on the incident, exposure, and how to remediate the issue.
• Ensure that all evidence is included—video, photograph, and audio.
• As with the debrief, avoid the inclusion of names of individuals.
• Include information about the team and their experience or qualifications.
Social engineering team members and skill sets
A social engineering team can be made up of many individuals, each with differing strengths, weaknesses, and levels of experience. You may be involved in an engagement that is a one-man show or deployed as part of a larger team to cover all the aspects of the assessment. In either case, it makes sense to fit the engineers skill set to the work at hand.
Here are some of the different types of individual that may be deployed to get the job done.
The generalist
The generalist is the all-purpose, do-it-all team member. They are likely to be the less experienced members of the team and have the least developed skill set and levels of experience, however you may need more experienced engineers to fill this role to make up the numbers.
Key attribute(s):
• Positive attitude—They have to be willing to attempt anything that is asked of them. On a social engineering gig, this can range from digging through the trash to tailgating smokers through the rear entrance.
• General skill set—At this point, the individual should have an awareness of some of the more common concepts of social engineering, and certainly a grasp of all the common terminology. It is most likely that the generalist will be given specific tasks to perform by the engineer in charge of the work.
The ethical hacker
The ethical hacker is your ace in the hole when you have gained physical access to the building and need to retrieve data from the network. This role will be filled by a penetration tester, preferably one who can stay calm under pressure. Gaining access to systems is a completely different ball game when there are security guards looking for the engineers, or when there is a very restrictive time window to exfiltrate.
Key attribute(s):
The burner
A “burner” is a common term for a mobile phone that is used for shady business and cannot be traced to its actual owner by any means. As such, it can be disposed of without hesitation or guilt. The burner is the sacrificial lamb. It’s the team member that is sent in to carry out a high-risk exercise, accepting that there may well temporarily lose the individual when they get caught in the act. The implementation of this play is often needed because the hand has been forced, and there are no other ways to gain the required intel.
If the use of distraction techniques is employed, the burner will be stepping into the fray for this task also. Distracting a set of guards and often receptionists can really open up doors for the rest of the team!
The social engineer
The social engineer in the team is the person skilled in the art of manipulation, persuasion, and deception. Some people are lucky enough to have these skills come naturally to them. Others have picked them up throughout their careers in other roles. Sales people, for example, already apply the tricks of the trade without even realizing that it is social engineering! Listening to a sales person trying to get a receptionist or call center to pass their call through to a CTO or similar can be an eye opening experience. Regularly the sales team is asked to drop into this role and make calls as a part of our engagements.
As well as the supporting sales staff, there might be at least one dedicated social engineer on the team. It is most likely that he would spend the vast majority of his time on the phone trying to manipulate individuals into gaining entry for the generalists. Even though this is the case, never underestimate the power of face-to-face social engineering. People get calls they don’t want to deal with, or that seem suspicious all the time, but exposure to this in person is far rarer and as such can be more likely to work.
Key attribute(s):
• Extremely confident. This applies to face-to-face conversations as well as using the phone
• Expert in the human element of social engineering. Understands all concepts covered throughout this book. Chapters 1–3 are good starting points
• Exceptionally detailed when it comes to preparation work such as building strong pretexts.
The scout
The scout is responsible for all aspects of reconnaissance in the buildup and during the course of the engagement. This can range from gathering photographic evidence of the building and its security setup to establishing patrol times for guards. The scout will scope out entry and exit points, try to establish what door control mechanism is in use, and see if there is a particular time of day that may be more suited to the engagement. For example, if the plan is to tailgate the perimeter doors, the best time to do this is when the most people turn up to work. The more footfall there is through that door, the more opportunities there are to follow without looking too suspicious. There is nothing worse than standing around looking out of place waiting for someone to follow.
The scout will perform a good deal of initial reconnaissance from the comfort of the office too. It is surprising how much useful information can be turned up on images.google.com and maps.google.com. In fact, it is common to find high-resolution pictures with ID badges in them using this technique. Google Maps can be used to scope out the physical location with a degree of accuracy, but should not be relied on exclusively. Street view is a particularly useful tool, which can help to identify entrances and exits, smoking areas, and security gates.
The scout role will often be filled by a generalist within the team. It is fair to say that the reconnaissance phases of the engagement will be contributed to by the entire team, purely because of the importance of this information.
Getting all of the information in one place and getting around a table to discuss potential vectors is always a useful exercise.
Key attribute(s):
• Attention to detail—Every last piece of information counts in reconnaissance. Knowledge is power
• Technology savvy—Not just from a gadget perspective but also from the point of view of manipulating legitimate services, such as Google Maps, to perform useful reconnaissance
• General knowledge of security systems and social engineering
• Able to identify opportunities for the engagement, such as smoking areas, or routines that staff may have which open up a potential attack vector.
The thief
Ok, so this individual isn’t really a thief, but using more romantic notions of the master thief there can be some parallels drawn between the two character types.
This role within the team is filled by a person who is quite likely to possess skills from all of the aforementioned categories. Above and beyond this, the thief will have lock picking and physical security skills, an awareness of security systems and how to bypass or avoid them as well as the ability to go unnoticed, even when in areas that are particularly sensitive or well secured.
Nerves of steel are required for this role. Picking locks isn’t the easiest task if the hands are shaking uncontrollably.
Key attribute(s):
Summary
This chapter has covered the need for social engineering, and why the industry is slowly starting to grow and be taken more seriously. High profile compromises such as RSA have driven a change in attitude toward social engineering. Compliance was touched upon briefly and how social engineering engagements can be used to aid compliance.
Next came the topic of social engineering engagements. Looking at the operational conditions, challenges, and considerations, none of which should be taken lightly. This included a brief look at threat modeling, difficulties in time management, project management as well as ethical considerations. These topics were approached from the client’s perspective to try and help them identify the right people to perform your assessment. Legislative considerations were included such as the CMA, the Human Rights Act, and the CFAA.
Subsequently, came the subject of how to build a social engineering framework by adapting the PTES with a view to streamlining the operation.
Assessment prerequisites were a key topic, helping to ensure that the project does not come off the rails due to poor initial consultation or lack of supporting information.
Finally, identifying the key deliverables in any engagement, as well as identifying the team members who would deliver them.
Chapter 6 will look at threat modeling and how to effectively apply this during a social engineering engagement. The chapter will cover current threats as well as real world examples. It will also run through a practical approach to guiding a client through threat modeling.
Additionally, addressing why there is a need for threat modeling and what the actual threats are to our businesses.