plop09--security threat mitigation patterns v22supakkul/papers/supakkul--security threat...

Goal-Oriented Security Threat Mitigation Patterns:

A Case of Credit Card Theft Mitigation

Sam Supakkul1, Tom Hill2, Ebenezer Akin Oladimeji3, and Lawrence Chung1

1 Department of Computer Science The University of Texas at Dallas [email protected], [email protected]

2 Office of the EDS CTO EDS, an HP company [email protected]

3 Architecture and eServices Verizon Communications [email protected]

Abstract Most attacks on computer and software systems are caused by threats to known vulnerabilities. Part of the reason is that it is difficult to possess necessary broad and deep knowledge of security related strategic knowledge to choose mitigating solutions suitable for a specific application or organization. This paper presents three patterns that use goal-oriented concepts to capture knowledge of security problems and their corresponding mitigating solutions. Each pattern captures three kinds of problems, including an undesirable outcome that negatively affects a security goal, threats that lead to the undesirable outcome, and vulnerabilities that could be exploited by the threats. Alternative mitigating solutions are captured in relation to the problems, including vulnerability risk transfer, threat prevention, threat containment, undesirable outcome recovery, and impact on the security goal prevention and control. The alternatives are identified with consequences on other non-functional requirements (NFRs) such as cost and usability, which are then used as selection criteria in associated selection patterns. The patterns illustrate how knowledge of security incidents and security standards may be captured and used to help avoid the security problems suffered by TJX in the largest credit card theft incident in history.

1 Introduction Most attacks on computer and software systems are caused by threats to known vulnerabilities [Jon99].

Part of the reason is that it is difficult to possess necessary broad and deep knowledge of security related knowledge to understand the security problems, alternative mitigating solutions, and the selection of suitable solutions that also meet other organizational needs. For example, in order to prevent security problems, such as those suffered by TJX in the largest credit card theft in history, organizations need to be able to answer the following questions:

Q1: What does credit card security really mean?

Q2: What were the problems suffered by TJX?

Q3: What were the root causes of those problems?

Q4: How could the problems and causes be mitigated?

Q5: How to choose mitigating solutions that also meet other, often conflicting, organizational needs?

Properly answering these questions requires a large body of strategic knowledge. However, it is difficult to possess such broad and deep knowledge as security incident reports describing the incident and security standards containing potential solutions are often described informally and without context and rationale to guide us when each recommended security measure should be used. As a result, we face an insurmountable secure-systems design task.

Security patterns have been used to capture knowledge of specific threats [Fer07, Pel09] and solutions at both analysis level [Feb07b] and architecture/design level [Yod97, Fer01, Che03, Sch03, Pri04, Sch06, Fer07, Pel09, Mou03, Oku08]. However, these patterns provide partial answers to these questions in standalone separate patterns, making it difficult to grasp a high-level strategic comprehensive view for understanding security context, problems, solutions, and their relationships, and for deciding appropriate security solutions that provide adequate security, at the same time, also achieve other often conflicting organizational concerns such as cost and usability non-functional requirements (NFRs).

This paper presents goal-oriented security threat mitigation patterns for capturing cohesive strategic knowledge of security problems and solutions that capture three aspects of security problems including undesirable outcomes, their causing threats, and the exploited vulnerabilities, which are used as the basis

for exploring solutions that mitigate the vulnerabilities by changing the security asset and facility so that the new risk is more acceptable, mitigate the threats by preventing or containing the threats, or preventing or controlling the undesirable outcomes. In addition to being identified in relation to the security problems, the alternatives are noted with consequences on other non-functional requirements (NFRs), which are then used as criteria for selecting suitable mitigating solutions. Three concrete patterns are presented to illustrate how knowledge of security incidents, security standards and other best practices may be captured and used to help avoid the security problems suffered by TJX in the largest credit card theft incident in history.

The rest of the paper is structured as follows. Section 2 describes the TJX incident as the basis for the patterns presented in this paper. Section 3 describes the meta-pattern as a visual template for the patterns presented in Sections 4, 5, and 6. Section 7 discusses related work and observations. Section 8 summarizes the paper and future work.

2 The TJX Case TJX, the holding company of many large retail chains such as TJ Maxx and Marshalls, suffered the largest credit card theft in history between 2003 and 2008 that was initially estimated to have affected 45 million credit cards, identity information of 451,000 customers, $20 millions in fraudulent transactions, and to cost TJX $1 billion over 5 years excluding lawsuits [Gau07, Hil07, Hil08, Per07, US08, Can07]. This incident became an infamous case study in retail and credit card industries, and in the security community [Bra07]. We have studied over 30 news articles, investigation reports, and a court indictment, which are mostly informal description of the case. We found it difficult to get a clear picture of the scenario how the incident occurred. Based on the publically available information with some assumptions, we developed a diagram to describe the attack scenario as shown in Figure 1.

Figure 1. The Attack Scenario and Three Realized Security Threats in the TJX Incident

This paper presents three patterns for mitigating the three security threats described in the scenario, including Wireless WEP Hacking, Remote Access Masquerading, and Malicious Transfer of Sensitive Data mitigation patterns. Since specific detailed attacks of these threats are not reported in the publically available sources, we capture many possible causes as well as alternative solutions from the literature and the PCI DSS security standard.

