A Systematic Method to Understand Security Risks in a Retail Environment

Transcription

1 A Systematic Method to Understand Security Risks in a Retail Environment Version 1.03 Final Prepared by Michael Howard, Senior Principal Cybersecurity Architect Mark Simos, Cybersecurity Architect Sean Finnegan, Cybersecurity Director Vic Miles, Retail Technology Strategy 1

2 Table of Contents 1 Introduction The Process A Logical Retail Model External Entities Processes Data Stores Data Flows Infrastructure Control Domains Administrative Configuration and Management Administrative Operations and Practices Next Steps Conclusion Appendix A A Brief Overview of Threat Modeling and STRIDE Streamlining STRIDE for Processes Further Threat Modeling Reading (c)2013 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. 2

3 1 Introduction All computer systems are subject to attack by malicious insiders and external entities. In some cases the damage caused by an attack might be insignificant, or in other cases incredibly high. The damage depends on the skills and motivations of the attackers and the value of the assets they compromise. Retail systems, like many other vertical industry systems, secure assets that are incredibly sensitive, and if breached can lead to loss of assets, loss of brand reputation, loss of customer trust, and potentially legal action. Many of our clients have asked the Microsoft Cybersecurity team to help them define a way to systematically assess the strength of their enterprise systems. Cybersecurity professionals agree that an effective review of the security posture of an enterprise must consider the entire operating environment, regardless of operating systems and deployment scenarios; and that is the goal of this whitepaper. In writing this paper, we used a combination of skills including enterprise systems security expertise and retail domain expertise. By combining the two domains, we have defined a process called Retail Threat Modeling that takes a logical view of a retail environment and maps that onto a security discipline referred to as threat modeling. This paper includes appendices that explain some topics in more detail. The goal of this paper is to help our retail clients understand how they can determine the inherent risk in their systems, and to make sure appropriate defenses are in place. Note The word systematically is important. Analysis of systems for security issues must be complete and structured. Unfortunately, much of the security analysis process performed today is ad-hoc and non-deterministic. The process proposed in this paper is systematic, deterministic and structured. Page 3

4 2 The Process The process involves taking a logical view of a retail system and then applying the threat modeling process to each of the elements in the logical diagram. The Microsoft Security Development Lifecycle 1 threat modeling process will systematically derive a list of threats to the system and from that exploration a list of appropriate mitigations and defenses can be determined. For each area of the logical model we will include known attacks and best practices. Additionally we will provide a perspective from the point of view of a cybersecurity professional who has performed the threat modeling process with many enterprise clients. If the reader is not familiar with the threat modeling process, we would recommend a review of Appendix A A Brief Overview of Threat Modeling and STRIDE. For best results evaluating a retail system, it is useful to have retail and cybersecurity subject matter experts working together on the analysis. 3 A Logical Retail Model Below is a logical model of a typical retail system, we want to caveat this with the recognition that the retail model is dynamic among retailers and their suppliers. If an environment differs widely from this model, then a new model would be built and the threat model would be built against the updated model. The logical model must contain entities for all information that is sensitive, such as any shopper personally identifiable information (PII). The process begins with an accurate system diagram. 1 Page 4

5 Figure A Logical Retail System model The threat modeling process requires that we take each of these elements in the diagram, and apply the STRIDE mnemonic, then we will consider the mitigations and industry best practices. First, we start with the external entities (rectangles) and determine the threats that apply to each. 3.1 External Entities External entities are subject to spoofing and repudiation; but generally speaking repudiating an external entities transactions are an issue with the rest of the system, most notably the processes that track ordering data and such, so we will focus on spoofing. Element STRIDE Questions to Consider Suppliers S How are suppliers authenticated? How is their privilege controlled and authorized. Where and how are their credentials issued, stored, protected and revoked? This applies to all suppliers beyond the core IT infrastructure. Corporate Employees S How are corporate employees authenticated by whatever processes they communicate with? How is their privilege controlled and authorized. Where and how are their credentials issued, stored, protected and revoked? Page 5

