CyberWire Daily - Trends and tips for cloud security. [Research Saturday]

Episode Date: February 9, 2019

The team at Palo Alto Networks' Unit 42 recently published research tracking trends in how organizations are addressing cloud security, along with tips for improvement.  Ryan Olson is VP of threat intelligence at Palo Alto Networks, and he joins us to share their findings. The original research can be found here: https://unit42.paloaltonetworks.com/unit-42-cloud-security-trends-tips/ Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of

protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security.

Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI.

Learn more at zscaler.com slash security. Yeah, so this one's a little bit different from the kind of stuff that we normally publish. That's Ryan Olson. He's Vice President of Threat Intelligence for Palo Alto Networks. The research we're discussing today is titled Cloud Security Trends and Tips, Key Learning to Secure Your AWS, Azure, and Google Cloud Environments. Something that we think is important as more organizations move into the cloud, they start moving more of their infrastructure there, especially into public clouds, is just sort of understanding that there's this shared responsibility model

between the cloud provider, the infrastructure provider, and the organization that's actually deploying their software out there. They do not take over all of the security for everything that's happening just because it's on their systems. You still have to patch your systems. You have to update their software. You still have to manage credentials and do all of these other things that you would do if it was in your data center as well. It's just you don't need to worry about the physical devices themselves. So we published this report to help people understand that these threats, they do exist.

A lot of people are making mistakes out in the cloud, how they configure their systems. I want to shine a bit of a light on that so there's a better understanding that there's real threats out there. And do you think there's a misperception out there that folks feel as though, I guess, is there a false sense of security when folks move their stuff to the cloud? I think there is a false sense of security that people feel because just the fact that people can't necessarily just sort of quit your systems the same way. You don't feel as exposed because it's in the cloud and you sort of have this trust in your provider, whoever they might be, that they're doing all these good things for you to keep your

system safe. But no matter what they do, it still comes down to you're running software, that software has possible vulnerabilities, your data is there, and anyone can access it under the right conditions, which is why we've seen lots of breaches that have occurred in public cloud environments because people have simply left their, you know, their buckets exposed. So anyone can go and download a whole bunch of files because the person who deployed it didn't necessarily understand what the new security model really was. Right, right. Well, so before we dig into some of the specifics here, I mean, you all basically highlighted

five broad categories of things to be concerned with, the things that require your attention when moving to the cloud. You want to just start off by taking us through that list? Sure. So the first one is account compromises. And based on the data that we're collecting through our RedLog platform, we're able to identify that probably around 29% of organizations have some accounts that are actually compromised that they haven't changed passwords for, which is a lot.

It's problematic. Because if you think about how the public cloud works, in many cases, the only thing stopping someone from accessing a host is a login and password, accessing some sort of data. So having excellent credentials, credentials that are regularly changed, that haven't been breached, and ideally using multi-factor authentication for particular logins becomes even more important in the public cloud. Because if you compare it to your own data center, to access the sensitive application inside your network, you generally need to be either inside the network

or connected to a VPN of some kind to allow you to get to that host in the first place. But with a lot of public cloud deployments, those hosts are just completely exposed to the internet. So anyone can get to it. So the only thing stopping an attacker from getting to the data is just having the right password,

the right sort of key to the door. One of the things that I noticed in your research is this whole notion of there being dormant accounts. Folks have been given access who might not need it anymore. Yep. And that's actually pretty common. Someone will create an account for an individual somewhere in some public cloud infrastructure. They set it up because they need to make some changes and they never sort of go and clean that account up. Maybe the person has left the company, maybe they just never had another reason to go and log into it,

and the account just sits there dormant. And that's an exposure because that's a user with a password who could be compromised. If someone compromises your laptop and they get access to install a key logger and they get those credentials, if there isn't some sort of multi-factor authentication, all those accounts that are sitting out there unused, they're really just extra exposure that's unnecessary. And you make the point that you need to operate under the assumption that credentials will be compromised. Take us through what do you mean there?

