Failing to prepare is preparation to fail
As the year draws to a close, it is time for businesses across all industries and sectors to reflect and prepare for the upcoming new year. With this in mind, premier organization and recognized global leader in incident response – Forum of Incident Response and Security Teams (FIRST) has produced 11 vital steps that organizations should take to improve their incident response strategy.
It is highly likely that an organization will face a cybersecurity incident of some sort at some point in its lifetime, regardless of the level of cybersecurity defence in place. According to a global survey[1] undertaken by Marsh in partnership with Microsoft, two-thirds of respondents ranked cybersecurity as a top five risk management priority, but only 19% expressed high confidence in their organization’s ability to manage and respond to a cyber event, and only 30% have developed a plan to do so. Below are 11 steps that an organization should take to become more resilient against an incident.
Planning for a security incident
- Assign a clear incident leader.
During a response, coordination is needed across many teams, including Security, IT, Engineering, Operations, Legal, Human Resources and Public Relations. In most cases, technical response work will not all be conducted by a single team. However, organizations benefit by having one clear authority within the organization who defines the process that will be followed and focuses on planning those interactions ahead of an incident.
- Manage the information gap.
Plan ahead to have a communications lead, who works closely with the incident leader, and works to satisfy third party information requests from across the organization. During an incident, there will be a large set of requests for information, with a small team actually investigating and developing the deliverables. An often-overlooked piece is to record details of each decision as it happens. When you look to perform a post-mortem after the event it can be extremely difficult to recall the exact timeline of the incident. Multiply this with the complexity of many of the incidents we see today and it can become almost impossible.
Your team needs to build relationships with the incident response community. Effective cooperation during an incident is about trust. When an incident strikes, it’s too late to build it. Have your team engage with business partners, national Computer Security Incident Response Teams (CSIRTs) and service providers before you need the relationship. Join relevant organizations in the field, meet their security teams at conferences and industry working groups, or use existing mechanisms such as a vendor review process to determine and track the right points of contact early on.
- Retain external legal, PR and technical support.
There will be technical skills not available to your team. These may include legal, public relations and technical support, such as crisis management or disk forensics. Find a provider for these services and sign a retainer, before the incident strikes.
- Study applicable reporting requirements.
You may have made commitments to your customers on how quickly you’ll inform them when data is breached. Even if you haven’t, various legal reporting regulations are now in effect, such as the GDPR, where organizations typically have up to 72 hours to gather relevant information and report to the appropriate regulator – or the European Union NIS Directive, according to which specific Digital Service Providers must report “with no undue delay”. Work with your legal team to understand each requirement ahead of time, so your incident response process takes them into account.
- Exercise, exercise, exercise.
It’s a common misunderstanding that security exercises are only important once you’ve achieved a certain level of maturity. In fact, exercises pay off from the very beginning. Take a scenario that affected another organization and perform a table-top walkthrough of how your organization would deal with that same incident. At the very least you’ll identify gaps you still have to address. Exercises should be regular and involve a range of participants. It’s important that the senior members of an organization (right up to senior executive management) as well as the technology and other staff participate. The “muscle memory” this will build is invaluable when a real incident occurs.
Responding effectively and managing risk
- Communicate often and early.
When a security incident is known to the public, it’s important to acknowledge it early, even if you can only state you are investigating. This helps ensure that affected parties understand you are aware and working on it and will be a source of information in the future. Providing regular updates helps ensure a cadence, so they will come back at regular intervals and will feel less inclined to go look for information from other sources, which may be inaccurate.
- Be truthful and straightforward.
End users lose trust when communication isn’t clear and understandable, or if they feel you are not expressing what truly happened. Be clear and write to the technical level of your users, but don’t make things sound better than they truly are. When end users are exposed to risk as a result of your breach, say it.
- Don’t lose track of the basics.
“What would have happened if this took place on another system?” is valuable information, but you should first focus on the key questions you need your team to pursue early on. Higher priority questions typically include: “How did the breach take place?” and “What customer data is affected?”. Failing to reach basic agreement on the impact of an incident can cause delays and confusion later.
After the incident
- Study and document your response.
The most important phase when handling a security incident is the “post-mortem”. It’s almost impossible to prevent all incidents from happening, so this is a chance to review why this one took place and identify ways to improve your program. Ask the “Five Why’s”: every time you believe you have an answer to why the incident took place, ask for a deeper, underlying cause, until you hit at least five levels of “Why.” Address all levels, and focus on the deeper, underlying ones, as they will lead to other, future incidents if left unaddressed.
- Never let a good incident go to waste.
There are two positive benefits from an incident: The first is that as it so clearly illustrates both needs and impacts; an incident is often the best time to get additional investment to prevent the next one. Make sure to clearly communicate what your security program needs to be more effective and create follow up plans to get buy-in from senior leadership in your organization. Secondly, every incident you work helps you learn more about your process and your organization; how your systems interact but more importantly, how your people interact.
- Share your learnings.
As a community, we can only become better if we actively share information on the cybersecurity issues we experience. Airlines are so safe exactly because every failure is scrutinised and shared in detail with others, and action plans are made by airlines regardless of who was originally affected. By sharing your learnings, other community members have an opportunity to learn, and the internet becomes a safer place to socialise and do business.
By taking these steps, organizations will be in a better place to effectively respond to a security incident. Finally, think of organizations in the context of a supply chain. Most organizations care about a breach of customer information. But even more persistent and concerning can be the effect of products and deliverables on other organizations. In this position, for instance as a B2B provider selling hardware and software, or providing a service that when interrupted, would impact critical infrastructure, the narrow definition of a data breach may not be the biggest concern and other risks will need to be addressed and analyzed.
FIRST enables incident response teams to more effectively respond to security incidents by providing access to best practices, tools, and trusted communication with member teams. The FIRST community has developed high level documents detailing possible services CSIRTs and PSIRTs may provide. Currently the CSIRT Services Framework is available at version 2.0 and the PSIRT Services Framework at version 1.0.
