20230403分享-ATT&CK & D3FEND with a CAVEaT

ATT&CK & D3FEND with a
CAVEaT
Discovering the Challenges and Plotting
a Course for Cloud-Specific Adversary
Modeling
© 2023 Cloud Security Alliance – All Rights Reserved. You may download, store, display on your
computer, view, print, and link to the Cloud Security Alliance at https://cloudsecurityalliance.org
subject to the following: (a) the draft may be used solely for your personal, informational, non-
commercial use; (b) the draft may not be modified or altered in any way; (c) the draft may not be
redistributed; and (d) the trademark, copyright or other notices may not be removed. You may quote
portions of the draft as permitted by the Fair Use provisions of the United States Copyright Act,
provided that you attribute the portions to the Cloud Security Alliance.
© Copyright 2023, Cloud Security Alliance. All rights reserved. 2

Acknowledgments
Editor-in-Chief
Mari Spina
Contributing Authors
Tim Wade
Robert Marcoux
Paul Deakin
Bob Klannukarn
Kerry Long
Andy Radle
Eric Arnoth
Rebecca Choynowski
Oscar Gokce
Alex Reyes
Mari Spina

Table of Contents
Acknowledgments��3
Editor-in-Chief��3
Contributing Authors��3
1. Background��5
2. Considerations for an Adversary-Oriented Cloud Threat Model��6
2.1 Technology and Cloud Service Coverage��6
2.2 Content of a Cloud Threat Model��7
2.3 Use Cases for a Cloud Security Threat Model��8
2.4 Technology for Threat Model Curation��9
2.5 Unique Cloud Security Stakeholder Considerations�� 11
2.6 The Role of Government Regulatory and Security Guidance �� 11
2.7 Industrial/Societal Considerations for Threat Information Capture�� 12
3. Capabilities of an Adversary-Oriented Cloud Threat Model�� 13
3.1 Threat Model Content Objectives�� 13
3.2 Service Provider Specific Threats and Mitigations �� 13
3.3 Emerging Threats Relevant to Cloud Systems��14
3.4 Threat Information for Cloud-based Cyber Analytics �� 15
3.5 Levels of Information Abstraction�� 16
3.6 Value-Added Content Capture, Curation, and Dissemination�� 17
4. Recommendation�� 19
5. APPENDIX A: Tabletop Example using CAVEaT:��20
5.1 Introduction to CAVEaT��20
5.2 Planned CSA CAVEaT Working Group��20
5.3 Tabletop Exercise Using Cloud Specific Content �� 21
Step 1: Initial Access - Traditional ATT&CK Technique T1078.004 - Valid Accounts�� 21
Step 2: Command and Control -Traditional ATT&CK Technique T1573.002 - Encrypted
Channel�� 22
Step 3: CAVEaT Enumeration – CAVEaT-Modified ATT&CK Technique T1580 - Cloud
Infrastructure Discovery�� 22
Step 4: Credential Access - CAVEaT Modified ATT&CK Technique T1552.005 - Unsecured
Credentials��24
Step 5: Lateral Movement – Traditional ATT&CK Technique T1021 – Remote Services�� 25
Step 6: Collection Tactic – CAVEaT-Modified ATT&CK Technique T1530 - Data Collected

from Cloud Storage�� 25
Step 7: Exfiltration – CAVEaT-Modified ATT&CK Technique T1537 - Leveraging SaaS
Applications�� 27
Step 8: Execution - CAVEaT-Modified ATT&CK Technique T1059 - Leveraging Cloud Shell28
Step 9: Persistence - Traditional ATT&CK technique T1136.001 - Create Account��28
Lessons Learned��29
6. APPENDIX B: Existing Frameworks – Detailed Overview��30
6.1 CAPECTM��30
6.2 NSA/CSS Technical Cyber Threat Framework v2 ��30
6.3 ATTACK®�� 31
6.4 FiGHTTM�� 31
6.5 ATLAS™ �� 32
6.6 D3FEND™�� 33

1. Background
A variety of cyber threat models are available to cybersecurity practitioners. A review of those threat
models indicates the need for a cloud-centric threat model that addresses unique aspects of cloud
environments and Cloud Service Provider (CSP) offerings, and covers theoretical content necessary
to keep pace with the rapidly changing cloud technology landscape. Prominent threat models in
use today by security practitioners are examined in Section 6 APPENDIX B: Existing Frameworks –
Detailed Overview, and summarized below.
• CAPEC™: Common Attack Pattern Enumeration and Classification (CAPEC)1 is a method

