13 essential steps to integrating control frameworks

In recent years, requirements for effective information technology governance programs have increased. Information security and risk management professionals face a continually growing collection of laws, regulations, and industry standards—PCI DSS, Sarbanes-Oxley, HIPAA and Red Flag Rules to mention just a few examples— each adding to a seemingly endless set of requirements. As organizations attempt to comply with these provisions, the various activities can become confusing, conflicting, and difficult to manage.

It is fairly obvious that each of these laws, regulations, and standards were created with a specific, laudable goal—to protect a specific type of data asset that, if compromised or corrupted, could result in damage to either the controlling organization or the originating entity. Undeniably, these data elements have value, and they deserve protection. The question that arises from this need, however, is how to address such protection in a method that is comprehensive and actionable.

Also see Jennifer Bayuk’s “What to Expect From an Information Systems Audit”

In order to address individual or combined groups of requirements, organizations often adopt various security or risk management “frameworks”. These programs apply a comprehensive list of controls, standards, or practices that, when implemented correctly, claim to provide an organization the ability to reduce the overall risk to critical data. The types of data, however, vary, and it seems that someone publishes a new “best practice” every day. With the different controls, breadth of coverage, and levels of rigor and detail, the one consistent quality of these frameworks is the lack of consistency.

Regardless, at the end of the day, each frameworks (or requirement sets that function as framework components) is simply an effort designed to address general information technology needs, government-specific requirements, and industry-driven standards. As a rule, they are high-level in their requirements, specifying “what must be done” rather than the “how it must be accomplished”. In order to ensure that they remain effective against the continually changing information security threat landscape, these control sets require an ongoing process of implementation, review, and security program updates.

After considering these issues, attempting to adopt these control sets seems to be more trouble than benefit. The requirement to achieve compliance in our modern business environment is critical, however, and organizations find this need to be adequate reason to make the commitment. The price of non-compliance with required controls can be immediate and costly, both from direct fines and indirect costs such as loss of consumer confidence and market share. Organizations seeking to comply with the stated controls must approach this effort in a way that addresses not only immediate compliance but also ongoing adherence. This is where frameworks become essential.

Frameworks prevent unintended control gaps. Specific legal and regulatory standards provide finite requirements that must be addressed. What they do not necessarily address are the other elements that either support these requirements or areas that directly compliment them, ensuring a more rapidly successful governance program. Frameworks assist in this, providing a set of goals, developed and vetted by the community, that define best practices that might be otherwise missed.

In addition, the use of a comprehensive framework shows a desire to do more than the minimum effort. In adhering to a rigorous set of controls rather than just the required activities, an organization shows a level of effort to rise above the barest standards.

With these benefits identified, how can a framework possibly have detriments? Simply put, no one tool can cover everything.

Frameworks are rigorous only within the scope of their coverage. However, a HIPAA framework will not address cardholder data requirements. A COBIT framework, while perfectly effective for addressing the general computing controls needed for SOX compliance, does not provide a overreaching security program that addresses privacy needs. Frameworks are specific to the world in which they live.

Frameworks are, as stated before, typically high level, emphasizing controls to be implemented rather than the processes needed to achieve compliance. The gap between control and execution must be closed in order to address the framework requirements, but the means that organizations use to accomplish this vary greatly. Two like entities that carefully follow identical frameworks to protect the exact same data elements may have significantly different security postures.

Frameworks usually have an element that requires regularly executed risk assessments. However, due to the strictly defined control set, these risk assessments can focus too tightly upon a set of controls, leaving others unaddressed. The framework that was intended to increase the overall security of the organization effectively blinds the organization to threats that may be actively attempting to compromise sensitive information.

Also read an in-depth look at IT risk assessment frameworks including OCTAVE and FAIR

After reviewing both the benefits and drawbacks, it appears that there may not be any such thing as an effective framework. This may very well be true. It is because of this situation, however, that it becomes critical for an organization to understand that their ideal framework may actually be a combination of several others. A company has only a single security practice, but they may be answerable to many differing laws and regulations. Ongoing review and audit requirements for entities that attempt to follow multiple distinct frameworks rapidly overwhelm and confuse even the most dedicated information security staff. Limited budgets quickly force organizations to prioritize efforts, but the need to address the overall threat landscape does not become any less critical. In the end, multiple frameworks are often needed, but the task of managing them becomes almost impossible to implement.

Following multiple frameworks as individual entities requires a Herculean effort and is rarely effective. Too many competing priorities and timelines tend to result in an inability to achieve any form of effective compliance. However, the simple fact is that a framework is nothing more than a series of control objectives that have been bundled to address a purpose.

