Securing Your Cloud Supply Chain

By Matt Chiodi, Chief Security Officer, Public Cloud, Palo Alto Networks

Supply chain security has become top-of-mind for many leaders, as incident after incident has revealed supply chain vulnerabilities that expose significant organizational risk. Security challenges like Log4j and SolarStorm have battered organizations of all sizes with risks they likely didn’t even know they had. With a supply chain attack, a vulnerability in one component of a software stack can expose an entire organization to potential exploitation.

Research from Palo Alto Networks Unit 42 has identified a particularly impactful type of risk in the cloud supply chain that should be a major cause of concern. Our research team found that 63% of third-party code used to build cloud infrastructure is insecure. The security risks include misconfigurations that expose organizations to risk, improperly assigned permissions and vulnerable code libraries.

What is the cloud supply chain anyway?

Most of the time, when individuals talk about the supply chain, they’re thinking of things like physical widgets and goods that move from one place to another. What many organizations haven’t wrapped their heads around yet is the fact that the movement of those physical goods is often enabled by applications that are running in the cloud. Going a step further, if your organization is building its own cloud native applications, then you’ve got a supply chain within a supply chain.

Modern cloud native applications are built and composed in three high-level steps. At the first level is the provisioning of the cloud infrastructure. The second step is to have a Kubernetes® container orchestration service, the platform on which the applications are deployed. The third step is the deployment of application container images themselves. Any one of those three layers can have misconfigurations or vulnerable code elements.

Dropping the SBOM (Software Bill of Materials)

While cloud supply chain security can be complex, it also offers opportunities to make it more straightforward. With cloud native applications, containers are almost always used, which provide an easier way for organizations to actually track what’s in an application.

The concept of a Software Bill of Materials (SBOM) is simplified with containers as they are declarative. A user can look inside the container manifest and line-by-line, and understand what is inside of the container.

SBOMs are set to increasingly be part of the software supply chain, thanks in part to Executive Order 14028, which mandates the use of SBOMs for US government suppliers.

Recommendations for securing the Cloud Supply Chain

The cloud supply chain can be complex, considering all the different layers, components, and sources. While complex, cloud supply chain security can be managed with a four-step strategic approach:

Step 1: Define the strategy

A critical first step is to outline an overall strategy to the cloud supply chain that starts with having a shift-left approach. The concept of shifting left is all about moving security earlier in the process, sometimes also called DevSecOps. The strategy need not be outlined in a massive document either. All that’s really needed initially is an outline of the vision, roles, and responsibilities. Iterate over time from here.

Step 2: Understand where and how software is created

This is where you may have to do a little bit of digging to understand where and how software is created in the organization. This is really about going out and documenting how software makes it from a developer’s laptop all the way until it gets to the production cloud environment.

Step 3: Identify and implement security quality guardrails

In traditional manufacturing processes, quality controls have long been part of operations. That hasn’t always been the case when it comes to cloud applications, however. What’s needed is to identify where the organization can put proactive checks in place along the line as software is being created. Good security controls need to include as much automation as possible to help supplement manual code review efforts, which will not scale by themselves.

Step 4: Consider certifications

While the first three steps are about building security into applications that an organization is developing, there is also a need to validate the security of applications and cloud infrastructure it is consuming. That’s an area where certifications can play a role. The big cloud providers typically have a litany of third-party attestations and certifications. Among the most common are SOC2 Type II and ISO 27001, which identify how a provider implements its own security controls and independently verifies them.

It’s important to have those certifications to be able to understand how providers systemically go through and evaluate risk. This is important because as you begin scaling the use of cloud, the provider is now a direct extension of your company.

Using all the steps outlined here can help a security leader put their organization on a solid path towards not only shifting security left but making security synonymous with development. Given the increasing reliance of organizations on the cloud and cloud native applications, the time is now to implement a cloud supply chain security strategy

To learn more, visit us here.

About Matt Chiodi:

Matt has nearly two decades of security leadership experience and is currently the Chief Security Officer of Public Cloud at Palo Alto Networks. He works with organizations to develop and implement security strategy for public cloud adoption and maturity. He does this through advisory meetings with clients, frequent blogging and speaking at industry events such as RSA. He currently leads the Unit 42 Cloud Threat team which is an elite group of security researchers exclusively focused on public cloud concerns. Chiodi has served on the board of various non-profits including Board VP and Governor of Philadelphia’s InfraGard. He is currently on faculty at IANS Research.