While threat modeling is becoming an important part of the security lifecycle, we at Harness are also in the process to bake threat modeling in our software delivery lifecycle (SDLC). In this blog, we’ll provide a general overview of the threat modeling process we use, its challenges, benefits, and a high-level look at the steps within the process.
Threat modeling is a process to identify security needs, locate threats and vulnerabilities, assess their severity, and prioritize solutions.
As OWASP defines,
Threat modeling works to identify, communicate, and understand threats and mitigations within the context of protecting something of value.
A threat model is a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through the lens of security.
Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, Internet of Things (IoT) devices, and business processes.
Threat modeling looks at a system from a potential attacker’s perspective, as opposed to a defender’s viewpoint. Making threat modeling a core component of our SDLC can help increase product security.
You cannot patch a vulnerability you cannot see, and you cannot defend against an attack you don’t know is coming. However, at a high-level, these are the issues that threat modeling can actually address. It equips your security team with a standardized means of both shoring up existing architecture against attacks and evaluating new security additions to your technological ecosystem hence organization has overall enhanced security posture.
The primary benefit of threat modeling is that design flaws can be addressed before a single line of code is written, thereby reducing the need to redesign and fix security issues in code at a later time hence saving cost,time and resources. Since this is a discussion which involves everybody, helps achieve greater collaboration between developers, architects, security professionals and business stakeholders.This practice helps organizations build a security-first approach into their SDLC. There by inching a step towards compliance and regulatory requirements.
There's also value in conducting a threat model after deployment. Understanding the issues in the current deployment provides best practices for future security architecture strategy. Monitoring weaknesses also allows for faster and more effective remediation.
The entire team – including security architects, developers, testers, and DevOps teams — have a key role to play in developing a threat model:
Though the benefits of threat modeling are extensive, it does come with some challenges, the most common of which are:
Broadly speaking, the process of threat modeling involves five essential steps
Security objectives are goals and constraints related to the confidentiality, integrity and availability of your application. They include:
The second step in the threat modeling process is concerned with decomposing the application, or gaining a fundamental understanding of the application and how it interacts with external entities. This involves:
This information is documented in a resulting threat model document. It is also used to produce DFDs for the application. The DFDs show the different user paths through the system, highlighting the access privilege boundaries.
Identify possible attackers or threat agents that could exist within the target of evaluation. Use Means, Motive, and Opportunities to understand Threats posed by Attackers. Then, associate threat agents with system components they can directly interact with.
Work on minimizing the number of threat agents by:
It has below sub sections:
Identify risk owners and agree on risk mitigation with risk owners and stakeholders. Provide the needed controls in forms of code upgrades and configuration updates to reduce risks to acceptable levels.
The risk mitigation strategy might involve evaluating threats from the business impact they pose. Once the possible impact is identified, options for addressing the risk include:
In this step we create a detailed threat modeling report which can be shared with respective business/function owners.
The report can contain detailed information about the risks identified, risk score, mitigation strategy, impact, threat targets etc. It can also contain tracking references of bugs created in your issue tracking system to tackle each of the threats.
This provides a concise summary of the key aspects, significance, and participants involved in the threat modeling process. In an upcoming part 2 of the blog post on this topic, we will delve into each step in greater depth and examine how Harness can assist you achieve part of this process.
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.