(Introduction to) Simple Cloud Threat Modelling

The observation that people using complex, heavy and formal security frameworks miss and don’t understand very basic security gaps of modern IT ecosystem led me to the decision to write about the need for simple cloud threat modelling.

Well established security frameworks are very formal and resemble waterfall. In ever changing IT world we need agile approach also for security modelling. We must understand modern technologies and adapt quickly to market changes. We want to create a simple cloud thread modelling, easy to understand and apply.

Areas of interest

We want to divide IT landscape into well defined managable pieces. First of all let’s define top level areas: Internet, Cloud, Intranet, End User Computing.

As the Internet we understand the untrusted network external to the Cloud and the Intranet together with edges of these using public IP addresses. We used adjective untrusted. In next paragraphs we are going to use labels: trusted, untrusted, partially trusted for IT areas whuch will help us to understand danger and risk. If the resource is untrusted it means that in its scope we should expect unmitigated danger and risk. If the resource is trusted it’s not the source of danger, because all risks and defined, continuosly measured and mitigated. If the resource is partially trusted it means that the risk management doesn’t cover all possible dangers but most common or from the same perimeter. We assume an area to be a container of resources. The Internet is a container of machines connected via common global network.

As the Cloud we define third party container for resources delivering Infrastructure as a Service, Platform as a Service and Software as a Service. Cloud is trusted or partially trusted. Why? Let’s focus on it for a moment. The cloud vendor delivers you an isolated cloud deployment unit — VPC/VNet. This unit is by default created just for your account or subscription — it’s only for you. Inside VPC you can create VMs or databases or other resources. The cloud vendor promises you to deliver secure environment. VPC uses Software Defined Network with AES-encrypted underlying physical network. There is no risk that some other Cloud client may enable promiscous mode and listen to your network traffic. In ideal world the Cloud would be fully trusted. But the world is never ideal: virtualization platform for computing and network may not be fully written by the cloud vendor (Xen, KVM) and may have software bugs which can be exploited. Also physical hardware like CPU may have security bugs in silicon. We assume Cloud to be partially trusted. Of course if you use very specific subset of the cloud for which you are certain about security you may assume full trust.

We have also Intranet (on-premises network connected to the Cloud via VPN solutions like Direct Connect, Express Route) and End User Computing (laptops or desktops connected to Intranet or to the Internet). If EUC resource is fully controlled by the company (hardended OS with dedicated policies, Anti-Virus, Internet Security package, network traffic and mail filtering) we can assume EUC to be partially trusted. Why not fully trusted? The OS, AV, IS, mail client may have software security bugs. What about BYOD private laptops used to connect to the desktop in the cloud? Without Anti-Virus, with outdated Windows 7? Definitely not trusted.

We have basic areas (containers with resources) defined and we touched the subject of the trust. Let’s explore it.

The trust level

If we know that we covered all risks for the particular resource and none of its dependencies are untrusted we assume that the resource is trusted. If in the proximity of the resource there is an untrusted resource the trust level usually should be downgraded to the partially trusted (unless all risks of the untrusted are mitigated).

Example: We have Windows 10 laptop with all installed security updates, Next Generation Anti-Virus with Internet security and hardened policies and settings, however the latop is used at home and connected to the untrusted Internet. The laptop is considered as partially trusted. The laptop connected to the Intranet (on-premises network in the building you work in) is trusted because the Intranet is trusted.

We can model threats in the cloud using graph — vertices would be our resources and edges would be our labeled dependencies: trusted label would be green, partially trusted amber and untrusted red. The color of labels would have impact on the color of a vertex. We should consider routes between vertices. If there is at least one path between a pair of vertices it means that we must manage the risk between these 2 resources. The idea is simple but powerful.

The tool

We need a lot of A4 papers or a whiteboard and markers: red, orange, green, black or the Archimate. We draw areas with perimeter and resources inside then apply colorized edges.

Our private cloud resources accessed from a laptop at home are safe provided that the laptop is not the source of the danger — the user can’t access the Internet directly but only via a security proxy like Palo Alto, Menlo, McAfee Web Gateway, ZScaler. We assume on-prem VPN to be fully trusted.

The untrusted Internet is the source of a danger

The analysis

1. EUC vs Cloud

