Home > David Stubley

Keeping cool in a crisis – Incident Response

September 15, 2015 by

Back in January 2015, SC Magazine published my article on keeping cool in a crisis. With the ever-increasing portfolio of breached organisations, maybe it is time to revisit that advice again?

Cyber-Attacks

In today’s world it is inevitable that organisations will suffer cyber-attacks. When an organisation is attacked their incident management procedures will be key in sustaining the company through the crisis. However, with large scale breaches continuing to cost organisations and individuals dearly as well as hit the headlines, more could be done to improve incident management procedures.

Preparation

Preparation is key to any planned response but it can be difficult for organisations to anticipate what will be required in the event of an incident. For many organisations, incident response procedures plan to tackle scenarios identified through business continuity risks or following internal incidents. Procedures are often completed or reviewed as part of an annual business planning process by those with a focus on the business. This results in an introspective focus that can leave incident management procedures lacking.

An introspective focus does not effectively anticipate the full suite of scenarios that an organisation may face in responding to an incident. Such an internal emphasis does not take into account the evolving threat landscape or the changing external environment in which the organisation operates. Without placing incident response measures in this dynamic external context, organisations may find their response measures are lacking in the face of current attacks.

Learning from others

Of course, gaining information about factors external to your organisation, such as threats, is often an insurmountable challenge, but organisations have an opportunity to carry out reviews of the breaches of their competitors or other organisations similar to their own.

Groups conducting attacks, whether for financial gain or other motives, will frequently use the same methods of compromise. This fact has clearly been demonstrated in the recent attacks on the electronic point of sale systems in the US retail sector and the on-going use of targeted phishing emails to gain access to corporate networks. There are also previous attack trends of utilising SQL injection or memory scraping malware as attack methods to draw upon as examples of attack methodologies being reused. The use of similar methods by attackers means that organisations have an opportunity to identify attack approaches and vulnerabilities that could be applicable to them. Organisations should therefore look to use the experiences of others within their sector to enhance their own incident management procedures.

While it is accepted that the full details of the incident will not be publicly available, many industries have information sharing forums and employees build up relationships with their counterparts in other organisations. It is likely that an organisation will be able to garner sufficient information to identify vulnerabilities exploited by attackers and key attack vectors. This information can be used to review the incident and determine if the organisation is itself vulnerable to such an attack. In short organisations should conduct a post-incident review of the incidents that impact on other organisations.

Using the information available, an organisation can identify potential attack scenarios and whether they are likely to be breached as a result. By playing out these scenarios within the context of their own environment, organisations will be able to identify if they have compensating controls in place or where they may be required. Once compensating controls are in place organisations can then test their effectiveness in the context of these scenarios and therefore gain assurance that they are not exposed to the attacks their peers have suffered.

This process may be assisted by experts such as security testers, ordinarily external to the incident response planning process. Penetration testers can provide insight into the scenario planning and assessment process. By the very nature of their jobs, penetration testers are often skilled at identifying and understanding attack vectors. By using such experts, organisations will be able to add more rigor to their assessment of scenarios as well as challenge preconceptions. Ultimately this will result in a more resilient approach to incident response.

In summary

Reviewing the incidents of others will enable organisations to anticipate the types of attacks they may be vulnerable to and prepare for them, ultimately keeping cool in a crisis.

By keeping abreast of the threat landscape, spotting trends within relevant industries and reacting to the external environment, organisations will be able to plan effectively for incidents, if not reduce the likelihood of a successful attack. Should an attack occur, organisations will have more resilient incident response measures in place with which to tackle these anticipated threats. By learning from others’ misfortunes organisations may be able to avoid the pain of going through a similar experience.

Click here to find out more about our approach to incident response.

Cryptic message of the day

July 21, 2015 by 
MjAxNS0wNy0yM1QwMDowMTowMCswMTowMCAweDM3CTB4NDUgCTB4NWYgCTB4
MzUgCTB4NTkJMHg1MgkweDUzCTB4NWYJMHg0ZgkweDRjCTB4NDQJMHg1Zgkw
eDU0CTB4NGYJMHg0NAkweDQxCTB4NTk=

Cyber Essentials

February 20, 2015 by

CE_logo_affiliated_hi_res

 

 

 

7 Elements achieves Cyber Essentials Certification body status.

7 Elements, are now a certification body able to deliver Cyber Essentials (CE) and Cyber Essentials Plus (CE+) engagements for organisations that are aiming to meet this standard.

The move comes as 7 Elements looks to expand its service offering to include a cost effective security solution to all clients which now includes conducting this government approved assessment. The CE and CE+ accreditation has been developed as a method to significantly reduce business vulnerability at an achievable cost. More information on the scheme can be found here.

Passphrase Guidance

February 11, 2015 by

