Categorization Dispute for a Consolidated HR and Benefits Platform
An agency is consolidating three legacy systems into a single HR-Benefits platform. The program office proposes a Moderate categorization because most users and records are administrative. The security lead notes the platform will process payroll data for 120,000 employees, store background-investigation adjudication records for 8,000 clearance holders, and expose a public benefits calculator. An agency overlay requires High confidentiality for adjudication data. The platform also connects through a cross-domain solution to a classified network for eligibility checks. The program office wants to avoid a High baseline because of cost and schedule; the CIO has asked for a defensible categorization before the design review.
1. What is the FIPS 199 security categorization for the consolidated platform? Show your reasoning, including how you handle the mixed information types, the public calculator, and the classified interface.
Read the worked answer
The overall categorization is High.
Reasoning:
- FIPS 199 requires impact analysis for confidentiality, integrity, and availability across all information types processed, stored, or transmitted by the system, then application of the high-water mark.
- Payroll data and personnel records are likely at least Moderate for confidentiality and integrity, and Moderate for availability.
- Adjudication records are High confidentiality under the agency overlay. That single High confidentiality impact drives the system confidentiality impact to High and the overall system to High.
- The public benefits calculator, standing alone, might be Low. But if it shares the same authorization boundary, database, or administrative infrastructure with the adjudication data, it cannot be used to lower the categorization. Aggregation and spillover risk must be considered.
- The cross-domain connection to a classified network is an interconnection, not a categorization escape hatch. If the cross-domain solution is inside the boundary, it is assessed at the High water mark. If it is a separate system, the interconnection still must be documented, and the connected system's categorization and controls must be considered for spillover and trust.
The categorization package should identify each information type, the provisional impact from the agency's information-type mapping, the final impact by security objective, the high-water mark rationale, the authorization boundary, and the approving official's signature.
2. The program office asks whether it can keep the platform at Moderate by labeling the adjudication data as a separate 'enclave.' What would you advise, and what would need to be true?
Read the worked answer
Labeling data as an enclave does not change the categorization by itself. A lower categorization for the general platform would be defensible only if the agency creates a genuinely separate authorization boundary for the adjudication enclave and can demonstrate that the enclave cannot be used to compromise or spill into the Moderate platform, and vice versa.
That would require, at minimum:
- A documented boundary with separate hardware, virtual networks, identity stores, administrative accounts, and logging where feasible.
- Strict access controls and data-flow rules between the enclave and the Moderate platform, including cross-domain or API controls, monitoring, and spillover prevention.
- A separate FIPS 199 categorization for the enclave at High and a separate authorization package or a clearly documented shared-controls arrangement.
- AO and CIO approval of the boundary and interconnection risk.
Cost and schedule are not valid reasons to lower an impact rating. If the systems remain technically or administratively inseparable, the high-water mark applies to the whole platform. A 'paper enclave' that shares the same databases, domain admins, or hypervisor would likely be treated as one boundary.
3. How should the public benefits calculator and the cross-domain connection be treated in the categorization and boundary documentation?
Read the worked answer
Treat both explicitly in the boundary and data-flow documentation.
Public calculator: If it only serves public information and is isolated from sensitive data, it could be categorized Low on its own. But if it queries the same backend, shares web infrastructure, or can be used as a pivot into the sensitive platform, it must be included in the High boundary. The documentation should show whether it is a separate system, a subsystem, or a front end, and why its categorization does or does not affect the high-water mark.
Cross-domain connection: Document it as an interconnection with source and destination, data types, direction, security controls, and spillover risk. If the cross-domain solution is part of the platform, it inherits the High categorization. If it is external, the agency still needs an interconnection agreement or equivalent, and the platform's SSP must describe controls such as SC-7, AC-4, and audit/monitoring. The connection to a classified network may also bring national-security overlay requirements into scope. The key judgment is that neither the public calculator nor the classified interface can be waved away as 'out of scope' without a documented boundary decision approved by the AO.