Hands-on Incident Response and Digital Forensics

Mike Sheward

• Editore: BCS, The Chartered Institute for IT
• Anno: 2018
• ISBN:
  9781780174228
• Argomento: Law
• Categoria: Forensic Science

Incident response is the method by which organisations take steps to identify and recover from an information security incident, with as little impact as possible on business as usual. Digital forensics is what follows - a scientific investigation into the causes of an incident with the aim of bringing the perpetrators to justice. These two disciplines have a close but complex relationship and require a balancing act to get right, but both are essential when an incident occurs.In this practical guide, the relationship between incident response and digital forensics is explored and you will learn how to undertake each and balance them to meet the needs of an organisation in the event of an information security incident. Best practice tips and real-life examples are included throughout.

PART 1
INCIDENT RESPONSE

1 UNDERSTANDING INFORMATION SECURITY INCIDENTS

Information security is a broad topic, with many subdisciplines. You could work in application security, network security, compliance, forensics or a security operations role, or be a lawyer specialising in information security and data privacy. All of these information security roles appeal to people with different skill sets, experience levels and interests.

An organisation can have one person spending some time on security where possible, or a dedicated security team (this could be as large as several thousand full-time employees), with budgets that vary just as broadly. Despite all the differences between these roles, and the resources available to a given security team, one event that binds us all together is the security incident. We’re all working to reduce the likelihood of them occurring in the first place, and to minimise the impact they cause when they do happen. In this chapter, we’re going to be looking at what exactly makes a security incident a security incident, common methods of detection, and why they will continue to occur.

WHAT IS AN INFORMATION SECURITY INCIDENT?

Before we can respond to, or even attempt to plan for, an information security incident, we must first define what exactly an information security incident is. Various standards and publications have their own definition, but many of these definitions are variants of the definition afforded by NIST (National Institute of Standards and Technology) Special Publication (SP) 800-61, Computer Security Incident Handling Guide:

A security incident is the act of violating an explicit or implied security policy.

In this book we’ll be using this NIST definition of an information security incident.

The beauty of this definition is that it can be applied globally to any organisation, but by referencing a security policy it accommodates the significant differences between individual organisations and their risk profiles. For example, at most Silicon Valley start-up offices you’ll see people using their smartphones freely in their work areas without issue. Doing so at the office of a defence contractor handling classified information would very likely be considered a serious security incident. The same activity, in two different environments: one is acceptable, the other is a security incident. Policy is the differentiator.

This should serve to reinforce the importance of security policies for all organisations, no matter the size or industry. After all, you can’t take action against someone for violating a policy if there aren’t any policies for them to violate. The first step in creating an incident response plan should be revisiting other information security policies, first to make sure that they are in place, and secondly to ensure that they are up to date.

TYPES OF INCIDENT

Although the detail of what makes a security incident a security incident may vary from organisation to organisation, we can still classify several types of security incident that are universally considered as such.

At the highest level security incidents fall into two categories. The first of these categories is incidents with internal origins, meaning an incident caused by an insider to an organisation. An example of this would be an employee mishandling data, either deliberately or accidentally. The second category is incidents with external origins, meaning, as you can probably guess, an incident caused by an outsider to an organisation. An example of this type of incident would be if a user is phished by a malicious attacker who goes on to use stolen credentials to obtain unauthorised access to data.

All security incidents are sensitive matters, but some are more sensitive than others. The external versus internal classification scheme also serves as a guide to the level of confidentiality that should be applied to an incident. As a security incident handler, you will likely have access to a great deal of sensitive information. This is often a necessary side effect of being effective in detecting security incidents. Given that internal security incidents often involve the actions of a single employee, they are typically much more sensitive and are treated on a ‘need to know’ basis. Simply put, this means that only the people who ‘need to know’ the details of the incident will be informed. Conversely, if an external attacker defaces a web page, the chances are that more people will be involved in the clean-up operation, from both technical and public relations perspectives, and therefore more people will ‘need to know’.

Let’s run through some examples of incidents that fall into these two categories.

Internal incident types

In information security it is often said that your people are your greatest asset, as well as your greatest risk. The types of security incident caused by insiders to an organisation can range from innocent mistakes made while trying to do the right thing to purposefully malicious actions designed to cause harm.

Inappropriate data handling

Data is the lifeblood of most organisations: payment card data, healthcare data, customer data, analytical data and financial data, to name but a few types of the stuff. With data come various rules and requirements for how it is handled. For example, in the case of payment card data the Payment Card Industry Data Security Standard (PCI DSS) rules supreme; this contains a number of requirements an organisation must meet if they wish to handle credit card numbers and process payments.

General legal requirements for the handling of data about individuals, such as the Data Protection Act (1998) in the UK and its Europe-wide replacement that took effect in 2018, the General Data Protection Regulation (GDPR), contain provisions and penalties for non-compliance and must be adhered to.

