Under the 2013 DFARS rule contractors are required to, “safeguard unclassified controlled technical information resident on or transiting through contractor unclassified information systems.” By contrast, under the 2015 and 2016 rules the contractors are required to, “safeguard covered defense information that resides in or transits through covered contractor information systems . . . “ Thus, while all rules require the protection of data that is resident on or transiting through contractor information systems, the 2013 rule applies to Controlled Technical Information (CTI) while the 2015 and 2016 rules apply to Covered Defense Information (CDI).
The simplest explanation of the difference between the two rules is that CDI under the 2015 and 2016 rules is a broader category than CTI under the 2013 rule for two reasons. First, the definition of CDI in the 2015 and 2016 rules include CTI as well as other data categories. Second, there are also differences in the definitions of both CDI and CTI between all three versions of the rules. Each of these differences, the nuances between them, and the systems in which they are resident or transiting are discussed more fully in the sections that follow.
Unlike the rules governing classified data, which function to protect all classified data, the new rules do not apply to all unclassified data. Rather, they apply to only certain unclassified data that has been identified as worthy of protection. Thus, even though the new clauses are required in every defense contract, their requirements for security controls and incident reporting are triggered only if the covered data resides or transits through the contractor’s information systems. Consequently, a first step to understanding the requirements of the rule is understanding to what kinds of data the controls and security standards apply.
Amazingly, the types of data to be protected are different for the 2013, 2015 and 2016 versions of the DFARS rule. The difference is both obvious and immediate since it appears in the first paragraph of the scope section, DFARS 4-7300(a) of the respective rules. The following sections explain the difference between the different rule versions and differences in the data to be safeguarded.
The term CDI did not appear in the 2013 version of the rules. The term CDI only appears in the 2015 interim rule and the 2016 final rule. Under both the 2015 and 2016 rules, CDI is the category of data which should be safeguarded.
CDI is more expansive than CTI because the definition of CDI includes CTI as well as other types of data. Although CDI appears in both the 2015 and 2016 rules, there are differences between them, too. In the 2015 version of the rule, CDI includes CTI as well as three other data types. The other three data types are critical information, information related to export controlled items, and any other information identified in the contract. Under the 2016 version of the rule there are only two types of data comprising CDI. Those two data types are CTI and other information described in the CUI registry.
Despite that the 2016 version has only two data types, the 2016 version of the rule is likely still the broadest of any of the three rule versions. The reason it is probably broader is because the list of protected data in the CUI registry is likely more comprehensive than whatever would have been captured in the other categories of critical information, information related to export controlled items and any other information identified in the contract. Even if the CUI registry is the equivalent of critical information, providing a catalog of critical information like the CUI registry is more helpful and definitive than the amorphous definition that of critical information that had appeared in the 2015 rule.
Beyond the definitional issues related to data types, there are some other important differences between the 2015 and 2016 versions of the rules that determine what data is actually covered. These other differences involve whether the data is marked or otherwise identified in the contract and whether it is, “collected, developed, transmitted, used or stored by or on behalf of the contractor in support of the performance of the contract.”
In the 2015 rule, the definition of CDI did not include marking except in the definition of CTI. In the 2015 version, the definition of CTI is quite permissive with respect to marking. In other words, under the definition of CTI the data need not be marked. Rather, it only needs to meet the criteria for marking under DoDI-5230-24 whether or not it actually is marked.[EN-1] This is discussed further in subsequent sections on the definition of CTI.
While the definition of CTI is still quite permissive with respect to marking in the 2016 version of the rule, a requirement that CDI itself be marked or otherwise identified in the contract was included.[EN-2] Since CDI trumps CTI, this provision helps to narrow when the safeguarding requirements are actually triggered.
Unfortunately, despite the marking or identification requirement in the 2016 definition, there is still one element that acts as a big net that can still trigger the safeguarding requirement. Under the 2016 version, the CDI definition also applies to data that is “collected, developed, received, transmitted, used or stored by or on behalf of the contractor in support of the performance of the contract.” Thus, it need not be marked or identified in the contract. It simply needs to be CTI or other information described in the CUI registry and then,[EN-3]
This criteria existed in the 2015 definition as well. It was also a provision that significantly broadened the safeguarding requirement from the initial requirements in the 2013 version. The fact that it still exists in the 2016 version means that the definition of CDI remains quite broad despite the other limiting requirement that the data be marked or identified in the contract.
Where this requirement gets broad is that it is not limiting to the government’s data that might have been “collected, developed, received, transmitted, used or stored by or on behalf of the contractor in support of the performance of the contract.” Since it does not have any kind of limiter other than CTI or other data listed in the CUI registry, this part of the definition also captures sensitive, proprietary or trade secret of the contractor if it otherwise meets the definition of CTI or other data described in the CUI registry.
The categories of CTI, critical information and export control information are discussed further in the sections below.
The term Controlled Technical Information (CTI) means technical information with military or space applications that is subject to controls on access, use, reproduction, modification, performance, display, release disclosure or dissemination but does not include information that is publicly available without restriction. The definition appears in the 2013, 2015 and 2016 versions of the rules. It is somewhat a complex definition comprised of three parts and all three parts must exist. Thus, it is not enough that the data qualify as technical information if it does not have a military or space application or if it is not also subject to control even if it does have a military or space application.
The first and second parts of the definition relating to technical information and military or space applications are identical under all versions of the rules. The third part, however, has a subtle difference with significant consequences. Each is discussed below.
The term technical information is defined in all versions of the DFARS rules. All versions define technical information as “Technical Data or Computer Software” as those terms are defined in the DFARs clause, 52.227-7013 on Rights in Technical Data-NonCommercial Items whether or not that clause is included in the contract.
Under DFAR 52.227-7013, the term “Technical data” means recorded information, regardless of the form or method of the recording, of a scientific or technical nature (including computer software documentation). Thus, the term would include drawings of manufactured items, manufacturing or assembly processes, test results, basic or applied research, analytic processes or algorithms, accumulated data or results, etc. The term does not include computer software or data incidental to contract administration, such as financial and/or management information.
While computer software is not included in the definition of technical data described above, it does fall under the broader category of technical information that is subject to control under both versions of the DFARs rules. Also under DFAR 52.227-7013, the term “Computer Software” means computer programs, source code, source code listings, object code listings, design details, algorithms, processes, flow charts, formulae recompiled. Computer software does not include computer data bases (meaning the data accumulated in a software application). Data bases would be covered by the previous category of technical data. Similarly, computer software documentation (meaning administration and operating manuals as compared to design details which are subject to control) are not subject to control.
While administration and operating manuals do not fit the definition of technical information, they are a kind of data that could be marked and subject to control under DoDI-5230-24. Thus, administration and operating manuals are an example where all three parts of the definition are not met. While they could be marked under DoDI5230-24, they do not meet the definition of technical data. Thus, they are not the kind of data that is subject to control under either version of the DFARs rules.
The second significant part of the definition for CTI is that it has a military or space application. There is nothing in the rule that defines a military or space application. Furthermore, there is nothing that limits the terms military or space application to weapons systems likes tanks, planes or ships or to vehicles like space craft. One must conclude therefore that if it has use by the military or in some space related function whether directly on a weapons system or space vehicle or even indirectly in support of those end items or missions that it has military or space application.
The limitation to military or space application may not be much of a limiter. To illustrate, would a normal commercial laptop computer have military or space application if it was being used by the military or a space agency either directly in an operational capacity or indirectly to support operations or even administer the organization? Most likely the answer is “yes”. Thus, the definition for military or space application is actually quite broad and not as narrow as one might think.
The third set of key terms that define CTI are “subject to controls on the access, use, reproduction, modification, performance, display, release, disclosure, or dissemination.” This phraseology, “subject to controls”, is also quite broad, since there are many ways that data could be subject to controls.
The first way that data could be subject to controls is under some other statute or regulation such as items on the United States Munitions List (USML) that are controlled by the International Traffic in Arms Regulations (ITAR). ITAR as well as other statutes and regulations are discussed further in a subsequent section below.
Another way under the two DFARs rules that data could be subject to controls is if it was explicitly marked with one of the distribution statements B through F for control in accordance with DoD Instruction (DoD-I) 5230-24, which establishes the framework and markings for managing, sharing, safeguarding, and disseminating technical documents in accordance with policy and law. Exhibit 1 contains Table 5 from DoD-I 5230-24 which summarizes the various codes and when each are to be applied to controlled documents.
Notice that code A means that the data is approved for public release. Thus, any data marked with code A is not subject to control nor either of the DFARs rules, since data that is available to the public without restriction is not subject to the rules. Both the 2013 and the 2015 versions contained this exemption for CTI.
Considering that the length of many government programs can be quite long, the life of data secrets may not be as long. In addition, products can be reversed engineered and their data secrets determined and published.
While the data availability provision provides identical sunset provisions to the effectiveness of both the 2013 and 2015 rules, there is still uncertainty about whether data is “available publicly without restriction.” Certainly, if the original developer of the data publishes it without restriction there is no ambiguity. Similarly, if the data is marked with code A there is no ambiguity that the data is not subject to control.
The uncertainty arises when it is published by someone other than the original developer as a result of reverse engineering, for example. In that case, is protection of the data still required? Who would be the final arbiter of whether all of the data has actually been uncovered and revealed?
Other than the category of publicly available or public release, there are thirteen other categories of data that could be marked under DoDI-5230-24. Most are inherently governmental such as Direct Military Support, Contractor Performance Evaluation, and Operations Security. Yet some are unique to contractors such as Proprietary Information. All of these would be marked with codes B through E and are for data that is subject to control however and are subject to control under either of the DFARs rules.
Code F is a special code that applies to data whose distribution is limited only to that authorized by the controller office.
Under the 2013 version of the DFARs rule, the data subject to control would be obvious since it is data that is marked in accordance with DoDI-5230-24. Thus even proprietary data that is subject to control under the rule would only be proprietary data that is marked, which would most likely be some other contractor’s proprietary data that had been provided to the another contractor by the government.
Under the 2015 rule, however, covered data is not limited to data that has been marked, since the 2015 rule expands the definition of covered data to data that would be marked. Thus, data that never leaves a contractor’s facility and is never marked by government personnel would still be covered and would still be data that is subject to control provided that it has a military or space application. Unfortunately, the criteria that data have a military or space application may not be much of a limiter either, particularly if even indirect support functions are included.
Under the 2013, 2015 and 2016 versions of the rule, controlled technical information is data with military or space application that is subject to controls on the use, access, reproduction, modification, performance, display, release, disclosure or dissemination. Where there is a difference between the rules is whether the information is marked.
While the 2013 requirement is limited to marked data, the 2015 and 2016 requirement extends to both marked data as well as unmarked. Thus, the 2015 and 2016 rule not only applies to GFI provided to the contractor or developed under the contract but could also apply to the contractor’s own sensitive, proprietary or trade secret data meeting the definition of CTI or the descriptions of other data types listed in the CUI registry as long as the data was “collected, developed, received, transmitted, used or stored by or on behalf of the contractor in support of the performance of the contract.”
Critical information is another of the four categories of data that comprises the definition of CDI under the 2015 rule While the category of critical information is included under the 2015 rule, it does not exist under the 2013 rule. In the 2016 rule, it was replaced with “other information” described in the CUI registry that requires safeguarding or subject to controls.
Under the 2015 rule, critical information are specific facts identified through the Operations Security (OPSEC) process about friendly intentions, capabilities, and activities vitally needed by adversaries for them to plan and act effectively so as to guarantee failure or unacceptable consequences for friendly mission accomplishment. Critical information is not about technology in the way that CTI was about technical data and information. Rather, critical information is the results of our own OPSEC processes, which look at ourselves in order to learn what information is openly available but would be useful to an adversary. The OPSEC process then develops methods for protecting that information from an adversary. Critical information, therefore, is the results learned from the OPSEC process.
Critical information would likely be marked or could be marked under DoDI-5230-24 B through F under several different data categories described in that instruction.
Export controlled information is another category of data that comprises the definition of CDI. The category of export controlled information is included under the 2015 rule but does not exist under the 2013 or 2016 versions of the rule.
Export control information is defined as unclassified information concerning certain items, commodities, technology, software, or other information whose export could reasonably be expected to adversely affect the United States national security and nonproliferation objectives. Export control information includes dual use items (items with both civilian usage as well as weapons of mass destruction or conventional weapons usage) controlled by Export Administration Regulations (EAR), item on the USML governed by the ITAR, license applications; and sensitive nuclear technology information.
While, as a result of specific references to EAR, ITAR and nuclear technology information, export control information may have a more precise definition than “information with military or space applications” under CTI, it is hard to imagine that anything in this category would not also be covered by the broader CTI category. If there is something this category adds to the definition it might be that the CTI category includes potentially marked information while there is no such condition for this category. The apparent duplicative nature of this element of the CDI definition in the 2015 version of the rule is likely why it was removed from the 2016 version.
Other information is a fourth category of CDI under both the 2015 and 2016 versions of the rule. It is not part of the definition for CTI and, thus, is not part of the covered data under the 2013 version of the rule.
There are some significant differences between the 2015 and 2016 versions of the rule and the definition of other information. Under the 2015 version other information is any other information that is marked or identified in the contract, whether marked or not marked, that requires safeguarding or dissemination controls. Clearly, under the 2015 rule other information can be quite narrow since it must either be marked or appear in the contract.
The definition of other information in the 2016 version further narrowed the definition to require that other information also appear in the CUI registry that is maintained by NARA.[EN-4] Thus it is not enough that the data be marked or identified in the contract. Indeed, it must also appear in the CUI registry.
While the 2016 version narrows the definition of other information with the CUI registry requirement it then lessens the marking or identification requirement by adding an additional criterion that the information can also be information that is, “Collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the contract.” Thus, if the data appears in the CUI registry it must also meet either the marking or contract identification requirement or it simply be, “Collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the contract.”
In the end, contractors may not find much relief from the CUI registry requirement when determining other information. The information descriptions in the CUI registry are quite generic and broad. Thus, while the CUI registry requirement may help to narrow what data is other information and subject to the protection standards, it may still represent a big net that ensnares all kinds of information and subjects the contractor to the protection standards and compliance related risk.
There simply has not been as much attention paid to what constitutes a contractor information system or even residency on or transiting through those systems as their has with the covered data and even the security standards. As with every other part of the DFARS rule, there has been considerable variation in this part of the rule as well.
All three versions of the DFARS rule contain a definition of Contractor Information System. The definition is simply, "An information system belonging to, or operated by or for, the Contractor. This is so vanilla, though, that it is not very helpful.
In 2015 version of the DFARS rule the definition was added for a Covered Contractor Information System. That definition is, "An information system that is owned, or operated by or for, a contractor and that processes, stores, or transmits covered defense information." This definition was also included in the 2016 version. It is a little more helpful, since it starts to make clear that the requirements apply to the data and not the network..
In 2016 a definition was added for an Information System. The definition is, "A discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information." The 2016 version of the rule is the only version where a definition of an information system was provided.
The above definitions would seem both logical and intuitive. The significance of these provisions may not be as obvious, however. The significance of these provisions is more obvious when one realizes that the focus of the rules and all the various versions is that safeguarding applies to the data and not the network. Indeed,safeguarding of the network only applies if CUI resides on that network or is transmitted through it. As a result contractors wishing to practice better risk management can identify their covered data and narrow the network or at least segment the network to portions with covered data and portions not having covered data.
There have been three versions of the DFARS rules issued that applied to contracts.. Each version had its own unique definition of the data that qualified for protection.
Under the 2013 version of the rule the data required to be protected was identified as Controlled Technical Information (CTI). In later versions of the rule, CTI was still covered but other types of covered data were added. The new name given to the expanded data was Covered Defense Information (CDI).
While both the 2015 and 2016 versions of the rule retained the name CDI, the composition of CDI was different for each version. While CTI was unchanged, it was the other data categories where the changes were made.
Understanding what data is covered is important for two reasons. First, it is clear that not all data must be protected. In fact, not even all contract data that a defense contractor might possess while performing its contracts. Rather, only certain data must be protected. As a result, the first step every defense contractor should take is determining exactly what data it has that must be protected. Once that is determined, contractors might find that the requirements for safeguarding CUI are not as significant as was once thought. Also, as the compliance issues surrounding safeguarding CUI continue to escalate contractors could find that they significantly reduce their compliance risk.
Second, the CUI requirements are about protecting data and not about protecting networks, in general. Since a contractor's network could extend across the entire organization, once the CUI data target is significantly reduced, contractors could find that they can further reduce their compliance risk and their cost of compliance by segmenting their networks. In fact, CUI data is likely limited to engineering and manufacturing areas of a contractor's organization. Thus, segmenting those areas could significantly reduce a contractor's compliance risk and cost.
The next part in this series of articles on safeguarding CUI is on the Security Standards.
The previous part in this series of articles on safeguarding CUI is on Understanding the Road to the DFARS Safeguarding CUI
EN-5 - For the CUI registry category list see, https://www.archives.gov/cui/registry/category-list.