Contents

Inquiries

Celestial Defense of Atlanta Georgia is a highly skilled and experienced provider of expert consultant computer security and computer forensic services involving:

• Incident response
• Forensic Grade Imaging and preservation
• Forensic examination and analysis of servers, workstations, laptops, phones, and other storage devices and media
• File system analysis
• File activity and usage analysis
• Device system analysis
• Intrusion analysis
• Internet usage analysis and web page reconstruction
• Social media and text messaging recovery & analysis
• File deletion activity analysis and data recovery
• Compliance with organizational, contractual or regulatory requirements like DFARS 4.7300 and 52.204-7012 and NIST 800-171 governing the safeguarding of CUI
• Database analysis
• Software analysis
• Data security process, procedures and systems consulting
  • Systems hardware design, selection, construction and installation
  • Process design, implementation and integration
  • Policy and procedure development
  • Training and process monitoring

To speak with one of our government contract consultants to learn how we can help you click below or call 770-777-2090.

Contact

Untangling the Governing Set of Security Standards for
Controlled Unclassified Information (CUI)

by: Gregory L. Fordham

Under all versions of the DFARS rules contractors are required to provide adequate security to safeguard the covered data. The security systems and controls, that are used by the contractor to adequately safeguard covered data, are required to meet certain minimum standards that are prescribed by the contract clauses.

The 2013 rule requires only 51 security controls from the NIST SP 800-53 standard. Those standards are to be applied, however, only to its own systems.[EN-1] Thus, even though the definition of a contractor information system is quite broad, as discussed previously, these controls only apply to the contractor’s own information systems.

The 2015 interim rule issued across several months in the fall of that year and the 2016 final rule issued in October of that year prescribe standards for both contractor information systems as well as cloud computing service providers. With respect to contractor information systems the 2015 and 2016 versions impose the NIST SP 800-171 security standards. The NIST SP 800-171 standards contains 109 controls which can be mapped to 124 of the NIST SP 80-53 standards.

With respect to cloud computing service providers under the 2015 and 2016 versions, the applicable standards are different for cloud service providers used by DoD versus those being used by a contractor. For those cloud providers serving DoD the requirements are those described in the Cloud Computer Security Requirements Guide (CCSRG), which follows a DoD modified version of the FedRAMP version 2 Moderate baseline. The CCSRG applies when contractors are providing cloud computing services directly to DoD.

The 2016 version of the rule also applied cloud computing standards to cloud service providers used by contractors. In that situation, the CCSRG was not specified. Rather, the 2016 rule simply required the FedRAMP modified baseline requirements.

The following sections discuss the basic NIST SP 800-53 security standards as well as the subsets of those security controls imposed by the 2013, 2015 and 2016 rules including both contractor information systems and cloud computing service providers.

NIST SP 800-53

The NIST SP 800-53 standards are intended for use in federal information systems and organizations.[EN-2] They are not intended for use by commercial organizations or even government contractors but they have become the foundation from which almost all federal government related security control standard specifications are derived. They have even worked their way into CNSSIs governing classified data security standards.

The security controls listed in NIST SP 800-53 are divided among 18 control groups or families that are represented by alphabetical characters like AC and IR. These 18 control groups are derived from the 17 families in the FIPS PUB 200 document that was developed by NIST and describes the minimum security requirements for federal information systems. Thus, these are known as the basic control groups. Exhibit 2 provides a listing of the Summary Controls appearing in NIST SP 800-53 as well as other security standards.
The difference between the 18 control groups in NIST SP 800-53 versus the 17 control families in FIPS PUB 200 is that the FIPS PUB 200 families involve information system controls only, while the NIST SP 800-53 document also includes one family, PM [Program Management], that is not an information system control but an enterprise or organization wide kind of control.

Across the 18 control families are 170 basic and derived controls that are identified by the higher level character based family code followed by a dash and a number like AC-1, AC-2, IR-1 or IR-2. Since this is where the specific security controls are described, these are known as the derived security controls.
In addition to the 170 basic and derived controls there can be a number of enhanced controls for each basic control. Enhanced controls are designated by the parenthetic number following the basic control (ie AC-2(1), AC-2(2), IR-2(1) and IR-2(2)). In total, there are more than 900 basic, derived and enhanced controls described in SP 800-53, although about 93 of them have been withdrawn as individual controls and subsequently incorporated into other controls. Thus, the full number of list of controls includes both currently active and superseded controls.

