Using Threat Modeling for DevSecOps Practice丨IDCF

author:

Yao Shengwei (currently working at Tianjin Yinyuan Technology Tianjin Blockchain Technology Innovation Center)

R&D Effectiveness (DevOps) Engineer Certified Student

1. From DevOps to DevSecOps

DevOps initially emphasized the collaboration and cooperation between development and operation and maintenance. Today, it no longer only involves development and operation and maintenance teams. In order to better play the role of DevOps, the entire IT process and various types of work must be integrated into the entire life cycle of the application.

While the way DevOps works allows development teams to deploy applications faster, it’s like trying to go faster over a cliff, there’s nothing safe about it!

Today, with the cloud, DevOps teams have access to unprecedented infrastructure and scale. But then some of the most malicious actors on the Internet can quickly access these teams through the cloud, creating security risks for the business every time they deploy an application.

In such a distributed environment, perimeter-type security is no longer feasible, so companies must adopt more micro-level security and create multiple lines of defense in applications and infrastructure.

How do you ensure your application is and remains secure through continuous integration and delivery? How do you identify security issues in their early stages and fix them? This starts with a practice commonly known as DevSecOps.

DevSecOps, short for "development, security and operations," automatically integrates security at every stage of the software development lifecycle - from initial design, through integration, testing, deployment, and all the way to software delivery [1]. 

DevSecOps represents a natural and necessary evolution for development organizations to implement security. In the past, security was always added to software at the end of the development cycle (almost as an afterthought) by a separate security team and tested by a separate quality assurance (QA) team.

Traditional security development process

In the traditional security development process, the security team intervenes relatively late and is basically a line of defense before product release. Objectively, development and testing are run according to agile and DevOps processes. At the last step, there is no return. The waterfall approach to security testing resulted in "intestinal obstruction" of releases.

This approach is fine if you only release software updates once or twice a year. However, as software developers adopt agile and DevOps practices, and software development cycles shorten to weeks or even days, the traditional "additive" approach to security creates unacceptable bottlenecks.

DevSecOps seamlessly integrates application and infrastructure security into agile and DevOps processes and tools. It solves security issues as soon as they arise, making them easier, faster, and less expensive to deal with without bringing them into production. Additionally, DevSecOps makes application and infrastructure security a shared responsibility among development, security, and IT operations teams, not just the responsibility of the security team alone. It enables "delivering software more securely and faster" - the motto of DevSecOps, which automates the delivery of secure software without slowing down the software development cycle.

DevOps vs. DevSecOps

DevSecOps integrates security teams and their capabilities into DevOps practices, making security the responsibility of everyone on the team. Security is no longer an afterthought, but security assessment is performed at every step of the process.

DevSecOps assesses the four dimensions of program security

Securing applications is an ongoing process that includes securing infrastructure, designing an architecture with layered security, continuous security verification, and monitoring for attacks.

2. Understand threats and their impact

In the [R&D Effectiveness (DevOps) Technical Engineer Certification] training, Mr. Zhuang Junqian mentioned the issue of SQL injection in a course introducing common security vulnerabilities. The OWASP organization (Open Web Application Security Project) lists injection as the number one threat to web application security in its OWASP Top 10 2017 document.

From the course, we can discover some characteristics of SQL injection:

1. SQL injection is an attack that can execute malicious SQL statements. These statements control the database server behind the Web application.

2. An attacker could use SQL injection vulnerabilities to bypass application security measures. They can bypass authentication and authorization of a web page or web application and retrieve the contents of an entire SQL database. They can also use SQL injection to add, modify and delete records in the database.

3. SQL injection vulnerabilities can affect any website or web application that uses a SQL database (such as MySQL, Oracle, SQL Server, etc.). Criminals may use it to access, delete, or alter sensitive data without authorization: customer information, personal data, trade secrets, intellectual property, and more.

The dangers of SQL injection cannot be underestimated. There are many famous SQL injection incidents in history, such as:

In 2008, the database of Ohio State University was attacked by SQL injection, resulting in the leakage of more than 360,000 pieces of sensitive data, including the names, Social Security numbers, dates of birth, etc. of students, faculty, staff, and alumni.

In 2011, Sony's PlayStation network suffered a SQL injection attack, resulting in the theft of more than 77 million users' personal information, including names, addresses, emails, passwords, etc. Sony lost approximately $170 million and faced multiple lawsuits.

In 2015, the British telecommunications company TalkTalk suffered a SQL injection attack, resulting in the leakage of personal information of more than 150,000 customers, including names, addresses, phone numbers, bank accounts, etc. TalkTalk lost around £60m and lost 100,000 customers.

SQL injection attacks are among the oldest, most common, and most dangerous web application vulnerabilities.

Comparison of OWASP Top 10 2017 and 2021 lists

In the OWASP Top 10 2021 list[2] announced not long ago, we also saw from the list that access control failure (Broken Access Control) rose from fifth to first. 94% of applications have been tested for some form of access control failure. The 34 CWEs mapped to access control failures occurred more frequently in applications than any other category.

Access control refers to the restriction of authenticated users from performing actions beyond their permission levels. Access control disruption occurs when such restrictions are not configured correctly. This could result in unauthorized access to, and modification or destruction of, sensitive information.

Failure of access control will cause the following serious consequences:

1. Unauthorized information disclosure, modification or damage to all data, such as user data, sensitive information, configuration files, etc.

2. Unauthorized execution of business functions beyond user permissions, such as management pages, API operations, file uploads, etc.

3. Unauthorized escalation of privileges, such as becoming a user without logging in, or logging in as a user and becoming an administrator.

The harm of access control failure cannot be underestimated. There are many famous access control failure events in history, such as:

1. In 2017, the U.S. credit rating agency Equifax was hacked, resulting in the leakage of personal information of more than 140 million Americans, including names, Social Security numbers, dates of birth, addresses, etc. The attackers exploited a known Apache Struts vulnerability on the Equifax website to bypass access controls and gain access to the database.

2. In 2018, Facebook was hacked, resulting in the theft of more than 50 million user accounts, including names, genders, locations, etc. The attacker exploited a vulnerability in the "view profile" function on the Facebook website to bypass access control and obtain the user's access token.

3. In 2020, Twitter was hacked, resulting in the accounts of many celebrities and politicians being tampered with and some fraudulent Twitter messages being posted. The attackers used internal tools owned by Twitter employees to bypass access controls and gain administrative rights to target accounts.

There are many examples of access control failure, but they can be roughly divided into the following types:

1. URL-based access control fails: An attacker can access pages or resources that should not be authorized by modifying parameters or paths in the URL.

2. Failure of ID-based access control: Attackers access or modify other users' data or records by modifying unique identifiers in requests, such as user IDs, order IDs, etc.

3. Failure of method-based access control: Attackers use different HTTP methods, such as GET, POST, PUT, DELETE, etc., to perform operations that should not be authorized, such as addition, deletion, modification, and query.

4. Metadata-based access control fails: Attackers bypass authentication or escalate permissions by modifying metadata in requests, such as cookies, JWT, hidden fields, etc.

5. Invalid access control based on CORS: By exploiting the misconfiguration of CORS (Cross-Origin Resource Sharing), attackers can access APIs or resources that should not be authorized from different domain names.

Here are some specific examples of access control failures:

1. Suppose a website has two roles, namely ordinary users and administrators. Ordinary users can view their own personal information, and administrators can view the personal information of all users. Under normal circumstances, the application will generate different URLs based on the user's role, for example:

   https://example.com/app/getUserInfo (normal user)

   https://example.com/app/admin_getUserInfo (admin)

   If the application does not perform access control checks on the URL, then an ordinary user can view the personal information of all users by changing the URL to the administrator's URL. This is an example of URL-based access control failing.

