Celestial Defense of Atlanta Georgia is a highly skilled and experienced provider of expert consultant computer security and computer forensic services involving:
Contact us to speak with one of our government contract consultants to learn how we can help you or call 770-777-2090.
For decades DoD has imposed security requirements for safeguarding classified information on its contractors by way of the National Industrial Security Program (NISP) but the safeguarding of unclassified information is not covered by that program. The security controls for unclassified information are based on standards like the NIST SP 800-53 standards. Since the development of the NIST SP 800-53 standards, they have also been integrated into security standards for classified information under CNSSI [Committe on National Security System Instructions] 1253. As a result, these days the requirements for protecting classified and unclassified data have many similarities.
CNSSI 1253, Security Categorization and Control Selection for National Security Systems, contains a subset of the NIST SP 80-53 controls and provides the first two steps of the Risk Management Framework (RMF) for national security programs. There are a number of drivers for national security systems, since the classified data security requirements are also based on Executive Orders (EO) and Intelligence Community Directives (ICD).
DoD’s expanded interest in data security for unclassified information follows an expanded government wide interest in protecting unclassified information. In fact, the federal government’s interest in safeguarding unclassified information has grown dramatically since 2000, at least unclassified data on its own systems.
In 2000, the primary direction for the protection of unclassified information was memorialized in OMB Circular A-130, which focused on the management of federal information resources. Since 2000 there have been several significant initiatives related to cyber security in general and Controlled Unclassified Information (CUI) in particular.
In 2002 the Federal Information Security Management Act (FISMA), also known as the E-Government Act, was enacted to provide a framework for the development and maintenance of minimum security controls to protect federal information systems. The Act required the head of each agency to implement policies and procedures to cost-effectively reduce information technology security risks to an acceptable level. The process was to be overseen by the Director of OMB who would report at least annually about agency security practices and policies and approve or disapprove agency information security programs.
In 2014 FISMA was replaced by the Federal Information Security Modernization Act (FISMA 2014). It made several notable changes to the 2002 FISMA legislation. First, the law authorized the Secretary of the Department of Homeland Security (“DHS”) to assist the OMB Director in administering the implementation of agency information and security practices for federal information systems. Second, the law changed the agency reporting requirements, modifying the scope of reportable information from primarily policies and financial information to specific information about threats, security incidents, and compliance with security requirements. Third, the law updated FISMA to address cyber breach notification requirements.
While the above measures addressed safeguarding federal systems and the information they contained, the measures were still somewhat decentralized and left to individual agency interpretation, implementation and monitoring. The result was a confusing patchwork of inconsistent policies and practices.
In order to remove the confusion, at least for unclassified information, Executive Order (EO) 13556 was issued on November 4, 2010. While EO 13556 centralized the oversight, it did not do much else to remove the confusion. For example, there is no definition of CUI in EO 13556 nor any provision for security standards for safeguarding CUI. About all EO 13556 did was recognize the issue and designate the National Archives and Records Administration (NARA) as the government’s executive agent for CUI.
In addition, there was no clear boundary established for NARA’s management and oversight of CUI. In other words, there was no distinction for whether NARA’s management and oversight applied only to executive agencies or whether it extended to executive agency contractors or even if it extended to the private sector as a whole.
In addition, it did not describe the data to which it applied other than to say it was information “that requires safeguarding or dissemination controls pursuant to and consistent with law, regulations, and Government-wide policies, excluding information that is classified under Executive Order 13526 of December 29, 2009, or the Atomic Energy Act, as amended.” Thus, it did not distinguish between government owned data, which it had an ownership interest in protecting, or other data that it not only did not own but may not even use, like proprietary data of commercial contractors and perhaps even other private sector businesses.
CUI was simply the designation given to “unclassified information throughout the executive branch that requires safeguarding or dissemination controls, pursuant to and consistent with applicable law, regulations, and Government-wide policies,” whatever that meant. While such language would seem to apply only to the executive branch, there are numerous other kinds of arms and export control statutes that ensnare all kinds of commercial businesses who are not executive agency contractors.
Both versions of FISMA and EO 13556 authorized the National Institute of Standards and Technology (NIST) to develop standards for the control and security of federal information systems and CUI. Over the years NIST has been quite busy and authored a number guides and standards. A few of the more notable NIST publications are:
The DoD’s process for extending CUI requirements on its contractors began with a proposed rule in 2011 that was then made a final rule in August 2013. This was before NARA, the executive agent for CUI, ever issued any rules or standards, although NARA had requested NIST to develop a set of security standards. It was also before NARA had promulgated any of its own rules governing federal contractors, although it had indicated that a single FAR [Federal Acquisition Regulation] wide rule would likely be proposed in 2016. In fact, a final rule was published in May 2016 that added requirements to FAR 4.1900, 7.105, 12.301 and the contract clause at FAR 52.204-21, 52.213-4, and 52.244-6.
Prior to DoD finalizing its DFARS rule in 2013 several respondents during the public comment period for that proposed rule expressed concerns that the DoD rule was premature in establishing standards, since a government wide CUI policy in response to EOI 13556 had not yet been formulated. Those respondents feared that the DoD rule could be misaligned with the final CUI requirement. As it turns out, that was exactly what happened.
In late 2015, after the publication in June 2015 of the NIST SP 800-171 standards on protecting CUI in nonfederal information systems and organizations, DoD issued revised DFARS rules without public comment. The 2015 DFARs rule was significantly different from its 2013 version. The differences ranged from the replacement of its earlier CUI security standards, that were based on 51 of the NIST SP 800-53 standards, with the newly published NIST SP 800-171 CUI standards that contained 102 security controls. The 2015 rule also expanded the rule’s coverage from just contractor information systems to cloud based computing services as well. The expansion to include cloud based services as well was clearly in response to OMB’s 2011 policy initiative in that area.[EN-1] The 2015 rule also made other definitional changes that were significant. As a result, DoD renamed the rule governing its CUI efforts from “Safeguarding Unclassified Controlled Technical Information” to “Safeguarding Covered Defense Information”.
If there was any good news for contractors, it was that the NIST 800-171 controls imposed by the 2015 rule update were later determined to be so significant and require such extensive efforts by contractors to implement that another interim DFARS rule was issued on December 30, 2015 that gave contractors until December 2017 to upgrade their systems to meet the NIST 800-171 requirements. The grace period does not affect the 2013 requirements, however. Thus, contractors exposed to the 2013 requirements must still abide by them until their contracts with those provisions are formally closed out, which, depending on the contract type, could be years after final performance.
Remarkably, in October 2016 DoD issued the final rule for its 2015 proposed rule. The final rule also had some differences from the interim rule. Fortunately, the differences mostly narrow the rule’s requirements and applicability. For example, one significant difference is that the rule is not an automatic flow down by upper tier contractors to their subcontractors. Rather, upper tier contractors are supposed to make an assessment of whether their subcontractors will be handling in any CDI and then only flow down the requirement if it is determined that they will be handling CDI.
For contractors other than cloud based computer service providers, there are now three sets of DoD rules involving protection and safeguarding of CUI, a 2013, 2015 and a 2016 DFARS version. Furthermore, since the requirements are imposed on contractors by way of contract clauses, it is possible that contractors could be subject to all three sets of rules if they have a contract mix where some contracts contain the 2013 DFARS rule requirements while others have the 2015 DFARS rule requirements and still others have the slightly different 2016 DFARS requirement.
In essense, the DoD was the first federal agency to impose requirements for safeguarding CUI on its contractors. The process began in 2011, shortly after passage of ED 13556, with the publication of a proposed rule. While the proposed rule was not being included in contracts, the rule was finalized in 2013 and it imposed safeguarding requirements of CUI on contractors at every tier including commercial items. Thus, starting in November 2013 every award of defense contract would have the safeguarding requirements. In addition, those requirements would be passed down to subcontractors at every tier.
DoD’s efforts were well ahead of NARA, the government’s executive agent for managing EO 13556 and the government’s initiative for protecting CUI in non-federal organizations like federal contractors. Once NIST published its standards for the protection of CUI in non-federal organizations in May 2015 in its Special Publication 800-171, it was obvious that DoD’s requirements for safeguarding CUI were severely misaligned. As a result, DoD published another interim rule later in 2015 that both updated its information security controls for contractor information systems but also expanded the coverage to cloud computing services under FedRAMP, another initiative being managed by OMB. The expanded coverage was considered so burdensome that in late December 2015 contractors were given until December 31, 2017 to comply.
DoD’s 2015 rule was finalized in late 2016. Several more changes were made to both definitional aspects of the rule as well as its coverage. The definitions were streamlined. They were also made more tangible with inclusion of the CUI registry as an added source for identifying the covered data. With respect to coverage, it was scaled back such that the requirements were no longer an automatic flow down to subcontractors. Rather, primes and upper tier subcontractors would make an assessment about whether covered data would even be involved with their subcontracts before including the requirements in the subcontracts.
While the 2016 final rule narrows the safeguarding requirements, there are still aspects about the coverage that are still beyond the intended scope of the initiative. The government’s interest in safeguarding CUI is to extend the protection to the systems of non-federal organizations so that the CUI data is similarly protected regardless of the actual environment.
Despite the intentions, the protection of CUI in non-federal organizations is defined such that it extends beyond the government’s data and into sensitive, confidential and trade secret data of the contractor if that data is CTI or other data listed in the CUI registry and it is “collected, developed, received, transmitted, used or stored by or on behalf of the contractor in support of the performance of the contract”. While this could be a direction in which the country wants to move, it is beyond the intentions of the initiative as described in the NIST SP 800-171 standard. In NIST SP 800-171 it was stated that, “The protection of unclassified federal information in nonfederal information systems and organizations is dependent on the federal government providing a disciplined and structured process for identifying the different types of information that are routinely used by federal agencies.” Thus, the CUI initiative was about protecting federal CUI residing, transiting or being stored in non-federal information systems.
As part of its safeguarding objective, the new rules include a reporting requirement on contractors whenever their information systems involving CUI are compromised. The reporting requirement is not limited to whether the CUI was actually altered, destroyed or taken. Indeed, it extends to any kind of improper access.
At least for now, the reporting requirement is not intended as a means to identify a safe guarding non-compliance. In fact, the rules make clear that a compromise is not evidence of non-compliance.
The purpose of the reporting requirement is simply part of the government’s monitoring effort to ensure that CUI is safeguarded by monitoring trends and techniques. Undoubtedly, however, those who are more skilled at contract administration than cyber security are sure to misunderstand the reporting requirement and want to link it with some kind of punishment.
All of the CUI safeguards will assuredly change in the future. As the reporting results come in there are likely to be changes in the specific security controls that will be required. There could even be an entire rethinking of the implementation since it provides for the protection of CUI only while a contract is being performed. There is ample concern for the protection of CUI even whether or not a contract exists or the organization is even a contractor. Of course, that could depend on exactly how CUI is defined. As of now, numerous products are controlled and prevented from export. There is an interest in protecting their data whether or not a contract is involved.
The next part in this series of articles on safeguarding CUI is on the Covered Data Requirements.