Last month, my column "Implied Trust, Presumed Secure and Other Dangers of Supply Chain" covered supply chain security in the context of the Naval Undersea Warfare Center (NUWC) infiltration of a contractor's network by Chinese hackers. Much to the US Navy's chagrin, while the pilfered 614 gigabytes of US Navy data were unclassified, aggregated it could be (or was, depending on the press release) classified.
Regardless, it was a massive heist that included signal, sensor and cryptographic systems data, submarine radio room information, the Navy's submarine development unit's electronic warfare library and information on Sea Dragon, a “disruptive offensive capability” project.
While I underscored the importance of comprehensive hardening - understanding the operational environment, dissection of technological and process layers, reverse engineering of forensic outputs from defined assets, mapping data state changes and attack vectors to continuous improvement - I was remiss in digging into the weaknesses of imposed regulations.
From that article, some interesting conversation occurred with one common question, if government contractors are required by recent amendments in DFARS 252.204-7012 to comply with NIST 800-171, how could this happen? Well, there are a few ways, keeping in mind these are hypothetical to the NUWC hack since we don't have enough procedural or operational information to perform an forensic breakdown.
For context, this we know: the many government data breaches in recent years ranged from benign unclassified to classified data, often rooted in escalated privileges, misapplied access provisions or breakdowns in controls between state changes. And sometimes regulatory obscurities.
Despite efforts to improve legislation, regulations, standards, procedures, controls and vulnerabilities reporting, there is still little control over contractors and suppliers handling of "controlled" government data; the following explains why.
For background, the Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012, supplemented to the Federal Acquisition Regulation (FAR), was brought into force December 31, 2017. In simple terms, it requires that contractors under a Department of Defence (DoD), General Services Administration (GSA) or National Aeronautics and Space Administration (NASA) contract must comply with NIST 800–171, especially "adequate security" developed by the National Institute of Standards and Technology (NIST).
The NIST 800-171 framework, in short, provides protection for controlled unclassified information (CUI) in non-federal systems and organizations, defining CUI as any potentially sensitive, unclassified data requiring controls, defining its safeguarding or dissemination. It's the potentially part that can be problematic to compliance, if it is not clearly and properly defined.
To assist in this process, NIST (the organization) has published the NIST MEP Cybersecurity Self-Assessment Handbook and provides outreach and support for the application and implementation of these cyber security standards, privacy requirements and evaluation of vendor security posture. Also, there is no shortage of NIST 800-171 compliance consultants and tools available.
Naturally, not every contractor would have met that date and/or the regulations, for any number of reasons, and many others may have been deemed compliance but aren't, either knowingly or unknowingly. Considering the above, I'll dissect the two possible scenarios - failure to comply and inadequate compliance (noting either can occur with contractors or their sub-contractors) to see where the wheels could have fallen off with the NUWC contractor. And whether it could again with others.
Zero Compliance: Failure to Comply by Contractors and their Sub-Contractors
If a contractor, or their sub-contractors, fails to comply (for whatever reason) and has a DoD contract in play within their facilities, assets are exposed. In a post-attack scenario, whatever the damage, the consequences and sanctions of non-compliance, considered to be contract default, runs a long gamut. In this case, negligence may result in loss of contract award, negative performance review and/or future bid protest.
Should it be found that compliance certification was falsified, the contractor may be subject to default termination, suspension, debarment and/or liability under the False Claims Act or other false statement statutes. Regardless, if the failure to comply was discovered post-breach, the horse would already have left the barn - the asset compromised.
Close Doesn't Count: Inadequate Compliance by Contractors and their Sub-Contractors
The more likely scenario than the complete failure to comply would be 'inadequate' compliance due the number of possible interpretive, procedural or administrative errors, such as failure to properly interpret and implement NIST 800-171 or failure to clearly identify assets and their parameters in the procurement process and contract award.
Compliance really goes back to any number of requirement bound activities - if the requirement is not fully understood, analysed and met, everything thereafter is flawed. Within the context interpreting and implementing NIST 800-171, many things can wrong: improperly assessing compliance, failing to identify eligible systems, data or ambiguity, failing to adequately close gaps or failing to properly execute remedial approaches or work-arounds, such as segregation of assets.
Again, the fundamental basis of NIST 800-171 is to provide guidance in hardening systems to protect assets that belong to or were developed for the DoD by the contractor or its sub-contractors - but it has the be the right system and the right asset.
Knowing the asset's states and where a system begins and ends, its management controls, mission objectives and operating environment are only half the battle. As NIST 800-171 is intended to be high level and flexible, it does not address complexities of an operationalized network architecture. That requires knowledge, expertise and very concise documentation for internal use and for compliance.
Looks Right To Me!: Failure to Properly Assess Compliance
The market for assessment of NIST 800-171 compliance is burgeoning for a reason - it's an arduous task and does require impartiality, as well as expertise. Contractors who pursue assessment on their own may risk improper assessment of their compliance, even if they understand the guidelines and contractual requirements and information in scope.
Don't forget that NIST 800-171 was designed to be technology-agnostic - a blessing and a curse - to permit a tailoring based on contractor size, capacity, architectures, etc. Considering this, expect some ambiguity. Since the DoD does not certify compliance nor does it endorse a third-party certification process, an external review becomes extremely valuable.
As stated earlier, the foundation of compliance begins with fully understanding, analysing and accurately and completely meeting the requirements. Failing to do so, renders the standard and its level of security ineffectual, making the systems and contractor non-compliant.
Cherry-Picking or Taking the Whole Tree: Failure to Identify Eligible Systems, Data and Ambiguity
One of the primary questions has been how to determine the eligibility of system. Not all systems that are accessing, storing or processing covered defense information (CDI), will be in scope of DFARS 252.204-7012, requiring NIST 800-171 compliance. Other information may include the contract documentation that is in scope of the DFARS where CUI that is "collected, developed, received, transmitted, used or stored by or on behalf of the contractor in support of the performance of the contract". This is where compliance gets tedious. Understanding the definition of CDI provided by the National Archives and Records Administration registry is important in defining all information in scope. Noting, CDI includes CUI and controlled technical information, it may not be specified in the contract.
Going back to ambiguity, considering the risks of breaching contractual duties to a contractor's business or their legal liability, documentation of 'good faith' steps taken to mitigate known and potential issues is time well spent. Thorough cross-referencing from the NIST 800-171 controls to the NIST 800-53 will provide additional clarity and structure to the controls that form overall compliance.
Mind the Gap: Failure to Adequately Close Gaps
Once gaps are properly identified they must be closed and if not in short order, certainly with a planned approach with specific details, outcomes and implementation dates. Clearly failing to adequately close or plan to close gaps results in non-compliance. The DoD is aware that not all contractors can meet all NIST 800-171 required security controls immediately.
For that reason, the accepted and preferred method in identifying and coordinating gaps is in a System Security Plan (SSP) and Plan(s) of Action and Milestones (POAMs) that reflect the challenges of implementation of these controls with priority and timelines in a workable path.
Work-Arounds: Failure to Properly Execute Remedial Approaches
Remedial approaches - or work-arounds - that alter the contractor's internal processes or procedures, rather than adopting certain required controls, may include separation of duties, segregation of assets, modifications to network zones or other approaches. While these may be acceptable, ensuring that they are properly executed and that resulting vulnerabilities or gaps are identified and addressed are essential to compliance.
Government has no choice but to rely on contractors and for as much they try to mitigate risk, some will have to be accepted. With the NUWC contractor hack, we don't know whether they were NIST 800-171 compliant or were inadequately compliant. While DFARS 252.204-7012 and NIST 800-171 was a step in the right direction, it didn't go far enough. Allowing certification of compliance to be managed externally and arms-length to the government might be the next big legislative change.
From the scenarios shown, it's easy to envision how unregulated assurance of certification and assessment can - and will - result in serious problems. In this case, it can't said enough: if compliance requirements are not fully understood, analysed and met, everything thereafter is flawed.
written by Valarie Findlay