Using threat modeling to ensure better security

Do you think that a software can never be breached simply because one has bought the best of IT equipment, firewalls, and antivirus? Well, think again! By the end of this post, you might begin to re-evaluate your security parameters.

Any compromise on customer data means a breach of trust, which means an organization’s reputation can get eroded. In this blog, we will focus on how Development and Operations teams can use automation to save customer’s data through a DevSecOps culture.

The current scenario

Before beginning with security automation, we should first understand our immediate focus area for automation, where our high-value assets are more vulnerable. As shown in Figure 1 below, the Cyber Insider Report 2019 records show that database vulnerability is at 56% while filesystem data is 54% vulnerable to insider attacks because it has customer data over volumes, followed by endpoints (51%).

Figure 1: Assets which are most vulnerable to insider attacks

                                                                                                 Source: Cyber Insider Report 2019 - Fortinet

How can threat modeling help?

An overview

Threat modeling is a part of the design process, which helps make the right decisions to build security into the architecture and integration. It helps in identifying the areas which are more vulnerable to an attack. Security experts can find the best-fit threat model for platforms based on the guidelines defined by the compliance team, which we can further automate by using DevOps to bring in a real DevSecOps culture.

Threat modeling methodologies

To build such a model, we can evaluate different threat modeling methodologies to identify structural vulnerabilities and prevent attacks. Security experts, architects, and business stakeholders can work together in choosing the methodology that fits them best:

• STRIDE – a developer-focused model to identify system threats in 7 different categories, using Microsoft’s data flow diagram.
• P.A.S.T.A. – an attacker-focused model to provide an asset-centric mitigation strategy. It uses the process of attack simulation and threat analysis to identify and rank threats.
• Trike – It uses the threat model as a risk management tool that can help in the security auditing process. Security experts build a requirement model and create a DFD (Data Flow Diagram) to define the boundaries of the system. This method builds a risk model based on assets, roles, actions, and calculated risk exposure.
• VAST – A recent enterprise-focused model which covers the entire SDLC, operations, and can be integrated with the DevOps methodology.

A phased approach to implementation

Irrespective of the model you choose, the real challenge is the implementation of the methodology. The solution lies in automation, where the DevOps evangelists can help to bring threat modeling into a real-time automated process. Based on my experience across different ecosystems, various threat analyses, and discussions with various security and compliance experts, I have found that any organization can implement threat modeling successfully through the following phased approach:

Step 1. Define the security requirements: Ask for the security requirements defined by your compliance team. There are several regulatory bodies that can help you in defining these standards. For example, CIS benchmarks help you safeguard systems, software, and network against today’s evolving threats. As most of our infrastructure is on the cloud, many cloud providers now, help in implementing these guidelines. For example, AWS security hub provides its findings against security standards like CIS or PCI DSS, which can be utilized to set the base of automation.

Step 2. Enable team with security threats and experience: Installing various security tools doesn’t make everything foolproof. We can still play with our customers’ sensitive data if we cannot use those tools effectively and efficiently. Before direct implementation, we must understand the security focus areas within the development and operations teams. Microsoft has recently published security design principles, which can be leveraged for a quick start within the continuous delivery pipelines. To do so, the following checkpoints can help:

• Provide and help teams to embed certified security libraries within codebase as an extra layer of security using automated pipelines.
• Integrate static application security testing (SAST) and dynamic application security testing (DAST) with penetration testing within the built pipelines.
• Automate infrastructure provisioning to avoid human error.
• Prepare and rollout the automated patching process to mitigate exposure to common vulnerabilities.
• Use only certified tools and methods provided by the compliance team and automate the process for its verification.

Step 3. Identify assets: Along with a company’s intangible assets like trade secrets, execution plans and intellectual property, we must also focus on technology assets. Today, engineers are using various ways to keep cloud-applications scalable and cost optimized. While working towards solutions like scalability or a dynamically changing infrastructure, we need to keep the inventory up-to-date at any given point of time. An automated infrastructure auditing process can build a structured and controlled inventory, create the setup of an automated architecture.

Step 4. Build a framework: After identifying our high-value assets, we should build a framework which can dynamically generate the architecture of the infrastructure. In today’s world, these architectures are volatile and require automation to identify the threat-prone areas. This process can comprise many inputs such as load balancer logs, firewall rules, network logs, patching updates, etc. Almost all the cloud and on-premise infrastructure providers can help in getting these details. The objective here is to strengthen the threat model with authentic and real-time infrastructure details.

Step 5. Create an application process flow: The next step is to create an application process flow diagram. There are many tools that can build this diagram automatically. The challenge here, though, is to keep it updated with respect to the business drivers and capabilities, and in compliance with the defined policies and guidelines. Software leaders like Microsoft are already providing threat detection tools using Data Flow Diagrams (DFDs), which we can utilize as a starting point to get insights. Further, such tools can be automated by using already injected security modules within code, identifying modules based on business requirements, customized log mechanism, defining and identifying entry points for attackers, verifying checksum of external dependencies, and tracing application data flow.

Step 6. Identify threats using AI/ML: To keep up with the rapidly evolving threat landscape, many organizations, including Nagarro, have already started working on implementing AI/ML platforms to detect anomalies. At the implementation level, we have already put a dynamic architecture builder and a decomposed application view in place. The next step is using smart modules which can not only detect threats based on the existing data but can also suggest improvement areas using various threat patterns. It is important to integrate these automated models with inputs from an existing DevOps toolchain within the organization because every feature is already passing through these toolchains and leaving their quality trails behind.

7. Manage threats visually: In one of my previous blogs, I have talked about how we can bind the DevOps world within a service catalog. The data dashboard in the blog can help organizations to manage threats visually and do performance analysis using defined KPIs. If we can integrate customized views of our dynamic architecture builder, application decomposer, and critical paths based on threats, it will provide us with a real-time view of the entire ecosystem and the auditing process as well.

Step 8. Evaluate organization’s security maturity: Measuring maturity is important for successful implementation. Many organizations have based their DevOps maturity on some core pillars to help in identifying the maturity of any platform. One of the must-have pillars is security. Here, we can start ranking every threat based on its severity level and evaluate the platform against all the identified areas. Additionally, we can enhance this automated model by establishing security benchmarks for various levels or stages and setting minimum acceptable limits for assets of different values that can be improved over time.

Figure 2: Phased approach for successful implementation of threat modeling

Bottom line

Several methodologies are available for threat modeling, which an organization can adapt based on their needs and maturity. Security as code implementation, as described at different levels, will help organizations in creating robust platforms to fight against cyber-attacks and keep client data protected. Certainly, this will be a time-consuming process that needs to pass through multiple continuous feedback and improvement processes, but the completion of every phase will only strengthen your DevSecOps approach.