for organizing patterns of attack to understand how cyber adversaries operate. The attack
patterns are those generally found in operating systems, networks, and applications but
don’t address cloud-specific threats.
• D3FEND™: Detection, Denial, and Disruption Framework Empowering Network Defense
(D3FEND) is focused on the specific countermeasures (i.e., mitigations), and this knowledge
graph captures well-documented mitigations and links to ATT&CK techniques but does not
directly address cloud environments.
• FiGHT™: The MITRE 5G Hierarchy of Threats (FiGHT) is a curated knowledge base and TTP,
serving as a model for the operators, customers, and suppliers in the 5G ecosystem. While
incorporating some cloud-specific threats, and not limited to real-world observed adversary
activity, it focuses on cloud use by 5G operators.
• MITRE ATLAS™: Adversarial Threat Landscape for Artificial-Intelligence Systems, or MITRE
ATLAS, is a knowledge base of adversary tactics, techniques, and case studies for machine
learning (ML) systems. Although ML and AI threats are applicable in cloud environments, the
scope of ATLAS makes it too limited for general cloud threat use.
• MITRE ATT&CK®: The MITRE ATT&CK2 Matrix knowledge base provides a curated, common
lexicon for the communication of real-world observed adversarial behavior between
cybersecurity practitioners. As a result, some practitioners may require TTP content that is
more predictive in nature and includes Application Program Interface (API)-based and CSP-
specific threats.
• NSA/CSS Technical Cyber Threat Framework v2: The NSA/CSS Technical Cyber Threat
Framework v2 (NTCTF v2)3 is a technical extension of the Director of National Intelligence
(DNI) Cyber Threat Framework and focuses primarily on a common technical lexicon for
adversary activity. Its general nature and lack of cloud specifics make it difficult to use
operationally for cloud environments.
1 (CAPEC - Common Attack Pattern Enumeration and Classification (CAPEC™) (mitre.org)

2 MITRE ATT&CK®
3 ctr-nsa-css-technical-cyber-threat-framework.pdf

2. Considerations for an Adversary-
Oriented Cloud Threat Model
Developing a threat modeling and information collaboration platform can be a daunting task.
Many issues must be considered including those addressing technology, information content,
content usage, content curation, stakeholder needs, involvement of government, the regulatory
environment, as well as societal and industrial factors that drive businesses. Below is an examination
of specific considerations that should be addressed when setting out to seed and cultivate a threat
modeling and information content collaboration solution that involves industry providers and
practitioners toward improving the security of cloud-based systems.
2.1 Technology and Cloud Service Coverage

Historically, the complexity and nuance of cloud technologies have been simplified to “just
using someone else’s computer.” This statement emphasizes the high degree of third-party risk
that organizations acquire when they migrate from self-owned and self-managed on-premises
infrastructure to cloud services that are provided by CSPs. One considerable component of that risk
is the increased technical complexity, such as the abstract interconnects of cloud computing. These
interconnects present unique security challenges that differ both by the nature of the underlying
technologies as well as the nuanced implementations that vary from CSP to CSP. Generally, those
technologies can roughly be divided into at least the following variants.
Infrastructure as a Service (IaaS): The closest analog to traditional data center technologies, IaaS
threat models offer the most common ground with traditional threat models and taxonomies, such
as MITRE ATT&CK.
Software as a Service (SaaS): While aspects of traditional threat models are applicable, particularly
related to identity-layer modeling, significant control and visibility is removed relative to traditional
application security methods.
Cloud-Native Infrastructure, Platform as a Service (PaaS) and Function as a Service (FaaS):

Representing a suite of technologies most divergent from traditional datacenter technologies, Cloud-
Native infrastructure runs the gamut from Kubernetes clusters to functional, serverless applications.
This class of cloud technologies is least likely to be represented by prior art.

2.2 Content of a Cloud Threat Model
A comprehensive cloud threat model must address the following considerations and be scoped to
contain the described capabilities.
Hybrid Interconnectedness: There is a layer of cloud-centric threat modeling that must necessarily
consider the hybrid nature of the modern enterprise. While entirely self-contained cloud attacks
exist, and are threatening in their own right, the blast radius of a cloud attack often exploits the
interconnectedness of the modern enterprise. Attacks may originate in an on-premises network and
migrate into the cloud, begin in the cloud as a means of pivoting to the on-premises network, or
may be used as a bridge between network legs that might otherwise be segmented. Cloud to cloud
attacks should also be anticipated.
Unique Threats by Cloud Delivery: The various service models (e.g., SaaS, IaaS, and so on) create
challenges for threat modeling. For example, while IaaS resembles a traditional enterprise network,
SaaS significantly differs in both structure and functionality. Similarly, cloud-native application
architecture in PaaS contains unique concerns. For this reason, the term “cloud” itself may be too
abstract for sufficiently defining the threat models that exist between the different cloud capabilities
available. Some concepts may not translate effectively between the variations in cloud services and
may result in threat models that do not provide meaningful, actionable information of the threats
and risks faced by cloud operators and customers. The differences in the cloud services models also
lead to differences in mitigation and detection of those threats.
Abstraction necessary to manage the unique CSP constructs: The account interface in a cloud
service may feel substantially different than one in a traditional on-premises enterprise environment.
More importantly, an individual CSP’s implementations of core cybersecurity capabilities may have
non-trivial differences from other CSPs. An effective threat model taxonomy needs to communicate
capability implementation details at an abstraction level that not only informs cloud service
consumers but also fosters CSP understanding of security needs in order to promote the delivery of
essential security building blocks.
Flexibility against volatility: Unlike traditional networks whose protocols are controlled by (semi)
strict RFCs, cloud services are akin to an airplane being built in mid-flight. CSPs are continuously
adding to and evolving their services. This produces volatility in the very technology that adversaries
will operate in driving substantial changes to their behaviors and attack patterns. To accommodate
this volatility, threat-models will need flexibility in their definitions and structure and be adaptable
over time.
Cyber Threat Intelligence scope boundary: Because CSPs own the underlying infrastructure that
customers of cloud services use, conflict of interests may deter these service providers from
providing timely, forthcoming, and publicly documented intelligence about adversary activity and/
or capabilities that impacts their customers and the public. This potential dearth of insight into
real-world happenings may present blind spots that prevent accurate modeling of threats for cloud
providers and customers.

2.3 Use Cases for a Cloud Security Threat Model
A well-designed threat model supports many use cases for stakeholders in the cybersecurity
community and industry. Examples may include, but are not limited to, the following.
Threat-Informed Defense: Cybersecurity defenses must take into consideration how adversaries
behave and operate, whether on-premises or in the cloud. A threat model should be a systematized
representation of adversary TTPs, ideally based upon observed behavior of real-world adversaries.
As such, it is a prime instrument for defenders to choose mitigations to prevent adversary actions,
detections to observe adversary activity, and plan defenses in advance to provide a minimal attack
surface for the most optimal cost-benefit ratio.
Threat Actors
Cloud Service: Adversary Tactics,

Threats and Techniques, and
Mitigations Procedures (TTPs)
Defensive Tools Critical Assets:

and Techniques Commercial, USG
Cyber Threat
Intelligence
Adversary Emulation: This is the process of assessing the security of an organization’s technology
environment by applying Cyber Threat Intelligence about specific adversaries to mimic how they
operate. The focus should be on the ability of an organization to verify detection and/or mitigation
of the emulated adversarial activity. Threat models can help create scenarios to conduct adversary
emulation by providing a structured profile of coordinated adversary activities i.e. campaign or
scenario driven sequence of behaviors. These profiles can then be used to help inform cyber security
planning, penetration testing, and cybersecurity operations like threat hunting.
Section 5 APPENDIX A: Tabletop Example using CAVEaT provides an example of a paper-based

emulation of a cloud specific attack scenario. It illustrates the use of threat models and attack
scenarios and highlights the need for cloud-specific content useful for the cloud security practitioner.
Red Teaming: This is the process of attempting to breach a defended environment in the same
manner that an adversary would. A threat model framework can be used to develop red team plans
that avoid defensive measures that might be in place in a cloud environment. The red team uses an
adversarial mindset and attempts to apply adversary techniques to see what impact can be achieved.
Red teaming is not limited to techniques seen and published; theoretical and lab proven techniques
can also be used by a red team to help validate the feasibility and utility of a specific technique.

Cyber-investment Planning: Threat models can help drive cyber investment planning. Knowing
what adversaries are likely to target in an organization and what their general capabilities are can
help determine the potential attack surface, vulnerabilities, gaps, and weaknesses that an adversary
might exploit to penetrate and operate within that environment. Organizations can then couple this
awareness with the available architectures, products, and operational models needed to identify cost
effective risk mitigation strategies.
Identify Mission/ Identify Mitigations Conduct Portfolio

Assess Risk against a Conduct Sensitivities,
Business Process & and Assess Cost & Analysis, Optimize
Threat Model Prioritize Mitigations
Critical Assets Impact ‘ROI’
Defensive Capability Assessment: The existing defensive capabilities of an organization’s technology

environment can be assessed by leveraging the adversary capabilities identified in a threat model.
Product features, operational models, and architecture can be studied and compared with profiles of
possible adversary activities, providing a risk-based gap analysis report. This report can then be used
by an organization to determine whether existing defenses need improvements, based upon a cost/
benefit analysis in comparison to the risk.
Threat Intelligence Communication: Since threat models provide structured documentation

of observed and/or potential adversary capabilities and behaviors, they can help convey threat
intelligence within and between organizations. In particular, the structure should include a well-
defined abstract model of the threats being documented, with numbering systems and relationships
between object sets. These object sets can then be referenced in reporting of observed threat
activities. The threat model should be represented in a common and standardized data format that is
used for or facilitates threat intelligence sharing.
Detection Analytic Development: Detection analytic development typically requires knowledge

of adversary tools and/or behaviors. A threat model that provides technical details for adversary
capabilities can thus be used to guide and inform detection development.
2.4 Technology for Threat Model Curation

Building, maintaining, distributing, and operationalizing a threat model may require custom
developed software and standardized data formats that may be informed by the following
considerations.
Cyber Threat Intelligence (CTI) Data Compatibility: Compatibility with leading CTI community
information sharing standards and protocols should be considered to facilitate use, dissemination,
and adoption. Compatibility with STIX4 and TAXII5 protocols that are currently used by the ATT&CK
community and the security industry as a whole, could be beneficial to support integration with and
feeding threat content to ATT&CK as well as support dissemination of threat information to current
CTI channels employing STIX and TAXII.
4 https://attack.mitre.org/resources/working-with-attack/
5 About TAXII (Archive) | TAXII Project Documentation

Collaboration Platform: The development and curation of threat models is currently a subjective
process that is subject to the respective biases of those participating in the process. As such, it
should be a collaborative effort amongst a team of subject matter experts. For such a collaborative
team to operate efficiently and successfully, a collaboration platform is needed to facilitate the
process. For the data to be meaningfully consumed by those seeking to leverage a threat model
for their cybersecurity processes, the data formats used should be widely accepted standards that
facilitate the automated processing of the threat model in conjunction with other data sources, such
as those needed for the use cases of the threat model (see previous section).
Threat Model Representation: One of the challenges in developing a threat model is how to store
the data and structure of the model in such a way that it can be easily distributed and operationalized
for the many and varied use cases that interested stakeholders may have. Looking at the MITRE
ATT&CK Framework as a reference, STIX is employed as the core representation of the entire threat
model in a single file. By leveraging this open-source standard format, the ATT&CK Framework can
easily be distributed and shared, and users of ATT&CK can automate the use of the threat model in
code, leveraging the standard libraries available for parsing and manipulating STIX content. This has
allowed ATT&CK to be consumed by many private and public applications, serving as the foundation
for a broad cyber security ecosystem that utilizes the threat framework as its core.
Other threat models being developed should adopt this strategy, leveraging STIX as a core means of
representing the developed model. Doing so will greatly reduce the overhead and cost of consumers
adapting yet another threat model into their operations and use cases.
Representing a threat model does not need to be constrained to a single format, additional ones
could be used. For example, MITRE FiGHT and ATLAS are both represented in YAML, which provides
some of the benefits of STIX and can be converted to STIX, but representing complex models in
this format can be awkward and problematic for developers who need to consume the model.
Graph visualization and graph database technologies are also popular technology choices for
operationalizing the interconnect nature of threat progression, but these require dedicated server
infrastructure to make use of the formats.
Software to operationalize: For a threat model to be useful to its stakeholders, software is needed
to enable both manual and automated means to implement the various use cases. Software libraries
to consume the threat model and store it in memory for other programs to utilize in a standard,
structured fashion are a critical cornerstone of any software suite built around the threat model in
question. This will enable both public and private software offerings to flourish, lowering the cost of
entry for both the model and its user base.
Software to generate custom heat maps for the threat model (e.g., ATT&CK Navigator) are a
foundational technology to enable key use cases such as Adversary Emulation, Cyber Investment
Planning, and Defensive Capability Assessment. Because of the dynamic nature of offensive
campaigns, software that can graphically capture the progression of adversary behaviors over time
can be extremely valuable (e.g., ATT&CK Flow). Software to enable end-users of the threat model the
ability to edit its content is critical; different organizations may have a unique view and perspective of
the threat landscape. Moreover, an organization’s unique risk model may be challenging to represent
in a generic threat model that’s designed for broad and public consumption.

2.5 Unique Cloud Security Stakeholder Considerations
An effective threat model must consider the diverse stakeholder groups involved in the practice of
security resulting from the shared responsibility model that drives security control implementation
in the Cloud. This typically includes CSPs, Cloud Service Consumers, and Cloud Security Vendors that
stand to benefit from adoption of a threat model framework and be impacted by joint stewardship of
threat model content.
Cloud Service Provider (CSP): Threat models that effectively address threat mitigations can provide
evidence of a CSPs security control efficacy. As a result, CSPs should be motivated to ensure
comprehensive coverage for their security control implementations. Threat modeling outcomes
should identify a CSP’s countermeasures, defense capabilities, and highlight control implementations
available to mitigate risk. Additionally, CSP security offerings will generally differ between providers
so providing a comprehensive view of each provider’s security capabilities will be important.
Cloud service consumers: Cloud security service consumers benefit from threat model content that
facilitates threat hunting, the development of cyber threat intelligence, the creation of playbooks
for ongoing cyber operations, and the implementation countermeasures and mitigations, as well as
inform cloud security solution design for use in modernization and technical refresh projects.
Cloud security vendor: Cloud Security Vendors seek threat models to provide reliable, accurate,
and standardized expectations for cloud control-plane and data-plane telemetry that enable threat
identification, detection, and response capabilities.
2.6 The Role of Government Regulatory and Security

Guidance
Government regulations can play both a positive and negative role in cloud threat modeling. Threat
models can be most impactful if they reflect true adversarial behavior. In the cloud environment,
real adversary behavior and techniques are held closely within the CSP. In other industries, although
a breach may be reported under various legal requirements, the detailed threat techniques
are not necessarily made public. In general, the strongest breach reporting is tied to privacy
related breaches. In 2022, the U.S. Government enacted the Cyber Incident Reporting for Critical
Infrastructure Act of 2022 (CIRCIA)6 which expanded incident reporting to a potentially broad set of
covered entities. The reporting is to the Cybersecurity and Infrastructure Security Agency (CISA).
The scope is notably not limited to personal data breach however, it is limited to “substantial’’ cyber
incidents. For threat modeling, techniques observed by adversary campaigns that are not ultimately
successful can still be valuable, but current regulation does not obligate organizations to share that
information. An incentive-based approach could be considered to encourage sharing of threat and
adversary behavior information publicly. Such a model would likely need to provide some level of
indemnification to reporting organizations as well as address antitrust concerns that might arise
from collaboration among competitors.
6 Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA) Fact Sheet (cisa.gov)