2. Suppose a website has an ordering system, and each order has a unique order ID. Under normal circumstances, the application will generate the following SQL statement based on the order ID entered by the user:

   SELECT * FROM orders WHERE order_id = '123456';

   If the user enters the correct order ID, then this statement will return the order information, otherwise it will return empty. However, if the application does not perform access control checks on the order ID, then a user can view or modify other users' order information by modifying the order ID to that of another user. This is an example of ID-based access control failing.

3. Suppose a website has a file management system where users can upload, download or delete their own files. Under normal circumstances, the application will perform different operations based on the HTTP method used by the user, such as:

   GET /files/filename.txt (download file)

   POST /files/filename.txt (upload file)

   DELETE /files/filename.txt (delete files)

   If the application does not perform access control checks on HTTP methods, then one user can delete another user's files by using the DELETE method. This is an example of method-based access control failing.

4. Suppose a website uses JWT (JSON Web Token) to verify the user's identity and permissions. Under normal circumstances, the application will determine whether the user has the right to access certain resources or functions based on the JWT generated when the user logs in. But if the application does not perform validity or integrity checks on the JWT, a user can bypass authentication or escalate privileges by modifying or forging the JWT. This is an example of metadata-based access control failing.

5. Suppose a website has an API that allows users to access some public resources from different domain names. In order to achieve this function, the application uses the CORS (Cross-Origin Resource Sharing) mechanism and sets the following response headers:

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

This means that the application allows any domain name to access the API and allows sending credentials such as cookies. However, if the application does not perform access control checks on the API, then an attacker can construct a malicious web page, access the API from a different domain name, and use the user's cookies and other credentials to perform some operations that should not be authorized. This is an example of CORS-based access control failure.

We can see that security issues are exposed throughout the software development cycle, and we need to follow the requirements for secure software development and take the first step towards safer coding.

Following best practices for secure software development requires integrating security into every stage of the software development lifecycle (from requirements analysis to maintenance), regardless of project approach (Waterfall, Agile, or DevOps). With concerns about data breaches and operational security flaws being exploited, more and more developers understand that addressing security issues needs to be integrated throughout the entire development process.

In the development life cycle, the later the problem is solved, the higher the cost of solving the problem.

Security issues are no exception. If security issues are ignored in the early stages of software development, each subsequent stage may inherit the vulnerabilities present in the previous stages. The final product will accumulate many security issues and data breaches may occur. Integrating security into every stage of the development lifecycle will help identify problems early and help reduce development costs.

We introduce it according to each stage of the Security Development Lifecycle (Security Development Lifecycle, SDL), and you can use them to complete secure software development practices in each stage of the life cycle [3].

The various stages of SDL include:

Security development life cycle

3. Use SDL to create a modern DevSecOps framework

Since DevSecOps is an extension or enhancement of existing software development practices, it is easiest to think of the DevSecOps framework from an agile perspective as a way to plan and design, code, test, deploy, and continuously operate.

planning and design

DevSecOps begins early in the software development life cycle, usually during the design or planning phase. For example, security issues can affect goal setting during Sprint planning. The DevSecOps framework brings security goals into the planning phase by:

• Establish coding standards and conduct peer reviews. When developers write parts of the code differently, security flaws can find their way into the product. If a team establishes and enforces a consistent set of coding standards and evaluates the code base against this set of standards, it can greatly prevent the introduction of vulnerabilities. Peer review ensures that code actually adheres to standards and catches common programming errors.

• Use security plug-ins in IDE environments. IDEs are extensible platforms, and various security plug-ins can often be installed to check for potential vulnerabilities in the code, just as the IDE can highlight missing punctuation or syntax errors. IDE-based security checks provide developers with static code analysis before they commit to the code base.

• Conduct threat model analysis. Threat modeling encourages developers to treat an application like a hacker. Developers should consider the potential risk of abuse of their programs and should consider ways to prevent abuse in their program targeting settings. Common threat model analysis methods include STRIDE, DREAD and OWASP. Multiple threat models can be combined to enhance the security of the design. We can use Microsoft Threat Modeling Tool for analysis, which is also the practical tool that this article will focus on.

Writing code and code management

