On The Cyber Jack Podcast, we sat down with Matt Chiodi, CSO of public cloud at Palo Alto Networks, to talk about supply chain security, new insights from a Unit 42 research report, and the power of a Red Team engagement.
[automated transcript for accessibility and your reading leisure]
Jack 00:03
Today Matt Chiodi, the CSO of public cloud at Palo Alto Networks, joins us to talk about why supply chain security is failing, cloud complexities, and what a Red Team can reveal. All this and more on The Cyber Jack Podcast.
Matt, thanks so much for joining us today to talk about the supply chain and the cloud. Let's first kick things off with you telling us a bit about your background and what you've been focused on recently.
Matt Chiodi 00:37
Sure, well, I've spent the last 20 years in various IT and security roles, and probably the last little bit more than a decade, it has been focused exclusively on cloud security. In my current role, I am the Chief Security Officer of cloud at Palo Alto Networks, and I run our unit 42 Cloud Threat Intelligence Team.
Jack 01:01
Well, it's a great time to have you on the show. Supply chain security has become one of the most talked-about topics in cyber over the past couple of years. Can you sum up why it has become such an area of concern?
Matt Chiodi 01:15
You know, hackers have always been looking for the weakest link in all those SolarWinds certainly received the most headlines; there have been many others over the years, like not Petya that just just to name probably one of the ones other people might recognize. In my view, cloud comes into play here, because that's where the majority of enterprise applications are moving. And quite frankly, organizations are not yet at the point of maturity, where they're keeping those cloud workloads secure. And many of them, they're heavily relying on open source, which is not always the most secure.
Jack 01:51
Yeah. And it seems like a lot of organizations maybe weren't ready to handle the high speed of adoption that we're seeing in the complexities that the cloud can bring. And just to shift gears a bit. I know unit 42 recently released a threat report examining supply chain security in the cloud. Specifically, could you talk to us a little bit about the genesis of that report and some of the key findings?
Matt Chiodi 02:16
Yeah, so we do our our cloud threat reports about every six months, and we typically focus on a different area of cloud security. When we do those, for example, our last report, we looked at how COVID-19 impacted security in the cloud, right? Everybody talked about you know, the physical impacts on the human body. But we wanted to dive into how does it how did it impact cloud security. So that was our previous report, you'd have to go back about six months to find that one still out there. In this most recent report, we dove specifically into supply chain security in cloud-native applications in when we do our threat research at Palo Alto Networks, it is always based upon hands-on either red team exercises, or it's based upon research that we've done based upon both proprietary data or potentially even public datasets. So you know, we focused very deeply on supply chain security, as it pertains to cloud-native applications. Probably one of the most interesting things that we found is that third-party code, specifically open source poses a hidden risk. You know, we found that nearly 63% of third-party code used in building cloud infrastructure has insecure configurations. 63%. You know, containers are very popular in the cloud. In fact, it's almost a requirement if you are building cloud native applications to use containers. And while studying 1000s of container images in our research, we found that a shocking 96% contain known vulnerabilities. So Jack, this isn't you know that these aren't like zero days, these are all known vulnerabilities that have a CVE granted to them so 96% into the bottom line for me is that DevOps and security teams must gain visibility into the bill of materials of every cloud workload. They can't depend upon the same sets of tools and processes that they used in their data centers.
Jack 04:24
Wow. Those are some staggering statistics. And you mentioned that these reports are compiled using a lot of primary research and insights based on hands-on customer interactions. I understand that part of this report was compiled as a result of a red team exercise. Can you walk us through that and some of the big takeaways?
Matt Chiodi 04:45
Yeah, absolutely. So you know, supply chain flaws, in general, are difficult to detect. You mentioned the red team exercise that we carried out our Unit 42 researchers were basically approached by a law SAS provider who wanted us to simulate what we'll call an inside up style of attack that is similar has some similarities to what happened with SolarWinds and Cassia. In this, obviously, there was limitations to you know what we could do in the red team exercise. But we were able to leverage misconfigurations in the customer software development environment, which allowed the researchers to control the customer's software development processes; with the level of access that our researchers were able to get, they could control the flow of software. And this allowed them to perform a supply chain style of attack. And they were able to do this, because they exploited process gaps in critical security flaws, like hard coded credentials. So you know, this organization, I think most would consider them to have mature cloud security. This was a large SAS provider, but our team was able to own their continuous integration infrastructure in only three days. So this just goes to show that even mature security programs can have operational security gaps that leave them open to potential cloud-native supply chain attacks.
Jack 06:22
And when you talk about gaps, adversaries have really been utilizing the path of least resistance in the form of cloud misconfigurations. They've been a real consistent problem. Why are cloud misconfigurations such a thorn in the side for organizations?
Matt Chiodi 06:39
You know, organizations, by and large, really lack the same visibility into cloud platforms that they had on premises, and you can't secure what you cannot say, right. And we've been repeating this mantra for probably the last three years, it's getting a little bit better. So visibility is really that that primary issue into misconfigurations. The second part of it, I think, has to do with the shared responsibility model, but probably not from the angle Jack, that you're you might be thinking, I've seen organizations struggle with not understanding, well, this is what I do. And this is what the cloud service provider does. Rather, they're struggling with it inside their own organization. What does the security team do? What does the development team do? What does the operations team do? What does the Cloud team do their own clear on those? And that is what leads to all these misconfigurations? Right. So in previous research, we analyzed about 18 months worth of cloud breaches. And we found that 65% were the result of customer misconfigurations 65%. So it's really it's the visibility, I think it's poor documentation or poor understanding within the environments of a rather of in the customers' environments of, you know, who does what, right on the internal side. And then the other piece of it is just complexity, right? So the cloud service providers are innovating at such a rapid pace, that complexity through innovation is actually a big challenge, especially if an organization is unclear on roles and responsibilities.
Jack 08:21
And it seems like a lot of security issues are deeply rooted in visibility, communication responsibility. So final question, what advice do you have for CISOs looking to shore up their supply chain security in the age of the cloud?
Matt Chiodi 08:37
What we recommend, first of all is to obviously go out to the the website cloud threat dot report, and you can download a full copy of our latest threat research. Again, just go to cloud threat dot report, and you can download a full copy of the research toward the end of the of the paper, we really get into a couple different recommendations. First and foremost, we really like what the Cloud Native Computing Foundation has put together the CNCF, they created a white paper on supply chain security, probably sometime in the last six to nine months.
So number one, we recommend reading that we recommend disseminating that widely, both across the development teams, security teams, cloud teams. So that's kind of step number one; let that be kind of the kind of the base layer of understanding. The second step. And this is kind of directed the security teams is defining a left shift strategy. And key things that should be in this document our vision, roles and responsibilities, goals and milestones. And this is really about just laying out what the shift left look like for our organization. That's something that has to be done with stakeholders from all the involved teams. Step number two is understanding where in-house software is created. In your organization in this is going to be different for every organization for very small, maybe medium-sized companies, they need to go out and understand where the software being coded right all the way back to a developer's laptop, in their IDE, all the way through to when they push that software to some type of like a Jenkins or a circle CI, and then how does it then make it from there out to the cloud? It's really about doing that sleuthing of understanding where are all the touch points, because each one of these is an opportunity to do software quality, right. And that's really step three is about identifying and implementing security quality, guardrails. Quality Assurance has long been a part of software development. But it traditionally has not included security. This is where they have an opportunity to use automated security testing tools like bridge cruise checkov.
It's an open-source tool, you can just Google that you can find it. It's really about arming developers and enabling them to secure their code the first time, so you don't end up doing it in production environments. So I think if organizations utilize the steps that I briefly outlined, it will really put them on a solid path to not only shifting security left, but making security synonymous with development. There it is.
Jack 11:28
Matt, thank you so much for coming on the show. We'll continue to keep a lookout for more research from Unit 42. To all of our listeners, we'll see you next time.
###