The recent SolarWinds incident has shed a light on an area of cybersecurity that is not frequently in focus. Better said, it is “again has shed a light”, if we remember the Heartbleed incident that happened back in 2014. Back then, my colleague Alexei Balaganski wrote in a blog post that “software developers (both commercial and OSS) […] should not rely blindly on third-party libraries, but treat them as a part of critical infrastructure”.
What we need is a defined approach and consequent enforcement of what, in a slightly awkward manner, is called C-SCRM or Cyber Supply Chain Risk Management. This concept includes enforcing software security from the very beginning of its development cycle. It is not only about cloud services and COTS (commercial of the shelf) software but applies to any type of software that is procured or self-developed, including software in things and devices as well.
Consequently, we must extend the Zero Trust paradigm beyond networks, security systems, and identities and apply it to all types of software. Don’t trust software, period.
What does Zero Trust stand for?
Zero Trust has been defined over 10 years ago as a concept that focused on removing implicit trust from network architectures and enforcing strict identity verification and access controls for every user or device. “Trust but verify” might be a popular saying, but the motto of Zero Trust has always been “Don’t trust. Verify”. This is the quintessence of the Zero Trust approach that has evolved since then to other areas of security, beyond the network, including identity and device security.
Zero Trust is a paradigm, not a tool. It helps in architecting cybersecurity infrastructures and in defining concepts for operations. Given that security needs to be verified and enforced in multiple places – as the concept states – it involves a range of technologies to implement such a Zero Trust paradigm in an IT infrastructure.
What happened in the SolarWinds incident?
The SolarWinds incident was an attack that became public in December 2020 but had been running at least for several months beforehand. The installers for SolarWinds’ Orion monitoring platform had been backdoored. Unfortunately, that software is (or has been) running in many organizations, including major cloud data centers. Several other software vendors like Microsoft and FireEye have reported that they’ve been breached through the use of SolarWinds products.
What this attack demonstrated is that even large software vendors with strong cybersecurity background can be compromised due to the inherent software and cybersecurity supply chain risks. Unfortunately, most organizations trust the software they procure and use, instead of verifying its security. And, unfortunately, verification is not easy to do and has its limits. But it can be done, it must be done, and it results in increased security. However, some products you can purchase might go as far as explicitly demand that customers disable their antimalware tools before installing them. This is the complete opposite of the idea of Zero Trust.
What is Cyber Supply Chain Risk Management?
Before looking at the specifics of software security (secure software, securing software), this leads to the broader theme of C-SCRM. This discipline applies the broader Supply Chain Risk Management to software and IT services and addresses the inherent cybersecurity risks. This is not only about using SaaS services or COTS software, but also about software in connected devices and things such as sensors, machines, control devices, etc.
Supply Chain Risk Management looks at the risks regarding both the reliability of supply chains and risks and damages derived from suppliers, from misconduct (e.g. child labor) to quality issues.
C-SCRM tries to assess and mitigate the risks that come from IT, particularly software, specifically regarding the availability of IT and – as the name implies – security.
What does C-SCRM include?
Going into detail would be beyond the scope of this post. However, you may want to listen to this talk of my colleague Christopher Schuetze on the necessary components of an effective C-SCRM approach.
How to apply Zero Trust on Software Procurement
In essence, we can’t trust software, in whichever form we receive and use it without validating its integrity and security first. Software security must be consequently enforced and verified, including measures such as
- Secure design and coding practices: While concepts like “secure by design” are being discussed for many years, they are still not implemented everywhere. Now is the latest time to start working on it. This also includes modern software testing principles.
- Software composition analysis: Any reused code such as open-source libraries must be constantly tracked. Where is it used? Which version is in use? Are there known vulnerabilities and patches for them? Which coding practices are in use by the suppliers of this code?
- Static and dynamic code analysis: There is a range of tools for static and dynamic code security, which can be used to identify security issues in code. These practices should be extended to areas like API design as well.
- Organizational controls: This all must become part of the ISMS (Information Security Management System), with defined and enforced controls.
- Security analytics: Last not least, security analytics can help to identify anomalies in software. While operational analytics has been a part of DevOps for years, it should be expanded to cover security telemetry and forensics as well – such integrated platforms are already available.
A good summary of this is provided by my colleagues Matthias Reinwarth and Alexei Balaganski in this episode of the KuppingerCole Podcast.
How to check for Software Security
To quote Alexei Balaganski again, from what he wrote back in 2014 as a recommendation following the Heartbleed incident:
“One of those approaches, unfortunately neglected by many software vendors, is hardening applications using static code analysis. Surely, antimalware tools, firewalls and other network security tools are an important part of any security strategy, but one has to understand that all of them are inherently reactive. The only truly proactive approach to application security is making applications themselves more reliable.
Perhaps unsurprisingly, code analysis tools […] don’t get much hype in media, but there have been amazing advances in this area since the years when I’ve personally been involved in large software development projects. “
There is a lot of solutions available to improve code security and mitigate risks in the software supply chain. It is about using these the right way, integrated into a holistic C-SCRM approach. You’ll find further information in this episode of the KuppingerCole Podcast on post-SolarWinds software security strategies.
The extended Zero Trust approach: Don’t blindly trust software
Zero Trust must be extended and cover software security, for software in any form (embedded, COTS, as-a-service) and regardless of whether it’s home-grown or externally procured. “Don’t trust. Verify” – this is as essential for software as for identity, devices, or networks.
