Scottish author Robert Burns wrote in the poem “To a Mouse,” “The best-laid schemes o’ mice an’ men. Gang aft a-gley.” You may better know the saying in its more common form, “The best-laid plans of mice and men often go awry.”

This saying may resonate with incident responders, business continuity planners and crisis managers. They know all too well that all plans may be useless after the first shot is fired. But, as former President Dwight D. Eisenhower said, “In planning for battle, I have always found that plans are useless, but planning is indispensable.” To be ready, start with finding out which business practices and processes can impact response and build a governance structure that supports a resilient organization.

Part of your planning must include knowing how your business practices can support or degrade your cybersecurity response. Incident response plans alone are not enough. Planners and responders need to develop insights into how their business runs as a whole. Doing so allows planners to find areas, such as practices and processes, that could have cascading effects during a response.

Think of this planning as a type of systems design approach, similar to the NIST 800-160 principles, but from a business process perspective.

Or put differently: what good is a robust incident response process if business practices tax it, make it less effective or prevent it from working? On paper, and perhaps even in isolation, your cybersecurity response may be great. In practice, running alongside the rest of the business, it is just another process that could come to a screeching halt.

Does your program make sense for your needs?

An incident response program needs to be flexible, but maintain structure at the same time. Otherwise, it becomes the Wild West of decision authorities, escalation protocols and disjointed communications.

Unless the organization is small, centralized control often does not make sense. The centralized approach can be slow (suffering from communication delays) and maybe ‘too far away’ from the incident to make sound decisions.

Instead, you want to harmonize. Think of this as a constitution that guides the program, defining lanes and cooperation. Models that do not harmonize can lead to a degraded response.

These are some common harmonization hiccups:

• Policy and practice do not align
• Planning requirements do not integrate with organizational structure
• Roles and responsibilities are not well-marked or defined
• Process and asset identification have not been identified or maintained
• Processes and assets do not have dependencies mapped
• Business priorities compete or are in conflict with security benchmarks because each process is being performed alone or in silos
• Resource misalignment or unavailability
• Reactive, monolithic, bureaucratic systems prevent change and make it hard for processes to adapt.

When planning meets real-world processes

Assume you have a strong cybersecurity program and confidence about how well it can respond to threats. By itself, it tests well. How does it work when you embed it within the system, though?

Consider this: incident response success depends on inputs from another process (a dependency) outside of the cybersecurity scope. You’re always going to have an ‘ingestion source’ where the problem starts. This could be anything, such as a security operations center or a third party. Let’s say it’s customer support.

Imagine your business provides technology services. You may not have picked up any odd signs yet, but your customers complain of degraded service. Their normal process is to reach out to your customer support team.

Now, what happens if the customer support process is deficient? In this case, that can be a poor user experience (e.g., filling out a cumbersome form, not getting a person on the phone, an unreliable ticketing system, etc.). In this case, the incident may not be detected until much later because one key ingestion source is all clogged up.

What happens if you overwhelm that ingestion source? Where will the response be focused? The ‘clog up’ (symptom) or the disease, in this case, a possible attack?

It’s time for a non-cyber business practice: downstream consequences.

Moving upstream and downstream

Problems like this can extend outside of the cybersecurity team. That’s just how working with a team goes. Mapping up- and downstream practices and processes can help spot areas that support or degrade cyber response.

Threat actors might even have learned of your customer support vulnerabilities (poor practices). They can exploit these poor practices on purpose. Customer support, for example, can be an entryway for social engineering to target your customers and overwhelm the plans you have in place for response.

How do you reduce the damage?

Which business practices impact incident response?

First and foremost, knowing every possible vector, process and response that could impact your response will consume too many resources. It’s foolish and won’t get you a good return on investment. But you can prepare for the most common ones. Think of it as putting yourself ‘inside the 20’ or ‘good scoring position’. You begin from a position of strength.

Let’s assume you have a decent governance structure and incident response program in place. What’s missing? Trouble points could include:

• Ingestion sources not identified
• Poor non-cybersecurity business practices or processes
• Oversharing information (e.g., too much open-source information) and opening the door to social engineering attacks
• Under-sharing information (e.g., practices or processes are poorly understood), creating blind spots
• Practices conflict or circumvent security measures
• Processes are missing dependencies or developed in isolation from business impact.

In essence, you may have many ‘unknown unknowns’ that need to be translated into ‘known knowns’. The bottom line is you need better insight into how your business practices and processes will impact your cybersecurity response. That means some discovery (knowing your business) and being creative (thinking like a threat actor).

Defining impact categories

Once you are confident with the number of known knowns, the next step is performing some qualitative and quantitative analysis. To do that, you need criteria and categorization related to impact. Some categories could include:

• Financial
• Regulatory and Compliance
• Internal Operations
• External Operations
• Reputation
• Health and Safety.

Every organization will have different impact categories. Match them to your business operations. Not only are you improving your cybersecurity response by undergoing this exercise, but you are also improving your hazard response.

Remember the customer service problem we used as an example? If we mapped processes and assets correctly, we would know who and what is impacted and what type of impact would result. We could assign which are most critical from both qualitative and quantitative perspectives.

Maybe the cybersecurity incident response process relies on the customer service process (an ingestion source and dependency). These could put pressure on internal operations if customers can no longer reach your team. Overlay a malicious actor who is aware of these problems, and the risk gets higher.

In other words, even if you cannot see where your cyber and business processes are tied together, they still exist. It’s very similar to the data life cycle continuum we discussed elsewhere. And if you don’t act on this, the impact of an attack or a mistake could be bigger than it has to be.

So now what?

We’ve pointed out lots of problems and issues. Now, how do you solve them? Here are some methods and ideas:

• Develop a method to find and maintain business process identification, then perform process mapping. You may be surprised by what you find. Something you thought was key may not be that at all, whereas something you thought was not related may be critical. Bonus points if you can integrate this method into some of your systems of record, ensuring automatic and regular updates and maintenance.
• Develop impact categories, with related escalation criteria, which suit your business needs and practices. Generic criteria, and ones without thresholds, leave plenty up to interpretation and can muddy your response. Qualitative and quantitative thresholds are important to wipe out the grey areas (e.g., ‘significant’ financial risk versus $500,000 loss per day).
• Perform business impact analyses (BIAs) on your processes. The BIA may not mark which business practices an attacker could exploit, but you may learn which processes are vulnerable because of their practices. It’s all part of discovery and knowing your business.
• See the world through the eyes of your customer. Of course, almost all businesses do this for the purposes of sales and market expansion. But do you look at it from an incident response perspective? The good news here is that the last two years have forced businesses to learn to work through disruption. If you take this approach, you are forcing your business and security teams to work together and share knowledge.

When plans meet the enemy

Most of all, perform a reality check on your practices and processes. You may have great plans and policies on paper, but they could be overly prescriptive or strict, making them impossible to use or implement. Or you have a weak-link business practice that could knock over your entire operation in one fell swoop.

Cybersecurity and data protection, in general, is a standard business operating procedure now. So, the cybersecurity process needs to work with other processes to find areas of strength, vulnerability and even ways to expand new business opportunities. Make your best-laid plans worth it.