������

Over the last three years, amid some of the most disruptive conditions ever experienced, a huge wave of malicious attacks began targeting the software supply chain. At a time when teams were already fighting to maintain business as usual,

��

One of the reasons why these attacks proved so disruptive is because they can scale so rapidly. By exploiting a vulnerability inside a key piece of software used by millions of companies around the world — like, for example, SolarWinds, a hugely important part of many organizations’ IT infrastructure — attackers can immediately compromise software further down the supply chain that depends on it.

��

But that doesn’t necessarily account for the immense growth of these kinds of attacks. In reality, the rise of supply chain attacks is down to two things: first, the increasingly distributed nature of software systems, composed of interlocking products and services, means that software supply chains are complex and diffuse; this gives attackers more potential points of entry. Second, the problem is propounded by the fact that increased complexity makes transparency immensely challenging — often the issue is either invisible or unacknowledged.

��

Given the potential impact of security breaches on reputation and revenue, taking it seriously is critical. But to do so today requires business leaders to go beyond the mindset that views security as something static, a set of hires or IT assets that need to be ticked off a list. Instead, security needs to be seen as something dynamic and requiring constant attention. In this article we’ll outline what this means in practice with the key lessons that should be drawn from the recent spate of disruptive supply chain attacks.

Lesson #1: Always know what’s running across your application estate

��

The complexity of many organizations’ application estate is such that without changing the ways teams work and adopting new techniques it is almost impossible to know the security status of every single piece of software. This is one of the reasons why supply chain attacks are so compelling to malicious actors — they are relatively invisible and can be difficult to capture quickly. Indeed, even when a vulnerability becomes known, determining its impact can be challenging, leading to levels of disruption which can be just as damaging as the attack itself.

��

There are a number of ways to overcome this challenge, but perhaps the most significant is the concept of a Software Bill of Materials (SBOM). This is an idea that comes from manufacturing; a “bill of materials” provides a record of all the parts needed to create a product, making it easier to identify defects if they arise. Brought into software, a SBOM makes it possible to track the various components and dependencies that are part of a given application.��

��

SBOMs are likely to become prevalent across business in the years to come — in 2021 in the US, NTIA at the behest of an , demonstrating that this is something moving up the agenda of policymakers. While there aren’t currently any legal obligations, it is undoubtedly something business and technology leaders should consider if they want to mitigate the risks of supply chain attacks and ensure improved application security.

��

An SBOM can be developed using Software Component Analysis, a technique that scans many different codebases to identify vulnerabilities. This is, it should be noted, a technique that needs to be part of continuous practice — in other words, technology teams need to be proactive in assessing the state and shape of their application estate.

Lesson #2: Build in alerting and immediate reporting

��

As noted above, in complex systems it can be difficult to identify the precise areas of risk and vulnerability. That means putting detection and reporting tools in place is a vital step in strengthening your security posture.

��

At one level this is a question of technology selection; there are a wealth of tools that can identify vulnerabilities by detecting unusual changes in a given codebase and provide alerts when needed. However, it's important to note that this is about more than technology — your incident response strategy needs to be well-planned and tested regularly. A comprehensive plan will tackle issues such as who needs to be involved and who needs to be informed — sometimes this will span beyond technology and product teams to legal or PR.��

��

It will also provide a guide as to what should and should not happen. For example, it might specify which parts of a service can be turned off (if any) and any potential workarounds in the event of a security breach. Even the very best vulnerability scanning tools won’t be able to guide you on the right course of action for your specific context: that needs leadership.����

Lesson #3: Pay constant attention to your threat models��

��

Threats to your infrastructure and applications shouldn’t be viewed as a risk — they should instead be seen as an inevitability. What’s more, they also need to be understood as threats that are constantly evolving. There is no point at which threats will stabilize: the technology world is locked in a game of cat and mouse with malicious actors who are constantly trying to out-innovate each other.��

��

This means, then, that you need to pay close attention to the threat landscape. There are a number of ways of doing this but it's important that you view it through the lens of your own application estate. In one sense, it’s an additional layer that sits upon the practices outlined in lesson #1.

��

On the one hand you need to be attuned to the types of attacks that are taking place across the global economy. A threat model can help here; it allows you to identify and document potential vulnerabilities and risks across your organization — technical and otherwise — so you can then set out countermeasures. On its own, however, it won’t be enough: a threat model is useful only if it receives constant attention. It needs stewardship from security professionals who can constantly update and evolve the model.

��

On the other hand, meanwhile, it’s important to recognise that every technology decision that is made inside the organization has security implications — that includes everything from your choice of third party libraries to your decisions around what data to collect and store.��

��

Sensitivity to external realities and self-awareness (and a dose of humility, perhaps) can go a long way in improving your security posture.

Lesson #4: Embed security inside continuous delivery practices

��

The lessons outlined so far are all security-centric. That is to say, they all treat security as a specific and discrete domain. That has risks and can sometimes perpetuate a particular anti-pattern that we call a “security sandwich” — when security is only considered at the start and end of the development lifecycle.��

��

The alternative to this is to embed security considerations and practices inside the software development process. Continuous delivery can certainly play a role in ensuring security, as smaller and more frequent releases are easier to manage, maintain and rollback if required, but if you are delivering in such a manner it’s still important to build security into that process.

��

This may require a shift in mindset about organizational structure. Teams that do security effectively today will rarely have separate security teams but will instead ensure that the relevant expertise is properly incorporated inside development workstreams.

Lesson #5: Build a culture of security that extends to the edges of your organization

��

Moving security upstream — “shifting left” — and embedding it inside development processes and teams is just the first step towards building a truly security-centric organization. It needs to be something that runs across every facet of the company, even in how non-technical staff think about security. It has been claimed that social engineering techniques — where attackers exploit human error — are used in , demonstrating that building broad security awareness can be a useful way of strengthening the security of your systems and data.

��

If you can foster a culture where good security hygiene is practiced, the next step is to decentralize security, moving away from the notion that there is a perimeter that sets internal networks and systems from the outside world.��

Bringing culture and security together

��

Application security isn’t just a technology issue. It’s also a cultural one that requires human attentiveness and judgement. This can be challenging and it may require organizational changes and, indeed, growing pains.

��

However, leaders occupy an important position to empower those best placed to drive that change and to foster a culture that recognises security, today, is business-critical.