What do you mean there? Yeah, so this is a little different than how most people, a lot of people have these policies inside their companies where they have to rotate their credentials every 60 or 90 days. And I think sometimes those policies can be detrimental because people then create these password schemes that are easy to crack by someone who actually has seen one of the passwords. But in public cloud infrastructure, I think it's more important to take those steps because credentials do get compromised, especially when people have bad sort

of password systems. And because it's exposed out to the internet, you wouldn't even necessarily know unless you're monitoring that those credentials were used at some point. So it isn't a guarantee that every single login and password combination is going to be breached at some point. But making these changes, and especially because you can do this pretty easily in public cloud infrastructure, rotate credentials, it just becomes an even more important component of keeping that data more secure. So when it comes to preventing account compromises, you all have some tips here. You want to walk us through those? Yeah, so I think the most important one that I just mentioned was enforcing multi-factor authentication, especially on privileged accounts. Most public cloud infrastructure

have this concept of a root account that has access to all of the different services. They can deploy additional virtual machines. They can do all these things and they're not really restricted by the same kind of policies that other users are. That one in particular is most important to have multi-factor authentication on either through a token or through some sort of SMS. And then the other aspect of this is credentials aren't just passwords. Credentials, especially in public cloud, often are access keys, sort of these long tokens that are generated because one service is talking to another service. It's not necessarily a user. It's just you need to provide this API key

to be able to access the data. Those can be exposed through ways that people just aren't used to. Oftentimes, they get bundled into code, code inside a script that's going to access a system, and that code can get exposed itself. People make mistakes by accidentally uploading it to GitHub or to somewhere else and maybe making a repository public that wasn't supposed to be public. Those are the same issue of credentials that have been exposed and someone can take control over. You just have to think more about when it comes to the public cloud. So I think those are the two main ones of the ones that we recommended that I really want to note for the listeners. Yeah. Well, let's move on to the next topic. And this was cryptojacking. Cryptojacking has been a huge topic for the last, I'd say, almost 18 months now.

Because we were seeing on the desktop, on people's computers, we were seeing lots of attackers move to compromising hosts so they can go and mine specific cryptocurrencies. Monero was the one that we were seeing most. But we also saw these attacks happening in the public cloud. Basically, if the attacker can get access to those credentials, whatever they are, API keys or otherwise, if they can spin up a virtual machine in your cloud, they can spend a lot of your money going and mining cryptocurrency. And what we've seen toward the end of the year is as the currency prices have been dropping significantly, we think the price of Bitcoin is around $3,500 US right now. And last year at this time, it was closer to $18,000. We've seen this trend cooling off a little bit. This is one that I don't expect to just disappear. I don't think we're going to see all attackers who are using the crypto mining business model stop performing it. But I do think we're going to see people shift back more toward launching ransomware attacks and other kinds of attacks that they have that can make more money off of as the price is

drawn. And so what are your recommendations for best practices here? Really understanding what's getting deployed inside of all of your virtual machines is really important. And one thing that you can do is in these crypto mining attacks, something that's required is that the virtual machine that is deployed has to be able to go and talk to a mining pool. And the best thing you can do is in these crypto mining attacks, something that's required is that the virtual machine that is deployed has to be able to go and talk to a mining pool. And the best thing you can do is make sure you're actually monitoring the traffic out of all the virtual machines inside of your public cloud. So you can see, are we seeing traffic to mining pools? And ideally just implement a denial policy to say, unless you have specifically allowed traffic from these VMs, don't allow anything out.

It's just unnecessary traffic going out, and it'll prevent you from being impacted because nobody's going to deploy these in your network, even if you are compromised, if they're not going to make any money off of it. So the next category you looked at was compliance. Take us through what you found here. Yeah, so compliance isn't something that in Unit 42 we normally have to talk a lot about. But in the public cloud, it becomes more important because you're effectively saying, hey, you have a whole bunch of new infrastructure that you've gone out and deployed, and there are a lot of regulations around how you actually defend this data. So one of the things