3 A Visual Meta-Pattern for the Security Mitigation Patterns Figure 2 depicts a visual meta-pattern that serves as a visual template for understanding and creating the patterns shown in Figure 3, Figure 6, and Figure 9 in the spirit of Alexander's “three-part rule” expressing “a relation between a certain context, a problem, and its corresponding solution(s)”. In each pattern, the outer area (left , top, and right) represents the security context, including asset and forces (security goal and other NFRs), for the security problems and their corresponding alternative mitigating solutions that may have positive and/or negative consequences toward the (NFRs) forces that need to be taken into account.

The positive or negative contribution links (green or red directed lines) indicates how the achievement of one goal/problem contributes to the achievement/denial of another goal/problem. SomePlus (“S+”), Help/+, and Make/++ indicate that an achievement of a goal/problem helps (with an unknown degree), partially helps, or definitely helps achieve another goal/problem. SomeMinus (“S-”), Hurt/-, Break/-- indicates that an achievement of a goal/problem helps (with an unknown degree), partially helps, or definitely helps deny another goal/problem. A goal/problem may be AND/OR decomposed (denoted by single- or double-bar lines) to more specific goals or problems.

Security asset is either a primary asset or facility. Primary asset is a piece of information, an operation, a physical entity, or human, that is of high value that needs to be protected, for example, credit card information or an e-commerce web site. Facility is a secondary asset that when compromised could lead an undesirable outcome against the primary asset, for example, network and server that have direct or indirect access to credit card information.

Security goal is a security concern in the context of an asset. For example, a US law defines security as confidentiality, integrity, and availability security objectives [FIS02], while the payment card industry is concerned with only the confidentiality of payment card information [PCI05].

Security problem is an undesirable outcome, a threat, or a vulnerability. Undesirable outcome is an undesirable situation that negatively impacts a security goal, for example, stolen credit card information is an undesirable outcome that hurts the confidentiality of credit card information. Threat is an operation or technique that may be used to exploit a vulnerability, for example, the hacker in the TJX case broke wireless network WEP encryption key that may have exploited weak WEP encryption algorithm vulnerability. Vulnerability is a weakness of an asset or facility.

Mitigating solution is an impact prevention and control, threat prevent and containment, or vulnerability risk transfer. Impact prevention and control is a solution that prevents a realized undesirable outcome from inflicting a negative impact on a security goal. For example, PCI recommends that card authentication data (e.g. card verification code) be not stored to make credit card information useless if stolen. Threat

prevention and control is a mitigating solution that helps prevent a threat from being realized, reduce or eliminate the possibility for a realized threat from causing an undesirable outcome. Vulnerability risk

transfer is a solution that changes the facility so that the risk associated with the old facility is transfer to the risk of the new facility that is more acceptable. For example, the high risk associated with wireless WEP encryption could be transferred to a lower risk of a more secure wireless WPA encryption. The notion of risk transfer is adapted from a risk management technique discussed in [Boe89].

FunctionReference

Interface

Legend

Agent NFR Solution

ANDdecomposition

++Make

+Help

DirectContribution

Consequence

– – –Break Hurt

ORdecomposition

S+

Some+

S-Some-

UndesirableOutcome

A

Asset

F

Facility Function

Threat Vulnerability

NFRReference

context problem solution

forcesasset

context

Undesirable outcome [Asset]

Threat

Vulnerability

Asset

++

++

Facility

Risk Transfer [Vulnerability]

Prevention [Threat]

Containment [Threat]

Security objective [Asset]

.

Positively affected NFR

Negatively affected NFR

S+

S-

S-

S-

S-

S-

S+S+S+

Prevention and control[Impact]

S-

S+

S+

S-

S+

S-

S+

S-

.

A

F

Figure 2. A Visual Meta-Pattern for Security Mitigation Patterns

4 Wireless WEP Hacking Mitigation Pattern

Figure 3. A Wireless WEP Hacking Mitigation Pattern

The Wireless WEP Hacking mitigation pattern in Figure 3 is concerned with the confidentiality of an

intranet (security goal) that can be compromised via a wireless network (facility) by wireless WEP hacking, including (1) passive attacks such as brute-force keys trying, fragmentation attack, or weak

IV attack, or (2) active attacks such as replay attack and insider attack (threats) that can exploit shared key authentication, short key length, known characteristics of ARP packets, and weak WEP encryption algorithm (vulnerabilities), which could lead to unauthorized access to the intranet

(undesirable outcome) that negatively affects the confidentiality of the intranet (security goal).

The shared key authentication, short key length, known characteristics of ARP packets, and weak

WEP encryption algorithm (vulnerabilities) can be mitigated by not using shared key authentication, restricting access based on MAC addresses, using at least 104-bit encryption key, using more secure

encryptions such as WPA, WPA2, IPSEC, VPN, or SSL/TLS (risk transfer measures) that change the facility to that with more acceptable risks. The insider attack (threat) can be prevented by frequently

changing key either manually every quarter or every major personnel change, or automatically every

few hours (preventive measures). These mitigation solutions have positive and/or negative consequences upon cost, administration need, and usability (NFRs).

4.1 Context

Asset Intranet: An internal network that has direct or indirect access to sensitive information that is desirable by hostile agents.

Facility Wireless network: Wireless network provides a convenient and cost effective means for data communication based on IEEE 802.11 standard. Because wireless signal can be easily intercepted by hostile agents within the signal range, it is recommended that private wireless networks be configured to encrypt transmitted data. WEP is an encryption widely used by the first generation wireless networks. It uses RC4 encryption algorithm that generates keystreams of 64 or 128 bits in length from a seed, which is a concatenation of a fixed 24 bits device generated Initial Vector (IV) and a user defined 40-bit or 104-bit shared key.

