June 30, 2007 was a big day for data security. That was the deadline for organizations that store, process, or transmit credit card payments to be in compliance with the Payment Card Industry Data Security Standard (PCI DSS). As the deadline approached, the media reported that less than half of all affected businesses would be able to meet that deadline.
People in the security industry shook their heads and wondered why businesses were struggling so hard to comply with what we saw as very basic, common-sense security measures. We couldn’t figure out why even the stiff penalties for noncompliance – fines of up to $500,000 and loss of the ability to accept credit cards – apparently wasn’t enough to get affected businesses to take security seriously. And then we went right back to writing unintelligible documentation for data security programs. We cranked out mountains of articles and white papers intended to make the technologies necessary for PCI DSS compliance understandable to the general public; unfortunately we wrote them in geek, which is about as understandable to most people as Greek.
Perhaps that’s why, a year and a half after the deadline, businesses are still struggling with PCI compliance. A recent Ponemon Institute PCI-DSS Compliance survey revealed that only 28% of smaller companies (501-1000 employees) are PCI-DSS compliant and around 70% of large companies (75,000+ employees) say they are in compliance. Those are horrible statistics.
Compliance can be achieved with little or no angst if you understand what you need to do and the tools that enable you to do it. In this article we will review the PCI standard and take an in-depth look at the more critical data protection technologies.
The Payment Card Industry (PCI) Data Security Standard was created by major credit card companies to safeguard payment card data. 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. Merchants, service providers, and banks are required to perform an annual assessment (for Level 1 merchants), and annual penetration testing and application testing (for Level 1 and 2 service providers).All credit card processing systems require logging of all access to credit card data, in addition to quarterly scans and annual penetration tests.
The PCI DSS is a multifaceted security standard centered around six best practice principles and a set of associated requirements:
PCI DSS proof of compliance requirements vary according to the volume of transactions a business conducts. The chart below summarizes the four different Merchant Levels defined in the PCI standards:
For more information on the PCI DSS requirements, please visit www.pcisecuritystandards.org.
Because PCI requirements cross all security sectors, no one vendor offers all of the technologies to satisfy every one of the PCI requirements. However, as virtually every institution that handles credit card data already has network firewalls, anti-virus, and in-transit encryption technologies deployed, compliance with the PCI standard is typically focused on deployment of application security and data protection mechanisms and the integration of defense-in-depth systems and policies.
Most people are generally aware of encryption and the role it plays in data defense. But some myths about encryption still linger: the fear that encryption is impossible to manage in a distributed enterprise, will slow network performance, will impact availability of data for use in critical business processes, or will result in irretrievable data if something goes wrong with the encryption scheme. Some of these ideas were valid decades ago when encryption technology was in its infancy, but all of these issues now can be managed with mature, modern encryption solutions backed by the right policies and procedures.
Modern enterprise class solutions are designed to make the best use possible of available computing cycles and will also take advantage of background processing to help ensure that encryption has virtually no impact on network performance or users. Loss of data if the encryption key is lost in a server crash or other incident can be successfully managed through proper key management, which would include a secure key recovery process.
There’s more than one way to encrypt data, but best practices and compliance regulations dictate that we use algorithms – different methods of scrambling data – that have been tested and approved by an agency such as National Institute of Standards and Technology (NIST). Solutions providers are experimenting with different ways of protecting data, some of which have not been approved yet. That’s great; we have to keep one step ahead of the malicious hackers, but a business that is using non-standard encryption to protect payment card data is out of compliance.
Encryption is typically packaged as a “solution” and includes tools to automate processes such as key management tasks. Annual rotation of encryption keys is required by data security regulations such as PCI DSS while security best practices indicate that rotation should be performed far more frequently. (The PCI Security Standards Council has indicated more frequent rotations will be required in a soon-to-be released revision of the standard). Look for solutions that provide an automated and secure mechanism – such as dual control of encryption keys, akin to a bank requiring two signatures before it will cash a particularly large check – for key rotation that requires little to no down time for the application.
Sometimes, of course, you have to unencrypt data in order to work with it. Access to payment card data should be carefully managed and granted only on a need-to-know basis which is typically managed by a role-based/policy-based access control technology. Policy-based access defines users’ (employees, contractors and agents) access rights and assigns unique access IDs and access privileges based on the organization’s security policies. Access rights are defined on an individual basis, or more efficiently through role assignment, and rights are limited to a specific period of time. For example, temporary workers or contractors are authorized access only for specific days and times during the work week or up to a specified date.
Another feature you may see in mature solutions is “centralized management of user access.” This allows the security administrator to change status of users and/or their access privileges from a single point of control and, with a push of a button, roll it out to all impacted databases. This is particularly useful when a breach is suspected, or the business has a large or frequent staff turnover.
Tokenization is a fairly new technology for protecting highly sensitive data. When you use tokenization the original data field is automatically removed from the data flow as early as possible and is replaced with a reference that points to the actual data field. Think of it as a claim check: you hand over your data to be stored in a secure location and you get a claim check. When you need the data again, you use the claim check to obtain the item in question, in this case sensitive data such as a credit card number. Happily there’s no real claim check to worry about here, as the application processes everything behind the scenes.
In the event of a breach of the database or another business application, only the tokens could be accessed, which would be of no value to a would-be attacker. The actual payment card data is safe, stored in a highly secure server protected by robust encryption technology.
Tokenization allows enterprises to effortlessly reduce the overall risk that results from many persons having access to confidential data, often beyond what can be justified by business needs. And security is immediately strengthened by minimizing the number of potential targets for would-be attackers. Any business that collects, processes, or stores payment card data is likely to gain measurable benefits from tokenization.
Some merchants and service providers have refused to consider tokenization because it isn’t yet specifically cited as an approved technology in PCI DSS. Those businesses that are implementing tokenization specifically for PCI often cite PCI DSS 3.1, which says to keep cardholder data storage to a minimum. Since tokenization reduces the number of instances of stored card data to only one instance, this seems justified. It’s certainly something to discuss within your own business and with PCI consultants.
One thing is certain though, tokenization does not take the entire point of sale out of scope. If the POS accepts credit or debit cards, then the POS is in scope no matter what. But when properly implemented, tokenization can reduce the PCI scope and make compliance more manageable. Some forms of tokenization can even take entire applications out of scope.
Data masking hides selected sections of a data field or record while allowing the rest of the information to be viewed by authorized users. This is a useful technology when a business needs to provide access to some parts of a customer record while protecting other parts. Properly masked data provides the information necessary for analysis, testing, and QA purposes without exposing the original, sensitive information. The masked data also retains its associations and referential integrity. The use of data masking in these scenarios enables businesses to significantly reduce their data security risk profile and is often required for regulatory compliance.
Traditional data masking solutions generate lower quality substitute data – random numbers, random digits, random dates, etc., constructed using building blocks called mask primitives – that are not adequate for some use cases. So many organizations are still quietly using unprotected sensitive data in the test system environment to avoid surprises when running the applications against real data in the production environment. This is a major security issue. Some organizations are addressing this problem by building a separate and fully secured environment for integration testing and system testing. This is a very costly approach and it will only solve the issue for the last steps in acceptance testing. In many cases this approach also creates a new environment with potentially new security issues.
If you decide to include data masking in your security implementation, look for a policy-based solution that creates masked data that is truly usable for test/analysis purposes. Be wary of solutions that provide limited options; a good enterprise solution should provide enough functionality to meet changing needs and changing regulatory compliance demands. In most cases you’ll want a solution that can be used with both operational databases in test environments and statistical databases (e.g., business intelligence, data warehouses).
Some people will insist that masking should never be reversible, and in many cases that may be true, but there are some situations in which you’d want a solution that is reversible, something that would make it possible to retrieve the original data. Other use cases can be supported by data masking using random data. And there are use cases that may require parts of the credit card or social security number to be accessible. You also want a solution that allows you to automate the process of generating data; otherwise the entire process will become too costly and time-consuming.
PCI requires businesses to track and log all access to network resources and cardholder data. The presence of logs in all environments allows thorough tracking and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.
Data security solutions typically offer auditing tools. Mature solutions will track and log all attempts to access cardholder data, including the type of event, date, and time of event, and a success or failure indication. Audit logs obviously should be protected as well, access should be limited to authenticated persons with a job-related need, and that access will also be logged.
Database activity monitoring is a technology that’s been generating a lot of interest lately, but it’s important to remember that it should only be used in combination with other data protection technologies. Used properly, database activity monitoring is an appropriate solution for lower risk data. No encryption is involved here, the data is cleartext, and you are watching the data not making it unreadable. The point is not to shield that data but to provide increased visibility to how people are accessing and using an enterprise’s less-critical data. It’s a great supplemental tool in a comprehensive security plan.
In some cases we’re also seeing database activity monitoring used by businesses that are just beginning to roll out a comprehensive data security plan, or companies are using database activity monitoring alone to protect lower-risk data. It is a useful tool and a good complement to PCI-mandated protections, as long as you are aware that database activity monitoring is not a suitable way to protect high-risk data.
A critical component of PCI compliance is the implementation and on-going management of security policies across the enterprise. Policies define who has the rights to view, modify, destroy, or access cardholder and other sensitive data. To be effective, policies obviously need to be enforced, and applications have been developed to do just that.
A policy enforcement tool – or a data security solution that is policy-driven – automatically enforces an organization’s security policies across an entire enterprise. The best solutions come with pre-defined basic policies to make it easy for businesses to get the tool up and running, as well as allowing security administrators to customize the policies as needed.
A best-in-class policy management solution will include segregated security management and monitoring functions – these give organizations a way to completely separate security administration from data administration responsibilities, establishing a critical check-and-balance protocol.
Being in full compliance with PCI will result in a decent level of data security, and for some payment card processers that will be an improvement. But PCI was never intended to be an end point; it’s a foundation that was meant to be built on. Unfortunately the good intentions of PCI are lulling some payment card processers into a false sense of security, and the need to achieve compliance can siphon off time and budget that would be better spent deploying real data protection.
Take, for example, the recent case of the U.S. grocery chain that was certified PCI DSS compliant and yet was still wide open to an attack that exposed 4.2 million credit and debit card numbers. Apparently, malware installed on servers at more than 270 of the company’s stores captured card data as it was transmitted from point of sale to payment card processors. The data was then forwarded to offshore servers. Had that data been encrypted, it’s safe to assume that the subsequent 1,800+ reported fraud cases wouldn’t have occurred, but since PCI doesn’t specifically require data to be encrypted at point of capture, the result was a PCI compliant merchant with a huge security hole that was just waiting to be exploited. (And if you were a savvy criminal, wouldn’t you be looking just past those well-publicized PCI points of compliance for holes to exploit – such as data travelling unencrypted from cash registers?)
Security simply cannot be achieved by ticking off steps on a PCI checklist. Real security is holistic, encompassing technology, people, processes, and policies. It is hardwired into everything a company does, and is part of that company’s culture. And while it may seem like a real challenge at first to institute a comprehensive data security plan, ultimately a unified approach will be far more effective, increasing security and saving both time and money.
Ulf Mattsson is the Chief Technology Officer for Protegrity, a leading provider of Data Security Management Solutions. Ulf created the initial architecture of Protegrity’s database security technology, for which the company owns several key patents in the areas of Encryption Key Management, Policy Driven Data Encryption, Internal Threat Protection, Data Usage Control, and Intrusion Prevention. 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 organization 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.
The big compliance push isn’t necessarily resulting in better data security. Compliance tends to encourage security-as-destination thinking – something that can be achieved and ticked off on the to-do list. But real security is an ever-evolving journey. Below are eight of the common mistakes enterprises make in their PCI compliance efforts – well-intentioned errors that often have a significant negative impact on budgets and data security, and the best practices that can help remediate these slip-ups.
The quarterly network scans mandated by PCI DSS 6.6 are a security checkpoint, not a method of managing web application security. Web applications are now a preferred attack vector for malicious hackers and as such need to be monitored on a continuous basis. For applications developed or customized in-house, the following “find, fix, prove” process must be continually performed: Identify vulnerabilities (find), correct them (fix), and test to confirm that the correction is effective (prove). Best practice also dictates that you secure the application level with a dedicated web application firewall, which helps organizations meet 8 of the 12 PCI DSS requirements.
In some cases, rather than re-architecting an entire enterprise environment and revising critical business processes across the board, it may be more effective from a cost and data security standpoint to move systems that collect, transmit, and store PCI-protected data into their own environment and restrict these systems interactions with the rest of the enterprise network. This allows the enterprise to focus its compliance efforts on the most critical components of the network.
Narrowing the enterprise’s focus to protect data against specific types of attacks often results in opening the doors to other types of attacks. Don’t implement a media-scare-story-driven security plan based on reacting to every overwrought report or bit of research. Constantly shifting focus to manage the threat of the moment will result in piecemeal security; focus instead on comprehensively securing data.
Virtually all government and industry privacy and security regulations outline the most basic best practices of data security. Being able to pass a regulatory audit does not automatically ensure effective security. Instead of trying to protect your organization’s data assets by solely striving to meet individual regulatory requirements, focus on acting in accordance with data security-centred best practices, reinforced by security solutions such as automated policy enforcement, encryption, role-based access, and system auditing. In other words, do the right things instead of just the required things.
If a business is required to comply with data protection standards or regulations, and its outsourcing partner fails to protect that personal data, the company that owns the data will most likely be considered at fault and liable for any associated costs, penalties, or legal actions that might arise from its exposure. You must ensure that the company you are partnering with – offshore or domestic – takes data security seriously and fully understands the regulations that affect your business.
Disparate data protection projects, whether created by design or due to company mergers, often result in an impossible-to-manage hodge-podge of secured and unsecured systems, with some data on some systems encrypted and some not, some systems regularly purged of old data on a monthly basis and others harboring customer information that should have been deleted years ago. If this is the case within your enterprise, consider appointing one person as the PCI DSS compliance manager, to serve as a single point of contact and authority for compliance efforts and, ultimately, to develop and deploy an enterprise-wide unified plan to manage sensitive data assets and enable compliance with applicable regulations and standards.
The success of an enterprise’s security efforts need to be regularly reviewed and measured; older goals may need to be dropped, new plans may need to be instituted, and sometimes technologies that seemed like great ideas at the time may become a gaping security hole as a result of new discoveries. DES encryption, for example, was once considered secure until researchers proved it was vulnerable to brute force attacks due to its short (56-bit) key. Security is always a moving target and we have to be willing to move forward as conditions demand.
Security measures that aren’t understood and fully embraced across the enterprise can and will be circumvented. As you plan and implement PCI DSS, don’t stint on ensuring that employees understand the importance of keeping customer data secure and protected and have the tools and training they need in order to secure that data.
We’re always on the lookout for opportunities to partner with innovators and disruptors.
Learn More