Cloud Security and Compliance for US Federal and DOD Contractors
NIST SP 800–171 is targeted towards non-federal entities (such as government contractors, state and local agencies, etc.) with IT systems containing sensitive federal information. It focuses on protecting the confidentiality of Controlled Unclassified Information (CUI) in nonfederal systems and organizations, and recommends specific security requirements to achieve that objective where the confidentiality impact level is a moderate. Federal systems are required to follow FIPS Publication 200 and NIST SP 800–53 among others. The requirements set forth in SP 800–171 can be used by federal agencies in contracts and other agreements with non-federal organizations. The US Department of Defense has amended the regulation governing acquisitions to require non-federal agencies conducting business with DOD to adopt NIST SP 800–171. Under DFARS 252.204–7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, contractors with information systems that contain or transmit covered defense information are required to provide “adequate security” on contractor information systems for covered defense information.
SP 800–171 used the security controls in the moderate baseline (i.e., the minimum level of protection required for CUI in federal systems and organizations) of SP 800–53 to tailor (add, modify, eliminate) requirements, controls, or parts of controls that were:
- Uniquely federal (i.e., primarily the responsibility of the federal government);
- Not directly related to protecting the confidentiality of CUI; or
- Expected to be routinely satisfied by nonfederal organizations without specification.
The result is 110 security requirements broken up into 14 control families. Each family contains any number of basic security requirements and derived security requirements. SP 800–171 contains a mapping to the SP 800–53 security control in order to provide additional non-prescriptive information about the requirements.
Nonfederal organizations finding themselves on the receiving end of this publication should realize that these requirements only apply to the components of their systems that actually process, store, or transmit CUI, or that provide security protection for such components (e.g. general support systems/components). These organizations should identify and designate the specific systems or components for the processing, storage, or transmission of CUI, in order to limit the scope of the requirements to only those systems or components.
One cost-effective and efficient method to accomplish this can be done by isolating CUI into its own security domain by applying architectural design concepts such as subnetworks with firewalls or other boundary protection devices. Implemented correctly and up to the high watermark of requirements imposed by the different agencies. Further, for nonfederal organizations that do not have the internal resources or expertise to adequately comply with the NIST SP 800–171 should consider authorized services such as Cloud platforms that have received Federal and DOD authority to operate (ATO) through the FedRAMP program. Given that cloud platforms such as AWS and AWS GovCloud have achieved the requisite compliance status with NIST SP 800–53 at the Moderate and High (AWS GovCloud) levels, organizations can reduce their compliance burden by exploring the adoption of compliant platforms.
The SP 800–171 requirements must be documented in a Security Plan. The Security Plan should describe the implementation of how each security requirement is implemented. It should also describe the system boundary, the operational environment, and the relationships / interconnections with other systems. The boundary should identify the information resources used to process, store, or transmit CUI. For example, the operating systems, databases, applications, and network infrastructure. It should also identify the versions, quantity, and locations of the equipment. This will provide a scope for what is contained within the Security Plan. The operational environment should briefly describe the technical environment and briefly describe each of the technical components making up the system. The relationships and interconnections section should describe any interconnections with other systems. It should identify the name of the interconnected system, the type of interconnection, and the purpose / nature of information being shared.
The organization should also create a plan of actions document that describes how any security requirements that are not currently implemented will be met in the future and how any planned mitigations will be implemented. This should be specific enough to identify the affected component, the details of the remediation, and the approximate due date for completion. There is no specified format for these documents. Organizations can document the system security plan and plan of action as separate or combined documents and in any chosen format. When requested, the system security plan and any associated plans of action for any planned implementations or mitigations should be submitted to the responsible federal agency/contracting officer to demonstrate the nonfederal organization’s implementation or planned implementation of the security requirements.
Interested in learning more? Please join us for our Security by Design MicroSummit on Oct 27, 2017.