Security goal Confidentiality of the intranet: An intranet should be accessible to only authorized personnel and devices.

4.2 Problems

Undesirable

Outcome

Unauthorized access to the intranet: Unauthorized access to the intranet by a hostile agent could lead to other undesirable outcomes such as stolen sensitive information.

Threat Wireless WEP hacking

Keystream re-use: A hacker may eavesdrop shared key authentication sessions and recover the keystreams being used. With a sufficiently large library of keystreams, encrypted data using any re-used keystreams can be decrypted by the hacker.

Brute-force key trying: A hacker may try every key combination until the key is found.

Fragmentation attack: A hacker may use the knowledge of 802.11 fragmentation feature to transmit or decrypt information without the need to know the shared key [Bit06].

Weak IV attack: A hacker may eavesdrop and collect a large number of IVs used in a wireless network. If weak IVs are re-used in the network, they can be used to crack the encryption key [Flu01].

Replay attack: Based on the 802.11 protocol, the first 8 bytes of every packet is known, thus can be used to recover the first 8 bytes of the key. A hacker may recover an additional byte in the key by sending encrypted messages using the recovered key with different combinations for the extra byte. The packet with the correct key would be replayed by the Access Point to be detected by the hacker. This process can be repeated until the entire key is recovered. [Bit06]

Vulnerability Shared key authentication: Before a device may use a wireless network, the responsible Access Point (the wireless network controller) may optionally require the device to go through a shared key authentication process, a four-way challenge-response handshake testing whether the device has a correct shared key. The communication between the Access Point and the device exposes a pair of clear text and its corresponding encrypted text that can be eavesdropped by hostile agents.

Short key length: A key of 40 bits in length can be cracked by trying all combination in less than a month [Bit06].

Known characteristics of ARP packets: Address Resolution Protocol (ARP) is used by devices in an Internet Protocol (IP) network to look up a physical hardware

address from a logical network address. ARP data packets have a fixed length format, and a portion of the packets is transmitted in clear text even when WEP is used. Knowing these characteristics allows hackers to learn about and hack a wireless network.

Weak WEP encryption algorithm: WEP uses RC4 encryption algorithm that has flaws such that certain initial vectors (IVs) can reveal more information about the rest of key than others [Flu01].

4.3 Solutions

Threat

Prevention

Frequently rotating WEP key:

Manually rotating the key every quarter or every major personnel change: WEP keys should be changed or rotated every quarter or every major personnel change [PCI05 Requirement 4.1.1]. Without a rationale provided in the PCI DSS, this technique is assumed to possibly prevent attack from insiders who previously had knowledge of the key.

Positive Consequences

Help (+) cost: This is a procedural solution as no additional equipment is required, but may require time and resources.

Negative Consequences:

Hurt (-) administration needs: A system administrator needs to manually change or rotate the key.

Break (--) usability: User intervention may be required to reconfigure the wireless computers or devices whenever the key is changed.

Hurt (-) availability: During the key rotation, the wireless network is not available to the users until their wireless devices or computers have been updated with the new key.

Automatically rotating the key every few hours or less: Weak IV attack generally needs to eavesdrop over 1,000,000 packets to crack a key. Changing the key every few hours would make previously collected encrypted packets useless, thus, spoiling the attack before it could succeed. Since frequently changing key every few hours is impractical to perform manually, a number of products provide automated dynamic keys distribution [Won03].


Make (++) administration needs: Automated key rotations requires little or no human intervention by a system administrator.

Make (++) usability: User intervention is not required during the key rotation.


Hurt (-) cost: This solution requires a key distribution tool such as RADIUS that may incur additional cost.

Using WEP with more secure supplemental technologies: More secure encryption such as IPSEC, VPN, and SSL/TLS should be used in conjunction with the insecure WEP [PCI05 Requirement 4.1.1].


Make (++) administration needs: Once wireless computers or devices

have been configured, there is little need for administration.

Make (++) usability: User intervention is not required once the wireless computer and devices have been set up.


Break (--) cost: Assuming new wireless access points supporting WPA are needed, this mitigation would incur additional equipment costs.

Risk Transfer Using a more secure encryption: Encryption methods, such as WPA, WPA2, VPN, or SSL/TLS are harder to crack, therefore, should be used instead of WEP [PCI05 Requirement 4.1].


Make (++) usability: Connected network devices and computers do not require re-configuration once they have been set up to use the new encryption method.

Negative Consequences

Hurt (-) cost: New equipment that supports WPA or WPA2, or VPN software may be required.

Using at least 104-bit encryption key: A key of 104 bits is generally sufficient in preventing a brute-force attack as it would take millions of years to crack [Bru].


Make (++) cost: Most wireless access point equipment support 104-bit keys for WEP encryption.


None. No negative consequences to other NFRs of interest.

Restricting access by MAC addresses: Wireless access point should be configured to restrict access by the MAC addresses of authorized computers [PCI05 Requirement 4.1.1].


Make (++) cost: Most wireless access points support this technique, therefore, no additional equipment is required


Hurt (-) administration need: A network administrator needs to configure wireless access points whenever a device is added or removed from the network.

4.4 Mitigation Selection

4.4.1 Cost Driven Mitigation

Figure 4. Cost Driven Mitigation for Wireless WEP Hacking