In version 4 of the publication, the Program Management controls were relocated from the list of security controls and placed in Appendix G, which deals exclusively with Program Management. Exhibit 2 provides a distribution of the 800-53 security controls for each family classification.

The NIST SP 800-53 standards document is more complex than a simple listing and description of the more than 900 controls. As indicated above, the document is a controlled document that provides traceability of the controls through its various versions. Thus, not all of the 900 basic, derived and enhanced controls are currently active, although more than 800 are currently active.

In addition, the document categorizes its controls into three baselines of Low, Moderate and High. Thus not all controls are intended to be used in every situation. Rather, the specific controls to be used in a particular situation can be tailored to fit the situation based on its classification of Low, Moderate or High. Even at the high level, however, not all controls are required. Indeed, even at the high classification only about 340 of the controls are applicable. Thus, the difference between the nearly 900 and 340 controls at the high level classification are truly optional controls that can be employed to enhance the security of a particular situation.

To determine whether the information or information system is a Low, Medium or High level classification one must follow the processes for classification described in the FIPS-PUB-199, Standards for Security Classification. This publication examines information and information systems from the perspectives of confidentiality, integrity, and availability. It then assigns the weights of Low, Moderate or High to each of these three perspectives and takes a high water approach for determining which baseline should apply. In other words, for the Los baseline to apply the information or information system must have a Low risk value for all three attributes of confidentiality, integrity, and availability. If any of these three perspectives have a higher value then the baseline of the highest value is the value that will be assigned to the information or information system for that element.

Organizations must employ all of the controls in the respective security baseline unless specific exemptions are allowed based on the tailoring guidance in the 800-53 standards. Organizations should use the tailoring process to achieve cost effective, risk based security that supports organizational needs. Some of the general considerations that influence the tailoring process include the existence of common controls among differing information systems as well as various scope considerations.

2013 Security Standards

The 2013 rule imposed 51 of the security controls dispersed across 14 families in the NIST SP 800-53 standard. Thus, the 2013 rule, which only considers 51 of the NIST SP 800-53 standards does not impose the entire NIST SP 800-53 standard. Exhibit 2 provides a distribution of the 51 controls under the 2013 version of the rule across the various security control families. Exhibit 3 identifies the 51 controls under the 2013 and 2015 versions of the DFARs rules.

There was yet another clause in the initially proposed version of the 2013 rule that dealt with Enhanced Safeguarding of Unclassified Information. That part of the initially proposed rule imposed eight additional security controls from the NIST SP 800-53 standards for a total of 59. The larger set of 59 security controls would apply to certain more critical data. The clause imposing the enhanced controls was dropped in the final rule, however.

One of the 51 required security controls imposed by the 2013 version involved control PM-10 for program management. At the time of issuance of the 2013 rule, the 800-53 specification was in revision 4. While PM-10 had been included in the system security controls under revision 3, that control was deleted from the system controls appearing in appendix D of the standard and moved to appendix G, since it was not system specific.

2015 and 2016 Rule Security Standards

The 2015 version of the DFARs rule considerably expanded the security controls that must be used to adequately safeguard CUI. The expansion occurred both from the expansion of the specific controls that must be used to safeguard CUI on contractor information systems and from the expanded coverage of information systems to include Cloud Computing Service Providers.

With respect to contractor information systems, the 2015 rule adopted the newly published NIST SP 800-171 security standards, which were devised for the protection of CUI on non-federal information systems and organizations.

With respect to Cloud Computing Service providers, the 2015 rule imposed the Cloud Computer Security Requirements Guide (CCSRG), which follows a DoD modified version of the FedRAMP version 2 Moderate baseline.

The 2016 final rule did not make any changes to the security standard requirements for either contractor information systems or Cloud Computing Service Providers. Each of these are discussed in the sections below.

Contractor Information Systems - NIST SP 800-171

Both the 2015 and 2016 DFARS rules require contractors to have systems for safeguarding controlled data that, at a minimum, meet the requirements of the NIST SP 800-171 standard. The NIST SP 800-171 standard was developed in specific response to EO 13556.

The contents of the NIST SP 800-171 are different than the NIST SP 800-53 standard security controls in several respects. First, the 800-53 controls were developed for Federal agencies and contain expectations that are beyond the protection of CUI.[EN-3] By contrast, the 800-171 standards were developed explicitly in response to EO 13556 and the protection of CUI.

