The Right Tool for the Job: A Case for Common Input Scenarios for Security Assessment

Abstract

Motivated by the practical importance of security assessment, researchers have developed numerous model-based methodologies. However, the diversity of different methodologies and tool designs makes it challenging to compare their respective strengths or integrate their results. To make it more conducive to incorporate them for practical assessment tasks, we believe it is critical to establish a common foundation of security assessment inputs to support different methodologies and tools. As the initial effort, this paper presents an open repository of Common Input Scenarios for Security Assessment (CISSA) for different model-based security assessment tools. By proposing a CISSA design framework and constructing six initial scenarios based on real-world incidents, we experimentally show how CISSA can provide new insights and concrete reference points to both security practitioners and tool developers. We have hosted CISSA on a publicly available website, and envision that community effort in building CISSA would significantly advance the scientific and practical values of model-based security assessment.

A Appendix: CISSA Example

In this section we provide an example CISSA by describing the seven elements (N, D, U, O, X, A, C) for the Target Corporation data breach. The input files themselves are available online in XML format [1].

1.1 A.1 Brief Recap of the Target Incident

The data breach at Target Corporation in 2013 resulted in the loss of credit card data from 40 million customers [3, 8]. This multi-stage attack began with the theft of an HVAC vendor’s credentials for Target’s vendor management web portal. From there, attackers were able to penetrate deep into Target’s corporate network, steal personally identifiable information (PII) from a database, and deploy malware to pull customers’ credit card information off of Target’s point-of-sale machines. Stolen data were exfiltrated via FTP from inside the corporate network.

Fig. 7.

Components and network for target input scenario

1.2 A.2 CISSA Definition for the Target Scenario

To illustrate how CISSA specification can represent the details of read-world incidents for security assessment, we briefly present how we define the Target scenario under CISSA.

Components and Network  N . A large retailer such as Target typically has 100s or 1000s of locations, each with numerous point-of-sale (POS) stations that accept and process customer payments. Figure 7 depicts the network connections ($E_N$) and devices ($V_N$) considered in this scenario. The model includes K store locations, each with $T_K$ POS machines which are connected via a switch to a back-of-house (BoH) server. This BoH server connects to a central payment server at the corporate network, which interfaces with external financial institutions to verify transactions. The corporate network also includes a directory server, a web server, and a database server. We abstract other corporate services from this model. In the XML files online [1] we specify additional information.

Data  D . Data plays a central role in the Target CISSA. The attackers’ goal was the theft of customer data, and this was made possible by the acquisition of additional system-specific data. Table 5 describes the data items that are modeled in this scenario. We provide a unique identifier for each data item $ID_D$, a description of the data’s properties $L_D$, and a list of devices that interact with the data $Map_D$ (network links are omitted for brevity).

Table 5. Data items in the target input scenario

Users  U . In this scenario, several different user types are affected by the incident. In particular, credentials from a vendor and, later, a Domain Administrator, enabled the adversaries to steal sensitive information relating to the company’s customers. Table 6 summarizes the relevant user information.

Table 6. Users in the target input scenario

Operations  O . Arguably the most important system operation in this scenario is the handling of consumer credit card information during POS transactions. Figure 8 depicts this process. Here the vertices $V_O$ denote the major operations from the POS terminal, a store’s BoH Server, and the Bank responsible for clearing the transaction, while the edges $E_O$ imply sequential order. The mapping function $Map_O$ in this case assigns specific devices to the roles described above (e.g., POS Terminal 5 in Store #300). Additional system operations in this scenario could include the POS Terminal or BoH Server’s software update process, or the processes for collecting and storing personally identifiable information (PII) in the company’s database.

Fig. 8.

Transaction operations for target input scenario

Table 7. Undesirable outcomes in the target scenario

Table 8. Attack steps for the target input scenario

Undesirable Outcomes  X . In this scenario we model the final undesirable outcomes of the attack as loss of credit card data and loss of personally identifiable information, as specified in Table 7. Due to space limit, we do not elaborate on intermediate undesirable outcomes $x_1$ to $x_7$ for each attack step, while providing brief summary in Table 8.

Attack  A . The attacker input $\alpha$ is modeled with:

• Goal: theft of credit card data X1.

• Access: external attacker, with access to “Web” in N.

• Skills: use of existing tools and malware (no zero-days).

The attack on Target’s corporate network and POS system is thought to consist of 11 steps [3]. We model a simplified 8-step attack, i.e., $\sigma _1$: Steal credentials of vendor, $\sigma _2$: Exploit vulnerability on Target web portal, $\sigma _3$: Steal Domain Admin access token, $\sigma _4$: Create new Domain Admin account, $\sigma _5$: Steal PII from database, $\sigma _6$: Install malware on POS machines, $\sigma _7$: Aggregate stolen data in network, and $\sigma _8$: Exfiltrate data via FTP.

The above text constitutes the attack step description input ($L_\omega$). In Table 8 we specify the pre-conditions ($Pre_\sigma$) and post-conditions ($Post_\sigma$) for these attack steps.

Table 9. Countermeasures in the target input scenario

Countermeasures  C . The credit card industry maintains a set of standards for data protection [20]. In addition to those guidelines—which were followed in this scenario—other countermeasures can potentially detect or prevent similar attacks.

• Multi-factor authentication for the outward-facing vendor portal, and for the Domain Administrators.

• Application whitelisting for the point-of-sale machines and the servers involved in transaction verification.

• Real-time monitoring of user lists and network queries to detect the addition of new user accounts (particularly admin accounts) and potentially identify lateral movement of an attacker within the network.