In the newest episode of the eIQcast, eIQneworks Product Evangelist John Linkous provides an update on PCI compliance and how far it goes to actually keep credit card data secure.

Running time: 10:38

Direct Link: http://eiqcast.podOmatic.com/entry/2009-10-28T13_09_11-07_00

“eIQnetworks already correlates data from more data sources than any other solution on the market, and for that reason SecureVue is uniquely positioned to identify sophisticated in-progress attacks or vulnerabilities that log-only solutions will miss,” said Vijay Basani, eIQnetworks’ CEO. “With the ComplianceVue packages, eIQ now offers a turnkey solution for comprehensive compliance reporting across a broad range of security data including events, configuration data, vulnerabilities, and network flows, proving again that ‘log data is not enough’ to properly prove adherence to regulatory rules.”

The new ComplianceVue packages include a SecureVue Central Server, and the associated compliance reporting modules and dashboards required to provide necessary documentation for regulatory-driven audits. Reporting is effortless, and section-specific compliance reports are directly linked to appropriate rules and requirements of each supported regulation, best practice, or standard. Interactive dashboards provide real-time views into key compliance metrics, and provide drill-down into underlying data to support comprehensive internal and external auditing needs.

For more details and benefits on the new ComplianceVue package, check out the full press release on the eIQ site: “eIQnetworks Introduces ComplianceVue Packages for PCI, NERC and HIPAA to Streamline Regulatory Compliance Reporting”

The indictment places blame for several high-profile data theft incidents on a small group of individuals who found holes in websites used to transfer the credit card data. Basically, these folks have to be the best hackers out there if they were behind every high profile data breach of the past two years.

In the latest episode of eIQcast, Security and Compliance Evangelist John Linkous reviews the charges, talks about how retailers and consumers can protect themselves, and notes how the crime was carried out by exploiting a well-known (and extremely easy to replicate) web site security weakness.

Running time: 13:30

Direct Link: http://eiqcast.podOmatic.com/entry/2009-08-18T14_31_20-07_00

Even worse, you have some organizations that won’t accept responsibility when something does go wrong. I won’t rehash the discussion here, but Heartland’s CEO Bob Carr stepped on the security industries toes in this interview with CSO by trying to throw his QSA under the bus. That didn’t really sit well with me, so I posted a response (BTW the response is my opinion and my not reflect the views of eIQ – how’s that for a disclaimer?)

Regardless of whether someone is looking to check the box or make the auditor go away, they are delusional. You see, PCI is only the beginning of the process. Hats off to the PCI Security Standards Council that have proscribed a set of practices that will improve security. Any organization in compliance with PCI is in decent shape, but they are far from done.

Let me make sure I’m absolutely clear, COMPLIANCE DOES NOT EQUAL SECURITY. If you have any misconceptions that it does, get up to the white board and write it about a zillion times. Compliance is a lowest common denominator, by definition. A rubber stamp is not going to keep you secure.

The regulations are also moving targets, which is a good thing. As new attacks emerge, they will keep moving the bar for PCI compliance. The updated version (1.2) hit last October, and subsequently there was additional guidance on securing applications and wireless in-store networks. Yet the fact remains, PCI is looking backwards and responding to the issues, but about 2-3 years behind.

For example, PCI 1.2 specifies that retailers can no longer use WEP to protect wireless networks. A few retailers learned that lesson the hard way. But the industry has known WEP has been broken for years.

Let me repeat this again, if you are serious about security, any regulation should be a lowest common denominator to base your security program on. That being said, we all need to spend a lot of time documenting what we do and preparing reports for the auditors. This is tremendously resource intensive and something that can and should be automated.

But that’s another topic for another day. Let’s stay focused on the reality that the technical controls to meet a compliance mandate is a subset of what you need to do to actually protect your organization.

Events in 2009 provide further proof that PCI compliance is not enough to secure credit card information, yet PCI compliance is a major driver of technology purchases each and every day.

