GRC Blog

The entirety of NIST SP 800-53, REV. 5 SECURITY AND PRIVACY CONTROLS FOR INFORMATION SYSTEMS AND ORGANIZATIONS include over one thousand controls and enhancements, more than 400 reference documents, and now an additional assessment methodology with an array of a few dozen assessment step attributes for every single requirement. It's easy to understand why organizations would want to leverage as many high-level processes or COMMON control processes as possible.

Consider that for every element in the control catalog spreadsheet, there are nearly infinite connections and context that influence how that control is selected and implemented. It might be one and done, and it might be a dreaded "per system" or even "per event" level control. Download from NIST - The Control Catalog - but this is not everything! 

Isn't the deduplication of corporate management functions the reason we agreed to the merger?

There are really good reasons and really bad reasons to designate controls as shared or common. 

NIST explains that "Common Controls are controls whose implementation results in a capability that is inheritable by multiple systems or programs." For example, we use a set of Corporate Policies which protects us from inconsistent and poorly drafted policies at each layer of the business. Imagine if every Director was allowed to or required to write their own Code of Business Conduct? Given the disparity of priorities, capabilities, and resources, the disparities in control coverage could be disastrous.

"A control is deemed inheritable when the system or program receives protection from the implemented control, but the control is developed, implemented, assessed, authorized, and monitored by an internal or external entity other than the entity responsible for the system or program." Saying this another way, a common control has Governance Oversight. There are internal checks to assure the implementation of corporate policies, usually as a part of the Privacy Information Management and Information Security Management System (PIMS/ISMS) across the entire enterprise. (We'll write more about that in another article.)

Implementing controls as Common Controls can introduce the risk of a single point of failure.

The alternative to implementing common controls is to implement system-specific or hybrid controls.

System-specific controls are the primary responsibility of the system owner and the authorizing official for a given system. Every system has an array of owners, stewards, administrators, and users. These roles have responsibilities to implement their system-specific controls. If you need guidance for how those roles should be divided, NIST has an outstanding resource which you can securely download from here Roles and Responsibilities in a Risk Management Framework

System-specific controls is often the point where additional requirements, such as those suggested in OWASP Web Security Testing Guide | OWASP Foundation, MITRE ATT&CK®, and CIS Benchmarks (cisecurity.org) become part of a System Security Plan (SSP) and where they require a Plan of Actions and Milestones (POA&M) to keep track of findings and their remediation. 

So, we can see how organizations will want to avoid myriads of system-specific "one-off" controls, especially where these types of requirements involve a large investment in management technologies.

Implementing system-specific controls can introduce risk if the control implementations are not interoperable with common controls. For example, a system-specific setting might put considerations for availability and usability at odds with statements about processing and privacy. Given the challenge of matching system policies and common inherited broad corporate policies, any company will want as few unique system controls as possible.

This is one reason EnterpriseGRC Solutions promotes the use of GRC related cloud security products. Anything that normalizes system policies to their overarching Governance, especially where those controls are can align with industry-approved mapping guidance, is often the lifeblood that keeps that company afloat. Attempting to remain in good standing with US and International Laws concerning the development of cloud products and the limitations on the products & services these providers themselves may consume, absolutely requires Cloud Security and GRC applications. We promote such companies in our section Products & Service Providers. Some immediate high-level mentions include Security Compass, SD Elements, and Araali Networks. 

The Authorization to operate a system is directly tied to [OMB A-130] The official management decision given by a senior Federal official or officials to authorize the operation of an information system and to explicitly accept the risk to agency operations (including mission, functions, image, or reputation), agency assets, individuals, other organizations, and the Nation based on the implementation of an agreed-upon set of security and 
privacy controls. Authorization also applies to common controls inherited by agency information systems.

Organizations can implement a control as hybrid if one part of the control is common (inheritable) and the other part is system specific. For example, an organization may implement a Contingency Plan (CP-2) using a predefined template for all organizational information systems with individual system owners tailoring the plan for system-specific uses, where appropriate. The division of a hybrid control into its common (inheritable) and system-specific parts may vary year and organization. This is why controls like CP-2 require annual review to confirm the currency record for all information technologies employed, the approach used by the organization to manage its controls, and the complete and accurate assignment of responsibilities.

"When a control is implemented as a hybrid control, the common control provider is responsible for ensuring the implementation, assessment, and monitoring of the common part of the hybrid control, and the system owner is responsible for ensuring the implementation, assessment, and monitoring of the system-specific part of the hybrid control. Implementing controls as hybrid controls can introduce risk if the responsibility for the implementation and ongoing management of the common and system-specific parts of the controls is unclear." This is why companies attempting to achieve or maintain their US ATO really need a GRC program and array of cloud security management systems that can track and maintain clarity over the responsibilities of all controls and policy affecting the system.

The determination as to the appropriate control implementation approach (i.e., common, hybrid, or system-specific) is context-dependent. The control implementation approach cannot be determined to be common, hybrid, or system-specific simply based on the language of the control. Identifying the control implementation approach can result in significant savings to organizations in implementation and assessment costs and a more consistent application of the controls organization wide. Typically, the identification of the control implementation approach is straightforward. However, the implementation takes significant planning and coordination.

Planning for the implementation approach of a control (i.e., common, hybrid, or system-specific) is best carried out early in the system development life cycle and coordinated with the entities providing the control [SP 800-37]. Similarly, if a control is to be inheritable, coordination is required with the inheriting entity to ensure that the control meets its needs. This is especially important given the nature of control parameters. An inheriting entity cannot assume that controls are the same and mitigate the appropriate risk to the system just because the control identifiers (e.g., AC-1) are the same. It is essential to examine the control parameters (e.g., 
assignment or selection operations) when determining if a common control is adequate to mitigate system-specific risks.