6 Store Employees S How are store employees authenticated by whatever processes they communicate with? How is their privilege controlled and authorized. Where and how are their credentials issued, stored, protected and revoked? Sales & Mktg S How are sales and marketing people authenticated? How is their privilege controlled and authorized. Customers S How are customers authenticated in-store and on the web? Admins S How are admins authenticated? How is their privilege controlled and authorized. Payment Processor S How do the internal systems know they are communicating with the correct payment processor? What authentication scheme is used and how is it enforced? Issuing Bank S How does the payment processor know it is communicating with the correct issuing bank? What authentication scheme is used and enforced? Threat Modeler s Perspective: Least Privilege The single most important defense in any system, including Windows, is to operate the system with the lowest possible privilege. For example, staff at the point of sale should never run their system with administrative privileges. In Windows, there are some privileges that can be granted to accounts that are a small step away from being a full-fledged administrator. The following privileges should be granted only to highly trusted users: Allow log on as a service, Access this computer from the network, Allow logon through Remote Desktop Services, Act as part of the operating system, Backup files and directories, Restore files and directories. Similarly in Active Directory, membership in groups such as Domain Admins and Enterprise Admins should be restricted to a very small number of accounts requiring that privilege. We cannot stress enough how important it is to operate a least privilege environment. If an attacker can gain administrative rights on a system, he can access highly sensitive data such as passwords and account information and use that as a beachhead into the rest of the organization. This is especially true if accounts are shared across multiple devices through account traversal attacks (explained later.) 3.2 Processes Next we look at processes, these are quite complex as they have all the STRIDE threats; however, in practice, it is possible to group the threats as S, TRID and E, because many of the mitigations for all the TRID threats are similar (access control.) Element STRIDE Questions to Consider Page 6

7 POS S How does a user of the system know it s a valid system? What authentication scheme is used? If any. TRID E How does a user of the system know the system has not been tampered with? For example, a rogue set of software or a card skimmer? How do admins verify the system is correct? Same applies to the POS underlying operating system. What kind of malware detection is in use? Does the system execute with the least amount of privilege to perform its routine tasks? Also, is the account used on the POS used elsewhere in the system? See sidebar below about shared accounts. Web Site S How does a user know the site is the correct site and not a rogue? DNS cannot be relied upon, SSL/TLS is usually the correct response. Where are the SSL/TLS keys stored? Sales & Inventory system ERP/Internal Systems TRI D E S TRID E S TRID E How do admins know the site is correct and has not been tampered with? See the Data Store: Web pages and logic for further detail. How are denial of service attacks addressed? Does the web server code run with lowest privilege and is all access to all database assets performed at lowest privilege also? Also, is the account used on the POS used elsewhere in the system? How do users authenticate the sales & inventory system is the correct host? How does a user of the system know the system has not been tampered with? How do admins verify the system is correct and the operating system is correct? What kind of malware detection is in use? Does the system execute with the lowest possible privilege? Also, is the account used on the POS used elsewhere in the system? How do systems that depend on this process know they are communicating the correct system? What authentication schemes are used? How does a user of the system know the system has not been tampered with? How do admins verify the system is correct and the operating system is correct? What kind of malware detection is in use? Does the system execute with the lowest possible privilege? Also, is the account used on the POS used elsewhere in the system? Page 7