The use of Information Sharing and Analysis Centers (ISACs)7, which exist in many sectors, has
been a way to share information about adversary behavior affecting particular industries. Today,
the information shared doesn’t necessarily leave the ISAC and, to date, there isn’t a clear ISAC with
cloud service providers participating. The ISAC model isn’t the only approach as there are groups
like Global System for Mobile Communications (GSMA)8 that have internal risk and fraud groups that
govern sharing of information among members. A drawback of the ISAC or equivalent approach is
that they can become islands of information also useful for other industries that may not necessarily
be included. This is potentially an issue as cloud technology continues to make its way into so many
business sectors.
A regulatory approach to encourage threat sharing is also challenging in a world with many legal
and regulatory jurisdictions. Cloud providers operate under different regulatory schemes depending
on where they offer services. An approach that works in one legal arena may not work elsewhere.
Regulatory schemes could also significantly disadvantage a provider operating in one country if their
competitors do not operate there as well.
With the challenge of different jurisdictions, a regulatory approach to mandating threat disclosure
seems unlikely but non-governmental frameworks with government support may provide an avenue
for better sharing of adversarial behaviors. Governments can remove disincentives for threat
information sharing and perhaps create incentives for sharing. Bug Bounty programs have been a
positive incentive for responsible disclosure in the industry. Government incentives for disclosure
such as tax credits for participation and liability limitation may be avenues to consider in exposing
vulnerabilities and adversary activity that could impact everyone.
2.7 Industrial/Societal Considerations for Threat

Information Capture
The argument against threat models and public disclosure of adversary behavior still persists in
limited areas such as telecommunications and cloud providers. Reasons given include intellectual
property protection, brand protection, the problem is already addressed so why disclose it, and that
the customer can’t do anything about it so why make it public. This last argument against threat/
vulnerability information leans into the primary counter-argument that has broadly been accepted
by security practitioners. The prevailing practice today is to assume breach and that understanding
the weaknesses and vulnerabilities provides the defender the ability to mitigate known weaknesses
and vulnerabilities commensurate with an organization’s risk tolerance. The argument against
publicizing the info is that an adversary can use that information to attack an organization. This
argument presumes that the adversaries are not sharing techniques and vulnerabilities themselves,
which we know to be false for quite some time9. If one assumes the adversaries are already aware
of the techniques they use, it puts the defenders in an even worse position. The sharing of threat
information puts the defenders on equal basis with adversaries providing the best chance at
mitigating the vulnerabilities and weaknesses.
7 https://www.nationalisacs.org/member-isacs-3
8 https://www.gsma.com/
9 Ablon, L., Libicki, M. C., & Golay, A. A. (2014). Markets for Cybercrime Tools and Stolen Data: Hackers’ Bazaar. RAND
Corporation. http://www.jstor.org/stable/10.7249/j.ctt6wq7z6

3. Capabilities of an Adversary-
Oriented Cloud Threat Model
Cloud security practitioners represent an emerging segment in the cybersecurity profession. It is
understandable that cloud security practitioners will have somewhat unique information needs for
content addressing adversary behavior and mitigation practices. Below is a discussion of threat and
mitigation information concepts useful for the cloud security practitioner.
3.1 Threat Model Content Objectives

A cloud-centric threat model should function as a resource for consumers of cloud services seeking
to secure the new and emerging environments offered by CSPs. This is especially necessary as cloud
services used by customers transitions away from IaaS to more PaaS, SaaS, and FaaS offerings.
To provide the most useful model for cloud consumers in today’s rapidly evolving cloud services
industry, a cloud security-specific threat model should accomplish the following:
• Reuse the schema and expressive nomenclature of the MITRE ATT&CK Framework whenever
possible to foster understanding, content sharing, and adoption
• Provide a focus on the information needs of actual cloud consumers seeking to secure the
cloud services used and systems hosted within the cloud
• Address the cloud-specific nature of an attack of adversarial behavior and its mitigation
• Operate to publish timely partial knowledge rather than wait for corroborating proof of an
attack
• Leverage vendor participation, especially for mitigation information, to improve the
accuracy and effectiveness of threat mitigations.
3.2 Service Provider Specific Threats and Mitigations

