On March 2023 the White House released a new National Cybersecurity Strategy. The strategy outlines a list of 5 pillars the White House considers critical to improving cybersecurity for all Americans, both public and private sector. The third pillar deals with the drive to shape market forces to improve security and resilience. Part of that list is the idea that too many software producers don’t invest properly in cybersecurity or proper testing and avoid liability by contract. Too often can you find in user agreements’ small print something like: “Licensee agrees to indemnify and hold Licensor harmless from and against all loss, cost, expense, or liability (including reasonable attorney’s fees) arising out of a claim by a third party against the Licensor based upon the Licensee’s use of the Software.” (see more here)
While bigger companies have the power and money to enforce such contracts the White House considers the software and hardware producers ultimately responsible for the software and hardware they produce. To quote from the strategy document: “Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not on the end-users that often bear the consequences of insecure software nor on the open-source developer of a component that is integrated into a commercial product.”
The White House proposes to develop legislation establishing liability for software products and services. Such liability may sound frightening if you’re a company that has so far relied on blame-shifting and obfuscated user agreements to evade exactly that kind of legal trouble. It’s even more disconcerting if we consider the ease with which such claims are presented to the American legal system.
To offer a carrot to all those powerful companies, the strategy proposes the advancement of the Safe Harbor framework to shield from liability those companies that can prove they have done all that they should in order to protect their software. The term Safe Harbor appears in the document only twice. You’re probably wondering what exactly is this proposed framework, where it came from, and what terms are currently covered or are proposed to cover.
In this article, we’ll look into existing Safe Harbor laws and see where they currently apply and what they offer to those companies that abide by them.
What are the existing Safe Harbor laws? Exploring the Laws Currently Providing Safe Harbor
As of today, several states have introduced data breach litigation “Safe Harbor” laws that offer an affirmative defense to liability resulting from data breaches with the aim of encouraging businesses to be proactive with their cybersecurity. An organization must implement and maintain cybersecurity programs that adhere to industry-recognized best practices standards and be able to demonstrate reasonable compliance with them at the time of the breach in order to qualify for Safe Harbor protection.
Ohio was the first state to pass the cybersecurity affirmative defense in 2018. Connecticut and Utah recently adopted their acts in 2021. Similar Safe Harbor laws have been proposed by several other states. In particular, by Iowa and New Jersey in 2020 and by Georgia and Illinois in 2021 (see here for more details). While all of these proposals offer businesses with cybersecurity programs a positive defense, the exact conditions depend on the state. For example, the industry-standard frameworks that are mentioned in the Connecticut, Ohio, and Utah bills are not specifically listed in the Georgia bill. The Georgia law instead mandates a “reasonable” framework that takes into account the company’s size, complexity, and sensitivity of the information being protected. Although this strategy is a key component of the laws in the other states, the Georgia bill appears to have made the decision to not restrict the options to those specific frameworks.
In terms of acceptable standards, the most common US cybersecurity framework today is NIST’s SSDF (NIST 800-218) and this framework is also mentioned in the White House strategy paper as well.
It’s important to note that in none of these cases is the protection from liability absolute. Safe Harbor cannot be used as a defense if an organization knew about a threat or vulnerability and failed to take reasonable action to address it in a timely manner, leading to a data breach. Overall, the idea behind the legislation is to encourage companies to exercise best practices to protect themselves. If they fail to even do the minimum required by industry-recognized best practices they cannot be absolved from their responsibility when a data breach inevitably occurs.
What Is CISA’s Part in This Cybersecurity Strategy?
On April 2023, CISA released a new joint guide for software security called Shifting the Balance of Cybersecurity Risk: Security-by-Design and Default Principles. This policy guide came out about a month after the release of the White House’s strategy paper and its influence can be clearly seen. With the support of several cybersecurity agencies from around the world, CISA aims to take the same approach that the White House proposes and make it global. The guide aims to get software manufacturers to take responsibility for their products and code using radical transparency and building safe products, developing ones that are both secure by design and secure by default.
Another layer of information that is useful to have about your components is their license. A lot of open-source components come with a license that is not compatible with commercial use. It’s important to make sure that all your open-source components, even ones you didn’t include yourself but were included by some other component, are compatible with whatever you’re trying to make in terms of their license.
These fundamental ideas are expanded upon in the CISA guide, which also offers software developers a long list of actionable recommendations for making their products more secure.
It’s interesting to see how many of these specific recommendations are based on NIST’s SSDF framework but expressed in a less voluntary, more practical way. For example, the guide states that software developers should incorporate the creation of an SBOM into their SDLC to provide visibility into their software’s components. While the SSDF does recommend the SBOM it’s never mentioned as a clear, mandatory instruction.
Legalizing Responsibility Shift
The National Cybersecurity Strategy, or at least this part of it, proposes to create a unified Safe Harbor framework based on the existing state laws but far more extensive and comprehensive. For one thing, The existing laws only offer protection from liability in the case of a data breach. The proposed framework would work for any liability for a cyber incident as long as the company being prosecuted can demonstrate its compliance with existing best practices such as the SSDF.
The proposed framework must be adaptable and be able to evolve to incorporate new security frameworks and new best practices as they are discovered and implemented. The strategy proposes to keep investing in security disclosure programs and in the development of additional SBOM tools and use cases.
The software ecosystem cannot keep advancing as it has so far without a serious shift in responsibility. It should be clear to everyone, producers and users alike, that security comes first and foremost in any software product, starting from the initial idea and design stage onward. Security should not be a thing added as an afterthought after the development is done. The liability shift cannot happen without the private sector and as this sector is notorious for its abhorrence of federal heavy-handed involvement, the idea of offering a ‘carrot’ in the form of a ‘get out of jail free’ card is a good incentive.
How To Prove Adherence To Cyber Security Best Practices
Having a law that says you need to ‘prove your adherence to existing best practices’ is all well and good how would you go about it? The current US regulations and best practices such as the SSDF encourage software producers to make use of attestations to secure their supply chain and thus to provide such proof.
Attestations are verifiable, cryptographically signed pieces of evidence (such as files, folders, repositories, file provenance, or test results). Such evidence should be linked to a specific environmental context, making the attestation an immutable piece of evidence that can be verified to prove the existence of the event or file testified to.
Scribe offers a tool called Valint that provides the capability to generate evidence, sign it into an attestation, and later, retrieve and verify it. Using this tool in conjunction with the Scribe Hub platform you can generate an evidence trail of attestations not just for your final product but for each of the builds leading to it, demonstrating your adherence to security best practices continually and over time instead of just at a singular point such as right after the build is done.
Scribe offers the use of Valint for free and offers the use of its platform on a freemium basis – you can start experimenting with it for free right now. Try Scribe for free and see what tools and capabilities it offers you. Collecting such evidence continually for each of your builds can also offer you a unique perspective of your products’ security over time. Since it looks like the prevailing winds of change are pointing towards expanding software producers’ responsibility, it seems like a good idea to start collecting your hard evidence and attestations now, rather than wait for when it’s codified into law.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