DevSecOps means more than just security-aware coding standards and peer reviews. It also means putting security at the center of code base management and maintenance to avoid introducing vulnerabilities. Common techniques for ensuring secure code submission and management include:

• Manage dependency security. External libraries, open source code, and reused modules are common in software development. However, external code may not follow the same security standards and precautions as the company's internal workflow. Developers should check the security of all dependencies, verify that they are authentic, officially released versions and deliver them securely.

• Scan code and code repositories. Code repository scanning tools can statically analyze code submitted to the repository before a build is executed, checking for vulnerabilities, hard-coded credentials, and other common omissions. Vulnerability testing and other static tests are critical to code security. Code repository scanning adds security for large teams because developers on the team access the same repository.

• Securing the development pipeline. After a security issue is detected, a full DevSecOps framework might adjust the development workflow to prevent code from being committed directly to the default or trunk branch until the issue is resolved. Additionally, attackers can compromise the pipeline itself by introducing malicious code or stealing credentials. Therefore, companies should implement security controls in their development pipelines.

test

Testing can detect application flaws and security issues. Automation and orchestration of build, test, and release pipelines should include security tools that run when code is deployed for testing, e.g., checking for vulnerabilities during unit tests. Common testing considerations for DevSecOps frameworks include the following:

• Integrated Dynamic Application Security Testing (DAST). DAST and penetration testing have historically been the last steps in the development process. DevSecOps should add DAST, penetration testing, and other types of dynamic vulnerability testing to the testing regimen during the build phase of the pipeline. Full DAST and other dynamic vulnerability testing, such as security acceptance testing, can be time-consuming, but lighter testing options are available to both get results faster and identify issues missed in static testing.

• Securing infrastructure. The security considerations of DevSecOps should not only be limited to the application itself, but also need to take into account the deployment environment, whether it is local or cloud infrastructure (virtual machines, containers, K8S clusters, etc.). Security-driven policies can be implemented on cloud infrastructure with the help of tools such as Microsoft and AWS. Infrastructure as Code (IaC) is a way to build standards and good application environments.

Deployment and operation

Even if the build is successful, it does not mean that security issues will never arise again. DevSecOps practices enter deployment and operations environments in the following ways:

• Configuration management. The infrastructure environment in which the application is hosted must be stable. Any attempt to change the configuration of an established infrastructure may be malicious. Tools to monitor and enforce infrastructure configuration should be a core element of an organization's DevSecOps framework. Cloud vendors also offer these tools, such as Microsoft Defender for Cloud and Microsoft Sentinel.

• Intrusion detection and behavioral analysis. Analytical tools (intrusion detection and prevention systems) can establish a baseline of traffic patterns and performance and then use this to detect suspicious or malicious anomalies in a workload or network. Such tools are mature and ready for adoption by DevSecOps.

• Continuous security testing. DAST, penetration testing, and other types of security testing should not stop at the testing phase of the application lifecycle. Testing (e.g., port scans, fuzz testing) should be performed regularly and whenever the team suspects there are new risks in the code. For example, if a newly discovered vulnerability appears in a processor's command set, operations or security support administrators should take action. When testing confirms a potential vulnerability exists, they can immediately begin developing and deploying new patches.

• Alerts and reports. Security tools and policies need to be paired with comprehensive alerting and reporting. Developers and project stakeholders should receive actionable intelligence to support timely identification and remediation of issues.

• Review afterwards. Even with the best security efforts, organizations can still end up encountering security issues in their applications or infrastructure. When a security incident occurs, it is necessary to conduct a post-mortem summary. Teams should work together to solve problems and use the experience to adjust future development and operations efforts to avoid repeating the same mistakes.

4. Microsoft threat modeling tools and their use

Threat modeling is a core element of the Security Development Lifecycle (SDL). This is an engineering technique that can be used to help identify threats, attacks, vulnerabilities, and countermeasures that may affect an application. Threat modeling can be used to shape the design of your application, meet your company's security goals, and reduce risk.

