What coming-of-age films can teach us about incident response

I grew up in the 90s, when coming-of-age films provided therapeutic insight for handling the uncertainty and awkwardness of growing up. In fact, such films were to me what the internet is to younger generations: a library of knowledge, discourse, and documented situations that—for better or worse—lead to growth and change.

Now, as a 30-something security professional, I can’t help but recognize some thematic parallels between the wisdom from those coming-of-age blockbusters and Lessons Learned, the final phase of the SANS Incident Response Cycle (aka PICERL).

At its root, the film genre is about elevating one’s understanding and awareness while attaining a new level of maturity. Likewise, Lessons Learned—in the context of incident response—is about reflecting on an incident and working to shore up systems and processes in an effort to prevent something similar from happening again.

What’s so cool about Lessons Learned?

Simply put, Lessons Learned is one of the most important phases of PICERL, yet arguably the most overlooked, largely because it’s inherently retrospective and labor intensive: post-incident report, stakeholder meeting, closing the loop with threat intel, updating processes and procedures, etc. In a world in which adversaries are always on the move, many companies feel like this process takes time away from manning the frontlines.

But, they’re missing the mark. This phase of reflection on the how and why of an incident will ultimately provide insights and improvements that’ll help tune defenses and inform decisions; all while maturing your security posture along the way.

So, in an effort to illustrate the value of this phase, I’m excited to share five sequential similarities I’ve drawn from classic coming-of-age movies that are emblematic of the wisdom that can be gleaned from the final phase of the SANS Incident Response cycle.

DISCLAIMER: We by no means condone all of the messaging portrayed in the following films (some of which have aged better than others). That said, they do offer up key takeaways that can certainly be applied to Lessons Learned.

The downfall

The Sandlot (1993)

Every coming-of-age story hinges on a catalyst for change, a downfall of sorts. Imagine that the unthinkable happened: your company fell victim to Conti ransomware. Your encrypted data is the signed Baby Ruth ball, your network is the fence, and the adversary is The Beast.

At this point in the incident, you’ve probably already isolated infected systems, contained the threat, and are working to assess the damage and eradicate the threat. While this is still an active incident, the foundation of a meaningful Lessons Learned is established, even amid the chaos. Believe me when I say: documentation is everything when it comes to a major incident. Noting the details of who, what, where, and when will set you up for a more organized recovery and post-incident workup. It could also mean the difference between a follow-on attack or shored-up defenses. Don’t let contemporaneous documentation fall to the wayside!

Meeting of the minds

The Breakfast Club (1985)

You’ve just wrapped up the recovery phase. The impact was substantial. Your company decided not to pay the ransom, but restoring from backups was not as simple as planned. While it may not seem like it, there is hope for a better future ahead.

Now is the chance for your internal IR team (i.e., SOC manager, incident handlers, analysts, IT admin, etc.) to come together and debrief. This is an opportunity to verify the attack timeline, discuss response inefficiencies, come to a consensus on what the heck happened, and most of all, determine how it can be prevented.

Use the incident report—which includes details gathered and actions taken during the incident—as a guiding light. Key aspects of the report should include the four W’s (mentioned above) and pertinent insights that could lead to preventing this type of attack moving forward. The goal is to set the tone for an open dialogue about the incident and gain a better understanding of vulnerabilities, the adversary, and ways to improve collection and detection. This internal session should be held prior to holding a Lessons Learned meeting with stakeholders. If misfits from The Breakfast Club can do it, you can too!

The epiphany

Back to the Future (1985)

No, not all epiphanies come with a DeLorean that doubles as a time machine. In the context of IR, however, great insights and solutions do come in the form of Lessons Learned meetings, which involve the core security team as well as leadership and external parties. Per industry best practice, this meeting should be held no later than two weeks after the initial incident. You might be tempted to simply shoot off an email to stakeholders, but let’s be honest: nothing great has ever taken place over email. Instead, make it a priority to schedule this meeting for the benefit of your stakeholders, your team, and your reputation.

Provide a summary of the incident report, and be transparent about recovery efforts. Ransomware recovery times do vary, so acknowledging up front where you are in that process will go a long way. You’ll also want to provide details on proactive security measures moving forward such as increased monitoring, performing daily backups, and threat hunting. When all that is said and done, open up the floor to give the stakeholders a voice. What are their concerns? A simple forum such as this can lead your security team to identify opportunities for additional training and tools to address deficiencies. Moreover, it can help inform necessary changes to processes and procedures moving forward.

The makeover

Clueless (1995)

By now, you’ve made it through the recovery process and are well into post-incident activity following the big meeting with stakeholders. Now is the time to harvest the value from that meeting and adopt recommendations and necessary improvements. The goal: identify, implement, test, and deploy.

Perhaps you discovered—by way of open discourse—that blocking a legitimate system binary (e.g., Regsvr32.exe) to stop the progression of Conti’s destruction inadvertently halted all robots on the production line, costing the company tens of thousands of dollars. I’d say that’s a critical discovery. In knowing this, your team may want to explore improvements such as network and device segmentation as well as Application Control. This would allow your team to initiate bans (and exceptions) by policy and cause less disruption and loss in the future.

The meeting might also uncover confusion and inefficiencies regarding roles and responsibilities between the core IR and disaster recovery (DR) teams. In this case, it may be wise to revisit and revise both your Incident Response Plan (IRP) and Disaster Recovery Plan (DRP) to account for ransomware scenarios and defined roles. At any rate, the information gathered and subsequent enhancements made will be unique to every company and environment. After all, no two makeovers are ever the same.

Rebirth

Almost Famous (2000)

You’ve managed to weather the storm and have made it out on the other side, with renewed perspective. At this point, systems have been tuned, processes have been refined, your internal IR team and external stakeholders are in alignment. You’ve closed the loop on the IR cycle and have hardened your defenses against Conti. So, what’s next?

Continuous improvement, of course! Review notes from both the incident report and the Lessons Learned meeting to inform best practices and company-wide policy changes. Hold purple team and/or tabletop exercises to test your full IR capabilities against various threats. Be open to “getting schooled,” learning, and growing with each incident. Your company is the protagonist of its own story, so make it a story worth knowing.