Control Selection 9 Flashcards

An organization is implementing a hybrid cloud system where some components reside on-premises and others in a FedRAMP-authorized CSP environment. During control selection, the security engineer wants to inherit controls from the CSP's authorization package. Which factor MOST critically determines whether a control can be legitimately inherited from the CSP?

Answer: The CSP's authorization boundary must explicitly encompass the specific service or feature the organization is consuming.

Control inheritance from a CSP is only valid when the CSP's authorization boundary explicitly covers the specific service being consumed. A CSP may hold a broad FedRAMP authorization, but if the organization is using a service or feature not within that boundary, inheritance is invalid regardless of the overall authorization level. The CRM (Option A) is important but secondary — the boundary scoping is the prerequisite. Impact level matching (Option C) is a common misconception; the organization must ensure adequate coverage but the boundary is the gating factor. AO acceptance (Option D) is good practice but does not itself validate inheritance.

During the Prepare step of the RMF, an organization defines a control overlay for its industrial control systems (ICS). When the control selection step is reached, the system owner discovers the overlay adds three controls not present in the MODERATE baseline and removes one baseline control deemed non-applicable to ICS environments. Which action is correct?

Answer: The system owner may still tailor the overlaid baseline, adding or removing controls through the standard tailoring process with appropriate justification.

NIST SP 800-37 and SP 800-53B both clarify that overlays refine a baseline but do not eliminate the system owner's ability to further tailor. The resulting overlaid baseline is itself a starting point for system-specific tailoring. A system owner can still add controls, remove controls (with justification), or adjust organization-defined parameters. Option A incorrectly treats overlays as immutable. Option B conflates POA&M use with a tailoring decision — removing a non-applicable control through tailoring doesn't require a POA&M. Option D invents a compensating control requirement that doesn't exist in this context.

A CGRC practitioner is selecting controls for a system that processes CUI but is operated by a contractor not subject to FISMA. The contractor's system must comply with NIST SP 800-171. During control selection, the practitioner notes that SP 800-171 Requirement 3.13.10 (establish and manage cryptographic keys) maps to multiple SP 800-53 controls. If the contractor implements SP 800-53 controls directly instead of SP 800-171 requirements, what is the PRIMARY risk?

Answer: The contractor's system would not satisfy DFARS 252.204-7012 compliance because the clause specifically mandates SP 800-171, and using SP 800-53 directly is not an accepted equivalency without explicit government approval.

DFARS 252.204-7012 mandates implementation of SP 800-171 for contractors handling CUI. While SP 800-171 was derived from SP 800-53 controls, the two are not interchangeable under the regulatory framework — the clause references SP 800-171 specifically. Using SP 800-53 directly without explicit contractual or government authorization creates a compliance gap with the DFARS clause, regardless of whether the security posture is equivalent or superior. Option A is partially true (SP 800-53 can be more prescriptive) but misidentifies the primary risk. Option C is incorrect — SP 800-53 is actually a superset. Option D overstates the restriction; SP 800-53 is not exclusively for federal systems.

An organization is selecting controls for a LOW-impact system and applying scoping considerations. The system is an internal employee-facing web application with no external connectivity and physically located in a secured data center with existing environmental controls inherited from facility operations. The ISSO recommends removing PE-3 (Physical Access Control) as a system-level control because it is fully inherited from the facility. The AO's security team challenges this, citing the system's dedicated server rack. Who has the stronger argument, and why?

Answer: The AO's team, because PE-3 requires system-level implementation to address access controls specific to the server rack, and inherited facility controls may not cover rack-level access.

PE-3 at the system level addresses physical access controls for the specific areas where system components reside — in this case, the dedicated server rack. Facility-level inherited controls (e.g., building perimeter, data center door access) typically satisfy PE-3 at the building/room level, but rack-level access controls (locked rack, rack access logging) are a system-specific responsibility. The AO's team is correct that the inherited facility controls likely do not fully cover rack-specific access. Option A misstates SP 800-53B; there is no blanket exclusion. Option C describes a misapplication of scoping guidance. Option D overcorrects — PE controls can be inherited when the inheritance genuinely covers the required implementation.

While tailoring a MODERATE baseline, a system owner wants to add a control from SP 800-53 that addresses a specific threat in the system's operating environment — a threat not reflected in the initial risk assessment. The new control has organization-defined parameters (ODPs) that were never configured by the organization. Which sequence of actions is correct?

Answer: Configure the ODPs using organizational risk tolerance guidance or by requesting the organization's parameter values, document the tailored control in the SSP, and assess it during security assessment.

Adding controls beyond the baseline is explicitly permitted — and often expected — when the threat environment warrants it. SP 800-37 and SP 800-53 both support this. The correct process is: configure any ODPs using organizational guidance (or request them), document the tailored addition in the SSP, and include the control in the security assessment scope. Option A is flawed because using vendor defaults for ODPs without organizational concurrence violates the intent of ODPs and may not align with risk tolerance. Option B overstates AO involvement — minor control additions don't require a new risk assessment, though judgment applies. Option D mischaracterizes the tailoring process; adding controls is a normal tailoring activity, not a special change control event.

An organization operates two systems: System A (HIGH impact) and System B (LOW impact). System B's ISSO proposes leveraging System A's AC-2 (Account Management) implementation as a common control to satisfy System B's AC-2 requirement. The organization's CISO approves this arrangement. During System B's assessment, the assessor finds that System A's AC-2 implementation does not enforce a 45-day inactive account disablement policy — a parameter System B requires based on its specific risk profile. What is the CORRECT conclusion?

Answer: System B must implement a system-specific AC-2 control or a hybrid control arrangement to address the 45-day requirement that the inherited common control does not fulfill.

When an inherited common control does not fully satisfy a system's control requirements (including ODPs), the system must implement the gap through a system-specific control or hybrid arrangement. The fact that System A operates at a higher impact level does not guarantee coverage of every parameter System B requires — impact levels reflect overall baseline stringency, not specific ODP values. Option A incorrectly assumes higher impact equals a superset of all lower-impact configurations. Option C misdirects the finding — System B has a control gap regardless of System A's posture. Option D misrepresents CISO authority; approving a common control arrangement does not override system-specific tailoring requirements or ODPs.