Beyond reactive measures: Harnessing threat modelling for DevSecOps success

In the world of software development, DevOps aims to make the process faster and deliver better-quality software to users. DevSecOps takes it a step further by focusing on security, quality, and speed. While tools and tests are in place to ensure the security of the code and configurations, these measures often miss addressing security issues related to how the application is designed and built.

That is where threat modelling comes into play. It helps us create secure applications by identifying and dealing with potential threats. Threat modelling helps us understand where our application may be vulnerable and take steps to make it more secure.

A Gartner Research prediction adds weight to the significance of threat detection and response. According to their findings, by 2026, more than 60% of threat detection, investigation, and response capabilities will rely on exposure management data to validate and prioritize threats, marking a substantial increase from the current 5%. This shift enables businesses to effectively monitor and tackle risks as their attack surfaces expand due to increased connectivity and the use of SaaS and cloud applications.

What is threat modelling?

Let us start by understanding what threat modelling means. Simply put, a threat is a possibility of something harmful happening if specific actions or orders are not followed. Conversely, a model is a description or representation of a system or process that helps us understand what might happen. So, when we combine these concepts, a threat model is a description that helps us visualize the potential for something wrong or harmful to occur.

Now, when we talk about threat modelling in the context of applications, it becomes a structured approach to evaluate and mitigate risks to application security. It involves modelling the application from an attacker's perspective, considering their interests, like entry and exit points, data flow, and critical assets of the application, and shutting down those entry points.

To our advantage, unlike attackers, we know the application design thoroughly (or at least we should). With this knowledge, we can follow a structured methodology to build a threat model for our applications. This helps us identify and manage risks more effectively, ensuring that we can act appropriately to enhance the security of our applications.

Why threat modelling is essential?

Understanding the importance of threat modelling is crucial when it comes to designing secure software solutions. It is a direct approach that allows us to analyze systems, identify potential attack vectors, and develop strategies to mitigate the risks associated with those attacks. Threat modelling is significant in any risk management process, helping us proactively address security concerns.

One of the critical benefits of threat modelling is its ability to identify and resolve design issues early in the software development lifecycle (SDLC). By incorporating threat modelling from the beginning, we can detect vulnerabilities and make necessary improvements, saving time and costs overall. In fact, threat modelling is often considered the first activity to secure a solution as it focuses on the design itself. This characteristic makes it an incredibly effective security practice to apply throughout the SDLC, ensuring that security is a fundamental aspect of the software solution from its inception.

The STRIDE methodology

The process of threat modelling can become quite complex. One widely used approach is the STRIDE methodology, which recommends conducting a separate technical analysis for each significant type of attack. Integrating threat modelling early in the software development lifecycle helps the STRIDE framework map out the application based on its unique use cases and business logic. This enables identifying and eliminating potential vulnerabilities even before writing a single line of code.

The STRIDE methodology remains applicable throughout the development and production phases. It allows you to revisit the framework whenever you release new code, enabling assessment of its impact on the overall attack vector of your application. STRIDE's threat model encompasses six distinct threat categories:

Spoofing: This occurs when a hacker pretends to be someone else, assuming their identity to commit fraud. Examples include phishing attacks where the attacker sends deceptive emails from false addresses, tricking recipients into sharing sensitive data. Using automated tools powered by artificial intelligence (AI) has made phishing attacks increasingly convincing.
Tampering: Data tampering involves unauthorized changes to information or data. Bad actors may tamper with configuration files to gain control over systems, insert malicious files, or modify or delete log files. Integrating change monitoring, such as file integrity monitoring (FIM), becomes crucial for identifying instances of data tampering. This process examines files against a baseline to detect unauthorized alterations. Proper logging and storage support file monitoring efforts.
Repudiation: Repudiation threats arise when the attacker performs malicious or unlawful activities within a system and denies being involved in the attack. These attacks often make it challenging to trace the malicious activity back to the perpetrator. Email systems are particularly vulnerable to repudiation attacks since few systems verify the validity of outbound mail.
Information disclosure: Information disclosure, commonly called information leakage, occurs when a website or application unintentionally reveals data to users who are not authorized to look at it. This threat can affect an application's processes, data flow, and data storage. Examples of information disclosure include unintended access to source code files through temporary backups, exposure of sensitive information like credit card numbers, and revealing database information through error messages. These issues commonly stem from publicly shared internal content, insecure application configurations, or flawed error responses in the application design.
Denial of Service (DoS): Denial of Service attacks aim to disrupt the intended functioning of a system or application. Hackers flood the application with an overwhelming volume of fake requests, rendering it inaccessible to legitimate users. While DoS attacks may not grant hackers access to data or financial benefits, they can cause significant financial losses and reputational damage by exhausting resources and rendering the application unavailable.
Elevation of privilege: Elevation of privileges refers to the scenario in which an authorized or unauthorized user acquires access to information beyond their authorized scope. For instance, a missed authorization check or data tampering can enable an attacker to modify disk or memory settings, execute unauthorized commands and gain elevated privileges within the system.

