How to respond to a security incident

In this blog I would like to outline a process of responding to a security incident, including a breach of personal data. It is intended to be high-level in nature to allow for adaptation to different types of incidents and specific needs of your organisation.

There are many definitions of a security incident out there. I prefer this one: a security incident is an attempted or successful unauthorised access, use, theft, disclosure, modification or destruction of information, or interference with or misuse of information processing infrastructure, applications and data. A personal data breach is one of the types of a security incident which occurs when personal information is subject to loss or unauthorised access, use, disclosure, copying or modification.

Identification and triage

A security incident can be identified through various means and channels. A potential security incident will likely be one or a number of the following:

• One of your employees notices an error leading to a potential exposure of sensitive information (e.g. sensitive information sent to the wrong recipient) or suspicious activity or alerts (e.g. files missing or modified)
• A customer contacts your company through a support channel, email or social media suggesting an issue with their account (e.g. missing or modified information)
• A potentially malicious party contacts your company with a threat (e.g. demanding a ransom, threatening a denial of service attack)

External parties as well as your staff should have a quick and easy way of reporting a potential security incident to avoid customer dissatisfaction, brand damage, litigation, unwanted media attention and regulatory fines. The method will vary depending on your environment but can include a dedicated email address, phone number or collaboration tool channel.

A potential security incident should be validated and its impact assessed performing the following steps:

• Identify whether unauthorised disclosure has occurred and whether it is intentional, inadvertent or as a result of criminal activity
• Identify what type of business sensitive or regulated data is at risk
• Identify the cause and extent of the incident (how much data is at risk? How many customers are affected?)
• Identify the systems involved
• Identify whether there is a risk of ongoing breaches or further exposure of the information
• Identify the extent of the unauthorised access to or collection, use or disclosure of sensitive (including personal) information, including the number and nature of likely recipients and the risk of further access, use or disclosure
• Identify whether the information was lost or stolen. If it was stolen, determine whether the information was a target of theft
• Identify who is affected by the incident (employees, contractors, customers, third parties, etc.)
• Identify if the regulator should be notified

If applicable insurance cover was purchased, the insurance provider should be contacted to support with further activities in line with the policy.

If it is confirmed as a false positive or accepted risk, it should still be recorded for future reference and traceability, but the subsequent steps don’t necessarily have to be followed.

Triaging the severity of a security incident is performed to assess potential impact to your company. It should be performed as quickly as possible shortly after or in parallel with incident identification. Severity might fluctuate as more is known about the incident.

Containment and resolution

A verified incident should be contained to prevent further exposure and minimise further negative impact (e.g. more customer data being compromised). The technology team should drive the engagement and containment process and the business owner involvement is key as containment options might present an availability risk.

In an event of a potential compromise, appropriate actions to contain the incident and limit its impact will depend on the nature of the incident and may include:

• Isolating the activity that led to the security incident
• Blocking an external party from accessing your environment
• Suspending a business/operational process
• Suspending a customer or employee account
• Force a password reset for an affected account
• Disconnecting the affected workstation or host from the network
• Suspending part of or entire infrastructure or application
• Correcting a weaknesses in physical security or logical security
• Taking steps to recover the sensitive (including personal) information, records or equipment from all sources, where possible

Containment may not be possible during some incident scenarios or multiple containment steps may be required as more information about the threat becomes available or if initial attempts are ineffective. 

Once an incident is contained, service restoration can commence. The disaster recovery plan should be invoked where appropriate and this is where your data backups become handy.

If vendor support is required for implementation of the resolution, the vendor should be contacted and details of the incident and the required actions to be undertaken should be shared with the vendor.

Communication and closeout

Communicate the resolution to the external parties affected, if any.

A root cause analysis should be conducted for incident to determine the conditions, activities or gaps in security controls that led to a security incident. The root cause analysis of the incident may indicate that such an incident can be avoided in the future, provided preventive actions are taken.

The root cause analysis report doesn’t have to be complex and different versions may be created depending on the audience. The following questions should be answered:

• What happened?
• Why did this happen?
• Who was affected?
• What was the impact?
• What have we done about it?
• What are we doing to prevent this in the future?

It is also a good idea to include a timeline and audit logs where appropriate.

Recognise that there is an opportunity to improve your product, processes or cross-team collaboration post-incident. You can also use this in your ongoing awareness training emphasising the lessons learned. 

Security posture should be continually improved in line with the business risk appetite. Use this to implement additional pragmatic and prioritised security controls to protect the most important assets.

Every employee should be encouraged to identify product and process improvement opportunities leading to enhanced security and data protection. 

It’s not possible to be 100% secure. Security incidents should be anticipated, response procedures developed and periodically reviewed and improved.

Remember, a culture of trust and transparency is essential to timely identify, contain and resolve security incidents. Mistakes can happen. See something – say something; no matter how small you think it may be! Don’t ignore it.