Abstract
Migrating enterprises and business capabilities to cloud platforms like Amazon Web Services (AWS) has become increasingly common. However, securing cloud operations, especially at large scales, can quickly become intractable. Customer-side issues such as service misconfigurations, data breaches, and insecure changes are prevalent. Furthermore, cloud-specific tactics and techniques paired with application vulnerabilities create a large and complex search space. Various solutions and modeling languages for cloud security assessments exist. However, no single one appeared sufficiently cloud-centered and holistic. Many also did not account for tactical security dimensions. This article, therefore, presents a domain-specific modeling language for AWS environments. When used to model AWS environments, manually or automatically, the language automatically constructs and traverses attack graphs to assess security. Assessments, therefore, require minimal security expertise from the user. The modeling language was primarily tested on four third-party AWS environments through securiCAD Vanguard, a commercial tool built around the AWS modeling language. The language was validated further by measuring performance on models provided by anonymous end users and a comparison with a similar open source assessment tool. As of March 2020, the modeling language could represent essential AWS structures, cloud tactics, and threats. However, the tests highlighted certain shortcomings. Data collection steps, such as planted credentials, and some missing tactics were obvious. Nevertheless, the issues covered by the DSL were already reminiscent of common issues with real-world precedents. Future additions to attacker tactics and addressing data collection should yield considerable improvements.
1 INTRODUCTION
Migrating business capabilities or entire enterprises to the cloud is increasingly common. However, moving to the cloud is not a security guarantee. For instance, Gartner predicted that, by 2025, 99% of all cloud breaches would be customer-side lapses,1 but such issues are already commonplace. A crux with customer-side cloud security is combinations of traditional security vulnerabilities enhanced with cloud-native attacker tactics. Therefore, the search space grows large and complicated, spanning multiple attack steps, assets, and services. In response, this work proposes a domain-specific modeling language for Amazon Web Services (AWS) environments. First, it can model AWS environments and configurations. Then, the models are used to simulate attacks by automatically constructing and traversing the corresponding attack graph. The result is an AWS security assessment akin to virtual penetration testing requiring minimal security expertise from users.
AWS is currently one of the most adopted public cloud platforms, offering services numbering in the hundreds. However, security incidents involving AWS services are also routinely reported. One such service is the Simple Storage Service (S3), a data storage solution for managing objects in so-called buckets. Another frequently used service is the Elastic Compute Cloud (EC2), which hosts virtual machine instances. Essential to many other services is the Virtual Private Cloud (VPC). This virtual network infrastructure allows cloud customers to deploy and configure, for example, web servers in logically separate networks on the AWS infrastructure. Finally, the policy-oriented Identity and Access Management (IAM) for user and permissions administration is another essential service. Even when limited to these four services, a realistic breach can start by exploiting a vulnerable web application on an EC2 instance. Then, the attacker can pivot by exploit IAM privileges assigned to the instance. Such causal vulnerability chains make security assessments of enterprise AWS environments overwhelming due to sheer scale and complexity.
Regarding attacks, two highlights in a recent threat landscape report2 were abusing valid credentials and pivoting within the environment. Also relevant is that the Cloud Security Alliance (CSA) egregious 11 threats report [13] lists customer-side issues such as data breaches, misconfigurations, change control, IAM problems, and account hijacking in the top five. Examples actualizing these threats are abundant. One 2019 incident involved request forgeries from a misconfigured firewall.3 Leaked AWS credentials caused the Tesla4 and Uber breaches.5 Exposed S3 buckets is another common root cause behind, for example, the Accenture6 and Time Warner7 incidents. Finally, escalating privileges via AWS permission combinations has gained attention in industry.8, 9, 10 All in all, there appears to be practical needs for assessing cloud services usage and configurations.
Automated assessment artifacts often focus on general network security. Seminal work includes NetSPA [5], MulVal [46], and the Topological Vulnerability Analysis (TVA) tool [44]. Some recent contributions are Vulnus [3] and MAD [4]. AWS-specific tools can be both commercial solutions, such as hava.io11 and Hyperglance,12 or one of many different open source tools.13 AWS itself also provides numerous security services, such as Inspector for EC2 security and vulnerability assessments. AWS also provides certain assessments based on formal methods. One such solution is TIROS for network reachability [6] and, Zelkova for analyzing policy configurations [7]. However, security incidents still occur despite the large selection of services and tools, which suggests that some AWS problems remain.
The problem is not the lack of particular tools but the lack of specialized yet holistic security assessment methods. No single AWS or third-party solution seems to capture the structural relationships and chains of vulnerabilities present in customer environments. Fuller pictures require multiple services but this by itself can add undesirable complexity. Moreover, repositories such as MITRE cloud matrix14 does not account for AWS-specific techniques, such as particular privilege combinations. Looking wider, the cloud security requirements in Kumar and Goyal [35] and many cloud modeling languages in Bergmayr et al. [10] may account for application security, but not tactics and techniques. Close to this work is the recent modeling language proposed in Mouratidis et al. [42], except it also has a strategic and requirements focus. The problem with the existing cloud modeling work, despite its richness, is that it serves a different purpose to modeling threats. Therefore, more effort should be directed to modeling detailed events that realize cloud threats such as those reported in Reference [13].
This work proposes a domain-specific threat modeling and cyber attack simulation language developed with the Meta Attack Language (MAL) [26]. The proposed language was tailored to AWS, since it is market-leading with regularly reported security incidents. The domain-specific language, hereafter the DSL for AWS or just the DSL, can model AWS environments and reason about their security by constructing and traversing attack graphs. However, the DSL does not include supporting features, such as automated information collection and visualizations. Such functions are currently found in securiCAD Vanguard.15 Vanguard is a commercial tool powered by the DSL for AWS described in this work. The contributions of this work are, therefore, fourfold:
It presents the DSL for AWS, a language where users solely describe, manually or automatically, AWS configurations to obtain security assessments.
The DSL for AWS reasons with both traditional software vulnerabilities and cloud-specific attacker tactics and techniques.
A first validation of the DSL is performed based on scenarios, comparison, and performance testing.
A demonstration of the first fully realized application of MAL.
Before introducing the DSL, Section 2 discusses related works, and Section 3 describes the methodology. Following is the presentation of MAL in Section 4 the DSL in Section 5. Section 6 demonstrates relevant aspects of the DSL, followed by validation results in Section 7. Finally, Section 8 discusses the validation outcomes and general observations about the DSL, and Section 9 concludes the article and suggests topics for future work.
2 RELATED WORK
2.1 Security and Cloud Modeling
The DSL for AWS is related to model-driven security [26] and attack simulations research. The former has had numerous contributions over the years. These include secureUML [30], UMLsec [38], Tropos [11, 40] with cloud aspects [41], OCTAVE [1], SECTET [60], CORAS [14], and the policy-oriented work of Reference [37]. More recent examples are SecDSVL [2] for visual enterprise modeling and STS-ml [47] for socio-technical systems. The focus of the aforementioned work is either establishing frameworks, describing systems, enterprise modeling, or eliciting security requirements. For example, Tropos for clouds [41] can manually model deployments, business goals, attacks, and defenses. The intention is development time planning and mapping security requirements to cloud offerings. The DSL for AWS instead focuses on automatically assessing AWS environments, deployed or planned, by simulating attacks. The DSL also distinguishes itself by not requiring users to model attacks and threats themselves.
The literature is rich regarding cloud security requirement overviews [9, 35] and cloud modeling languages [10]. A few requirements overviews are Jensen et al. [25] for application security concerns and Kandukuri et al. [31] for service level agreements. Further are Gruschka and Jensen [18] for attack surface classifications between users, cloud services, and the cloud itself. Grobauer et al. [17] discussed cloud-native security issues, Xiao and Xiao [59] reviewed cloud operation and construction security, and Fernandes et al. [15] covered aspects ranging from software security down to platform virtualization. When synthesized [35], cloud security requirements do not account for cloud tactics and techniques, such as the MITRE cloud matrix.14 Tactics and techniques, in addition to software vulnerabilities, are included in the DSL for AWS. Moreover, the DSL assessments simulate chains of attacker actions and vulnerabilities. The DSL, however, is not a requirements modeling language by design, but it could inform such activities.
Cloud modeling languages for end users often support resource deployment and management rather than security [10]. The DSL for AWS is capable of describing cloud resources and configurations, but primarily for security assessment purposes. A recent contribution reminiscent of the DSL is the secure cloud modeling language [42]. This language also models cloud deployments and automatically reasons about security. Its analyses encompass vulnerabilities, constraints, objectives, and mitigation suggestions. The DSL for AWS is, in contrast, currently limited to reasoning about possible attacks. However, the secure cloud modeling language has a requirements alignment and strategic scope. The DSL instead takes a tactical and penetration testing perspective. For example, this can show how benign AWS-specific API requests can be abused to move within a cloud environment, rather than solely relying on application vulnerabilities.
2.2 Graph Construction and Security Assessments
To reason about attacks, the DSL represents attacker behaviors with attack-defense graphs [26]. The basic attack graph, primarily attributed to Philips and Swiler [54, 55], models sequential attacker paths, sometimes using probabilistic edge weights. A multitude of attack trees and attack graph variants exist currently. Kordy et al. [34], Hong et al. [21], and Lallie et al. [36] reviewed these thoroughly. Related to attack graphs are attack trees, which generally model attacks and, optionally, defense mechanisms [34]. Attack trees, popular for threat modeling, gained significant traction from Schneier [49] with a later formalization by Mauw and Oostdijk [39]. Later variants, such as attack-defense trees [33], introduced defensive measures.
Attack graphs are commonly used for automated security assessments. Such work often fall within attack graph construction. The distinguishing topics are reachability analysis, establishing vulnerability and privilege relationships, efficient graph construction, and attack path determination [32]. NetSPA [5] was an early attack graph construction tool using network models and external scanning software. It was later extended with client-side vulnerabilities [22] and visualizations in GARNET [58] and NAVIGATOR [12]. MulVal [46] is another influential network analyzer, which identifies attack paths via specifications of topologies, configurations, users, access policies, and known vulnerabilities. A methodology similar to References [5, 46] is also found in the TVA-tool [44], its follow-up Cauldron [23], and NetSecuritas [16]. However, these three approaches also attempted to suggest security controls. ZePro [53] and k-Zero Day Safety [57] took a different approach. The former analyzes which attack paths likely contain zero-day exploits. The latter estimates how many zero-days would be required to penetrate a network. General network analyzers could assess cloud networking environments. This scope, however, does not include cloud-specific issues and techniques.
The proposed DSL for AWS is built using MAL, a culmination of previous work on creating security modeling languages and constructing attack graphs for enterprise architectures. The earlier work of Reference [52] proposed using probabilistic relational models for cybersecurity modeling and analysis. The Cyber Security Modeling Language (CySeMoL) [51] implemented this notion by constructing attack paths relative to models of assets, attack steps, and countermeasures. The Predictive Probabilistic Cyber Security Modeling Language (P2CySeMoL) improved on CySeMoL by extending the scope of available assets, making fewer assumptions about attackers’ time, and improving the efficiency of probability calculations [20]. PwnPr3d [28, 29] later followed up the CySeMoL family. It introduced the layered meta-modeling architecture, which is conceptually similar to MAL. However, the general-purpose meta language, rather than single-purpose languages, was not developed until Reference [26].
2.3 Tool Ecosystem
AWS already provides numerous security services for specific tasks. Table 1 summarizes the capabilities of related assessment tools compared to the proposed DSL and Vanguard. For example, the IAM access and VPC reachability analyzers, based on References [6, 7], reason about policies and network topologies. Audit tools, such as the Trusted Advisor, can instead check for deviations from best practices, similar to AWS Config rules. AWS Config, however, records and retains configurations and configuration changes. This config inventory is similar to asset inventories, but the latter has a dedicated Asset Inventory service. Finally, Inspector can assess EC2 instances and their configurations, including identifying Common Vulnerabilities and Exposures (CVE) occurrences akin to a vulnerability scanner.
Table 1. Comparison of Select AWS Assessment Support Against the Proposed DSL and Vanguard
The main difference between the existing services and the DSL is linking security issues across services. The auditing services and Inspector may highlight vulnerabilities but not their consequences. Moreover, single vulnerabilities may appear insignificant until they are correlated. This is the search space that quickly grows beyond comprehension without tool support, such as the DSL. The DSL, however, can model but not identify CVEs and similar flaws. Instead, it relies on the modeler or, for example, Vanguard to supply such information. Vanguard, in turn, ingests Inspector results and models them automatically. Vanguard can additionally compile asset inventories and automatically instantiate entire DSL models as well. However, the core modeling and simulation capabilities come from the DSL proposed in this work.
2.3.1 Open Source.
The DSL for AWS aims to provide model-based security assessments analogous to penetration tests. The open source community contains a myriad of AWS security tools.13 Table 2 shows an excerpt of somewhat related tools and their purpose compared to the DSL. A very similar tool is awspx16 by F-Secure Labs, which also analyzes AWS environments using graphs. Another class of tools was auditing tools or suites. These would typically check static rules to highlight problems and deviations from best practices, similar to existing AWS services. Another variant focused on single services. Aaia,17 for example, employed graphs but was limited to IAM. The final tool class was red teaming tools, which move beyond the passive assessments pursued here. Overall, many existing tools claim to perform AWS security assessments. However, they are either not holistic or do not reason about threats on the same level as the DSL proposed here.
| Tool | Scope | Objective |
|---|---|---|
| DSL for AWS | Assessment | Assess security based on attack graphs across services. |
| awspx | Assessment | Assess security based on attack graphs across services. |
| CloudSploit | Audit | Identify misconfigurations and security risks. |
| Cloud Security Suite | Audit | Collection of multiple auditing tools and checks. |
| Prowler | Audit | Identify risks and deviations from best practices. |
| ScoutSuite | Audit | Identify risks and deviations from best practices. |
| Aaia | IAM | Visualise and analyse IAM as graphs. |
| aws-security-viz | VPC | Visualize VPC and EC2 security groups. |
| cfn_nag | CloudFormation | Find infrastructure issues in CloudFormation templates. |
| LambdaGuard | Lambda | Audit lambda usage and configurations. |
| cred_scanner | Scan | Scan files for AWS credentials. |
| Leonidas | Red team | Framework for red teaming and exploitation. |
| Zeus | Hardening | Audit and harden security settings of multiple services. |
Table 2. Excerpt of Open Source AWS Tools and Their Purposes Compared to the DSL for AWS
3 METHODOLOGY
This work presents the latter part of a design research process [48] that began as a small proof of concept in 2018 [50]. Specifically, this article communicates the further design, demonstration, and validation of the DSL for AWS using MAL. MAL was chosen, since it is explicitly designed for creating languages to model and reason about chained vulnerabilities at scale [26]. Figure 1 shows the research methods mapped to each design research phase. Since MAL was explicitly designed for threat modeling [26], Figure 2 shows how the DSL was developed. The later validation employed independent third-party test scenarios, driven by an analogy with expert systems hearkening back to CySeMoL [51].
Fig. 1. Design, demonstration, and validation activities performed in this work.
Fig. 2. Adaptation of a threat modeling process as an iterative language design and development process.
3.1 Design
The threat modeling in Myagmar et al. [43, p. 2–4] cycled through three activities: characterizing the system, identifying assets and access points, and identifying threats. An iteration would start by selecting certain AWS services to investigate and implement in the DSL. Then, the corresponding assets and structural relationships were represented and codified with MAL. The primary references were existing user and developer guides.18 These guides were enough to implement the corresponding assets and structural relationships in the DSL for AWS, the descriptive part of the modeling language. Additionally, the structural and descriptive aspects of the DSL were deliberately designed to replicate AWS as closely as possible. Domain elements, abstractions, and terminology outside of AWS were kept to a minimum. The purpose was to improve usability and comprehension, both in using the DSL and in communicating simulation results.
To identify threats and defense mechanisms, developer and application programming interface (API) guides were examined for requests with immediate impacts, such as read and delete operations. Indirect attacker actions, such as listing objects, were omitted unless strictly necessary for the attack or simulation. More advanced attacks were sourced from reported incidents or grey literature from the industry. These sources were preferred over, for example, enterprise ATT&CK matrix,19 since it did not cover cloud tactics. The resulting cloud actions, complete with causes, consequences, and defenses, were later codified with MAL as well. The resulting attack-defense logic, as well as the overall modeling capabilities, were verified through unit tests. Finally, assumptions regarding AWS services were verified against actual services.
3.2 Demonstration
To demonstrate the basic capabilities of the developed DSL, the Capital One incident3 was modeled using the proposed DSL. The incident contains both a request forgery and abuse of AWS privileges as a direct consequence. This is the type of structural problems and vulnerability chains the DSL was designed to assess. Furthermore, the extensibility of the DSL is demonstrated by showing how a service specification could be implemented.
3.3 Validation
The DSL for AWS was tested on the 2nd of March, 2020, against four scenarios provided with CloudGoat. CloudGoat20 is a tool by Rhino Security Labs that deploys pre-defined vulnerable-by-design AWS environments. Validity in this work was results-driven and determined by the quality of the reasoning produced by the DSL simulations [45]. CloudGoat at the time21 contained six scenario environments exhibiting flaws and misconfigurations. Two were excluded as the DSL did not model the appropriate tactics at the time. The missing key tactics resulted in unavoidable failures at the outset. This did not test the quality of the produced reasoning, but the breadth of the DSL.22
Each of the four remaining scenarios were deployed one at a time to an otherwise empty AWS account. The DSL was then used to model the resulting environments and simulate attacks. To further evaluate the DSL, it was compared to awspx,16 the open-source tool performing similar assessments. The scenarios were redeployed and assessed in the same manner as for the DSL. However, one additional scenario was omitted for this particular comparison. This was because Awspx did not support one of the key services at the time. So, the final comparison used the three remaining scenarios where both artifacts appeared equal at the outset.
The attack simulations were run via SecuriCAD Vanguard. Although manual modeling was possible, Vanguard supported both visualization and the envisioned automated model instantiations. The automation used a Vanguard script that automatically compiles the asset inventory via the AWS API and Boto 3. The resulting inventory file was first modified to make assets publicly accessible, since CloudGoat otherwise restricted access. The inventory was then uploaded to Vanguard to read and instantiate the corresponding DSL models. The simulations were set to target every applicable asset in Vanguard, such as EC2 instances and S3 buckets. The results were additionally viewed at the maximum level of detail. Finally, the cybercriminal threat profile was selected. Criminals can attack using unknown exploits, but not to the same extent as state-sponsored attackers.23
3.3.1 Attack Path Coverage.
The simulation results were evaluated by calculating a node and link coverage metric, respectively. Coverage itself was defined as the percentage of visited entities compared to the steps defined in the provided CloudGoat solutions. Two coverage variants are reported for both nodes and links, DSL and entity coverage. DSL coverage is the predicted upper bound, the best possible result based on the DSL source code. Entity coverage is calculated from the simulation results, as reported by Vanguard.
Furthermore, the level of abstraction differed between the CloudGoat solutions and the DSL. For example, CloudGoat solutions can contain Bash commands and the DSL, conversely, contains steps invisible in the CloudGoat solutions. Therefore, the solutions were manually normalized before calculating coverage. The first normalization step was to omit all steps not related to AWS, such as local Bash commands. The second was to compress all major events into single nodes. For example, finding then exploiting a CVE would compress to a single exploitation step. Additional diagrams were created to illustrate these normalized paths and show what was covered by the DSL.
3.3.2 Performance.
To further test the applicability of the DSL for AWS, its performance was evaluated with the sampling set to 100 rounds. Anonymous measurements were collected from four EC2 instances running simulations in a production environment. Therefore, performance was measured based on environments provided, and queued for simulation, by real end users. The EC2 machine types used in the tests are shown in Table 3. The majority of the measurements were collected from a memory optimised R5 large instance.24 The R5 instances could use up to an Intel Xeon 3.1 GHz processor. The general purpose T3 instance could use up to either the same Intel processor or an AMD EPYC processor. Results exceeding 150 s on models below 25,000 DSL assets were considered anomalous and removed. These were likely results from abnormally long queue times or technical failures. Finally, the queue times could not be separated from the calculations. This means that the actual simulations are either the same or faster than the results from these tests showed.
4 THE META ATTACK LANGUAGE
4.1 Informal Overview
MAL25 is a programmatic specification language for creating domain-specific threat modeling languages that construct attack graphs for simulations. These languages have two primary capabilities. They provide the alphabet and grammar necessary to build descriptive models of domain elements and their structural relationships. Then, they provide the means to embed attack and defense logic with causal dependencies into domain element definitions. This logic is extracted from instantiated models to construct probabilistic attack-defense graphs. The resulting graphs are traversed and sampled with Monte Carlo simulations to assess the security of the instance model. The resulting attack path sub-graphs represent the likely actions of potential attackers.
Figure 3 summarizes the meta-language tokens. An
Fig. 3. Tokens of the Meta Attack Language.
The majority of the tokens in Figure 3 encode attack steps and defense mechanisms rather than structural relationships. Performing an attack step may enable subsequent steps, forming sequential paths. Such successor steps can, additionally, reside in other assets as determined by the associations. An attack step is rendered ineffective if it is structurally or logically unreachable. Another method for stopping attack steps is defining some corresponding defense logic.
4.1.1 Attack Step Conditionals.
The fundamental attack logic unit is the single attacker action, an
Beyond explicit conditionals, MAL can simulate intricate decision-making and structural conditions via the basic asset-level set operations union, intersect, and difference. These are part of attack step grammar, rather than independent tokens. A practical example is when numerous traffic filtration rules govern which set of endpoint assets are reachable in a network. The difference between the set of reachable and unreachable systems, given by the structural relationship between rules and systems, obtains the final set of reachable endpoints for the attack simulations. Altogether, the attack-defense logic, existence checks, and set operations enable MAL to replicate complex structural and logical conditions in its languages and simulations.
4.1.2 Path Inference and Simulations.
The combination of assets, associations, attack steps, and defenses is enough to construct models and conduct reachability analyses. However, probabilistic simulations are supported by assigning
The attack simulation output is, in addition to the attack path sub-graphs, the Time-to-Compromise (TTC). The effort required to reach a node, performing a single attack step, is the local TTC. The total effort to reach a node, the sum of the paths, is the global TTC. When simulating attacks, a single
The current attack simulations commonly try to determine the critical attack paths with a single source shortest path algorithm [26, pp. 7–8]. This produces paths ranging from the shortest path to the longest path. For example, the shortest path may be the lowest effort path preferred by opportunists. The longest path can be arbitrarily long and complex, potentially beyond what is realistically achievable. MAL itself can report all identified paths. However, applications based on MAL, such as Vanguard, may further select and filter results.
4.2 An AWS-inspired MAL Example
4.2.1 Language Design.
Figure 4 represents the structure of a minimal AWS-like MAL design. Relative to the MAL tokens (Figure 3), classes translate to
Fig. 4. Class diagram showing the structure of an AWS-inspired example language. Classes represent assets and attributes represent attack steps or defenses.
The first attack vector at line 4 is implemented by guessing a
Successfully compromising user identities means obtaining their privileges. This is implemented by
is
Listing 1. Example language MAL code.
The second attack vector requires a remote connection (line 36) and at least one application
Visually, MAL designs and intuitions can be gleaned by tracing connections in diagrams such as Figure 4. For example, answering which
4.2.2 Modeling and Simulation Example.
Compiling the example language source code with the MAL compiler28 produces Java classes corresponding to the assets. These classes are used to instantiate the domain-specific models manually or automatically. For example, a basic scenario consists of one user Alice, Alice’s password, Alice’s permission to terminate an EC2 instance, and a vulnerable application running on the instance. Listing 2 below shows the Java code modeling the scenario. Lines 1–7 instantiate assets. Lines 9–19 connect the assets. The asset constructor arguments determine the labels used when reporting simulation results.
Listing 2. Example language model instantiated in Java.
The final steps in lines 21–25 conduct the attack simulation. The attacker’s starting points are having guessed Alice’s password and connected to the running application. Simulating from there would produce the graph in Figure 5. Both starting points lead to, and end on, the application stopping. The example language has now been demonstrated from design to final results. The DSL for AWS, albeit significantly larger, follows the same workflow. Furthermore, similar design principles were employed as well. For example, the generic
Fig. 5. Graph produced using the example language, showcasing both attack vectors. Various attack steps from the asset definitions are translated into graph nodes.
5 THE DSL FOR AWS
Figure 6 summarizes the DSL for AWS workflow as of March 2020, from the AWS platform, the DSL itself, and to simulation end results. The leftmost side of the figure shows the high-level structure of the DSL for AWS, and below is the AWS platform. Although manual modeling is possible, the intended usage is to compile a JSON asset inventory via the official Boto 3 software development kit. Boto 3 can query the AWS API for asset listings that are compiled into the asset inventory itself. Parsing the inventory to then programmatically instantiate the corresponding DSL assets and associations, thus, automates the modeling process. Automating the modeling also automates the simulations, since the DSL instance models include all security logic required to construct the attack graphs. The information collection, the act of programmatically instantiating models, and visualizations are what Vanguard supplies to the workflow. The DSL contains the core modeling and security assessment capabilities, the primary contributions of this work.
Fig. 6. Overview of the DSL automated modeling and simulation workflow. The DSL describes and reflects the AWS platform. Models can be programmatically instantiated using the JSON inventories compiled with Boto 3. This produces structural model and attack graphs, the latter used for simulations to obtain attack paths.
Singh Virdi [50] developed the original proof of concept DSL for AWS. It was limited to some core assets and a handful of rudimentary EC2, S3, and IAM functions. In contrast, the current design consists of 14 MAL source code specifications, categorized as service or essential, spanning 12 services to different extents. Service specifications model single, mostly independent, AWS services. The essential specifications replicate functions underpinning most other services and language implementations. These include generic core assets, networking, user permissions, and software vulnerabilities.
5.1 Essential Specifications
5.1.1 Core.
The Core specification provides fundamental assets used across all of the DSL, shown in Figure 7. Notable is the base
Fig. 7. Asset associations in the Core specification. R symbolizes inheritance from Resource.
5.1.2 Virtual Private Cloud.
The Core specification can represent single machine instances but not communications between them. The VPC service provides networking capabilities and mostly mirrors traditional networking. Concepts such as subnetworks, routing, and IP addressing are identical. However, traffic between VPCs requires VPC peering connections, and Internet access requires an Internet gateway. Load balancers can additionally disseminate traffic across multiple hosts. Firewall capabilities are implemented via security groups (SG) and network access control lists (NACL). SGs implement fine-grained rules down to individual hosts, whereas NACLs only work at subnet levels.
The DSL VPC specification describes all network traffic flows and is relatively complex (Figure 8). However, most VPC and networking concepts have intuitive MAL counterparts. Their intuition is best gleaned by visually tracing the associations in Figure 8. For example, an
Fig. 8. Overview of the VPC specification. The diagram flows vertically, starting from concrete instances and ending in wider networks and the Internet. R symbolizes inheritance from Resource.
The bulk of the networking simulation is performed in the
5.1.3 Identity and Access Management.
The IAM service provides policy-based access control. Policies determine what actions principals, all agents capable of issuing API requests, may perform on certain resources. Policies consist of statements that, in turn, define which actions are permitted or denied. Actions mirror the API requests defined for each cloud service. Policies designate resources with Amazon Resource Names (ARN). ARNs are text strings formatted hierarchically, functionally similar to URLs. ARNs can also contain wildcards to designate all assets at a given level. ARNs can further point out both resources and principals, since principals are a resource type in AWS.
Figure 9 shows the specification for IAM. The intuition is that assuming an IAM identity leads to performing certain actions. Permitted actions are found by consulting applicable policies. Finally, action consequences are defined by specific sub-classes, similar to the example language in section three. However, ARNs designate the target of actions.
Fig. 9. Overview of the IAM specification. R symbolizes inheritance from Resource. The top half models policies. The bottom half models principals.
The DSL includes identity- and resource-based policies. Identity-based policies are attached to principals and govern their outgoing actions against resources. Resource-based policies conversely govern incoming requests to resources. Policies are further categorized as managed or inline. AWS maintains managed policies, whereas customers write inline policies. For all modeled policy types, ARNs designate target resources and principals, respectively. Principals are defined as IAM identities with additional user, group, and role sub-classes. The IAM user represents a user account or API user, commonly assumed via passwords or access keys. The IAM group is essentially a set of permissions that applies to collections of IAM users. The IAM Role is a set of permissions that can be requested by, or delegated to, other principals.
The DSL extends the Core
The DSL simulates policy resolutions similar to network transmissions. Allowed actions are sets of
The DSL obtains all A by repeating the following set operations across policy types:
(1) | Find the separate sets of all allow and deny statements for every policy type. | ||||
(2) | Join (union) all allow and deny statements into two separate sets. | ||||
(3) | Obtain all allowed and denied actions from the two statement sets. | ||||
(4) | Find the difference between the sets of allowed and denied action. | ||||
For example, implementing the above procedure to find all actions allowed by only identity-based managed policies means tracing the associations from
Certain permission combinations can permit privilege escalations. An example is tampering with users’ credentials or login profiles, which provide access to the management console. A challenging tactic to reflect in MAL is creating new resources with privileged IAM roles. The DSL models this for each
5.1.4 Vulnerability.
The Vulnerability specification provides assets for modeling software vulnerabilities and exploits. The intuition is modeling
Listing 3. Determining actions allowed by managed policies for an identity.
Exploits are, similar to vulnerabilities, modeled after the CVSS base impact metrics. The CVSS measures impact as the effects on confidentiality, integrity, and availability. Their possible values are none (N), low (L), and high (H). The DSL for AWS defines
An important attack simulation use case is investigating what-if scenarios and reasoning with imperfect information. The vulnerability constructs have so far dealt with known vulnerabilities. Unknown vulnerabilities are modeled by instantiating
5.2 Service Specifications
5.2.1 Elastic Compute Cloud.
The specification for EC2 models virtual machines. It mostly uses the Core specification assets, since it aptly defines basic virtual machine instances. The additions define specific
5.2.2 Relational Database System.
The specification for the Relational Database Service (RDS) mostly utilizes Core assets, since a database host,
5.2.3 DynamoDB.
The DynamoDB service hosts NoSQL databases. The primary assets in the specification for DynamoDB are
5.2.4 Simple Storage Service.
The final storage specification is for S3. It currently defines base relationships between the
5.2.5 Key Management System.
Certain services can interface with the centralized Key Management Service (KMS). The specification for KMS handles a Customer Master Key,
5.2.6 Elastic Container Registry.
The specification for the Elastic Container Registry (ECR) is more extensive. This specification, along with the Elastic Container Service specification, was an extension to the DSL developed by Jefford-Baker [24]. ECR is a storage service for docker images. The primary components of the specification are
5.2.7 Elastic Container Service.
The Elastic Container Service (ECS) deploys docker images stored in ECR. The main assets of the specification for ECS are
5.2.8 Lambda, CodeStar, and CloudFormation.
The specifications for Lambda, CodeStar, and CloudFormation are largely stubs at the time of writing. They provide the minimum functionality required to model role-based privilege escalations. This requires the definition of the service itself and a single corresponding resource creation
6 DEMONSTRATION
Figure 10 shows how a simplified variant of the Capital One incident could be represented in the DSL for AWS. The services exercised are S3, EC2, IAM, and Vulnerability. The network interface asset (VPC) is required to request the EC2 role credentials with S3 privileges. The assumptions are that the attacker can invoke the S3 API and communicate with a representative vulnerable application. Simulating this results in getting the Snappy Parquet S3 object via the EC2 role due to a request forgery vulnerability. Generally, this scenario is a cloud data breach by obtaining and abusing valid credentials. The networking portion was not demonstrated here but it is tested in the upcoming validation section.
Fig. 10. Demonstration of the Capital One request forgery and privilege abuse using the DSL for AWS. Highlighted objects indicate entry points.
6.1 Extending the Language
The DSL can only be extended by manually editing the MAL source code at this time. Further development activities can follow the threat modeling procedures described in this work (Figure 2). Creating or extending the essential specifications often cannot rely on pre-existing code, making them more challenging to demonstrate effectively. However, developing service specifications is straightforward, since they can rely on the underlying essential specifications. For example, extending the Lambda stub specification mainly requires the appropriate resources and IAM privileges to be specified.
Extensibility is best demonstrated by developing, for example, the Lambda stub specification. The scope of this demonstration will be the Lambda service and some select operations. The assets in scope were the functions and their execution roles.30 The threats for this iteration will be deletion, invocation, and source code updating to abuse the execution role IAM privileges. What remains now is the MAL implementation.
Listing 4 shows how the Lambda logic and the identified threats could be implemented in MAL. The Lambda function is realized as the
Listing 4. How the Lambda stub specification could be extended.
7 VALIDATION
Table 4 shows how well the DSL performed in each CloudGoat scenario in terms of coverage. The maximum node coverage, DSL nodes, was generally high and mostly higher than the corresponding maximum link coverage, DSL links. The exception for both nodes and links was scenario six, where maximum coverage was lower due to some unsupported services. However, the actual node and link coverage was often below the max coverage. The reasons become clear once the paths produced by the DSL are examined in detail.31
| Scenario | Nodes | DSL nodes | Node coverage | DSL links | Link Coverage |
|---|---|---|---|---|---|
| 2. cloud_breach_s3 | 3 | 100% | 100% | 100% | 100% |
| 4. ec2_ssrf | 8 | 88% | 50% | 43% | 29% |
| 5a. rce_web_app | 7 | 88% | 71% | 80% | 60% |
| 5b. rce_web_app | 7 | 86% | 57% | 75% | 50% |
| 5c. rce_web_app | 7 | 100% | 71% | 80% | 60% |
| 6a. codebuild_secrets | 8 | 63% | 50% | 29% | 29% |
| 6b. codebuild_secrets | 7 | 71% | 43% | 40% | 20% |
| 6c. codebuild_secrets | 6 | 67% | 50% | 20% | 20% |
The main barriers were unsupported operations and, especially, credentials planted in user data items.
Table 4. Overview of the CloudGoat Path Coverage
The main barriers were unsupported operations and, especially, credentials planted in user data items.
7.1 Second Scenario—Cloud_Breach_s3
This scenario is similar to the Capital One incident3 and the previous modeling demonstration. However, this scenario includes the VPC configurations as well. The attacker should exploit a server-side request forgery (SSRF), obtain access keys from the EC2 metadata, and use the keys to reach an S3 object. The DSL produced a full and linked solution, shown in Figure 11, by assuming the existence of an
Fig. 11. Three normalized steps of the second scenario and the path the DSL reported.
7.2 Fourth Scenario—ec2_ssrf
This scenario expects the attacker to obtain an access key pair from Lambda environment variables, then another key pair from the EC2 metadata for a different S3 bucket. As shown in Figure 12, the DSL supported many of the required steps but did not combine them. Going from user A to user B required the Lambda list operation that was not implemented at the time. Similarly, Vanguard not considering Lambda function an end goal made the visualization omit the last invoke step. However, user B was only required for enumeration, which the DSL omits by design. Overall, though, the main challenge was the scenario relying on planted credentials. This is a weakness in the data collection pipeline that becomes clear in the following scenario.
Fig. 12. Eight normalized steps of the fourth scenario and what the DSL reported. The outlined graph elements represent the max coverage, what the DSL should cover. The filled elements represent the actual coverage, what was reported. Crosses indicate unsupported operations.
7.3 Fifth Scenario—Rce_Web_App
This scenario is presented as three branching paths, all shown in Figure 13. The DSL covered most of this scenario but the end goal was unreachable. The reason is illustrated as the missing links to access RDS across all paths. Notably, the simulation stopped at data read operations, where the planted credentials were. A similar pattern is evident in the first S3 get operations. The simulation covered the actions, but could not directly continue from there. Rather, multiple independent paths were required to assemble the full picture presented in Figure 13. The underlying deficiency is the data collection pipeline, as the data content is neither collected nor interpreted.
Fig. 13. Normalized steps of three paths in the fifth scenario and what the DSL reported. Each horizontal row represents a branch. The outlined graph elements represent the max coverage, what the DSL should cover. The filled elements represent the actual coverage, what was reported. Crosses indicate unsupported operations.
7.4 Sixth Scenario—Codebuild_Secrets
This scenario had three branching paths as well, all shown in Figure 14. The end goal in path A was reached, despite the initially low coverage for this scenario. In path A, the DSL accounted for the RDS portion of the scenario except for the unsupported snapshot operations. The two remaining paths were missed largely due to unsupported services. However, even if adding the services would improve coverage, the problem with planted credentials would remain.
Fig. 14. Normalized steps of three paths in the sixth scenario and what the DSL reported. Each horizontal row represents a branch. The outlined graph elements represent the max coverage, what the DSL should cover. The filled elements represent the actual coverage, what was reported. Crosses indicate unsupported operations.
7.5 Coverage Comparison
On November 5, 2021, awspx supported IAM, EC2, S3, and Lambda. Table 5 shows the coverage of both the DSL and awspx32 calculated from the same normalized CloudGoat solutions. On average, the DSL performed better, since it included more services. Awspx outperformed the DSL in scenario four, because it included more Lambda operations. However, there are key differences between the two not evident in coverage. Awspx contained significantly more operations per service, since it mapped out benign actions as well, resulting in better coverage. However, it could not account for vulnerabilities, such as request forgeries, making it less capable of building vulnerability chains.
| Scenario | Length | Node coverage | awspx nodes | Link coverage | awspx links |
|---|---|---|---|---|---|
| 2. cloud_breach_s3 | 3 | 100 % | 66 % | 100 % | 50 % |
| 4. ec2_ssrf | 8 | 50 % | 86 % | 43 % | 43 % |
| 5a. rce_web_app | 7 | 71 % | 57 % | 80 % | 40 % |
| 5b. rce_web_app | 7 | 57 % | 43 % | 75 % | 20 % |
| 5c. rce_web_app | 7 | 71 % | 57 % | 80 % | 60 % |
Table 5. Node and Link Coverage of the DSL Compared to Awspx When Assessing the Same CloudGoat Scenarios
7.6 Performance Test
Figure 15 shows the attack simulation time measurements; 328 observations were collected with 14 anomalies removed, leaving a total of 314. The average model size, instantiated DSL assets, was 7,784 with a median of 6,962, which corresponds to the cluster in between 5,000 and 10,000 assets in Figure 15(a). The mean time for the Figure 15(a) calculations was 30.41 s, with a median of 21.70 and standard deviation of 24.95. The vast majority of simulations finished in less than 60 s for models containing 15,000 assets or less.
Fig. 15. Performance results measured in seconds. The simulations sampled the attack graphs 100 times.
Only 10 models exceeding 15,000 assets (Figure 15(b)) were measured. These simulations approached or exceeded 100 s of simulation time. There is a distinct increase from 60,000 assets; 60,000 assets took 191.50 s, whereas 80,000 took 566.08 s, approximately 3 min compared to nine and a half. However, the latter might be abnormally inflated by queuing times on the machine that ran the simulation. Nevertheless, every measured simulation below 80,000 completed in less than 4 min, including the queuing times.
8 DISCUSSION
CloudGoat showed that the DSL could describe and identify possible data breaches, permission issues, and network misconfigurations. In particular, the results often captured the consequences of compromising valid accounts and potential pivot points. These flaws share at least two characteristics. They are architectural and largely static. Such analyses are a strength of the DSL and an indicator of its practical usability. Moreover, it is these types of architectural analyses that become intractable at larger scales without support from tools.
However, the analogy driving this work, and the analogy behind MAL-based attack simulations [26, p. 1], was parallel virtual penetration tests. When validated accordingly, it became evident that some simpler penetration testing tasks could be difficult. Conversely, some complex tasks became simple, such as architectural analysis. One option is changing the analogy, which could change the choice of validation tests and re-orient the expectations on the DSL. But rather than retroactively changing analogy, this is perhaps better practiced in future work.
Still, if viewed through penetration testing, the missing links from CloudGoat may further indicate a limitation with the underlying graph construction method. Namely, some realistic attacker tactics change the environment. This is especially relevant when assessing dynamic environments, such as cloud environments. Some cloud assets can be created, removed, and modified with relative ease. Such tactics can sometimes be computed with hypothetical reasoning. For example, being allowed to create EC2 instances with certain privileges implies accessing it to obtain those privileges. However, this challenge exists, because the underlying attack graphs cannot change once computed.
The planted credentials posed a different challenge, which was interpreted as a data collection limitation. For instance, linking credential assets to S3 objects is a simple modeling task. However, the difficulty lies in inferring when and how to do so. Such tasks impose different challenges, including automatically identifying the AWS API key signatures or high entropy strings as possible passwords. A simpler approach would be to assume such possibilities and build models accordingly, but this is also a non-trivial task.
Vanguard, and by extension the DSL, had to rely on certain assumptions for automation, often the catch-all unknown vulnerability. Strictly how attack simulations should deal with ambiguity and guessing remains an open issue. There were also assumptions regarding preferred attack targets. For example, being unable to select Lambda as a target might have omitted the final step in the reported results (Figure 13). Finally, cursorily removing the Internet exposure shifted assessment results toward user credential theft in scenario five. This opens up questions about realistic assumptions, attacker profiling, decision-making, and sensitivity for future work. MAL simulations are, at the time of writing, simple shortest path calculations.
The calculation time was, for the majority of the sample, below 1 min. Additionally, all measurements were slower than the actual time, since the queue times could not be separated from the calculations. This is one plausible reason behind some models below 10,000 assets exceeding 1 min but not others. The measurements for models beyond 20,000 DSL assets were sparse. However, the results indicated favorable scaling up until 40,000 assets and beyond. Visually, there is an indication of quadratic scaling, but that conclusion requires further measurements at the appropriate scale.
Compared to earlier work, the DSL can reason about VPC configurations and IAM policies in the context of cyber attacks, bearing some resemblance to TIROS [6] and Zelkova [7], and any amount of known and unknown vulnerabilities. The automated workflow additionally enables continuous assessments of configurations and changes. Once the DSL is fully probabilistic, it will also rank attack paths more accurately. At this stage, simulation sensitivity might be a central validation metric. There are, however, no suggestions for patching strategies,33 like Vulnus [3], or countermeasures like References [16, 23, 44].
8.1 Improving the DSL
One language issue was the DSL being too straightforward. It could not always simulate tactics, such as deploying then accessing database snapshots. Certain methods are, however, difficult to represent in MAL due to its static models. Nevertheless, planted inline credentials and similar collection tactics were the major obstacle encountered. To re-iterate, this is not inherently a modeling limitation. The logic could easily be represented, for example, via EC2ReadMetadata.credentials.access. The problem is knowing when to invoke such logic and how to enhance the data collection pipeline.
Some auditing tools could alert to potential secrets stored in the environment and thereby enrich the data collection pipeline. Similarly, credential scanners, such as cred_scanner (Table 2), could potentially fill a similar function. Such tools could indicate when to invoke credential access logic, which could be a sufficient alert to end users. Moreover, a sufficiently privileged data collection agent might also determine the nature of, at least, found AWS credentials. This would be the ideal solution for AWS-specific keys, but automatically identifying other credentials remains an open issue.
Another topic is knowledge acquisition for the DSL and MAL-based artifacts overall, a missing component from the analogy with expert and knowledge-based system. Acquisition mechanisms enabling end users to update the attack and defense logic is preferable to manually editing MAL code. Additionally, it would improve the usability and long-term maintainability of the DSL and MAL-based artifacts overall. In a similar vein, the recent work by Gylling et al. [19] leveraged threat intelligence, especially the ATT&CK matrix, in the context of MAL and probabilistic attack graphs. Further work in this direction, also for the DSL and cloud security, could be lucrative. Integration with existing threat intelligence standards, such as STIX [8] or those discussed in Reference [56, pp. 23–24] could be of particular interest.
8.2 Limitations
The quality of test-based validations depends on the relevance and coverage of the scenarios [45]. The CloudGoat scenarios are inherently artificial, making generalizations about performance in real-world environments uncertain. CloudGoat did include most of the CSA top five threats [13] and some Cloud Matrix tactics to some extent. Furthermore, some incidents such as the Capital One request forgery were explicitly represented. However, specific attacks, such as container escapes, were neglected. Conversely, CloudGoat contained services not supported by the DSL. The missing services and operations highlight lapses in the DSL, many that could be modeled with relative ease. What can be concluded overall is that correct logic sequences produced in CloudGoat are likely replicable in practice. However, test cases give limited insights on validity outside of coverage.
One drawback with testing through Vanguard was it potentially obscuring some results. The disparity between the DSL and actual coverage is evidence of this. A manual check could determine whether missed user accounts were visited at all. However, since these users had no practical impact on the simulations, the reports omitted them. The result is a lower actual coverage than DSL coverage. The problem is arguably a form of sensitivity in the reporting and user settings. Specifically, when user settings or assumptions in software, such as Vanguard, do not match expectations. For example, if Lambda is not checked or considered as an end goal, then it might not be reported as a result despite being covered. The path diagrams in Section 7 improve transparency but were created manually. Similarly, the normalized CloudGoat steps were also produced by manually interpreting the, sometimes incomplete, CloudGoat solutions. In the end, obtaining objective coverage and quality measurements were challenging.
9 CONCLUSIONS
Migrating to cloud platforms like AWS has become increasingly common, but customer-side mistakes routinely cause security incidents. Testing the DSL for AWS against CloudGoat via Vanguard demonstrated the ability of the language to identify basic AWS security issues automatically. The tests suggested no fundamental structural or logical issues in the DSL, but CloudGoat highlighted certain shortcomings. For one, there is room for more advanced attacker tactics and additional cloud services in the language. The simulated behaviors and attacker profiles are also rudimentary and can be examined further. Finally, issues with opaque data and collection techniques remained unresolved. Nevertheless, the real-world precedents showed that even major breaches could have “egregious,” yet simple, causes of the kind the DSL could demonstrably identify. Future improvements regarding cloud tactics and data collection steps should yield considerable improvements.
9.1 Future Work
Future work can explore how to handle inline credentials, for example, by finding them or adding some probabilistic attack steps. Another line of inquiry is identifying further attacker tactics and profiles. One method is studying existing literature and incidents, possibly with input from security firms and industrial actors. A similar approach could also provide data for assigning probability distributions in the DSL. A third angle could be devising graph-traversal algorithms. MAL-simulations currently rely on finding the shortest path, but more realistic methods might incorporate behavioral or decision-making theory. Specifically, attackers and the paths they produce may need to be constrained by their resources, preferences, and character traits. Finally, further work regarding countermeasure suggestions might require a separate algorithm together with a MAL extension for defining security controls.
Footnotes
1 https://www.gartner.com/smarterwithgartner/is-the-cloud-secure.
Footnote2 2021 IBM Security X-Force Cloud Threat Landscape Report: https://www.ibm.com/downloads/cas/WMDZOWK6.
Footnote3 Capital One incident: https://www.justice.gov/usao-wdwa/pr/seattle-tech-worker-arrested-data-theft-involving-large-financial-services-company.
Footnote4 Tesla hack: https://www.cnbc.com/2018/02/21/hackers-hijack-teslas-cloud-system-to-mine-cryptocurrency-redlock.html.
Footnote5 Uber breach: https://www.bbc.com/news/technology-42075306.
Footnote6 Accenture leak: https://www.zdnet.com/article/accenture-left-a-huge-trove-of-client-passwords-on-exposed-servers/.
Footnote7 Time Warner breach: https://www.bbc.com/news/technology-41147513.
Footnote8 https://www.cyberark.com/threat-research-blog/cloud-shadow-admin-threat-10-permissions-protect/.
Footnote9 https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/.
Footnote10 https://securityriskadvisors.com/blog/aws-iam-exploitation/.
Footnote- Footnote
12 https://www.hyperglance.com/.
Footnote13 For an extensive list, see https://github.com/toniblyx/my-arsenal-of-aws-security-tools.
Footnote14 MITRE cloud matrix: https://attack.mitre.org/matrices/enterprise/cloud/.
Footnote15 https://www.foreseeti.com/securicad-vanguard-for-aws/.
Footnote16 https://github.com/fsecurelabs/awspx.
Footnote17 https://github.com/rams3sh/Aaia.
Footnote18 https://docs.aws.amazon.com/index.html.
Footnote19 https://attack.mitre.org/matrices/enterprise/.
Footnote20 https://github.com/RhinoSecurityLabs/cloudgoat.
Footnote21 An archived copy can be found at: https://github.com/viktorengstrom/cloudgoat.
Footnote22 The original results, including the omitted tests, can be found at: https://github.com/KTH-SSAS/DSLforAWS/tree/master/tests.
Footnote23 https://docs.foreseeti.com/docs/configure-simulations#attacker-profile.
Footnote24 For more on instance types, see https://aws.amazon.com/ec2/instance-types/.(Accessed11November2021).
Footnote- Footnote
26 https://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html.
Footnote27 https://docs.microsoft.com/en-us/cpp/cpp/single-inheritance.
Footnote28 https://github.com/mal-lang/malcompiler.
Footnote29 https://www.first.org/cvss/v3.1/specification-document.
Footnote30 Obtained via GetFunctionConfiguration according to https://docs.aws.amazon.com/lambda/latest/dg/lambda-dg.pdf, pp. 831–837. (Accessed 9 November 2021).
Footnote31 The original paths are available at: https://github.com/KTH-SSAS/DSLforAWS/tree/master/tests/vanguard%20output.
Footnote32 The original awspx results are available at: https://github.com/KTH-SSAS/DSLforAWS/tree/master/tests/awspx.
Footnote33 Vanguard has since been improved to report threat rankings and bottlenecks with root causes. This suggests where weaknesses are but not necessarily an efficient order to address them in or how.
Footnote
- [1] . 2003. Introduction to the OCTAVE Approach.
Technical Report . Software Engineering Institute, Carnegie-Mellon University, Pittsburgh, PA.Google ScholarCross Ref
- [2] . 2014. SecDSVL: A domain-specific visual language to support enterprise security modelling. In Proceedings of the 23rd Australian Software Engineering Conference. IEEE, 152–161. Google Scholar
Digital Library
- [3] . 2018. Vulnus: Visual vulnerability analysis for network security. IEEE Trans. Visual. Comput. Graph. 25, 1 (2018), 183–192.Google Scholar
Digital Library
- [4] . 2019. MAD: A visual analytics solution for multi-step cyber attacks detection. J. Comput. Lang. 52 (2019), 10–24.Google Scholar
Cross Ref
- [5] . 2002. Netspa: A Network Security Planning Architecture. Ph.D. DissertationMassachusetts Institute of Technology.Google Scholar
- [6] . 2019. Reachability analysis for AWS-based networks. In Proceedings of the International Conference on Computer Aided Verification. Springer International Publishing, Cham, 231–241.Google Scholar
Cross Ref
- [7] . 2018. Semantic-based automated reasoning for AWS access policies using SMT. In Proceedings of the Formal Methods in Computer Aided Design (FMCAD’18). IEEE, IEEE, 1–9.Google Scholar
Cross Ref
- [8] . 2012. Standardizing cyber threat intelligence information with the structured threat information expression (STIX). Mitre Corp. 11 (2012), 1–22.Google Scholar
- [9] . 2014. Key challenges and opportunities in cloud computing and implications on service requirements: Evidence from a systematic literature review. In Proceedings of the IEEE 6th International Conference on Cloud Computing Technology and Science. IEEE, 114–121.Google Scholar
Digital Library
- [10] . 2018. A systematic review of cloud modeling languages. ACM Comput. Surveys 51, 1 (2018), 1–38.Google Scholar
Digital Library
- [11] . 2001. A requirements-driven development methodology. In Proceedings of the International Conference on Advanced Information Systems Engineering. Springer, Berlin, 108–123.Google Scholar
Cross Ref
- [12] . 2010. Visualizing attack graphs, reachability, and trust relationships with NAVIGATOR. In Proceedings of the 7th International Symposium on Visualization for Cyber Security. ACM, New York, NY, 22–33.Google Scholar
Digital Library
- [13] . 2019. Top Threats to Cloud Computing: Egregious Eleven.
Technical Report . Cloud Security Alliance. Retrieved from https://cloudsecurityalliance.org/artifacts/top-threats-to-cloud-computing-egregious-eleven/.Google Scholar - [14] . 2007. Model-based security analysis in seven steps-a guided tour to the CORAS method. BT Technol. J. 25, 1 (2007), 101–117.Google Scholar
Digital Library
- [15] . 2014. Security issues in cloud environments: A survey. Int. J. Info. Secur. 13, 2 (2014), 113–170.Google Scholar
Digital Library
- [16] . 2015. Netsecuritas: An integrated attack graph-based security assessment tool for enterprise networks. In Proceedings of the International Conference on Distributed Computing and Networking. ACM, New York, NY, 30.Google Scholar
Digital Library
- [17] . 2010. Understanding cloud computing vulnerabilities. IEEE Secur. Privacy 9, 2 (2010), 50–57.Google Scholar
Digital Library
- [18] . 2010. Attack surfaces: A taxonomy for attacks on cloud services. In Proceedings of the IEEE 3rd International Conference on Cloud Computing. IEEE, 276–279.Google Scholar
Digital Library
- [19] . 2021. Mapping cyber threat intelligence to probabilistic attack graphs. In Proceedings of the IEEE International Conference on Cyber Security and Resilience (CSR’21). IEEE, 304–311.Google Scholar
Cross Ref
- [20] . 2014. P\(^2\)CySeMoL: Predictive, probabilistic cyber security modeling language. IEEE Trans. Depend. Secure Comput. 12, 6 (2014), 626–639.Google Scholar
Digital Library
- [21] . 2017. A survey on the usability and practical applications of graphical security models. Comput. Sci. Rev. 26 (2017), 1–16.Google Scholar
Digital Library
- [22] . 2009. Modeling modern network attacks and countermeasures using attack graphs. In Proceedings of the Annual Computer Security Applications Conference. IEEE, 117–126.Google Scholar
Digital Library
- [23] . 2011. Cauldron mission-centric cyber situational awareness with defense in depth. In Proceedings of the Military Communications Conference (MILCOM’11). IEEE, 1339–1344.Google Scholar
Cross Ref
- [24] . 2019. ALCOL: Probabilistic Threat Modelling of the Amazon Elastic Container Service Domain. Master’s thesis KTH Royal Institute of Technology, Stockholm, Sweden.Google Scholar
- [25] . 2009. On technical security issues in cloud computing. In Proceedings of the IEEE International Conference on Cloud Computing. IEEE, 109–116.Google Scholar
Digital Library
- [26] . 2018. A meta language for threat modeling and attack simulations. In Proceedings of the 13th International Conference on Availability, Reliability and Security. ACM, New York, NY, 38.Google Scholar
Digital Library
- [27] . 2016. Can the common vulnerability scoring system be trusted? A Bayesian analysis. IEEE Trans. Depend. Secure Comput. 15, 6 (2016), 1002–1015.Google Scholar
Cross Ref
- [28] . 2016. pwnpr3d: An attack-graph-driven probabilistic threat-modeling approach. In Proceedings of the 11th International Conference on Availability, Reliability and Security (ARES’16). IEEE, IEEE, 278–283.Google Scholar
Cross Ref
- [29] . 2016. Quantitative information security risk estimation using probabilistic attack graphs. In Proceedings of the International Workshop on Risk Assessment and Risk-driven Testing. Springer International Publishing, Cham, 37–52.Google Scholar
- [30] . 2002. UMLsec: Extending UML for secure systems development. In Proceedings of the International Conference on The Unified Modeling Language. Springer, Berlin, 412–425.Google Scholar
Cross Ref
- [31] . 2009. Cloud security issues. In Proceedings of the IEEE International Conference on Services Computing. IEEE, 517–520.Google Scholar
Digital Library
- [32] . 2016. A taxonomy for attack graph generation and usage in network security. J. Info. Secur. Appl. 29 (2016), 27–56.Google Scholar
Digital Library
- [33] . 2010. Foundations of attack–defense trees. In Proceedings of the International Workshop on Formal Aspects in Security and Trust. Springer, Berlin, 80–95.Google Scholar
- [34] . 2014. DAG-based attack and defense modeling: Don’t miss the forest for the attack trees. Comput. Sci. Rev. 13 (2014), 1–38.Google Scholar
Digital Library
- [35] . 2019. On cloud security requirements, threats, vulnerabilities and countermeasures: A survey. Comput. Sci. Rev. 33 (2019), 1–48.Google Scholar
Digital Library
- [36] . 2020. A review of attack graph and attack tree visual syntax in cyber security. Comput. Sci. Rev. 35 (2020), 100219.Google Scholar
Digital Library
- [37] . 2008. Model driven security management: Making security management manageable in complex distributed systems. In Proceedings of the MODSEC@ MoDELS.Google Scholar
- [38] . 2002. SecureUML: A UML-based modeling language for model-driven security. In Proceedings of the International Conference on the Unified Modeling Language. Springer, Berlin, 426–441.Google Scholar
Cross Ref
- [39] . 2005. Foundations of attack trees. In Proceedings of the International Conference on Information Security and Cryptology. Springer, Berlin, 186–198.Google Scholar
- [40] . 2002. A natural extension of tropos methodology for modelling security. In Proceedings Agent Oriented Methodologies Workshop.Google Scholar
- [41] . 2016. Security requirements engineering for cloud computing: The secure tropos approach. In Domain-specific Conceptual Modeling. Springer, 357–380.Google Scholar
Cross Ref
- [42] . 2020. A security requirements modelling language for cloud computing environments. Softw. Syst. Model. 19, 2 (2020), 271–295.Google Scholar
Cross Ref
- [43] . 2005. Threat modeling as a basis for security requirements. In Proceedings of the Symposium on Requirements Engineering for Information Security (SREIS’05), Vol. 2005. Citeseer, 1–8.Google Scholar
- [44] . 2009. Advances in topological vulnerability analysis. In Proceedings of the Cybersecurity Applications and Technology Conference for Homeland Security. IEEE, 124–129.Google Scholar
Digital Library
- [45] . 1993. Expert system verification and validation: A survey and tutorial. Artific. Intell. Rev. 7, 1 (1993), 3–42.Google Scholar
Cross Ref
- [46] . 2005. MulVAL: A logic-based network security analyzer. In Proceedings of the USENIX Security Symposium, Vol. 8. Baltimore, MD, 113–128.Google Scholar
- [47] . 2015. Modelling and reasoning about security requirements in socio-technical systems. Data Knowl. Eng. 98 (2015), 123–143.Google Scholar
Digital Library
- [48] . 2007. A design science research methodology for information systems research. J. Manage. Info. Syst. 24, 3 (2007), 45–77.Google Scholar
Digital Library
- [49] . 1999. Attack trees. Dr. Dobb’s J. 24, 12 (1999), 21–29.Google Scholar
- [50] . 2018. AWSLang: Probabilistic Threat Modelling of the Amazon Web Services Environment. Master’s thesis KTH Royal Institute of Technology, Stockholm, Sweden.Google Scholar
- [51] . 2012. The cyber security modeling language: A tool for assessing the vulnerability of enterprise system architectures. IEEE Syst. J. 7, 3 (2012), 363–373.Google Scholar
Cross Ref
- [52] . 2010. A probabilistic relational model for security risk analysis. Comput. Secur. 29, 6 (2010), 659–679.Google Scholar
Digital Library
- [53] . 2018. Using bayesian networks for probabilistic identification of zero-day attack paths. IEEE Trans. Information Forensics and Security 13, 10 (2018), 2506–2521.Google Scholar
Cross Ref
- [54] . 1998. A Graph-based System for Network-vulnerability Analysis.
Technical Report . Sandia National Laboratories, Albuquerque, NM.Google ScholarCross Ref
- [55] . 2001. Computer-attack graph generation tool. In Proceedings DARPA Information Survivability Conference and Exposition II. DISCEX’01, Vol. 2. IEEE, IEEE, 307–321.Google Scholar
Cross Ref
- [56] . 2018. A survey on technical threat intelligence in the age of sophisticated cyber attacks. Comput. Secur. 72 (2018), 212–233.Google Scholar
Digital Library
- [57] . 2013. k-zero day safety: A network security metric for measuring the risk of unknown vulnerabilities. IEEE Trans. Depend. Secure Comput. 11, 1 (2013), 30–44.Google Scholar
Digital Library
- [58] . 2008. GARNET: A graphical attack graph and reachability network evaluation tool. In Proceedings of the International Workshop on Visualization for Computer Security. Springer, Springer, Berlin, 44–59.Google Scholar
Digital Library
- [59] . 2012. Security and privacy in cloud computing. IEEE Commun. Surveys Tutor. 15, 2 (2012), 843–859.Google Scholar
Cross Ref
- [60] . 2006. Sectet: An extensible framework for the realization of secure inter-organizational workflows. Internet Res. 16, 5 (2006), 491–506.Google Scholar
Cross Ref
Index Terms
Automated Security Assessments of Amazon Web Services Environments
Recommendations
An Attack Simulation Language for the IT Domain
Graphical Models for SecurityAbstractCyber-attacks on IT infrastructures can have disastrous consequences for individuals, regions, as well as whole nations. In order to respond to these threats, the cyber security assessment of IT infrastructures can foster a higher degree of ...
Different facets of security in the cloud
CNS '12: Proceedings of the 15th Communications and Networking Simulation SymposiumCloud computing is a long fantasized visualization of computing as a utility, where data owners can remotely store and access their data in the cloud anytime and from anywhere. Using a shared pool of configurable resources, users can be relieved from ...
Microsoft and Amazon: A comparison of approaches to cloud security
CLOUDCOM '12: Proceedings of the 2012 IEEE 4th International Conference on Cloud Computing Technology and Science (CloudCom)Research has shown that data security has always been an important aspect of quality of service for data service providers; but cloud computing poses new and challenging security threats. The most common security concerns for users of cloud storage are ...

























Comments