Figure 4 depicts recommended solutions based on the alternatives in Figure 3 with an emphasis on cost (denoted by “!!Cost”). The recommendations are made at leaf-level solutions (solutions that are neither decomposed nor targets of a contribution link). For example, Manually [rotating key] every quarter is a leaf-level solution while Frequently rotate key is not. To mitigate the web hacking problem, its undesirable outcomes, threats, and/or vulnerabilities should be mitigated in order to satisfice1 the security objective.

For illustration purposes, area 1 in Figure 4 shows that Use WEP with VPN, or SSL/TLS solution is recommended (denoted by a Satisficed label or a check mark) over Use WPA, WPA2 because the former is less costly than the latter (denoted by a Hurt/- contribution vs. a Break/-- contribution toward Cost respectively). The Satisficed label on the solutions is evaluated to a Denied label for Weak WEP-encryption

algorithm problem over the Break/-- contribution between the two. The labels are subsequently evaluated and propagated through other contribution links and decompositions using the evaluation catalog presented in Appendix A. For example, in area 2, the Denied labels of both sub-problems are evaluated to a Denied label for Hack[WEP Encryption...] parent problem over the OR-decomposition, which also suggests that all sub-problems of an OR-decomposition must be all mitigated. Ultimately, Confidentiality [Intranet] and Cost are evaluated to be Weakly Satisficed, the best results based on the available alternatives.

Recommended mitigations:

• Manually [rotate key] every quarter or every major personnel change that hurts/- Insider attack,

• Use at least 104-bit encryption key that breaks/-- Short key length vulnerability,

• Do not use shared key authentication that breaks/-- Shared key authentication vulnerability,

• Use WEP with VPN, or SSL/TLS that breaks/-- Weak WEP encryption algorithm vulnerability.

1 Satisficing has an ancient origin (circa 1600), it is a Scottish variant of satisfy, referring to the notion of “good

enough” [Ste03]. It is adopted by the NFR Framework for noting the achievement of non-functional requirements (NFRs), which, for their subjective nature, are usually satisficed rather than satisfied in an absolute sense. [Chu00].

4.4.2 Usability Driven Mitigation

A

F

Figure 5. Usability Driven Mitigation for Wireless WEP Hacking

Figure 5 depicts recommended solutions with an emphasis on usability or friendliness of the solutions (denoted by “!!Usability”). For example, Frequently rotate key can be used to counter Insider attack by either rotating the key Manually every quarter or Automatically every few hours or automatically every few

hours, where the latter is recommended as it does not require user intervention, therefore is more friendly. Other solutions are recommended to counter other sub-problems of Hack [WEP Encryption…] threat so that ultimately, Confidentiality [Intranet] is evaluated to be Weakly Satisficed and Usability is Satisficed based on the available alternatives.

Recommended mitigation:

• Automatically [rotate key] every few hours or less that hurts/- Insider attack threat,

• Use WPA or WPA2 that breaks/-- Weak WEP encryption algorithm vulnerability,

• Use at least 104-bit encryption key that breaks/-- Short key length vulnerability,

• Do not use shared key authentication that breaks/-- Shared key authentication vulnerability.

4.5 References and Known Uses

[PCI05] PCI Data Security Standard version 1.1 [Bit06] A. Bittau, M. Handley, J. Lackey, “The final nail in WEP's coffin”, IEEE Symposium on Security and Privacy, 2006 [Vis09] A list of over 700 organizations that are using and in compliance with the PCI DSS

5 Remote Access Masquerading Mitigation Pattern

Figure 6. Remote Access Masquerading Mitigation Pattern

The Remote Access Masquerading (mitigation pattern) in Figure 6 is concerned with the confidentiality

of a corporate server (security goal) that can be compromised via remote login using ID and password (facility), by a hacker masquerading as a valid user using stolen ID and password, which can be

accomplished by illegally obtaining the ID and password and using them for login where the

information could be obtained via (1) social engineering, (2) intercepting, or (3) passwords guessing (threats) that exploit (1) some undesirable user behaviors, (2) interceptable IDs and passwords, and (3)

simple passwords being used (vulnerabilities), that could lead to unauthorized access to the server (undesirable outcome) that negatively affects the confidentiality of the corporate servers (security goal).

Undesirable user behaviors, interceptable IDs and passwords, and simple passwords being used (vulnerabilities) can be mitigated by securing IDs and passwords via (1) user education, training, and

enforcement, (2) encrypting stored and transmitted IDs and passwords, (3) using strong passwords that are frequently changed non-dictionary words (risk transfer measures) that change the facility to that with more acceptable risks. Alternatively, hacker masquerading as a valid user using stolen ID and

password (threat) may be prevented by using two-factor authentication that uses ID/password with

certificate/token based authentication or ID/password with biometrics based authentication

(preventive measures). In case that those mitigation techniques were unsuccessful, unauthorized access to

the server (undesirable outcome) can be recovered by resetting the compromised passwords (impact prevention or recovery) to limit the impacts on the unauthorized access (security goal). These mitigation solutions have positive and/or negative consequences upon cost and usability (NFRs).

5.1 Context

Asset Corporate server: A corporate computer server that has access to sensitive data.

Facility Remote login facilities: Computing facilities such as an intranet, the Internet, and an ID/password based login process allow remote users outside the corporate network to login to a corporate server.

Security goal Confidentiality of the server: Every corporate server should be accessible to only authorized personnel and devices.

5.2 Problems

Undesirable

Outcome

