5 Reasons to Respond Quickly to a Cybersecurity Breach

Practices such as tabletop exercises simulate stressor events, such as data breaches, without impacting the real world.

While it may not be everyone’s coveted learning opportunity, in a real stressor event, companies are looking for substantive answers and solutions so that the security failure that caused the data breach or stressor event is more likely to cause it. is systemic or a point-in-time instance. , does not occur again.

There are immediate steps to take after a breach occurs, some of which are captured in a recent analysis by my colleague Frank Domizio. The first days and weeks after the event should, of course, focus on immediate containment, recovery, and continuation efforts.

After that, you will have a great opportunity to learn what really happened and how you can prevent it in the future. This analysis explores different approaches to analyzing security control failures and ultimately using that knowledge to strengthen your defenses. Learn about the five reasons, black box analysis, and a practice called retrospectives.

5 why why

The 5 Whys technique is a root cause analysis technique and is often used in the context of postmortem analysis. This is done by continuing to ask “why?” Dig deep into the root cause. When you do a why-why analysis, things can escalate quickly. 1 reason turns into 5, 5 turns into 15.

Here’s what the five reasons (along with potential answers) look like in action, using an example of an exploited Structured Query Language (SQL) injection vulnerability that caused a security incident.

• Why was there an undetected vulnerability in the production version of the web application? It was not detected in a recent penetration test.
• Why were no vulnerabilities identified in recent tests? All penetration tests were short-term, time-bound efforts and did not cover the vulnerable areas of the application.
• Why were all the tests timeboxed? Lengthy penetration testing is much more expensive than other forms of vulnerability identification.
• Why hasn’t the team invested in other forms of vulnerability identification like static analysis? The team did not have the resources available to support this type of analysis.
• Why can’t team members support other forms of analysis? No one has experience in these areas and we have not yet invested in training along these lines.

Whoever leads the postmortem process should determine the scope of the investigation. I believe it’s worth an initial very broad sweep to identify as many potential failure conditions as possible. Then follow up with a more focused investigation of the root cause, digging as deep as possible into the reasons. Perhaps focus on where you have more control over potential fixes. Ultimately, understanding failure modes or risks should be combined with intentions and plans to fix them.

black box analysis

The concept of black box analysis comes from the airline industry. There, black box analysis is an intensive data-driven study of telemetry captured by an aircraft black box after a failure or loss event. This type of analysis can be classified as a data-driven post-mortem, looking for correlations in the available data that may have contributed to the failure event.

The cybersecurity equivalent of black box thinking considers the following types of data:

• Leading indicator metrics such as patch frequency. Privilege spread across the environment. Vulnerability reports from outside the security team.Level of developer involvement, to name a few
• Security telemetry that happens just before, during, and after a security event.
• Market or regulatory dynamics that occur before and after an incident.

retrospective

Retrospectives are a commonly used tool in agile software development, but they are also useful in security settings. A retrospective is a group activity that brings together various team members to identify a thematic issue about what went well and what didn’t. Retrospectives can reveal different opinions and perspectives on failure. There are many different ways to conduct retrospectives, but I have always found the following to be helpful.

• Organize input from team members by theme (predefined or created with input)
• Assign an owner for further investigation
• See if the room is attended by the right people and if more structured learning is needed

Using predefined prompts during retrospectives helps structure the feedback that is collected. Retrospective themes related to cybersecurity include:

• tools/techniques
• business process
• Communication within the security team
• Communication with other teams
• Dependence on third parties

in conclusion

Beyond the three techniques outlined in this analysis, there are many other ways to build post-compromise learning. However, the one described above provides a good starting point. A deeper understanding of what went wrong and how it happened in the context of a security incident can help you adapt your environment and team to prevent similar incidents in the future.