At the recent CloudNativeSecurityCon in Seattle, 800 DevSecOps practitioners gathered to address a myriad of software supply chain security issues, including the security of container images and the impact of zero trust on the software supply chain.
As of last year, there were 7.1 million cloud-native developers, 51% more than the 4.7 million 12 months earlier, Cloud Native Computing Foundation executive director Priyanka Sharma said in the opening keynote. “Everyone is becoming a cloud-native developer,” Sharma said.
However, this rapid shift to cloud-native development can be a source of concern, since the rapid release cycles may lead to organizations not following secure lifecycle development (SDLC) practices, Sharma warned. Snyk’s 2022 State of Cloud Security report found that 77% of organizations acknowledged that they have poor training and lack effective collaboration among developers and security teams.
“There are siloed teams often working in separate countries, time zones, using different tools, policy frameworks,” Sharma said. “In the cloud-native environment, we are interacting with so many other entities. Throw in a lack of security policy, and there’s the recipe for your security breach.”
The lack of security policies is fueling an increase in vulnerabilities due to misconfigurations. An alarming 87% of container images running in production have critical or high-severity vulnerabilities, up from 75% a year ago, according to the Sysdig 2023 Cloud-Native Security and Usage Report. Yet only 15% of those unpatched critical and high vulnerabilities are in packages that are in use at runtime where a patch is available.
Sysdig’s findings are based on telemetry gathered from thousands of its customers’ cloud accounts, amounting to billions of containers. The high percentage of critical or high-severity vulnerabilities in containers is the outgrowth of the rush by organizations to deploy modern cloud applications. The push has created an influx of software developers moving to the more agile continuous integration continuous development (CI/CD) programming model.
Sysdig’s report recommended filtering to isolate only the critical and highly vulnerable packages in use in order to focus on packages that present the most risk. Further, only 2% of the vulnerabilities are exploitable. “By looking at what has in use exposure, that is what is actually in use at runtime, and having the fix available will help teams prioritize,” Sysdig threat researcher Crystal Morin wrote in the report.
5 Elements of Zero Trust Implementation
Sharma pointed to last year’s Cost of a Data Breach report from IBM and Ponemon Institute, which showed that 79% of organizations have not moved to a zero-trust environment. “That is really not good,” Sharma said. “Because almost 20% of breaches are occurring because of a compromise at a business partner. And keep in mind that almost half the breaches that occur are cloud-based.”
A key barrier to instituting zero trust is environments where permissions are not under control. According to the Sysdig report, 90% of permissions granted are not used, creating an easy path for stealing credentials. According to the report, “teams need to enforce least privilege access, and that requires an understanding of which permissions are actually in use.”
Zack Butcher, founding engineer at Tetrate and an early engineer on Google’s service mesh project Istio, said creating a zero-trust environment isn’t that complicated. “Zero trust itself isn’t a mystery,” Butcher told attendees. “There’s a lot of FUD [fear, uncertainty, and doubt] around what zero trust is. It’s fundamentally two things: people process and runtime controls that answer and mitigate the question, ‘what if the attacker is already inside that network?'”
Butcher identified five policy checks that would make up a zero-trust system:
- Encryption in transit to ensure messages can’t be eavesdropped
- Service level identity to enable authentication at runtime, ideally a cryptographic identity
- The ability to use those identities to be able to perform runtime service-service authorization to control which workloads can talk to each other
- Authenticating the end user in session
- A model that authorizes the actions users are taking on resources in the system
Butcher noted that while these are not new, there is now an effort to create an identity-based segmentation standard with the National Institute of Standards and Technology (NIST). “If you look at things like API gateways and ingress gateways, we do these checks usually,” he said. “But we need to be doing them, not just at the front door, but every single hop in our infrastructure. Every single time anything is communicating, we need to be applying, at minimum, these five checks.”
NIST Standard Coming Up
During a breakout session, Butcher and NIST computer scientist Ramaswamy “Mouli” Chandramouli explained the five controls and how they fit into a zero-trust architecture. Tools such as a service mesh can help implement many of those controls, Butcher said.
The presentation is an outline for a proposal that will be presented as NIST SP 800-207A: A Zero Trust Architecture (ZTA) Model for Access Control in Cloud Native Applications in Multi-Location Environments. “We expect to have this out for initial public review sometime in June,” Butcher said.
Butcher said supply chain security is a critical component of a zero-trust architecture. “If we can’t inventory and attest what’s running in our infrastructure, we leave a gap for attackers to exploit,” he said. “Zero trust as a philosophy is all about mitigating what an attacker can do if they are in the network. The goal is bounding their attack in space and time, and controlling the applications that execute in that infrastructure is a key element of bounding the space an attacker has to work with.”
