How to do Threat Modeling for Cloud Applications

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.

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:

1. Insufficient identity, credentials, access and key management
2. Insecure interfaces and APIs
3. Misconfiguration and inadequate change control
4. Lack of cloud security architecture and strategy
5. Insecure software development
6. Unsecured third-party resources
7. System vulnerabilities
8. Accidental cloud data disclosure
9. Misconfiguration and exploitation of serverless and container workloads
10. Organized crime/hackers/APT
11. 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.

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.

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.

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.