Purposes change, and there is no reason that security frameworks cannot do the same. The goal is to create an effective governance program. Achieving this in an effective and manageable fashion is difficult, but it can be done by carefully planning an approach of blended controls, carefully controlled scoping of data assets, and unified process.

A series of concepts used to approach such a merger of two or more frameworks is listed below. It is by no means definitive, but the lessons are effective across any methodology used.

1. The organization must understand which frameworks or framework elements are needed to address, at a minimum, the critical security concerns. When addressing control requirements, more is not necessarily better, and each additional control entity represents an investment in time, money, and effort.
2. Choose a base framework to use. An organization should identify a base framework to contain the additional controls. This framework should be as broad as is viable, allowing for only minimal, more specific needs to be addressed.
3. Break the identified framework elements down according to functional areas and combine controls into like families or tiers. Different frameworks often contain equivalent controls under different headings or focus areas. By understanding where the controls map to one another, existing controls can often simply be enhanced rather than having to add completely different compliance needs.
4. Identify critical controls that address the most restrictive requirements. In many situations, there will be control objectives that must be accomplished, intermingled with additional categories that are simply “good-to-have”. The action items that are required for compliance needs should be categorized as more critical.
5. Define control “numbering system” and nomenclature. For ease of evaluation and tracking, the combined framework elements should be indexed in a way that allows them to be viewed as parts of a whole. In addition, a formalized control language should be used to address concepts across the new framework, avoiding confusion as compliance efforts begin.
6. Identify affected data. Just as it was necessary in the first step to identify which controls and frameworks were needed, it becomes necessary to reverse the process, ensuring that all elements of data that are subject to the collected controls. The majority of this information was known at the start of the exercise, but a second glance after consolidating the requirements often identifies additional data sources, repositories, and systems.
7. Understand data flows. As critical as it is to understand the affected data elements, it is just as important to understand where those data elements reside and why. How the information is collected, processed, stored, and transmitted is essential to determining in-scope systems, applications, and processes that must adhere to the new framework.
8. Formally define scope of data controlled by the frameworks. After identifying the data flow patterns and practices, a consolidated list of servers, systems, applications, processes, and governance items must be created and then reviewed against expected values.
9. Reduce data scope aggressively. Each data control element is an investment in time, money, and effort. The same can be said for each element of the in-scope data that is addressed by the combined framework. Existing business processes and needs should be used to determine if data is being used or retained in inappropriate or unneeded areas. Where possible, data should be consolidated and purged, reducing the overall scope of control coverage, especially critical control requirements such as those brought on by legal or regulatory provisions. (Editor’s note: see Ben Rothke and David Mundhenk’s guidance on reducing PCI scope.)
10. Classify affected data according to impact. Some controls will be identified as more critical, and the data elements associated with these will likewise be viewed as more sensitive. These classes of information assets should be classified and labeled to ensure that adequate attention is applied.
11. Define data lifecycle elements based upon classification levels and requirements identified by various standards and practices. Once the combined framework controls are in place; the data is identified, scoped, and minimized; and classification levels have been established, a comprehensive data lifecycle program should be implemented. Through this process, end users can manage data elements, complying with the chosen control framework requirements without having to conduct extensive research into sometimes arcane control sets.
12. Review existing infrastructure, policy, and procedure against the consolidated framework and data lifecycle requirements. Governance and operational resources must be reviewed against the newly developed framework and associated lifecycle elements. Where needed, changes should be made to support the new controls system.
13. Implement consistent solutions across all data elements located within the tier. The supporting processes that enable the controls effectiveness should be viewed from the perspective of consistent, modular growth. Networks, systems, and management tools should be designed to scale or be replaced easily. Consolidated security programs (such as incident response, vulnerability management, and change management) and scheduled requirements (audits, penetration testing, vulnerability assessments, risk assessments, and reports) should be updated to address all required controls across the entire framework, resulting in a consistent, singular approach to compliance and readiness.

Frameworks are wonderful tools that can greatly simplify an organizations pursuit of effective information governance and compliance. However, one size rarely fits all, and a well-considered combination of framework elements may be the best option.

Chris Gray is a senior risk and compliance management consultant for Accuvant. In this role, Gray provides world-class security, compliance and IT risk management consulting services to Accuvant clients, focusing on compliance readiness and controls framework integration. Gray has considerable experience in the creation and integration of controls frameworks across a number of industries and subject areas, including Sarbanes Oxley (SOX 404), privacy, and the Payment Card Industry (PCI).