Unauthorized access to the server: A server that is accessible to a hostile agent that could lead to other undesirable outcomes.

Threat Masquerading as a valid user: A hostile agent may masquerade as an authorized user logging into a server by illegally obtaining an ID and a password, then login to the server using the stolen ID and password. ID and password may be illegally obtained by social engineering attack, interception, or passwords guessing.

Vulnerability Undesirable user behaviors: Certain user behaviors are undesirable; for instance, some users leave a note of their ID and password near the computer for convenience, or some users may be easily tricked into revealing their ID and password by social engineering attacks and phishing

Interceptable ID and password: IDs and passwords can be intercepted from a repository or during a transmission if they are stored or transmitted in clear text.

Simple passwords are easy to guess: Simple words that are easy to remember are also easy to guess, for example, using dictionary attacks.

5.3 Solutions

Undesirable

Outcome Recovery

Resetting compromised passwords: If an account is suspected to have been compromised, the owner may change the password, or the organization may reset the password to a new system generated password, or disable the account.


Make (++) cost: This solution should already be part of normal account maintenance capability.


Hurt (-) usability: Affected users would have to remember the new password or re-activate the account if disabled by this mitigation technique.

Threat

Prevention

Use two-factor authentication: Typical authentication requires a user to provide some forms of credentials, including what the user knows, what the user has, or what the user is, which generally requires the user to supply a password, a proof of possessing a security token, or a biometrics sample. Two-factor authentication requires the user to provide two out of three forms of credentials, which can be facilitated by technologies such as RADIUS [PCI05 Requirement 8.3].


Make (++) usability. Two-factor authentications using security token or

biometrics require the users to memorize little or no information.


Hurt (-) cost. Two-factor authentication using password with security token or biometrics authentication is more costly than one-factor password based authentication due to the cost of security tokens or collecting, maintaining, and verifying biometrics samples.

Risk Transfer Not available. It is unlikely that ID and password based authentication could be replaced since it is widely used, cost effective, universally supported by most computing platforms.



Figure 7. Cost Driven Mitigation for Remote Access Masquerading

Figure 7 depicts recommended mitigating solutions with an emphasis on cost of the solutions. Because Masquerade [Remote login using ID/password] is AND-decomposed to Illegally obtain ID, password and Login using stolen ID, password sub-problems, at least one of the sub-problems needs to be mitigated in order to mitigate the parent problem. In this case, only Illegally obtain ID, password sub-problem is mitigated since its corresponding solutions (i.e. Securing ID and passwords) are less costly than those of Login using stolen ID and password sub-problem (i.e. Two-factor authentication for remote access) as indicated by many positive contributions (Help/+) toward cost for the former and negative contributions (Hurt/- and Break/--) for the latter.


• Securing ID and passwords, which consists of: o Strong passwords (frequently changed non-dictionary words) that hurts/- Simple

passwords are easily guessed vulnerability, o User education, training, enforcement that hurts/- Undesirable user behaviors, and o ID/passwords encryption (stored and transmitted) that breaks/-- Interceptable ID and

password vulnerability

5.4.2 Usability Driven Mitigation

Figure 8. Usability Driven Mitigation for Remote Access Masquerading

Figure 8 depicts recommended solutions with an emphasis on usability of the solutions. For example, in area 1 in Figure 8, Password & Biometrics two-factor authentication for remote access is chosen over securing ID and passwords (), as the latter would require the users to memorize difficult to remember frequently changed non-dictionary passwords. Similar to the cost driven mitigation, countering only Login

using stolen ID, password (area 2) sub-problem is sufficient in preventing the Masquerade [Remote

login...] problem because of the AND-decomposition. Ultimately, Confidentiality [Corporate Server] is evaluated to be Weakly Satisficed and Usability is Satisficed.

Recommended Mitigation:

• Two-factor authentication using biometrics that breaks/-- Login using stolen ID, password threat


[PCI05] PCI Data Security Standard version 1.1 [Vis09] A list over 700 organizations that are using and in compliance with the PCI DSS

6 Malicious Transfer of Sensitive Data Mitigation Pattern

Figure 9. Malicious Transfer of Sensitive Data Mitigation Pattern

The Malicious Transfer of Sensitive Data (mitigation pattern) in Figure 9 is concerned with the confidentiality of sensitive data (security goal) that can be compromised via an internal host, intranet,

the Internet, an external host, and data transfer capability (facilities), by a malicious transfer of

sensitive data to an external host (threat) that exploits a system capability that a connection can be made to any external host (vulnerability), that could lead to stolen sensitive data (undesirable outcome) that negatively affects the confidentiality of the sensitive data (security goal).

The possibility that a connection can be made to any external (vulnerability) can be mitigated by building a firewall configuration to restrict connections that restricts outbound traffic to that is

necessary and from authorized applications to authorized IP in the demilitarized zone (DMZ), and

denies all outbound traffic that is not specially allowed (risk transfer measures). Alternatively, the malicious transfer of sensitive data (threat) can be contained by recovering the affected facility solution

that logs network activities, frequently monitors the facility, and isolates the affected facility when a

malicious transfer has been detected (containment measures). In case that all mitigation techniques were unsuccessful, stolen sensitive data (undesirable outcome) can be prevented from negatively affecting the confidentiality of sensitive data (security goal) by not storing complete data and/or storing the data in

a different form that is not useful for hostile agents (impact prevention and control). These mitigation solutions have positive and/or negative consequences upon cost and availability (NFRs).

