Ultimately, most compliance mandates – PCI DSS, HIPAA, SOX, GLBA, and others – are about protecting one type of data, not necessarily all business data, or all aspects of the systems that store, transmit and process.  In some cases, the target is credit and debit card data (PCI DSS), protected healthcare information (HIPAA), or consumer data (GLBA).  In other cases, it’s a specific type of data, such as financial reports (SOX), and only one aspect of that data (in the case of SOX, integrity of the data… not so much confidentiality or availability).

Regardless of the regulation, their goal is to function as a starting point for a security program that minimally meets their requirements, but is further augmented with additional policies, standards, procedures and controls to protect all valuable assets within the organization.  In order to protect sensitive data from either internal or external threats, it’s important that systems and processes are developed to achieve not only these minimum regulatory requirements, but the additional objectives that make a full-blown security program – which is actually much is harder than it sounds.  Proving either can also be a real challenge for many organizations.

From a compliance perspective, you “can check all of the boxes” to demonstrate that you’re meeting a regulatory standard, but that doesn’t mean that your entire infrastructure is secure.  Take Stuxnet, for example, which targeted the industrial software running on Siemens PLCs (programmable logic controllers).  While energy-related organizations could comply with all of the necessary network security regulations relating to their industrial systems (such as the NERC CIP standards), that won’t stop a Stuxnet-style attack that enters the infrastructure via another part of the network that slowly – but surely – makes its way to its intended target.  In the case of Stuxnet, it was Siemens PLC units.

Ensuring information security and regulatory compliance isn’t easy.  It often requires different data sets to be analyzed and recorded – creating additional work for already stretched information security professionals.  Fortunately, there are some basic, overlapping components to many regulations that also happen to be fundamental aspects of good security practices:

• Visibility into all security-related data (not just one type of data, like logs/events)
• Correlation of data to determine when bad things are happening
• Demonstration of improvement in compliance and security posture over time
• Quantitative risk monitoring to identify systems that are at-risk
• Easy reporting to demonstrate both compliance and network security

Wouldn’t it be nice if there was a way to capture all your network security data from across an entire Enterprise network in real time and report against different subsets – not just from today, but yesterday… or last week… or perhaps last month in order to evidence network security or compliance with regulatory mandates?

Somebody ought to develop a platform like that…

Perhaps the most glaring solution, and one promoted as critical by all three of our panelists, is the need for better security education and awareness training.  According to Theresa Payton, “CBTs [computer-based training] are not going to cut it – people just go through and click, without really thinking about security after the CBT is over.”  The consensus across the panel is that real security awareness involves concretely demonstrating how security threats can be realized by bad user behavior, through hands-on examples.  If people actually see how the can be exploited – and the ramifications of it – they’re much less likely to exhibit insecure behaviors.

Another critical requirement is for organizations to focus on end points; configuration security is absolutely critical to ensuring this, whether the end point is a server, desktop, laptop, or mobile device.  As John Pescatore of Gartner pointed out, over 65% of successful attacks are enabled due to security misconfiguration; poorly configured security gives attackers and malware carte blanche into your systems.

Finally, the third critical tool is appropriate authentication and authorization.  From multi-factor authentication, to role-based access control and ensuring that employees and contractors are granted security access based on the concept of least privilege, these two mechanisms can prove invaluable to mitigating the risks posed by today’s most pervasive threats.

I’d like to thank all three of my panelists at this year’s FedSMC event — former White House CIO Theresa Payton, former Army G-6 CIO Vernon Bettencourt, and NIST Distinguished Scientist Dr. Ron Ross – for their fantastic insight!

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.

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

Running time: 9:53

Direct Link: http://eiqcast.podOmatic.com/entry/2009-04-22T07_45_10-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