The specific threats and mitigations vary dramatically from CSP to CSP, and the variant of cloud
service offers that they provide. For example, SaaS attacks will primarily focus on abuse of policy
and entitlement threats and mitigations, to include intersections with concerns related to data-loss,
while the CSP space will incorporate more robust and diverse threats and mitigations.
Common CSP mitigations and security controls include:
• API Security (e.g., Gateways, Web Application Firewalls, etc.)

• High Availability Infrastructure (e.g., Load balancers)
• Basic Detection (e.g., Amazon Guard Duty)
• Investigation and Correlation (e.g., Amazon Detective, Microsoft Log Analytics, etc.)
• Cryptographic/Key-Management Modules (e.g., Hardware Security Modules)

A model illuminating CSP specific mitigations would be valuable for the practitioner attempting to
understand and implement cloud service-based threat mitigations. For example, in AWS, the solution
you choose will depend upon the threat you are trying to mitigate. AWS suggest that the following
solutions can help to mitigate threats:
• AWS Web Application Firewall

• Amazon Macie – for discovering sensitive data
• AWS Key Management Service for Key Management
• AWS Audit Manager – audits AWS usage to simplify how you assess risk compliance with
regulations and industry standards
• Amazon Guard Duty – a cloud-based threat detection service
• Amazon Detective – an Amazon-based solution for security investigations.
Knowing which of these tools to implement and how to configure them to mitigate specific threats
across an IT service environment can be a daunting task for the cloud security practitioner. Mitigation
guidance that is specific to the threat, the cloud service, and the cloud native security tool being
employed would greatly improve practitioner effectiveness.
Azure, for example, has two main technologies that can be leveraged to protect customer
subscriptions against attacks that utilize Azure interfaces/APIs. The first technology is Azure Policy
in active response mode. In this mode, Azure policy serves as a type of API/interface firewall,
preventing specified changes to Azure resources without requiring manual intervention. The second
technology is Defender for Cloud, formerly Azure Security Center, that can monitor Azure API events
in the Activity log and flag suspicious events through the use of proprietary signatures or machine
learning processes. The chief complaint about Defender for Cloud is that customers have limited
visibility into why an alert is generated and may not be inclined to trust it because of this.
3.3 Emerging Threats Relevant to Cloud Systems

As emerging threats leveraging publicly accessible commercial cloud provider APIs/interfaces
become more prevalent and are more completely cataloged, they deserve a place of prominence
inside a cloud threat model. The greatest divergence between an enterprise-based threat matrix
like ATT&CK and a cloud-based threat matrix will be the increasing preponderance of techniques
that leverage cloud interfaces/APIs in some aspect. Adversaries will soon discover that many
organizations have a blind spot when it comes to interactions with cloud interfaces/APIs. Customers
largely believe that cloud service providers are monitoring and securing this avenue of attack when
this may not be the case. In fact, abuse of Cloud APIs and interfaces is an example of a security
problem that challenges the current shared security model. Customers currently do not have enough
understanding of how these APIs and interfaces work to aid CSPs in securing them and CSPs cannot
do it on their own. When compared with network intrusions like those in the ransomware events,
API data incidents tend to have shorter attack chains, often amounting to nothing more than a well-
crafted HTTP request. Rather than apply the ATT&CK framework to these events, F5 threat research10
narrowed the incidents down to a number of broad categories that, in their assessment, better
captured what is going on and what to do about APIs:
10 https://www.f5.com/labs/articles/threat-intelligence/2021-application-protection-report-of-ransom-and-redemption#_
AttackDetails

• Bad authentication
• Bad authorization
• Misconfiguration
• Insufficient logging and monitoring
• Excessive data exposure
• Un-sanitized input
Two-thirds of API incidents in 2020 were attributable to either no authentication, no authorization,

or failed authentication and authorization. The simplicity of API attacks and the poor state of API
security indicate that the attack surface ramifications of API-first architectures are still not widely
understood.
3.4 Threat Information for Cloud-based Cyber Analytics

Cyber analytics is an important arrow in the cloud security practitioner’s quiver. This is where the
cloud security practitioner will benefit from comprehensive information about adversary behaviors.
It is important to note that cyber analytics applied to cloud environments must consider the specific
cloud service interfaces provided to the consumer. Threat detection data sources will vary by cloud
service provider and associated detection algorithms will have to address cloud service log data. A
comprehensive data model that provides linkages between adversary behavior and observable cloud
system artifacts is essential. Such a model should provide content to support:
• Identification of cyber event logging requirements for continuous monitoring

• Development of threat detection capabilities
• Configuration risk assessment and management

3.5 Levels of Information Abstraction
Various threat models represent threats at different levels of abstraction. The highest levels of
abstraction tend to be found in models such as the Lockheed Martin Kill Chain or Microsoft STRIDE.
Mid-tier abstraction levels have proliferated of late, starting with the MITRE ATT&CK Framework, but
have extended to include ATLAS and FiGHT. Lower levels of abstraction include extremely detailed
technical catalogs such as CAPEC, CWE, and CVE.
While both high- and low-level abstraction models have their place, recent trends have shown the
mid-tier for abstraction to be the most useful for the most stakeholders. High-level models tend to
be too vague to be useful for practical purposes, while low-level models tend to be too complicated,
driving up cost and time needed to operationalize the models in any meaningful use case. As
such, threat models in the mid-tier tend to represent a “goldilocks” zone of abstraction for most
stakeholders and user cases.
ATT&CK Tactic Other Tactic

Category Category
ATT&CK Technique Other Technique

Category Category
Cloud #1 Adversary Cloud #2 Adversary Cloud #3 Adversary Cloud #n Adversary

Behavior Behavior Behavior Behavior
Cloud #1 Threat Cloud #2 Threat Cloud #3 Threat Cloud #n Threat

Detections Detections Detections Detections
Cloud #1 Threat Cloud #2 Threat Cloud #3 Threat Cloud #n Threat

Mitigations Mitigations Mitigations Mitigations

3.6 Value-Added Content Capture, Curation, and
Dissemination
A primary goal of content capture and dissemination should be speed and agility to remain relevant
and useful to the cloud security practitioner. Timely capture, curation, and publication for subscribers
of cyber information sharing organizations. To be useful, cloud security practitioners require threat
information as soon as possibly available. This objective works to help cyber defenders to keep up or
even get ahead of attackers.
Another goal should be to expose the cloud service consumers and security practitioners to the
“how” of a technique and associated mitigations. By focusing on the mechanisms involved in
adversary behavior, victims of cloud-based attacks may be more willing to share the results of their
cyber defense and incident response activities when victim or adversary attribution is not important.
An additional benefit of focusing on the “how” rather than the “who” of an attack is that techniques
discovered through academic studies or penetration testing exercises can be included in a cloud
security specific threat information corpus without altering the perceived effectiveness of the cloud
service platform involved.
For effective content capture, a content submission system and processes should be established. Such
a system should allow for the submission and nomination of content for research and review while not
limiting its discoverability by practitioners searching for answers to critical threat behavior they may be
experiencing. But while submission and publication should be timely, a curation process must exist to
disposition the value of nominated content. In this context, active threat and mitigation information
could be published immediately upon submission and nomination and then be tagged with information
indicating the levels and degrees to which it has been researched, peer reviewed, modified, enriched,
endorsed, and even observed or corroborated in the wild.
Suggestion
Public Comment
Curation
Publication

These can be complicated processes to manage and the definition and application of curation
processes for content nomination, acceptance for review, conduct of reviews, and the inclusion
of authorities will be vital for effectiveness. For example, would it be reasonable for non-CSP
employees to describe a CSP specific threat mitigation? What if the CSP is unavailable to provide
mitigation content? Would it then be reasonable for a university researcher to provide specific
mitigation information if they tested and confirmed the mitigation in their test environment? These
are the questions that a curation team must address with an eye toward timely publication of useful
information with appropriate caveats to inform the consumer regarding the value of the information
as it progresses through the curation process.
Finally, the goal of curation should be to develop the authoritative source for adversary behavior
and threat mitigation solutions so that the information source can operate as a feeder to other
collections of similar information. For example, at some point in the curation process, a theoretical
adversary technique may become corroborated by public events and publications. At this point, the
curation process could make appropriate annotations on content and the results could be allowed
to feed other threat, vulnerability, and mitigation information stores useful to Cloud Security
practitioners such as the MITRE ATT&CK, D3FEND, and CVE, and CSA’s Global Security Database
(GSD)11. In this event, it will be important that internet search results are appropriately deconflicted
from those consumers might receive when searching these datastores. Selection and use of unique
content identifiers will prove valuable in supporting cloud security practitioner research and analysis.
Potential Curation Status Tags
Peer- Accepted by
Drafted Submitted Theoretical Observed
Reviewed Target
(e.g., ATT&CK or
D3FEND, CVE, CWE,
CAPEC, CSA-
GlobalSecurityDB,
OpenCLoudVulnDB, ...)
11 GlobalSecurityDatabase

