Since November 2013 with the release of its initial rule on safeguarding covered defense information and cyber incident reporting, the Department of Defense (DOD) has been working to impose additional requirements on defense contractors that process, store, or transmit what is identified as covered defense information. The Defense Federal Acquisition Regulation Supplement (DFARS) clause 225.204-7012 (Revised Oct 21, 2016),Safeguarding Covered Defense Information and Cyber Incident Reporting, defines covered defense information (CDI) as “unclassified controlled technical information or other information, as described in the Controlled Unclassified Information (CUI) Registry, that requires safeguarding or dissemination controls pursuant to and consistent with law, regulations, and Governmentwide policies, and is:
(1) Marked or otherwise identified in the contract, task order, or delivery order and provided to the contractor by or on behalf of DoD in support of the performance of the contract; or
(2) Collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the contract.”
Essentially CUI has direct military or space application and consists of items such as engineering data and drawings, technical reports, specifications, source and executable code, etc. (see their category list) This is data that is sensitive but not to the point where it becomes classified.
There were two interim rules published since the initial publishing of the initial rule in November 2013, one in August 2015 and one in December 2015. The final rule was published on October 21, 2016. The December 2015 interim rule established the deadline for compliance as December 31, 2017 which is now fast approaching.
Who has to be DFARS Compliant & What are the DFARS Regulations?
All Defense contractors and subcontractors, independent of size, that process, store, or transmit covered defense information must be compliant with DFARS 225.204-7012. While there are several elements to which contractors must comply, there are two primary elements that seem to be the most dominant, demonstrating “adequate security” and cyber incident reporting.
Adequate Security (through compliance with NIST 800-171): As defined in the DFARS, adequate security includes “protective measures that are commensurate with the consequences and probability of loss, misuse, or unauthorized access to, or modification of information.” To help provide more context of what adequate security is regarding the protection of covered defense information, the Government stated that contractor information systems that process, store, or transmit CDIshall implementsecurity requirements in National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, “Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations.” The specific use of the word “shall” makes compliance with NIST 800-171 a requirement. Essentially, the government is stating that “adequate security” is compliance with NIST 800-171. See below for additional items to be aware of regarding compliance with NIST 800-171.
Cyber Incident Reporting: DFARS 225.204-7012 defines a cyber incident as “actions taken through the use of computer networks that result in a compromise or an actual or potentially adverse effect on an information system and/or the information residing therein.” If contractors experience a cyber incident that impacts CDI, then they must do the following:
- Perform an analysis and gather evidence to determine if specific CDI was compromised on contractor computers or servers.
- Rapidly report (within 72 hours) the discovery of the cyber incident. A medium-assurance certificate will be required to report the incident.
- Preserve and protect OS images and other forensic evidence (e.g. packet captures, logs, etc.) for 90 days.
What these requirements essentially mean for contractors is that they must have an incident management plan and procedures in place (and tested) prior to the December 31, 2017 deadline.
What is Important to Know About NIST 800-171?
For those that work within government cyber and information security circles, compliance with security controls is nothing new – NIST SP 800-53 has been out for a long time, and revision 5 is actively being worked. The security controls defined in NIST 800-171 were derived from the Federal Information Processing Standard (FIPS) Publication 200 control families and the NIST SP 800-53 moderate security control baseline, and they are more straightforward in their wording. The SP 800-171 controls are oriented toward protecting the confidentiality of CDI, but integrity and availability should not be ignored as they are key tenants of an information security program.
While NIST 800-171 represents just a subset of the requirements defined in NIST 800-53, compliance with NIST 800-171 is still a very significant task, especially for small and medium sized government contractors. NIST 800-171 defines approximately 109 security requirements across 14 control families. Below are some of the requirements that government contractors should take specific note of as compliance with these is more involved (either technically, process-wise, or both):
Audit and Accountability (3.3.5 and 3.3.6): Auditing is a very important control area to the government. Through audit events, the story of the who, what, when, and where of activities on an information system is told. Without the audit logs documenting the events occurring on the information system, the contractor (and the government) is essentially left blind in trying to reconstruct events that occurred on the system in support of an investigation. Requirements 3.3.5 and 3.3.6 specify the correlation of audit review, analysis and reporting process and define the need for audit reduction and reporting in support of on demand analysis and reporting. This is much more than the typical approach of just configuring the components of the information system to generate syslog events and send it to a centralized syslog server. Contractors must be familiar with the content of the audit records through the review and analysis process. Specific events of interest must be identified, pulled from the general collection of audit information (reduced), and be reported on (to support on “on-demand analysis”). There are many technical approaches to satisfy these requirements, but contractors should not underestimate the time to understand the auditing capabilities of the systems, configure the systems appropriately, develop a baseline – all before a technical implementation can be put in place.
Identification and Authentication (3.5.3): This is the requirement for multifactor authentication (MFA) for local and network access. There are a wide variety of MFA solutions available, and the good thing is that a federal Personal Identity Verification (PIV) or DOD Common Access Card (CAC) is not required. MFA should be an architected solution that integrates well into the system that transmits, processes, and stores CDI. Users already frustrated with passwords and the complexity rules to which they must comply. Adding another layer to authentication, albeit a very important one in my opinion, can add to user frustration if it is not implemented in a manner that is low impact to users.
Incident Response (3.6.1): The requirement is for an “operational” incident handing capability – operational being the operative word – meaning that the incident handing capability is functional and covers all phase of the incident handling process (preparation, identification, containment, eradication, recovery, and lessons learned). Incident handling is not a program that is just supported by a shelf-ware plan and procedures. Incident handling is a specialized area within cyber security and requires specific understanding and technical skills. It also involves a team of people from management down to the individuals with the technical skills to perform forensics, eradicate the problem, and recover the system. The plan must be regularly exercised (ideally quarterly) as people and technology frequently change in an organization. The exercises don’t have to be large time-consuming events; but at some point in the year, all members of the incident handling team need to participate in an exercise.
Security Assessment (3.12.1 and 3.12.3): These requirements are to “periodically assess” and “monitor…on an ongoing basis” the security controls in the system to ensure they continue to operate effectively. In short, implement a continuous monitoring program. Like incident handling, continuous monitoring requires active participation by organizational staff, including system and security administrators. SP 800-171 is not prescriptive on what controls have to be monitored and the frequency of monitoring, but controls that address the high-risk areas in the system should be monitored on a regular basis (e.g. at least monthly). One example is maintaining the security configurations for components of the information system (see 3.4.2). It is imperative that security configurations (e.g. system hardening) be constantly and consistently maintained. This is also a good control to automate. Automate as much of the continuous monitoring program as possible. To understand more regarding continuous monitoring, refer to NIST SP 800-137, “Information System Continuous Monitoring for Federal Information Systems and Organizations.”
What is the Impact if an Organization is not DFARS Compliant (or NIST 800-171 compliant)?
Put simply, a government contractor that is not compliant with DFARS 225.204-7012 is at risk of losing business with the government. In response to comments on the DFARS rule, the government stated, “the rule does not preclude a requiring activity from specifically stating in the solicitation that compliance with the NIST SP 800-171 will be used as an evaluation factor in the source selection process” (Federal Register, Volume 81, Number 204, October 21, 2016). It will be up to the government, though, to decide how compliance will be measured with regards to the specific solicitation. The government also stated, “by signing the contract, the contractor agrees to comply with the contract’s terms.” It is in the best interest of the government contractors to be compliant with NIST 800-171 requirements and be able to demonstrate that compliance.
How Should Organizations Prepare for DFARS Compliance?
If an organization has not started their efforts to comply, they are already behind the eight ball. The deadline is fast approaching, so action is required now. Below are a few recommendations to get the ball rolling (if it is not already):
1. Develop a Security Controls Traceability Matrix (SCTM): Organizations should demonstrate compliance across the system, so to help facilitate the application of the controls across the system, organizations need to identify every component within the system to which the control applies. Each control should be mapped to each applicable component in the system using a simple matrix.
2. Identify gaps: Using the SCTM, organizations can then investigate where and how controls are already implemented in the system. Where there are gaps, develop a gap remediation plan identifying how and when the gap will be remediated and what resources will be used to address the gap.
3. Execute the gap remediation plan: Put simply, “plan the work, work the plan”
4. Document how the controls are satisfied: Essentially, along with the SCTM, the documentation of how controls are satisfied can be used to demonstrate compliance with the controls. Data from the continuous monitoring program will also be strong evidence of compliance.
Each passing day brings us closer to the December 31, 2017 DFARS/NIST 800-171 compliance deadline. There are two primary elements of the DFARS clause to which contractors need to demonstrate compliance. The first is to demonstrate “adequate security” is in place for protection of systems that process, transmit, or store CDI. Adequate security is essentially translated as compliance to NIST 800-171. The second is to ensure that there is an operational incident reporting capability in place that can support the reporting requirements of the clause.
If your organization is not familiar with NIST security controls, it can be challenging to interpret the controls and translate them into system implementations. Linford & Company has extensive experience with NIST and associated NIST compliance. If you are interested in learning more about NIST requirements and DFARS compliance, or getting help to meet the December 31, 2017 deadline, please contact us.