If the need-to-have products for PCI compliance are not enough for security, what are the nice-to-have products that can make an enterprise far more secure?

In the latest episode of the eIQcast podcast series, Ross Levanto asks eIQnetworks Product Evangelist John Linkous for his thoughts on the question. In the process, they discuss the features and functionality that IT and security teams can investigate as part of PCI compliance projects to greatly enhance the security of their systems.

Running time: 8:59

Direct Link: http://eiqcast.podomatic.com/entry/2009-06-05T07_07_13-07_00

In the latest episode of eIQcast, Ross Levanto asks eIQnetworks Product Evangelist John Linkous about Visa’s claims. They review how companies can move toward the unattainable continuous compliance goal, and they provide tips on certain effective data security strategies not specifically mandated by the PCI rules.

Running time: 11:08

Direct Link: http://eiqcast.podOmatic.com/entry/2009-04-06T11_42_21-07_00

Now the folks from Visa are out there working to clarify what they meant and what needs to change as PCI evolves. An interview on bankinfosecurity.com with Visa’s Deputy something or other, Adrian Phillips, goes a long way towards clarifying the hypocrisy. Basically, Visa’s idea now is that compliance is NOT a point in time, but needs to be assessed on a continuous basis.

Just as other industry standards, such as accounting, are amended and changed over time, Phillips says PCI requirements must evolve as well. “The principal area we must focus on is the need for continuous monitoring for compliance,” he says. “I think that people have been confusing the message. People are saying ‘I have been found compliant,’ when in fact they were found compliant on that one point in time when the assessment was done.”

First of all, this is a step in the right direction – should it happen. Obviously we live in a dynamic world. There are new attacks daily. There are new devices moved, added, and changed daily. There are new applications rolled out or decommissioned or updated, that’s right – daily. So the idea that anyone found “compliant” on March 24 would still be “compliant” on September 25 is not a good assumption.

But, as you’d expect, I have some issues with this concept. First of all, the compliance game is based upon a periodic audit. Maybe it’s every quarter, maybe every year. But it’s not like anyone is going to audit on a continuous basis. Even internal audit staffs focus on certain aspects of the systems for a certain period of time, to the exclusion of other systems. So there will always be a certain measure of statistical “assumption” made to say an organization is compliant.

More importantly, no organization can staff up for continuous assessment. They’d need more people than systems, applications, and devices. It may solve the global unemployment problem, but probably isn’t going to help the profit situation for most large companies. So obviously organizations are going to need a large dose of automation to stay on top of these regulations on a continuous basis. They’ll need to assess the technical and qualitative controls and be able to pull reports at any point in time to substantiate their real time security and compliance posture.

Which is great news for anyone in the business of aggregating security data and reporting on technical and qualitative controls. Ahem… like eIQ…

Unfortunately Visa and MasterCard are making all of us play the same game of late. There have been recent rumors running rampant (alliteration anyone?) about another data breach of a credit card processor (coverage: SCMag, Dark Reading). Allegedly on the scale of Heartland and that is bothersome. Especially when we can’t get any information from the banks or payment card brands. So we are forced to call is “Breach X” for the time being.

So in the absence of any real data, what can we do to make sure nothing is compromised? Let’s take two paths, the first is for you personally (and your employees) and the other is for your company.

Personal Protection Plan

There is a high likelihood that your credit card data has been compromised as a result of either Heartland or Breach X. If you are lucky, then your bank will just issue another card and you’ll need to go change all your numbers and update all your e-commerce sites and the like. It’s a hassle, but it’s not that big a deal.

If you aren’t lucky, they won’t and you’ll have a compromised card on the street. That’s why you should be monitoring your personal credit accounts on a daily basis. Each of your credit card companies have a web site and you can log in daily and check the recent transactions. This is a great habit to get into.

By the way, as a “value add” the corporate security team can do training for employees on things like identity theft and private data protection. These kinds of tips may come second nature to you (as a security professional), but certainly not to the rank and file. You can win a lot of credibility points internally by turning these massive breaches into an educational opportunity.

