Are you a government contractor who’s concerned about staying in compliance with data security compliance? You should be. But, not to worry, Spade Technology has the information on the NIST and DFARS compliance rules – as well as the IT solutions — you’ll need to stay safe where concerns federal acquisition regulation.
With the release of its initial rule on safeguarding covered defense information and cyber incident reporting in November 2013, 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 252.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 Government-wide 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.
The December 2015 interim rule established the deadline for compliance as of December 31, 2017, which is now fast approaching.
All Defense contractors and subcontractors, independent of size, that process, store, or transmit covered defense information must be compliant with DFARS 252.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 CDI shall implement security 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 252.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:
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.
For those that work within government information and cybersecurity 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.
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 for 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 complex 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 on users.
Incident Response (3.6.1): The requirement is for an “operational” incident handling 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 of 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 need 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.
Government contractors that are not compliant with DFARS 225.204-7012 are at risk of losing business with the government. Give Spade Technology a call today at (508) 339-5163 to bury the risk and be able to safely do your job.
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 government contractors to be compliant with NIST 800-171 requirements and be readily able to demonstrate that compliance.
If your organization has not started its efforts to comply, you are already behind the eight ball. The deadline is fast approaching, so the action is required now. Below are a few recommendations to get the ball rolling (if it isn’t already):
The December 31, 2017 DFARS/NIST 800-171 compliance deadline is rapidly approaching (less than a month away). 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 the 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. Spade Technology has extensive experience with compliance regulations and NIST compliance.
If you are interested in learning more about NIST and DFARS compliance requirements, or getting help to meet the December 31, 2017 deadline, please contact a Spade Technology representative at (508) 339-5163, or email us at email@example.com for more info.