Second, while the 800-171 standards can be mapped to the 800-53 standards, the mapping tables provided in Appendix D of 800-171 are included only for information purposes and some of the 800-53 standards match to more than one 800-171 standard. Although the mapping is provided in Appendix D, the mapping is not intended to convey or impart any additional CUI security requirements beyond those that are provided in Part 3 of 800-171.[EN-4] As a result, the NIST SP 800-171 standard security controls are separate and distinct from the NIST SP 800-53 standard.

Third, the 800-171 standards are articulated differently than seemingly similar controls under 800-53. In fact, the 800-171 standards are described more like performance standards. Furthermore, there are not any detailed explanations of the standards requirements. As a result, there is no single manner in which any particular standard has to be accomplished. Furthermore, the accomplishment of the standards can be quite subjective, since there is no particular means of measuring achievement of the requirements.

As an example of the ambiguities within the standards, consider requirement 3.1.8 that requires limiting unsuccessful logon attempts. While such a practice is a widely recognized security practice, there is no specificity in the 800-171 standard about how many unsuccessful logon attempts trigger a contractor taking action. In addition, there is no specificity about over what period of time the unsuccessful attempts should be limited and there is no instruction about what should be done when the number of unsuccessful logon attempts is achieved. All of these details, as well as many others, are left to the discretion of the contractor.

According to the mapping tables, the unsuccessful logon requirement of 3.1.8 of 800-171 standard maps to the AC-7 requirement of 800-53. In several respects, the AC-7 requirement of 800-53 is as flexible as the 3.1.8 requirement. For example, the AC-7 requirement does not specify a period of time over which the unsuccessful logon attempt should calculated. In other words, it does not describe whether it is over minutes, hours, days or perpetuity before the accumulation begins again.

With respect to the action that should occur once the designated number of unsuccessful logon attempts occurs, the 800-53, AC-7 requirement expressly specifies that the account should be locked out until released by an administrator. Since the 800-53 requirements mapped to the 800-171 requirements are not intended to impose a higher requirement than what is imposed by the 800-171 standards, the account lockout requirement of the AC-7 control under 800-53 is not an actual requirement of the 800-171 standard, since one is not actually provided under 3.1.8. Thus, any kind of action limiting unsuccessful logon attempts would satisfy the 800-171 requirement under 3.1.8. For example, an automatic lockout that was timed for only 5 minutes would still satisfy the 3.1.8 requirements even though it would not satisfy the AC-7 requirement under 800-53.

Clearly, there are many details missing from the 800-171 standard requirements. As a result, contractors will likely find it easier to accomplish the requirements than initially believed or as portrayed by many commentators and outside service providers. When assessing their compliance with the requirements contractors may find it useful to list each of the 800-171 requirements and then describe their method of accomplishing each of the standard requirements and then confirm whether there actually are any other requirement details for which their solution falls short.

In short, the 800-171 standards lack so many details that clever contractors experienced in interpeting government contracts, including their specifications, should be able to comply with the requirements relatively easily. Even the DoJ cyber initiatives under the False Claims Act will likely be similarly impotent becasue the 800-171 standards lack sufficient specificity.

Interestingly, Appendix E of the the 800-171 standard provides some explanation about how its standards were developed.[EN-5] It explains that two of the considerations were the 800-53 standards as well as FIPS PUB 200 document. With respect to the 800-53 standards, Appendix E goes onto explain that it began with the 263 controls comprising the moderate baseline. It then categorized the derived and detail controls into four categories. Those categories were CUI, FED, NFO and NCO.[EN-6]

From the 263 there were 124 controls that were related to CUI and designated with the CUI acronym. It is from these 124 controls that the 109 controls were developed for 800-171. Thus, the number of controls imposed on contractors under 800-53 is considerably smaller. Also, as explained above, the mappings to the related 800-53 controls is for information purposes only and not intended to impose a greater standard than what is actually required by the controls listed in Part 3 of 800-171.

The reasons for eliminating the other controls from the 800-53 moderate baseline when developing the 800-171 controls is also provided in Appendix E to the 800-171 standard.. Another 18 were considered uniquely federal and designated with the FED acronym. Another 58 controls were not directly related to protecting the confidentiality of CUI and designated with the NCO acronym. Finally, there were 63 controls that are, "expected to be routinely satisfied by non-federal organizations without specification" and designated with the NFO acronym. The 63 NFO security controls are listed in Exhibit 4.

