Creating Hardened Policies and Procedures

The only limits to methods employed by a competent social engineer were identified as the availability of the tools available to them, their imagination, and their level of nerve to complete the assault.

With all this in mind, what can a business do to reduce their potential risk to becoming a target and to reduce the potential for a successful attack. The success or failure of an effective Social Engineering Defensive Strategy is constructed using a multilayered defense approach that relies heavily upon its strong foundations. These foundations are comprised upon two key components:

1. Social Engineering Policy

2. Employee Social Engineering Security Awareness and Education Programming (extensively covered in Chapter 15).

This chapter will provide extensive guidance on the purpose of a Social Engineering Policy and how to build one that is fit for purpose and that meets an organization’s needs. However, it should be remembered that even the strongest of policies, supported by various technical and physical controls, will not completely eliminate the potential of suffering a breach at the hands of a highly determined, well equipped, and competent social engineer.

Notwithstanding this, both of these foundations are proven to be the most efficient and cost-effective method. For example, all that is required to develop credible foundations is management support combined with the dedication, enthusiasm, and willingness of a knowledgeable Information Security specialist and the time for both its development and delivery. Consequently, the costs associated with policy creation are relatively small in comparison to the wealth of technical and physical controls that are available.

This chapter will also provide the reader with additional guidance into developing suitable policies and procedures, providing an insight into what makes a good document.

Background

As an example, let’s look at a small to medium sized retail business that is seeking to enhance the security around its sensitive or critical assets. The business carries out a risk assessment against the potential cost of a breach to their information assets and is surprised when the evaluation is estimated to be in the range of $4 million, the equivalent of their annual turnover. As a result, this receives the full attention of senior management and the business sets about hardening its security measures.

On the advice of an external security products vendor, the business spends approximately $2 million on a plethora of technical and physical devices to ensure that these assets are protected against well-constructed defense in-depth security infrastructure.

Job done? Not quite…!

Despite the fact that this approach has issues going back through the centuries, it is still the most commonly employed model. For instance, take a look at the siege of Troy. In the twelfth century BC, for more than a decade the Achaeans besieged the defenses that secured the city of Troy, in an attempt to gain access. However, the city of Troy had been constructed using layered defenses, configured such as:

Outer layer protection

Outer layer 1: A wide, deep trench

Outer layer 2: 1300-ft wide “dead zone,” with floor mounted spikes

Outer layer 3: An earthen (stone-reinforced) wall, with wooden joint stakes

Outer layer 4: Towers, constructed of wooden beams

Inner layer protection

Inner layer 1: 500-ft wide “dead zone”

Inner layer 2: A dyke of earth “heaped up from two sides”

Inner layer 3: Wooden inner wall

Inner layer 4: High wooden gates

Consequently, after suffering persistent losses, the Archaeans were forced to come up with a new and inspirational method of attack, which would enable them to covertly get through the strong defenses. This is where they implemented the approach of carrying out the assault using social engineering tactics, exploiting the weaknesses associated with people. This was the birth of the Trojan horse-style attack; whereby an attractive gift is delivered, awaiting a trusted resident to transport it, containing a hidden payload, through the various layers of defenses. This approach not only has the potential for greater success but also allows the perpetrator to launch a strong attack (having avoided being weakened through the numerous layers of defense) closer to the heart of the target.

The example above highlights the vulnerabilities associated with a Social Engineering attack and clearly demonstrates the vulnerabilities associated with the exploitation of human nature.

In addition to the large amounts of coverage for the Troy siege, the concept of Social Engineering appears in abundance throughout the ages. Take a look at many stories (both children and adult) that include the use of Social Engineering. For instance, the bulk of children’s fairy tales are based upon Social Engineering concepts (Hansel and Gretel, Snow White, Red Riding Hood, Pinocchio, etc.) and the entire concept of the quintet of Terminator films have been created on the concept of Social Engineering, when the machines become self-aware they identify the threats perceived from humans and, as part of a vulnerability management program, start to wipe them out, through the use of Social Engineering, masquerading machines to look like humans.

