How to do Threat Modeling for Cloud Applications
Table of Contents
Forbes Magazine recently ran an article titled Why Threat Modeling Is Now A Critical Business Skill. You know a technology is starting to become mainstream when it gets published in a business periodical. But threat modeling isn’t new—it’s been around for two decades. So what’s changed? The cloud.
Software developers have known about threat modeling for a long time. And to a greater or lesser degree, have embraced it. Along the way, it has evolved from a slow, manual process to something that better leverages technology to be faster and more repeatable. But, it was still mostly used for software development, and then things started moving to the cloud.
Once workloads, and even whole datacenters, began moving to the cloud, it became clear that the same insights threat modeling provide for software development, it could provide for everything in the cloud. And that brings us up to the present.
Today, threat modeling for all applications in the cloud is becoming a best practice for organizations that understand it’s a lot smarter to be proactive about cloud cybersecurity. Moving security “to the left” just makes good business sense. Here we will explore why and how to do threat modeling for applications in the cloud.
What is threat modeling?
Threat modeling is a proactive approach to identify the entry points on a system’s attack surface, enumerate the threats and implement security controls. Its intended goal is to prevent security breaches.
The starting point for threat modeling has been and always will be a visual depiction of a system’s architecture. Technically speaking, threat modeling is not limited to software systems. Any system, or even organization, can (and probably should) have a threat model built. But for the sake of this discussion, we will focus on software systems.
The best way to grasp software threat modeling is to understand what it started from and what it has evolved into. Modern threat modeling probably began with Microsoft’s introduction of the STRIDE methodology back in 1999. STRIDE is just an acronym for the types of threats which can act against software. In essence, it provided a memory aid (i.e., a checklist) for developers to think through a system’s data flow. Of course the visual depiction of the system had to be done manually in the early going.
So, in the early days, threat modeling was a manual process applied to a software system and that system, most likely, resided on a corporate server somewhere within the organization. The threats were mostly limited to internal threats, as the cloud hadn’t reached widespread adoption yet. And the threat model’s effectiveness was limited by the practitioner’s expertise.
Fast forward to today. Almost every application is in the cloud, which means there are both internal and now external threats. It also means that creating software has morphed from application development (AppDev) to development operations (DevOps). The implication? Threat modeling is much more complicated, but is still limited by the practitioner’s expertise. That’s why many companies that do threat modeling are forced to bring in third-party experts to do their threat models for them.
Threat modeling has evolved from a one-time project to an ongoing process to where it is today in the most advanced organizations: a company-wide capability. Along the way many tools, platforms and knowledge bases have been developed to help automate and speed up threat modeling. And that automation and speed are essential, because in the cloud, things change fast, and they never stop.
What is a cloud service provider?
There’s a saying, there’s no such thing as the cloud, it’s just someone else’s computer. It’s true, and that someone else is a cloud service provider (CSP).
A CSP is a third-party company offering cloud-based services on a pay-per-use basis. Those services are delivered via one of three cloud models: 1) Infrastructure-as-a-Service (IaaS); 2) Platform-as-a-Service (PaaS); and 3) Software-as-a-Service (SaaS). They offer these services in public clouds (open to any organization), private clouds (intended for a single organization), as well as hybrid clouds (a combination of the two).
There are three, well-known, major public cloud providers:
- Amazon Web Services (AWS);
- Microsoft Azure; and
- Google Cloud Platform (GCP).
Each has their advantages. For instance, AWS is probably the easiest to use, Azure’s the most cost effective and GCP is best for data analytics and artificial intelligence (AI). There are also hundreds of other cloud providers all over the world.
The one thing all CSPs take seriously is cloud security, which is the subject of the next section.
How secure is cloud computing?
The big misconception with cloud cybersecurity is that it is completely handled by the CSP. And that’s just not the case.
When it comes to cloud security, CSPs employ what’s referred to as a shared responsibility model. In this model, the CSP is responsible for some things and the customer is responsible for other things. One way of looking at this is, the CSP is responsible for security “of the cloud” while the customer is responsible for security “in the cloud”.
The details vary by CSP, but in general, CSPs take responsibility for all the hardware and software that comprise the cloud infrastructure. That includes things like compute, storage, networking, physical plant, HVAC, etc. Customers are responsible for everything that utilizes the infrastructure. That includes things like customer data, applications, guest operating systems, access management, configurations and encryption.
So, how secure is cloud computing? According to a Gartner prediction, through 2022, 95% of cloud security failures will be “attributable to user error.” In other words, cloud cyber security depends almost entirely on customers using the cloud securely. CSPs mostly uphold their end of the cloud security bargain.
Of course it is difficult to get a quantitative sense for how many security breaches there are in the cloud. That’s because CSPs and most cloud users prefer not to report a breach. The takeaway should be that if you use the cloud in a secure way, your data in the cloud will be secure.
How do you keep your cloud data secure?
At the risk of oversimplification, keeping your cloud data secure is a two-step process: identify the threats and put controls in place to thwart those threats.
According to the Cloud Security Alliance, there are 11 Top Threats to Cloud Computing. They are, in order of significance, as follows:
- Insufficient identity, credentials, access and key management
- Insecure interfaces and APIs
- Misconfiguration and inadequate change control
- Lack of cloud security architecture and strategy
- Insecure software development
- Unsecured third-party resources
- System vulnerabilities
- Accidental cloud data disclosure
- Misconfiguration and exploitation of serverless and container workloads
- Organized crime/hackers/APT
- Cloud storage data exfiltration
This is a fluid list and continues to be impacted by new technologies including edge compute, IoT, OT (operational technology), blockchain, ZTA (zero trust architecture) and SDP (software defined perimeter). The good news? Every item in the list above is directly controllable by users/developers.
Many of the items in the above list detail how cybersecurity in the cloud differs from on-premises cybersecurity. But probably the biggest difference is not included in that list, and is discussed in the next section.
How does cloud cybersecurity differ from on-premises cybersecurity?
As previously mentioned, one difference between cloud and on-premises cybersecurity is the introduction of more external threats in the cloud. But, ultimately, a threat is a threat, and you deal with all of them the same way: identify them and put a control in place.
But there is another difference of cloud security which may be even more impactful: in the cloud, everything is self-service. That means developers don’t have to ask the IT department for a new server or storage, they can just click a button. And with greater independence, comes greater possibility for security mistakes.
The possibility for these unchecked (and potentially insecure) changes to the cloud infrastructure is why it is paramount to put policies and procedures in place which govern changes. It’s also why threat modeling is an essential aspect of cloud security. Threat modeling is a way to proactively ensure the change you’re about to make doesn’t induce a vulnerability.
So, quick changes to cloud infrastructure have the potential to induce insecurities. There are actually two ways to make quick changes to cloud infrastructure. The first was mentioned above: self-service. The other way is in response to Infrastructure-as-Code (IaC).
IaC is a way to provision cloud infrastructure through code, rather than manually (i.e., with the click of a button). In essence, IaC automates cloud infrastructure provisioning, which is a great idea, as it saves developers a lot of time. But it also means that the infrastructure is always changing, and it can be a challenge to secure a cloud environment that is always changing.
How do you secure a cloud environment that is always changing?
Cloud computing and cyber security coexist in a tenuous relationship. In cloud computing, things tend to change fast.
Generally speaking, when you’re trying to secure something, fast changes are not something you want. So, how do you secure a cloud environment that’s always changing?
Again, at the risk of oversimplification, it’s a two-step process: first you baseline security and then you monitor for changes. What should you baseline? You could start with the 10 Realms of Cloud Security Services as reported by the Security-as-a-Service Working Group of the Cloud Security Alliance:
- Identity and access management
- Data loss prevention
- Web security
- Email security
- Security assessments
- Intrusion management
- Security information and event management (SIEM)
- Business continuity and disaster recovery
- Network security
The idea behind this list is to provide cloud users greater clarity on security while simultaneously limiting their financial burden. That balance of security and cost is an important one, as every company has a finite security budget.
When it comes to cloud security, there must be a way to prioritize security threats. Prioritizing threats helps an organization understand which threats require an immediate investment, because they pose an existential threat to the organization, and which ones are less critical. So, how do we prioritize threats in a cloud that’s always changing? Threat modeling.
What is cloud threat modeling?
It might seem that all threat modeling does is “model threats”, and while that may have been true initially, it no longer is.
Remember, current threat modeling is not just a tool or technique, it’s a company-wide capability. And that capability produces a lot of useful information.
In addition to identifying threats, the process of threat modeling produces security requirements, test cases, CIS benchmarks, best practices, validated security controls and compliance violations (if any). It also produces one more thing: it identifies doomsday scenarios.
It is this alignment of doomsday scenarios with identified threats which helps prioritize security investments. This is where you want to invest in security controls. Where a lack of controls can cause the most organizational damage. It’s one of the most important benefits of threat modeling.
Cloud threat modeling brings all this capability into the cloud. It helps companies understand where to make investment when securing their cloud deployments. And it does all that by executing on the two steps mentioned above.
In the most advanced forms of cloud threat modeling, an initial scan is done of the cloud environment which looks at each and every service and resource in detail, gathers information and analyzes it. Then, it follows that up by doing a periodic scan to look for changes in the environment and sends an alert when one is detected.
It is this ability to automate threat modeling that makes it feasible in the cloud. Without that, it would be an unmanageable manual process which leaves a lot of security gaps. Cloud threat modeling is automated threat modeling.
What industries would benefit most from cloud threat modeling?
While every company that deploys in the cloud should do threat modeling, there are three industries in particular that can really benefit from it.
That’s due to the stringent compliance requirements imposed on organizations in those industries. The industries are banking, healthcare and education.
A holistic approach to threat modeling identifies threats to data governance and compliance, in addition to security threats. And in the three industries mentioned above, governance and compliance requirements are strict and complex. Failures in these areas can result in fines, as well as lost business, for companies in those industries
Compliance requirements that apply to Fintech companies in general and banks in particular include PCI-DSS (credit cards); KYC (know your customer); AML (anti-money laundering); SEC Rule 17a-4 (data retention requirements); and SCI (System Compliance and Integrity). These are just the ones at the U.S. federal level. There may also be state and international requirements.
In the healthcare industry, there are compliance requirements that apply to patient care, billing, reimbursement, managed care contracting and even OSHA. The big one is HIPAA (Health Insurance Portability and Accountability Act), but there are others from Medicare, Medicaid, the FDA and DEA. And again, these are just those at the federal level.
If you don’t work in education, you may not know. But the industry is almost as tightly regulated as the other two, mostly around student privacy. Key regulations include FERPA (Family Educational Rights and Privacy Act); COPPA (Children’s Online Privacy Protection Act); PPRA (Protection of Pupil Rights Amendment); and CIPA (Children’s Internet Protection Act). All of these can be violated without the right controls in place. Controls that are identified by the proper use of threat modeling.
What is cloudmodeler
CloudModeler, by ThreatModeler, is a utility which integrates right into the AWS and Azure platforms. It has all the functionality of ThreatModeler, plus the automation necessary to operate in the cloud.
CloudModeler scans already-built workloads and builds a threat model based on the components. CloudModeler then updates the threat model to reflect any changes to the infrastructure (i.e., additions of or modifications to a component).
Of course CloudModeler comes with all the standard ThreatModeler capabilities, which include the Intelligent Threat Engine, an automated threat intelligence framework and threat model chaining.
The Intelligent Threat Engine (ITE) automatically identifies all the relevant and applicable threats to each component, gathers the associated security requirements and test cases to provide the information needed to respond to the threats.
The threat intelligence framework is a central repository for managing, detecting and alerting users of potential threats. By automating this process and updating the repository in real-time, CloudModeler saves businesses time from these normally manual processes.
Just like ThreatModeler, CloudModeler now comes with threat model chaining. Threat model chaining provides detailed insight into the interactions that occur between standalone threat models for each application component, the supporting systems and the infrastructure.
How do you integrate CloudModeler with your cloud service provider?
With CloudModeler, there’s no hardware to purchase or software to install. CloudModeler is a SaaS (software-as-a-service) and integrates with AWS and Azure via an API (application programming interface).
CloudModeler does use several services offered by the CSPs, including storage, compute and the API Gateway service. CloudModeler also uses specific services from the CSP to validate security requirements.