4. Recommendation
Based on the forgoing discussion, below are specific actions recommended for execution on behalf
of the cloud security industry to advance the art and practice of adversarial analysis and threat
mitigation.
1. Establish a program fostering open reporting of threats: Much of the success of the prior
art with respect to domain-specific threat modeling is predicated on the free exchange of
information inside of the security community. Such information exchange facilitates and
accelerates activities ranging from ongoing threat research, threat activity discovery and
disclosure, and collaboration.
2. Establish a program for Rapid/Agile development/publication of cloud security content:
Core technology and infrastructure stakeholders are dependent on the rapid exchange
of information to make informed, risk-based decisions. Content capture, curation, and
publication must be as rapid and agile as possible.
3. Establish a threat and mitigation content model for cloud security practitioner use:
Cloud security practitioners suffer from extreme complexity when building secure and
resilient cloud systems. A model that comprehensively describes cloud service specific
adversarial behavior and mitigations that are dependent upon specific cloud services for
the predominant CSPs will help to reduce the complexity. Content that easily leverages and
works complementary to the ATT&CK Matrix, D3FEND, and other authoritative information
bases will further facilitate the research and analysis activities of the cloud security
practitioner.
4. Establish an international content curating body: An authoritative body whose membership
includes both the expertise to advise and the credibility to influence should be established
and chartered to facilitate open reporting and collaboration for the cultivation and curation
of authoritative cloud technology and service specific threat and associated mitigation
information.
As an international organization possessing broad industry reach, established industry relationships

with cloud service providers, governments, and practitioners, Cloud Security Alliance (CSA) is well-
positioned to have the greatest impact upon advancing the state of cloud technology-based threat
and mitigation information sharing, curation, and modeling. It is further reasoned that the MITRE
CAVEaT model represents a positive starting point.

5. APPENDIX A: Tabletop Example
using CAVEaT:
This content was originally presented at Cloud Security Alliance (CSA) Federal Summit on October
13th 202212. A Tabletop exercise is a paper-simulated attack scenario designed to reveal an
organization’s security posture weaknesses and facilitate development and implementation of risk
mitigation strategies. This Tabletop exercise uses both traditional and non-traditional data that better
emulates a cloud-based attack.
5.1 Introduction to CAVEaT

The cloud service specific content used in this Tabletop exercise is derived from the CAVEaT Model,
currently being advanced through a CSA-MITRE collaboration. Content presented here from the
CAVEaT model has not been curated. The goal is to provide a technical deep dive on the selected
steps to illustrate the value of performing a Tabletop exercise for cloud systems.
CAVEaT is a threat-based information framework, modeled after the ATT&CK Matrix, to assist in
the assessment of security associated with today’s cloud services. Developed at a middle level of
abstraction, there are three (3) scenarios in which CAVEaT currently accepts an adversary behavior
into its information base:
• Empirical Observation - adversary behaviors from contributed threat intelligence.

• Proof of Concept - adversary behaviors successfully demonstrated in a laboratory setting.
• Theoretical - conceptual adversary behaviors not yet demonstrated in a laboratory setting or
in the wild. It can be better to have a good idea than absolute proof.
5.2 Planned CSA CAVEaT Working Group

At the October 2022 CSA Federal Summit held in Washington DC, the Global Vice President of
Research, John Yeoh, announced the establishment of the CSA CAVEaT Working Group (WG).
The CAVEaT WG is intended to become the industry collaboration body chartered to advance the
development of the CAVEaT model and oversee its content curation. At the summit, John made the
call for interested parties and offered the following email for those interested in getting involved:
CAVEAT@cloudsecurityalliance.org
12 Summary - CSA Federal Summit 2022 (cvent.com)

5.3 Tabletop Exercise Using Cloud Specific Content
The Centers for Threat Informed Defense (CITD) MenuPass13 is the threat scenario used for the
tabletop exercise presented here. The scenario is organized into two attack scenario sequences. For
this tabletop exercise, the MenuPass Scenario 2 was selected. The MenuPass Scenario 2 consists of
the following tactics:
• Step 1 - Initial Access

• Step 2 - Execution
• Step 3 - Discovery
• Step 4 - Privilege Escalation
• Step 5 - Credential Access
• Step 6 - Lateral Movement
• Step 7 - Exfiltration
• Step 8 - Command and Control
• Step 9 - Persistence
The Tabletop security team modified the MenuPass Scenario 2 steps, specifically steps 3 through 8
(out of 9 total) to include pre-curated CAVEaT content. Steps 1,2, and 9 have been left alone as the
traditional adversary behaviors and mitigations also apply for a cloud-based attack. The tabletop
exercise, based upon the modified MenuPass scenario, is presented below. The exercise illustrates
the integration of cloud-specific adversary and mitigation information useful for the cloud security
practitioner.
Step 1: Initial Access - Traditional ATT&CK Technique T1078.004 - Valid Accounts
Adversaries may obtain and abuse credentials of existing accounts. Compromised credentials may
be used to bypass access controls placed on various resources on systems within the network and
may even be used for persistent access to remote systems and externally available services, such
as VPNs, Outlook Web Access, network devices, and remote desktop.[1] Compromised credentials
may also grant an adversary increased privilege to specific systems or access to restricted areas of
the network. Adversaries may choose not to use malware or tools in conjunction with the legitimate
access those credentials provide to make it harder to detect their presence. Possible actions include:
• Reuse Stolen Credentials that were harvested to SSH to box

• Could Brute Force Jump Host Access Account but this will be flagged by Azure
See ATT&CK Matrix for mitigations. The resulting recommendations are to monitor, audit, and
manage account creation, credential handling, and routine end-user training on the use and
management of credentials. Eliminate default passwords and remove inactive accounts.
13 https://github.com/center-for-threat-informed-defense/adversary_emulation_library/blob/master/menuPass/Emulation_
Plan/Scenario2.md#step-4---menupass-privilege-escalation

Step 2: Command and Control -Traditional ATT&CK Technique T1573.002 -
Encrypted Channel
Adversaries may employ a known encryption algorithm to conceal command and control traffic
rather than relying on any inherent protections provided by a communication protocol. Despite the
use of a secure algorithm, these implementations may be vulnerable to reverse engineering if secret
keys are encoded and/or generated within malware samples/configuration files. Possible actions
include:
• SSH Foothold Command and Control Channel (won’t be blocked, EDR might see if
sufficiently configured)
• AptGet Install Azure CLI (won’t be blocked; MS living off the land)
See ATT&CK Matrix for mitigations. The resulting recommendations are to implement network-based
intrusion detection and prevention systems to mitigate and to consider implementation of SSL
inspection for additional effectiveness.
Step 3: CAVEaT Enumeration – CAVEaT-Modified ATT&CK Technique T1580 - Cloud

Infrastructure Discovery
An adversary may attempt to discover infrastructure and resources that are available within an
Infrastructure as a Service (IaaS) environment. This includes compute service resources such as
instances, virtual machines, and snapshots as well as resources of other services including the
storage and database services.
• Network scanning/discovery
• Cloud service enumeration
• Enumeration of cloud environment and services using previously obtained credentials
• Discovery using cloud APIs
• Potential open services using publicly opened APIs

