a systematic method to understand security risks in a...

1

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

A Systematic Method to

Understand Security Risks in

a Retail Environment

2

Table of Contents

1 Introduction ............................................................................................................................................ 3

2 The Process ............................................................................................................................................. 4

3 A Logical Retail Model ........................................................................................................................ 4

3.1 External Entities ............................................................................................................................. 5

3.2 Processes ....................................................................................................................................... 6

3.3 Data Stores .................................................................................................................................... 9

3.4 Data Flows ................................................................................................................................... 10

4 Infrastructure Control Domains ..................................................................................................... 11

4.1 Administrative Configuration and Management ......................................................................... 11

4.2 Administrative Operations and Practices ..................................................................................... 13

5 Next Steps ............................................................................................................................................. 14

6 Conclusion ............................................................................................................................................. 14

Appendix A – A Brief Overview of Threat Modeling and STRIDE .............................................. 15

Streamlining STRIDE for Processes .......................................................................................................... 17

Further Threat Modeling Reading ........................................................................................................... 17

(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.

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.

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 Lifecycle1 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 www.microsoft.com/sdl

http://www.microsoft.com/sdl

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?

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.)


POS S How does a user of the system know it’s a valid system? What

authentication scheme is used? If any.

TRID 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?

E 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?

TRI 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.

D How are denial of service attacks addressed?

E 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?

Sales &

Inventory

system

S How do users authenticate the sales & inventory system is the correct

host?


with? How do admins verify the system is correct and the operating

system is correct? What kind of malware detection is in use?

E Does the system execute with the lowest possible privilege? Also, is the

account used on the POS used elsewhere in the system?

ERP/Internal

Systems

S How do systems that depend on this process know they are

communicating the correct system? What authentication schemes are

used?


with? How do admins verify the system is correct and the operating

system is correct? What kind of malware detection is in use?

E Does the system execute with the lowest possible privilege? Also, is the

account used on the POS used elsewhere in the system?

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 How is the card reader protected from tampering? Is there a way to

determine if the reader is running the correct operating code?

E Does the code on the reader execute with lowest possible privilege? Also,

is the account used on the POS used elsewhere in the system?


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 store2. 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 Adversaries3 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 end-

points. 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.

3 http://www.microsoft.com/en-us/download/details.aspx?id=34793

4 http://www.microsoft.com/en-us/download/details.aspx?id=36036

http://www.microsoft.com/en-us/download/details.aspx?id=34793

http://www.microsoft.com/en-us/download/details.aspx?id=36036

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.)


Web pages &

logic

T 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?

I 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?

I Is there any personal or sensitive data? If yes, then this raises the risk

substantially. How is the data protected from disclosure?

Sales &

Inventory Data

T How do you know the data is correct and has only been updated by valid


used?


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?


substantially. How is the data protected from disclosure

Account

Received

T How do you know the data is correct and has only been updated by valid


used?


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?

I Clearly, this is personal or sensitive data and must be protected at all

costs. The minimum bar should comply with PCI requirements.


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 data-

stores, 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.


Credit Card Reads

POS

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.

Admin Web

site

TI 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?

Customers

Web site

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?

Web site

web pages &

logic

TI 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

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.

Other data flows

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

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

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

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.

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 STRIDE Applicability

Data at Rest TID (potentially R if data is an audit log)

Data on the Wire TID

Process STRIDE

External Entities (items that influence your system,

but you do not control)

SRD

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)

Non-Repudiation Strong authentication, authorization and tamper

detection. Trusted third-parties.

Information

Disclosure

Confidentiality 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.

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

a systematic method to understand security risks in a...

Documents