Despite all of this, Social Engineering remains to be the most significant threat to Information Security. For example, with all the aforementioned readily available examples, why are people still vulnerable and willing to wheel that mythical horse through the various layers of defense in their virtual world by opening that spurious e-mail?

This being reality, what can be done to mitigate this threat? Organizations need to focus on those human vulnerabilities, ensuring that their employees become self-aware and include the human element in their vulnerability management program. This can only be achieved through improved awareness derived from formal policies and procedures and contributing to a substantial level of protection, especially when supported by a security awareness program that includes Social Engineering.

Looking back to the siege of Troy, had there been a strict policy regarding the acceptance of unexpected gifts or had the city of Troy residents received a security awareness program highlighting the vulnerabilities associated with the exploitation of human nature, would the siege have ended in the same manner? In truth, it is extremely likely that the end result may have been significantly different. For example, what would have been the chances of the residents of the city of Troy dragging the large wooden horse through the various layers of defense if foundations 1 and 2 had been part of the defensive infrastructure?

Social engineering defense: a proactive approach

Having set the scene for need to lay strong foundations, this section will explain what makes a good policy and how this can be effectively developed and implemented.

As with any policy, it is only effective when it receives the whole-hearted support from senior management. A common failing for businesses is when a policy or procedure is introduced and yet the business leaders have not fully understood or supported what the policy is trying to achieve. Let’s look at a couple of examples:

• Example 1. An organization has recently been the victim of a burglary and as a result introduces a number of physical security controls. Following which, an external door or window is found unlocked negating these supplementary security measures. In response, the company implements a formal cease-work procedure whereby the last person to depart the building is required to carry out a physical walk around to ensure that no sensitive paperwork is left out and all the doors and windows are secured. Following the first few weeks after its introduction, everyone is adhering to the new procedure and the benefits of improved security measures are clearly evident. Then, as is always the case when dealing with people, complacency sets in and personnel start to let things slip. This leads to a window being left open once again negating the additional security measures. The management responds with a half-hearted reprimand that provides little deterrence and has little effect on reducing the chance of a reoccurrence. The relevance and importance of this new procedure suffers further damage 1 week later when it becomes known that a member of the senior management has been guilty of paying lip service to it and leaving the premises insecure.

• Example 2. A company makes the conscious decision to ensure that all their sensitive data is secured away when not required. As a result, they introduce a clear desk policy, which requires all employees to ensure that any sensitive data is locked within the secure office furniture. This all sounds like good practice to help the business safeguard its sensitive information. However, the policy is only ever seen by the author and the approver, being retained in a private folder and not being made readily available to all of the company’s employees who as part of their duties are responsible for dealing with sensitive information assets. Subsequently, during the out of hours, one of the cleaners inadvertently picks up a number of these items along with various items of rubbish and it ends up at the local landfill site. The potential consequences for such an accident is a breach of confidentiality or creating a significant impact to the business when this crucial information is not available at the time it is required.

These two examples demonstrate the importance policies and procedures afford to help ensure the protection of assets by addressing the weaknesses associated with people. The intrinsic security of a vault is made worthless if the person securing it leaves the door wide open.

With this in mind, the importance of developing and implementing worthwhile policies and procedures that help deal with the exploitation by Social Engineers is the cornerstone of any successful Information Security program. An attack by a Social Engineer uses four stages (preparation, manipulation, execution, and exploitation) to exploit the inherent vulnerabilities that come with human behavior:

Consequently, companies wishing to employ a proactive approach, to ensure that risks to their organization are reduced will start with well-written policies and procedures. These documents must be targeted at the audience that are most susceptible from the two modes of Social Engineering attack (Human Based or Computer/IT based) and be well written using jargon-free language and be concise. In essence, these policies should be readily available and clearly articulate what the company’s objectives are and what employees MUST and MUST NOT do.

As per the very dynamic nature of business and the technical environments within which this critical information resides, it is imperative that any supporting documents are regularly reviewed to ensure that they retain their relevance updating the versions as required.