CAVEaT-described Mitigation (Un-curated Content):
Mitigation Description
This type of attack technique cannot be easily mitigated with preventive
controls since it is based on the abuse of system features.
Least Privilege All access given to users in the cloud environment should be assigned by
the necessary privileges needed for team members to complete their job
responsibilities. Ensure that temporary access tokens are issued rather than
permanent credentials, especially when access is being granted to entities
outside of the internal security boundary.
AWS To implement least privilege in an AWS environment IAM policies will be used.
This gives the ability to allow users to perform list, read, write, permissions
management, or tagging actions. AWS suggests utilizing last accessed
information and AWS CloudTrail event history to get a better understanding of
privileges that might be needed or reduced based on a specific role. Full details
can be found at https://docs.aws.amazon.com/IAM/latest/UserGuide/best-
practices.html#grant-least-privilege.
Azure To implement least privilege in an Azure environment Azure Active Directory

roles will be used. Azure outlines different tasks and the least privileged role
that are suggested to be associated with the task. Those details can be found at:
https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/
roles-delegate-by-task. To learn how to assign specific roles it can be done via
the Azure Active Directory Portal. Instructions on how to assign roles can be
found here: https://docs.microsoft.com/en-us/azure/active-directory/users-
groups-roles/directory-manage-roles-portal.
GCP To implement least privilege in GCP it is recommended to use predefined

roles (which allow for granular access permissions) instead of primitive roles
(roles/owner, roles/editor, and roles/viewer). Full details on the difference
between types of roles can be found here: https://cloud.google.com/iam/docs/
understanding-roles. To assign these roles IAM service accounts are used and
complete details can be found at: https://cloud.google.com/iam/docs/using-
iam-securely#least_privilege.
The resulting recommendation is to invest in privileged management capabilities that enforces time-
based access control for admin accounts.

Step 4: Credential Access - CAVEaT Modified ATT&CK Technique T1552.005 -
Unsecured Credentials
Adversaries may search compromised systems to find and obtain insecurely stored credentials.
These credentials can be stored and/or misplaced in many locations on a system, including plaintext
files (e.g. Bash History), operating system or application-specific repositories or other specialized
files/artifacts. Possible actions include:
• Query key vault for credentials, secrets, and keys

• Harvesting credentials using cloud APIs.
Multi-factor Use multi-factor authentication for user and privileged accounts. Do not manage
Authentication Cloud portals from machines that perform user email and web browsing tasks.
All users should be required to utilize two factor authentication.
AWS This can be enforced by first creating a policy that would prohibit actions except
those that allow a user to change their password or manage 2FA, then attaching
a policy to a group that includes all user accounts where they can be allowed
all access if they sign in with 2FA. Once these actions are completed it should
be tested to verify the access is given correctly. To see full details on how to
complete this view AWS documentation at: https://docs.aws.amazon.com/IAM/
latest/UserGuide/tutorial_users-self-manage-mfa-and-creds.html.
Azure This can be done by creating a MFA registration policy. It can than be assigned to
all users (with the ability to exclude some if need be, but is not recommended).
Make sure once the policy is created and added to users that it is then being
enforced, once enforced it should be tested for verification. To see full details
on how to complete this view Azure documentation at: https://docs.microsoft.
com/en-us/azure/active-directory/identity-protection/howto-identity-
protection-configure-mfa-policy.
GCP This can be done by first enabling it on the current account being used by admin
to assign the roles, then enable two factor on an instance by instance or project
by project basis, then assigning the requirements based on IAM roles and
applying it to all users. To see full details on how to complete this view Azure
documentation at: https://cloud.google.com/compute/docs/oslogin/setup-two-
factor-authentication.
The resulting recommendation is to implement a modern MFA for all users, to reduce the risk of
harvested usernames and passwords, that enforces time-based access control for admin accounts.

Step 5: Lateral Movement – Traditional ATT&CK Technique T1021 – Remote
Services
Attackers can possibly use valid accounts to log into a service specifically designed to accept remote
connections, such as Telnet, Secure Shell (SSH), and VNC. The adversary may then perform actions
as the logged-on user. In an enterprise environment, servers and workstations can be organized
into domains. Domains provide centralized identity management, allowing users to login using one
set of credentials across the entire network. If an adversary is able to obtain a set of valid domain
credentials, they could login to many different machines using remote access protocols such as SSH
or Remote Desktop Protocol (RDP). This attack could target cloud-based application services and
resources.
See ATT&CK Matrix for mitigations and recommendations. The resulting recommendation is to
Implement multifactor authentication on remote service logins where possible and to limit the
accounts and permissions of the accounts that are at higher risk of compromise.
Step 6: Collection Tactic – CAVEaT-Modified ATT&CK Technique T1530 - Data

Collected from Cloud Storage
Adversaries could possibly access the data from improperly secured cloud storages. Most cloud
vendors offer solutions for online data object storage such as Amazon S3, Azure Storage, and Google
Cloud Storage. These solutions differ from other storage solutions (such as SQL or Elasticsearch) in
that there is no overarching application. Data from these solutions can be retrieved directly using the
cloud provider’s APIs. Possible actions include:
• Query/discover/copy data from storage account

• S3 blob manipulation
CAVEaT-described mitigation (Un-curated Content):
Encrypt Encrypt data stored at rest in cloud storage. Managed encryption keys can
Sensitive be rotated by most providers. At a minimum, ensure an incident response
Information plan to storage breach includes rotating the keys and test for impact on client
applications.
AWS To encrypt data at rest in an AWS environment first start by configuring the
IAM roles and permissions. A policy will need to be created to specify that the
data is to be encrypted and then the policy is attached to the instance. Full
details on how to accomplish this can be found at: https://aws.amazon.com/
blogs/security/how-to-protect-data-at-rest-with-amazon-ec2-instance-store-
encryption/.

Azure To encrypt data at rest in an Azure environment it can be done differently
depending on the cloud service the customer is utilizing - normally a check box
is presented enabling encryption for data at rest. For SaaS customers this can
be enabled or available on each specific service. For PaaS customers there are
specific storage and application platforms that are supported. In terms of IaaS
customers Azure storage components such as queues and blobs are encrypted
by selecting a check box during creation. Azure also allows customers to
employ their own encryption in addition to the server side encryption provided
by Azure –effectively creating two layers of encryption for all storage assets.
Currently this must be done programtically as described here: https://docs.
microsoft.com/en-us/azure/virtual-network/tutorial-filter-network-traffic
Encrypted compute allows for all managed disks, snapshots, and images to
be encrypted utilizing a service managed key. The keys are stored in the Azure
key vault. Full details on how to accomplish this can be found at: https://docs.
microsoft.com/en-us/azure/security/fundamentals/encryption-atrest.
GCP Encrypt data stored at rest in cloud storage. Managed encryption keys can
be rotated by most providers. At a minimum, ensure an incident response
plan to storage breach includes rotating the keys and test for impact on client
applications.
The resulting recommendation is to encrypt all cloud-stored data, and add implementation of key
vaulting technology with HSM functionality.

Step 7: Exfiltration – CAVEaT-Modified ATT&CK Technique T1537 - Leveraging SaaS
Applications
Adversaries may exfiltrate data by transferring the data, including backups of cloud environments, to
another cloud account they control on the same service to avoid typical file transfers/downloads and
network-based exfiltration detection. This sometimes could not be detected by SecOps if they are
only watching for the transfer of large chunks of data outside the cloud environment through normal
file transfer servers/VMs. Using HTTPS (port 443) Move selected files to foxhole storage account e.g
Dropbox, or another SaaS. This attack is technically taking advantage of a compatible certificate that
could possibly allow the attacker to intercept an encrypted packet to be rerouted between servers
to confuse the systems to system communications. The adversary can also use SaaS applications
to establish a C2 channel from the cloud environment to execute commands or can use SaaS
applications to establish a C2 channel from the cloud environment to execute commands. Possible
actions include:
• C2 and exfiltration tactic

• Leveraging SaaS applications
• Using web servers
Manage log data like Ensure log data is protected and managed like any other confidential
other sensitive data data source with encryption at rest and positive control.
Cloud Access Security Implement CASB solutions to ensure cloud resources are being
Broker properly accessed.
Endpoint Detection Anti-virus or malware detection services will flag and protect against
any suspicious information and files.
Disable unnecessary Adversaries could potentially exploit available Enterprise SaaS the
SaaS same as an open port or service on a machine. Harden, lockdown, or
outright disable any SaaS that is not needed.
The resulting recommendation is to invest in an in-line Cloud Access Security Broker (CASB), which
will detect traffic going to and from the SaaS, as well as detect ShadowIT that could be running within
the environment.

