As a Certified Information Systems Security Professional (CISSP) and Payment Card Industry (PCI) Qualified Security Assessor (QSA), I frequently run into unencrypted cardholder data while conducting assessments. Actually, as a PCI Assessor, I am required to verify there is no unencrypted credit card data per many of the requirements in Section 3 of the PCI Data Security Standard (DSS). If such data is discovered during an assessment, I’ll take this information to the client and follow a somber progression of discussion, shock, denial, awe and many more steps before the remediation really gets into full swing (or even begins).
As a matter of awareness, in some states PCI Compliance issues impact both the client’s PCI Compliance status and also potentially their compliance with state data protection laws based upon the PCI Data Security Standard. Occasionally clients expressed this concern and often they mention Minnesota, Washington, and Nevada when discussing it. This article is not intended to provide ANY legal advice - consult the laws in the states where your company does business and your personal legal and/or corporate legal counsel for additional information.
Typically I find that the client had no idea the information was even there. Sometimes the data resides on in-scope systems; sometimes it resides on systems that were not supposed to be in-scope; and sometimes the data re-appears as fast as it is removed -- and developers and administrators alike end up investing an incredible amount of time to review systems and code to pinpoint how it is getting there.
Occasionally it is an organization’s applications causing the storage. In these cases, the data is structured and resides in undocumented data queue folders and temp files/folders used by middleware products. (Tip: run system call traces AND search the file systems. The system call traces will find where the data is being stored so secure deletes can be used to remove it. Regular expressions along with tools like grep, SENF, and Spider are helpful in finding the data on disk)
Unfortunately, it is also common for the legacy functionality that was built from necessity during the organization’s experiments with shadow IT teams -- those that operate on the fringes of the core applications and fill those enhancement requests that an underfunded IT department can never seem to get to -- that cause the unencrypted storage of cardholder data in unstructured, almost random formats. (Hint to those who still have "shadow IT": Fund the IT Department and focus on business cases and ROI because professionals always build things that are better in the long run.)
Major problems are often found on an organization’s email servers, portals, document repositories, file servers and print servers.
Call centers sometimes have quality assurance recordings with cardholder data in audio format (which is easily mined by data thieves using voice recognition, by the way! YIKES!).
Sales offices sometimes have customer files with cardholder data to assist their sales agents with entering their favorite customer’s PAN repeatedly so customers do not have to provide it every time.
Worse yet are the orders in your customer emails -- with full PAN -- because it causes your email system to store cardholder data. When someone enters these into the PCI applications, it confirms email is an acceptance channel -- a clear PCI violation regardless of what the Information Security Policy says. When someone replies with a canned message about not being able to accept orders sent via email, but forgets to remove PAN from the message, they distribute someone’s credit card number in unencrypted form over the Internet -- another clear violation. (Tip: Have an outbound call representative call the customer to get the PAN via phone instead. This is an opportunity to try to upsell while they are on the line, so it could lead to more business. Also, if it costs customers' time and effort when they email PANs, they’ll likely stop doing it!)
The problem does not stop at order acceptance. Customers tell me that putting a stop to the wide variety of compliance problems is as much an employee culture and customer relationship management issue as it is a business process problem.
On the back-end there are agents IM-ing back and forth, legacy sales receipt documents with unencrypted cardholder data, charge-back-related spreadsheets, full PAN and/or CVN information in the data analysis environments, cardholder data in voicemail systems, old backup tapes, log files from the last debug session, and a seemingly endless supply of other trap doors just waiting to undermine efforts to be PCI-compliant.
Every time I find cardholder data being stored unencrypted and where it doesn’t belong, the problem has a dramatically negative effect on the overall size, scope and level of effort required to get through a customer’s yearly PCI DSS assessment. Regardless of how it's done, my team must routinely verify appropriate identification of PCI scope is taking place within a customer's Cardholder Data Environment, so periodically merchants and service providers who store/process/transmit cardholder data should really take the step to identify all of the stored cardholder data locations on their own.
Diligence and supporting evidence are at the foundation of each and every statement found inside a ROC. When ROC projects go astray, it’s not that assessors wanted to have a level of distrust toward our clients. We are required to verify their every word. So, when a statement is proven false, previous statements can also come into question. These situations can cast a shadow of doubt over the entire process. This always requires additional levels of inspection, and it usually also spells trouble.
Here are two questions for clients to consider before an assessment:
Why not discover the data loss on your own and clean it up before the assessor arrives onsite for your annual review?
Why not fully document the process used to search, and be ready to demonstrate the process to the assessor? If you have a solid process that the assessor can become comfortable with, there’s little reason the assessor won’t go along with reviewing your configs and watching you run your search again, rather than trying to engineer and complete his or her own approach. When it comes to finding stored cardholder data and dealing with technical enforcement of written policy, one of the best tools for helping with this process is DLP.
What is DLP?
“DLP” is short for “Data Loss Prevention." DLP is a name for a category of products or suite of tools designed to help protect information. DLP can detect unauthorized data flows or stop unauthorized flows of sensitive information, depending upon how it is configured.
How does DLP work?
It varies by the DLP technology used, but in general terms a method of identifying information is applied to an information transport or storage point, and if the information is detected, a policy enforcement capability is invoked. DLP mostly relies on a mixture of regular expression-based string matching, file watermarks, meta-data matching, transport type, conceptual (lexicon based), fingerprinting analysis, and storage point/type based logic to identify the data that should be protected and what the desired enforcement of the configured policy is. DLP solutions often use content awareness and contextual analysis to determine when there are potential incidents.
What security gaps do DLP technologies help fill? The most important purpose DLP serves is data asset identification. It is impossible to adequately protect data assets in an organization if the entity is unable to identify where all copies of the data asset exist. A second benefit of having DLP technology is the ability to control information going forward -- after data assets are found and marked, and unauthorized data storage points are cleaned up. DLP can prevent data from leaking to USB drives, unauthorized emailing of sensitive information, unauthorized cut/paste or upload of sensitive information to Internet websites, and several other things, depending on the type of DLP technology used.
What types of DLP solutions are there? Lots! At FishNet Security we often categorizes DLP solutions by breaking them into the categories of data in motion, data at rest, and data in use. Within the categories of DLP solutions, the common ones I run into are:
- Email interceptors (situated between the corporate email servers and the Internet)
- Workstation and server agents
- Web/proxy interceptors
- Data at rest discovery solutions
What phases will a typical DLP deployment to through? At FishNet Security we characterize the high level deployment stages for our customers as:
Using this staged approach helps create a concept of a baseline within an environment passively then moves into the monitor and protect states where DLP is able to take actions.
Mapping PCI DSS Requirements to DLP Solution Approach:
|PCI DSS Requirements||DLP Solution Approach|
|Requirement 3: Protect stored cardholder data||Discover, classify, quarantine|
|Requirement 4: Encrypt transmission of cardholder data across open, public networks||Monitor, protect (e.g., block or encrypt)|
|Requirement 7: Restrict access to cardholder data by business need-to-know||Discover, classify, quarantine|
|Requirement 8: Assign a unique ID to each person with computer access||Discover, classify (e.g., data at rest scanning to identify groups with access)|
|Requirement 10: Track and monitor all access to network resources and cardholder data||Monitor, protect (e.g., data in use at endpoint through copy, print)|
|Requirement 12: Maintain a policy that addresses information security||Help meet compliance with corporate security policy|
What are examples of methods that can be used to bypass DLP solutions?
Taking a photo of a screen is a common example of a bypass.
Another we often encounter is accessing information from platforms that the client based DLP tools in use do not support – OSX, for example.
Another we encounter is printing, particularly authorized printing of documents, followed by unauthorized physical removal. Several endpoint agent solutions have added features to allow DLP administrators to block printing; however, for whatever reason it seems that turning this feature on is frequently low on the administrator’s todo list.
Another is the wide variety of encryption-based attempts -- ranging from simple character substitution to full FIPS 140-based methods.
There are many other ways I have not listed as well. Realizing there are numerous scenarios that can potentially permit data to sneak past even the most sophisticated DLP solutions is an important part of being a responsible owner of a DLP solution because it encourages a layered approach.
If DLP can be bypassed in certain situations, why should my organization use it?
- It stops the many obvious problems in their tracks. It can prevent malicious software from extracting information and uploading it to malicious or unknown third parties via the network's egress.
- It helps identify malicious users (who are frequently “well meaning insiders”) who are violating policy in creative ways that may otherwise go undetected.
- It helps stop users who may otherwise steal information.
- The use of DLP demonstrates due diligence and assists with reasonable information protection.
Often security managers look at their DLP deployment as a risk reduction tool. DLP offers the ability to gradually change behaviors through “teachable” moments.
The bottom line: DLP comes in many forms and flavors, and while it is not infallible, it is still a great technology. Well rounded metrics based reporting are often a key feature of DLP solutions so it’s easy to run reports and show what DLP has done to protect the environment. With such reports, management quickly realizes DLP was money well spent. Also with DLP it’s easy to demonstrate the PCI environment is properly scoped.
The clients I have talked to generally say their DLP technology paid for itself the moment it successfully detected just one problem or stops one incident. Select a DLP product, mark all the information you believe is sensitive, and find out where it's REALLY ending up! The answer could shock everyone -- especially the data owner and CISO.
Best of all, DLP could help your organization get through your annual report on compliance much faster than you've been able to in the past.
With data in motion solutions, the incident details are often captured and stored within the DLP database. For example, an email with sensitive data in the body or attachment could be stored.
With data a rest discovery, DLP solutions can often create a pointer to the sensitive information for follow-up.
A key feature of a solid DLP solution is the ability to create and manage remediation. A strong workflow and integration with an organization’s existing case management tools are often both highly desirable.
Occasionally our clients have asked if their DLP solution could be in scope for PCI. If the DLP environment is continuously and regularly storing, processing, or transmitting cardholder data, it is clearly and completely in-scope for PCI. If this is not the situation, work with your assessor.
Recognize DLP tools generally have an ability to intercept and retain many forms of sensitive data, including cardholder data. A bold declaration of the system as being out of scope for PCI or other regulations will offer little comfort in the event of a data breach. DLP offers many choice features that would make it a perfect attack platform for an individual attempting to harm any organization- a risk that should be appropriately managed. If you do not implement reasonable measures inside of your DLP platform such as Role Based Access Controls (RBAC), logging and monitoring, transport encryption, and storage encryption then your DLP solution is introducing significant risk.
I often encourage organizations with DLP to continuously REMOVE their old DLP incidents from the DLP system as they are discovered and as remediation is completed. If you can capture the incident without capturing the cardholder data, DO IT! If you must capture the cardholder data but also can encrypt the information, DO IT!
Take appropriate measures to manage the integrity of the DLP configuration and ensure the information in DLP is part of an EXCEPTIONS process. not a continual situation. Make sure you have the logs to prove this.