Printer Friendly

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 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 management/cisp_merchants.html.

To review the standards for the PCI Payment Application Best Practices programme, see 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.

In either of the above scenarios, the insider has learned how the POS system functions well enough to attempt an attack. Traditionally, insider threats are the most difficult to prevent and detect. Further, it is likely that no technology solution will be adequate to safeguard against every possible attack scenario.

However, other industries (notably the financial services industry) have handled insider threats for decades. In situations where known technology weaknesses are recognised, the financial services industry typically compensates by instituting procedural checks and balances. These greatly reduce the likelihood of successful attacks. In most cases, they come in the form of separation of duties and multiple points of possible failure. The result is no single employee has the ability to compromise the entire system easily. Instead, a conspiracy would need to exist, which is deemed to be much less likely. That same approach of separation of duties is also used significantly in the recommendations made later in this article in circumstances where weak points exist in a typical POS architecture out of necessity.

Common outsider threats

A second category of threat that must not be neglected is outsiders. Although their motivation is far more likely to be profit rather than to harm the retailer's reputation, it is important to consider them in the analysis.

At least two feasible scenarios exist that could provide an outsider with an attack vector for launching an attack on the POS; both scenarios involve poorly configured retail store site networks.

In the first scenario, a retail site network is misconfigured so that it is directly accessible to the external internet at large. In this scenario, an opportunistic attacker may accidentally (or otherwise) find the retail network and begin an attack.

The second scenario would involve a mis-configured site network that inadvertently allows any 'guest' data traffic to traverse the same network that the business systems, including the LSS itself, resides on. In both cases, a successful attack on the POS itself should need to include a significant additional effort to explore, analyse and learn the operation of the POS. Such an attack may well take months or more, but considering the five-year lifespan of the POS, it should be wise to treat it as possible, however unlikely.

Other threats

Although we consider the above threats to be the most likely, they are in no way the only ones that exist. Similarly, other motivations for attacking the POS may also exist. The internet has seen an enormous amount of "joy riding" attacks over the years that seem to be motivated by little more than intellectual curiosity and bravado. The largest risk of successful attacks by these miscreants is denial of service and other forms of general havoc. Certainly, not something to be ignored, but the business impact to retail is not likely to be anywhere as significant as in either of the above scenarios.

Retail system architecture

This article is using examples based on a retail system with a LSS performing encryption of credit card data at the retail store level. The encrypted data is decrypted by a Central Security Service (CSS). Security administration and key management is performed by a Central Administration Service. In the case where a store and forward approach is used between the store locations and the central system, a few of the potential scenarios that are reviewed below can be avoided. These include a major Wide Area Network (WAN) outage.

In a typical LSS deployment, other non-LSS components are housed on the same equipment that the LSS resides on. This may also include an archive of credit card (tokens if used) in the POS environment. Although data is encrypted and believed to be quite safe from inadvertent disclosure, other system failures (e.g. disclosure of the encryption key) could expose the archived data to an attacker. The potential business impact to the retail organisation in such a compromise should be regarded as high.

The most effective means of minimising this risk is to separate the Encryption Key Service from the other components residing on the same computer hardware, minimise the volume of sensitive data stored locally and, if possible, provide significant physical protection of hardware containing highly sensitive data. Many other industries commonly collect their most sensitive data and store in data centres with substantial physical security.

Rendering data unreadable

There are three radically different ways to render data unreadable:

1) two-way cryptography with associated key management processes,

2) one-way transformations including truncation and one-way cryptographic hash functions

3) using index tokens and pads.

Two-way encryption of sensitive data is one of the most effective means of preventing information disclosure and the resulting potential for fraud. Cryptographic technology is mature and well proven, and there is simply no excuse for not encrypting sensitive data. However, the choice of encryption scheme and topology of the encryption solution is critical in deploying a secure, effective and reasonable control. The single largest failure in deploying encryption is attempting to create an ad-hoc cryptographic implementation.