Step 8: Execution - CAVEaT-Modified ATT&CK Technique T1059 - Leveraging Cloud
Shell
Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries.
These interfaces and languages provide ways of interacting with computer systems and are a
common feature across many different platforms. Most systems come with some built-in command-
line interface and scripting capabilities, for example, macOS and Linux distributions include some
flavor of Unix Shell while Windows installations include the Windows Command Shell and PowerShell.
Delete IMG Files in Customers can reset their containers whenever they want in Azure by
Azure Customer deleting the .IMG file within their cloud console storage account. Do
Storage Accounts this especially if it is suspected an account compromise for a user has
occurred.
Locking down IP Run container images with minimal functionality, whitelist specific IP
addresses and ports addresses and ports for required services, and remove all unnecessary
tools on the machine, being a Docker container or a virtual machine.
The resulting recommendation is to reduce the attack surface by limiting the number of processes
and applications running in the environment that could be used by an adversary. Reducing the attack
surface includes applying segmentation policies for all network and system flows to prevent lateral
movement from persistent threats.
Step 9: Persistence - Traditional ATT&CK technique T1136.001 - Create Account
Bad actors may create an account to maintain access to victim systems. With a sufficient level of
access, creating such accounts may be used to establish secondary credentialed access that do not
require persistent remote access tools to be deployed on the system. Accounts may be created on
the local system or within a domain or cloud tenant. In cloud environments, adversaries may create
accounts that only have access to specific services to by-pass filters, which can reduce the chance of
detection by cloud security stack. Local Linux accounts could be created on a deployed Linux VM in
Azure during the deployment or post deployment of the SSH jump-box. Possible actions include:
• Create local Linux account on jump box
See ATT&CK Matrix for mitigations. Resulting recommendations include: Implement MFA for all
users, especially privileged users, domain controllers’ isolation via firewall and default least privileged
access control policy. Consider the use of Just in Time/Just Enough Administration (JIT/JEA) for zero
trust access control.

Lessons Learned
Key Tabletop takeaways include:
• CAVEaT is missing cloud-based content for complete adversary emulation using cloud only
behaviors as exemplified in steps 1, 2, 5 and 9 of the MenuPass Tabletop exercise.
• CAVEaT would benefit from the assignment of its own unique TTP IDs as can be seen in
steps 3, 4, 7, 8 of the MenuPass Tabletop. However, the correlation of CAVEaT TTPs to
applicable ATT&CK Matrix TTPs is also valuable for adversary behavior modeling.
• CAVEaT provides reasonable content for steps 6, 7 and 8 of the MenuPass scenario
demonstrating its utility for adversarial behavior modeling for cloud environments.
The community does not have a comprehensive resource like the ATT&CK Enterprise matrix for
cloud-based environments. This is likely because many of the steps required in an effective adversary
Kill Chain have not been observed in the wild using cloud-only techniques. To model MenuPass
adversary behaviors using only cloud-based techniques, something like CAVEaT would be helpful.
The expectation is that when CAVEaT is more mature and appropriately curated, all steps in an
adversary Kill chain could be modeled using cloud-based techniques.

6. APPENDIX B: Existing Frameworks –
Detailed Overview
6.1 CAPECTM
Common Attack Pattern Enumeration and Classification (CAPEC)14 is a method for organizing
cyber adversaries’ attack patterns to understand how adversaries operate. These attack patterns
are grouped into Mechanisms of Attack, based upon a technical view of how adversaries can
misuse computing, networking, and application resources. Examples of these mechanisms include
Manipulate Data Structures and Inject Unexpected Items. The mechanisms of attack documented
by CAPEC are applicable to six Domains of Attack, namely Software, Hardware, Communications,
Supply Chain, Social Engineering, and Physical Security. CAPEC is an ITU standard X.1544 and in
ISO/IEC TR 20004:2015. It provides the common attributes and approaches of how an adversary
can exploit weaknesses. CAPEC has direct ties to the Common Weakness Enumeration (CWE)
system, which is a separate model to document classes of weaknesses in software and hardware.
Per its website, capec.mitre.org, CAPEC is designed to be used by analysts, developers, testers, and
educators to advance community understanding and enhance defenses. The weaknesses addressed
by CAPEC have not yet been translated or decomposed for cloud systems.
6.2 NSA/CSS Technical Cyber Threat Framework v2

