Today’s cloud security requires a new way of looking at threat models. Making a threat model can support your security teams before problems start. It helps them develop a strategy for handling existing risks, instead of detecting incidents at a later stage. Let’s walk through how to create a threat model that works for your cloud landscape.
The Open Web Application Security Project (OWASP) defines threat modeling as “a process for capturing, organizing and analyzing all of the information [that affects the security of an application].”
By the end of making one, you should have a list of “security improvements to the concept, requirements, design or implementation.”
Why Does Threat Modeling Matter?
A threat model shows parameters that explain a threat. For example, it might cover the built-in risk factors, threat agents, potential attack road maps, business impact assessments and remedies. In the field of software security, threat models help spot threats to systems and data — from tech-driven threats such as web exploits to wider risks such as unwanted system access or insecure data storage.
There are many threat assessment methodologies, like Microsoft’s STRIDE. STRIDE — which stands for Spoofing, Tempering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege — helps security experts and developers find threat vectors in these categories.
Creating a threat model at the design stage helps throughout the system development life cycle. Teams can learn the controls and automate cloud security infrastructure from beginning to end. Therefore, threat modeling should occur at an early stage of your system development.
Let’s get started. Here are the best steps to building a threat model.
1. Choose the Right Team for Your Cloud Security
A threat modeling process should include people from teams across different disciplines. A security team member will serve as the risk owner of the process. The security team, web developers, software engineers, operations team and business segment owners might all be important members.
Working with the expertise of multiple, mixed groups involved in app development, testing scenarios and business delivery will provide a more holistic vision of what you are designing. That includes what could go wrong in the process and how to rectify or mitigate risk over the long term.
2. Understand the Boundaries of the System
Once your team is ready, it’s time to analyze what the trust zones and scope of the system are. Just be cautious not to make the system boundary too large — as you increase the scope of the boundary, it gets more difficult to model. Map out all the application architecture to understand the data flows and actors involved. A data flow diagram is the usual way of doing this.
OWASP has some guidelines, which look at the following factors:
- The trust boundaries modeled within the system.
- The threat actors or agents that interact within and outside of the trust boundaries of the system.
- Information flows in various directions within and to/from the trust boundaries.
- Information persistence within and outside of trust boundaries for data modeling.
- The potential threats and existing risks to these trust boundaries.
- Threat actors or agents that exploit known openings.
- The impact and likelihood a threat agent could exploit an opening.
3. Consider Risk Factors to Cloud Security
When you have a list of threats to your applications and system, you need to determine what type of controls you will put in place to reduce them. If you don’t configure the various things required to implement the system boundaries properly, they could impact your threat model in a big way.
For example, take a look at your cloud security infrastructure design and the control plane services to start with. Many companies face at least one critical security misconfiguration. The term “critical” was coined because some configuration issues allow an attacker to gain access directly to private database services on the cloud provider management console. These issues could also be used to hide criminal activity from auditing and monitoring services. The increased volume of data breaches happening via open ports on the cloud impacts workloads on cloud providers’ private and public subnets.
Once your assembled team has defined what your app threat model is and the most important production applications, it’s time to work on a remediation plan.
4. Execute a Remediation Plan
The first and foremost step in designing this plan is to rank the risks based on which are the most severe. You could do this using a ranking method in risk assessment methodology. Next, rank each threat that exploits a vulnerability by how critical it may be. Choose a team member to fix these threats from high to low, starting with the most critical. You must define a risk owner for every risk to ensure someone covers all your threats.
In the cloud, your workloads will access other services at various entry points via an application programming interface call or via other external users. Other mechanisms help in accessing a cloud-native environment from an on-prem data center. For example, you might encounter a cloud access security broker architecture or federated identity management. In that case, you should try to minimize the access with trust zone boundaries and entry zones. Using a cloud service provider, like an Amazon Web Services (AWS) architecture framework, Google Cloud Platform, or Microsoft Azure, ensures that you provide a consistent and measured approach across your risks to mitigate them without any performance or scaling issues.
There are various threat modeling tools on the market. For example, the OWASP Threat Dragon and Microsoft’s threat modeling tool provide various built-in features that help to deploy apps in the cloud. These restrict access based on roles or attributes and public key infrastructure services. That helps to keep systems safe without making the team less secure or less efficient.
5. Audit and Monitor Workloads
It’s important to understand the need to monitor and track your apps’ status on the cloud on an ongoing basis. You can do this using tools like Azure monitor logs and storage analytics or AWS cloud trail and cloud watch logs. Other popular cloud platforms, like Caveonix and IBM OpenStack, help improve application pervasiveness and provide layered and cloud-native security.
The big advantage of threat modeling is that it helps provide a holistic view of potential issues by focusing on threats, not weaknesses. This will make your cloud security posture more robust.
Simply put, threat modeling is a logical way of thinking about what your system and apps can or cannot do. By focusing on threats rather than weaknesses, you can leverage your technical niche and get a wider view of your posture using a cloud-native approach.
The post How to Design and Roll Out a Threat Model for Cloud Security appeared first on Security Intelligence.