A secure and functionally usable form of password authentication is passphrases. Passphrases are a combination of words that can be entered as a password. Recent attacks that have resulted in password leaks provide a wealth of knowledge about common password patterns. Passphrases provide a more secure but user-friendly alternative to traditional passwords.

A well-formed passphrase can be far more holistically secure than other password authentication alternatives. This additional security stems from maximising human memorability and cracking complexity in concert with minimising selection guessability, observability and recordability. Passphrases increase usability as they can contain special or unique significance to the user, are more memorable and their length and form can provide significant layers of complexity. Passwords are much easier to crack than passphrases, regardless of their cryptographic protocol. In addition, cracking passwords is becoming progressively easier by harnessing the power of cloud computing and new technology. The approximate time required to brute-force a complex eight character password lies between seconds and days for most cryptographic protocols, whereas for passphrases this time increases exponentially, making passphrases significantly more secure. Passphrases are therefore computationally more challenging to crack than passwords.

Passphrase Generation Recommendations

The following factors are recommended in the generation of secure passphrases.

• Use three or more uncommon words, for example “steep alphabet dawn win”.

• The phrase should not be common, for example a well-known saying or from a film or book.

• Use spaces or special characters between words to further enhance the security. For example, “steep-alphabet-dawn-win” or “steep!alphabet-dawn!win”.

• As with passwords, do not enforce excessive expiry of passphrases to avoid user fatigue that may result in users employing insecure coping strategies that ultimately degrade and diminish security. Enforcing new and distinct passphrase selection every three months should meet the needs of a risk averse organisation.

• A limit of 32 characters will give users freedom to create more secure passphrase word combinations, while not putting excessive demands on existing systems to maintain the data or computational tasks.

• As with complex passwords, secure passphrases should consist of at least two of the following elements however, users should be free to choose from any of these categories:

  • Uppercase letters
  • Lowercase letters
  • Numbers
  • Punctuation marks
  • Mathematical or other conventional symbols
  • Spaces

Passphrase Security Augmentation Elements

In developing a passphrase policy it is crucial that the system is practical for users. This can be achieved by ensuring that verification methods impose a minimal burden on users. To assist in this the following factors should be considered in developing a passphrase policy.

  • Memorability: Passphrases must not made overly complex as to be difficult to recall.
  • Guessability: Passphrases should be hard to guess. This means family, colleagues, friends and social engineers should not be able to guess passphrases by exploiting the varying degrees of intimacy with a passphrase holder. Passphrases should not contain meaningful dates, pet names, addresses, hobbies, interests or otherwise.
  • Observability: Passphrases should be entered easily. If a passphrase is overly time consuming to enter this enhances the ability of shoulder surfers to accurately observe password entry.
  • Recordability: Passphrase entry must be secure. Users should become naturally wary of highly observable key press combinations for instance, the passphrase “qwe rty uiop” is highly recordable due to the sequential means of entry on standard keyboards. As characters are being typed into the passphrase field they should also be immediately obfuscated to avoid screen recorders from recording passphrase input. The workstations in use must also be secure to ensure keyloggers are not in operation.

For more guidance on passwords, please visit the following link.

Password Guidance

February 11, 2015 by

Most organisations utilise passwords as a method of authenticating users as part of their access control solution for their systems. 7 Elements have often found poor password policy or insufficient policy enforcement can be a severe point of failure in an otherwise secure system. For password authentication to be effective the security provided by using passwords must remain robust regardless of persistent attacks originating from either human or computer sources. Organisations can take steps to ensure that the passwords used to access their systems are sufficiently strong by employing a robust password policy. This guidance lays out some key steps organisations can take to develop a robust password policy and therefore help ensure that strong passwords are used on their systems.

Password Formation Guidance

To ensure that users have strong passwords the following basic guidelines on how passwords are formed may be used as part of a robust password policy. A robust password policy should stipulate that a password has the following properties.

• Passwords should be a minimum of nine characters long. They should also be sufficiently complex to offset the likelihood of a successful brute force attack or guessing of the password.

• Passwords should not contain personal information such as names, addresses, birthdays, car registrations, ID numbers etc.

• Complex passwords should consist of at least four of the following elements however, users should be free to choose from any of these categories:

  • Uppercase letters
  • Lowercase letters
  • Numbers
  • Punctuation marks
  • Mathematical or other conventional symbols
  • Spaces

• Use of common passwords should be banned. Common passwords can be compiled from the many repositories of passwords released after major account hacks.

• A history of old password hashes should be kept. This should be used to prevent users from re-using their previous passwords.

• Accounts should be locked out after a number of failed access attempts. This is ordinarily set to three attempts. This helps to reduce the likelihood of a successful brute force attack against accounts.

• Passwords should be changed at regular intervals. However, organisations should be aware that constantly enforcing password changes may cause users to develop password generation fatigue. This may result in users employing insecure coping strategies, such as writing passwords down or using non-complex passwords. This could eventually degrade the security of password authentication.

