Federal Government Agencies and their Contractor System Maintainer System Security Officer (SSO) teams are primarily focused on the logistics of the compliance exercise of obtaining and maintaining Authority To Operate (ATO) for Agency Federal IT Systems, via the participation in controls assessments, penetration tests, and audits, as opposed to identifying, communicating and managing the risks that any given Information System contains (every system does have known weaknesses and risks as no system is ever completely secure). Even if the risk management activities are the stated objectives, the reality is most of the time and effort for Government and Contractor SSO teams goes into audits/tests, findings and POAMs.

In short, SSO teams often succeed or fail by the existence of audit findings, and much of their current management of risk is in the context of whether a known weakness will become a finding in an audit, rather than the likelihood it could be exploited, leading to a system intrusion or data breach, for example.

So, does that mean that is a problem for agencies? Not necessarily, if their workflow of documenting systems and control compliance, performing audits and tests, documenting findings, remediating weaknesses, and providing closure evidence is mature and strong. Moreover, the NIST Special Publication 800-53 security and privacy control requirements, as written or in Agency-tailored versions, are a valuable means to an end of managing risk by providing IT and Security teams clear and consistent guidance for hardening Federal Information Systems.

Nevertheless, expecting external third-party auditors to uncover administrative or technical weaknesses given limited prior knowledge of a business process or its Information Systems means there will always be things that they simply do not have the deep understanding of, or time, to uncover during a controls assessment.

As it happens, agencies such as Department of Homeland Security DHS via its Continuous Diagnostics and Mitigation (CDM) Program are driving more centralized collection of data across agencies that is driving a shift from pure compliance to continuous management of risk, through data feeds of system and application event logs, network traffic meta data, hardware and software assets, user account activity etc.

Going forward, SSO teams will have to focus less on the process of obtaining an ATO and more on the quality of data being fed to central Security Operations Centers (SOCs) and on managing the risks that insight into that data reveals.

Despite what I have said about the move away from pure control compliance and audits, in order to facilitate these initiatives SSO teams can still look to NIST controls for guidance. For example, in the context of CDM, by reviewing how their systems meet the following NIST SP 800-53 Rev. 5 controls, including all control enhancements:

• AC-2 ACCOUNT MANAGEMENT
• AU-2 EVENT LOGGING
• AU-3 CONTENT OF AUDIT RECORDS
• AU-6 AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING
• CA-7 CONTINUOUS MONITORING
• CM-7 LEAST FUNCTIONALITY
• CM-8 SYSTEM COMPONENT INVENTORY
• RA-5 VULNERABILITY MONITORING AND SCANNING
• SI-2 FLAW REMEDIATION
• SI-3 MALICIOUS CODE PROTECTION
• SI-4 SYSTEM MONITORING

Further reading:

DHS Continuous Diagnostics and Mitigation (CDM)

NIST SP 800-53 Rev 5: Security and Privacy Controls for Information Systems and Organizations

A version of this article was first published in the CMS ISSO Journal ISSUE 14 October-December 2020.