that people like us do with products like Redlock is we look at how are you doing from a configuration perspective compared to various standards, you know, HIPAA standards, GDPR, PCI, all of these things where there are regulations around you have to encrypt certain kinds of data and you have to maintain certain kinds of information to actually keep it secure. And what we found were a lot of organizations as they deploy are just not meeting those requirements. You know, there are certain best practices and requirements that are laid out that just they're not configured properly to hit organizations as they deploy are just not meeting those requirements. There are certain best practices and requirements that are laid out that just they're not configured properly to hit all of them. So one example was we found about 32% of organizations weren't fully hitting their

requirements for GDPR, the general data privacy requirement that was passed in the EU recently. And that's a big percentage. That's a lot of organizations who what they really need to do is start making some changes in how they're managing that infrastructure, but also have the data, understand, are you actually hitting these compliance requirements or not, so that you have the ability to say, we need to go and make some changes. And why specifically is this more of an issue in a cloud environment than if you were hosting the stuff yourself? I think it's a similar issue between the cloud as well as keeping this inside of your data center. But I think something that happens in public cloud environments, which doesn't happen as much in data centers, is people inside an organization deploying virtual machines or

deploying other kinds of infrastructure without having to go through their IT org. The IT org who generally has things in place to make sure they're complying with all those regulations. If you have a separate part of the business who can suddenly spin up virtual machines and deploy code and set up databases without ever talking to their IT team, they end up in a situation where they might be falling out of compliance with these regulations. So making sure that the IT and the security teams

have the ability to perform these kind of audits and get this data becomes even more important in those public cloud situations. Well, let's move on to the next one. And this was vulnerability management. Take us through this one. So when you deploy virtual systems out into the public cloud, unless you're using, you know, one of the services where it's fully provided to you by the cloud vendor. So if they're hosting the entire SQL database or something like that, you're still responsible for making sure the systems are getting patched. So you still have to update all of your software, make sure you're running the proper kernels on your operating

system, making sure you're updating the PHP libraries, whatever they might be for what you're actually running. And what we found was about 23% of organizations have a host that's missing some sort of critical patch in the cloud, which isn't really that terrible. If you look at a data center, oftentimes you do find a lot of hosts that don't have everything patched. That's why patching has been such a big challenge. But what's true in a data center is you can deploy a vulnerability scanner, scan across all your hosts and sort of know what the situation is. That's not quite as easy to do in the public cloud. You've got to have different ways to actually go and gather that inventory of all the hosts that are actually running inside your public cloud and what software is on them. And that's a little bit different. It just requires some different kinds of visibility.

And so what do you recommend? How can folks get on top of this? I really think the most important thing here is, again, having that visibility. So being able to sort of correlate all of the vulnerability data that you have inside your network in the public cloud, and then look at the controls that you have in place. If you have hosts that aren't patched, understand what kind of controls exist for you in the public cloud, either as a virtual firewall or something else that can prevent those vulnerabilities from being exploited from the outside. I don't think we're ever going to be in a situation where we can tell everyone, just make sure you've got everything 100% patched. It's a great world of the future, a great thing to think about. But if we're never going to get there, it's about mitigating what the risk is. And the way that you approach that mitigation is different in public cloud because you don't have the same kind of infrastructure necessarily.

Now, the last category that you explored was managed container services. What were we talking about here? Yeah, so containers are really growing in popularity, especially inside the public cloud. popularity, especially inside the public cloud. I believe our number was about 25% of organizations were using some sort of container service in their public cloud, either Amazon's Elastic Container Service or Kubernetes, a different version of Kubernetes from Google or for Azure. And that means that's a quarter of them who have deployed this container management system. So in a normal situation, if you were doing this in your data center, those Kubernetes instances, the hosts that are actually allowing you to sort of orchestrate the creation of new containers, it would be walled off inside your data center. No one's

