Threat Modeling Business Processes?

Introduction

A common question of threat modeling practitioners is that of threat modeling business processes. Should I be threat modeling them? If I should, how would I do it? Even if I could do it, how do I scale it? I will attempt to answer a few of those questions below.

How to Effectively Threat Model Business Processes

Understanding and mitigating risks associated with specific business processes is critical to maintaining robust security posture and ensuring business continuity. After all a disruption to a business process is a potential disruption in the business's availability.

However, this task comes with its own set of challenges.

Challenges in Threat Modeling Business Processes

1. Lack of Standardized Threat Library: Unlike software threat modeling, there isn't a universally accepted library for business process threats. This makes it difficult to anticipate and catalog potential threats.

2. Inconsistent Representation of Processes: Business processes are often documented in diverse ways, lacking a uniform structure. This inconsistency complicates the analysis and identification of vulnerabilities.

3. Technology Integration: Most business processes are intertwined with technology, making it imperative to consider technological threats alongside process vulnerabilities.

Given these challenges, it’s crucial to approach threat modeling with a structured methodology. Since business processes often rely on technology for their execution, scaling, or sustaining, threat modeling should focus on the availability, confidentiality, and integrity of the involved data and supporting systems.

Proposed Process for Threat Modeling Business Processes

To streamline the threat modeling process, I've developed a structured approach that ensures comprehensive coverage and an easy transition into traditional threat modeling methodologies. Here’s the proposed process:

1. Document the Business Process: Start by thoroughly documenting the business process. This step involves mapping out each step and understanding the flow from start to finish. This could be accomplished by creating a dataflow diagram or simple process flow diagram in any diagramming tool.

2. Note the assets or data Involved: Identify and note what data is being transmitted, consumed, or processed at each step. Understanding the data flow is crucial for identifying potential vulnerabilities.

3. Document Supporting Systems: List the systems that are supporting, sustaining, or checking the business process. This includes both technological systems and human interventions.

4. Categorize systems by impact: Categorize the systems according to their support value and impact on the business process. Suggested categories include:

• Contributes to Process: Systems that provide essential contributions to the business process.
• Supports Process: Systems that offer support, enhancing the efficiency or effectiveness of the process.
• Sustains Process: Systems that ensure the continuous operation and stability of the process.
• Executes Process: Systems directly involved in executing the core functions of the business process.

These categories help to convey the level of support each system provides. Some systems offer direct support to the business process, while others provide indirect support. The goal is to prioritize the systems that most significantly support the business process and address the threats that could impact them.

5. Transition to Traditional Threat Modeling: Finally, use traditional threat modeling methodologies such as STRIDE, PASTA, or attack trees to generate and analyze threats from the prioritized components.

By following this structured approach, businesses can systematically identify and address potential threats, thereby safeguarding their processes and ensuring smooth operations. Threat modeling is not just a technical exercise but a crucial component of comprehensive risk management.

Example:

At the top of the diagram, I have created a simple flow diagram describing a user's journey to update a user profile and register for MFA. Next, I grabbed the different technical systems that support that process.

Once I have them accurately described, I want to prioritize the systems. I have used RED for high impact, yellow for medium impact, and green for low impact (due to having HA configurations).

Following my prioritization, I went through and assessed my threats and countermeasures and had 8 remaining critical threats, 26 high, and 7 very low.

Conclusion

Threat modeling a business process can be accomplished by breaking down a business process into the supporting technical systems. Protecting the confidentiality, integrity, and availability of those systems provides the same protections for the parent business process.