Reducing Supply Chain Attack Surface through SaaS

We’ve all been watching closely as the Solarwinds hack, known as SUNBURST, gets its due analysis. This attack was sophisticated and rightfully should concern any company. Companies are now — or should be — considering not only what products they are using but to what attack vectors those products are exposed that unduly extend attack surfaces.

Solarwinds makes great products —  I’ve used them for years. Naturally, using them now would be concerning until they can rebuild trust and process. I would hesitate to use most on-premises software because of the security exposure. There are just too many moving parts which could lead to compromise. 

These on-premises software packages use so many technologies across programming languages, libraries, messaging platforms, databases, and more. Keeping this all secured is a hard job for vendors. Installing software behind your security perimeter itself introduces a new security risk. That might manifest itself as a backdoor exposure of critical assets and endpoints, making them vulnerable. 

Keeping that kind of software to a minimum is ideal when minimizing potential risks to your key systems. Conversely, by using SaaS services as much as possible, you should be reducing potential routes for compromise since little to no software is installed behind your own security perimeter. 

Zero Trust and Industry Standards

Netflix pioneered this idea with “zero trust” networking, wherein by default no employee’s access was “trusted.” Many software companies founded in the cloud-native era have taken this idea to the extreme by going “pure SaaS” — they don’t have a corporate network at all.

Observability products and SIEMs often require either a full installation of on-premises software and hardware, but where SaaS is concerned, they merely need a proxy or a limited number of agents across the infrastructure, whether on-prem or off. The data may flow in a single direction or bi-directionally. Trying to use unidirectional services is ideal (in that they only communicate outbound from your high-security environment to the internet in order to send data to a SaaS solution). This avoids the risk of bidirectional solutions and generally reduces risk as much as possible if there are issues with a software provider. 

This is how Logz.io is delivered for Log Management, Infrastructure Monitoring, Distributed Tracing, and Cloud SIEM. In fact, it is the norm when looking at cloud-native tooling designed for the modern enterprise. 

Reducing Attack Surface with Open Source after Solarwinds

Open Source also strengthens security. This is not a novel statement, but one worth noting given the recent Solarwinds debacle. The security of most open source projects is generally higher than closed source systems. How? By making code available to everyone, it is constantly under review. Build processes and testing are also automated.

This is especially the case when using software that is part of well-known software foundations like Apache or the Cloud Native Computing Foundation (CNCF). Everything is transparent, done in plain sight of the public. 

Transparency and Penetration Testing

Conversely, closed source systems are managed by the vendor. You have to trust the vendor will address and disclose security issues. It is a requirement. While most companies are honest and do the right thing, many do not disclose or even detect problems effectively. We at Logz.io are strong proponents of open source and this is not only how we run our service, but also how we strengthen the community.

One of the ways to improve security is also running bug bounties, allowing professional hackers to make a living by trying to compromise your source code. Here at Logz.io, we enjoy working with HackerOne for vulnerability testing. It ensures our code — both public and private — are as secure as possible. 

Your Right to Test

These are some of the things you and your organization can demand of vendors and partners. You are entitled to be sure they are not exposing you for additional attacks. 

If you’d like to discuss this more extensively, please message me on Twitter @jkowall, and I look forward to the dialog.