If your company is a member of the Department of Defense (DoD) Industrial Base (DIB), it is very likely that you are already familiar with the clause DFARS 252.204-7012. And if you are not familiar with it, we’d recommend you double-check your contract to see if this clause is in there. With DFARS 7012 requiring government contractors prepare to handle Controlled Unclassified Information (CUI) and the Cybersecurity Maturity Model Certification (CMMC) set to actually enforce this, there is significant overlap between both DFARS 7012 and CMMC. However, one of the requirements described in DFARS 252.204-7012 is not explicitly found in NIST 800-171 or the CMMC, which makes us wonder if it will still be required for DoD contractors to implement in order to become CMMC-certified. We prefer to lean on the safe side here at Totem, which is why we recommend all contractors handling CUI be prepared just in case!
The Hidden Requirement in DFARS 252.204-7012
DFARS 252.204-7012 can be broken down into two primary components: protecting CUI and reporting cyber incidents. The “hidden” requirement comes from the latter, in the following procedure:
“When a Contractor discovers a cyber incident has occurred, the Contractor shall preserve and protect images of all known affected information systems … and all relevant monitoring/packet capture data for at least 90 days from the submission of the cyber incident report.”
We know from CMMC Level 3 control IR.3.098 that all contractors and subcontractors are required to track, document, and report incidents to the Department of Defense within 72 hours. So, what does the DoD mean by preserving and protecting images and other capture data? Does this require a specific technology to implement?
The short answer is this: we don’t know because they didn’t tell us. However, just because it was not explicitly laid out in NIST 800-171 or the CMMC does not mean that we should just ignore it altogether. If DFARS 252.204-7012 is in your contract, there’s certainly a chance an assessor will ask about this requirement, and you’re bound by the contract to do it anyway. Therefore, we are going to do our due diligence at Totem to meet this requirement, and we encourage you to do the same. We hope to make this process a little easier for you, so aside from the recommendations we discuss here, you can also check out the free downloadable incident response plan (IRP) template we include at the end of this blog.
How Can My Company Meet This Requirement?
The first step in meeting this requirement is to ensure that you have an effective incident response plan in place. It’s difficult to report an incident to the DoD if you never discover one is taking place. Keep in mind that an IRP is not merely a list of actions to be taken after an incident occurs; it must detail how your organization will act from pre-discovery to post-disclosure. Recall the four steps of NIST’s incident response life cycle:
We won’t go into any more detail here on how to develop an IRP, but if you need some additional guidance on how to do this, we can help. Aside from the free IRP template, you can check out our Six Steps to Include in Your IRP blog or feel free to jump into one of our online workshops, where we will help you build an IRP tailored to your organization’s needs.
The hidden requirement in DFARS 252.204-7012 most closely incorporates the second step of NIST’s incident response lifecycle, Detection & Analysis. Thankfully, NIST has given us quite a bit of information on what technologies to use in this phase, so we will use this information as a guide for fulfilling the hidden requirement.
According to this NIST Incident Handling guide, some of the common sources of incident precursors and indicators include alerts, such as those from the following items:
- Intrusion Detection & Prevention System (IDPS)
- Security Information & Event Management (SIEM)
- Antivirus and antispam software
- File integrity checking software
- Other third-party monitoring services
In addition to alerts, NIST also identifies different types of logs as important indicators of incidents, including:
- Operating system logs
- Application logs
- Network device logs
- Network flows
If your organization can demonstrate that you gather and maintain this information for at least 90 days after the incident is reported and can readily present this knowledge when required to, you are likely on track to meet the hidden requirement. Keep in mind, however, that this information can be time consuming for you to generate and keep track of, so we recommend focusing specifically on gathering data that is actionable, such as those from the sources we previously mentioned. If the DoD chooses to conduct a damage assessment on your organization following the incident, they will only want the relevant capture data, so don’t overwhelm yourself with logs that aren’t important!
In addition to alerts and logs, the hidden requirement also expects the preservation and protection of all images associated with affected information systems. An “image” is a preservation of the state of the machine at a given moment in time. It is important to preserve the state of a compromised machine so that it can be analyzed and studied to determine and fix the root cause of the compromise. Kind of like a crime scene investigator taking photographs of a crime scene. Since, as small business, you can’t afford to tie up an affected machine for lengthy analysis—you need to get back to work, after all—preserving an image allows someone to perform the analysis long after the organization recovers from the incident.
Hopefully, you are already very familiar with the process of creating system images, as it is an effective backup and restoration solution for mitigating the damages of a failed hard drive. If you aren’t familiar with this process, think of a virtualized environment: with a virtual machine (VM), you can take “snapshots” of the system in order to aid in recovery for later. When something goes wrong, you can simply revert back to an earlier snapshot. In this case, however, we aren’t using disk imaging as a recovery mechanism, but for preservation. The DoD may want to see such “snapshots”, or images, of your systems after the incident occurred, so be sure to store images of the affected systems for at least 90 days following the submission of your incident report.
There are several options when it comes to image preservation. Your small business certainly isn’t limited to our shortlist of options, but it will serve as guide if you don’t know where to start.
Strategic/procedural options for image preservation include:
- Pull the machine out of service and store in a secure location. Replace the machine for recovery.
- Pull the hard drive out of the machine and store in a secure location. Replace the hard drive for recovery.
Technical options for image preservation (all free!) include:
- Clonezilla – One of the simplest and most robust imaging programs; commonly used today
- VMware vCenter Converter – Use to convert physical machine images into virtual machine images
- AccessData FTK Imager – Creates forensic images without altering original evidence
- SANS Investigative Forensic Toolkit (SIFT) Workstation – Contains advanced incident response tools; ideal for conducting thorough analysis of a computer system
- Mount to Linux machine and use dd command – Convenient command line alternative for creating disk images
Conclusion: Don't Ignore This Requirement
As your organization continues to pursue its CMMC certification, we strongly urge you to keep this requirement in mind. How frustrating would it be to spend so much time preparing, only to be caught off guard by a requirement that wasn’t explicitly stated in the CMMC Model? We certainly don’t want this to be the case for you. With the CMMC landscape constantly changing, we can say as a fellow small business within the DIB that it’s just better to be safe than sorry.
Good luck out there!
-Nathan Cross, Cybersecurity Engineer