The NSA/CSS Technical Cyber Threat Framework v2 (NTCTF v2)15 is a technical extension of
the Director of National Intelligence (DNI) Cyber Threat Framework. NTCTF v2 was designed to
standardize how NSA characterizes and categorizes adversary activity by using a common technical
lexicon that is operating system independent and closely aligned with industry definitions. This
common technical cyber lexicon supports sharing, product development, operational planning, and
knowledge driven operations across the Intelligence Community (IC). Public dissemination of the
technical cyber lexicon allows for collaboration with the whole-of-community. Use of the NTCTF
facilitates organizing and examining adversary activity to support knowledge management and
enable analytic efforts. The level of generalization and enterprise environment focus can make the
NTCTF v2 somewhat difficult to apply operationally to cloud systems. For example, an adversary
action in the NTCTF v2 such as ”Pre-position payload” only has the “Key Phrase“ ”cloud document
hosting services“ to indicate association of cloud services to the adversary action. Details on how an
adversary might accomplish the ”pre-position payload” in a particular cloud provider are absent.
14 (CAPEC - Common Attack Pattern Enumeration and Classification (CAPEC™) (mitre.org)
15 ctr-nsa-css-technical-cyber-threat-framework.pdf

6.3 ATTACK®
The MITRE ATT&CK16 Matrix provides a common lexicon for the communication of adversarial
behavior between cybersecurity practitioners. It is being used by practitioners around the world
and has become the standard by which threat-based analysis is performed. ATT&CK supports the
sharing of adversary TTP content using the STIXTM 17/TAXIITM 18 Framework. ATT&CK TTP development
originated to support enterprise IT systems but have since expanded to include mobile devices and
Industrial Control Systems (ICS). TTP content is strictly limited to adversary behaviors validated as
“seen in the wild” in public Cyber Threat Intelligence (CTI) reports made by trusted sources. Given
this rigid requirement, one challenge may be potential gaps in the CTI made available to document
adversary activity in the cloud. Since CSPs own the underlying infrastructure that customers of cloud
services use, conflict of interests may prevent these service providers from providing timely and
forthcoming intelligence about adversary activity that impacts their customers and the general public.
6.4 FiGHTTM
The MITRE 5G Hierarchy of Threats (FiGHT) is a curated knowledge base that models actual and
potential adversary behaviors involved in planning and executing operations against the operators,
customers, and suppliers of 5G products, networks, and services. FiGHT is derived from and
compatible with MITRE ATT&CK, containing many of the same object sets and following the same
schema. Some adversarial behaviors documented in ATT&CK have a special relevance in 5G systems.
In these cases, FiGHT directly references these original behaviors and provides additional 5G
context that is relevant to the operators and suppliers defending these networks, while also giving
a direct link to the source ATT&CK content. FiGHT also has a broader scope, documenting both
theoretical and lab proven behaviors, in addition to adversary behaviors observed in the wild that are
documented by trustworthy Cyber Threat Intelligence (CTI). As such, the FiGHT Threat Model can be
viewed as a 5G specific extension and an overlay of ATT&CK.
The FiGHT behavioral model consists of the following core components:
• Tactics that denote the immediate objective of adversaries when performing a specific,
atomic behavior
• Techniques that describe the specific, atomic behaviors adversaries perform during an
operation
• Sub-techniques that more specifically describe how a given technique can be achieved, in
greater technical detail
• Addendums that provide 5G context for existing ATT&CK content
• Metadata that captures filterable information about techniques and sub-techniques.
• Data sources that can be used by defenders to detect documented techniques and sub-
techniques
• Mitigations that can be used by defenders to prevent documented techniques and sub-
techniques
16 MITRE ATT&CK®

17 https://attack.mitre.org/resources/working-with-attack/
18 About TAXII (Archive) | TAXII Project Documentation

FiGHT is also intended to be a living knowledge base built through community contributions and
collaboration. As adversary behavior evolves and 5G progresses to later generations, the FiGHT
model will also evolve to provide a useful tool for equipment/software developers, operators, and
customers.
FiGHT may prove useful to enterprise users of cloud since the 5G system of systems is embracing
major cloud technologies and using many cloud services and CSPs. Key CSPs are offering 5G core
network services as well. The FiGHT framework included theoretical and lab-proven techniques
against cloud services while ATT&CK, of course, included seen-in-the-wild techniques. Together, they
can provide insight into securing general cloud-based systems despite the FiGHT focus on 5G.
6.5 ATLAS™
MITRE ATLAS19, is a knowledge base of adversary tactics, techniques, and case studies for machine
learning (ML) systems based on real-world observations, demonstrations from ML red teams and
security groups, and the state of the possible from academic research. ATLAS is modeled after the
MITRE ATT&CK framework and its tactics and techniques are complementary to those in ATT&CK.
ATLAS enables researchers to navigate the landscape of threats to machine learning systems. ML
is increasingly used across a variety of industries. There are a growing number of vulnerabilities in
ML, and its use increases the attack surface of existing systems. MITRE developed ATLAS to raise
awareness of these threats and present them in a way familiar to security researchers.
Because ATLAS allows the threat model taxonomy to include theoretical and practical attacks that
have not yet been observed in the wild, it is useful to practitioners that wish to model defenses
against the threat surface presented by AI and ML systems while the adversarial tradecraft in this
area is still underdevelopment or information sharing barriers exist. That said, while some crossover
may exist between AI/ML based threats and cloud threats (e.g., data pollution at scale) ATLAS is
insufficient to model the vast majority of cloud-based threats and should be viewed as a useful, but
orthogonal, independent threat model.
19 https://atlas.mitre.org/

6.6 D3FEND™
Initially funded by the National Security Agency (NSA), D3FEND20 is a cybersecurity knowledge base
of counter measures, capabilities, and components that enables security architects and IT executives
to assess a defense technique. The knowledgebase encodes data to define the relationships between
key cybersecurity concepts, and how those concepts relate to each other. Countermeasures
components and capabilities are specified, and the database encodes, which threats a
countermeasure address, and from an engineering perspective how and under what circumstances a
countermeasure to a tactic/threat or procedure will work. The cybersecurity concepts and relations
are backed up by research and development literature and over 500 countermeasure patents from
the U.S. Patent Office that the knowledgebase references. You can query the knowledgebase and
you can determine which countermeasures relate to which attack tactics, threats, and procedures. In
the long run it is thought that the knowledge base will use machine learning/automation to keep the
knowledge base up to date.
To date, the most common use case has been to guide investment and acquisition. D3FEND has two
options for doing this. With a standard defensive technique taxonomy, it may be utilized to compare
the claimed capability in various commercial solution sets. As a result, product disparities and gaps
in terms of required functionality can be more precisely, consistently, and repeatedly identified. In
terms of relevant offensive approaches, it can help to define a plausible testing plan for the defensive
techniques. This is accomplished by locating the claimed defensive tactics of a product or product
set, then searching D3FEND for the potentially connected attacking techniques. By combining the
relevant offensive techniques, one can create an offensive test strategy. Additionally, D3FEND is at
an early stage and the knowledge base has not been fully populated21.
20 https://d3fend.mitre.org
21 https://d3fend.mitre.org/resources/D3FEND.pdf

20230403分享-ATT&amp;CK &amp; D3FEND with a CAVEaT

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

20230403分享-ATT&amp;CK &amp; D3FEND with a CAVEaT

Загружено:

Авторское право:

Доступные форматы

ATT&CK & D3FEND with a

© Copyright 2023, Cloud Security Alliance. All rights reserved. 2

© Copyright 2023, Cloud Security Alliance. All rights reserved. 3

© Copyright 2023, Cloud Security Alliance. All rights reserved. 4

© Copyright 2023, Cloud Security Alliance. All rights reserved. 5

• CAPEC™: Common Attack Pattern Enumeration and Classification (CAPEC)1 is a method

1 (CAPEC - Common Attack Pattern Enumeration and Classification (CAPEC™) (mitre.org)

© Copyright 2023, Cloud Security Alliance. All rights reserved. 6

2.1 Technology and Cloud Service Coverage

Cloud-Native Infrastructure, Platform as a Service (PaaS) and Function as a Service (FaaS):

© Copyright 2023, Cloud Security Alliance. All rights reserved. 7

© Copyright 2023, Cloud Security Alliance. All rights reserved. 8

Cloud Service: Adversary Tactics,

Defensive Tools Critical Assets:

Section 5 APPENDIX A: Tabletop Example using CAVEaT provides an example of a paper-based

© Copyright 2023, Cloud Security Alliance. All rights reserved. 9

Identify Mission/ Identify Mitigations Conduct Portfolio

Defensive Capability Assessment: The existing defensive capabilities of an organization’s technology

Threat Intelligence Communication: Since threat models provide structured documentation

Detection Analytic Development: Detection analytic development typically requires knowledge

2.4 Technology for Threat Model Curation

© Copyright 2023, Cloud Security Alliance. All rights reserved. 10

© Copyright 2023, Cloud Security Alliance. All rights reserved. 11

2.6 The Role of Government Regulatory and Security

© Copyright 2023, Cloud Security Alliance. All rights reserved. 12

2.7 Industrial/Societal Considerations for Threat

© Copyright 2023, Cloud Security Alliance. All rights reserved. 13

3.1 Threat Model Content Objectives

3.2 Service Provider Specific Threats and Mitigations

• API Security (e.g., Gateways, Web Application Firewalls, etc.)

© Copyright 2023, Cloud Security Alliance. All rights reserved. 14

• AWS Web Application Firewall

3.3 Emerging Threats Relevant to Cloud Systems

© Copyright 2023, Cloud Security Alliance. All rights reserved. 15

Two-thirds of API incidents in 2020 were attributable to either no authentication, no authorization,

3.4 Threat Information for Cloud-based Cyber Analytics

• Identification of cyber event logging requirements for continuous monitoring

© Copyright 2023, Cloud Security Alliance. All rights reserved. 16

ATT&CK Tactic Other Tactic

ATT&CK Technique Other Technique

Cloud #1 Adversary Cloud #2 Adversary Cloud #3 Adversary Cloud #n Adversary

Cloud #1 Threat Cloud #2 Threat Cloud #3 Threat Cloud #n Threat

Cloud #1 Threat Cloud #2 Threat Cloud #3 Threat Cloud #n Threat

© Copyright 2023, Cloud Security Alliance. All rights reserved. 17

© Copyright 2023, Cloud Security Alliance. All rights reserved. 18

Potential Curation Status Tags

© Copyright 2023, Cloud Security Alliance. All rights reserved. 19

As an international organization possessing broad industry reach, established industry relationships

© Copyright 2023, Cloud Security Alliance. All rights reserved. 20

5.1 Introduction to CAVEaT

• Empirical Observation - adversary behaviors from contributed threat intelligence.

5.2 Planned CSA CAVEaT Working Group

12 Summary - CSA Federal Summit 2022 (cvent.com)

© Copyright 2023, Cloud Security Alliance. All rights reserved. 21

• Step 1 - Initial Access

Step 1: Initial Access - Traditional ATT&CK Technique T1078.004 - Valid Accounts

• Reuse Stolen Credentials that were harvested to SSH to box

© Copyright 2023, Cloud Security Alliance. All rights reserved. 22

Step 3: CAVEaT Enumeration – CAVEaT-Modified ATT&CK Technique T1580 - Cloud

© Copyright 2023, Cloud Security Alliance. All rights reserved. 23

Azure To implement least privilege in an Azure environment Azure Active Directory

GCP To implement least privilege in GCP it is recommended to use predefined

© Copyright 2023, Cloud Security Alliance. All rights reserved. 24

• Query key vault for credentials, secrets, and keys

20230403分享-ATT&CK & D3FEND with a CAVEaT

20230403分享-ATT&CK & D3FEND with a CAVEaT