Hash algorithms are one-way functions that turn a message into a fingerprint, usually a several dozen bytes long binary string to avoid collisions. Truncation will discard part of the field.

These approaches can be used to secure data fields in situations where you do not need the data to do business and you never need the original data back again, but unfortunately a hash will be non-transparent to applications and database schemas since it will require several dozen bytes long binary data type strings (longer than the 20 bytes for the broken SHA-1 or two-way symmetric encryption). An attacker can easily build a (rainbow) table to expose the relation between hash values and real credit card numbers if the solution is not based on HMAC (Hash Message Authentication Code) and a rigorous key management system. Salting can also be used if data is not needed for analytics.

An HMAC is a type of message authentication code (MAC) calculated using a specific algorithm involving a cryptographic hash function in combination with a secret key. As with any MAC, it may be used to verify both the data integrity and the authenticity of a message simultaneously. Any iterative cryptographic hash function, such as MD5 or SHA-1, may be used in the calculation of a HMAC; the resulting MAC algorithm is termed HMAC-MD5 or HMAC-SHA-1 accordingly. The cryptographic strength of the HMAC depends upon the cryptographic strength of the underlying hash function, on the size and quality of the key and the size of the hash output length in bits.

An attractive solution to this problem can be tokenisation that is the act of replacing the original data field with a reference or pointer to the actual data field. Tokenisation enables you to store a reference pointer anywhere within your network or database systems. It can be used to reduce the cost of securing data fields, but will require a central service to assign permanent (persistent) token values. Tokenisation by a local service can be used to assign a non-permanent token value at multiple end points early in the data flow. You must always support a tokenisation system with a rigorous encryption system based on separation of duties, secure audit, random key generation and protection of keys and credentials.

Choosing cryptographic algorithms

The encryption algorithms used in the POS architecture should be chosen carefully and be widely accepted, subjected to extensive peer analysis and scrutiny. Such analysis is the norm in the cryptographic community. A weakness in the cryptographic algorithm could result in a complete compromise of the POS system. Thus, the potential business impact to a retailer would be extreme, and could result in failure of both of the POS's primary business objectives.

Cryptographic failure would have such a significant impact, that I strongly recommend a rigorous review of the selected algorithms in use. It is generally considered a best business practice to use a published cryptographic algorithm for protecting sensitive information. Accepted algorithms typically include those specified by the National Institute of Standards and Technology (NIST) as being Federal Information Processing Standards (FIPS).

Protection of cryptographic keys

It is essential that each LSS (as well as CSS) retains a copy of the encryption key while in an operational (unlocked) state. At the same time, however, this "crown jewel" exposes the POS system. An attacker with access to a LSS could potentially peruse the system's processes and memory to acquire the key and decrypt data. The likelihood of this sort of attack succeeding is quite low, but were it to be successful the impact could be very high. Take every reasonable precaution to protect the key while the LSS is operational.

Combine software cryptography and specialised cryptographic chipsets

Encryption keys should be protected when stored in memory or in databases, and during transport between systems and system processes. This can be achieved by using a well balanced combination of software cryptography and specialised cryptographic chipsets (known as Hardware Security Module (HSM)). They can provide a selective, added level of protection, and help to balance security, cost and performance needs.

Certain encryption keys and fields in a database require a stronger level of encryption, and a higher level of protection for associated encryption keys. Encryption keys and security metadata should continuously be encrypted and, have their integrity validated, even when communicated between processes, stored or cached in memory. Security data should remain ciphered until needed for use by crypto-services routines.

Some keys must be available in memory

Different types of keys need to be available in memory. With software-based crypto and HSM-based encryption the data encryption and access keys must be available in memory. It may not be feasible to use a primary and a secondary HSM in each store location. A solution based on distributed software and an optional HSM is a feasible approach in many environments, since each POS must also be able to operate even if the connection to the HSM in the store is down. Memory attacks may be theoretical, but cryptographic keys, unlike most other data in a computer memory, are random. Looking through memory structures for random data is very likely to reveal key material. Well made encryption solutions go to great efforts to protect keys even in memory.