going to be able to go and touch it. But in the public cloud, it's possible that you leave that fully exposed to the internet. So we found 46% of organizations, their Kubernetes pods, where they could accept these instructions, they were allowed to accept traffic from anywhere, which is just unnecessary. It's unnecessary for those to be left exposed. And it's an important thing to actually control because being able to deploy basically a virtual machine, a Docker image that contains a bunch of software inside somebody's network gives you a lot of access, both for an abuse perspective for taking up their resources, but also to potentially launch some sort of more

malicious attack where they go and try to access more data. So what do you suggest here? In this case, there's some good best practices around just sort of blocking off access to these systems, using the user management system within your public cloud provider to prevent people who don't need access to your Kubernetes managed instance from accessing it. And then also, where possible, try to find good solutions for monitoring your container deployments. You want to be able to understand what containers are you launching, what is the source of the images for those, so that you have more confidence that there isn't something malicious going on in one of these sort of things that are foreign to a lot of people in the world of IT. So, I mean, looking at these as a whole, sort of a high-level look, what are the overall take-homes from the examination that you did here?

I think the best takeaway is that a lot of people who are moving their infrastructure to the public cloud, and nearly everybody is doing this in one way or another, they're at least sort of dipping their toe in the water, don't necessarily know how to keep that secure. And they don't have the right tools to make sure they're keeping it secure. And from a security perspective, in particular, my team generally, what we're talking about is adversaries who've compromised networks, and they're installing malware, and they're trying to steal people's data. What you see in the public cloud is a different kind of attack. You might have seen somebody attack an organization and steal their credentials, but then they use those credentials just to log into a database and extract a whole bunch of data or download a whole bunch of files.

The actual evidence that occurs out in the public cloud is really different. And you introduce these new capabilities like containers and all these different services that the cloud providers have deployed. Just to give you one quick sort of anecdote, I was talking with someone about why public cloud is different from a threat research perspective. And I've got a lot of really smart people on my team, but I told them, I opened up the Amazon page where Amazon shows all their services. And there's so many of them. They've all got interesting names. And I said, if you asked anyone on my team, what role does Amazon, and I just sort of scrolled down the list and said, Amazon LightSail, what role does it play in an attacker's playbook and how they're

going to launch their attack? They would probably say, what is Amazon LightSail? Because it's just, and there's new services all the time. We're just, this is the world of public cloud moves really, really quickly. There's a lot of new services that are popping up and it really does require someone to sit down and educate themselves on what are these things and what do they mean to my organization from a defensive perspective? Do they open a new hole or do they, quite frankly, make it easier for me to manage my infrastructure? A lot of this automation, a lot of the things that we've learned through the development of DevOps can help a lot with security because you can suddenly destroy a virtual machine and restart a new one. And you don't really have to worry so much about, was there malware involved on that machine?

Because you can kill it anytime you want to. And maybe you do. Maybe you kill those machines every day. But now you have to think, is the thing that's generating that virtual machine itself compromised? And how does that work? And how do we control access to it? So it's just new concepts that people need to wrap their heads around in security. Our thanks to Ryan Olson from Palo Alto Networks Unit 42 for joining us.

The research is titled Cloud Security Trends and Tips, Key Learning to Secure Your AWS, Azure, and Google Cloud Environments. We'll have a link in the show notes. Cyber threats are evolving every second, and staying ahead is more than just a challenge. It's a necessity. That's why we're thrilled to partner with ThreatLocker, a cybersecurity solution trusted by businesses worldwide. ThreatLocker is a full suite of solutions designed to give you total control,

stopping unauthorized applications, securing sensitive data, and ensuring your organization runs smoothly and securely. Visit ThreatLocker.com today to see how a default-deny approach can keep your company teams and technologies. Our amazing CyberWire team is Elliot Peltzman, Puru Prakash, Stefan Vaziri, Kelsey Bond, Tim Nodar, Joe Kerrigan, Carol Terrio, Ben Yellen, Nick Valecki, Gina Johnson, Bennett Moe, Chris Russell, John Petrick, Jennifer Iben, Rick Howard, Peter Kilpie, and I'm Dave Bittner.

Thanks for listening.