The CISA Secure Software Attestation –Why Use an External Assessor?
With the deadlines for the newly incorporated Cybersecurity Infrastructure and Security Agency (CISA) Secure Software Development Attestation Form looming, organizations supplying government-used software must get their ducks in a row to ensure compliance with these requirements.
In completing the CISA form, organizations can either self-attest or engage an accredited Third-Party Assessment Organization (3PAO) for assessment. As one of your 3PAO options, in this article, we’ll first discuss how things progressed to this pivotal point and why a 3PAO—specifically Schellman—may be your best option for compliance.
The Progression of Federal Software Security Concerns (How We Got to This Point)
What is Executive Order 14028?
This new requirement for government-used software first spawned back in May 2021, when President Biden published his Executive Order on Improving the Nation’s Cybersecurity (E0 14028)—an EO that took specific and significant aim to improve the security of federal IT systems as well as the private sector technology and software providers that support them.
To assist the relevant agencies and their private sector suppliers, Biden—within EO 14028—ordered the National Institute of Standards and Technology (NIST) to develop a framework to standardize the threshold for software security and secure software development.
What is the NIST Secure Software Development Framework?
Nearly a year later, NIST published its Special Publication (SP) 800-218, also known as its Secure Software Development Framework (SSDF) in February of 2022.
Designed to be readily adaptable to different development environments, technologies, and organizational structures, NIST’s SSDF aims to provide a structured approach to identifying, mitigating, and managing security risks associated with software applications. Through its holistic set of guidelines, best practices, and recommendations, the SSDF can assist software developers, architects, and security professionals with integrating measures to secure all phases of the software development lifecycle (SDLC).
NIST also published several other documents and guidance that could help organizations improve their software security, including:
- Security Measures for “EO-Critical Software” Use (also published to satisfy Biden’s specific asks in his EO); and
- The NIST Security Software Framework (intended as fundamental, overarching guidance for software security).
Moreover, the Office of Management and Budget (OMB) published two related memorandums that integrate EO 14028 and the SSDF to identify requirements for government agencies and software providers while also address definitions, actions, responsibilities, and timelines:
- M-22-18: E“nhancing the Security of the Software Supply Chain through Secure Software Development Practices”
- M-23-16: “Update to Memorandum M-22-18, Enhancing the Security of the Software Supply Chain through Secure Software Development Practices”
- M-21-30: “Protecting Critical Software Through Enhanced Security Measures” (a bonus memorandum included for the definition of critical software)
What is the CISA Secure Software Attestation Form?
Also in President Biden’s EO 14028 was a new requirement for CISA to ensure software producers attest to the requirements through a new form that “identifies the minimum secure software development requirements a software producer must meet, and attest to meeting, before software subject to the requirements of M-22-18 and M-23-16 may be used by Federal agencies.”
So, if you’re a software producer and want to provide products to the government for use, you should likely first implement elements of the NIST SSDF into your software development practices before attesting—through the CISA form—that the software you produce is developed in conformity with those guidelines, and you must complete that form by June 8th, 2024 if you produce critical software (though you have a few more months if you produce non-critical software, as that deadline for those products is September 8th, 2024).
Self-Attestation vs. Using a 3PAO for Your CISA Secure Software Attestation
Given the incredibly quick turnaround at this point—the date of this blog is May 13, 2024—the good news is that you have the option to self-attest—meaning, you can have a chief executive of your organization or a chosen delegate sign the form.
Alternatively, you can engage an accredited 3PAO to assess of your software security before issuing a formal report that you can attach to the CISA self-attestation in lieu of having your CEO sign it.
While you may be thinking that bringing in a 3PAO would just eat up valuable time, first let us just say that even if you weren’t able to have an assessment completed before June 8th (or September 8th), a letter confirming your engagement and intent to undergo one would suffice for CISA.
You might also be thinking that it’d be much easier to just sign the form rather than having to deal with an entire audit process but consider that using a 3PAO for your CISA Secure Software Attestation would benefit your company beyond satisfying a new federal requirement. Independent validation of your security measures would provide further assurance to your customers—including federal government agencies—that they can trust your software
Why Schellman for Your CISA Secure Software Attestation
While you do have other options, being a 3PAO ourselves, we at Schellman have already been engaged by several clients—including those for whom we perform FedRAMP assessments—to conduct this type of review, and we might also be the right partner for you due to our:
- Independence: As a third-party assessor recognized by the government and a leading provider of FedRAMP and CMMC assessments, we provide an objective evaluation of your software security.
- Depth of Secure Software Knowledge: Our expertise in this area extends beyond the NIST SSDF standard to other related best practices from the PCI Secure Software Framework (SSF), NIST Cybersecurity Framework (CSF), OWASP, and more.
- Efficient Methodology and Workflow: Through our AuditSource platform and our focused approach that we’ve refined over 20 years in operation, we streamline evidence collection and observation testing, thereby reducing the burden on your security, development, and operations teams.
In performing software security assessments, we use a systematic approach to evaluate software production, examining controls at the enterprise, build environment, and product layers as part of a process that includes the following stages:
|
Scoping |
First, we’ll identify the critical (and non-critical) applications. In many cases, your customers will have already relayed what is critical or not critical but either way, we’ll review your full catalog of products to understand their respective criticality and use-case within the federal government. |
|
Enterprise Controls Review |
As software security begins at the enterprise level, we’ll then review and evaluate your policies, procedures, change control processes, quality assurance, and developer training. |
|
Build Environment Testing |
When assessing your build environment—where your software is developed, tested, approved, and deployed, we’ll interview build environment personnel and review documentation and technical evidence to validate the security of the code as well as the processes used to develop, test, and deploy it. Items tested will include: · Environment segregation · Logging · Multifactor authentication · Encryption · Software testing and scanning · Software supply chain · Vulnerability and flaw management (NOTE: For small businesses, there may be only one build environment, but larger organizations could have distributed teams of engineers and testers.) |
|
Product Specific |
If you only produce a single product—or a single subset of products—we’ll example the product and the supporting evidence showing that the security controls were in place as defined by enterprise and build environment controls. |
|
Reporting and Feedback |
Finally, we’ll provide you with an independently assessed report to submit to CISA—our deliverable will also contain identified opportunities for improvement of your adherence to the broader NIST 800-218 standard, as well as our feedback regarding best practices overall. |
Getting Started in Meeting the CISA Secure Software Deadline
Whether you engage us as your 3PAO to attest to your security or not, if you produce software for government use, you’ll need to complete the CISA form—and soon.
But if you are interested in learning more about partnering with us in meeting the CISA mandate, contact us today so that we can discuss further how that engagement would progress, as well as how to enhance your software security overall.
About Douglas Barbin
As President and National Managing Principal, Doug Barbin is responsible for the strategy, development, growth, and delivery of Schellman’s global services portfolio. Since joining in 2009, his primary focus has been to expand the strong foundation in IT audit and assurance to make Schellman a market leading diversified cybersecurity and compliance services provider. He has developed many of Schellman's service offerings, served global clients, and now focuses on leading and supporting the service delivery professionals, practice leaders, and the business development teams. Doug brings more than 25 years’ experience in technology focused services having served as technology product management executive, mortgage firm CTO/COO, and fraud and computer forensic investigations leader. Doug holds dual-bachelor's degrees in Accounting and Administration of Justice from Penn State as well as an MBA from Pepperdine. He has also taken post graduate courses on Artificial Intelligence from MIT and maintains multiple CPA licenses and in addition to most of the major industry certifications including several he helped create.