Designing Common Control Frameworks: A Model for Evaluating Information Technology Governance, Risk, and Compliance (IT GRC) Control Rationalization Strategies Lance Hayden, Ph.D. Cisco Systems, Inc.
[email protected] This paper is an updated version of a paper published in Information Security Journal: A Global Perspective, Volume 18, pp. 297-305, 2009. Bio: Lance Hayden has nearly two decades of experience in the information security field, holding positions in the public and private sectors, as well as academia. He began his career as an intelligence officer with the Central Intelligence Agency and has spent the past decade in various security roles at Cisco Systems. Lance holds a Ph.D. in Information Science from the University of Texas where he also teaches on the topics of security informatics, privacy, and surveillance. Lance’s current professional work involves the design of governance, risk, and compliance (GRC) solutions for large companies, including research and development into the most effective ways to rationalize and implement security controls in order to improve efficiency and reduce costs involved with organizational compliance efforts. Introduction The current information technology (IT) security environment is more challenging than ever. Recent high-profile security breaches have resulted in governments, standards bodies, and industry groups taking it upon themselves to begin mandating requirements for security that mirror controls found in corporate and IT governance, risk, and compliance (GRC) activities (ControlPath, 2006). In addition to traditional security risks including vulnerabilities, disruptive technologies, and distributed workforces, IT security programs are thus faced with increasing regulatory and compliance scrutiny (Calder & Watkins, 2006). Many of the resulting control frameworks are developed in parallel with enforcement regimes that ensure the compliance requirements actually have “teeth” in that organizations can be held accountable for not meeting their obligations (DeLuccia, 2008; Tipton & Krause, 2007)).
In the United States, the Sarbanes-Oxley Act (SOX) and the Health Insurance Portability and Accountability Act (HIPAA) represent government mandated compliance requirements for publicly traded companies and organizations acting as custodians of personal healthcare information, respectively. Globally, there exist numerous similar compliance regimes that require the protection of data and the systems that process it, including the European Union’s Data Protection Directive and a variety of country specific data protection laws. Formal international standards such as ISO 27001, as well as de facto standards such as Control Objectives for related and Information Technology (COBIT®) define best practices for implementing IT security programs and are used widely by auditors for assessing IT and security controls (Gazaway, 2007). Some industries have seen the need to develop their own security compliance requirements to protect data, creating frameworks applicable to the unique needs of the industry, including the Payment Card Industry’s Data Security Standard (PCI DSS) for the credit card industry (Virtue, 2009), and the HITRUST framework for the healthcare industry (Kaplan, 2009). Empirical research has shown a correlation between effective corporate and IT GRC and tangible benefits including increased revenue, profits, and customer retention (IT Policy Compliance Group, 2008). Add these benefits to the potential consequences of poor compliance, including loss of certification, fines, and even criminal charges, and predictions are that IT security will continue to move towards mandated, standardized control frameworks as a baseline for security activities (Brewer, 2006). Challenges for security managers seeking to comply with mandated control frameworks can also be formidable, and can include functional and organizational separation between corporate
(and even IT) compliance and information security responsibilities as well as the requirement for additional resources and skills that may not be present within existing IT security organizations. Such obstacles to compliance are compounded when one considers the number of separate control frameworks for which a single organization may be responsible. To maximize the effectiveness of compliance efforts in these situations it becomes desirable to analyze and map together separate control frameworks in such a way as to more efficiently and holistically address all necessary control requirements with minimal effort and overlap, thus preserving resources and developing a more comprehensive security compliance program that addresses a variety of different frameworks. This article discusses the alignment of different security control frameworks and three associated control mapping strategies that are commonly used today: normative mapping, transitive mapping, and granular mapping. The benefits and limitations of each mapping strategy will be discussed, and all three strategies will be illustrated through the use of a case study organization facing the security compliance challenges outlined above. The purpose of the proposed evaluative model is to provide security managers with a tool by which to assess the potential effectiveness of control mapping strategies, whether they are considering implementing such control mapping internally as part of a compliance program or considering purchasing this capability from a third party product or services vendor. The evaluative model discussed in this article grew out of a year-long research project conducted by a professional services organization into the process of control rationalization, the benefits of particular mapping strategies, and the methods by which
such rationalization was incorporated into security and GRC products and consulting services. The immediate requirement for the research was to gain the knowledge, skills, and tools required to launch a new professional service offering specifically addressed at customers who required assistance in standardizing security activities across several different regulatory frameworks. The project was not academic, but rather a practical attempt to solve a defined business problem in support of an organizational goal. A team of consultants conducted the research, and was also responsible for creating and delivering the service offering. Supporting the team’s efforts were an extended group of vendors, customers, and industry and academic researchers on whom the consulting team depended for knowledge, skills, tools, and literature. Given this structure, the project conformed to a participatory design methodology in which different stakeholders such as users, vendors, and researchers work together to create understanding, shared practices, and products or systems (Muller, 2008). Participatory design is a broad field, emerging from action research studies conducted in Scandinavia in the 1970’s that attempted to bring workers into the system design processes of their organizations and to enable both to benefit from that collaboration (Bødker, 1996).
The Challenge of Compliance in a Multi-Framework Environment A central challenge for organizations seeking to unify or streamline their compliance requirements into a single, more efficient activity is how the organization will address different requirements, in the form of specific controls within a framework or standard. The term control typically refers to an internal control, which is a process or
method by which organizations regulate their own activities to achieve specific objectives or accomplish their mission (Anand, 2006; Silverman, 2008). Controls may refer to policies, processes, or technologies that are put in place to govern organizational functions, including security management. Controls can include requirements that a company document management support of technology implementations, that an organization creates acceptable use policies for company assets, or that specific configurations or security safeguards be in place for computers or other networked devices. Control frameworks are logical structures that organize individual controls into integrated sets of activities (policies and procedures) and artifacts (documentation and technologies) that enable an organization to effectively achieve its goals (Network Frontiers LLC, 2008). Many different controls exist, and are specified in a variety of frameworks ranging from government regulations to industry or organizational best practices including those discussed previously. An interesting characteristic of controls and control frameworks, particularly as they apply to information security, is the overlap between the control requirements mandated by a given set of frameworks. Control frameworks that support information security are designed to reflect best practices for safeguarding systems and data that are under the custodianship of the covered entity. But certain best practices for security are well known and documented, and an examination of the various frameworks available quickly reveals that the methods, processes, and technologies mandated by a particular framework are often replicated in some form within other information security control requirements. Differences in language, however, can result in different controls even when the overall requirements of those controls are very closely aligned. Some
frameworks are more specific in their mandated safeguards, prescribing targets of protection, safeguard processes, and necessary technologies in great detail while others assign general security requirements and leave implementation to the responsible entity. Similarly, some frameworks are much more technologically focused while others concentrate primarily on process or policy safeguards. The end result is often duplication of effort and redundant controls that may or may not prove equivalent in the event of an audit. As organizations grow and expand into new markets or geographic territories, then number of control frameworks to which they can be subject also increases, driving a need to manage compliance across the entire organization. But in order to manage compliance in this way, some organizations develop a need or desire to produce a common set of activities and safeguards that can be adopted universally while still meeting the needs of all the original, “authority” frameworks and the individual controls contained within them. To meet this challenge many compliance and security vendors have begun to adopt various forms of control rationalization, in which controls from one framework are analyzed and then mapped or cross-referenced to controls in a completely different framework. Rationalized controls are not a new concept (Deloitte & Touche LLP, 2005). But the sudden intersection of security management and GRC efforts that has occurred in recent years has served bring rationalized control frameworks out of the more specialized fields of audit and accounting and into the daily activities of IT directors, security managers, and everyday users.
An Evaluative Model for Control Rationalization An important result of the research project was an understanding of current state of the art regarding how control frameworks are rationalized and mapped or crossreferenced. These mapping activities are used by organizations internally to support the creation of a “common controls framework” (CCF) that can be used as the basis of a unified security program or to support audit preparation among organizational entities attempting to achieve compliance. For organizations that see the task of control rationalization as too complex or resource intensive, the mapping analysis can be outsourced to consultants or technology vendors who provide solutions that meet specific customer needs. Rationalization strategies vary, however, and not every strategy is suitable for an organization’s needs. It therefore becomes very important from a compliance perspective, particularly if an organization is undergoing formal audits against standards or regulations, that the organization chooses an appropriate rationalized control methodology or tool. Choosing inappropriately can result in consequences that range from not achieving the desired efficiency from the streamlined control sets at best, to failing audits and suffering the resulting financial or legal consequences. The evaluative model proposed here identifies three primary control rationalization strategies: normative mapping, transitive mapping, and granular mapping. Each mapping strategy brings benefits as well as costs, and can be interpreted as existing along a continuum. The most effective strategy for organizations with compliance requirements, or vendors of compliance solutions, to employ is contingent upon a number of factors including the number of control frameworks and controls to be rationalized, the
resources available for analysis and mapping between control frameworks, and the importance of equivalence between specific controls for the purposes of audits and standardized security programs. Table 1 summarizes the three mapping strategies.
Table 1 – Summary of Mapping Strategies Normative Benefits
• • •
Limitations
•
• •
Transitive
Moderately comprehensive Maximum customization Effective for large sets of frameworks
•
Requires “meta” control framework and new control language Control language must be interpreted Analytically intensive
•
• •
•
•
Granular
Less resource intensive Preserves original control language Allows for prioritization of a single framework
•
Minimally comprehensive Equivalence problems are common (“false positive” mappings) Unidentified relationships are common (“false negative” mappings)
•
• •
•
Highly comprehensive (“1 to 1”) Preserves original control language Effective for small sets of frameworks Too complex and confusing for large sets of frameworks Resource requirements rise exponentially with each added framework
Case Study: ACME Healthcare The evaluative model of control mapping strategies will be illustrated through the case of ACME Healthcare Incorporated, a regional provider of healthcare services and primary care clinics in the Midwestern United States. As a public company in the U.S.,
dealing with healthcare information on patients and accepting credit cards at its clinics, ACME is required to adhere to several compliance frameworks including the SOX and HIPAA regulations, and PCI DSS. For clarity of demonstration, mapped controls will be limited to the requirement to conduct a risk assessment and the requirement to implement anti-malware protection.
Normative Control Mapping The first mapping strategy discussed here is normative mapping, meaning that all control frameworks to be rationalized are analyzed and cross-referenced into a new, separate framework of controls that has been developed specifically for that purpose. This “meta” framework contains controls that have been written to incorporate the requirements of several different frameworks into a common language. The purpose of normative mapping is to identify and eliminate the redundancy of multiple control frameworks by creating a master set of controls to which all others are referenced. In the case of ACME Healthcare, this means developing a single common control framework across the enterprise that suitably addresses specific required controls, reducing the need for separate efforts that may create silos of compliance. Figure 1 shows an example of such a mapping, in which HIPAA, PCI DSS, and SOX control requirements are mapped into normative controls requiring that ACME conduct a formal risk assessment and implement anti-malware controls. Specific controls from the three frameworks are then mapped against these meta-controls, which have been constructed with language that incorporates all sub-requirements. ACME will then work towards compliance with the
normative framework, confident that the normative controls address the requirements of all mapped sub-frameworks.
Figure 1: ACME Healthcare Inc. – Normative Control Mapping
Benefits of Normative Control Mapping Normative mapping allows an organization to design and implement a new “meta” control framework that incorporates and meets the requirements of the various separate control frameworks to which it must comply. In Figure 1, ACME constructs new controls for “Formal Risk Assessment” and “Anti-malware” that fully address the control requirements of HIPAA and PCI for these activities. Normative mapping provides room for interpretation as well, which ACME utilizes in its treatment of SOX Section 404. Section 404 is a very general control statement, but can be interpreted as requiring both risk assessment and technical controls. Normative mapping allows ACME to incorporate these requirements in a way that best suits the needs of the organization. As the number of frameworks and the mandated controls within each framework increase, normative mapping can create significant improvements in efficiency and standardization across the organization’s compliance efforts, while ensuring that all necessary control requirements continue to be met.
Our research found that properly conducted normative mapping provided a great deal of comprehensiveness, eliminating redundancy in controls while still meeting equivalence requirements between frameworks. Normative mapping allowed for maximum customization in controls rationalization, but remained workable and efficient even when used with large numbers of control frameworks.
Limitations of Normative Control Mapping One important limitation of normative mapping derives from the characteristic that also gives it strength, namely the employment of new language to describe controls. Control frameworks, particularly those against which an organization can or must audit to achieve compliance, are necessarily strict in the interpretation of those controls. For frameworks that allow the responsible entity more flexibility in implementing the specifics of the control requirement, this requires documentation on the part of the entity to explain why a particular method, process, or technology meets the required safeguard. For frameworks with detailed control requirements the interpretation of specific language can be very strict indeed, with an auditor seeking to evaluate a control only against the interpretive environment of the authority framework. In these cases, an auditor may see the differing language of the normative control framework as an unacceptable basis for formal evaluation. Put more directly, some auditors may be looking for a specific control, encompassed in specific and expected language. Should that language not be present, the auditor will not evaluate the control as present either. A related challenge to normative control mapping, also rooted in the language of the controls, comes from the process of developing a new control that will successfully
incorporate the requirements of a variety of related controls. One critique that developed during the course of our design research was that it often became necessary either to use more abstract language to describe a control requirement or else to broaden the scope of a normative control to accommodate multiple use cases and degrees of specificity. In this way, normative controls can “bloat” to become quite large in order to satisfy the disparate requirements and caveats of the controls that map into them. This in turn makes the normative control more complex both to articulate and to implement. We found that the general solution to these limitations lay in the ability of the organization considering normative mapping to clearly document the associations between the normative and mapped controls. For this reason, an important consideration in normative mapping projects is whether sufficient resources exist to effectively analyze the individual controls across frameworks. A normative mapping strategy must ensure that normative controls are constructed to provide an appropriate level of equivalence between mapped controls, and to effectively document these rationales and decisions in support of formal audits.
Transitive Control Mapping Where normative mapping strategies seek to relate disparate controls through the use of a new, specially formulated control framework, transitive mapping strategies rely instead on an existing authoritative control framework to provide the key to rationalization. Usually this framework is determined by prioritizing one of the multiple control frameworks for which an entity is responsible, on the basis of the business or compliance needs of the entity. The prioritized framework then becomes the central reference point for all other mapped control frameworks. In Figure 2 ACME Healthcare
employs a transitive mapping strategy for HIPAA, PCI DSS, and SOX, using HIPAA as the prioritized framework.
Figure 2: ACME Healthcare Inc. – Transitive Control Mapping
Benefits of Transitive Control Mapping An immediate benefit of transitive mapping of control frameworks is that this strategy is less resource intensive than normative mapping, particularly as the number of authority control frameworks grows larger. In transitive mapping the original control frameworks and the language of specific controls are preserved rather than subsumed by a new framework of controls, as with normative mapping. Instead, the organization uses the relationship between controls from one framework and controls from the prioritized framework to eliminate redundancy between the two, thus allowing for a streamlined control set. In Figure 2 ACME maps various SOX and PCI DSS controls to HIPAA controls rather than treating the controls separately. The resulting equivalence relationships can be used in audit situations to demonstrate that a prioritized framework
control replaces or acts as a compensating control against controls in the mapped frameworks.
Limitations of Transitive Control Mapping Two important limitations must be considered when multiple control frameworks are referenced through a single pre-existing framework: issues of equivalence and issues of unidentified relationships. If not addressed these limitations can result in the creation of “false positive” mappings in which two controls are mapped together that should not be; “false negative” mappings in which two controls should be mapped together but are not; and a general degradation of expected efficiency as identified problems require additional analysis, remediation, and documentation. Unlike normative mapping, transitive mapping does not create new control language and instead relies on the original language from the chosen key control framework against which all other frameworks are referenced. As a result, mappings are constrained to directly identifiable relationships between existing controls in both the key control framework and all subsequently mapped frameworks. Control relationships are analyzed and those controls that are determined to be equivalence are then directly mapped. In Figure 2, SOX Section 404 is mapped to HIPAA 164.308(a)(1)(ii)(A), which mandates a risk assessment, indicating a measure of equivalence between those controls. Similarly, PCI DSS 12.1.2 is also mapped to HIPAA 164.308(a)(1)(ii)(A) as equivalent. The problem that arises from this mapping strategy is the implied equivalence between controls that have not been formally analyzed or mapped. There is no evidence, unless a formal analysis is performed, that an equivalent relationship exists between
Section 404 and PCI DSS 12.1.2. Transitive mapping implies such a relationship by virtue of the fact that the two controls are mapped to HIPAA 164.308(a)(1)(ii)(A). In our team’s research and mapping experience, this implication often proved to be misleading, creating a false positive mapping, as the nature of control language varied widely between frameworks and controls. A related problem with transitive mapping also emerged from differences in language and the resulting equivalence analyses in controls that were similar but differed enough that our team was often unable to directly map controls from the target framework into the key framework, despite overlap. In these cases, rather than produce a false positive mapping we chose to count the controls separately. A similar situation occurred when a control required by a particular framework had no related control within the key framework against which it could be mapped. This happened quite often when attempting to map, for instance, technically specific control frameworks that specified security and equipment configurations with more abstract business frameworks that concentrated on policy or process controls. In Figure 2, SOX Section 404 provides a good example. In the normative mapping, Section 404 could be mapped into ACME’s Anti-Malware requirements. In the transitive framework there is less room for interpretation and therefore these controls could not be directly linked. The common control framework that results from a transitive mapping strategy is a combination of controls mapped to the key framework, transitively related controls mapped against one another to avoid false positives (if this work is actually done – often it is not), and controls that are not mapped through the key framework and therefore remain independent. A problem exists with these unmapped controls in that false
negatives are often created in transitive mappings when two controls are related or equivalent, but neither shares a commonality with the key framework. Although not illustrated in Figure 2, our study found many instances where equivalent controls in a transitive mapping framework remained unidentified. While maintaining these controls separately does not negatively impact compliance (the controls remain functioning and in place), the lack of mapping between them makes the CCF larger and more complex than necessary, eliminating some efficiency from the rationalization process. The problems of both false positives and false negatives in a transitively mapped CCF grow with the number and type of frameworks included in the mapping. For this reason it becomes very important for security managers considering transitive mapping to understand how mappings are derived. It may be necessary in some scenarios to supplement a rationalized CCF with additional analysis and documentation to ensure that audit requirements are fully met and that the organization has performed due diligence on the controls logic they have adopted.
Granular Control Mapping Granular mapping is the most ambitious control rationalization strategy, attempting to perform a relationship and equivalence analysis of the complete set of controls for every framework to be mapped. In this method every included control is analyzed and mapped against every other control across all included frameworks. These one to one relationships are documented and the resulting CCF is a comprehensive matrix of all control relationships. Figure 3 illustrates the ACME Healthcare example controls in a granular mapping analysis.
Figure 3: ACME Healthcare Inc. – Granular Control Mapping
Benefits of Granular Control Mapping Granular control rationalization strategies work best for mapping initiatives involving a very small set of control frameworks, where they provide the most comprehensive and robust rationalization. Granular mapping shares a characteristic of transitive mapping in that original control language and structures are retained and, unlike normative mapping, a new specially created framework is not used. Unlike transitive mapping, though, the granular map does not use a key framework to simplify the rationalization. Instead, in a granular mapping project every relationship is identified, analyzed, and documented so that all related controls are explicitly connected. In this way a granular control map attempts to identify all equivalent (and therefore redundant)
controls, while preserving the original controls’ language and structure to avoid misinterpretation or miscommunication in audit situations.
Limitations of Granular Control Mapping While powerful at small scales (2 or 3 related control frameworks), granular mapping quickly becomes unwieldy and confusing as more frameworks must be rationalized. Every framework included in a granular mapping increases (possibly exponentially) the number of possible relationships that may exist between the controls. Even at smaller scales, granular mapping is the most resource intensive and timeconsuming rationalization strategy available. At larger scales it will likely prove cost prohibitive to conduct the mapping as the efficiencies to be gained by the creation of a common control framework are overshadowed by the costs of developing that framework. Our team found no vendors or users that had conducted granular mapping projects for more than three control frameworks and in most cases it was only used to map two related frameworks against one another for a specific project. Most IT GRC scenarios involve more than two control frameworks that must be rationalized. For these reasons we included granular mapping as one strategy in our model but we do not expect to see it utilized in typical control rationalization projects.
Conclusions Our research sought to develop an evaluative model against which various control framework rationalization strategies could be assessed. The model proposed here is useful for such evaluation, providing basic strategies for mapping different frameworks
that are currently used within the security and IT GRC communities to create common control frameworks. Organizations seeking to develop or purchase a common control framework have several options available to them including conducting the rationalization and mapping in house, outsourcing the CCF development to a consultant, or purchasing a CCF as part of a vendor’s IT GRC tools. Regardless of the decision, an organization has an interest in understanding how these mappings are being derived. Most vendors, we discovered, do not indemnify their control rationalizations or mappings. The customer is therefore responsible for ensuring that any mappings that are used in support of audit functions, compliance with regulations, or securing production systems are correct and appropriate. Organizations considering a control rationalization strategy in order to reduce the complexity or redundancy of existing compliance efforts, or that wish to implement a standardized, holistic security program that will still address their various compliance requirements should evaluate potential mapping strategies. The strengths and limitations of each strategy should then be weighed against the environment, resources, audit requirements, and risk tolerance of the organization prior to selection.
References Anand, S. (2006). Sarbanes-Oxley guide for finance and information technology professionals. Hoboken, NJ: John Wiley & Sons, Inc. Brewer, C. (2008). The Tao of compliance: Unifying controls over chaos. Retrieved May 9, 2009, from http://www.t2pa.com/practical-advice/138-the-tao-of-compliance-unifyingcontrols-over-chaos Bødker, S. (1996). Creating conditions for participation: Conflicts and resources in systems design. Human Computer Interaction, 11(3), 215-236. Calder, A., & Watkins, S. (2006). International IT governance: An executive guide to ISO 17799/ISO 27001. London: Kogan Page. ControlPath. (n.d.). 2006 Compliance Progress Survey. Retrieved May 8, 2009, from http://jobfunctions.bnet.com/abstract.aspx?docid=276630&tag=content;col1 Deloitte & Touche LLP. (2005, November). Rationalizing your internal controls. Retrieved May 10, 2009, from http://www.deloitteandtouche.org/dtt/newsletter/0,1012,cid%253D98221%2526pv%253 DY,00.html DeLuccia, J. J. (2008). IT compliance and controls: Best practices for implementation. Hoboken, NJ: John Wiley & Sons, Inc. Gazaway, R. (2007, January 3). Create a sound compliance framework. SC Magazine. Retrieved May 11, 2009, from http://www.scmagazineus.com/Create-a-sound-complianceframework/article/34332/ IT Compliance Group. (2008, May). IT governance, risk, and compliance: Improving business results and mitigating financial risk (Annual Report No. 2008). Retrieved April 20, 2009,
from http://www.itpolicycompliance.com/research_reports/it_governance/read.asp?ID=12 Kaplan, D. (2009, March 2). Group unveils first-of-its-kind standard to secure patient data. SC Magazine. Retrieved May 10, 2009, from http://www.scmagazineus.com/Group-unveilsfirst-of-its-kind-standard-to-secure-patient-data/article/128168/ Muller, M. J. (2008). Participatory design: The third space in HCI. In A. Sears & J. A. Jacko (Eds.), The human-computer interaction handbook: Fundamentals, evolving technologies, and emerging applications (2nd ed., pp. 1061-1081). Boca Raton, FL: CRC Press. Network Frontiers LLC. (2008). IT compliance frameworks: Where the UCF fits. Lecanto, FL: Network Frontiers LLC. Schuman, E. (2007, October 25). TJX waging legal battle to keep security details secret. eWeek. Retrieved May 11, 2009, from http://www.eweek.com/c/a/Enterprise-Applications/TJXWaging-Legal-Battle-To-Keep-Security-Details-Secret/ Silverman, M. G. (2008). Compliance management for public, private, or nonprofit organizations. New York: McGraw-Hill. Tipton, H. F., & Krause, M. (2007). Information security management handbook. Boca Raton, FL: Auerbach Publications. Virtue, T. M. (2009). Payment card industry data security standard handbook. Hoboken, NJ: John Wiley & Sons, Inc.