For the most part, the 63 NFO controls involve having written plans, policies and procedures. Under FIPS PUB 200, federal organizations are required to develop and promulgate formal, documented policies and procedures governing the minimum security requirements provided in 800-53 and must ensure their effective implementation.[EN-7]

The characterization of the 63 NFO controls as, “expected to be routinely satisfied by non-federal organizations without specification” does introduce a contractual interpretation issue. Clearly, the question is whether the 63 NFO controls are contractually required even though they were not specified on the basis that they are “expected”? Or, is it simply that non-federal organizations are expected to already have policies, plans and procedures therefore they need not be specified? The simple answer to whether the 63 NFO controls are contractually required is “No they are not.” The basis for that answer is affirmed in many different ways.

First, the 63 NFO controls are not included in Part 3 of 800-171, which lists the 109 standards actually required.. In addition, the 800-171 standard clearly says that the NFO controls are not specified.[EN-8] In fact, the 800-171 standard explains that to the extent the 800-53 standards were considered, they have been tailored to eliminate controls that were uniquely federal, not directly related to protecting CUI and “expected” to be routinely satisfied by non-federal organizations.[EN-9] Thus, they have been considered for inclusion and deliberately eliminated from specification by the standard. Thus, they are clearly not required.

Second, as explained previously, the controls informally mapped from the 800-53 standard to the 800-171 standard are there for informational purposes only as a means to better understand the security requirements of the 800-171 controls. The informal mappings are not intended to impose additional requirements on non-federal organizations beyond those provided in Part 3 of the standard.[EN-10] Furthermore, none of the 800-171 controls listed in Part 3 of the standard address issues like policies, procedures or plans, which are predominantly the subject of the 63 NFO controls. Thus, to interpret the term “expected” as having the same meaning as required or specified would be a kin to imposing additional requirements on non-federal organizations beyond those provided in Part 3 of the standard.

Third, the exclusion of the 63 NFO controls is also addressed in footnotes 16 and 34 of the 800-171 standard. Footnote 16 acknowledges that the CUI requirements developed from the tailored FIPS PUB 200 and 800-53 moderate security baseline are a subset of the safeguarding measures necessary for a comprehensive information security program.[EN-11] It also encourages non-federal organizations to refer to Exhibit E and the 800-53 standard for a complete listing of the security controls deemed out of scope for the CUI requirements in Chapter Three. Thus, it recognizes, as it says, that the 63 NFO controls are not specified but expected of non-federal organizations desiring a comprehensive information security program. This point is further confirmed in Footnote 34, which explains that the security controls tailored out of the 800-53 moderate baseline for CUI protection are often included as part of an organization’s comprehensive information security program.[EN-12] Thus, Footnote 34 recognizes that the 63 NFO controls are permissive since they are “often” included in an organization’s comprehensive security program but apparently not required.

Finally, whenever policies, procedures or plans are actually required by the FAR they are clearly prescribed as is the case for DFAR regulations on contractor Cost Estimating Systems,[EN-13] DFAR regulations on contractor Material Management and Accounting Systems,[EN-14] contractor cost accounting practices under various Cost Accounting Standards (CAS) like CAS 407[EN-15] and CAS 418,[EN-16] and FAR requirements for Small Business Plans[EN-17] just to mention a few. Thus, when policies, procedures or plans are actually imposed by regulations they are clearly indicated. In this case, however, they are not expressly specified by any of the applicable information security controls or the FAR regulations themselves. Instead, as discussed above, they are expressly not specified.

In terms of actual guidance, the 800-171controls have no explanations and guidance about a control’s actual requirements. Thus, they are quite subjective. Potentially, the only source for guidance about the actual requirements of the controls is by way of the mappings to the related 800-53 security controls. At the same time, the mappings of the 800-171 standards to the 800-53 standards is not intended to “convey or impart any additional CUI security requirements beyond those that are provided in Part 3 of 800-171.”[EN-18] Thus at best the 800-53 mappings are simply informational about what facets could be considered as well as any suggested solutions for their accomplishment but they are not actually mandated requirements when they are different from the actual requirements specifically articulated in Part 3 of the 800-171 standard.

Despite that the NIST SP 800-171 requirements impose more standards than the 51 imposed by the 2013 rule, there are 5 required by the 2013 rule that are not part of the 2015 requirements. Thus, for contractors having contract portfolios containing both the 2013 and 2015 or 2016 rule versions it is not a matter of picking one rule or the other. Instead, an amalgamation of both rules is required in order to comply with the requirements imposed by both rules. Exhibit 3 provides a matrix matching the 800-171 to 800-53 security controls as well as identification to whether those controls are part of the 2013 or 2015 DFARs rules.

