Recent attacks on software supply chains have shown the potential to affect hundreds, or even thousands, of companies. They have also revealed the extent to which software is a collaborative, distributed, and aggregated effort, with potential vulnerability appearing throughout the system.
Grant Thornton Cybersecurity and Privacy Advisory Services Managing Director Maxim Kovalsky recently explained how these vulnerabilities arise in both the underlying code and the environments through which the code passes. To address this, the federal government has issued Executive Order 14028 (EO 14028), which establishes new requirements for software producers who supply the federal government.
To discuss the implications of this order, Kovalsky moderated a panel of industry experts that included Mitch Herckis, Director of Federal Cybersecurity at the Office of Federal CIO, Office of Management & Budget; Tim Brown, SolarWinds Chief Information Security Officer; Neatsun Ziv, Ox Security Co-founder and Chief Executive Officer; and Jitendra Joshi, Grant Thornton Cybersecurity and Privacy Advisory Services Director.
Herckis explained that the executive order is, in fact, a comprehensive order which addresses a wide range of topics — including how the federal government organizes itself around zero trust initiatives, shares threat information and provides the equivalent of an Energy Star rating to Internet of Things (IoT) devices. The part of the order which sets forth requirements for providing software to the federal government was developed with extensive industry input, in conjunction with guidance from the Office of Management and Budget. It requires CISOs to self-attest that certain minimum requirements have been met. Herckis said that, as time goes on, the intent is to further iterate those requirements so the bar can be continually raised. EO 14028 specifically addresses software developed after the release of the order.
Brown sees the need for such requirements, and thinks it's a good initial step. The compromise of SolarWinds’ Orion product delivered valuable insights into the nature of the threat. Brown said that the old assumption that only significant expenditures on third-party products should be scrutinized for security proved to be misguided, as Orion did not represent a significant spend by enterprises. Threat actors can cause significant damage to an organization by targeting a $25,000 piece of software. He emphasized that it is important to identify both the existence of a vulnerability and potential exploitability of that vulnerability. The goal is to provide everyone involved with a sense of the real, practical risks.
Avoiding undue burdens
What about vendors who were not able to meet the minimum requirements laid out in the order, especially in a world of continuous development and integration where software could be versioned several times a day? Herckis said that the goal was to reduce risk while still preserving the “broad and diverse marketplace that’s necessary to ensure the federal government is able to do its work.” He noted that, in certain worse-case scenarios, extensions and waivers could be granted, although “it’s a high bar.”
To further eliminate unnecessary work, the standard only requires a software bill of materials (SBOM) for software that is used in critical infrastructure. The standard aims to create secure and centralized clearing houses, and offers reciprocity between federal agencies. To ensure the relevance of documentation requests, agencies must develop a plan outlining what they require, why they require it, and what staffing and processes they have in place. In many cases, the request will only be a few pages.
The scale of the challenge
Given the vast amount of documentation in an SBOM — often 100,000 lines of data that includes information about dependencies and vulnerabilities — Ziv wondered whether software buyers could take effective actions if they identify a vulnerability. Even if it were all properly digested, this approach would have only been able to forestall a small percentage of recent attacks.
In a sense, no approach may be enough. Brown pointed out that the regulation probably would not have prevented extraordinary events such as the Solar Winds breach. That was a case of a nation-state bringing enormous resources, operating stealthily over an extended time and trying multiple approaches against a private company. Brown said that, in reality, the vast majority of attacks have far less resources and determination. He believed the executive order is an important step toward fending off opportunistic threats.
Possible alternative approaches
Ziv suggested that companies should develop a way to capture and declare the security of what they are building, arguing the best approach was to implement smart contracts which assigned the responsibility to whoever is building that component of the software.
Herckis noted that the current philosophy toward audits is to rely on self-attestation and the power of a C-level officer signing off, although in some instances providers will rely on third parties to audit the software vendor’s security practices. Brown was concerned that, in the absence of more structured guidance and controls — as with SOX audits — the attestation process puts undue responsibility on CISOs.
The importance of culture
In addition to the procedures outlined in EO 14028, the panelists emphasized the importance of soft factors such as education and culture. Ultimately, software buyers need to be able to understand, contextualize, and interrogate the data vendors provide.
Kovalsky posited that many “shift left” attempts aiming to integrate security earlier into the product development lifecycle have been less than successful. Interrogation of the software supply chain attempts to “shift” even further left. Brown saw enormous opportunity for CISOs to redefine their role in that process, by putting in guardrails which facilitate faster development cycles without compromising security of the products. Joshi expressed concern that, although guardrails and training have been in place for some time, the supply chain remains an existential threat for many companies. There is a need to shift the security mindset to better collaboration. More work is needed to enable the developers and builders by working with them in the trenches on the “how” that will help reduce the friction in a meaningful manner.
Ziv concurred: “The right thing to do is to start with the culture saying ‘security is here to help you. We are not going to do bad things to you. We're not going to force you to do things that you do not understand. We are here to assist you, because you're accountable for security but we are responsible for helping you and making sure that you have everything that you need. Once you're educated, we're going to place guardrails.’ It is a process. We have accompanied a few companies that have done this journey. We've seen the developers in those companies are saying ‘we own security’ and you see them walking in the corridors with hacker hoodies saying ‘I'm part of the security team.’”
Our cybersecurity and privacy insights
No Results Found. Please search again using different keywords and/or filters.
Share with your network
Share