Corporate Protection Plan

If you accept credit cards, data being stolen from a payment process isn’t your problem, right? In the strict sense, yes – but that is a pretty myopic view.

We need to learn about these attack vectors and make sure that it’s not going to happen to us. That means we probably want to start monitoring (or even blocking) unauthorized outbound connections. Rich Mogull has a great post on that.

You probably want to monitor your network traffic as another layer of defense, and also your systems to ensure malware or unauthorized configuration changes haven’t been made.

And most of all, you need to call your issuing bank and yell at them. It’s unacceptable that Visa and Mastercard have been sitting on this breach because the payment processor can’t get their act together. Whoever Breach X happened to should be out of business this time next week.

Yes, that’s harsh, but in this kind of environment, when customer trust is at an all time low and people are struggling – to not come clean and come clean quickly is just ridiculous. There is nothing like a public execution to keep everyone focused on doing the right thing in the event of a breach.

Now will the real [Breach X] please stand up?

Running time: 10:57

Direct Link: http://eiqcast.podomatic.com/player/web/2009-01-23T05_35_33-08_00

So what do we know? We know that Heartland WAS PCI compliant. At least that is their story. They passed their assessment back in April. Not sure how many more times folks have to learn the hard way that compliance DOES NOT equal security. As with the Hannaford Brothers breach last year, this is yet another data point that PCI is a good start, but by no means sufficient to ensure the safety of credit card data.

In terms of the attack, it’s also very similar to Hannaford. The network was breached via the firewall and then a number of servers were compromised on the internal payment network. The attackers loaded up sniffers (where Hannaford’s seemed to be based on key loggers) to snoop the payment traffic on the network. But the concept of the attack was the same.

PCI compliance is no defense against this kind of attack. At least how the PCI-DSS is written now. Logging data (requirement 10) is not going to catch this attack because the firewall was breached (which means the traffic was allowed) and the malware (key logger or sniffer) was installed on a set of devices.

The fact that Heartland was compromised is not the real point. The issue is how to make sure this doesn’t happen again. And not to you. Based on what we know of the attack, there were a number of points where the attack could have been detected.

Of course, since we are in the business of security and compliance management, I’ll feel free to illustrate the importance of looking at a broader data set than just syslog by discussing how SecureVue would have alerted to this attack in NUMEROUS ways.

1. The malware was installed on a number of devices, which means the configuration was changed in some way shape or form. SecureVue tracks configuration data and report on changes that don’t adhere to the baseline policy.
2. Key loggers and sniffers are very resource intensive, so the compromised devices would have displayed significant performance anomalies. SecureVue monitors performance characteristics of the devices, so the administrators would have been alerted to these issues.
3. The malware was some kind of executable, and SecureVue’s asset management capabilities track executables on managed devices, so the attack would have caught that way as well.
4. Finally, the attackers can’t monetize the stolen credit card data until they send the data outside of the network for mining, so our network flow analysis would have alerted us to the fact that a strange traffic flow was being sent from those devices to a site outside of the network.

Clearly LOG DATA IS NOT ENOUGH, especially since these folks were PCI compliant (or so it seems). It goes back to my ages old mantra that compliance DOES NOT equal security. Traditional SIEM and Log management products do not look at this broad array of data and thus cannot detect this specific attack. If you are not monitoring configuration, asset, performance, and flow data in addition to logs, you are exposed. I

To be clear, there is no guarantee any of these different data types alone would have pinpointed the attack. But if you combine all of these TOGETHER, and correlate across all of these different data types it’s clear that SecureVue would have detected something that needed to be investigated and in many cases, help a savvy administrator prioritize the areas to investigate.

Unfortunately, this won’t be the last time we hear of a successful attack on PCI compliant organizations. Leading organizations won’t wait until they are compromised to put in place a broader and more effective monitoring environment.