8 Card Reader S Is there a mechanism to verify the authenticity of the card reader? When the POS talks to said reader, what authentication mechanism is used? TRID E How is the card reader protected from tampering? Is there a way to determine if the reader is running the correct operating code? Does the code on the reader execute with lowest possible privilege? Also, is the account used on the POS used elsewhere in the system? Threat Modeler s Perspective: Malware The fact that malware can exist on a system is a tampering threat to the underlying system, and the way tampering threats are mitigated is with integrity controls: once a system s integrity is about to be compromised, then some system, for example anti-malware or application whitelisting comes into play. There are multiple 3rd party whitelisting solutions as well as the Microsoft AppLocker or Software Restriction Policies that are built in to Windows. While it will likely require some testing to verify it does not impact the operations of the POS device a whitelisting solution should restrict the device to just running the desired Point of Sale application. Account Lateral Traversal Attackers may choose to attack one or more devices (including POS) over the network using exploits or even using a physical attack on a device in a store 2. However, it is difficult to compromise hundreds or thousands of devices using these methods and in many attacks it is common that attackers leverage some sort of lateral traversal using stolen (information disclosure threat) but legitimate privileged credentials to compromise a large number of devices. Microsoft has extensive experience in countering these types of attacks as they are often used by Determined Adversaries 3 to quickly gain access to information from across the enterprise after compromising a small number of systems. Microsoft has previously published general guidance on countering these threats in the white paper Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques. 4 Shared Accounts It is common in enterprise systems to use accounts that are shared between multiple endpoints. This can make the system easier to manage, but it also can create a potential risk to the system that administrators must be aware of. The three common types of shared accounts are: (a) Shared Service Accounts, (b) Shared Administrator Accounts and (c) Shared User Accounts. Organizations must audit their environments and list all accounts that are used and where the accounts are used. 2 The discussion of protection against physical attacks on POS devices is out of scope for this paper Page 8

9 3.3 Data Stores Next we look at the where the data is stored; as a general rule, the two most important threats are information disclosure (i.e.; getting a customer list or credit card list) and tampering (i.e.; changing a web site s pages.) Element STRIDE Questions to Consider Web pages & logic T I When developers push new web application changes, how do you know they are correct and always correct until the next update is performed? What are the permissions on the assets? Is there any sensitive data in the web site assets (pages and application logic) such as encryption keys and passwords? What are the permissions on the assets? Customer data T How do you know the data is correct and has only been updated by valid personnel or systems? What are the auditing policies and technologies used? Sales & Inventory Data I T I Is there any personal or sensitive data? If yes, then this raises the risk substantially. How is the data protected from disclosure? How do you know the data is correct and has only been updated by valid personnel or systems? What are the auditing policies and technologies used? Is there any personal or sensitive data? If yes, then this raises the risk substantially. How is the data protected from disclosure? Loyalty T How do you know the data is correct and has only been updated by valid personnel or systems? Account Received I T I Is there any personal or sensitive data? If yes, then this raises the risk substantially. How is the data protected from disclosure How do you know the data is correct and has only been updated by valid personnel or systems? What are the auditing policies and technologies used? Is there any personal or sensitive data? If yes, then this raises the risk substantially. How is the data protected from disclosure Credit Card Info T How do you know the data is correct and has only been updated by valid personnel or systems? Page 9

10 I Clearly, this is personal or sensitive data and must be protected at all costs. The minimum bar should comply with PCI requirements. Threat Modeler s Perspective: Protecting Sensitive Data It is difficult to protect sensitive data on a device where the attacker has complete control of the operating system. However, dedicated hardware devices that never expose unencrypted data to the terminal can provide a safeguard provided that the encryption key is never shared with the terminal. Through the use of encrypting card reader hardware or cards that have a built in cryptographic processor the card data can be encrypted so that it is inaccessible to attacker malware running on the POS device. This assumes that no customer PII is visible to the terminal either in the initial card swipe, or in the authorization data returned to the POS terminal from the payment system. In addition, many retailers have separate loyalty programs that may contain customer PII although typically not credit card data. While this may be of less interest to an attacker this data still could be stolen by malware on the POS device and as a result just encrypting the credit card data at the swipe is not a panacea to preventing the theft of customer PII. 3.4 Data Flows Data flows are how data moves throughout a system, often over networking interfaces. Most non-trivial systems have an explosion of data flows, and each one must be evaluated. Like datastores, the core threats are tampering and information disclosure, but in the interests of brevity, we will treat both together as most mitigations will be available from the networking protocol in use. Also in the interests of brevity, we will only describe a subset of the data flows. One security best practice is to require SSL/TLS or IPsec throughout the system. SSL/TLS would require that all communication end-points understand SSL/TLS, but IPsec could be deployed as networking policy. Not only do these protocols provide channel encryption and tamper detection, but they can also provide end-point authentication. Element STRIDE Questions to Consider Credit Card Reads POS Admin Web site TI TI Is the credit card information protected from disclosure or tampering as it moves to/from the POS and reader? In some cases, the card reader might perform the encryption and tamper detection so the channel need not necessarily be encrypted. What networking protocol is used when admins communicate with the web site? Does it provide T & I defenses? Is there any sensitive data that might go across the wire? Page 10

