On December 29, 2005 CNN announced that 2005 had seen over 130 data
thefts resulting in potential exposure of 50 million people to
identity theft. Protecting customers’ sensitive data is critical to
ensuring the continued success of your company. While a variety of
controls are necessary to protect the confidentiality, integrity, and
availability of systems, protected data at rest is best achieved
through the proper implementation of encryption technologies.
The Payment Card Industry (PCI) Data Security Standard requires that
all companies that store cardholder data do so in a secure manner.
It requires that all merchants and service providers employ strong
cryptography to ensure that all sensitive data is adequately
protected. Unfortunately, a number of challenges have put compliance
with this requirement out of reach of most organizations. In fact,
the majority of companies currently in compliance with the PCI do not
encrypt data and instead have achieved compliance through the use of
compensating controls. This article will briefly explain the two
primary methods of encrypting data and describe why file-level
encryption may be the best solution for achieving compliance with the
PCI.
Today there exists two primary approaches to encrypting sensitive
data stored within a database; file-level encryption, and column-
level encryption. While both employ encryption technologies to render
cardholder data unreadable and support compliance with the PCI, this
is where the similarity ends. Column-level encryption operates at the
database layer to encrypt individual columns within a database. This
restricts views of unencrypted data to authorized users or groups.
Conversely, file-level encryption works at the operating system layer
and is used to encrypt the underlying files in which a database
stores its data.
There has been significant debate over the value of file-level
encryption versus column-level encryption. As most encryption
companies have pursued encryption from a column-level perspective,
this method has garnered the most attention and has consistently been
promoted as the best method for protecting data. Upon reviewing the
data, and solutions, this author disagrees. While column-level
encryption is a good solution, within the payments space, it is
suggested that file-level encryption is a better solution to
achieving compliance and protecting sensitive data.
There is a perception that column-level encryption is necessary to
protect sensitive data within a database. While it appears logical
at first glance, closer examination shows that column level
encryption provides little, if any value over file-level encryption.
All commercial-quality relational databases offer column-level access
control. Even encrypted columns still require that a database
administrator define access controls. This ensures that only
authenticated, authorized users are allowed to access the columns,
regardless of whether they are encrypted or not. For this reason,
column-level encryption does not offer any additional security over
native column-level access controls unless it can prevent the
administrators from gaining access to sensitive data. While most
column level encryption solutions can prevent the DBA from gaining
access to the encryption key, they cannot prevent DBAs from modifying
stored procedures and triggers or impersonating other database users
to gain access to unencrypted data While column-level encryption is
often proposed as the best security for databases, in truth, column-
level access control is the best method for protecting data within
the database.
While providing data protection, column-level encryption poses
significant challenges for companies operating within the payment
services space. Historically, column-level encryption solutions have
not lent themselves well to addressing the specific business needs of
merchants and service providers. While not an exhaustive list, below
are some of the more pronounced challenges merchants and service
providers face when evaluating and employing column-level encryption
solutions
Limited Applicability
By design, column-level encryption solutions encrypt data within
databases. While merchants and processors certainly store the
majority of their sensitive data within databases, a significant
amount of sensitive data frequently resides in additional locations.
Merchants and service providers who ‘batch’ process transactions will
often have large amounts of data in flat files. In addition,
transaction and debugging logs frequently contain cardholder data.
Unfortunately, these files are not protected by column-level
encryption solutions. It is important to note that the PCI
requirement 3.4 requires that sensitive cardholder data be rendered:
“…unreadable anywhere it is stored, (including …in logs…)…”
Performance
Merchants and service providers are in the business of handling,
manipulating, and transmitting cardholder data. As such, ensuring
data can be processed efficiently is critical to the success of any
company within the industry. While all encryption solutions provide
some overhead in terms of resource consumption, column-level
encryption solutions appear to impact performance significantly more
than file-level solutions.
As column level encryption solutions may require API calls outside of
the database server (in some cases onto a hardware box) the network
latency may increase in orders of magnitude. It is not uncommon for
some column-level encryption solutions to increase CPU consumption
alone by over 30% and may add over 100% overhead when all factors are
considered.
Integration challenges
Integration or implementation challenges should be described in terms
of how invasive they are to the current architecture or
applications. While column-level encryption solutions vary by
design, all interact with the DBMS at the database layer. This is
necessary to allow encryption at the column level. Integration of
column-level encryption solutions frequently require modifications to
the existing database and commerce applications. For third-party
applications, such modifications may not even be supported by the
vendor.
Unnecessary Granularity
While column-level encryption provides granular control over data
that is encrypted, within the payment services industry, this may not
be needed. Beyond the PCI, there exist a number
of laws that require the protection of personally identifiable
information (SB1386, OPPA). If the technology exists to encrypt all
personally identifiable information it does not seem logical to
exclude such data from the process. To do so would simply impose
additional liabilities.
Cost
Historically, column-level encryption solutions have been
prohibitively expensive for the majority of level-2, 3, and 4,
merchants and service providers. In addition to the costs associated
with
the initial purchase of encryption hardware and software licensing,
additional costs are frequently incurred from application and
architectural upgrades and redesigns.
As stated previously the Payment Services industry has some unique
needs that challenge conventional column-level approaches to
encryption. Unlike traditional ‘corporate’ and other company
networks, organizations working in the electronic payments industry
require solutions that support their
need for efficient, high speed processing. Additionally, the
complex, proprietary nature of most payment applications does not
lend itself well to integration with many column-level database
solutions. While possibly not the best solution for every
environment, within the payment services space,
file-level encryption solutions provide several significant
advantages over their column-level counterparts.
Ease of Integration
Since file-level encryption solutions operate just above the file
system, integration with existing applications and systems is much
simpler than with column-level solutions. In short, the solution
operates independent of the database, and other applications making
it non-invasive. This means that database schema, application
reconfigurations, and network modifications are not necessary.
Low Resource Consumption
While it would appear logical that encrypting a complete file would
consume more resources than encrypting a single column, this is not
accurate. File-level encryption solutions can operate with less than
5% resource consumption. The low overhead enables companies to
employ encryption without expensive system or network upgrades.
Granular Access Control
In addition to encrypting sensitive files, some file-level encryption
solutions also provide granular access controls. This feature
supplements the primary encryption functionality and allows companies
to restrict access to sensitive files based upon a who, what, where,
and how criteria. As the file-level solutions operate at the
operating system layer, they function independent of existing access
controls employed by Active Directory or LDAP. The access controls
provided by file-level encryption support compliance with PCI
requirements 7 and 8.
Robust Auditing and Logging
XComplimenting the access control detailed above, some file-level
encryption solutions provide robust auditing and logging of access
and activity. As PCI requirement 9 is one of the more difficult
requirements to meet, robust logging provides a significant benefit
for companies choosing file-level encryption.
Multiple File Encryption
XAs file-level encryption works at the operating system layer, the
type of file that is being encrypted is irrelevant. This means that
cardholder data in flat files, as well as any sensitive data
in log files, data extracts, debug logs, or configuration files can be
encrypted as easily as the database files. This provides a
significant benefit within the payment services space as sensitive
data is often found in multiple locations.
Industry specific challenges and needs complimented by a promotion of
column-level encryption as the only acceptable means of achieving
compliance has hindered the adoption of encryption by merchants and
processors. While column-level encryption is a solid technology with
many applications, within the payment services industry file-level
encryption is often a better solution to protect sensitive data and
to ensure compliance with the PCI as well as other, relevant
regulations. It is important to remember that no technology is a one-
size fits all solution. Before progressing in your compliance
project with a particular encryption technology, it is imperative to
ensure that the solutions chosen are the best fit for the particular
needs of network environment in question.
|
