An examination of news headlines in the first few months of 2006
reveals an apparently never-ending litany of data breaches and
compromised consumer information. This is despite the new spate of
data security and notification laws being passed around the country
and the current industry mandates on information security. This also
seems to fly in the face of the increased effort that most of the
Payments Industry is putting into PCI compliance and data security.
The most prominent of the recent breaches, in which a retailer was
compromised exposing hundreds of thousands of debit cards and their
PINs, highlights a potential weakness in any retail environment:
protecting data at the Point-of-Sale, or POS.
It is not a secret that hackers are increasingly targeting retail
merchants. In fact, well over half of the reported data breaches in
the past year involved card-present retailers. A closer look will
demonstrate that many of those targeted were in the restaurant or
hospitality industry. Why is the trend for data thieves to target
card-present retail merchants? There are two primary reasons that
POS retailers are being increasingly targeted over their Internet-
based counterparts. First, thieves want to steal data that can be
used to perpetrate fraud. Second, POS environments often present
more opportunities for exposure of sensitive data than eCommerce
environments.
The first issue is simply related to the value of the information
retained in retail environments. Hacking into an eCommerce company
will typically (if the company is PCI compliant) only result in the
compromise of the Primary Account Number (PAN), expiration date,
service code, and cardholder name and address. While critical from a
privacy standpoint, this data cannot be easily used to perpetrate
fraud. In the odd instance where the Card Validation Code (CVC2,
CVV2, etc.) is present (the merchant would not be compliant with the
PCI), it still results in a limited ability to use the data for
fraud. Thieves of CVC2 data can only conduct fraud over the Internet
and cannot recreate the cards. Retail merchants utilizing Point of
Sale, “swipe terminals” capture and transmit full magnetic stripe
data for authorization. This data, if compromised allows criminals
to recreate the actual card and conduct fraud much more easily and
efficiently. With full magnetic stripe data in hand, the criminals
are no longer limited to perpetrating fraud over the Internet.
The second issue is more complex. The current Payment Card Industry
Data Security Standard (PCI-DSS) applies to all companies that store,
transmit or process data. Requirement 3.2 of the PCI-DSS prohibits
the storage of magnetic stripe data subsequent to authorization. So
why are companies storing such data? The answer, unfortunately,
often lies in the POS solution used by the merchant and is not a
result of intentional non-compliance on the part of the merchant.
While all merchants and service providers are required to comply with
the PCI, the vendors that develop the POS solutions do not fall under
the purview of either the card associations or the member banks. As
a result, many POS developers provide solutions to merchants that do
not support PCI compliance. It is an unfortunate fact that many
merchants that are compromised simply did not know that they were
storing magnetic stripe data. Going back to the rash of compromises
in restaurant and hospitality segments it appears logical that they
would provide more attractive targets as they often employ multiple
POS systems over distributed networks. More POS systems and
registers mean that more targets are available to hackers and more
data is available to steal.
The Point-of-Sale challenge:
Today, retail merchants are often at the mercy of their POS vendor.
The merchant selects a POS solution that appears to fit their
business needs and is assumed to be secure. These merchants often
take great pains to ensure their infrastructure is compliant with the
PCI standard yet they are relying on the security of a POS solution
over which they have no control. This is where the problem for many
merchants starts. Point of Sale solutions all allow for the capture
of full magnetic stripe data. Many POS applications store the
magnetic stripe locally in log files for use in issue resolution. It
is not uncommon for a retail merchant with an integrated POS solution
to have a complete log filled with the full magnetic stripe data from
every single transaction ever conducted, stored locally on the IPOS
register. Often the systems are installed with verbose logging
enabled by default. This default setting is often unknown to the
merchant. In spite of the fact that the merchant may be encrypting
their primary database and may be ensuring no sensitive magnetic
stripe data is ever stored in their database, they are often storing
such data in various log files. The criminals have learned this and
are simply bypassing the primary databases and are looking for log
files filled with magnetic stripe data.
A clear example of this is a recent compromise of hundreds of
thousands of debit card numbers and PINs from a prominent merchant.
The merchant was employing a POS solution that used a very common
tracing and logging utility and was configured, by default, to store
unencrypted full magnetic stripe data in local logs as well as in a
centralized database. This same solution, in a default configuration,
also logged the PIN blocks and the encryption key in local logs. The
merchant could well have thought they were taking all necessary steps
to prevent the exposure of their sensitive data only to have their
security and compliance compromised by their POS vendor.
Another challenge faced by POS merchant is the need to support ‘store
and forward’, ‘batch’ or ‘offline’ processing. In these scenarios
the merchants must store full track data temporarily to allow for
authorization at a later time or date. While the business reasons
for using these methods may vary, the end result is similar. That is
that full magnetic stripe data is stored in a flat file. These flat
files are increasingly becoming targets of hackers and data thieves.
What can a merchant do?
There are several steps a merchant can take to ensure that their POS
systems do not compromise their PCI compliance and, more importantly,
that their POS systems do not inadvertently expose them to a
potential compromise of cardholder data. First, it is important to
ensure that whichever solution is used supports PCI compliance. To
support PCI compliance, the solution should ensure that logical
access, and other security controls are consistent with the PCI. If
software driven, it is advisable to select a solution that has been
validated against the Payment Application Best Practices (PABP). In
October 2005, MasterCard International released a new standard to
specifically address security of IP and wireless based POS
solutions. By 2006, it is required that all POS solutions be tested
and approved against these standards. As we have seen with the PCI,
while the card associations may push hard for adoption, legacy
systems and other factors will likely slow the process. Every
MasterCard member has access to the newly released IP POS standards
and should be able to provide the document to their merchants.
The second step that should be taken is to ensure that magnetic
stripe data is not being retained either in local logs or in
centralized logs. Inquire of the POS developer as to how data is
stored for issue resolution. Ensure that verbose logging is not
enabled, by default, on the POS systems. This alone will likely
prevent the storage of most of the magnetic stripe data.
Finally, it is a good idea to ensure all log files, and flat files
are encrypted. In the event logging is either intentionally enabled
by a hacker trying to steal magnetic stripe data, an employee trying
to resolve an issue, or unintentionally enabled, encryption of the
log files will prevent exposure of critical magnetic stripe data.
Similarly, encrypting flat files will ensure that they are not a
point of exposure of cardholder data.
|
