Cybersecurity Outside the Box: The Critical Importance of OOB Communications in Incident Response

Over the past year, my fellow CISOs as well as our Director of Incident Response, Tyler Hudak, have all noticed a troubling trend. Many organizations are overlooking the critical role out-of-band (OOB) communications should be playing in their incident response playbooks.  

“OOB comms” refers to using separate, isolated channels to communicate during a cybersecurity incident—channels completely outside the potentially compromised primary network. 

They are an important tactic in the MITRE ATT&CK Mitigations, a lesser known relative of the popular MITRE ATT&CK framework for understanding adversary behaviors. That’s because neglecting OOB comms can have serious consequences. 

Let’s dive deeper into why OOB comms are so critical for effective incident response, and how organizations can build it into their crisis communication plans. 

 

Learning Tough Lessons 

In the past year, some of our Inversion6 team helped a client who lost all communications capabilities due to a cyber-attack. That means no email, no chat and no telephones. Unfortunately, they also had no pre-planned solution for OOB comms.  

Our initial response involved on-site and face-to-face meetings as well as cell phone call trees to communicate with internal staff. Eventually a partner firm permitted the incident response team to use their third-party Microsoft 365 tools for online meetings and project tracking. The job got done, but it could have gotten done significantly faster and easier if OOB comms had been part of the initial playbook. 

In another example, a recent SANS report profiled an attack on the Ukrainian power grid where the attackers remained in the environment long after the initial breach to monitor and taunt responders while attempting to circumvent their activities.   

This is exactly why the MITRE Mitigations list stresses OOB comms. It allows responders to maintain operational security, communicate independently of a compromised and unstable infrastructure, send authenticated messages and securely store important data for post-incident analysis. 

 

Right Idea, Wrong Implementation 

In May 2019, the City of Baltimore suffered a crippling ransomware attack. When they realized their own email system had been compromised, they made an on-the-fly decision to establish OOB comms by encouraging their employees to sign up for free Google Gmail accounts.   

Unfortunately, Google’s automated response systems detected a large number of accounts created from a single network and immediately suspended them all. The accounts were later restored when city officials explained the situation to Google, but the issue further disrupted an already complicated incident response effort. 

Even if these accounts hadn’t been suspended, we cybersecurity pros shudder at the thought of using consumer level accounts for OOB comms. There’s simply too much risk and too little monitoring and verification (is dark.dilbert2002[@]gmail.com REALLY your CIOs personal email address?).   

A much better plan would have been to setup licensed Google Workplace business accounts specifically for “break glass” use. These services are pre-configured for authenticated and secure service, and they require approval from your legal and purchasing officials, adding another layer of verification. 

 

Choosing Your OOB Model 

There are two common approaches to OOB comms during incident response. 

1. The Contingency Operations Model 

In this approach, the incident response team continues to use familiar daily tools—email, messaging apps, file sharing etc.—but via dedicated, cyber-specific channels (e.g. separate mailing lists, chat rooms, and meeting links).  

 

If and when these primary systems are compromised, a parallel OOB setup—hosted entirely outside the organization’s infrastructure—can replicate these functions with a smaller user base and limited licenses.  

 

This approach emphasizes the temporary nature of OOB comms and reduces costs. However, teams may not be familiar with the backup platforms, so regular practice is essential. Critical response plans (IR and DR) should also be stored in the OOB system. 

 

2. The Always-OOB Model 

In this approach, incident response communications always occur through a separate OOB platform, regardless of whether a crisis is underway. This ensures responders are fully comfortable with the tools. It also keeps sensitive incident data isolated from daily operations.  

 

This model typically requires dedicated licensing and manual user provisioning, so the system should be limited to core responders—not the entire organization. As we saw with the City of Baltimore, this containment step is critical, and the security of OOB systems must be rigorously maintained. 

Which approach you choose depends on your organizational risk profile, as well as the overall maturity of your disaster recovery and business continuity planning. 

 

How to Get Started  

Here in Northeast Ohio, we produce a lot of maple syrup. If someone asks, “When should I plant a maple tree to start harvesting sap,” the answer usually goes something like this: 

“Forty years ago. But the next best time is today.”   

That’s another way of saying if your incident response playbook doesn’t currently include an OOB comms plan, you should get started right now. 

Start small by making certain your security communications are secure. Begin by setting up your immediate IR team only, and be meticulous about user accounts, authentication strength and ease of use.  

Of course, whatever OOB comms platform you choose must be fully disconnected from your core infrastructure. This means hosting, networking and authentication cannot be dependent on your organization’s services. For example, if you use M365 for standard services, you could conceivably set up a smaller, separate M365 tenant specifically for crisis response with a different domain name.  

Here are a few common options for OOB comms. Be sure to do your own research, and steer clear of ‘free’ consumer apps.  

• Microsoft Teams 

• Google Workplace/Meet 

• Cisco Webex 

• Zoom 

• Slack 

• GoToMeeting 

• Adobe Connect 

• Signal/Threema/other encrypted messaging platforms 

Remember, the reason we suggest keeping it ‘small’ is because you’ll most likely need to provision and deprovision your OOB users manually. It’s also another set of services your team must monitor for security, availability, and functionality. 

Finally, be sure to practice with these tools before you go live with your OOB option. We suggest one drill during normal business hours, then another in the evening or on a weekend. Practice enough in the first two months that it becomes a normative habit, then go to maintenance mode. You may also consider planning one of your quarterly incident exercises to leverage fully OOB communications.  

Semper Paratus! 

 

Want to learn more?  
Visit our Fractional CISO and Incident Response pages to see how we can help you stay prepared and protected.