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”

We can thank PCI for that. At least partially. PCI specifically calls out the need for log aggregation and analysis (Requirement 10) and of course, most customers are just looking for something to check the box and make the compliance issues go away. Log management can do that to a point.

But the next tact I take with these end users is to ask whether they have confused compliance with security. Most (when questioned) don’t fall into the trap of thinking that just because they are compliant, that they are secure. But those same folks tend to accept investing just enough to be compliant, and don’t push to actually protect their data.

And that’s why we continue to see high profile data breaches from these organizations that are “compliant.” Remember, being compliant on Tuesday doesn’t matter, if an organization is compromised on Wednesday. There are lots of precedents that say the regulators will determine the organization is not “compliant,” based on the fact that a compromise occurred. Yes, that stinks, but it’s fact. Deal with it.

So given that we can all acknowledge that compliance doesn’t equal security. And most end users do want to be secure. That they need to push beyond just simple log management and move toward security management. And the vendor community has evolved their offerings along those lines as well.

This need for both security and compliance has driven for convergence of previously separate technologies (security information and event management (SIEM) and log management) coming together. And now most vendors have solutions to address both problems. Of course, we can (and do) debate about what integration really means, which we wrote about recently on eIQviews.

The market only recently figured out that SIEM and log management really need to be integrated, but we at eIQ also believe in the near future we’ll see configuration assessment (the definition and enforcement of standard configurations for computing devices) become part of this security and compliance management platform as well. But, eIQ is ahead of the market requirements on that right now, so we’ll need to keep evangelizing the logic of continuing to integrate more functions into a common platform.

To wrap up this piece, just being compliant isn’t enough, and we know most organizations are looking for a combined platform to do both SIEM and log management. Yet, all of these converged solutions continue to use mostly log data for its analysis. As you know, eIQ knows that “log data is not enough” and the next set of posts in this series will talk about 10 reasons why.

Stay tuned.

Not a good day to be busted!

This past Monday the U.S. Justice Department charged 28 year-old Albert Gonzalez with a series of crimes that resulted in the theft of more than 130 million credit and debit card numbers from late 2006 to early 2008.

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

Don’t be like Dick and check out eIQ’s video at logdataisnotenough.com

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

Don’t be like Dick and check out eIQ’s video at logdataisnotenough.com

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…

In the latest episode of eIQcast, host Ross Levanto interviews eIQnetworks Product Evangelist John Linkous, who discusses how the credit card information was reportedly stolen, whether this is evidence of a new trend, and how future incidents of this type may be prevented.

Running time: 10:21

Direct Link: http://eiqcast.podOmatic.com/entry/2009-02-27T07_37_01-08_00

Photo Credit: “Murder mystery dinner crime scene” originally uploaded by robinsan

Ah, the Heartland breach continues to generate opportunities for us to get on the soapbox and talk about PCI compliance vs. security. The latest to appear is at Retail Info Systems News. Here is a little snippet (so I can make Anton a bit more crazy today).

“The message coming from the Heartland Payment Systems Breach is loud and clear. It’s reinforcement of what seemed to be evident from the Hannaford Bros. breach last year. PCI is not enough. Merchants have been relying on PCI as a crutch. Comply with the 12 requirements and credit card data is secure.

Of course, anyone that has been in the security business for a while knows the folly of thinking that any set of requirements and controls will truly create security. Throughout my 20 years in the industry, that just hasn’t been the case. Attackers are good and getting better. They are launching innovative attacks and rendering our defenses moot.

To be clear, there is value in the 12 requirements set forth by the PCI Security Standards Council. The PCI-DSS does a good job of laying the foundation for security, but just like you don’t live just on a foundation and expect to stay warm and dry in the winter, you can’t just rely on your security foundation for protection.”

You can check out the entire piece on the RIS site.

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.