An organisation may also have certain contractual requirements it must meet when handling customer data, for example a requirement not to share customer data with a third party for analytical purposes.

If any of these industry, legal or contractual requirements are violated by an insider at an organisation, either intentionally or accidentally, this could constitute a security incident. Mistakes such as storing sensitive data on removable storage media without proper encryption are more common than people would like to admit, and could be highly damaging to a business.

In recent times, the rapid growth of cloud services has led to some significant data handling mistakes as operators get to grips with doing things in new ways. There have been many reported cases of massive data files being made accessible to the entire internet because an incorrect permission setting was being used on the cloud storage service they were being stored in.

‘Shadow IT’ is another trend that can lead to this type of security incident. People get used to using a service personally, for example using Google Drive to store files, and want to use it for work too. Rather than getting approval from an IT authority within the company, they take the path of least resistance and just use the service anyway. Without the appropriate security, compliance and legal review and oversight, this can lead to significant problems for an organisation.

Mishandling security credentials

Credentials, such as user account names and passwords, uniquely identify a user within an organisation, and are all that stand between the user and the data they are allowed to access to be able to do their job. Despite this, people commonly mishandle their credentials. Remember, people are people, and people make mistakes (this is going to be a common theme in this book!).

The improper storage, transmission and disclosure of passwords are significant challenges for any organisation. As an example, many have dealt with employees sharing passwords with fellow employees while on holiday to facilitate some type of access to cover a given task.

Service accounts are user accounts that are used by computers to log in to other computers to perform a function. An example of this would be a service account used to deploy a piece of software across every machine on a network. Service accounts frequently have elevated permissions when compared to the accounts used by their human counterparts, so are a particularly enticing target for an attacker. It is for this reason that service account passwords should be securely shared between the systems administrator and the team requesting the account. All too often, these passwords are shared via instant message or email rather than a secure password vault tool.

A lost, stolen or otherwise mishandled set of credentials should always be treated as a security incident.

Acceptable use policy violations

Organisations leverage acceptable use policies to govern what employees can and cannot do when using their computer equipment. This can be highly important in creating a safe work environment for everyone. Common examples of things that are prohibited by acceptable use policies include:

• accessing pornography using work computers;

• illegally downloading copyrighted materials;

• sending abusive emails to others using work email systems;

• installing hacking tools or malicious software on the computer;

• disabling security features on the computer such as antivirus protection or encryption.

A violation of an acceptable use policy can be considered a security incident.

Unauthorised access

Sometimes, an insider can leverage their access, or the access afforded to a fellow employee, to obtain data they are not normally authorised to obtain. For example, why would someone in the sales department need access to another employee’s payroll information? There are various malicious motivations that may lead to someone obtaining unauthorised access to data, and there are many different ways that it can happen. Sometimes it can even happen accidentally.

If unauthorised access to data is detected then that is a security incident, and it must be treated as such to ensure that any follow-up actions needed to prevent a repeat incident are conducted.

It is also worth noting that unauthorised access incidents can also exist in the physical realm. Unauthorised access to a data centre could lead to unwanted physical access. If a malicious attacker has physical access to a server, the chances of being able to successfully protect it are greatly reduced.

External incident types

Every single business, across every type of industry, should consider themselves a target for malicious external actors leveraging technology to cause harm. When discussing what motivates those outside a business to break in, common themes include financial motivators, intellectual property theft, data exfiltration and compromise of IT assets for reuse in other cybercrimes. In other words, there is no shortage of reasons why, and given the amount of interconnectivity in the modern world, there is no shortage of potential attack vectors for them to exploit.

A hacking attack against a web application or network

This is the ‘classic’ incident. A malicious actor finds a vulnerability in a web application, then exploits the vulnerability to compromise the application. From there, depending on the motivation of the attacker, the outcome could be something as simple as website defacement, perhaps in an act of hacktivism,¹ or something as complex as establishing a persistent presence to be able to steal credit card information.

There are various types of vulnerability that could be present in a web application, and we’ll look at these in more detail in the incident response process and network forensics section of Chapter 11.

Phishing or spear-phishing attack

This is the most common method for an attacker to gain access to an organisation. Phishing attacks are dirt cheap, require minimal technical skill and rely on the omnipresent trusting nature of humans, particularly those who are less technically savvy.

In a phishing attack, the victim is sent a nefarious email that is crafted to look like it is from a trusted source. This could be a bank, a government department or even a social media site. The email will usually indicate that something requires the victim’s action to resolve promptly to avoid some sort of disruption to their daily lives, usually involving money – ‘Your bank account is about to be frozen’ or ‘we’re issuing you a fine’ are common examples. The resolution requires the victim to log in to a fake version of the site that allegedly sent the email, and in doing so they ...