By understanding these threat categories, organizations can effectively identify, prioritize, and mitigate risks, ensuring the security of their applications in the face of evolving cyber threats.

DevSecOps and threat modelling best practices

Here are the best practices for implementing threat modelling:

Identify potential risks: Start by thinking about where things can go wrong in your project and what steps you can take to mitigate that risk. Use the STRIDE framework as a starting point to identify potential threats.
Consider business risks: In a DevOps model, assessing business risks from the beginning is essential. Involve business stakeholders early on and communicate the risks in a way that resonates with the technology teams.
Implement DevSecOps: Threat modelling can be an entry point for evolving from DevOps to DevSecOps. Include threat modelling in your road plan and allocate resources for training and using appropriate tools.
Model the attack possibilities: Identify security controls, software assets, and potential threat agents and create a diagram to visualize the system's security model. This helps identify threats using methods like the STRIDE framework.
Start with a pilot project: Begin your organization's adoption of threat modelling by selecting a small project with stakeholders and a team that will benefit the most. For example, choose a project with heightened security requirements and a security-conscious team.
Bridge the communication gap: Just as DevOps improves communication between development and operations teams, threat modelling is another step to closing the gap. Ensure all stakeholders, including the business side, have visibility into the project and provide a platform for questions and concerns.
Automate threat modelling: Look for opportunities to automate threat modelling using tools that integrate with your DevSecOps toolchain. Seek out a tool that provides a set of threat definitions, documentation, and training for your IT teams. Avoid overextension and limit automation to a level where it makes sense.

Why must you threat model? – The benefits

Threat modelling is essential for several reasons. Firstly, it allows organizations to proactively identify potential risks and vulnerabilities early on in development, enabling them to address security issues before they become significant problems. This proactive approach helps enhance overall security by considering potential threats and attack vectors, allowing organizations to design and implement adequate security controls and countermeasures to mitigate risks. Furthermore, threat modelling is cost-effective as it helps prioritize security efforts and allocate resources efficiently, focusing investments on critical areas and reducing the potential impact of security breaches. Additionally, threat modelling improves collaboration among different teams, fostering better communication and coordination to effectively address vulnerabilities. It also assists organizations in complying with industry best practices, compliance requirements, and regulatory standards, ensuring a more secure and compliant system. By incorporating threat modelling, organizations can demonstrate their commitment to security and risk management, building trust and confidence among clients, partners, and investors. Lastly, threat modelling promotes continuous improvement by encouraging a culture of adaptation and evolution in security practices based on emerging threats and changing business requirements.

Threat modelling – high-level steps:

Threat modelling is vital for evaluating and addressing threats to systems and applications. It involves adopting a hacker's perspective to identify threat vectors and actors that could infiltrate or damage the system. The critical steps in threat modelling are as follows:

Assemble a diverse threat modelling team.
Define the scope of threat modelling by identifying what aspects it covers.
Identify the likelihood of exploitation by exploring threat scenarios.
Rank the threats based on their risk level.
Implement mitigation measures to address the identified threats.
Document the results for future security decisions.

Before starting threat modelling, define the business objectives and consider security and compliance requirements. Understanding the application's design is crucial, including creating a data flow diagram and reviewing existing design documentation. By following these steps, you can conduct thorough threat modelling and enhance the security of your systems and applications.

In conclusion, threat modelling is indispensable in DevOps and application security, enabling organizations to identify and mitigate potential risks proactively. Integrate threat modelling into the development process to build resilient and secure applications from the ground up. To learn more about threat modelling and its implementation in your organization, feel free to write to us at contact@opcito.com. We look forward to further discussing the power of threat modelling and helping you strengthen your security practices.