Threat modeling is a structured methodology used to analyze the security of an application or information system. It is a proactive means of identifying security requirements, integrating security throughout the lifecycle of development, and it can ensure security mechanisms are maintain throughout the product lifecycle. According to Peerlyst, there are five threat modeling methodologies, each with a different approach; commonality amongst them is a rather time consuming process flow.1 Executives do not have time to perform exhaustive threat models. However, it is essential to provide business partners and the board a succinct understanding of the organization’s threat landscape.
Defining the Threat Landscape
The threat landscape of an organization is the collection of environments and technologies that store, process, and transmit information they own or are custodians of. In the case of ECS, the fictitious cloud provider we’ve been using as an example throughout this blog series, its threat landscape is composed of its hosting domain, service oriented architecture, and technology stack (see Figure 1), all of which is documented in the master reference model.
Additionally, the threat landscape extends to any key partners or customer segments that ECS exchanges information with, which are identified in the business model. For example, at least three of ECS’s value propositions will host information from customer segments, those being Adaptive Readiness, Golden Years Federal, and Golden Years State Retirement. Hosting that information is likely achieved by establishing various trust conduits such as single sign-on through federation of identities along with periodic extract, transform, and load (ETL) processes minimally. Once trust has been established between a customer’s or partner’s environment, those environments are also components of your threat landscape because compromise may be achieved from their infrastructures.
A threat landscape generally comprises hosting, services, technology, and people resources respectively. From a systems perspective, the complete threat landscape is the total sum of the internal and external threat landscapes, forming a superset of interoperable resources as depicted in Figure 2.
Internal and external threat landscapes are made up of the same system components. Differentials are based on implementation and technology choices.
Hosting Resources
The way a solution is deployed, the type of cloud service, and the tenant model make up an organization’s hosting resources and provide the basis for the threat landscape. Why? This is how the data may be accessed by legitimate and non-legitimate consumers. Understanding the architecture of hosting solutions along with their strengths and weaknesses is the first step in building multi-dimensional security. For example, protection mechanisms used for IaaS are quite different from those used for SaaS. Where the organization is responsible for security compute technology in IaaS, SaaS security is mostly the responsibility of the cloud provider, with the organization assuming only minimal responsibility at the application layer. Taking on the role of an attacker, how might you access a multi-tenant SaaS solution deployed in a public cloud? What about a single tenant IaaS solution hosted in a private cloud?
Services Resources
Service Oriented Architecture (SOA) provides access to all management and consumer services of an information system. Services are supported by protocols, for example, SOAP over HTTPS, message queue (MQ) over SMTP, or SFTP. This second layer of the threat landscape is important because it has the potential to provide trusted conduits through which an attacker, after gaining access, can escalate privilege and initiate data exfiltration. All components of SOA must be protected based on the conduits of trust, along with opportunities of compromise. For example, firewalls with access control lists (ACLs) and policies as well as intrusion detection systems (IDSs) placed at the perimeter are not effective controls for a database containing personally identifiable information (PII) or payment card information (PCI). Rather, role-based access control along with encryption are effective controls for that use case. Services are supported by technology and often determine when and how attackers gain access.
Technology Resources
Appliances, platforms and operating systems, applications, and customer software compose the technology resources of the threat landscape. When accessed by a service, they may provide a stepping stone to compromise should either an unknown or unpatched vulnerability be exploited. Vulnerabilities can also be the result of poor configuration decisions such as flat network architectures or defaults system and application passwords. All technology that composes information systems must be protected based on operational and performance feasibility. This adds yet another dimension of security to the threat landscape.
People Resources
The final consideration of the threat landscape is people; people must have accounts to access technology. They must use technology to access other technology and services, and the relationship is one to many. Such a relationship introduces the possibly of compromise through a single person. Consider an on-call system administrator. We can expect staff in this role to have administrative access across multiple systems and zones, therefore ensuring their technology and accounts are well protected is of primary concern. A missed laptop patch or passwords that are transmitted unencrypted may lead to a newsworthy security breach.
Executive Threat Model
Now we can threat model the threat landscape. Remember, the threat landscape consists of the technologies of the business model’s value proposition, partner, and customer segments. The Threat Logic Cube shown in Figure 3 is a cyclical model that positions sets of simple, situational questions. This enables communication of high-level risks and concerns to executive peers and the board. It also provides a basis for a tiered defense model in that the questions are situational based on the context, resulting in a mesh of controls across the threat landscape.
Sanity Check
If you’re an Information Security leader, can you now identify the threat landscape from a high level, based on a business model? Would you try to threat model using the Threat Logic Cube?
If you’re part of the technical staff, given the executive threat landscape or the completed Threat Logic Cube, could you perform further threat modeling to create a control architecture?
In part 4, we will discuss control priority and placement.
