The good, the bad and the ugly of protecting data in a retail environment--Part 1.

The overall purpose of information security is to control risk by managing the impact of threats to information assets in the most cost-effective manner. This article takes a look at a typical point-of-sale (POS) solution, identifying common architectural weaknesses that can lead to data compromise. Specifically, key business priorities are assessed against the POS architecture to vet the solution for potential security shortcomings that could prevent it from carrying out its business mission.

In many retail organisations, the principal business objectives are to achieve compliance to the Payment Card Industry Data Security Standard (PCI DSS) to avoid fines and maintain proper standing in the industry, while protecting the brand name by avoiding breaches of customer credit card data. Many retail solutions have been carefully designed from both security and business goal perspectives. They may use hardening features such as PKI-driven strong mutual authentication of all system components, rigorous encryption of data in transit and at rest, secure unlock and update processes, etc. All represent best practices in the credit card processing industry today.

A retail system must be designed "from the ground up" to be able to operate safely and reliably in the most hostile of networking environments. Some mature security solutions are also environmentally friendly and address "the green security challenge" by delivering software solutions that operate on existing computing infrastructure. Typically they are on the same server as the application or database being secured. The appropriate level of encryption key protection can be achieved by using a well balanced combination of software cryptography and selective use of small footprint standard commodity type Hardware Security Modules (HSMs). This approach can provide the necessary level of protection while balancing security, cost and operational needs.

A computer containing encryption keys and sensitive data that is physically stolen from a retail site represents an example of a significant risk. Careful balance between business goals and security reduces the risk of a compromise that can threaten the retail organisation's brand reputation and business operations. Compliance to PCI is not enough to safeguard information in a retail environment.

This article will also assist in guiding security efforts in a POS environment. For example, weaknesses discussed here can prove to be effective at prioritising testing attention and effort. In other words, the testing, design review, code review, penetration testing, etc., processes should be prioritised in order to make the most effective use of the available development resources.

The Payment Card Industry Data Security Standard The PCI DSS was created by major credit card companies to safeguard customer information. Visa, MasterCard, American Express, and other credit card associations mandate that merchants and service providers meet certain minimum standards of security when storing, processing and transmitting cardholder data. Level 1 merchants, (those who process over 6m annual card transactions or merchants whose data has previously been compromised) service providers and banks are required to perform an annual assessment including penetration testing and application testing. All credit card processing systems require logging of all access to credit card data, in addition to quarterly scans and annual penetration tests.

Credit card transmission networks, processing and storage systems require host and/or network intrusion detection or prevention. Firewalls providing access to credit card processing and storage systems require an appropriately configured and managed firewall. Remote access to credit card processing environments require two-factor authentication. Databases, web servers and applications that store or process credit card data require 128-bit SSL encryption and effective management of crypto key transmission and storage.

Although currently not a PCI requirement, Visa and MasterCard encourage application development companies to certify their payment applications in accordance with the PCI Payment Application Best Practices programme. Applications that meet these standards can be listed on the Visa Web site as PCI-approved payment applications.

Reviewing the state of security

Data flows through a retail system, into and out of numerous applications and data stores. This flow, in its entirety, is the focus of a holistic approach to data security.

A critical first step in any data-driven security review is to identify all the points and places where sensitive data is processed, transmitted and stored. The plan should address such issues as data retention and disposal, user access, encryption and auditing.

You must take into consideration that business needs will often trump security requirements, and an effective security plan must take all of the stakeholders' needs into account, or it will fail. People will always find a way to thwart security measures they don't understand or have a negative impact on their productivity. For each specific POS system significant amounts of data should be collected, synthesised, and analysed in order to draw specific conclusions beyond those presented in this article.

1) The process should begin with the collection of all available design and architectural artefacts--diagrams, architecture documentation, etc.

2) The POS team should facilitate an architecture review meeting. During this meeting, a typical POS architecture should be described in detail, including various user stories that explain how the POS system is operated under different circumstances.

3) Then analyse the artefacts and meeting notes in order to synthesise the information and gain a thorough understanding of how the deployed POS will function. This should include a thorough reading of the design and architecture artefacts.

4) Perform the actual risk analysis, consisting of one or more of the risk analysis touch-point methodology sub-processes: i) attack resistance, ii) ambiguity analysis, and iii) weakness analysis.

For attack resistance analysis, the primary application components--and third party infrastructure components--must be analysed for known and published vulnerabilities, patches, etc. Ambiguity analysis should consist of comparing the POS design documentation against discussions from a review kick-off meeting.

5) Lastly, and most significantly, the architecture itself should be analysed for potential weak points and weak operational modes.

For more information for merchants, including the current transaction volumes/categories for each level, see http://usa.visa.com/business/accepting_visa/ops_risk_ management/cisp_merchants.html?it=il|/business/accepting_ visa/ops_risk_management/cisp.html|Merchants.

For the full text of the Data Security Standard, see http://usa.visa.com/business/accepting_visa/ops_risk_ management/cisp_merchants.html.

To review the standards for the PCI Payment Application Best Practices programme, see http://usa.visa.com/business/accepting_visa/ops_risk management/cisp_payment_applications.html

Typical threats

Any substantive analysis and discussion about an application's risks must include a discussion of the likely threats the application will face during its anticipated deployed life. In the analysis of the POS, the most likely threats that the system may face, for reasons we will describe below, are 1) malicious insiders and 2) technically knowledgeable outsiders motivated by profit. A brief discussion of each, along with the respective rationale, follows below.

Basic assumptions

Due to the rigorous security design that usually goes into a typical POS architecture, the bar is set quite high with regards to the difficulty that an attacker should have in order to compromise the system. Even an opportunistic attacker who manages to break one of the system's infrastructure components should still need to go to great lengths to compromise any of the system's true "crown jewels", e.g. a Local Security Service (LSS) unlock key, the actual POS keystore, or (untokenised) valid credit card data. As a result, it is assumed that a successful adversary should need to possess a significant level of technology expertise.

As a goal any attacker should be more than just proficient in numerous technologies that for example could include C, Java, UNIX/Linux, TCP/IP networking, etc. Additionally, the attacker should need to have a significant understanding of the functional and design aspects of the POS itself. This could be achieved through reverse engineering or analysing the source code, design documentation, etc. While many hack attacks are crimes of opportunity, targeting systems with easy to exploit flaws, it must be assumed that a sufficiently motivated attacker will be able to acquire (or hire) the technology expertise, as well as the application-specific knowledge to attempt an attack, on a more resilient target.

Common insider threats

There is likely to be one primary category of insider threat to the POS: retail employees. They may either be enlisted by an outsider(s) or may enlist the help of an outsider in order to attack the POS.

Their motivations are likely to be either profit or to cause harm to the retailer by a direct denial of revenue and/or tarnishing the retailer's brand with bad publicity that would almost inevitably be the result of a successful compromise.