Introduction
One of the most misunderstood concepts amongst Cybersecurity GRC teams, is the reach and benefits of a “Common Control Framework” or CCM. More often than not, the CCM is seen as the holy grail for ‘testing once, complying with many’. While there is some truth to this, realizing the value of CCM is more complex than leaders are led to believe and requires ongoing efforts to ensure accuracy and relevance of the framework, in other words it is not a one time project, rather it is a continuous improvement program.
Without focusing on the mapping of requirements between various industry frameworks and regulations, which can be acquired from many service providers in the marketplace, I would like to present a framework to build and maintain a formalized repository of Cybersecurity controls. This approach would allow any organization to improve external audit management processes, demonstrate compliance with internal policies and to track mitigation of Cybersecurity risks.
The first step is to clearly define the stakeholders around this Cybersecurity controls’ repository, I like to define them based on the level of impact and effort required to build, maintain and derive value from this repository. 1) Core users whose day to day job is to monitor the health of the Cybersecurity controls: Cybersecurity GRC teams, Internal Audit, ERM, SOX office, 2) Core contributors who are critical to the accuracy of the repository: control owners, engineering teams and 3) Leadership interested in the health of the Cybersecurity controls: CISO, CTO, CIO and Business Leaders.
The second step is to determine the information that should be included in this controls’ repository. For simplicity I will break this into 5 categories, a) External, b) Internal, c) Governance, d) Data/Asset Classification and e) Operational.
The Framework
a) External: should include all regulations, industry standards, best practices and even customer requirements your organization is subject to. There are multiple frameworks, even open sourced, that have created and continuously update mappings between all the major regulations and industry standards (see reference section below). There is no need to dedicate an enormous amount of resources to build and maintain those mappings in-house, focus should be placed on customer requirements or industry regulations that are strategic to your organization. Example, SOX, NIST, PCI, GDPR and ISO are already mapped by vendors; however, specific requirements for securing medical or payment devices mappings might not be readily available in the market, this is where the GRC teams need to focus on.
b) Internal: this category is key to ensure that the Cybersecurity strategy is aligned to and enabling Business objectives, this is accomplished by incorporating Business Goals, Risks and Appetite/Tolerance thresholds into this framework. Example, risk appetite around disclosure of Personal Identifiable Information (PII), or tolerance for Bring Your Own Devices (BYOD) technology, or a Passwordless approach on critical systems.
c) Governance: at this level is where GRC teams get to bring the most value to the organization, it involves the creation of Cybersecurity Policies and Standards (P&S) fully aligned with the External and Internal categories. GRC teams should ensure that these high level statements (i.e. Policies) capture the spirit of the external requirements and the risk posture of the organization, and the lower level control requirements (i.e. Standards or control objectives) meet those policies. Policy statement example: The organization requires strong authentication for all users accessing its information systems. Authentication methods must meet or exceed industry standards and best practices to ensure the security and integrity of organizational data. Standard statement example: Passwords must be at least 12 characters long and include a mix of upper and lower case letters, numbers, and special characters. MFA is required for access to all systems handling Restricted information.
Special Note: Existing control mappings in the marketplace include a “Common Control” description that is aimed to address the external requirements mapping; however, these do not incorporate your organization’s risk posture or business objectives. In order to take advantage of the externally provided “Common Controls”, these must be customized to the organization’s needs, ensuring they remain aligned to the external mappings and to your risk posture. In some cases the provided “Common Controls” will read more as a Policy and some as a Standard. It is the responsibility of the GRC teams to ensure where those statements get properly incorporated into the organization’s Policies or Standards.
d) Data/Asset Classification category: data/asset classification is a fundamental aspect of cybersecurity, this category of the framework will help your organization apply the appropriate security controls based on the sensitivity of the data and the assets storing, processing or transmitting such data. While in the broader sense all cybersecurity policies and standards apply to the entire organization, leveraging the data and asset classification level will allow the organization to prioritize the processes and systems that will be captured in the Cybersecurity controls repository. Example: Assuming the following data classification levels: Public, Internal, Confidential and Restricted; and leveraging the authentication examples above, we can prioritize documentation and monitoring of MFA controls on systems storing restricted data over password complexity on systems storing public data.
A key element to this example is that systems storing Internal information still require authentication controls; however, GRC teams can keep system owners accountable for the implementation of those controls through education, awareness and self attestation, while directing efforts to perform independent assessments of controls around systems storing Restricted data.
e) Operational category: the objective of this category is to promote additional collaboration between GRC teams and control owners/engineering teams. Processes should be established to identify, document, test and regularly update the actual “control points” or “controls implementations”, determining their design and operating effectiveness to comply with the control objectives documented at the Policy and Standards level. If additional guidance is required by control owners around “how to implement the policies and standards”, detailed “Guidelines” should be created. Example: in the Azure AD portal, navigate to the Multi-Factor Authentication settings, and set up MFA. Configure MFA policies in AD FS Management Console to enforce MFA under certain conditions, such as access from outside the corporate network or for specific applications.
The third step is to make this framework a continuous improvement process rather than a one time effort. Ensuring alignment between stakeholders on the value proposition of a centralized repository of Cybersecurity controls.
Framework in Action
Let’s work on a very simple example of how this framework can be implemented:
Leveraging the Security Control Framework (SCF) or the Unified Compliance Framework (UCF), let’s consider the following regulations and industry best practices: CIS, ISO 27002, NIST 800-53, NIST CSF, PCI, FedRAMP. All of these include considerations for Password-Based Authentication and Multi-Factor Authentication (MFA) and are already mapped between each other. So this is just a simple download from SCF or UCF.
From an Internal perspective, let’s assume a recent risk assessment has determined that the expected password entropy (the measure of password strength, i.e., how effective a password is against adversaries who try to guess it or use a brute-force attack.) should be at least 12 characters long, including lower and upper case letters, numbers and special characters. Also, the risk assessment determined that all systems with access to Restricted information should include MFA.
Using the information above let’s draft our organization’s Policy and Standard statements, making sure that these remain mapped to the essence of the External and Internal inputs above:
Policy Statement – The organization requires strong authentication for all users accessing its information systems. Authentication methods must meet or exceed industry standards and best practices to ensure the security and integrity of organizational data.
Mechanisms exist to enforce complexity, length and lifespan considerations to ensure strong criteria for password-based authentication.
Automated mechanisms exist to enforce Multi-Factor Authentication (MFA) for:
– Remote network access;
– Third-party systems, applications and/or services;
– Non-console access to critical systems or systems that store, transmit and/or process Restricted data.
Remember that in addition to the statement above, a Policy document also includes Purpose, Scope, Roles and Responsibilities, etc.
Standard Statements – Passwords must be at least 12 characters long and include a mix of upper and lower case letters, numbers, and special characters. Passwords must not be shared or reused across different accounts/services. Passwords must be changed at least every 90 days.
MFA is required for access to all systems handling Restricted information. MFA methods may include a combination of something you know (password), something you have (security token or mobile device), and something you are (biometric verification).
While CMDB and other sources should be relied upon as an input to this category, leveraging the latest Risk Assessments, Compliance Readiness Assessments, Audits or Data Classification efforts is sufficient to start building our controls’ repository, other sources can be added at a later stage as the organization’s asset management process matures. We should include networks, platforms, data storage repositories and applications of all types:
– GCP Compute Engine, AWS S3 buckets, On-Prem corp network;
– Linux servers, Windows servers;
– SaaS applications, on-prem applications.
Once the External and Internal requirements are integrated into Policies and Standards, and the assets have been clearly identified. We are ready to document the Control Points / Controls Implementations that we can assess.
In the example above I split the same requirement into two different Control Points / Implementations (almost the same description), I’m doing this based on the fact that Linux and Windows systems are configured (therefore tested) differently. An alternative would be to create only one single Control Implementation, since the Owner is the same, and split Linux and Windows at the Control Testing level, all this depends on your GRC tool capabilities to support any of these options. The importance of this Asset/Process/Owner combination is Accountability.
– Windows Servers + Process 1 + Engineering = Control Implementation 1
– Linux Servers + Process 2 + Engineering = Control Implementation 2
– Windows Servers + Process 1 + Engineering Team 2 = Control Implementation 3
Testing results can then get aggregated for reporting purposes, by team, by process, by asset, by Cyber domain, etc.
Conclusion
Building a Cybersecurity controls repository is not an easy task, requires focus, agility, setting clear expectations and goals, implementing a strong communications strategy and planning on delivering short, mid and long term results. Resources spent on this approach can be capitalized in terms of effective compliance programs, clear tracking of risk mitigation initiatives, a more efficient stakeholder engagement process, measurable performance of Cybersecurity controls’ and integration of GRC functions.
Another key element in the successful implementation of a framework like this, is the selection of the appropriate technology to store the information and automate the process, spend the right amount of time talking the vendors, explaining your goals and making sure there is full alignment between both.
Artificial Intelligence (AI) technologies can also be leveraged to build a Cybersecurity controls repository, in fact, I have relied on ChatGPT to draft some of the Policies, Standards and Controls examples in this article, I have also seen testing procedures being drafted by ChatGPT, just keep in mind that GRC professionals must validate the accuracy of the AI models output.
Cybersecurity Governance, Risk and Compliance 
Leave a comment