Cloud Computing Services Providers

The security standards for cloud computing are different than those governing contractor information systems. There are also differences for cloud service providers based on whether they are serving DoD directly or they are serving contractors directly.

Cloud Computing Services Providers Used by DoD

While the prospect of cloud based computing resources were not considered in the 2013 rule the use of those systems by DoD were considered in both the 2015 interim and 2016 final rule versions. Both the 2015 and 2016 versions of the rule impose the controls described in the Cloud Computing Security Requirements Guide (CCSRG) when cloud computing services are offered directly to the government.

The CCSRG is essentially DoD’s implementation of the FedRAMP security controls that have been enhanced with a few additional controls. Specifically, the CCSRG starts with the 323 controls contained in the FedRAMP moderate baseline. DoD then adds either 36 or 46 additional CUI controls depending on whether the Level 4 or Level 5 controls are applicable.

The CCSRG actually considers 6 different levels but only levels 4 and 5 involve systems handling CUI.

Level 1 applies to unclassified information approved for public release. This level is no longer recognized and in use. Rather it has been moved to Level 2.

Level 2 is uncontrolled information that is cleared for public release. It can also include some private DoD information that is not CUI data or mission critical information but some minimum level of protection is desired.

Level 3 is for CUI information but this level is also no longer in use. Rather, it has been merged with Level 4.

Level 4 is for CUI information such as information subject to export control, privacy information, Personal Health Information (PHI), or other information receiving the CUI designation.

Level 5 is similar to Level 4 in that Level 5 is also CUI information. The difference is that Level 5 information is CUI information warranting a higher level of protection than Level 4.

Level 6 involves classified information up to the SECRET level.

The FedRAMP controls are a subset of the NIST SP 800-53 controls that have been considered applicable to cloud computer service providers. The additional controls added by DoD are also taken from the 800-53 standards. Exhibit 5 provides a listing of the CUI security controls imposed on Cloud Computing Service providers by the CCSRG.

Cloud Computing Services Providers Used by Contractors

The use of cloud computing service providers was not contemplated in either the 2013 or 2015 versions of the rules. Indeed, it was not added to the rules until the 2016 final rule. Even then the requirements are arguably imposed in fewer situations than with cloud computing service providers serving DoD.
As was discussed in the section on information systems, under the CCSRG, that covers providers serving DoD, cloud computing services are distinguished between four different offerings of storage, software-as-a-service, infrastructure-as-a-service, and platform-as-a-service.”[EN-19] By contrast, the 2016 final rule describing cloud computing services for contractors mentions only store, process or transmit CDI.[EN-20]
The standards that apply to cloud computing service providers serving contractors are the FedRAMP moderate baseline without any of the DoD modifications provided in the CCSRG.[EN-21]

NIST SP 800-171 Rev 1

In December 2016 the first revision to the 800-171 standards was released. It included one new standard at 3.12.4 that required development and maintenance of System Security Plans (SSP). Both the SSP and Plans of Action (PoA) required by 3.12.2 are ways to monitor and manage improvements to the system to correct found deficiencies.

Both the SSP and PoA were documents also used by the government to assess a contractor's compliance with the security standards and monitor compliance with the DFARs requirements.

NIST SP 800-171 Rev 2

June 2019 a draft was issued for the second revision to the 800-171 standards. While this document does not add any more security controls it does provide a lot more explanation and guidance about the requirements of the various security standards. In some respects it is kind of like incorporating the 171A, Assessment Procedures described below and integrating them within the 800-171 standard, although the articulation is different.

NIST SP 800-171A, Assessment Procedures

In June 2018 a new document was released to assist contractors in generating evidence to support the assertion that the security requirements were being met.

As indicated previously, the requirements articulated in the 800-171 standard were simply stated without any other guidance or explanation of their intended requirements. Thus, it was quite possible for contractors to decide how conformance with their requirements was actually achieved.

The 171A document provided considerably more "guidance". In reality, it essentially was a way for DoD to essentially impose changes to the standards and require that they be interpreted as DoD had "intended".

NIST SP 800-171B, Enhanced Controls

In June 2019 a draft was released known as NIST SP 800-171B. Since it is still only a draft it is not yet ready for use in contract vehicles.