6.1 Context

Asset Sensitive data: Sensitive data such as credit card information that needs to be protected.

Facility Internal host, Intranet, Internet, External host: Network connection that allows data transfer from intranet to a malicious network or host via the Internet.

Security goal Confidentiality of the sensitive data: Sensitive data should be accessible to only authorized personnel and devices.

6.2 Problems

Undesirable

Outcome

Stolen sensitive data: Sensitive data is obtained by a hostile agent.

Threat Malicious transfer of sensitive data to an external host: The threat is composed of two sub-problems: malicious transfer of sensitive data and malicious transfer to a malicious external host.

Vulnerability Connection can be made to any external host: A network connection can be made between any host on the intranet with any host on the Internet by default, allowing a connection to be created for a malicious intent.

6.3 Solutions

Impact

Prevention

Not storing complete data: certain pieces of important information should not be stored with the rest of the sensitive data, for example, card authentication code should not be stored [PCI05 Requirement 3.2] so that the rest of credit card information would not be useful to hackers if they are stolen.


Make (++) cost. No equipment and effort is required.


Break (--) availability. The missing pieces of data would not be available for other legitimate uses.

Storing data in a different form that is not useful to hostile agents: Information, such as driver license number, that is needed for authentication purposes may be stored in a different form without retaining the original form, for example, as one-way hashed values that can be used for the same purposes (e.g. authenticating customers), but would not be useful to hostile agents if stolen. If the original information needs to be retained, it may be stored in an encrypted form. The use of hashed values and encryption are recommended by the PCI DSS [PCI05 Requirement 3.4].


Make (++) cost. No additional equipment is required


Break (--) availability. The missing data would not be available for other legitimate purposes.

Threat Recovering the affected facility: Organizations should maintain an audit trail of network activities [PCI DSS Requirement 10.2], frequently monitor the facility

Containment [PCI DSS Requirement 10.6], and isolate the affected facility when a malicious transfer has been detected.


None, other than the indirect weakly satisficing of the confidentiality of sensitive data.


Break (--) availability of sensitive data: Sensitive data may not be accessible to or from the isolated facility.

Risk Transfer Build a firewall configuration to restrict connections: The risk of freely created connections can be mitigated by a network firewall configuration that restricts outbound network connections to those destinations that are necessary for the sensitive data environment, only from authorized applications to only IP addresses in the demilitarized zone (DMZ), and that denies all outbound traffic that is not specially allowed [PCI05 Requirement 1.3.5]


None, other than the indirect weakly satisficing of the confidentiality of sensitive data.


Hurt (-) availability. Unplanned legitimate network connections and data transfer of data would be restricted.

Hurt (-) cost. Additional equipment such as network firewalls to restrict connections and to provide a demilitarized zone (DMZ) are required.



Figure 10. Cost Driven Mitigation for Remote Access Masquerading

Figure 10 depicts recommended solutions with an emphasis on cost. In this case, Not store complete data prevents Stolen [Sensitive data] undesirable outcome from affecting Confidentiality [Sensitive data] without any associated cost. The prevention is represented by the denying of the Break/-- contribution between Stolen [Sensitive data] and Confidentiality [Sensitive data]. Since the contribution is denied, regardless whether Stolen [Sensitive data] problem is satisficed or not, Confidentiality [Sensitive data] cannot be denied. Therefore, there is no need to counter any problems.


• Not store complete data breaks/-- the break/-- the contribution between Stolen [Sensitive data] and Confidentiality [Sensitive data]

6.4.2 Availability Driven Mitigation

Figure 11. Availability Driven Mitigation for Remote Access Masquerading

Figure 11 depicts recommended solutions with an emphasis on the availability of the sensitive data. To mitigate Malicous transfer of sensitive data to a malicious external hosts, we need to mitigate one or more of its AND-decomposed sub-problems. However, it is difficult to prevent Malicious transfer of sensitive

data sub-problem as it is intentional in nature. We therefore mitigate the other sub-problem through the mitigation of its root cause of Connection can be made to any external host with Build firewall

configuration to restrict connections.


• Build a firewall configuration to restrict connections that breaks/-- Connection can be made to

any external host vulnerability. Specific firewall configuration includes: o Restricting outbound traffic to that which is necessary for the sensitive data environment, o Denying all outbound traffic not specifically allowed, and o Restricting outbound traffic from authorized applications to IP addresses within the DMZ


[PCI05] PCI Data Security Standard version 1.1 [Vis09] A list over 700 organizations that are using and in compliance with the PCI DSS

