Secure data with vulnerable users

Sensitive data stored within a system can never really be completely secure. However, to explore the concept of vulnerable employees, let us suppose that a database is invented that cannot be penetrated by unauthorized users. Hackers can probe for the service, they can see that it is available, but no matter how hard they try they cannot gain access to the data. Attacking this database directly is simply not a viable option. So, instead of attacking the database directly, the only other approach is to attack the entities that interact with that database.

When the perspective is shifted from the idea of attacking a system directly to attacking those who use it, the benefits become very interesting indeed. In the database example above the attacker may attempt to trick that user into revealing their database credentials or allowing access to the database in some other way. However, although this may be the primary objective, it is not necessarily the best way of achieving it. For example, the attacker could try and trick the user into accessing the database on their behalf and reveal the information within, make changes to certain information or even delete sections. Rather than elicit the information required to gain access to the database directly, the user could become a puppet for interacting with that database. Providing the attacker’s pretext is good enough the user may perform this action without even realizing that they are causing a security breach. The attacker may achieve their objective without raising any alarms as a successful attack of this kind is very hard to detect indeed.

Thinking of users as puppets puts a true perspective on the scope, significantly expanding the security considerations. That same database user may well have access to the company’s e-mail service, workstations, business’s proprietary software and any general internal network resources such as file shares. As well as the database credentials they may have knowledge of employee hierarchy, door codes, location of keys, building layouts, the personnel’s favorite pub, what equipment is used, sensitive or critical information and even how the chief executive likes his coffee to name just a few.

The aforementioned individual may well have enough knowledge and privileges to unknowingly cripple the business. Therefore, compromising that member of staff would give an attacker the metaphorical “keys to the kingdom”. If they can effectively manipulate the employee then it is as good as having someone on the inside, in the sense of an “inside job.”

The problem escalates when you consider that a business may have hundreds or even thousands of employees falling into this category. In addition, it is frequently the case that a full security breach may have resulted from a single employee member being successfully targeted. When viewed in this way the problem seems practically unsolvable, the odds are certainly stacked in the attackers’ favor.

By making each employee privy to sensitive information, enabling them to access sensitive services and giving them access to sensitive areas, the business is essentially drawing a metaphoric target on their employees. The business is making each inherently vulnerable employee an extremely valuable target; making them even more vulnerable through various security weaknesses in the business itself. Therefore, it is little wonder that social engineering attacks are so very effective.

The problem with privileges

In order for the businesses to function, certain privileges must be granted to each employee. This is inevitable, there will always be a need for those individuals who by the very nature of their job would be considered to be a high-value target and those considered to be a lower value target. However, to what extent do privileges really affect the business’s susceptibility to social engineering? Or put another way, the employee’s actual value to a social engineer? Should the business approach privileges in any particular way when considering the threat of social engineering?

The greater the privileges assigned to an employee, the greater the risk they present to the business. Clearly the more services and data that employee can access, the more damage they can potentially do. It is important to remember that the vast majority of attacks are inside jobs, whether that be deliberate or accidental. From that perspective alone it is wise to think carefully about granting employees too many privileges.

The reality is that most employees are afforded too many privileges, simply to avoid business disruption. It is all too common to have a personnel member request access to a certain service or piece of information and have the IT department grant it without thinking to avoid some tiresome set of procedures. By doing this the business is gradually turning each employee into a greater threat both from the perspective of an inside attack and from the potential for that employee being compromised by a social engineer.

Would a social engineer target highly privileged users? Perhaps, especially if they have direct access to the target data. However, it is very important to understand that social engineers will take the path of least resistance. Therefore, placing all the security controls and training around your most highly privileged employees may prove to be a worthless venture.

