Proposed Supplement to NIST 800-171 Addresses Advanced Persistent Threats Targeting Defense Contractors

U.S. defense contractors are being heavily targeted by foreign cybercriminals. An internal Navy cybersecurity audit ordered after a series of successful breaches of Navy contractors revealed an agency in complete cyber chaos “in ways few appreciate, fewer understand, and even fewer know what to do about.”

The majority of federal contractors are required to comply with the strict security controls outlined in NIST 800-171, and defense contractors have an additional requirement of complying with DFARS 800-171. However, the recent spate of advanced persistent threat (APT) attacks against defense contractors by nation-state actors prompted the DoD to reexamine its contractor cybersecurity requirements and ask NIST to develop a set of guidelines specifically addressing APTs. The result was NIST 800-171B, which was released in draft form last month.

What’s in NIST 800-171B?

Like 800-171, NIST 800-171B addresses the handling of Controlled Unclassified Information (CUI). Many types of information routinely handled by federal contractors are classified as CUI, from Social Security numbers and other PII to information related to a weapons system or other high-value assets (HVAs). The latter is the focus of 800-171B. CUI related to an HVA has a higher than normal risk of exposure and is the primary target for APT attacks by foreign cybercriminals, but the basic and derived requirements of 800-171 were not designed with APTs in mind.

An APT is a “long game” cyberattack where hackers remain undetected in a system for a significant duration in the pursuit of a specific goal. Perhaps the most well-known example of an APT is the Stuxnet virus, which infected the Natanz uranium enrichment plant in Iran, slowly, silently, and gradually destroying centrifuges over a long period of time.

The enhanced security requirements in SP 800-171B were derived from and map to the requirements in SP 800-53. They are centered around what NIST has identified as the key elements of defending against APTs, including:

• Developing security requirements specifications with a threat-centric approach
• Implementing logical and physical isolation using system and network segmentation techniques, virtual machines, and containers
• Implementing dual authorization controls for the most critical or sensitive operations
• Limiting persistent storage to isolated enclaves or domains
• Continuous monitoring and protection through an SOC that employs advanced analytics

Additionally, 800-171B recognizes the reality of the modern cyber threat environment. Hackers are relentless; the moment one vulnerability is shored up, they find another to exploit. Defense contractors, and all other organizations, must accept that no defenses are foolproof; despite taking every possible precaution, they will eventually be breached. In light of this, 800-171B instructs defense contractors to implement “safeguards and countermeasures to confuse, deceive, mislead, and impede the adversary,” such as misleading hackers in such a way that they question the authenticity of the information they are attempting to steal.

Defense contractors will implement the 800-171B requirements in addition to, not in place of, NIST 800-171. NIST notes that only a small percentage of defense contractors will be required to comply with 800-171B, and even then, the enhancements will apply only to systems that handle CUI associated with HVAs. However, the recommendations in 800-171B could be applied on a voluntary basis by private-sector organizations that wish to take advanced security precautions to protect their high-value digital assets.

NIST is accepting public comments on SP 800-171B through July 19, 2019.

The cybersecurity experts at Lazarus Alliance have deep knowledge of the cybersecurity field, are continually monitoring the latest information security threats, and are committed to protecting organizations of all sizes from security breaches. Our full-service risk assessment services and Continuum GRC RegTech software will help protect your organization from data breaches, ransomware attacks, and other cyber threats.

Lazarus Alliance is proactive cybersecurity®. Call 1-888-896-7580 to discuss your organization’s cybersecurity needs and find out how we can help your organization adhere to cybersecurity regulations, maintain compliance, and secure your systems.

NIST proposes a Secure Software Development Framework to address software supply chain attacks

Applying software updates and patches as soon as possible is a cybersecurity best practice, but what if an update contains malicious code inserted by a hacker? Software supply chain attacks are a serious and growing problem for both private-sector organizations and the federal government. Among other incidents, Chinese nation-state hackers successfully breached numerous third-party contractors working for the U.S. Navy on multiple occasions over an 18-month period.

The Navy contractor attacks and similar incidents were the impetus for the federal government barring agencies from purchasing certain vendors’ software and hardware. However, these bans don’t address the root of the problem, which is that security must be baked into the software development lifecycle (SDLC) from the very beginning. This is why NIST has proposed a Secure Software Development Framework (NIST SSDF).

What’s in the NIST SSDF?

While there are many SDLC frameworks, few specifically address secure software development; they were designed to speed up and bring order to the development process, not ensure security. Instead, project managers are left to integrate secure development practices on their own.

The proposed NIST SSDF does not introduce any new practices. It curates high-level secure software development best practices from a number of existing sources. So that the framework is flexible, it does not specify how to implement its recommendations. Implementation will look different in every organization, as data environments, security objectives, and priorities greatly differ.

The proposed framework includes 19 best practices for secure software development, grouped under four categories.

Prepare the organization. The best practices in this category are about aligning the organization’s people, processes, and technology to build a strong foundation for secure software development. It outlines practices such as ensuring that security requirements for software development are known at all times so they can be taken into account throughout the SDLC; making sure that everyone involved in the SDLC knows what their roles and responsibilities are regarding secure development; and using automation to improve the accuracy, consistency, and comprehensiveness of security practices.

Protect the software. Software must be secured against tampering and unauthorized access, both intentional and accidental. The best practices in this category address how to secure source code for in-house projects and provide recommendations to aid end users in ensuring that the software they acquire is legitimate and has not been tampered with.

Produce well-secured software. The best practices in this category seek to maximize software security and minimize vulnerabilities in each release. Many developers have not been educated in secure development practices and end up unknowingly producing insecure code. In addition to addressing secure software development practices for in-house projects, it provides recommendations for verifying that third-party software meets security requirements.

Respond to vulnerability reports. This step focuses on identifying potential vulnerabilities in each successive release, addressing them, and preventing similar problems in future releases.

NIST hopes that the recommendations in the SSDF benefit both sellers and buyers in the software supply chain. Sellers who adopt secure software development practices will address the root causes of supply chain cyberattacks by minimizing potential vulnerabilities in each release and mitigating the impact of undiscovered vulnerabilities. Buyers can adapt these practices and incorporate them into their software acquisition processes.

The public comment period for the draft NIST SSDF began on June 11 and ends on August 5, 2019.

The cybersecurity experts at Lazarus Alliance have deep knowledge of the cybersecurity field, are continually monitoring the latest information security threats, and are committed to protecting organizations of all sizes from security breaches. Our full-service risk assessment services and Continuum GRC RegTech software will help protect your organization from data breaches, ransomware attacks, and other cyber threats.

Lazarus Alliance is proactive cybersecurity®. Call 1-888-896-7580 to discuss your organization’s cybersecurity needs and find out how we can help your organization adhere to cybersecurity regulations, maintain compliance, and secure your systems.

Let’s examine the role of the 3PAO in the FedRAMP assessment process.

The Federal Risk and Authorization Management Program (FedRAMP) was designed to support the federal government’s “cloud-first” initiative by providing a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. All cloud service providers (CSPs) that work with the U.S. government must comply with FedRAMP, and during the assessment process, all of these CSPs will work with a FedRAMP third-party assessment organization, or 3PAO, such as Lazarus Alliance.

What is a FedRAMP 3PAO?

A FedRAMP 3PAO is an independent assessor that has been certified to help cloud service providers and government agencies meet FedRAMP compliance regulations. CSPs who are pursuing certification through the FedRAMP JAB P-ATO process must partner with an accredited 3PAO for their FedRAMP security assessment. A 3PAO is optional for CSPs pursuing FedRAMP Agency authorization.

The 3PAO accreditation process is quite rigorous, requiring auditors to meet very high standards for quality and technical competence. To accredit 3PAOs, FedRAMP partners with the American Association for Laboratory Accreditation (A2LA). The A2LA assessment process evaluates the 3PAO’s technical competence and assesses their compliance with the general requirements of ISO/IEC 17020:2012 and FedRAMP specific requirements.

FedRAMP 3PAOs must be reassessed and recertified annually.

The role of the 3PAO during a FedRAMP assessment

The FedRAMP certification process begins with the preparation of the System Security Plan (SSP) document, in which the CSP describes all of the information security controls they are currently using and their implementation. Due to the potential for a severe conflict of interest, a 3PAO is not allowed to prepare an SSP for a CSP and then perform the CSP’s FedRAMP assessment; the CSP must prepare their own SSP prior to the commencement of the assessment.

During the FedRAMP assessment, a 3PAO:

• Assesses the CSP’s system’s operational security capabilities and prepare a Readiness Assessment Report (RAR), if the CSP is seeking a “FedRAMP Ready” designation prior to commencement of the formal assessment
• Develops the Security Assessment Plan (SAP), a customized account of the security assessment methodology, in conjunction with the CSP
• Performs the CSP’s security assessment
• Documents the results of the security assessment in the Security Assessment Report (SAR) and supporting documents

The SSP, SAP, and SAR make up the authorization package, which is submitted to the authorizing party (either the JAB or the agency) for review and approval.

After their initial certification is approved, CSPs enter what FedRAMP calls “continuous monitoring.” To maintain their certification, they must have their cloud systems reassessed annually, as well as whenever they make certain changes to their systems, to ensure that the systems still meet FedRAMP requirements. These reassessments must also be performed by a 3PAO.

To make it easier for our FedRAMP clients to prepare their SSP, Lazarus Alliance includes, at no additional cost, access to the IT Audit Machine (ITAM) FedRAMP SSP module from Continuum GRC. ITAM has self-help modules that walk the CSP through the process of preparing an SSP, and Lazarus Alliance also uses ITAM to perform the actual FedRAMP 3PAO assessment. By automating as much of the process as possible, we’re able to dramatically cut the time requirements and costs of FedRAMP certification and put it within reach of most CSPs.

The cybersecurity experts at Lazarus Alliance have deep knowledge of the cybersecurity field, are continually monitoring the latest information security threats, and are committed to protecting organizations of all sizes from security breaches. Our full-service risk assessment services and Continuum GRC RegTech software will help protect your organization from data breaches, ransomware attacks, and other cyber threats.

Lazarus Alliance is proactive cybersecurity®. Call 1-888-896-7580 to discuss your organization’s cybersecurity needs and find out how we can help your organization adhere to cybersecurity regulations, maintain compliance, and secure your systems.