7 Related Work and Discussion Knowledge pattern was first introduced to capture solutions of recurring town and house building problems [Ale79], which was later adopted for software design [Gam95]. The use of pattern has later spread to other types of software knowledge including requirements [Fowler00] and architecture [Yod97], with many specializing in the area of software and system security [Yod97, Fer01, Che03, Sch03, Pri04, Sch06, Fer07b, Fer07, Pel09, Mou03, Oku08] for capturing knowledge of security mechanisms such as access controls at the analysis, architecture, and design levels, using object-oriented notations such as UML. Pattern is also used to capture security problems such as security misuses/attacks [Fer07, Pel09] to help understand how each problem could happen. Additionally, security patterns may also capture security solutions from the perspective of agents and their collaborations [Mou03, Oku08], or high-level domain and phenomena of security problems [Lin04]. Our approach provides a new perspective with a broad view at the strategic level to understand security problems, mitigating alternatives, and mitigation selection based on other organizational needs. Each mitigation pattern in this paper may seem to simply list a number of problems, solutions, and their relationships at high-level. However, this is necessary because strategic planning for security achievement, by nature, involve broad understanding of various aspects of the problems and different ways to mitigate them that often require trade-off to compromise many other potentially conflicting organizational needs. Once a desirable solution is chosen, deep understanding of the solution (or problem) can be provided by the traditional security patterns (or misuse/attack patterns) that describe a specific solution or problem in detail. Our use of security standards as the source of security patterns has previously discussed in [Sch02]. Our non-functional requirements driven approach for mitigation selection seems to reflect real-life practices where organizations do not always aim for maximum security. For example, despite being a highly secure authentication method, biometrics is generally not used by any e-commerce web sites, due to high cost, low usability, and privacy concern the potential customers may have in allowing the web sites to have possession of their biometrics samples. Therefore, NFRs serve as important criteria for mitigation selection. It is noted that NFR perspective consequences, although desirable, are difficult to evaluate [Fer09]; therefore, they are assigned qualitatively instead of quantitatively in our patterns. The NFRs driven selection has been introduced for design patterns and security patterns selection [Gro01, Wei08] as a general guideline, where specific selections are incorporated as parts of mitigation patterns in this paper. The patterns in this paper were modeled using the RE-Tools2 that supports Problem Frames [Jac00], the NFR Framework [Chu00], and the Problem Interdependency Graph [Sup09] notations used in the patterns. The NFR Framework was embraced by the i* Framework [Yu94], which in turn was adopted by Tropos [Bre04], a foundation for Secure Tropos [Gio07]. While developing the patterns, we found that fully understanding the problems and relating them to solutions were helpful in exploring alternative mitigating solutions. For example, in the Wireless WEP Hacking mitigation pattern, “shared key authentication” is identified as a vulnerability of the “keystream re-use” attack, a sub-problem of an OR-decomposition, which needs to be resolved in order to mitigate the “passive attack”. However, the PCI DSS does not seem to have a recommendation to address this vulnerability. This seems to illustrate that the goal-oriented capturing of problems and corresponding solutions could help improve the completeness of security standards.

8 Conclusion In this paper, we have presented security mitigation patterns that use goal-oriented techniques to capture and relate security context, problems, and alternative mitigating solutions with recommendations that based on different organizational goals such as non-functional requirements (NFRs). Three specific patterns have been presented using the TJX largest credit card theft in history as a case study.

2 www.utdallas.edu/~supakkul/tools/RE-Tools

Acknowledgement We thank our shepherd, Eduardo B. Fernandez, for his valuable and insightful comments that led to significant improvement of this paper.

References [Ale79] C. Alexander, “The timeless way of building”, Oxford Univ. Press, 1979 [Bit06] A. Bittau, M. Handley, J. Lackey, “The final nail in WEP's coffin”, IEEE Symposium on Security

and Privacy, 2006 [Bra07] T. Bradley, A. Chuvakin, A. Elberg, and B.J. Koerner, “PCI Compliance: Understand and

Implement Effective PCI Data Security Standard Compliance”, Syngress Publishing, 2007 [Bre04] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, and J. Mylopoulos, “Tropos: An agent-

oriented software development methodology”, Autonomous Agents and Multi-Agent Systems, 8(3), pp 203-236, Springer, 2004

[Bru] Wikipedia, “Brute force attack”, http://en.wikipedia.org/wiki/Brute_force_attack [Gau07] S. Gaudin, “Banks Hit T.J. Maxx Owner With Class-Action Lawsuit”, InformationWeek, Apr. 25,

2007 [Boe89] B. Boehm, “Tutorial: Software Risk Management”, IEEE Computer Society Press, 1989 [Can07] Office Of The Privacy Commissioner Of Canada And Office Of The Information And Privacy

Commissioner Of Alberta, Report of an Investigation into the Security, Collection and Retention of Personal Information of TJX Companies Inc. and Winners Merchant International L.P., Sep. 24, 2007