Suppose a social engineer wanted to gain access to sensitive patient records. Should they target a surgeon or should they target a nurse? The surgeon has direct access to the data. However, they may have had additional specific training regarding when they can and cannot discuss this sensitive information. A social engineering attack against the surgeon is certainly possible, perhaps with a well-crafted impersonation of a family member or colleague. However, it would take a great deal of planning. The nurse will likely be an easier mark but will have no access to patient records at all. However, the nurse will have access to the computer system, where those records are stored. All it may take is a well-designed phishing e-mail sent to each head nurse. Any nurse that clicks the malicious link may unknowingly create a “back door” for the attacker, gaining access to the network. After escalating privileges the sensitive data could then be accessed without any interaction with the surgeons. Through the very nature of their job, surgeons have a high level of privileges and the nurses relatively low privileges, but this didn’t really hinder the perpetrator. The fact is that there was a higher chance of success, through phishing attacks against 20 head nurses than through tricking a doctor into revealing patient records.

Privileges extend well beyond what the businesses’ role-based systems dictate about the user. For example, suppose that according to the employee’s profile they have privileges to allow access to the Internet, the public file share and a suite of software packages necessary to perform their specific job role. Let’s say that a social engineer was able to convince this employee to reveal any information or manipulate them into performing any task. With regard to the job role-specific privileges granted to that employee, the social engineer wouldn’t gain much as that user doesn’t have access to any sensitive information or services that could be particularly useful to the social engineer. However, those basic privileges may be employed to launch extremely effective attacks against the business. If the social engineer persuaded the user into revealing their e-mail account credentials, the social engineer could then use the same account to send phishing e-mails to highly privileged personnel members. These internal phishing e-mails are extremely difficult to defend against as the business has no way of knowing who had really sent them. The recipient could well be tricked into downloading malicious software and uploading it to the public file share, subsequently endangering other users.

If a social engineer was able to fully manipulate a lower privilege employee, they could manage to arrange a meeting room for a contractor, revealing what remote access software the business uses or what operating systems and web browser versions are being used. All of these things are not related to the kind of privileges a business grants to the personnel. A business simply cannot achieve the kind of granular level of privileges needed to prevent social engineers from obtaining information that could be used against the organization.

It makes little difference whether a business grants high or low privileges to an employee, a social engineer can turn this to their advantage. The important point here is not to assign the security controls and awareness training to just those employees deemed as high-value targets. Security controls and training should be applied to everyone in the business as every employee is a potential target to a social engineer.

Data classifications and need to know

There are environments where the possibility of sensitive information leakage is an extremely serious concern, such as a government or military organization. What security controls are in place for these environments, which are not in place for most businesses? It all comes down to how important the data is and ensuring it is handled accordingly. A plethora of books have been written about data classification systems and so here we will only touch upon the absolute basics and how they relate to social engineering vulnerabilities.

To enable commercial organizations to improve their data security they can benchmark themselves against the various industry security standards. These standards include information classification as a defined security control. For example, ISO/IEC 27001:2013 A.8.2.1 states “Information shall be classified in terms of its value, legal requirements, sensitivity and criticality to the organization”. Therefore, an example of such a data classification scheme would be:

The above list seems like a very sensible separation of data types when the priority is preventing potential harm to the business.

In comparison, a military or government data classification scheme may look as follows:

There are obvious parallels between the two data classification systems, the main difference being the overall objective. The government and military organization are concerned with protecting national security, whereas the commercial organizations are concerned with protecting themselves in a business sense.

The main issue here when it comes to the susceptibility to social engineering is that the businesses don’t have to use the commercial classification system. Military and government agencies must use their system for a variety of legal reasons among others. Businesses have a choice and their decision is usually based on how sensitive they consider their information to be. The vast majority of businesses targeted by social engineers usually place their information into just two classifications: “confidential” and “public”. The lack of granularity in this classification system results in a lack of specific controls associated with each type of information. The fewer security controls in place and the more employees that can access the data, the more susceptible the business becomes to social engineering attacks.

There is also another significant difference between how commercial and military organizations handle their data, being the concept of “need to know.” In military organizations an individual can have all the relevant security clearance to access sensitive information but may be denied access if they do not “need to know” that information to perform their duties. This is an extremely effective security measure to limit the flow of sensitive information.

In commercial organizations the concept of “need to know” is rarely implemented, usually deemed as an unnecessary security control. So what effect does this have? Even if a business does decide to implement the full list of data classification systems there may be a significant leak of information between the various classes. Without the restrictions of “need to know”, any level of employee could potentially access sensitive information not necessary to perform their duties, making them more of a threat to the business. This information may be deemed as sensitive but that doesn’t necessarily mean that a low-privileged employee cannot gain access to it.

In military organizations the clearance levels map directly to the classifications of the data; without equal or above clearance you cannot access that data. In commercial organizations, the only form of security clearance is the role-based system used, which rarely maps so directly to the sensitivity of data.

This is not to say that businesses should start to use military style data handling methods. The point is simply that they shouldn’t do the opposite either; implementing a weak data classification system with all the data accessible to all the personnel.

Security, availability, and functionality

There is a clear relationship between security, availability and functionality, often depicted as the triad shown in Figure 2.1.

As you increase one of the aspects, the other two will decrease. For example, if you want functionality and availability then security will suffer. If you want the system to be as secure as possible then you must reduce the functionality and reduce how available it is to users.

Most businesses accept the inevitable struggle of trying to balance security and availability. If you make a system more secure you make it less available to users and vice versa. If the business cannot get the balance right then they may either create issues through insecure systems or issues where users struggle to do their jobs effectively. For example, if you have live network points available throughout the building an attacker can potentially plug a laptop in anywhere and attack the network services. However, users find being able to plug in their laptops in meeting rooms and various other places very useful, especially if they don’t have access to the wireless network. Here the balance may be shifted too far toward availability. The business may decide to implement port security controls and disable all unnecessary network points. Now they have greater resistance to attackers’ rogue laptop devices. However, the constant need to disable and enable ports and port security for legitimate users becomes an administrative nightmare. Now the balance has shifted too far the other way toward security. When it comes to social engineering this balancing act is equally as difficult.

Let’s suppose a business has discovered that the help desk department is giving away too much information. A social engineer had called through, spoken to the employee and finished the call having learned the name, address and direct telephone number for the head of the IT department. Here the balance is too far toward availability and functionality, if you consider the help desk engineer to be a service rather than a person. The business could decide to restrict what the help desk engineers can and cannot say over the phone, perhaps by providing a script for them to use. This would reduce the “functionality” in order to increase security. The social engineer then calls through again, this time impersonating the head of IT and leverages their privileges to pressure the engineer into complying with their requests. The social engineer is successful in eliciting information that the employee knows they shouldn’t be revealing. The business then decides that the balance is clearly still not correct, so they implement a caller identification process whereby the caller is called back on a known number. This reduces availability to increase security. In response, the social engineer then impersonates an employee and claims that they are using a personal phone as their business phone is broken and bypasses the identification process. The business responds by implementing a hard and fast policy that only the known number can be used regardless of the situation. The employees are made aware that if they break or bend this policy they may be disciplined. This further reduces availability to increase the security. The adept social engineer now considers other possible solutions, such as tricking the phone company into diverting the calls or maybe just attacking the business in some other way. Now the business believes they have a good balance until a genuine personnel member calls up with an urgent situation using their personal phone, having actually broken their business one. For that personnel member the balance certainly isn’t right at all as they hopelessly argue with a help desk engineer that refuses to help them.

The above example has obviously been exaggerated but it does demonstrate how difficult it can be to achieve the right balance. The business tries to improve security by removing availability to the point when it begins to overrestrict its own personnel members.

Another common example of issues surrounding security and availability is when businesses attempt to enforce a strong password policy. The business decides that users must use a long, complex password with uppercase letters, numbers and special characters. It is believed that this will significantly improve the overall security of the business. However, the availability is considered nonexistent to a user that can’t remember their new complex password. Consequently, that user then decides to write down the new complex password in case they forget it again. Suddenly the password security policy is rendered completely useless. Social engineers are fully aware of issues such as this and will often look for information such as passwords written down around the office (such as on small Post-It notes, calendars, diaries, etc.).

How does security relate to functionality? It is often said in the security world that the most secure systems are the simplest ones, with vulnerabilities usually being born out of complexity. By increasing the system’s functionality, you are increasing the amount of ways in which it could potentially be attacked.

Suppose the target business is paranoid when it comes to security. The personnel are not provided with any outbound Internet access, e-mail system, fax and can’t even communicate via standard postal mail. It is also near impossible to gain access to the building. The only realistic way to contact the personnel members is using the telephone through a call center, who thoroughly screen every caller. The “functionality” of this business, regarding their communications methods, is severely reduced. However, this results in a small attack surface which in turn makes them more secure. A social engineer would have to plan an attack via telephone and this would be no easy task, especially if the target company and the personnel have minimal online presence.

Most businesses cannot operate in the same way as the above example describes, leaving them no choice but to offer multiple communication methods. Consequently, for the vast majority of businesses, the social engineer can attack via telephone, e-mail, fax, written documents and of course in person to name a few.

In reality it is very difficult to predict the consequences of influencing the balance of security, functionality and availability, making it one of the hardest challenges businesses face. However, this challenge has to be met as any shift in this balance introduces a new vulnerability, which the social engineer will inevitably exploit.

Customer service mentality

Are employees trained to be vulnerable to social engineering? They’re certainly trained to be helpful, at least in most businesses and especially in roles such as the receptionist or help desk technician. If an employee is trained to be helpful, then they’ll do what they can to solve your problem, provided that it falls within their area of expertise. Social engineers are well known for leveraging this by presenting the employee with a problem in which the solution will most likely aid the social engineer in some way. Take the following conversation as an example:

This example shows how a social engineer may take advantage of the employee’s eagerness to be helpful. This is hardly a complex social engineering attack, using only the most subtle of techniques. However, it continues to be effective time and time again. The first two questions will inevitably receive a “yes” response and this is on purpose. The employee is subtly moved into a positive and agreeable frame of mind, making the third question more likely to receive a positive response. Had the social engineer immediately asked for the supervisor’s name and direct number then employee would likely have been less responsive.

Once the agreeable frame of mind is achieved, the social engineer presents the problem. They were in the middle of an important conversation with the supervisor but got cut off and he can’t remember their name. The employee can easily solve this and using an obvious trick reveals the full name. By stressing the importance of the conversation, the social engineer applies a slight pressure on the employee. The social engineer is not directly asking for the person’s name, they are presenting a problem with a solution involving the name. There is a big difference between the two in the mind of the help desk employee. Finally, the direct dial is gained by presenting a second problem. They keep getting cut off so would like the convenience of being able to dial back directly. Again, this problem is easily resolved. The social engineer then adds in a hint about the nature of call, being about a colleague. This would hopefully create a sense of curiosity in the help desk employee, increasing the potential for them being helpful. By presenting problems rather than asking directly for information, the social engineer takes advantage of the customer service mentality. This customer service vulnerability will exist wherever the social engineer can achieve their objective through the solution to a problem that personnel can solve.

Is the answer to remove good customer service mentality? That would certainly help to defend against social engineering as the hard-faced grumpy and stubborn receptionist would likely refuse to give out any information, probably out of spite rather than due to procedures. However, your business would quickly suffer from the tirade of negative customer feedback.

The extent to which this customer service mentality becomes a vulnerability depends upon the policies and procedures. If personnel are trained to be helpful and don’t follow any policies or procedures that provide guidance on what can and can’t be revealed, then the business has one serious weak link in the chain.

Poor management example

The lack of a “top-down” approach is a common topic in many a security book. The simple fact is, if you don’t have management support then your project is more than likely doomed to failure. What happens when management do not appreciate the threat of social engineering? Does this make the company more susceptible to it? The short answer is obviously “yes”! Without management “buy in” there will be little if any budget for defensive strategies and the employees are unlikely to support a concept that doesn’t have management support. Without robust policies and procedures, personnel awareness and training and security assessments, the business leaves itself open to attack.

Suppose the management team didn’t really appreciate the threat of social engineering but had to implement defenses due to regulatory or compliance drivers. The defense strategies may be in place, but does the management’s lack of support still create issues? Of course. The management team are likely to resist security procedures when it doesn’t suit them and possibly refuse to attend awareness and training programs on the grounds that it doesn’t apply to them. The management’s position makes them a possible target for impersonation techniques and if management consistently bypass security controls, then the social engineers can do the same. It is hugely important that management set a good example for the employees.

Lack of awareness and training

The importance of employee awareness and training is discussed in great detail in Chapter 15, including how to plan, design and implement an effective program. However, it is worth including within this section as a complete lack of any awareness and training can potentially be the most significant mistake a business can make, especially when it comes to defending against social engineering.

Awareness and training programs ensure that:

There are two main ways in which an employee can become highly vulnerable to social engineering attacks. The first is by the various weaknesses in the business itself, as already discussed. The second is by ensuring that human nature is completely open to exploitation. This would be accomplished by neglecting to perform any social engineering awareness and training.

The above refers to the general objectives of a security awareness and training program. This could be expanded if the aim was to give employees the tools needed to defend the business against social engineering attacks.

Social engineering awareness and training programs ensure that:

This may all sound relatively obvious but the design and implementation of an effective program is not so straightforward. Often businesses opt for a series of presentations that fail to achieve any real impact and certainly don’t provide the necessary “training” required.

Weak security policies

The idea of hardening the business policies and procedures to social engineering attacks is something covered in great depth in Chapter 14. Even those employees that are normally inexplicably invulnerable to social engineering attacks can still be made vulnerable due to weak policies and procedures. This is why an entire chapter is dedicated to helping businesses improve the current policies and procedures and create new, more security-oriented replacements. These final sections will explore some of the most common weaknesses in policies and procedures, how they make a business vulnerable and how social engineers may take advantage of them.

The business security policies are a continually updated set of documents explaining how the business intends to protect its physical and informational assets. Typically a business should ideally have policies covering:

The above list is certainly not exhaustive, depending on the size and complexity of the business, many more may be required. This is one of the most obvious mistakes that a business may make, not having these policies in the first place. If the business doesn’t take the time to create these policies, then they simply cannot expect the employees to act in adherence with the best practices defined within them. If the employees aren’t aware of how to use the equipment and services in a safe and secure way then they become seriously vulnerable to attack.

The next common mistake that businesses make is to create these policies but to fail to effectively communicate them to the employees. The documents are uploaded to some central intranet or Wiki service and only ever accessed by personnel when they violate some aspect of the policies. Are personnel expected to assimilate this information during the enrollment process? Most businesses would claim this to be the case, but how many employees do it? Also, how many times has the IT infrastructure and policies changed since enrollment? The information within policies should form the basis for foundational security awareness and training programs. The employees should be exposed to the information within these policies regularly as part of continuous training.

Let’s suppose that a business has created a set of security policies, made them available to all employees and communicates the content of those policies regularly. The employees have a thorough understanding of what the policies state and how they support the business’s objectives. This would all be a waste of time if the content of those policies was so weak as to have little actual effect on the security of the business. What do we mean by a “weak” security policy? The following paragraph is an example excerpt from a security policy relating to information sensitivity:

We have already discussed data classification systems and here we see how they are used as part of a security policy. The above excerpt seems sensible enough, stating the kind of information that should not be disclosed to the public. However, the term “sensitive” is very relative, one piece of information could be totally innocuous to an employee and the business, yet extremely useful to a social engineer.

Information should be treated like pieces of a jigsaw puzzle. The following is a list of jigsaw pieces that an employee may inadvertently reveal. These snippets of information are extremely useful to a social engineer but don’t clearly fall within the category of “confidential,” at least not to the average employee:

If a social engineer can leverage enough of these pieces in some way, they may be able to piece together enough of the picture to be useful. For example, if you know an employee is away you could call the business and impersonate them. A very clichéd social engineering attack is to turn up to the business claiming to have a meeting with the employee you know is away. This can be useful to perhaps drop USB drives with malicious software (hoping that employees will pick them up and attach them to their workstations), or simply to interact with the receptionist and study the layout of reception.

The main issue with the security policy is that it states what information should generally be considered confidential but not how, or why, it could be used against the business. Without how or why it is difficult to adhere to the policy as many items of information would fall within a gray area. To some employees the existing cleaning company would be as innocuous as the color of the office carpet. The policy doesn’t give the employee enough information to clearly work out what should and shouldn’t be revealed.

Policies are often vague by design, including all the information necessary to fully explain every aspect would result in a very large document indeed. It would be even more unrealistic to expect employees to assimilate a 250-page policy on security concepts. However, one of the reasons most policies are vague are because they are too generic. If a business ensures that the policy is aligned with their individual requirements then they can be more specific without being too lengthy.

When a policy is too specific, the employees may misunderstand or misinterpret the purpose of the specific policy item. The following is an example of an individual policy item regarding the transmission of passwords within the business.

This policy item sounds fair enough, the e-mail accounts could be compromised or the e-mails themselves intercepted. However, despite such a policy the employees will likely still shout out passwords across the office or spell them out loudly and clearly over the telephone for all to hear. They will still write them down, print them off and openly share them with colleagues in order to save time. The policy is addressing a very specific issue and not addressing the larger overall security concept.

Security policies can also be weak simply due to a lack of understanding of the weaknesses in security systems. For example, a company may have a security policy associated with e-mail usage that states:

Most modern phishing attacks are based around links to malicious websites rather than malicious attachments, so this policy is great advice. However, if the attacker found a cross-site-scripting (XSS) vulnerability in the business’s website, the link could lead to their official website but then redirect the user to the malicious website without them realizing it. This particular security policy would then, in fact, be helping the attacker.

Here is another common example of a weak security policy, this time associated with password strengths. This policy is normally configured within Microsoft’s Active Directory to try and enforce strong passwords.

What is the most popular password used? Well, to meet these complexity requirements and still remember the password most employees will choose, “Password1”. Or often the place where they work with a “1” on the end, such as Liverpool1 for example.

The above example is arguably more to do with computer system security than social engineering. However, the policy item is weak because it doesn’t take into account human nature. Social engineering is about exploiting human nature so this example fits in very well.

Weak procedures

Procedures are a critical part of any business, defined as “a series of actions conducted in a certain order or manner”. They ensure that business tasks are performed in a consistent way, in line with the business’s expectations. If a business has weak procedures then the personnel can become vulnerable to attack. By “weak” we mean that the procedure can be bypassed or circumvented in some way by an attacker.

For example, the following common procedure is related to signing in contractors:

When a contractor arrives at reception and introduces themselves:

The above procedure seems quite sensible and the vast majority of businesses use something similar. However, from the perspective of a social engineer this procedure could well be open to abuse.

If the social engineer arrived, signed in and then told reception that the primary contact wasn’t in but said it was fine for them to work unassisted, would the receptionist know what to do? If the social engineer dropped enough names, explained a very plausible situation, looked right and sounded convincing, the receptionist may well accept the social engineer’s reasoning for dismissing the procedure. In fact, in the face of not knowing what to do, accepting the social engineer’s reasoning will likely be a tempting solution to the problem. The social engineer may explain that they’d already spoken to their manager Helen and she said it would be fine to be unescorted, knowing full well that Helen is away on business presently.

Procedures are not always designed with security in mind, focusing more on trying to keep the businesses running smoothly. The simple lack of “if then” and “what if” statements creates situations where the employee is left to interpret the procedure, which leads to situations that social engineers can potentially manipulate. The above procedure is probably more concerned with fire safety than with thwarting social engineers.

For more information about hardening procedures please refer to Chapter 14.