How to Build Cybersecurity Response Business Practices

In his poem “To a Mouse,” Scottish poet Robert Burns stated, “The best-laid schemes of mice and men.” “Gang aft a-gley.” You may be more familiar with the phrase “The best-laid schemes of mice and men sometimes go astray.”

This proverb may ring true for incident responders, business continuity planners, and crisis management. They are fully aware that all strategies may be rendered ineffective once the first shot is fired. However, as former President Dwight D. Eisenhower stated, “in planning for battle, I have always found that plans are useless, but planning is indispensable.” To be prepared, begin by determining which business practices and processes can impact response and then create a governance structure that supports a resilient organization.

Knowing how your company practices might help or hinder your cybersecurity response should be part of your preparation. Incident response strategies alone are insufficient. Planners and responders must get insights into how their company operates as a whole. This helps planners to identify areas, such as behaviors and processes, that may have cascading implications during an emergency response.

Consider this planning to be a form of systems design technique, similar to the NIST 800-160 principles, but from the standpoint of a business process.

Or, to put it another way, what good is a comprehensive incident response mechanism if business practices tax it, reduce its effectiveness, or prohibit it from working? Your cybersecurity response may be excellent on paper, and maybe even in isolation. In practice, it is just another process that might fail while operating alongside the rest of the business.

Is Your Program Appropriate for Your Requirements?

An incident response program must be adaptable while yet being structured. Otherwise, decision authority, escalation mechanisms, and disconnected communications become the Wild West.

Centralized control is rarely appropriate unless the organization is tiny. The centralized method might be delayed (because of communication breakdowns) and ‘too far away from the situation to make appropriate choices.

You want to harmonize instead. Consider this a program constitution that defines lanes and collaboration. Models that do not agree might result in a poor response.

Here are several frequent harmonizing stumbling blocks:

• Policy and practice are not in sync.
• Planning needs are incompatible with organizational structure.
• Roles and duties are not clearly defined or delineated.
• Identification of processes and assets has not been recognized or maintained.
• There are no dependencies mapped for processes or assets.
• Because each activity is conducted independently or in silos, business goals compete or conflict with security criteria.
• Misalignment or scarcity of resources
• Reactive, monolithic, bureaucratic systems stifle change and make process adaptation difficult.

When Planning Meets Real-World Processes

Assume you have a robust cybersecurity program and are confident in its ability to respond to attacks. It performs effectively on its own. But how does it operate when embedded in the system?

Consider this: incident response success is dependent on inputs from another process (a dependency) that is not within the scope of cybersecurity. There will always be an ‘ingestion source’ where the issue begins. This might include anything from a security operations center to a third party. Assume it’s customer service.

Assume your company provides technical services. You may not have seen any unusual symptoms yet, but your customers are complaining about poor service. Their standard procedure is to contact your customer service team.

What happens if the customer assistance procedure fails? In this situation, it may result in a terrible user experience. Because one critical ingestion source is entirely choked up, the event may not be recognized until much later.

Moving Upstream and Downstream

Problems like these can spread beyond the cybersecurity team. That’s how working in a group works. Mapping upstream and downstream behaviors and procedures can aid in identifying areas that support or hinder the cyber response.

Threat actors may have even discovered your customer support flaws (poor practices). They can purposefully take advantage of these inadequate practices. Customer service, for example, may be used as an entrance point for social engineering to target your consumers and overload your response plans.

What Business Practices Have an Impact on Incident Response?

To begin with, understanding every single vector, process, and reaction that might influence your response will occupy far too many resources. It’s stupid and will not yield a decent return on investment. However, you can plan for the most prevalent ones. Consider it positioning oneself ‘within the 20’ or in a ‘strong scoring position.’ You start from a strong position.

Assume you have a solid governance framework in place, as well as an incident response procedure. What is lacking? Problem areas might include:

• Sources of ingestion are unknown.
• Non-cybersecurity-related business practices or processes
• Oversharing information (for example, too much open-source material) and allowing social engineering assaults
• Under-sharing of knowledge (e.g., poorly understood methods or processes), resulting in blind spots
• Practices that are in contradiction with or bypass security measures
• Processes lack interdependence or are built-in isolation from their business impact.

In essence, you may have a large number of “unknown unknowns” that must be converted into “known knowns.” The bottom conclusion is that you must have a deeper understanding of how your company policies and operations will affect your cybersecurity response. That requires some exploration (understanding your business) as well as some creativity (thinking like a threat actor).

Defining Impact Categories

Once you’ve determined the number of known unknowns, the following step is to do some qualitative and quantitative analysis. To accomplish so, you’ll require impact-related criteria and classification. Some examples of categories include:

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

Each company will have a unique set of effect categories. Match them with your company’s activities. Not only will this exercise improve your cybersecurity response, but it will also improve your hazard response.

Remember the customer service issue we used as an illustration? We would know who and what is impacted and what sort of effect would ensue if we accurately mapped processes and assets. We could determine which are the most significant from both a qualitative and quantitative standpoint.

Perhaps the cybersecurity incident response process is influenced by the customer service procedure (an ingestion source and dependency). If clients can’t reach your staff, this might place a strain on internal operations. When a malevolent actor is aware of these issues, the risk increases.

In other words, even if you can’t perceive the links between your cyber and business operations, they still exist. It is extremely similar to the data life cycle continuum that we described previously. And if you don’t take action, the impact of an assault or a mistake may be more than it needs to be.

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com