Software architects can use threat modeling tools to identify potential security issues in advance when they are at a stage where they can be relatively easily resolved without excessive cost. Therefore, it can significantly reduce the overall development cost. With non-security experts in mind, this tool makes threat modeling easier for all developers by providing clear guidance on creating and analyzing threat models.

Anyone can use this tool to:

1. Communicate about the security design of their systems.

2. Analyze these designs for potential safety issues using proven methods.

3. Propose mitigations for security issues and manage mitigations.

Some of the tool’s features and innovations:

1. Automation: Guidance and feedback on drawing models

2. STRIDE per Element: Guided threat analysis and mitigation

3. Report: Security Activities and Testing during the Validation Phase

4. The only way: Give users a better visual understanding of threats

5. Designed for developers and software-centric: Many methods are asset or attacker-centric. This tool is software-centric. The solution builds on activities familiar to all software developers and architects - for example, drawing software architecture

6. Focus on design analysis: The term "threat modeling" can refer to both requirements and design analysis techniques. Sometimes it refers to a complex hybrid form of the two. Microsoft SDL's threat modeling approach is a focused design analysis technique.

There are five main steps in threat modeling:

1. Define security requirements.

2. Create an application diagram.

3. Identify threats.

4. Mitigating threats.

5. Verify that the threat is mitigated.

Five Steps to Threat Modeling

Threat modeling should be part of a typical security development lifecycle, allowing us to optimize threat models and reduce risk over time.

Get Started with Microsoft Threat Modeling Tools[4]

0. Download and install Threat Modeling Tool. Visit https://aka.ms/threatmodelingtool

1. Start Microsoft Threat Modeling Tool

Microsoft Threat Modeling Tool

2. Select the "Create Model" option.

Click on the "Create Model" option

Add Azure App Service Web App

Add Azure SQL Database

2. In the right panel, search and add Azure App Service Web App and Azure SQL Database, and link them to display the request and response flow as shown in the figure below.

Form request and response flows

3. In the toolbar menu, select "View" -> "Analysis" view. The analysis view displays a complete list of threats classified by severity.

4. To generate a complete report of threats, select "Reports" -> "Create Full Report" in the toolbar menu, and then select a location to save the report.

The system generates a complete report that includes details of the threat, applicable SLDC stages, possible mitigations, and links to details.

Threat modeling tools can help answer certain questions, such as:

1. How does an attacker change authentication data?

2. What would be the impact if an attacker could read user profile data?

3. What happens if access to the user profile database is denied?

STRIDE model

To better illuminate such salient issues, Microsoft uses the STRIDE model, which categorizes different types of threats and simplifies overall security communications.

We can perform operations such as status annotation, priority changes, and comments for different threats.

Threat Modeling Tools Risk Mitigation

When we use the Microsoft Threat Modeling Tool to create, configure and analyze the model, that is, after defining security requirements, creating application diagrams, and identifying threats. We need to mitigate threats, and we can refer to risk mitigation categories for subsequent steps.

Risk Mitigation Category

Threat modeling tool mitigations are classified according to the Web Application Security Framework [5] and include:

It can help identify:

1. Where do the most common errors occur?

2. Where can the most feasible improvements be implemented?

Therefore, you can use these categories to focus and optimize your security efforts so that you can start from these locations when the most popular security issues arise in the input validation, authentication, and authorization categories. Final verification that the threat is mitigated.

Quote:

[1]What is DevSecOps? | IBM (https://www.ibm.com/cn-zh/topics/devsecops)

[2]OWASP Top 10:2021 list (https://owasp.org/Top10/)

[3]Secure development best practices on Microsoft Azure | Microsoft Learn (https://learn.microsoft.com/zh-cn/azure/security/develop/secure-dev-overview)

[4] Microsoft Threat Modeling Tool 概述 - Azure | Microsoft Learn 

(https://learn.microsoft.com/zh-cn/azure/security/develop/threat-modeling-tool)

[5]Risk Mitigation - Microsoft Threat Modeling Tool - Azure | Microsoft Learn 

(https://learn.microsoft.com/zh-cn/azure/security/develop/threat-modeling-tool-mitigations)