Industry information security and cyber security standards

In order to assist organizations with improving their Information Security and Cyber Security defenses, there are a plethora of Industry Standards that can be used, by companies, to benchmark themselves against.

Despite the fact that Social Engineering is reported to be the number one Cyber Security threat, it is an element that is only alluded to, in the various Industry Security Standards (IEC 27001:2013; COBIT 4.1; PCI:DSS version 2.0; ITIL, etc.) but is rarely directly referenced. However, perhaps it is an indication of the increasing threats presented from Social Engineering that has led to the Payment Card Industry Security Standards Committee have now made a direct reference to this threat, in version 3.0, where previously it was only covered in an additional document “Navigating PCI:DSS Version 2.0”:

8.2.2 Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys - Guidance: Many malicious individuals use “social engineering”—for example, calling a help desk and acting as a legitimate user—to have a password changed so they can utilize a user ID. Consider use of a “secret question” that only the proper user can answer to help administrators identify the user prior to re-setting or modifying authentication credentials.

However, in complete contrast, ISO/IEC 27001/2:2013 (Information Technology—Security Techniques—Information Security Management Systems—Requirements) makes no direct mention and no policy requirements are required to be enforced. That is until, the latest evolution with the launch of ISO/IEC 27001/2:2013. During the drafting of this document, in October 2011, Dejan Kosutic confirmed the omission of Social Engineering from the older standard.

Expected changes

At the moment of writing this chapter it is impossible to predict all the changes in ISO/IEC 27002:2013 because the final draft hasn’t been written. However, likely changes can be judged by hearing what ISO/IEC/IEC 27001 experts have to say—here’s a summary of suggestions from ISO/IEC 27k Forum, the leading expert forum about ISO/IEC 27001/ISO/IEC 27002:

• Accountability: Definition of what it means in relation to human resources management.

• Authentication, identity management, identity theft: They need better description because of their criticality for web-based services.

• Cloud computing: This model is becoming more and more dominant in real life, but hasn’t been covered in the standard.

• Database security: The technical aspects haven’t been systematically laid down in the existing revision.

• Ethics and trust: An important concept not covered at all in the existing revision.

• Fraud, phishing, hacking, and social engineering: These particular types of threats are gaining more and more importance, but aren’t covered systematically in the existing revision.

• Governance of information: This concept is very important for the organizational aspect of information security and is not covered in the current revision.

• IT auditing: Needs to focus more on computer auditing.

• Privacy: Needs to go broader than existing data protection and legal compliance, especially because of cloud computing.

• Resilience: This concept is completely missing in the existing revision.

• Security testing, application testing, vulnerability assessments, pen tests etc.: These are essentially missing in the current revision.

Published in July 2012, the (ISO/IEC 27032:2012 Information Technology—Security Techniques—Guidelines for Cyber Security) confirms the importance of Social Engineering, as a threat.

As defined, “the Cyberspace” appears to mean a complex, highly variable or fluid virtual online environment, and hence it is hard to pin-down the associated information security risks. While a variety of information security risks are connected with “the Cyberspace”, many (such as network and system hacking, spyware and malware, cross-site scripting, SQL injection, social engineering, plus information security issues relating to “Web 2.0,” cloud computing and virtualisation technologies that typically underpin virtual online environments and applications) could be classed as normal or conventional system, network, and application security risks and, in practice, the standard is largely concerned with information security risks associated with the Internet, rather than “the Cyberspace” per se. However, since these risks are already pretty well covered by other ISO/IEC or ISO/IEC information security standards, either published or under development, it is uncertain what information security risks are truly unique to “the Cyberspace.” Risks to virtual assets belonging players of Massively Multiplayer Online Role-Playing Games (MMORPGs) are mentioned in the standard but not directly addressed, for example. Frequent innovation in the realm of “the Cyberspace” makes it especially tough to set international standards in this area and could itself be classed as an information security risk, albeit one not covered by the standard.

