DoD now requires contractors to protect controlled unclassified information

In a board room somewhere, the CEO looks over at the CIO and asks, “I was reminded today about the big change regarding the DFAR[1] and cyber security that will come into effect beginning January 1st, 2018…are we good to go?” The CIO responds, “Boss, you are talking about the requirement to protect Controlled Unclassified Information, or CUI.”[2] After briefly pausing, continues, “This isn’t a technology problem, it is bigger than the network. Once someone tells me what and where our CUI is, I will be able to help the rest of the team answer your question.” “The CEO looks over at the General Council (GC), “Can you tell me what CUI is?” The GC replied, “There are over 100 types of CUI, I defer to the business side to define what CUI we create, process, store, or disseminate.” Nobody from the business side speaks up so the CEO asks, “So whose problem is this?” The GC states, “I think I can help. You and I sat down last week to discuss trade compliance issues. I am confident we can leverage the same functional framework we used for trade compliance to address cyber compliance. Doing this will reduce cost and time, create operational efficiencies and aid the board to better manage business risk.”

“Let’s start with the requirements. The DFAR mandates contractors and sub-contractors must protect CUI to the level outlined in the National Institute of Science and Technology (NIST) Special Publication (SP) 800-171[3]. Chapter 3 of SP 800-171[4] lists 110 actions we must take to protect CUI.” I found it interesting that nowhere in those 110 requirements does it require us to identify the types of CUI we create, process or store and equally important, where the CUI files are located. It assumes we know this; unfortunately, that isn’t even remotely the case. The DFAR also directs contractors and sub-contractors to report cyber incidents within 72 hours of detection to the Department of Defense (DoD). Last, it requires us to notify the DoD CIO by December 31st if we are unable to comply with the NIST document.” The CIO adds, “It is clear to me after reviewing all of the requirements that everything they ask us to do revolves around protecting the CUI from compromise. This isn’t a document intended to help you build a world-class network because it never addresses our top priority: availability. It struck me that the only thing set in stone is that we must utilize multi-factor authentication (MFA) for all administrative activities and remote access of CUI. Otherwise, it leaves a lot of decisions to us. For example, it tells us in several places we must monitor various network activities[5] , but it is up to us to determine what exactly that means and how to do that. Likewise, it tells us to audit various activities[6], but it is rather vague on what exactly needs to be audited.” The CIO continues, “I am glad it gives us the flexibility to make decisions, however, we must be able to justify our decisions to the DoD which in many ways makes the task more difficult. Doing so means we have to understand their framework at a very intimate level.”

The CEO interrupts, “Ok, I am getting a pretty good idea what seems to be required, but what does any of that have to do with trade compliance? I am not seeing it.” The GC smiles and replies, “I honestly can’t tell you all the types of CUI we deal with, but I do know one: Export Control. My recent experience with trade compliance made me very familiar with this particular CUI category and makes me optimistic that we can also become DFAR compliant. You remember that we partnered with a third party to help us get trade compliant quickly because we were at risk of censure from the US Department of State. Our partners did a great job and the processes they leveraged to help us get our arms around trade compliance are exactly the kinds of things we need to do here to help us with DFAR compliance.”

The GC says, “If the trade compliance issue hadn’t recently arisen I would have mistakenly analyzed the DFAR issue through a technology lens and that would have been counter-productive. How we frame the DFAR issue will drive the type of solution we seek. My recent trade compliance experience convinces me this is more of a compliance issue than a technology issue. I fear if we pursue a technology-first solution that we will proverbially speaking, chase issues at the tree level and miss the forest.”

“Through working with our trade compliance partners, they began their assistance from the lens of an auditor, which is their first pillar. Their audit clearly identified areas requiring immediate action and framed deficiencies in simple ways which I understood…business risk. Our partners then transitioned to their second pillar, consulting services. With the audit as the baseline, they scoped a path forward leading us to compliance. As part of the path forward, they leveraged their final three pillars: training & education services; certification and automation. These three pillars touch on the big three capabilities at the center of all issues: people, process and technology. Although the pillars can stand alone, in our case they leveraged all five pillars.

The CEO nods, “I am beginning to believe. I can see how those five pillars translate easily into helping us achieve DFAR compliance, assuming our partners possess corresponding cyber expertise. My next question though is can we do this ourselves or do we need help?” The GC says, “Ideally, we would like to do this ourselves, but we aren’t postured to do this today. We can either spend a year or more gaining the needed intimate knowledge of the framework and then would need to hire the right people to implement the DFAR requirements or alternatively, we can leverage our partners to compress the timeline by taking advantage of the significant head start they have over us.”

The CEO continues, “Considering our current timeline of January 1st, 2018 it seems that our best way forward is to work with an outside partner as you say. I still need a point person for this, and based on this discussion it seems the best fit is for the GC to take the lead. As you all stated, this is not a technology issue…it is much broader in scope. I think this is both a compliance issue and a business risk management issue because it impacts our ability to conduct business. We must get DFAR compliance right or we risk DoD censure. I also think that this work needs to be completed in coordination with Operations and Technology, so both of you (the CIO and COO) need to support the GC in this effort. Finally, given our tight time window, I will look for a report in two weeks and expect that we have our partner selected and already in motion. Don’t disappoint me.”

Unfortunately, the conversation above rarely occurs. Too many entities frame DFAR compliance as a technological issue and fail to advance beyond the “problem admiration” phase. For most organizations, achieving DFAR compliance will be neither an intuitive nor simple process because it is complicated. As the story identifies, solving this problem doesn’t require re-inventing the wheel. However, it does require specialized knowledge, appropriate processes, effective technology, and an implementable framework. How an organization brings those four requirements together will determine their success…and the clock is ticking.

Cyber Forward is the one you need to partner with to solve this complicated, time sensitive issue. We have painstakingly reviewed the federal guidance[7] and condensed the SP-171 requirements into fourteen distinct policy documents, which will guide procedure development and work center training. We understand the 109 types of CUI and can accelerate our partners’ data classification efforts, which are fundamental to DFAR compliance. Last, we offer two tracks to meet your business needs: we can either consult and develop a tailored solution or provide “train-the-trainer” courses to enable you to do so yourself. We stand ready to help.

[1] DFAR - Defense Federal Acquisition Regulation

[2] The DFAR CUI requirements can be found within 48 CFR 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting, and 48 CFR 252.204-73.

[3] 48 CFR 252.204-7012 section (b) (2) (i) states, “Except as provided in paragraph (b)(2)(ii) of this clause, the covered contractor information system shall be subject to the 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””.

[4] National Institute of Science and Technology (NIST) Special Publication 800-171, [Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations].

[5] NIST SP 800-171 ---- 3.1.12, 3.4.9, 3.12.3, 3.13.1, 3.13.13, 3.13.14, 3.14.3 and 3.14.6

[6] NIST SP 800-171 ---- 3.1.7, 3.3.1, 3.4.3, and 3.10.4

[7] We have reviewed 32 CFR 2002, Controlled Unclassified Information; the previously referenced 48 CFR 252.204-7012 and 48 CFR 252.204.73; OMB Circular NO. A-130; appropriate NIST SP 800 publications such as 800-171r1, 800-53, 800-53A, 800-50, 800-39, 800-37r1, 800-30r1, 800-16; appropriate DoD guidance such as Guidance to Stakeholders for Implementing Defense Federal Acquisition Regulation Supplement

Clause 252.204-7012 (Safeguarding Unclassified Controlled Technical Information); the NARA Marking CUI Guide v1.1; the CUI Registry, including all applicable laws specifying CUI control measures.

Latest Posts

Get Your Personalized Compliance Playbook