HIPAA, PCI DSS and Sarbanes-Oxley (SOX) are well known in information security and business. Despite the fact that the business is aware of these regulations and is willing to support them to avoid sanctions, there still exists a gap when information security professionals and the business must collaborate to ensure compliance. The result is mismatched expectations and frustration.
In part, some of the frustration is justified from the business as many information security professionals will use guidelines from the IT Governance Institute, the National Institute for Standards in Technology (NIST) and ISACA's COBIT as a basis for developing information security frameworks. This results in the business being presented with a framework that is heavily security centric and laden with technology and complex countermeasures as the 'fix' toward compliance. This is of concern for midmarket companies since they are typically focused on improving their long-term competitive stature. In today's market, part of that strategy is the outsourcing of functions which carry a level of risk as the data associated with these functions is sensitive and or confidential in nature. Stringent guidelines, costly technology and complex countermeasures will adversely impact the businesses overall goal of market competitiveness.
Rather than relying solely on the traditional information security guides to build a security framework, consider using one or more of the compliance regulations as a framework. Why? If an organization is already aware that they must meet both SOX and PCI requirements there is already a level of awareness among the stakeholders who must support these requirements. By using a compliance-driven framework, you may be better able to demonstrate how the countermeasures and controls you've been pushing will help the organization support compliance. Let's use PCI as our example.
PCI has 12 requirements that must be met by organizations that process credit card information. These requirements can be fully mapped to the recommendations of a security program as put forth by the IT Governance Institute. The difference between the two is that the PCI requirements are more granular and mention specific actions, technology types and in some cases explicit technology use to reach compliance. The simple presentation of the requirements will be more digestible in a framework that the business must buy into as compared to the broad categories typically seen in information security centric guides.
A pitfall though of the granular presentation of PCI requirements is seen when you realize that some of the traditionally supporting elements of a security program are not present. For instance, requirements 7, 8, 9 and 12 can be easily implemented but poorly supported if an organizations user community is not aware of why these requirements are necessary. PCI does not prescribe security awareness training as a method for supporting the education around the requirements. A similar gap is evident with requirements 1-6 and the lack of an iterative security assessment process to identify any lapses in security posture as a result of configuration changes in technology. Not to be forgotten is the lack of incident management in the PCI standard. Most security practitioners understand that it's not "if" a breach will occur but "when" it occurs you must be prepared to respond. So how may one go about developing and presenting a compliance-based framework without critical gaps?
You can gain efficiency in the creation of your compliance-based framework if you take your existing information security centric framework and overlay it on the compliance-based framework. Keep the information security centric requirements that you have identified as gaps in the compliance-based framework. Finally using a people, processes and technology (PPT) methodology you can merge the two frameworks into one. The result is a framework that is driven by compliance and supported by traditional information security program pieces.
Whether you are creating a program from scratch or adapting an existing program you must be patient as it typically takes at least 2.5 years to see the results of program efforts. Be prepared to fight some of the same battles and introduce new ones.
Ravila Helen White is senior IT security analyst for the Bill & Melinda Gates Foundation.
