The Legacy Claims Application and the Compensating Control
A state unemployment agency is implementing NIST SP 800-53 Moderate controls for a benefits portal. The identity team deployed multifactor authentication for 82% of staff, but 240 caseworkers still use a legacy claims application that cannot support SAML. The vendor says a patch is 14 months away. The project team proposes marking IA-2 as implemented with a compensating control consisting of network access restrictions and supervisor approval. Encryption at rest was enabled on the primary database, but backups are written to a storage account with a separate key-management regime. Configuration scans show 37 deviations from the hardened baseline, 12 on internet-facing hosts. The system is 60 days from the authorization decision, and the plan of action and milestones has 54 open items, 9 of them high risk.
1. Evaluate the proposed compensating control for the 240 legacy users. What would you approve, and what evidence would you require?
Read the worked answer
A compensating control must provide reasonable assurance that the risk addressed by the original control is mitigated. IA-2 exists to reduce credential compromise and repudiation risk. Network access restrictions plus supervisor approval do not achieve that if an attacker who obtains a password can still log in from a permitted network segment. Supervisor approval is a human detective process and is weak at machine speed. I would not accept the proposal as written and would not mark IA-2 “implemented.” It should be “partially implemented” with a compensating control and an open POA&M item tied to the vendor patch.
What I would approve as an interim measure: place the legacy application behind an access gateway or jump host that enforces a second factor at the network layer, such as certificate-based or smart-card authentication to the gateway. Restrict the 240 users to named accounts. Add session recording and alerting on anomalous hours or bulk record access. Keep supervisor approval only as an additional detective layer. If the application cannot support individual accounts, that is a separate account-management problem and must be documented as such.
Evidence required: revised SSP, network diagram, gateway configuration, sample session logs, alert test results, user-to-account reconciliation, and a signed interim risk acceptance by the AO with the vendor patch date as the milestone. The 14-month timeline should also be challenged with the vendor in writing, because it drives how long the residual risk persists.
2. Prioritize the 54 POA&M items and the 37 configuration deviations for the next 60 days. Explain your ranking criteria.
Read the worked answer
Rank by risk to the mission and data, not by raw count or by the label “high.” I would score each item on four inputs:
- Exposure: internet-facing or reachable by low-privilege users ranks highest.
- Exploitability: known exploited vulnerabilities, default credentials, and unnecessary remote services rank above theoretical flaws.
- Data impact: benefits data includes personal and financial information, so confidentiality and integrity failures carry high impact.
- Control dependency: logging and account-management deviations undermine detection of everything else.
The 12 internet-facing configuration deviations come first, especially those involving remote access, TLS, default accounts, or unnecessary services. Among the 9 high POA&M items, I would separate true control failures from documentation gaps. A missing SSP narrative is serious, but it is not the same as an unpatched public-facing host.
The 60-day plan should have three tracks: immediate containment for the top 12, remediation sprints for high items that can be fixed by configuration change, and evidence collection for items already fixed but not documented. Items that cannot be fixed before authorization must be carried as explicit residual risk with AO acceptance, not quietly relabeled. I would also verify that backup key management is brought under the same key-management regime as the primary database, or documented as a separate risk, because backup encryption is only as strong as its weakest key path.