Guest post by Rodrigo Rocha
In the past few years, many companies have moved to the cloud. It’s a movement that offers many benefits for businesses, but these benefits come with increased risk and vulnerabilities. Before we continue this article, it’s essential to understand what a Cloud Native Application is.
If you search on the web about what a Cloud Native Application is, you can probably find a list of descriptions. But according to the Cloud Native Computing Foundation, a Cloud Native Application is defined showing us these concepts:
“Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
The Cloud Native Computing Foundation seeks to drive the adoption of this paradigm by fostering and sustaining an ecosystem of open-source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.”
CNCF, 2018-06-11
A cloud native application is an application that uses a more distributed structure. The application was previously structured in a monolithic code, hosted internally, and maintained by teams that worked separately. This new approach to building applications using cloud-native technologies, such as containers and microservices optimized for scalability, performance, and reliability.
The current scenario for a cloud native application shows that this model is growing fast. This is confirmed when we look at research that shows increased adoption of this type of application architecture. Research published last year by Tigera shows that 75% of companies focus on cloud native applications. And to reinforce these numbers, Gartner shows that by 2025 95% of total applications will be deployed on cloud structures.
As we can see, cloud native applications are here to stay, and we need to adapt our tools to this new reality. One of these tools that we need to adjust is threat modeling. In cloud native applications, the traditional threat model approach shouldn’t be used anymore.
Traditionally, threat modeling was used to examine a monolithic application, which, most of the time, was hosted internally. This scenario is changing, and we need a new approach to modeling threats. There are plenty of articles about these topics, like cloud security, cluster security, container security, and code security, usually called securing the 4Cs. All of these are important, but if your developer team neglects threat modeling, they may put a lot of risk on your infrastructure and your applications.
OWASP describes threat modeling as a way to search for an application and the potential threats to which this system can be exposed. This methodology is one of the essential aspects of SDLC (Secure Development Lifecycle). However, in a world of cloud applications, it is insufficient, and we need to get a much wider point of view.
How can I use threat modeling in cloud native applications?
In a cloud native approach, we have many more scenarios that can be found because cloud structures are more dynamic and change every time you have a new component or a simple change in one element.
The fact that the applications reside in the cloud changes how we need to leverage threat modeling. For example, the threat model must be more flexible or at least used to look for security requirements in smaller parts of the application. (Divide and conquer).
But we also need to change the way that threat models are executed and need to understand that threat models need to be more cross-functional. Basically, the introduction of the security champions and the execution of the threat model in interaction and incremental models can solve most problems of the oldest model.
Threat modeling by a lone individual or a small group is no longer sufficient to cover all potential threats to a system. Regularly appearing new attacks make the threat modeling landscape highly complex, often rendering previous assumptions outdated.
Today cloud applications are more complex and dynamic. This requires the professional to adopt another approach and search for other professionals’ point of view. This mix of experience and knowledge can be positive for the application security process.
One of the most important actors in this new scenario is the developer, and they need to understand that it is important that they have this knowledge. It’s a normal scenario in the development process. We have a lot of changes per day in one application, which enforces the developer’s urgency to work continually with the threat model.
The threat model in a modern design implies a constant revision of the threat model. Applying tests to validate the security requirements identified by the threat model, use of automation to help in the process of scalability, and use of other professionals like secure experts, architects, or even business stakeholders.
Best practices for threat modeling in a cloud-native environment may include the following:
- Collaboration: Involve developers, security experts, and business stakeholders in the threat modeling process to ensure a comprehensive and holistic approach.
- Automation: Consider using automated tools to streamline the threat modeling process and reduce the risk of errors or missed threats.
- Continuous threat modeling: Incorporate threat modeling into the development process and update the model as the application evolves.
- Threat modeling for microservices: Consider each microservice as a separate component and perform threat modeling on each individually to ensure complete coverage.
- Integration with security testing: Integrate threat modeling with security testing to validate the effectiveness of the mitigation strategies and identify new threats.
One of the most important aspects of cloud native applications is that the attack surface changes every time. And every time you scale microservices up or down, you’re changing the attack surface, and your threat model needs to adapt to this.
At this time, one of the most important things to do is to understand that the attack surface will change every time, and we need to use the threat model as a live document revised and updated every development cycle. This live artifact needs to be revisited every time something changes.
Understanding how the application works and how it uses the cloud architecture is vital to the security professional to create a threat model that can really identify the application threat.
Every developer needs to know how they can make a threat model or even interpret the results of a threat model project.
Threat modeling must be more flexible and cross-functional, involving various experiences and knowledge from different professionals, including developers. Threat modeling must become an ongoing process, with regular revisions and validations through testing and automation to ensure the proper security of cloud native applications. Developers need to understand the urgency and importance of threat modeling in cloud native applications and work continuously with it to minimize risks and vulnerabilities.