This is page 2 of:
PCI Compliance Is Good; Data Security Is Better
If restricting access sounds too difficult, can you implement consequences for what I call bad (or at least thoughtless) behavior? Some companies have a policy that states if an employee damages a company vehicle, they lose the right to use a company car for some period of time.
Following that same line of thinking, why can’t an employee who repeatedly needs to have his laptop re-imaged to remove malware or inappropriate content face a similar restriction?
I know one organization that produces a list of repeat offenders and sends it to both each division head and the COO to raise the visibility of the problem. From what I have seen, you do not want to be an employee–or the division head with such an employee–on that list.
We have to accept the fact that the deck is stacked against retailers achieving perfect security. As the CIO you have to be right all the time, while the bad guys only have to be right once to compromise your systems. Accepting that difficult truth means security needs to go beyond compliance and protect the data and applications as they move around inside your network perimeter. PCI addresses data at rest (Requirement 3) and data you transmit (Requirement 4).
Going beyond these compliance requirements and encrypting or tokenizing your cardholder data or any personally identifiable information (PII) as it moves through your network can increase security. These approaches cost money, and they are not necessarily easy to implement.
It will be interesting to see if internal network breaches become a more common attack vector and how the PCI Council will respond. Someday, protecting data in transit over your internal network may make it into the PCI standard. Until then, such protection is a good extra step that can increase your security.
Nothing in PCI protects retailers against a determined malicious insider or a serious business process failure. If your organization is victimized, a Data Loss Prevention (DLP) or other tool with similar functionality (e.g., a firewall that inspects outgoing packet contents) can stop the worst from happening by blocking your valuable data from leaving.
PCI Requirement 1.2.1 tells you to restrict inbound and outbound traffic to just what is necessary, but DLP goes further. DLP can be difficult to implement. Once it is in place, it can monitor and protect data in storage and as it moves through your network.
Again, something like DLP might someday make it into the PCI requirements. And just because it isn’t there now does not mean it isn’t a good idea to explore, especially if your focus is security and not just compliance.
PCI compliance requires, among other things, that you know where your cardholder data is stored, understand how that data is used and manage the partners with whom you share it. Data security requires you to go further and take responsibility for your users, protect the data in transit and at rest, and prevent the data from leaving your network without your knowing about it.
To the maxim “validation does not equal compliance,” we now add “and compliance does not equal security.” Then, as a professor of mine used to say, we get to the exercises for advanced pupils: “and there is no such thing as 100 percent security.”
What do you think? Have you tried to limit employee Web access? Do you protect data in transit over your internal network? Have you looked at DLP or similar approaches to stop data from leaving your environment? I’d like to hear about your experiences. Either leave a comment or E-mail me at wconway@403labs.com.
-Marc
April 7th, 2010 at 3:19 pm
Walt,
Very well written. One of the biggest challenges that I face is the concept that my executives and my franchisees believe that being compliant is the goal, rather than being secure. When justifying the costs of “security”, the response is WIFM? The answer, a poor one, is “That we hope to protect you from a fate similar to so-and-so”. It’s never a good argument when you use “hope” and “them” in a justification.
I’m tired of the standards being so broad. It’s time that the council set out very specific standards about what needs to be implemented and how. No more of this, “If you have this, than prove to me it doesn’t do that”.
For all the griping that people did about the MA data privacy law, it resulted in action. “You must implement intrusion detection systems” is far more concrete than “You must protect card holder data.”
April 7th, 2010 at 3:44 pm
Walt, great article. I agree with your professor: Validation doesn’t equal compliance, and compliance doesn’t equal security. And of course,there is no such a thing as 100% security.
Compliance should be the starting point, not your end goal. Even as more organizations are shifting their thinking to more security, they know that data breaches are bound to happen. That’s why it’s important to act quickly once they’ve discovered that a breach has happened. Stop the bleeding as fast as you can to avoid it becoming a bigger problem.
PCI DSS is one of the most prescriptive standards, which provides very specific guidance for how to protect cardholder data. The intent of the standards is NOT to make organizations comply with it, but rather to create a more secure environment where sensitive data can be protected.
Thanks for sharing your insights.
April 7th, 2010 at 7:44 pm
@Todd,
Thanks for the comment. The specificity of, say, the MA privacy law you cited is great today, but what if a new, better, cheaper, easier technology comes along tomorrow? Do we change the law? By specifying the objective, PCI (and the Council) stays agnostic on any particular technology and allows merchants to meet the goal in whatever ways fit their business model and budget. I’d hate to see PCI without the option of compensating controls, for example. Unfortunately, we’ll probably never reach that perfect balance between specificity and flexibility.
@ Cindy,
Thanks for your comment an the kind words. We agree on the need to act quickly in a breach situation. The unfortunate reality is that most of the time the merchant only finds out they’ve been breached when a card brand or their acquirer calls them with the bad news. Yet more reason to go those extra steps from compliance to security.
April 15th, 2010 at 7:50 pm
I love this paragraph – “PCI compliance requires, among other things, that you know where your cardholder data is stored, understand how that data is used and manage the partners with whom you share it. Data security requires you to go further and take responsibility for your users, protect the data in transit and at rest, and prevent the data from leaving your network without your knowing about it.”
I am sure many readers here know this, but the cardholder data is effectively “in-the-clear” on the approximately 2.7 billion payment cards. It is encoded data, not encrypted data. So it’s the merchant’s responsibility to protect that data? That is a sad joke and it’s unfortunate the issuers are getting away with it.
If protecting the data helps us all sleep better, then great! Does it really stop the fraud? Not one bit. As long as the data is “in-the-clear”, the bad guys can and will get it. They will only stop trying to steal the data when it has NO more value and they can’t use the data to make counterfeit cards. Adding Encryption + Tokenization + Authentication + Dynamic payment card data will make it much more difficult for the bad guys to commit fraud and it’s the fraud that costs billions each year. Protecting the data without authentication will not stop fraud, so where is the ROI on security if the fraud and chargebacks do not go away?