Cloud infrastructures are built on many of the same technologies as traditional infrastructures, which are hosted...
on-site at an organization or at a data center. However, the scale of accessible data and third-party trust in resource management is the differentiator between those cloud infrastructures. Just as threat modeling a traditional infrastructure is necessary to protect information assets, threat modeling a cloud infrastructure is required to protect business relationships, regulatory obligations and contractual agreements.
Threat modeling is the process of deconstructing computing resources such as software or hardware to identify possible attack vectors. Deconstruction is important because computing resources are a system of interoperable components, each containing a possible weakness. Mature organizations ensure threat modeling is embedded within all technology projects. Why? Any time technology is designed, implemented, modified or removed, there is potential for introducing vulnerabilities that may compromise the information infrastructure.
Threat modeling paths
Traditional threat models fall into one of threepaths: adversarial, software development or risk-based. Adversarial models are based on the perspective of an attacker -- act and think like a hacker. Software development models are based on the features in software and are exhaustive. Risk-based models are based on information assets, such as credit card numbers or personally identifiable information.
Threat modeling cloud infrastructures cannot take one path; each path is composed of cloud infrastructures. Therefore, the modeling should be approached based on use case, enabling automatic deconstruction of each component of the cloud infrastructures during the systems development lifecycle (SDLC). In the past, SDLC equated to the software development lifecycle. Over time, it has been recognized that any system being planned, designed and deployed must adopt and follow a structured process to reduce infrastructure interruptions. When engaging the business, ensure that all technologies are considered systems and a structured process for their deployment is followed. Consider partnering with other leaders in your organization to implement a systems development lifecycle rather than focusing on the software development lifecycle.
Three steps to threat modeling
Threat modeling, regardless of the type, involves three steps: adversarial views, system security and threat determination. When examining adversarial views, consider attackers unknown and external, as well as known and internal, to the organization. When examining system security, the end-to-end system should also be considered. For example, a content management system using Microsoft's Active Directory to authenticate users that requires rules on the firewall to access the Internet is an end-to-end system rather than just a content management system. Additionally, understanding an end-to-end system informs the understanding of data flow. Data flow informs the entry and exit points of adversaries and enables the deployment of appropriate countermeasures and controls. Finally, threat determination eliminates threats that are not applicable, thus reducing the threat landscape. For instance, if a Web farm is running Apache, there is no need to consider Microsoft IIS exploits.
While not exhaustive direction, this simple formula is the key to performing successful threat modeling:
Caption: Combining the threat landscape with data flow produces threat vectors.
Use case threat modeling
Use-case modeling focuses on the services offered to support the cloud to consumers, administrators and partners offering attackers vectors of compromise. Administrative use cases offer the greatest opportunity for compromise due to the level of privileged access and trust across systems. However, since early 2000, organizations have become more responsible in securing administrative systems. Attackers have focused on client-side attacks to gain access with great success. They typically look for a single compromise to access systems. Once they find it, they look for other vulnerabilities that act as steppingstones to a greater compromise. Partner use cases should also be examined since they are granted a level of trust to operate within a cloud infrastructure. Attackers are aware of this trust, and where a partner's security is weak, a compromise will occur.
The diagram factors both egress and ingress data flow because once attackers gain access through an entry point, they must exit. Based on the above diagram, be prepared to apply threat modeling throughout the development and maintenance of the cloud infrastructure. Modeling may begin with the infrastructure components, then with applications and finally, with use cases. Threat modeling is not cyclical but rather an on-demand, systemic process. The goal is to determine entry and exit points for attackers, because enough of the exploits are blended threats. A blended threat is an exploit consisting of multiple types of malware. Code Red, Nimda and the Aurora hacks are examples of blended threats. The Aurora hack used about 12 different exploits with a known entry point via TCP port 25 using a whaling attack, the exit point being an encrypted tunnel over TCP port 80.
An attack may begin as a consumer attack and end with the exploitation of administrative and partner weaknesses.
Use-case threat modeling shows that deployment is a true defense in depth strategy, where the most critical cases are considered. The outcome is a multidimensional defense in depth model.
About the author:
Ravila Helen White is the director of IT architecture for a healthcare entity. She is a CISSP, CISM, CISA, CIPP and GCIH, and a native of the Pacific Northwest.