If you work in incident response, you’ll recognize this scenario all too well: It’s Friday night and you just started the book you’ve been keen on reading for a couple of weeks when suddenly, you hear your beeper buzzing. The display reads that the security operations center (SOC) escalated a security incident for an intrusion taking place on your company’s customer database.

Not to worry, though. You prepared for the possibility of a data breach and have an incident response plan ready for this kind of incident. Your team is well aware of the data breach risks associated with possible unauthorized access to the customer database. Your plan includes how to escalate matters to management, how to report issues to your data protection officer (DPO) and instructions for the IT team to preserve evidence, contain the threat and recover from the incident.

There’s nothing more to do, right? Not quite.

Take Control of Incident Response Communication

Incident response processes often only focus on the technical aspects of proper procedure. While we’ve already included escalation points to management and can foresee direct lines with the legal and human resources departments, there’s one crucial element that is frequently overlooked: communicating with your stakeholders.

One common data breach risk is this type of news spreading fast, and it’s often uncontrolled. Your incident response training and plans can prepare for a data breach, but they will not help you if, as a result of a miscommunication, your entire focus is on damage control instead of explaining what exactly has happened. It is essential that you remain in control of communications of this nature during and after a security incident.

The PR team for your organization is exactly the team that can help you accomplish this, but some planning and preparations will be necessary to ensure their support.

Identify Your Stakeholders

First, start by identifying your stakeholders for communication. Not every stakeholder requires the same level of detail or frequency of communication, but you have to identify these needs up front. This is where the PR team can provide valuable input, as they have already established these communication channels and should have a good idea of stakeholders’ expectations. For each group of stakeholders, it’s important to determine the following:

  • How you can reach them — take note if there are dedicated communication contacts at both ends.
  • The level of technical details they will expect.
  • The expected frequency of updates.
  • Decide if communications to the stakeholder group should occur publicly or via closed channels. For example, you might reach out to your customers through a press release and your board of directors through conference calls.
  • If you have previously included the contacts in exercises to prepare for a data breach, then use any lessons you’ve learned to further refine the information you provide.

Don’t forget about employee communication. It’s important to keep your employees aware of the incident and ensure that they hear the details from you and not from the media. Having employees on board during a security incident can help you resolve the matter more quickly and maintain trust in your organization at the same time.

Communication Templates and Finding the Correct Tone

Finding the correct tone during a crisis can be challenging. Additional data breach risks may be created if stressful emotions are allowed to take over during communication, especially when companies discover they have just been robbed of their data. To avoid having to come up with a text in the heated moment of an incident, it’s best to prepare a set of templates with the PR team that can be used to inform different stakeholders.

Here are some key elements to consider as you develop these templates:

  • Decide which elements you want to disclose or highlight during communications. This can include describing the types of data and consequences associated with the breach, especially if there’s a risk of losing personal or sensitive information. You should also decide what type of attribution you want to include in your communications, if possible. Non-public information for certain stakeholders might include attribution, while public communications might be more generic.
  • Always use the Traffic Light Protocol (TLP) in your communications. Verify that your stakeholders understand the schema. It may be expedient to share the schema across your channels.
  • Be aware that some communication can have legal consequences, as a public statement may be admissible in court if a lawsuit is filed.
  • Be sincere about what happened. Do not create templates that downplay an incident, as this can be disrespectful to your customers.
  • If you’re still searching for answers, say so.
  • Make sure your templates include contact information for stakeholders to reach out if they have additional questions.
  • Remember to tune your communications for social media. Twitter messages might be different from Facebook posts or press releases.

In your communications, always take responsibility for what happened and provide an indication of what steps have been or will be taken to protect your customers and how the situation could influence your services to them.

Develop a Communication Process

Next, verify with your PR team which types of incidents (based on impact or severity) will require their involvement. It’s essential that the incident response team and the communication team are on the same page, so make sure your taxonomy is understood by the PR team. Appoint a dedicated technical liaison for the communication team who can assist with the translation of technical concepts into language that is clear and understandable by the intended audience.

During the communication process, you need to include controls that help you decide which parts of the incident you want to disclose. Remember that making a public statement means letting attackers know they have been discovered. This could cause them to erase their tracks or conduct further retaliation attacks. You will need to evaluate disclosures on a case-by-case basis, but it’s worth thinking about these scenarios up front.

Your process should also include verifying whether your internal teams can handle the communication flow or if external help will be required, especially after the incident.

Incident Response Tooling

You should be able to rely on your organization’s communication tools during an incident, but it’s always good to prepare for the worst.

  • Set up a status or communication web page outside your organization. Having a backup internet connection (for example via a mobile phone) to update these pages might also be necessary.
  • Social media provides a widely accessible means of communicating, but beware of miscreants creating fake social media accounts and impersonating your organization. If you can, preregister social media accounts with names resembling your official accounts.
  • Foresee feedback loops in your tooling and verify that communications have effectively reached your stakeholders.
  • If you need mass communication, evaluate how you can send out text messages, social media posts and press releases at the same time with more or less the same content. The European Union Agency for Cybersecurity (ENISA), for example, published guidelines for secure group communications for incident response and operational communities.

Ultimately, you cannot overlook the communication component in your handling of security incidents. It is crucial that you ensure communications are supported by the team that’s best suited for the task, the PR team, who should be considered essential players in your incident response process.

More from Incident Response

X-Force Prevents Zero Day from Going Anywhere

This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

When the Absence of Noise Becomes Signal: Defensive Considerations for Lazarus FudModule

In February 2023, X-Force posted a blog entitled “Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers” that details the capabilities of a sample attributed to the Lazarus group leveraged to impair visibility of the malware’s operations. This blog will not rehash analysis of the Lazarus malware sample or Event Tracing for Windows (ETW) as that has been previously covered in the X-Force blog post. This blog will focus on highlighting the opportunities for detection of the FudModule within the…

Breaking Down a Cyberattack, One Kill Chain Step at a Time

In today’s wildly unpredictable threat landscape, the modern enterprise should be familiar with the cyber kill chain concept. A cyber kill chain describes the various stages of a cyberattack pertaining to network security. Lockheed Martin developed the cyber kill chain framework to help organizations identify and prevent cyber intrusions. The steps in a kill chain trace the typical stages of an attack from early reconnaissance to completion. Analysts use the framework to detect and prevent advanced persistent threats (APT). Organizations…

Defining the Cobalt Strike Reflective Loader

The Challenge with Using Cobalt Strike for Advanced Red Team Exercises While next-generation AI and machine-learning components of security solutions continue to enhance behavioral-based detection capabilities, at their core many still rely on signature-based detections. Cobalt Strike being a popular red team Command and Control (C2) framework used by both threat actors and red teams since its debut, continues to be heavily signatured by security solutions. To continue Cobalt Strikes operational usage in the past, we on the IBM X-Force…