11 Customers Web site Web site web pages & logic TI TI What networking protocol is used when users communicate with the web site? Does it provide T & I defenses? Is there any sensitive data that might go across the wire? This is file I/O and low risk. If the attacker has inserted themselves into this data flow, they are already on the box. Admin POS TI What networking protocol is used when admins communicate with the POS? Does it provide T & I defenses? Is there any sensitive data that might go across the wire? Credit Card Info Sales & Inventory System Other data flows TI What networking protocol is used between the credit card database and the sales and inventory system? As this data is sensitive, there must be viable mitigations against disclosure and tampering in place. 4 Infrastructure Control Domains In addition to the architecture of the system itself assessed by the threat model, retail organizations must also consider the configuration, operation, and management of the infrastructure hosting the system. Attackers have exploited these configurations actively in many industries, including retail. Attackers exploiting these underlying management layer of a system can typically span all forms of the STRIDE model by controlling the data stores, processes, and entities on these hosts. 4.1 Administrative Configuration and Management Management systems have control over hosts and the applications running on them, enabling them to alter the function of the systems under their control. This allows an attacker in control of the management tools to circumvent or disable security architecture and controls. For example configuration management agents on hosts can run arbitrary code, with SYSTEM level access. This is required on all types of operating systems to provide centralized management. As such any host joined to a domain is subject to scripts, configuration changes, and policies that could result in full control of the host. This is why it is important to consider the entire system during the threat modeling process. The typical span of control can be very large. From a security perspective it is necessary to limit the scope of this control by segmenting the operating environment from highly sensitive areas. Because adding segmentation can cause a level of Page 11

12 additional systems management overhead, a balance must be found between administrative effectiveness and efficiency vs. the security benefits from the containment effect. In a retail organization, this may resemble a diagram similar to the following: Figure Management of a Logical Retail System model Page 12

13 4.2 Administrative Operations and Practices In addition to the static architecture and static configuration of management tools, the use of credentials in control of the retail systems as well as the management tools controlling them can create a vector for controlling the system through credential theft. Attackers that steal administrative credentials from a host where they are used (such as an administrator s desktop computer) can abuse the privileges associated with that account, throughout the scope of that accounts control. The diagram below illustrates this and indicates the need to limit the scope of control for a single credential. Figure Credential theft vectors for attacking a Logical Retail System Page 13

14 5 Next Steps Microsoft recommends, as an initial action, that all retail enterprises build a threat model to fully understand the risks across the entire infrastructure. This full system view will involve engineers and administrators of all systems, not just Microsoft based systems. To do this, use Figure 1 as a starting point and create a model for the specific retail environment. Next, apply the STRIDE mnemonic to all the elements in the diagram as described in Appendix A A Brief Overview of Threat Modeling and STRIDE on page 15. For each of the STRIDE threat types, determine what is used to mitigate the threat. For example, if there s an Information Disclosure threat against credit card information held in a database, how is that data protected? Generally, the protections are access control and permissions, and encryption. Are any of these employed? If no, why not? And if yes, are the defenses correct or at the very least, adequate? Finally, Microsoft recommends that all retail organizations evaluate the configuration and operation of Active Directory and endpoint management tools used to manage and monitor the production environment. Admittedly, if the company is new to the threat modelling process or security analysis of infrastructure management, some help will be required from people familiar with these processes. 6 Conclusion The process of threat modeling is a valuable tool to help businesses in the retail sector holistically understand the security and privacy implications of their systems. Threat modeling uses a high-level solution diagram with various threat categories (STRIDE) applied to it to determine how an attacker can attack a system, and from there, mitigations can be determined. If there is a missing mitigation, then the risk can be determined, or a mitigation sought. The core point of threat modeling is to understand which threats are mitigated, and which are not to help understand what further action, if any, is needed to make the system secure from todays sophisticated attackers. Page 14