[Che03] B.H.C. Cheng, S. Konrad, L.A. Campbell, and R. Wassermann, “Using security patterns to model and analyze security requirements”, Int. Workshop on Requirements for High Assurance Systems (RHAS's03), pp 13-22, 2003

[Chu00] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, “Non-Functional Requirements in Software Engineering”, Kluwer Academic Publishers, 2000

[Fer01] E.B. Fernandez and R. Pan, “A pattern language for security models”, PLoP 2001 [Fer07] E.B. Fernandez, J.C. Pelaez, and M.M. Larrondo-Petrie, “Attack patterns: A new forensic and

design tool”, Procs. of the Third Annual IFIP WG 11.9 Int. Conf. on Digital Forensics, Orlando, FL, Jan. 29-31, 2007, Chapter 24 in Advances in Digital Forensics III, P. Craiger and S. Shenoi (Eds.), Springer/IFIP, 2007, 345-357.

[Feb07b] E.B. Fernandez, and X. Yuan, “Securing analysis patterns”, Proc. of the 45th annual southeast regional conference, pp 288-293, ACM New York, 2007

[Fer09] E.B. Fernandez, personal communication during the shepherding process of this paper, June, 2009 [FIS02] The Federal Information Security Management Act of 2002 (“FISMA”, 44 U.S.C. § 3541) [Flu01] S. Fluhrer, I. Mantin, and A. Shamir. Weaknesses in the Key Scheduling Algorithm of RC4.

Lecture Notes in Computer Science, 2259:1–24, 2001. [Fowler00] M. Fowler, “Analysis Patterns: reusable object models”, Addison-Wesley, 2000 [Jac00] M. Jackson, “Problem Frames: Analyzing and structuring software development problems”,

Addison-Wesley Longman Publishing, 2000 [Jon99] M. Johnston, “Known vulnerabilities are No. 1 hack exploit”, CNN, Dec. 17, 1999,

http://archives.cnn.com/1999/TECH/computing/12/17/hack.exploit.idg/index.html [Gam95] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, “Design patterns: elements of reusable object-

oriented software”, Addison-Wesley, 1995 [Gio07] Giorgini, P. and Mouratidis, H. and Zannone, N., “Modelling Security and Trust with Secure

Tropos”, Integrating Security and Software Engineering: Advances and Future Vision, chapter VIII, Idea Group, 2007

[Gro01] D. Gross and E. Yu, “From non-functional requirements to design through patterns”, Requirements Engineering, 6(1), pp. 18-36, Springer, 2001

[Hil07] S. Hilley (editor), Computer Fraud and Security, Elsevier, Apr. 2007 [Hil08] S. Hilley (editor), Computer Fraud and Security, Elsevier, Jan. 2008 [Lin04] Lin, L. and Nuseibeh, B. and Ince, D. and Jackson, M., “Using abuse frames to bound the scope of

security problems”, Proc. 12th IEEE Int'l Requirements Engineering Conf., pp 354-355, 2004

[Mou03] Mouratidis, H. and Giorgini, P. and Schumacher, M. and Manson, M., “Security patterns for agent systems”, Proc. 8th European Conference on Pattern Languages of Programs (EuroPLoP), Irsee, Germany, 2003

[Oku08] T. Okubo and H. Tanaka, “Identifying Security Aspects in Early Development Stages”, Proc. Third Int'l Conf. on Availability, Reliability and Security, 2008 (ARES 08), pp 1148-1155, 2008

[PCI05] Payment Card Industry, “Data Security Standard v 1.1”, 2005 [Pel09] J. Pelaez, E.B.Fernandez, and M.M. Larrondo-Petrie, “Misuse patterns in VoIP”, accepted for

Wiley's Security and Communication Networks Journal, 2009 [Per07] J. Pereira, “Breaking The Code: How Credit-Card Data Went Out Wireless Door”, The Wall

Street Journal, May 4, 2007 [Pri04] T. Priebe, E.B. Fernandez, and J.I. Mehlau, and G. Pernul, “A pattern system for access control”,

Research Directions In Data And Applications Security XVIII: IFIP TC 11/WG 11.3 18th Conference On Data And Applications Security, July 25-28, 2004, Sitges, Catalonia, Spain

[Sch02] Schumacher, M., “Security patterns and security standards”, Proc. 7th European Conference on Pattern Languages of Programs (EuroPLoP), July, 2002

[Sch06] M. Schumacher, E. Fernandez, D. Hybertson, and F. Buschmann, “Security Patterns: Integrating security and systems engineering”, John Wiley & Sons, 2006

[Sch03] Schumacher, M., “Security engineering with patterns: origins, theoretical models, and new applications”, Springer, 2003

[Ste03] W. Sterling, “Satisficing Games and Decision Making: With Applications in Engineering and Computer Science”, Cambridge University Press, 2003

[Sup09] S. Supakkul and L. Chung, “Extending Problem Frames to Deal with Stakeholder Problems: An Agent- and Goal-Oriented Approach”, Proc. the 24th ACM Symposium on Applied Computing (RE Track), March 9-12, 2009, Honolulu, pp. 389-394

[Tip05] H.F. Tipton, M. Krause, eds., “Information Security Management Handbook”, 5th Ed., CRC Press, Boca Raton, 2005

[US08] United States of America v. Albert Gonzalez, United States District Court District of Massachusetts, 18 U.S.C. § 371, Aug. 5, 2008

[Vis09] Visa Inc, “Global List of PCI DSS Validated Service Providers”, http://usa.visa.com/download/merchants/cisp-list-of-pcidss-compliant-service-

providers.pdf [Wei08] M. Weiss and H. Mouratidis, “Selecting Security Patterns that Fulfill Security Requirements”,

Proc. 16th IEEE Intl. Requirements Engineering, 2008 (RE'08) [Wir06] R. Wirfs-Brock, P. Taylor, and J. Noble, “Problem Frame Patterns”, PLoP 2006 [Won03] S. Wong, “The evolution of wireless security in 802.11 networks: WEP, WPA and 802.11

standards”, http://www.sans.org/reading_room/papers/68/1109.pdf [Yod97] J. Yoder and J. Barcalow, “Architectural Patterns for Enabling Application Security”, PLoP, 1997 [Yu94] Yu, E.S.K. and Mylopoulos, J., “Understanding “why” in software process modelling, analysis,

and design”, Proc. of the 16th int'l conference on Software engineering, pp 159-168, 1994

Appendix A. A Label Evaluation Catalog Figure 12 depicts a catalog of label evaluations for goals and problems that describes how to evaluate satisficing labels upward the goal and problem graph shown in this paper. Although these evaluations are depicted by softgoal icons, they are applicable for evaluating both goals and problems.

Figure 12. A Goal/Problem Label Evaluation Catalog

plop09--security threat mitigation patterns v22supakkul/papers/supakkul--security threat...

Documents