This version of the 800-171 standard contained 33 additional enhanced security requirements for critical programs and High Value Assets (HVA). Thus and as stated in the 800-171B standard, these additional controls apply only to contractor systems designated as part of critical programs or HVAs.

Under OMB Memorandum M-19-03 agencies are to take an enterprise wide view of cyber risk that unifies the effort to protect HVAs. Thus, contractors handling CUI related to such programs or HVAs can have contract requirements that include the enhanced requirements.

Agencies may designate an information system an HVA when it relates to one or more of the following categories:

• Informational Value – The information or information system that processes, stores, or transmits the information is of high value to the Government or its adversaries.
• Mission Essential – The agency that owns the information or information system cannot accomplish its Primary Mission Essential Functions (PMEF), as approved in accordance with Presidential Policy Directive 40 (PPD-40) National Continuity Policy, within expected time lines without the information or information system.
• Federal Civilian Enterprise Essential (FCEE) – The information or information system serves a critical function in maintaining the security and resilience of the Federal civilian enterprise.

The enhanced security requirements address protecting the integrity of CUI by promoting: (1) penetration resistant architecture; (2) damage limiting operations; and (3) designing for cyber resiliency and survivability.

Security Standards Summary

Across the various versions of the rule for safeguarding information, there have been several different security controls that contractors are supposed to follow. There was a single set of standards with only 51 controls under the 2013 rule. By the end with the 2016 final rule there are three different sets of standards. There are two different sets of standards for cloud based security providers and then there is the NIST SP 800-171 standards for all other contractor information systems. Between the three different sets of standards there are nearly 1,000 security controls.

The 2013 version of the rule passed without much fanfare. Furthermore, it is still in existence today and its requirements were not postponed when the requirements for the 2015 interim rule were postponed to December 2017.

The 2013 rule covered only contractor information systems. While the definition is broad the requirement to implement the standards and safeguard CUI is limited to a contractor’s information systems. In addition, there is no consideration of cloud computing services at all.

With regard to the 2015 and 2016 requirements, those are considerably different than the 2013 requirements in several respects. First the 2015 and 2016 requirements included both contractor information systems and cloud based systems. With respect to contractor information systems, those security standards were based on the 800-171 standards unless the contractor was providing those services for the DoD. In that latter case they, were governed by other provisions of the contract which most likely would have been the 800-53 standards.

Interpreting the requirements of 800-171 standards is best not left to technology personnel that are not well versed at interpreting contract requirements. There are many things about the 800-171 standards that would be interpreted by technology personnel to apply but would not actually apply when subject to contract interpretation requirements.

The most obvious examples of these differences are the 63 NFO standards and the mappings of the 800-171 standards to 800-53 standards. Many so called technology experts claim that the 63 NFO standards are required; yet, Appendix E of the 800-171 standard clearly says they are “not specified.”[EN-22] Similarly, the so called experts have claimed that 800-171 standards impose all of the requirements of the 800-53 standards to which they are mapped; yet, the 800-171 standard clearly states that the mappings are not intended to “convey or impart any additional CUI security requirements beyond those that are provided in Part 3 of 800-171.”[EN-23]

While there has been much hand wringing and fear mongering about the 800-171 standards, the reality of their requirements is far less than what many have claimed. Thus, compliance with the security standards of the 2016 final rule is as much a contractual exercise as a computer security exercise.

With regard to cloud service providers there has been considerable confusion over the regulatory process. There was no consideration of the cloud service providers under the 2013 rule and any contracts containing those requirements.

For the 2015 interim rule there was only consideration of cloud service providers serving DoD directly. There was no consideration of cloud service providers serving contractors. The language imposing security requirements on cloud service providers serving contractors was not added until the 2016 final rule.[EN-24]
Under the 2016 rule, cloud service providers serving DoD must satisfy the requirements of the CCSRG, which essentially are the FedRAMP moderate baseline with a number of additional security requirements added by DoD. Specifically, DoD adds either 36 or 46 additional controls to the CCSRG requirements depending on whether Level 4 or Level 5 controls are applicable.

With respect to cloud service providers serving contractors, the requirements are a little more relaxed than those serving DoD, since cloud service providers serving contractors must satisfy only the FedRAMP moderate baseline without any of the additional requirements imposed by DoD.

The next part in this series of articles on safeguarding CUI is on the Reporting Requirements.

The previous part in this series of articles on safeguarding CUI is on the Covered Data Requirements

End Notes