Making Integrity an Industry Standard

Software vendors clearly need to do more to show the software they provide does not contain a backdoor. But with complex software this is never going to be perfect, so businesses must move to regain control over their boundaries to block off any backdoors.

Google’s SLSA initiative, and others like it, shows the way forward for software vendors. It’s about ensuring the integrity of software artifacts throughout the software supply chain, but unlike other forms of engineering guidance it is something that can be measured.

For the business, there are several relevant moves in the industry. These introduce authentication and access controls that leverage cloud infrastructure to create a virtual boundary around the business that’s strong but flexible. Then, data flows can be monitored and controlled to detect or otherwise defeat backdoor communication channels.

These two aspects must be combined. Businesses need to demand the integrity guarantees that initiatives like SLSA will deliver for all the software they use. Software vendors need to adopt the protective measures to make sure they stay in control of their software build and distribution systems.

Forcepoint’s security technology is leading the way here. Our SASE solutions provide a cloud-based boundary to protect the distributed workforce, while our UEBA identifies and blocks backdoor information flows. For the Critical infrastructure, where strong physical boundaries are needed, our Cross Domain capabilities ensure information flows freely where required.

Controls on Multiple Fronts

A business needs to trust the authors of the software it uses. The business must trust the authors don’t add backdoor functionality into the software that would undermine their security, intentionally or unknowingly. A respectable business is not going to intentionally add a backdoor, so normal supplier selection processes will ensure the business is not attacked directly by the authors. But it is more difficult to be sure that no back door is introduced without the authors knowing, either by mistake or because someone else made unwanted modifications.

To avoid backdoors being introduced unknowingly, the software production process needs to be closely controlled. The software must be written, built and tested by the authors without any external interference. In practice this means managing the whole process using a repository. The repository contains all the artefacts relating to software production – source code, test data, build scripts and the resulting builds. Builds are uniquely identified and the repository contains all the information needed to trace backwards to establish how it was built, what testing it had and the source code it was built from. Also, when source artefacts change, the repository makes it possible to identify the user responsible.

Access controls around the repository ensure changes can only be made by authorised users, and that changes are properly reviewed and tested before they are adopted. All this makes sure released software builds are the product of the software authors and don’t contain any serious mistakes that would leave the user at risk. These controls, coupled with the traceability, assure the software consumer that the software is safe to use.

But in practice this is not sufficient, because the software authors will inevitably be using software produced by others. This externally developed software might be used as tools for the production of software, or be incorporated into the final product, and it might be obtained either in source or binary form. Whichever form it is in, the externally developed software might contain backdoors that mean the end product is unsafe.

What’s happening here is that the software authors are the consumers of the software produced by other software authors. So, the authors of some software need to trust the authors of any other software they import. This is made complicated by the use of large software libraries that have many contributors. The inter-relationships between these libraries are complex and dynamic, so developers use these libraries through a package manager that pulls in all the required components to support anything the developer wants to use.

The result is an easy life for the developer, which helps deliver complex software fast, but also a complete lack of control and visibility as to what is incorporated into the software they build. This gives rise to the need for a package management system that imposes some control over the process and allows it to be audited.

There are many initiatives that are bringing together these kinds of control and audit measures into frameworks that can be applied by software businesses to strengthen their security and enhance the integrity of the software they produce. Google’s SLSA is but one. It is firmly based on practice and it seems likely to have a big impact on the way open-source software libraries will be consumed in the future.

The crucial mark of success will be that consumers use the integrity information produced by these frameworks to make buying decisions, as competition will then force a pace of change to make software increasingly more secure.

Secure Distribution is Key

A business wants to be sure it’s safe to run the software they use. That not only means trusting the authors of the software, but also being sure that the software which is run is actually the software the authors created, and not software that’s been modified or created by somewhere else. In practice, this also applies to software authors, because they will inevitably be importing software from other authors.

The main mechanism employed here is to digitally sign software when it is produced and to check that signature when the software is installed or run. The principle is simple, but it has to be implemented carefully, because if an attacker can subvert it, they have an instant way in.

Firstly, it is important to protect the keys used for the signing. If these are divulged, an attacker can use them to sign unsafe software that will be trusted by its users. However, even if the keys are stored so they cannot be divulged, for example in a hardware security module, the attacker still succeeds if they can get control of the system that uses the keys. This means the software build system, that holds and uses the keys, must be well protected.

Secondly, the mechanism that imports software has to check the signature and reject any where the signature is invalid. This system must be protected to ensure it cannot be bypassed, that it cannot be disabled by the attacker and that the signature verification keys cannot be replaced by the attacker (as this would mean the user trusts anything produced by the attacker).

All this requires strong boundary security mechanisms to protect both the producer and consumer system, something Forcepoint excel at, along with proper procedures around the cryptography.

Security Must be a Business Priority

It’s clear that a business does indeed need to be careful to avoid software supply chain attacks, but what that really means is taking security seriously enough to change the business processes around software production and consumption.

Software developers are not willing or able to sacrifice velocity by limiting the use of third-party code, or by thoroughly reviewing it before use. What’s needed is a way of living with this. Software production must adopt processes that not only ensure delivered software is safe and free of backdoors, but also provide evidence of this to customers. Software consumers, including developers, need to demand this evidence and make it part of their buying processes.

Systems need a boundary that is flexible to support the business, but security mechanisms must be deployed to stop uncontrolled software distribution, limit access to backdoors and restrict the ability of a backdoor to communicate. This is not only true for end users, but also software developers.

Software distribution mechanisms must allow consumers to determine the integrity of the software they receive, but these mechanisms must themselves be protected from attack.

Businesses can no longer ignore the cyber security problem, hoping that others will be hit first and the attack neutralised before it reaches them. Supply chain attacks, once established, are likely to remain for the long term. The best form of defence here is to have one – one that stops the attacks getting in through the supply chain, backed up by measures that stop backdoors being exploited.