Building A DevSecOps Culture with Threat Modeling

Why DevSecOps is Important?

The consideration of security is an issue that has been around for as long as systems have been developed. However, the pressure to quickly bring new products to market and roll out frequent updates conflicts with traditional security control development’s more measured and meticulous approach.

Educating developers to embrace security as part of the process has always been a challenge: user awareness and the increasing frequency and sophistication of cyberattacks pressures developers to improve application security. In addition, security by design is now seen as a positive marketing tool for leveraging sales.

Steps for Building a DevSecOps Culture

Many development companies claim to implement DevSecOps to gain that tick in the box but are they doing it correctly? It goes beyond considering security as an agenda item in the development checklist, and organizations must integrate security into their business culture. This move can be a challenge where a DevOps business has evolved rigid development process. Adding the ‘Sec’ into the business processes often requires going back to basics and rewriting procedures.

A common mistake is to add a security expert to the development team and expect them to shoehorn their controls into the development as a parallel activity. Instead, the whole development team requires training to become skilled in security consideration and implementation so that everyone has a responsibility to design and implement secure applications. In addition, development tools and processes must support the seamless integration of security, not treat it as a bolt-on function to existing practices.

The transition from DevOps to DevSecOps is a culture change supported by training, tools, and processes. Therefore, it must be viewed as an investment into end-product quality rather than viewed as a development overhead to be effective.

It’s crucial to remember that there is no one correct solution for DevSecOps and no off-the-shelf culture to adopt. The following points provide a road map, but the destination depends on the exact nature of the business taking the journey.

1- Knowledge is Key

Thorough developer training is vital, as a viable culture requires knowledge and experience; otherwise, a business runs the risk of adding the additional workload of integrated security but still ends up with an insecure product full of weaknesses and vulnerabilities. Furthermore, the better trained the developers, the more effective the protection with lower impact on project timescales.

2- Transparent Integration

To be accepted into business processes, security must be an integrated part of the development process, an integral part of the Continuous Integration and Continuous Development (CI/CD) pipeline.

Automated tools that complement development and deployment processes are a significant benefit. From code analysis and dependency testing to security scanning, tools are available to support operations. Unfortunately, DevSecOps often fails when the security processes are isolated, performed separately, and open to bypassing when time pressures override good practices.

3- Encourage Openness

All stakeholders must embrace the DevSecOps goals and recognize the benefits to remove any friction that the additional workload can bring to a project. All personnel must be onside, supporting the processes and accepting the consequences.

Businesses often suffer from the effects of siloed departments; bringing development and operations together into a DevOps approach was challenging. Bringing security into the equation requires everyone’s cooperation, facilitated with open and honest communications between stakeholders and business-wide buy-in.

4- Integrated Reporting

Traditionally security issues are reported separately from development metrics. Project management focuses on progress against milestones and timelines, security focus on problems and occurrences. Developers are measured on productivity, the lines of code completed in a period. Security is measured in reported incidents and identified vulnerabilities.

With the whole development team responsible for security in the DevSecOps culture, management needs new metrics and reporting that combine all these factors to maintain productivity that simultaneously encourages good protection.

5- Small Steps or Long Strides

Changing culture can take time, mainly if there is initial resistance to change. While one option is to throw away the DevOps processes and start from scratch in a big bang approach, larger organizations may benefit from evolution rather than revolution. Small frequent changes that follow a prescribed route can get to the required cultural endpoint with less friction. Every successful step will weave security deeper into the culture, becoming ingrained as second nature by stealth.

6- Automation is the Answer

Adding security responsibilities to the development team is necessary, but it doesn’t have to be complicated. Tools and practices are available to simplify this change and prevent mental overload. The codification of security and policies as code is available to streamline this process by taking security documentation and putting it into a code structure that developers understand.

Automated processes can pull security into the CI/CD pipelines with minimal developer effort and limited impact on production flows, encouraging adoption.

Threat Modeling Explained

The primary method of reducing vulnerabilities is using threat modeling techniques to leverage knowledge, experience, and intelligence to identify credible risks and possible weaknesses.

Threat modeling facilitates identifying potential threats, allowing developers to devise controls and countermeasures to mitigate these threats. The goal is to eliminate the threat or at least reduce the risk to an acceptably low level. 

Threats come from two primary sources. First is human error in the development processes that introduce weaknesses and vulnerabilities in code. Techniques such as automated CI/CD pipelines with integrated Security as Code significantly reduce these risks. The second is external threat actors, hackers, and their malware. 

Threat modeling allows assessing risks from the attacker’s viewpoint, understanding their mindset to identify risks. This approach can reduce product vulnerabilities and the associated effort required for remediation and update deployment.

Threat modeling applies to the development environment as well as the developed products. The ability to compromise development systems and inject vulnerabilities into product code is an effective method for attackers looking to compromise the end customers for the code. The developer is seen as an entry point in the supply chain for an attack on a more lucrative target further down the chain. The SolarWinds attack demonstrated just how effective this strategy could be for a sophisticated attacker.

For cloud-based development, Kubernetes is now one of the most commonly used container orchestration systems. Its widespread adoption makes it an attractive target for attackers to refine their methods and apply them across a broad range of target organizations. However, one of the main challenges for Kubernetes users is the complex configuration issues inherent due to its flexibility and adaptability.

Misconfiguration offers attackers opportunities to find and exploit weaknesses. In addition, all applications have inherent security vulnerabilities that are identified over their lifetime. Kubernetes is no different. Following identification of vulnerabilities, notifications and security patches will follow. Thus, attackers have a window of opportunity between identification and patch installation to exploit the vulnerability. Also, more capable attackers may identify unknown vulnerabilities that are open to exploitation in a zero-day attack.

If you’re a Kubernetes user, take a look at our top Kubernetes security best practices.

Using Threat Modeling for your DevSecOps Culture

Traditionally, security vulnerabilities were treated as an operations issue problem. Identifying weaknesses or compromises of the product would trigger operations to request code changes and roll out updates or security patches.

Creating a DevSecOps culture that promotes end-to-end security awareness reduces the likelihood of vulnerabilities existing. It makes rectifying issues and updating deployment quicker and easier as everyone immediately understands the problem and has a stake in the solution. In addition, involving stakeholders across development and operations in the threat modeling process will promote security awareness and process buy-in, reinforcing a positive security culture and greater understanding of the issues.

Integrating Threat Modeling

Integrating threat modeling into the DevSecOps lifecycle is straightforward. Threat intelligence drives the security requirements defined in the planning phase. The developed threat models, implemented using Security as Code, integrate transparently into the development processes. Code analysis and dependency tests verify that threats are countered, supported by application security scans to validate the product's security. Continuous monitoring and updates to threat models that identify vulnerabilities in the deployed product result in product updates

Figure 1: Integrating Threat Modeling into DevSecOps

Conclusion

The integration of security into the DevOps philosophy brings significant long-term benefits. Where security is considered only as an afterthought, the cost of implementing security controls into a developed system is significantly higher than the inclusion of the controls as part of the development process. Often the more costly bolt-on controls will be less effective and more prone to weaknesses than those implemented as part of the development process. 

An effective DevSecOps culture provides significant benefits across development, security, and operations. A thriving culture eliminates the silo mentality, encourages cross-discipline collaboration, and enhances teamwork.

The critical benefits are the early identification and elimination of potential vulnerabilities that improve product quality and reduce maintenance effort. In addition, those issues that escape detection will tend to be less complex and quicker to resolve. Overall, customers will have a more reliable, dependable, and stable product.

Magalix empowers organizations to integrate security as code into development processes and culture. This service allows businesses to enforce security standards and reduce risks across infrastructure and embedded in DevSecOps workflows. Additionally, it will enable infrastructure monitoring that quickly detects and responds to security issues.

To learn more about how we can support your DevSecOps processes, please get in touch.