3.2 Control Allocation & Inheritance Models

3.2 Control Allocation & Inheritance Models

Core Blueprint Focus: In modern enterprise and cloud computing architectures, no individual information system operates in complete isolation. RMF Step 2 (Select / Task S-3: Control Allocation) requires practitioners to designate each security and privacy control as Common, System-Specific, or Hybrid. Mastering control inheritance streamlines authorization, eliminates redundant assessment testing, and ensures unambiguous accountability across complex organizational and cloud boundaries.

Control allocation is the deliberate architectural process of assigning responsibility for the development, implementation, assessment, and continuous monitoring of security and privacy controls to specific organizational entities, shared services, or individual system owners.

---

The Four Control Allocation Classifications

According to NIST SP 800-37 Rev. 2 and NIST SP 800-53 Rev. 5, every control selected for an information system's tailored baseline must be allocated to one of four implementation categories:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     CONTROL ALLOCATION CLASSIFICATIONS                      │
│                                                                             │
│  1. COMMON CONTROLS                                                         │
│     • Provided by a Common Control Provider (CCP)                           │
│     • Inherited by multiple information systems                             │
│     • Examples: Physical Security (PE-3), Personnel Screening (PS-3)        │
│                                                                             │
│  2. INHERITED CONTROLS                                                      │
│     • The consuming system's perspective of a Common Control                │
│     • Leveraged directly without local technical implementation             │
│                                                                             │
│  3. SYSTEM-SPECIFIC CONTROLS                                                │
│     • Implemented solely and uniquely by the primary information system     │
│     • Examples: Application RBAC (AC-6), Database Field Encryption (SC-28)  │
│                                                                             │
│  4. HYBRID CONTROLS                                                         │
│     • Contains BOTH an inherited component AND a system-specific component  │
│     • Examples: Incident Response (IR-4), Account Management (AC-2)         │
└─────────────────────────────────────────────────────────────────────────────┘

1. Common Controls

A Common Control is a security or privacy safeguard whose implementation results in a security capability that can be inherited by multiple, independent information systems across an organization. Common controls are funded, implemented, assessed, and maintained centrally by an organizational entity known as a Common Control Provider (CCP).

• Typical Examples:
  • Physical and Environmental Protection (PE-2, PE-3, PE-6): Enterprise data center badge access, perimeter guards, HVAC, and fire suppression.
  • Personnel Security (PS-2, PS-3): Centralized human resources background screening and onboarding/offboarding workflows.
  • Awareness and Training (AT-2, AT-3): Agency-wide annual cybersecurity literacy modules.
  • Enterprise Security Operations Center (SI-4, IR-4): Tier 1 24/7 boundary traffic analysis and centralized SIEM ingestion.

2. Inherited Controls

An Inherited Control represents the receiving system's operational relationship with a Common Control. From the perspective of the consuming Information System Owner (ISO), an inherited control is a safeguard that is provided by an external entity, parent infrastructure, or hosting provider that the consuming system relies upon to satisfy specific compliance requirements without needing to engineer, configure, or manage the underlying mechanism.

3. System-Specific Controls

A System-Specific Control is a safeguard implemented exclusively and uniquely within the authorization boundary of a specific information system. The System Owner and Information System Security Officer (ISSO) bear sole responsibility for designing, configuring, testing, and maintaining these controls.

• Typical Examples:
  • Application-level Role-Based Access Control (AC-3, AC-6): Custom permission matrices governing which users can edit financial ledgers or approve medical claims.
  • Custom Cryptographic Mechanisms (SC-28, SC-13): Application-layer database column-level encryption keys managed inside a dedicated application keystore.
  • Input Validation & Injection Defenses (SI-10): Application code routines preventing SQL injection, Cross-Site Scripting (XSS), and buffer overflows.

4. Hybrid Controls

A Hybrid Control is a control that possesses both an inherited (common) component AND a system-specific component. Hybrid controls are among the most heavily tested concepts on the CGRC examination because they require precise coordination and documentation to avoid compliance gaps.

---

The Common Control Provider (CCP) Lifecycle

The Common Control Provider (CCP) is an official RMF role (often an enterprise infrastructure director, CISO office lead, or data center operations manager) designated during RMF Step 0 (Prepare - Task P-4).

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE COMMON CONTROL PROVIDER LIFECYCLE                   │
│                                                                             │
│  1. IDENTIFY & DOCUMENT                                                     │
│     • Develop the Common Control Security Plan (CC-SSP).                    │
│     • Define exact service boundaries and consumption interfaces.           │
│                                                                             │
│  2. IMPLEMENT SAFEGUARDS                                                    │
│     • Deploy enterprise controls (e.g., enterprise SIEM, physical badges).  │
│                                                                             │
│  3. INDEPENDENT ASSESSMENT                                                  │
│     • Security Control Assessor (SCA) tests common controls ONCE.           │
│     • Produces Common Control Security Assessment Report (CC-SAR).          │
│                                                                             │
│  4. AUTHORIZATION & PUBLICATION                                             │
│     • Enterprise AO grants ATO to Common Control package.                   │
│     • Distributes Security Control Implementation Summary to ISOs.          │
│                                                                             │
│  5. CONTINUOUS MONITORING & NOTIFICATION                                    │
│     • Monitors control efficacy; notifies consuming ISOs of flaws/POA&Ms.   │
└─────────────────────────────────────────────────────────────────────────────┘

