Self-attestations are an increasingly popular tool for cybersecurity compliance frameworks such as the National Institute of Standards and Technology (NIST) Cybersecurity Framework and the Cybersecurity and Infrastructure Security Agency (CISA) directives.
The idea is that organizations attest to meeting specific security controls and requirements without third-party validation. For any frameworks that encourage the practice, attestation involves gathering the evidence you need to substantiate the compliance claims you make.
While self-attestation can provide certain benefits in flexibility and cost, it has challenges too. Foremost, you need robust evidence-collection processes to support attestations across various standards and regulations. Organizations must navigate those challenges as part of a comprehensive self-attestation compliance program.
What Does Self-Attestation in Compliance Mean?
Self-attestation in the cybersecurity realm simply means an organization asserts that it meets the expectations outlined in a particular framework or regulation. Typically, software producers provide letters to federal agencies asserting that their software products meet the latest cybersecurity standards and best practices.
Key compliance frameworks such as the NIST Cybersecurity Framework provide a common language and mechanism for self-attesting to implement cybersecurity best practices. Government directives including Executive Order 14028 also call for self-attestation around software security.
While self-attestation places accountability on vendors, federal customers can also request evidence such as independent component analysis, config scans, penetration tests, and audits.
By attesting to cyber secure development, vendors assure federal agencies that the vendors’ software is trustworthy and aligned to the latest cybersecurity standards.
Benefits of Self-Attestation
There are several potential benefits to self-attestation in compliance:
- Lower compliance costs. Self-attesting avoids the cost of an external assessment, making security standards more attainable for software vendors, especially smaller firms.
- Speed. Self-attestation allows software providers to validate against secure development standards on their timelines, rather than relying on scheduled outside audits. This supports more agile security processes.
- Flexibility. While popular frameworks do provide a common baseline, self-attestation allows the customization of evidence and compliance approaches based on each vendor’s unique business model and risk profile.
- Software supply chain visibility. Since federal agencies can request supporting evidence such as a software bill of materials (SBOM), component analysis, and security test results, self-attestation improves visibility across the software supply chain.
Overall, self-attestation puts accountability onto software vendors to implement secure development practices as defined by government baseline standards. This both reduces procurement costs for federal customers and encourages more secure coding across the commercial software industry.
Examples of Attestation Required by Frameworks
Many cybersecurity regulations and frameworks either recommend or require self-attestation.
- NIST Cybersecurity Framework. Organizations can self-attest to implement the various controls and safeguards NIST outlines. This helps establish a cyber risk management baseline.
- CISA directive. In directives such as Binding Operational Directive 22-01, CISA calls for federal agencies to attest to meeting certain software security standards around NIST SSDF.
- OMB M-22-09. This memorandum from the federal Office of Management and Budget requires software providers to self-attest that they follow secure software development practices under EO 14028. The memo relies on NIST definitions and guidance to define those best practices.
How Self-Attestation Works in Regulatory Compliance Processes
The self-attestation process generally involves three main steps within an overall compliance program:
- Establishing a baseline. The organization adapts standards and safeguards from relevant cyber frameworks and regulations to its specific context and risk profile. This becomes the tailored baseline for attestation.
- Self-assessing against the baseline. The organization performs frequent self-assessments using the adapted security controls and software practices to gauge conformance and track gaps that require remediation.
- Attesting to compliance. Using evidence collected internally through the self-review process, the organization drafts, reviews, approves, and archives formal attestation statements asserting compliance against the baseline.
Evidence Collection for Attestation
Organizations should gather adequate evidence to support software security attestation claims if required by federal customers. Useful examples include:
- Secure coding standards and practices
- Vulnerability scan reports
- Software composition analysis documents
- Third-party component inventories
- Developer training records
- Penetration test results
- Configuration monitoring records
Whether obtained internally or from an external audit, this evidence can substantiate that your company has indeed implemented the expected secure development practices across your software development life cycle (SDLC).
Types of Evidence That Are Relevant to Attestation
Some evidence sources carry more weight for validating software security self-attestation claims:
- External audits. Independent cybersecurity audit reports offer the highest reliability, providing factual third-party confirmation of security controls.
- Internal artifacts. Documentation such as secure coding policies, vulnerability logs, composition analysis reports, and developer training records provide visibility into security processes.
- Observed processes. Direct evidence such as visual confirmation of practices through onsite assessment or demos can supplement documentation. Open-source software, in particular, benefits from observable practices.
- Limited self-assertions. While verbal claims alone have less reliability, they can be strengthened by correlating evidence documentation. Signed self-attestation forms demonstrate accountability.
To substantiate attestation claims, NIST recommends software producers compile multi-factor evidence from reliable sources including independent audits, documentation, and directly observed processes.
Challenges of Self-Attestation in Compliance
Software security self-attestation does pose several challenges that producers must navigate, especially when selling to the federal government.
- They can overstate your security posture without independent validation or Third-Party Assessor Organizations (3PAOs) performing oversight.
- It’s sometimes difficult to collect comprehensive self-attestation from evidence across disparate systems, environments, and supply chain dependencies. Significant time, tools, and discipline are needed.
- They bring accountability risks if significant software vulnerabilities emerge after self-assessment compliance.
- You might be unclear on priorities for security control improvements without external audit findings. That leads to more work to develop a Plan of Action (POA&Ms) and hit milestones.
To succeed at self-attestations, organizations must implement robust processes for firm-wide cybersecurity self-assessments, evidence gathering, and continuous software improvement. Self-attestations do work, but independent audits can validate attestation rigor.
Evidence Collection and More is Made Easy with ZenGRC
Organizations often leverage governance, risk, and compliance (GRC) platforms such as ZenGRC to help tackle those self-attestation challenges.
Purpose-built for compliance, ZenGRC automates policy and evidence management, controls testing, reporting, questionnaires, and other GRC processes onto a single intuitive platform.
Request a demo today to learn more about self-attestation in cyber compliance and how ZenGRC can help!