Protection measures to consider should include memory compartmentalisation. Generate a separate ID that does the actual encryption/decryption, and ensure that no other process or system ID can access its memory. Ensure that the encryption/ decryption process and its memory does not get swapped out to a virtual memory swap/page file, which could leave behind persistent residue that could include the encryption key. Whenever the key is no longer needed, ensure that the memory location/variable where it was stored is thoroughly wiped. Consider a centrally monitored host-based intrusion detection system on every LSS to watch for attacks on the host itself.

The above list of recommendations for encryption key handling is commonly practiced throughout various industries where sensitive data is encrypted.

Some keys are more sensitive

Key-encryption keys are used to encrypt the key while in memory and the encrypted key is then split into several parts and spread throughout the memory space. Decoy structures may also be created that look like valid key material. Memory holding the key is quickly zeroed as soon as the cryptographic operation is finished. These techniques reduce the risk of memory attacks.

Separate encryption can also be used for different data. These encryption keys can be automatically rotated based on the sensitivity of the protected data.

Since web servers, application servers, and databases have no place on a dedicated cryptographic engine, these common attack points are not a threat. A severely constrained attack surface makes it much more difficult to gain the access needed to launch a memory attack. To maintain a high level of security, backups contain the encrypted data and only securely encrypted lower level keys. Additional details about implementation of key management will be discussed in a separate article.

Dual control, split knowledge and PCI

PCI DSS requires you to use dual control and split knowledge and proper key management practices to manage your keys. Dual control and split knowledge means no one person should have access to any information, device, or function, that allows them to determine the key that is being protected more quickly than through the best attack known for that algorithm. Ideally, this means a brute force search of the entire key space. The determination of any part of the key must require the collusion between at least two trusted individuals. This requirement can be a challenge in the POS environment and solutions will be discussed in a section about the LSS in part two of this article.

Any feasible method to violate this axiom means that the principles of dual control and split knowledge are not being upheld. This principle is enforced by requiring both dual control, and split knowledge. In other words, at least two people are required to reconstruct the key, and they must each have a physical item (thereby providing dual control), and some information that is required (thereby providing split knowledge). It is not enough to split a 128-bit key in half with each half containing the plain text bits of the original key. One of the two custodians can determine the key by exhausting the other half. This requires only 2^64 operations, instead of the 2^128 which is required for the entire key space.

Nor will storing key components on two media and not requiring any further authentication by the users to use these components provide the required split knowledge. Storing a key enciphered under another key that can be re-constructed with one or more passphrases, provides split knowledge, but not dual control. Storing a key on a single media that requires one or more passphrases to access does not meet the requirements of dual control. The dual control and split knowledge is only required to access the plain text key. The use of a key to encipher or decipher data, or access to a key that is enciphered under another key does not require such control.

Central helpdesk access to keys

At various times during normal POS operations, central helpdesk staff and site system administration staff are likely to have access to unlock-keys and encryption-keys. Despite the fact that key management has been carefully thought through to minimise these exposures, opportunities do exist for support staff to compromise customer data. Further, detecting this sort of insider attack can be extremely difficult, but the impact of a successful such attack on the POS could be quite severe.

Best practices in similar data environments generally include most, or all of the following measures. Check all personnel involved in sensitive operations such as key management. Ideally, support employee that has access to encryption keys should not have access to any sensitive, encrypted data and vice versa. This, however, can be a difficult measure to implement. Feasible, functional duties should be separate within the data centre. For example, help desk personnel who handle LSS unlocking should not also be involved with encryption key management.

The above recommendations are entirely consistent with practices found in numerous other industries, including financial services, where similar access to sensitive customer data is required.

PKI considerations