Section 7 of the standard distinguishes threats to personal and organizational assets, which appear to boil down to compromises of privacy/identity and corporate information, respectively: there are of course many information security standards covering both aspects. (For some obscure reason, Section 7 also mentions threats to online governmental services and infrastructure including terrorism, although quite what these have to do with “the Cyberspace” is unclear to me since I am not aware of any governments offering virtual environments or MMORPGs, unless perhaps “managing the nation’s economy” is classed as a game!)

Unfortunately, as this is deemed as a human threat, this standard relies on the other ISO/IEC standards to ensure that these threats have been addressed. Hence, organizations may be overlooking the need to protect themselves from Social Engineering attacks but hopefully this oversight may be addressed with the introduction of the updated ISO/IEC 27001/2 standards.

The industry standards listed above target all of the three Information Security domains (technology, people, and processes) that can be applied to protect organizations critical/sensitive information assets that are all key areas of Information Security Management System (ISMS) document sets. For example, the construction of a good ISMS document set is comprised of an overarching Information Security policy that refers to any other policies and procedures (acceptable usage, e-mail, clear desk, malware, etc.) that support the protection of organizations critical or sensitive data assets. Therefore, as Social Engineering is a merge of these three domains that allows an attacker to gain surreptitious access to that data any ISMS that has not included policy and processes is fundamentally flawed.

The development of such policies and procedures must address the attack vectors upon which Social Engineering is created; attacks from two perspectives (as already mentioned, throughout this book), including:

1. Human based

• Impersonation

• Posing as an important employer

• Being a vendor

• Exploiting desktop support

Developing fit for purpose social engineering policies and procedures

The scene has now been set as for why organizations need to address the threats associated with Social Engineering attacks, using a combination of policies, procedures, and awareness training; it is now essential that the correct approach to policy and procedure development is outlined.

So where does an organization start with developing a fit for purpose Social Engineering policy and associated procedures? There are two options:

1. What about buying a number of ready-made policies and procedures? Well, it’s better than nothing but can the Social Engineering policies and procedures written for one business type suit all business types? Certainly not! However, if an organization is uncertain as to the format they can use these documents as the basis from which to build a good set of Social Engineering documents that suit and meet the establishment’s needs.

2. The second option is to start with a pencil and a blank piece of paper to identify the types of Social Engineering attacks and the areas of the business, which could be susceptible to such an attack. The next stage is to sit down with the people employed in the vulnerable areas to get a thorough understanding of the processes they currently employ. This will then form the basis from which to develop any policies and procedures.

People get weighed down in how to correctly structure the documents but in reality an effective policy or procedure is one that works. For example, one that people can easily follow and that is specific to that particular organization; rather than one that is written with good English, is well structured but is as thick as “War and Peace” that no one ever reads or adheres to. As mentioned before, the purpose of such policies and procedures is to formally communicate safe and secure methods of operation.

All the supporting information has now been gathered together that can be implemented into organization’s Social Engineering document sets. Although, the fact that a formal structure is not required, to ensure an organization has an effective document set. The reality is that businesses expect to see formally structured documents. Therefore, an example of the structure and content, but not explicitly that could be included in an overarching Social Engineering Policy is provided below:

• Header:

• Company name and logo

What the document is attempting to achieve?

– Purpose

Provide employees with awareness of the occurrence of Social Engineering attacks

To create specific countermeasure procedures

– Scope

A list of the areas of the business, employees, contractors, etc. for whom the policies/procedures are applicable.

– Types of Social Engineering attacks

A list of the types of Social Engineering attacks that could be pertinent to the particular business.

– Actions to be taken

Detailed guidance to assist employees in appropriate actions that should be followed, in the event of being subject to such a possible attack.

– Enforcement

Details of positive rewards for employees successfully applying appropriate actions to a Social Engineering attack.

Details of negative reenforcement for employees failing to adhere to the policy or procedures.

– Reference documents

A list of policies and procedures that support additional safety and security against Social Engineering.

This provides an insight into the construction of the overarching Social Engineering Policy; however, as already mentioned additional supporting policies and procedures are needed in accordance with the particular threats to an organization. Therefore, as Social Engineering threats to the Help Desk have been identified here is an example of a Help Desk password reset procedure:

Procedure for resetting user passwords

Acceptable sources of requests

Users may only request that their own passwords be reset. If a caller asks for someone else’s password to be reset, the IT Help Desk must ask the caller to get the user account owner to contact them directly.

Requests must be received either in person or via the telephone. Requests via e-mail from someone else’s e-mail address or via fax, text messages, etc., are not acceptable.

Confirm the identity of the caller

If a user attending in person is not known to the IT Help Desk, identification such as a driver’s license should be requested and the fact that this was seen must be logged on the Help Desk incident record.

If the call is received via the telephone, the following steps should be taken to confirm the identity of the caller (if the call is received via an external phone number, either landline or mobile, extra care should be taken):

• If the caller is known, does it sound like their voice?

• If calling internally, check whether the extension number the user is calling from is the one listed against their name in the internal phone directory.

• Ask the name of their manager—check on the intranet for the correct answer.

• If there is room for doubt as to the identity of the caller, ask them to get their manager to send an e-mail authorizing the password reset.

Reset the password

Once the user’s identity has been verified:

1. Change the password to a random sequence of letters and numbers.

2. Tell the user the password there and then they may write it down as long as it is then successfully changed.

3. Get the user to log on and change their password while on the phone.

4. Confirm that they now have access to the network or system.

Password guidance

The following guidance should be given to the user regarding the creation of future passwords.

Choosing passwords

Passwords are the first line of defense for our IT systems and together with the user name help to establish that people are who they claim to be.

A poorly chosen or misused password is a security risk and may impact upon the confidentiality, integrity, or availability of our computers and systems.

A weak password is one which is easily discovered, or detected, by people who are not supposed to know it. Examples of weak passwords include words picked out of a dictionary, names of children and pets, car registration numbers, and simple patterns of letters from a computer keyboard.

A strong password is a password that is designed in such a way that it is unlikely to be detected by people who are not supposed to know it, and difficult to work out even with the help of a computer.

Everyone must use strong passwords with a minimum standard of:

• At least eight characters

• Contain a mix of alpha and numeric, with at least one digit

• More complex than a single word (such passwords are easier for hackers to crack)

Changing passwords

All user-level passwords must be changed at a maximum of every 90 days, or whenever a system prompts a user to change it. Default passwords must also be changed immediately. If it is suspected, or apparent, that a password has been compromised, it must be changed immediately and report any concerns to the IT Help Desk.

Users must not reuse the same password within 20 password changes.

In this particular example, the password reset points to the use of follow up emails, but readers may have noted that this has been identified as an exploitable method of verification so how can this be suitable? It all comes down to the balancing security versus business benefits. Consequently, the weaknesses of formal processes can only be truly identified through appropriate testing and if such a vulnerability is identified an additional measure may be required. Such as the application of the use of a regularly changed authentication passphrase that is only available from an internal location, such as a management restricted area on the companies’ intranet or a restricted folder on the local area network.

All of the above demonstrates the complexities and potential pitfalls associated with people. However, it also demonstrates how the correct application, interpretation and adoption of such a Help Desk procedure can help to reduce the chances of being subject to a successful Social Engineering attack and to identify a potential Social Engineering attack, using this approach.

Summary

This chapter has started to look at how policies and procedures can be hardened in order to provide an adequate level of self-awareness and training to reduce the risk of a Social Engineering-based breach.

The chapter started by looking at the Trojan horse as a real-world example of a Social Engineering episode and then pondered the question of how this risk could have been mitigated through a policy and procedure back in the age of Troy. Two more up-to-date examples were then discussed before starting to look at various industry security standards such as PCI:DSS and ISO/IEC 27001:2013 and how they covered the need for a Social Engineering policy. The chapter finished by providing an example template for such a Social Engineering policy that could be written for the business after first assessing the risk and understanding the real threat of a Social Engineering-based breach to the business.

The next chapter will continue the theme of social engineering defense strategies by discussing awareness and training programs.