First Report from the Cyber Safety Review Board
What an honor it has been to participate in the first-ever Cyber Safety Review Board process to deliver our first report focused on Log4j. I’m excited that we are just getting started and honored to be part of this new effort that has the potential to increase our cyber resilience and agility now and in the future.
The full report is worth the read for everyone, even though many recommendations are directed at what the government should do or support.
Hot off the proverbial presses -- what can the public learn from this report focused on the log4j incident?
For all organizations in general:
Know your assets before you “need” to (hint: you always need to know what your assets are and what versions of software are running on the most critical systems)
Practice rapid update rollouts that include prioritizing those assets
Muscle memory in organizational response was a key factor in those that reported the fastest and most comprehensive remediation
Build relationships with your vendors so that you know how to get information on their updates when a library is affected
Note which of your vendors seemed disorganized or uncommunicative and consider replacing them
Have a plan to implement mitigations while awaiting official patches for affected software running in your network
For software makers in general:
Follow best practices for secure development
Have a process for investigating vulnerability reports and responding with comprehensive fixes
Build an SBOM so you know what libraries and dependencies your software has
Provide your SBOMs to customers to help them speed up their identification of possibly affected packages in their environments
Build operational capacity for rapid response and coordination for the next library vulnerability that might affect your software
For open-source maintainers:
Plan to release security advisories at the same time as any public release candidate that addresses a security vulnerability
One particularly interesting area, where I have a strong personal opinion, was the bit about what China may or may not be requiring in terms of early vulnerability disclosure. The board’s concern is that if the Chinese government requires disclosure of vulnerabilities to them by affected companies within two days of becoming aware of those vulnerabilities, China might gain an offensive advantage.
My personal concern is that our government and others might try to mirror this requirement in some way, which will fundamentally break the principles of least privilege when it comes to Coordinated Vulnerability Disclosure.
Only the organizations that are responsible for creating a fix should know about a vulnerability before a patch is available. Adding government entities to the embargo during vulnerability coordination and disclosure will not meaningfully add to our safety, but it does meaningfully and dramatically increase the risk of a leak before a patch is ready. It would also create a new high-value target: a government-run treasure trove of unpatched vulnerabilities. Aggregating vulnerabilities from multiple software vendors in one place would raise the risk of a Pandora’s box event if that database of bugs was compromised.
As Congress considers the vulnerability landscape, contemplating requirements for reporting vulnerabilities to the U.S. government before they are patched, I hope they will listen to those of us who have considerable experience in weighing the risks of adding parties to vulnerability disclosure.
The CSRB report does not levy an opinion on this, but I do as an individual expert who created the first multiparty supply chain vulnerability coordination process at a major software vendor.
My opinion is that we will not see an increase in our cyber resilience by fashioning laws to artificially bring the government into Coordinated Vulnerability Disclosure as an observing party to unpatched vulnerabilities. What we do need are more organizations around the world who are prepared with asset lists, SBOMs, and well-oiled vulnerability response capabilities that are ready, able, and willing to help collectively defend the Internet that we all share.
I’m looking forward to my continued work on this and the other two U.S. government boards on which I humbly serve.