A laptop at home should have all up to date security patches for the OS, active Anti-Virus and/or Internet Security with current definitions and enforced Internet traffic tunelling via security proxy.

• An end user may be a target of a dedicated attack exploiting vulnerabilities in the software and hardware of the laptop.
• An attacker may want to intercept credentials used to access cloud resources for further lateral movement and data exfiltration (visibility: use access/audit logs on resources, mitigation: use RBAC with minimal privileges), discover the IT landscape (visibility: detect port scanning), steal confidential documents (mitigation: use DLP) or encrypt device to demand a ransom.
• Having intercepted access credentials to software development resources an attacker may steal the source code of an application to find weaknesses used in future attack or inject changes into codebase, data or configuration. Please note here that changes to AI training data changes behaviour of AI solution.
• An attacker may also be internal — employee, contractor (visibility: user activity monitoring with telemetry).
• An end user may get too broad access to cloud resources due to wrong configuration of resources or vulnerability (visibility: access logs, mitigation: RBAC with minimal privileges, continous reporting and review process)

The software development environment in the cloud should not have resources accessible without authentication or for all users and should not be exposed directly to the Internet.

—

2. Intranet vs Cloud

An attacker having wide access to the Intranet may execute Denial of Service attack against throughput of the cloud — on-prem data link. As a result business continuity of applications requiring cloud — on-prem connectivity would be disrupted.

—

3. Internet vs Cloud

Public resources

• Configuration error or vulnerability of Internet facing cloud native resource may lead to unathorized or too broad access. As a result confidentiality, integrity, availability issue may arise(visibility: access and audit logs, mitigation: limit the exposure of cloud resources to the untrusted Internet). A configuration error is also a lack of access control for databases and cloud storage.
• Configuration error or vulnerability of Internet facing application resource may lead to unathorized or too broad access. As a result confidentiality, integrity, availability issue may arise(visibility: access and audit logs, mitigation: use Content Delivery Network, Web Application Firewall, API gateway, reverse proxy, facade and similar solutions providing possibility to whitelist and blacklist URLs, IPs, filter requests, cut off traffic etc., apply layered security together with layered software architecture, use microservices and agile software development and Continuous Delivery (CI/CD) to quickly fix issues in application code base).
• A special case of a configuration error or vulnerability of Internet facing application resource is an error when unsanitized user supplied data processing results in malicious code injection and the malware is served to the consumers of the service (for example malware injected into Web page, spreading on devices of page visitors). Malware may be injected into Web page, database, cloud storage.
• Distributed Denial of Service attack (visibility: access and telemetry logs, mitigation: use Content Delivery Network, Web Shield, API gateway and similar solutions providing possibility to dynamically whitelist and blacklist URLs, IPs, filter requests, cut off traffic etc.)

Software development

• Version Control System (Git) must not be exposed publicly in the Cloud. The risk is unauthorized access to the code base (stolen source code), unauthorized changes. Repositories should have private access to limited set of users.
• Software packages should not be integrated directly from the Internet. Remote repository might be compomised and the software replaced with malicious version. All sofware packages should be integrated using local package repository with synchronization from remote repos, vulnerability scanning, posibility to block infected packages as well as finding affected applications via dependency management. This is true for maven, npm, containers, etc.
• Agile software development, CI/CD, DevOps and SecDevOps are preferred practices allowing to quickly mitigate security issues in supply chain management and security bugs. Static code analysis should be mandatory.

Exfiltration

• An attacker may use own cloud resources to upload stolen data. Any access to unknown cloud accounts should be blocked (for example via content-aware security proxy). Impersonation (for example via STS AssumeRole) should be filtered via cloud policies.

4. Third party risk

For every resource or for some subset we may consider the aspect of third party risk. It may materialize as a security bug of an Intel CPU powering a cloud server, as a low detection of malware by your Anti-Virus, as a insecure SaaS, etc.

Summary

• It’s very important to discover and document all possible resources and dependencies.
• Path between resources should contain security labels: trusted, untrusted, partially trusted. These labels should be discussed among security experts, application owners based on possible risks, probabilities and mitigations.
• This map should be regularly updated also taking input from developers and software architects.
• Your map may be different comparing with enterprises from the same business domain. It should be adjusted carefully to your company.
• Use Archimate.

A starting point of a cloud security modelling using Archi Tool.