15 Appendix A A Brief Overview of Threat Modeling and STRIDE Threat modeling helps systems designers uncover potential insecure design issues in a system. The process of building a threat model is straightforward, and involves identifying the core elements of the system such as the processes, the data storage systems, how the data flows through the system and the external entities that interact with the system. Once this is known, the list of potential threats is automatically determined using the STRIDE mnemonic. The elements of STRIDE are: S Spoofing. The ability to pose as someone or something else. T Tampering. The unauthorized ability to change something. R Repudiation. The ability to disavow a transaction. I Information Disclosure. The unauthorized ability to view something. D Denial of service. The ability to degrade service. E Elevation of privilege. The ability to elevate capabilities. Think of STRIDE as CIA (Confidentiality, Integrity and Availability) but more fine-grained, and from an attacker s viewpoint. Elements in the system diagram are subject to various STRIDE categories. For example a data flow between two processes (think: web browser to web server, or web server to database server) is subject to T, I & D. The next step is to determine which of these threats are a real risk. For example, do you care if an attacker can view (Information Disclosure) the data on the wire that flows from the web server to the web browser? If the answer is Yes then that threat must be mitigated, and the way I threats are mitigated is with confidentiality techniques such as access control policies or encryption. At this point, the appropriate mitigation is selected. This often requires using defenses and mitigations specified in the enterprise architecture. Element Type Data at Rest Data on the Wire Process External Entities (items that influence your system, but you do not control) STRIDE Applicability TID (potentially R if data is an audit log) TID STRIDE SRD Page 15

16 This process continues until all STRIDE elements for each application diagram element are addressed. Addressing the threats depends on the threat type. For example, Spoofing threats are mitigated with the logical process of authentication. The type of authentication varies by the element being authenticated. For example, users and computers could be authenticated using: IPSec SSH Kerberos SSL/TLS Basic authentication Digest authentication NTLM authentication Forms-based authentication OAuth But code and data would be authenticated using: Message authentication codes Digital signatures The following table is a list of threat types mapped to mitigation techniques and some examples technologies. STRIDE Element Mitigation Technique(s) Sample Technologies Spoofing Authentication SSL/TLS, Kerberos, Shared secret Tampering Integrity Permissions (operating system and firewall), cryptographic techniques (hashing, digital signatures and message authentication codes) Repudiation (most are T threats) Information Disclosure Non-Repudiation Confidentiality Strong authentication, authorization and tamper detection. Trusted third-parties. Permissions (operating system and firewall), encryption. Denial of Service Availability Load balancing, throttling, firewall ACLs Elevation of Privilege Least Privilege and Authorization Permissions and running systems with non-admin accounts. Page 16

17 Streamlining STRIDE for Processes When evaluating all threats that relate to processes all STRIDE it s possible to compress the amount of work required by focusing on S, TRID and E as three distinct groups, asking the following questions: Spoofing how is the process authenticated? Elevation does the process run with the least possible privilege? TRID what are the permissions on the process while on disc and how do you know the process is the correct process and not a rogue (ie; malware)? Further Threat Modeling Reading Howard, M. & Lipner, S., The Microsoft Security Development Lifecycle, Microsoft Press 2006 Shostack, A. Threat Modeling: Designing for Security, Wiley 2014 Page 17