Economies of Scale and Assessment Efficiency:

By assessing common controls at the enterprise tier, an organization achieves massive operational efficiencies. If 100 information systems reside in a single enterprise data center, the physical security controls (PE family) are assessed once by the CCP's assessor, rather than undergoing 100 separate, redundant assessments by individual system assessors.

[!WARNING] The "Inheritance Abdication" Trap: System Owners cannot simply check "Inherited" in their System Security Plan and ignore the control. Consuming System Owners are strictly required to:

1. Formally cite the Common Control Provider's system name and authorization date.
2. Verify that the CCP's ATO remains active and valid.
3. Review the CCP's Plan of Action and Milestones (POA&M) to identify any unresolved weaknesses that create downstream risk for their consuming system.
4. Fully document and implement their system-specific obligations for all hybrid controls.

---

Cloud Inheritance & The Shared Responsibility Model

When systems migrate to commercial cloud environments, the Cloud Service Provider (CSP) acts as an external Common Control Provider. Control allocation aligns directly with the NIST SP 800-145 cloud service models:

┌─────────────────────────────────────────────────────────────────────────────┐
│                 CLOUD CONTROL ALLOCATION & INHERITANCE                      │
│                                                                             │
│  Control Family / Layer     │   IaaS Model   │   PaaS Model   │ SaaS Model  │
│  ───────────────────────────┼────────────────┼────────────────┼───────────  │
│  Physical Data Center (PE)  │   Inherited    │   Inherited    │  Inherited  │
│  Hypervisor / Compute (SC)  │   Inherited    │   Inherited    │  Inherited  │
│  Operating System (CM, SI)  │ System-Specific│   Inherited    │  Inherited  │
│  Database Engine (SC, AU)   │ System-Specific│   Inherited    │  Inherited  │
│  Application Logic (AC, IA) │ System-Specific│ System-Specific│  Inherited  │
│  User Access & IAM (AC-2)   │    Hybrid      │    Hybrid      │   Hybrid    │
│  Data Governance (PT, MP)   │ System-Specific│ System-Specific│  Hybrid     │
└─────────────────────────────────────────────────────────────────────────────┘

FedRAMP Control Inheritance Mechanisms

In the federal and high-assurance commercial sectors, the Federal Risk and Authorization Management Program (FedRAMP) standardizes cloud control inheritance:

1. Customer Responsibility Matrix (CRM) / Control Implementation Summary (CIS): The CSP publishes a detailed CRM workbook specifying exactly which NIST SP 800-53 controls are fully satisfied by the CSP, which are shared/hybrid, and which are the sole responsibility of the customer tenant.
2. FedRAMP Package Access Request (PAR): Agency ISSOs and ISOs request formal access to the CSP's FedRAMP authorization package (via OMB/FedRAMP repositories) to inspect the CSP's System Security Plan, Security Assessment Report (SAR) prepared by a Third-Party Assessment Organization (3PAO), and continuous monitoring monthly reports.
3. Leveraged ATO / Agency ATO: The agency Authorizing Official reviews the CSP's FedRAMP artifacts, evaluates the agency's system-specific and hybrid control implementations, and issues an Agency Authority to Operate (ATO) accepting the cumulative risk of the combined stack.

---

Summary Comparison of Control Allocation Types

---

Real-World RMF Scenario: Delineating Hybrid Controls for an Enterprise HR System on FedRAMP IaaS

Scenario: An agency deploys a new Human Resources Information System (HRIS) processing employee PII onto a FedRAMP-authorized Infrastructure as a Service (IaaS) cloud provider. For control IA-2 (Identification and Authentication), the System Owner marks the control as "Inherited from Cloud Provider."

GRC Action: During the Step 2 review, the Security Control Assessor (SCA) rejects the control allocation. The SCA explains that while the cloud provider manages physical hardware security and hypervisor authentication (inherited), the guest operating system, application web portal, and user account authentication are deployed and managed directly by the agency. The control must be re-allocated as Hybrid: the agency inherits the cloud infrastructure authentication from the CSP, leverages enterprise PIV/CAC Single Sign-On from the agency IdP (Common), and implements local role-based application session authentication (System-Specific).