A tight integration of PKI and the POS system is possible in advanced POS environments. Rigorous mutual authentication, data encryption, etc., that a PKI enables are considered to be best practice solutions across numerous industries today. Consequently, a failure of the PKI would, without a doubt, have a devastating effect on the POS. A PKI 'situation', such as the retailer's Certification Authority (CA) certificate appearing on a Custody Receipt Listing (CRL) could halt the entire PKI in its tracks. Since the PKI is literally the infrastructure of the POS, a PKI failure could have a commensurate affect on the POS, resulting in considerable business impact on the retail organisation. Although the deployment and operation of the retailer's PKI is outside the direct scope of the POS project, great care must be taken to ensure that the PKI is operated in compliance with all relevant PKI industry best practices and procedures.

SSL keys in plain text

During a POS review, it is common to find Secure Socket Layer (SSL) private keys left in plain text on some servers. This could indirectly help an attacker get one step closer to attacking the POS successfully. In particular, the plain text SSL key could enable an attacker to masquerade as an authorised server in a Security Service conversation. The likelihood of such an attack succeeding is quite low, but could enable an attacker to do anything that the local service is able to do.

Consider password protecting the SSL key for the service. Although this can be unfeasible in some operational scenarios, if it doesn't present an undue burden for the retailer, it should be done. Password protecting SSL keys is commonly done on production servers throughout various industries. On the other hand, doing so is often not feasible, and thus, it is not uncommon to find plain text SSL keys in production data centres. It is less common to find plain text keys on field-deployed servers, however.

In June Database and Network Journal--Part 2: Protecting the Security Services and Web Applications

About the author: Ulf Mattsson is chief technology officer with Protegrity having created the initial architecture of Protegrity's database security technology, for which the company owns several key patents. His extensive IT and security industry experience includes 20 years with IBM as a manager of software development and a consulting resource to IBM's Research and Development organisation, in the areas of IT Architecture and IT Security.

Ulf holds a degree in electrical engineering from Polhem University, a degree in Finance from University of Stockholm and a master's degree in physics from Chalmers University of Technology

Protegrity Awarded Patent on Database Key Rotation Method

Protegrity Corporation has announced that it has been awarded a patent for database key rotation that allows for zero application downtime.

United States Patent 7,325,129, developed by Protegrity's chief technology officer Ulf Mattsson, delivers a continuous process for changing encryption keys in relational databases.

This ensures initial encryption, real time updates and on-demand key changes can all occur without ever needing to take mission-critical systems offline.

The patented technology, available across Protegrity's Defiance[R] Data Protection System solutions, extends customer control over data security management while ensuring service level agreements are no longer violated due to key rotation downtime demands.

The amount of time it takes an organisation to comply with PCI and other data security-focused regulations can be greatly reduced and enterprises will benefit from an increase in application availability without having to compromise database security.

"With this patented technology, Protegrity customers gain another practical layer of control over enterprise-wide data security," says Ulf Mattsson, chief technology officer of Protegrity.

"Database key rotation with zero downtime gives our clients a powerful new way to secure their databases while complying with data protection regulations with no impact on essential business processes."

Ulf Mattsson, chief technology officer with data security management specialist, Protegrity
COPYRIGHT 2008 A.P. Publications Ltd.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2008 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Mattsson, Ulf
Publication:Database and Network Journal
Date:Apr 1, 2008
Previous Article:IP/MPLS network management--automate or disintegrate!
Next Article:Businesses are embracing an XML future to prepare for changing times.

Related Articles
Server consolidation: cost saving but what about security? (Security).
Virtual vulnerabilities. (Up front: news, trends & analysis).
Education Matrix.
The underutilised security bulwark: database logs.
Beyond compliance: protecting sensitive data on the mainframe environment: in the light of the British Government data loss, part two of a rather...
The good, the bad and the ugly of protecting data in a retail environment--Part 2.

Terms of use | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters