When it comes to developing and selling software to the US government, companies are under a new set of guidance. Two years ago Executive Order 14028 – Improving the Nation’s Cybersecurity (EO) was issued requiring a host of actions be taken to improve “practices that enhance the security of the software supply chain”. In a recent memo, the Office of Management and Budget (OMB) – in accordance with the EO – requested all agencies comply with this NIST, which created the Secure Software Development Framework, NIST 800-218 for this purpose. The Guidance document details specific steps companies must take to ensure the security of their software development process.
This new regulation applies to all companies that develop, sell, or want to sell software to the US government and requires these companies to assess their compliance with the NIST Guidance document and develop an action plan to address any gaps. They must also document their activities to prove compliance.
The Need for Governmental Compliance
The purpose of identity attestation is to ensure that companies take a risk-based approach to secure software development. With 82% of CIOs believing their software supply chains are vulnerable to cyber attacks, protection is needed more than ever, especially for companies working with the government. Through this initiative, the government hopes to improve the overall security of federal information systems. All companies that intend to do business with the US government should take this new regulation seriously and assess their compliance with the NIST Guidance document.
How is the NIST SSDF, 800-218 Relevant to My Company?
If your company is involved in software development for the US federal government, it is important to be aware of the NIST Secure Software Development Framework (SSDF). The framework provides specific guidance on how to secure the software development process.
The following are key points to keep in mind when it comes to the NIST guidance document:
- It is guidance that outlines best practices for software development security.
- Companies that procure software with the US government should be aware of NIST 800-218 and should, at least, self-attest to the practices outlined in the document.
The NIST SSF includes the following:
- A definition of what constitutes secure software development.
- A description of the processes and activities involved in secure software development.
- Best practices for each stage of the software development process.
- Guidance on how to integrate security into the software development process.
- A description of the tools and techniques available to help secure the software development process.
Companies that do not comply with the new regulation may be ineligible to do business with the US government. In addition, they may be subject to audits and investigations.
Staying Compliant to Regulations, Requiring Identity Audits, with YouAttest
The NIST SSDF is an important step in ensuring the security of software development. All companies that develop software for the US government should take this new regulation seriously and assess their compliance with the document. They should also develop an action plan to address any gaps and document their activities. Taking these steps will help protect your company from cyber attacks and will also prevent you from being ineligible to do business with the US government.
The new government regulation requires software producers to attest to compliance with the framework to ensure that companies undertake a risk-based approach to secure software development.
YouAttest is the ideal tool for companies to attest to the current state of users, admin, and developer privileges and attest to any changes in this grouping. YouAttest executes the identity audit, by conducting an automated user access reviews (UARs), that can be used as evidence on these controls.
This is clearly referenced in a best practice in the NIST SSDF 800-218 document in section PO.5: Implement and Maintain Secure Environments for Software Development.
Example 6: Regularly log, monitor, and audit trust relationships for authorization and access between the environments and between the components within each environment.
Note similar controls for identity access audits are spelled out in other cyber guidances such as: CMMC, SOX, SOC2, HIPAA/HITRUST, PCI-DSS, GLBA, ISO 27001.
As with all recent government cybersecurity initiatives, dates may slip and the contours of the requirements may change around the edges, but the basic policy directive here is clear. Software producers that intend to keep the US government as customers need to get on board. In addition, contractors whose products rely upon or incorporate software will need to ensure that the vendors upon which they are dependent are fully engaged in the attestation process.