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…

Fortunately, some standards and frameworks for managing security are really starting to mature, to the point where they can become a starting point for building risk-driven common controls that easily map to regulations and other compliance drivers. Most of these frameworks and standards have been around for a number of years but through a combination of broad adoption, continuous feedback from adopters, and a mature management and improvement process, they are rapidly becoming a great starting point for building comprehensive information security. Here are three that I believe are well-balanced (addressing both technical and logical controls), risk-based (where the implementation of some or all controls is based on an analysis of risk to systems and data), and can be implemented across any industry:

• · PCI Security Council (PCI) Data Security Standard (DSS) 2.0 – Recently released, the 2.0 version of the PCI-DSS standard focuses on a solid combination of static, pre-defined technical controls (e.g., minimum password lengths and complexity requirements), risk-based technical controls (e.g., business continuity infrastructure), and logical controls (e.g., written policies and procedures, and separation of duty). Although designed specifically for securing chain of custody around credit card data, PCI-DSS is rapidly becoming a standard of controls that organizations are applying to different types of data.
• · ISACA Control Objectives for Information Technology (COBIT) 4.1 – The COBIT framework has long been a framework for managing information security. With a focus on processes – not just technology – COBIT has become the standard high-level framework used by global auditing firms to audit against compliance with SOX Sections 302/404, J-SOX, and other major financial regulations that address financial controls. Like other frameworks, COBIT is relatively light on technical controls (although there are some specific technical controls defined for applications, such as event auditing and monitoring); instead, the goal of COBIT is to provide a framework for using risk-based decisions to build and maintain a complete IT management program.
• · International Standards Organization (IS) 27002:2005 – One of many IT-related best practice documents issued by ISO, ISO27002 (formerly known as ISO17799) is geared toward helping an organization establish risk-based decisions to build and maintain a security program. Unlike COBIT, which is focused on general IT controls, ISO27002 focuses very squarely on information security. Being part of the ISO family, ISO27002 is augmented with additional ISO-delivered guidance to help certain verticals – healthcare and financial services, for example – implement specific controls that are not only ISO27002 compatible, but compatible with other industry-specific laws and guidance.