So, Equifax happened... this blog is not about that, even though it seems like it is. I wrote it before that news broke. Any resemblance to that situation is coincidence.
Previously, I went through the first two stages of CERC, pre-crisis and initial, and how they interact with incident response efforts. Now, we move on to the last three stages of CERC: maintenance, resolution, and evaluation. These are some of the most active stages for the organization. Each department will have priorities and resources will be stretched to the limit. As before, I'm going to examine communication and technical concerns at these stages and then I'll lay out some recommendations for how they can work together.
Response (Maintenance & Resolution)
Looking at the CERC priorities for these stages, we really see CERC's focus on communicating about the crisis and not actually resolving it. That's a key to remember when applying CERC to an actual real-world situation. If you are a smaller operation or the crisis is spiraling out, these tasks will be pushed to the side in favor of work that keeps the organization functional. However, with effective planning, the communication doesn't have to be a major undertaking. Ideally, it is a well-oiled function of the overall response. Communication is only really ever noticed when done very well or very poorly.
Communication concerns
One way to think about good risk and crisis communication is that it gives people affected by the crisis enough information to make the best decisions to protect themselves from harm. At the maintenance stage, everyone who needs to know is aware that an incident has occurred. They've begun taking the recommended actions to protect themselves. Now, you need to explain what is being done by the organization to remedy the situation, give more information about how the incident happened, and make sure those affected have all of the necessary information for self-protection as the crisis progresses. This is, of course, based on the idea that the organization knows all of these things.
Yet again, infosec breaks the rules of typical crisis response. Depending on the incident, there might not be much for those impacted to actually do. The "how this happened" and "what we're doing" is probably deeply technical and will require translation to be appropriate for most audiences. You might also never have satisfactory answers to some of the questions your audience will ask. You can't fully move onto the resolution stage until the crisis has been fully resolved and there is a clear understanding of what happened.
In the major infosec incidents that we've seen, the actions CERC calls for at the resolution stage aren't great for the organizations experiencing the breach. If the public still blames you for the crisis, you can't educate them and they don't really want to hear more about your organization's role - unless it comes in the form of you apologizing for losing their data.
Technology concerns
The infosec efforts that come into play at this stage are not my wheelhouse but Stuart Peck's recent talk at Security Scotland gave a really good overview of some of the goals and tasks during incident response. As I understand it, the priorities are:
Identify the source(s) of entry, indicators of compromise, infection vector
Mitigate and/or eradicate - removing malicious program/code/etc., close vulnerability/backdoor, rebuild system from backups in the case of ransomware or wiper
Get everything back up, patch and update, resume normal operations
These are very labor intensive operations that involve creative problem solving and exceptional teamwork. This work is also typically invisible to anyone who isn't actually doing it. Resolving an infosec incident doesn't involve many photo-ops. It is difficult to show the public, media, employees, etc. all of the hard work that you're doing. This creates the perception that nothing is being done. I'd love to run a study on what sort of work the public thinks is required for incident response. We can't rely on these teams to communicate about their work at this stage, they're busy doing the work, but someone should be explaining what is being done.
Working together
Any crisis management plan includes the creation/activation of the crisis response team. These teams are made of a variety of departments and vary depending on the crisis. From what I can tell, some organizations have incident response plans but they live within security teams and have limited connections to other departments. The majority of large organizations have crisis response plans that either integrate multiple departments or farm out to crisis management firms whose plans will do so. Organizations need to do better integrating IT and security, and all of the associated risks, into the larger level operations, including crisis management.
We have seen multiple incident response cases in which it's obvious that the communication team wasn't working with the incident response team. These are rarely cases of good incident response. To improve, the communication team needs to be looped in on the work that the incident response team is doing. A system needs to be developed wherein this doesn't impede the work of the IR team but helps the comms team work effectively and produce accurate messages. When the communication team is left up to their own devices in a crisis with which they're unfamiliar, bad communication happens.
The problem is that many organizations that experience a breach don't live in the security space. Their teams don't have to talk about IT and security on a regular basis so they don't have the knowledge to do so well. This is also true of standalone crisis communication firms. Most communicators don't have extensive knowledge of or experience with infosec to communicate about an incident without assistance. This puts a lot of pressure on those with the knowledge and experience during an incident. However, if there in a specific infosec crisis plan that includes both technical and communication concerns (developed when the organization isn't actively experiencing a crisis) that will hopefully alleviate the burden. An even better way to alleviate the burden is to make sure that the only time your whole organization is aware of infosec isn't during a crisis. Making infosec an integrated part of your organization at all levels and departments is the real solution but, baby steps. Write a comprehensive incident response plan.
This plan should include key terms (for all parties), distribution lists for specific types of information - both internal and external, templates, maybe a shorthand/code sheet for internal use to streamline communication, etc. There are plenty of guides for developing a crisis response plan and I'll probably write a full, infosec-specific one eventually. The key is to have a plan specific to your organization's risks and resources in regards to infosec, not just more traditional crises.
Evaluation
The last stage of CERC is very generic in its recommendations but is still important. The recommendations here can be applied to any department or type of operation: communication, technology, sales, etc. Whenever there's an unusual event, you need to take time to reflect, to try and learn something. A priority for me during evaluation is understanding how people, teams, and departments worked together. Did people have the information and support they needed to get things done? What can be done in the future to improve these systems - adding or removing a middleman, creating templates for memos, running simulations. Everyone might have their own priorities or methods for evaluation so it will involve some negotiation as well.
The "technology concerns" at this stage are the same. Learn from the crisis to improve security and try to avoid a crisis in the future. Report writing is a step in all incident response but it's important that the reports are read, understood, and internalized by key decision-makers. The evaluation stage is also the time to recommend changes to try to prevent future crises. There is a careful balance to strike here between using the crisis to motivate change and scolding an organization still trying to get back to normal. Be really careful not to even imply that doing these things before would have avoided the crisis; try not to mention that you've already made these recommendations, unless directly asked.
Lessons
I've covered a lot here so I'll keep the conclusion brief to a list of take-aways. There's still a lot to learn about communication for incident response but I think CERC presents a useful tool for both infosec professionals and communicators to improve responses to infosec incidents.
Integrate I.T. and information security into the entire organization, don't treat these teams/people like an external force that doesn't impact everything that your organization does.
Educate employees in all departments about infosec before a crisis happens, especially if they will be involved in incident response (sales, marketing, PR, etc.). Learning about anything during a crisis is ineffective and makes response harder.
Vague, uninformed communication can be as bad as no communication. Taking the time to give useful, descriptive information to your audience is a worthy investment.
Creating (and using) systems and channels for information sharing between teams before an incident can be critical once an incident breaks.
Infosec breaks a lot of the rules for traditional crisis communication so "standard" responses might cause more problems than they solve.
Have a crisis management plan specifically for infosec risks that integrates all parts of the organization.
Better utilize the evaluation stage and reports written after an incident to better prepare for (or maybe avoid) future incidents.
