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…

Security professionals are not driving the ship. The business folks are. So security folks that are resistant to the ebbs and flows of business will not be successful. We have to face the reality that we (as security professionals) need to adapt our defenses both to the actions of our adversaries, as well as the reality of our businesses. Budgets come and go, projects are re-scoped, and priorities change. That’s business. That’s life. Deal with it.

But you cannot adapt in a vacuum. In order to react quickly (which sounds very similar to my personal REACT FASTER mantra), an organization needs to understand what they are looking for. That means they need to be monitoring as much as they can, establishing what is “normal” in their environment and then watching for what is NOT normal. Things change all the time, but if you don’t know HOW they are changing, there is no way you’ll be able to understand WHY things have changed, and therefore you’ve got no shot to address the issue…before it’s too late.

Oh yeah, did I mention I’m a big fan of security monitoring?

“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”

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.

First is the concept of knowing what you don’t know, and that’s pretty much about finding the data that is protected and/or private and then tracking access and authorizations for that information. Don’t minimize the amount of work involved in this step. Whether you want to call it “data governance” or anything else, this step has killed many a compliance effort, as well as most of the stand-alone DLP market. But that’s another story for another day.

Second he dives into identity management, since that both enables the tracking of who does what, and also provides the ability to turn up or shut down access quickly and in an automated fashion. Since most organizations are pretty dynamic by nature (meaning people come and go, and customers come and go, and pretty much everything else comes and goes at different times), it’s hard to see how any organization can really substantiate compliance if they don’t have some level of automation underlying their identity infrastructure. This is another good topic, but not what caught my eye about this article.

What I want to focus on is his discussion of “state management,” which is basically configuration and vulnerability management. Though I buy into his idea of this being the third aspect of compliance automation, I think from a security operations standpoint – it’s as important (if not more important) to get this nailed PRIOR to large scale identity projects. Yes, this is part religion and part philosophy, but I still get back to the issue that anecdotally a lot more data is lost because of less than secure configurations and the inability to patch against known exploit code, than provisioning or deprovisioning issues.

I know, I know, compliance REQUIRES that you know who is accessing what and when. And that gets back to one of Richard’s points relative to doing what’s right for security vs. being forced to do what will get the auditor off your back.

Requirements like PCI pretty much require both state and identity management, but there is a lot of variability in what that really means. So, again it gets back to doing what’s right for your business, documenting the policies and being prepared and able to defend them when the auditor challenges you.

And they will. So be ready.

Running time: 10:46

Direct Link: http://eiqcast.podomatic.com/entry/2009-06-11T14_33_26-07_00

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…