What you need to know now
By Heather Engel, Sera-Brynn Chief Strategy Officer
DoD’s original FAQ was issued in January 2017, with answers to 59 questions on general application, security requirements, and cloud computing. The FAQ issued on April 2, 2018 nearly doubles that with answers to 109 questions on DFARS 252.204-7008 and 252.204-7012, FAR 52.204.21, NIST 800-171, cloud computing, and cyber incident reporting. Here are some of the highlights:
Subcontractor Management: Primes have long been concerned about the level of accountability to which they should hold their subcontractors. This question and answer – sub-contractor auditing (Q17) – confirms that the prime must flow down the requirement, and should use “whatever mechanisms” normally used. In our experience, there is often no supply chain management or audit function; organizations will need determine a means of auditing that addresses the risk posed by a particular supplier or contract.
Non-Compliance: A System Security Plan (SSP) and Plan of Action & Milestones (POAM) are used to demonstrate implementation and may be considered by the acquiring activity in contract awards. Consequences for non-compliance are addressed in Q18. Penalties for non-compliance already exist for other DFARS and there is no difference or special exception for 7012.
Marking Information: Q19 – Q27 all address identifying and marking various types of Covered Defense Information (CDI). This section clarifies that the requiring activity (i.e., the government) is responsible for marking and identifying CDI, and states clearly in Q21 that information will be marked according to DoDM 5200.01 V4 and DoDI 5230.24. Companies concerned about export controlled information and controlled technical information should carefully read this entire section.
For the first time, this FAQ addresses HIPAA compliance for systems also subject to NIST 800-171 (Q34) and recognizes that many organization supporting the DoD deal with layers of compliance. Q30 also notes that requirements for CUI Specified data may be subject to additional protection beyond what is required by NIST 800-171.
Many of our clients have struggled with what is considered a “reportable incident”. This is addressed in Q35 – Q37 and Q46. To comply and correctly categorize and report incidents that may have adverse effects, Sera-Brynn recommends that organizations have a solid understanding of what devices are considered “in-scope” and prepare in advance. Much of the information required for reporting does not depend on the circumstances of the incident, and having that information at the ready beforehand will streamline the process.
Q55 – can the acquiring activity judge the worthiness of how 800-171 is implemented? This is answered earlier in the FAQ, stating that the SSP and POAM may be considered. However, Q50 states that it is not appropriate for the acquirer to add additional requirements or dictate how 800-171 is implemented unless there is a specific need to categorize information as higher than “Moderate”.
In working with clients of all sizes, we find that many small businesses struggle and will continue to struggle with implementing these requirements, not only on a financial basis but simply finding the cyber security talent to manage the security of their networks. Q58 provides a nod to this and mentions various programs and resources that may be useful.
Q67 specifically addresses the needs of manufacturing systems and this is also alluded to in Q62 when discussing adjudication. And Q81 addresses a common issue – how do you know what is the minimum acceptable setting? Specialized systems that cannot meet a requirement should be addressed in the SSP, and again – implementation of the controls goes back to risk to the system. Sera-Brynn clients know that these controls must be interpreted within a risk framework – what is the risk level acceptable to the organization? In other words, how does setting a value of x impact my level of risk?
Q89 and 90 again describes minimum acceptable settings, this time for assessing risk and security controls. As stated with other question and answers asking about minimum acceptable, the DoD states that this should be done in the organization’s context of risk.
Q91 and 92 provide more detail on the SSP. Sera-Brynn’s recommendation has always been that the SSP is a living document that describes the control implementation – what is being done and how it meets the control. That doesn’t mean that this document should duplicate other policy and procedures, referencing is acceptable, even preferable if the documents already exist. DoD’s answer agrees and further reiterates that requiring activities may use the contractor SSP, and that the SSP may take any format.
Many questions, including Q68, 78, 94, 95, and 98, address encryption. A common misconception has been that encryption is required – it may be in some cases and for some controls, but this is not automatic. If it is being used to protect the confidentiality of information, it must be FIPS-validated.
The remaining question have to do with cloud computing, storage and services. The bottom line is this: a cloud service does not have to be FedRAMP-approved, but the service provider MUST meet the FedRAMP Moderate baseline. This can be tricky, especially if a defense contractor is using a CSP for data storage, backups, email or applications.
Knowing your data and networks and taking the time to understand your company’s business processes will make interpretation and compliance much simpler. Everything in business comes down to risk, and cyber compliance for defense contractors, researchers, and academia is no different.
About Sera-Brynn: Sera-Brynn is a global cyber risk management audit and advisory firm, a Payment Card Industry (PCI) Qualified Security Assessor (QSA), and a Third Party Assessment Organization (3PAO) certified under the Federal Risk and Authorization Management Program (FedRAMP). Founded in 2011 by former members of the U.S. intelligence community, Sera-Brynn is ranked #9 worldwide on the Cybersecurity 500 list and is known for its cyber risk management services.