• Password reuse should be limited so that unique passwords are not used across a single user’s multiple accounts. Furthermore passwords across accounts should not be similar permutations of the original password.

Password Security Augmentation Elements

In developing a password policy it is crucial that the system is practical for users. This can be achieved by ensuring that verification methods impose a minimal burden on users. To assist in this the following factors should be considered in developing a password policy.

• Memorability: Passwords must not be so complex as to be difficult to recall.

• Guessability: Passwords should be hard to guess. This means family, colleagues, friends and social engineers should not be able to guess passwords by exploiting the varying degrees of intimacy with a password holder. Passwords should not contain meaningful dates, pet names, addresses, hobbies, interests or otherwise.

• Observability: Passwords should be entered easily. If a password is overly time consuming to enter this enhances the ability of shoulder surfers to accurately observe password entry.

• Recordability: Password entry must be secure. Users should become naturally wary of highly observable key press combinations for instance, the password “qwerty” is highly recordable due to the sequential means of entry on standard keyboards. As characters are being typed into the password field they should also be immediately obfuscated to avoid screen recorders from recording password input. The workstations in use must also be secure to ensure keyloggers are not in operation.

• Complexity: A minimum password length combined with relative complexity is essential. Passwords do not need to be overly complicated to remember but instead fortified through the discussed elements of augmentation to prevent the success of current and emerging password hacking and encrypted hash cracking techniques.

For a more robust approach to password management, take a look at our guidance on using a passphrase.

Incident Response – keep cool in a crisis

January 22, 2015 by

SC Magazine recently published an article by our CEO, David Stubley on the topic of how to keep cool in a crisis.

“Learn from the misfortunes of your peers and prepare to defend against repeat use of the same cyber-attack techniques as part of your defence planning” advises David Stubley.

The full article can be found here and a link to our incident response services can be found here.

Forensic v’s Tactical

January 22, 2015 by

Forensic v’s Tactical – Acpo Guidelines Computer Evidence

A key consideration for any organisation responding to an incident will be the decision about whether to take a forensically sound approach to data acquisition and interrogation. The purpose of forensics is to gain legally permissive evidence from computers and digital storage media. Organisations should therefore take the decision at an early stage whether they may wish to take the case to court or involve law enforcement. Should this be the case organisations should use an approach that meets the evidential handling requirements of the local legal jurisdiction of the incident. In the UK the foundations for this approach have been well documented by the Association of Chief Police Officers (ACPO). More information can be found on their website:

http://www.acpo.police.uk/documents/crime/2011/201110-cba-digital-evidence-v5.pdf

Taking a forensically sound approach can limit the options available to you in responding to an incident. If your organisation only needs to understand the facts around an incident and has no requirement to involve law enforcement, a more tactical approach can be taken.

Taking a tactical approach broadens the tools and overall options available as part of an incident response. It will enable your organisation to gain a rapid understanding of the size and complexity of the event.

Cyber Security breakfast meetups for SMEs

January 15, 2015 by

Our CEO David Stubley will be presenting at the upcoming Cyber Security breakfast meetups for SMEs (Edinburgh) event on the 29th January at 8am.

During this talk David will explore the question of “What is Cyber Security?” Using real life case studies David will provide insight into the current and future threats faced by UK businesses.

The event will be held at New Register House in Edinburgh, for more information and to book a place, click here.

ScotlandIS Ecommerce Masterclass: Security and Legal

January 15, 2015 by

Our CEO David Stubley will be presenting at the upcoming Ecommerce Masterclass: Security and Legal event being held by ScotlandIS. At the event David will cover the current threat landscape and provide real life examples of online attacks.

The event will be held at the Bonham Hotel in Edinburgh on the 29th January 2015 at 2pm.

Matthew Godfrey-Faussett, Partner, IT & Healthcare at Pinsent Masons will also present on the legal aspects associated with information security and data protection.

For further information and to book a place, please visit ScotlandIS.

Threat Modeling and Security Testing within Virtualised Environments

January 11, 2015 by

Our latest blog takes a look at threat modeling and security testing within virtualised environments.

The continued deployment of Virtualisation within existing network architectures and the resulting collapse of network zones on to single physical servers are likely to introduce radical changes to current architectural and security models, resulting in an increased threat to the confidentiality, integrity or availability of the data held by such systems. Recent experience has already shown that the use of Virtualisation can introduce single points of failure within networks and successful attacks can result in the ability to access data from across multiple zones that would have historically been physically segregated.

To deal with this change will require a corresponding change to the architectural and security models used and a full understanding of the associated risks/threats that Virtualisation brings.

The purpose of this post is to set out areas that will need to be explored in order to gain assurance that Virtual Environments do not introduce or aggravate potential security vulnerabilities and flaws that can be exploited by an attacker to gain access to confidential information, affect data integrity or reduce the availability of a service.

Virtualisation raises lots of questions, including:

  • Will the Virtual Environment breach existing security controls that protect the existing physical estate? If so, how?
  • What additional controls will be required?
  • Does the proposed change exceed risk appetite?

Threat Modeling

To explore these questions, a comprehensive threat modeling exercise should be undertaken to look at the level of risk and threats associated with Virtualisation. This exercise should be tailored to be specific to the environment / business market that you are in (for example – financial organisations will need to be aware of regulatory requirements such as PCI-DSS which could impact on the use of virtualisation.)

A detailed threat model will aid in the development of a robust architectural model as well as feed in to any assurance work conducted. Such activity should be completed at the design stage and, failing that, at the latest prior to any deployment, as reviewing potential threats after deployment can result in costly redesign and implementation work.

Any risks and potential vulnerabilities that are identified during the threat analysis phase should be mitigated with appropriate security controls and built in to the design prior to implementation. Security testing should then be arranged to verify that the risks have been effectively mitigated.

Of course, in some instances there will be environments where threat modeling is not part of usual business security practice. Where there this is the case, any team conducting assurance activity should complete a tactical threat modeling exercise as part of their engagement and to inform the direction and context of any testing / recommendations. A tactical threat modeling exercise is one where less time and effort is applied and is more focused on a ‘how would we attack this system’ basis. Such an approach will take into account possible attack scenarios and is likely to form the basis of a penetration testing scoping exercise.

Technology and functionality changes fast and this can lead to a change within the attack surface of an organisation. Threat assessments should be an on-going activity, even a tactical threat assessment on a regular basis to take in to how changes in technology deployed affect the efficiency of existing controls will aid in the organisational understanding of the threats posed and may help to avoid a costly breach or loss of data.

Example Questions

Questions that should be asked as part of a threat mapping exercise:

How will Virtualisation impact the patch management process?

  • Consideration will be needed in terms of patching and virus control being in a centralised environment. Virtualisation introduces the risk of out-of-sync Virtual Machines existing within the network. As an example, introduction of VM snapshot/rollback functionality adds new capability to undo changes back to a “known good” state, but within a server environment when someone rolls back changes, they may also rollback security patches or configuration changes that have been made.

Is there sufficient segregation of administrative duties?

  • Layer 2 devices are now virtualised commodities; this could lead to a new breed of ‘virtualisation administrators’ who straddle the role of traditional network / security engineers and thus holding the keys to the virtual kingdom. SANs Virtualisation admins will be responsible for assigning storage groups to specific VMs, so again they’re may have rights across that network divide as well, essentially making them Network/Server/Storage admins from a rights perspective.

Is there a suitable security model in place?

  • Where multiple user groups / zones or where different risk appetites exist within an environment then separate security models should be created to contain breaches within one zone and help protect against know attack types.
    No single security model should be applied across all groups or zones.

Is there suitable resiliency built in to the environment?

  • What level of resiliency is required in terms of disaster recovery / denial of service mitigation and are they in place and more importantly are they effective?
  • Is there sufficient Disaster Recovery built in to the environment?

How does the virtual environment interact with existing network architectures and authentication mechanisms?

  • Does this introduce a weakness to the environment that could be utilised by a malicious party?

Has a design review been completed?

  • Virtualised environments are complex, as such during the design stage effective and detailed review of the proposed design should be conducted to aid the development of a more robust and secure system. The output from threat modelling should be incorporated in to this review to ensure that a suitable design is implemented.

Are you outsourcing any component of the virtualised environment?

  • Third party relationships have become a major focus over the last few years with several high profile data loss incidents in the media. The contract with the vendor should include appropriate clauses to ensure data security, while formally enabling testing and remediation activities. More specifically the contract should facilitate regular security testing.
  • Does the outsource contract allow you to define physical location of your data? The jurisdiction can affect not only the threat model, but also your handling of risks.

To Close

Any security testing conducted against the virtual environment should follow detailed and industry standard methodologies (OWASP, CREST, OSSTM ) and comprise both infrastructure testing / build reviews and security device configuration reviews (i.e. firewall rule sets). However specific testing to break out of the virtual environment will need to be included as the ability to access the restricted hardware layer will result in data leakage and potentially the ability to compromise any other attached Virtual Machines (gaining unauthorised access to user data and systems).

Essentially many of the areas of risk which are specific to virtualization arise from the capabilities which it provides. For example virtualisation allows for the hosting of systems from different networks on a single physical server. This can have benefits in terms of reduced costs/datacentre space requirements, but also introduces a new perimeter between networks, the Virtualisation hypervisor. So if there is a security issue which affects the hypervisor it can allow attackers to jump from one network zone to another, effectively bypassing existing security controls such as Firewalls.