EP32 Can You Ever Know Thyself: Cloud Attack Surface Management

Security.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks so much for joining us today. Your hosts here are myself, Timothy Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and member of the cloud security team here at Google. You can find and subscribe to this podcast wherever podcasts are sold. as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday afternoon, please do hit that subscribe button. Finally, you can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, our episode today is about attack surface management.

Correct, yeah, and it's a fun little space that's been kind of forming in front of our very own eyes in the last few years. Back when I was an analyst, now that I'm reformed from that, I recall hearing from some people that they want to discover all those assets that can be attacked. And of course, a naive and instinctive view of me as an analyst was to say, hey, don't you have a vulnerability scanner? Don't you have the asset management database of some sort? Surely you know what you have. And of course, we all know the answer is no, not really. Today, in this era of cloud and SaaS and people buying IT with credit cards, No, companies do not know what they have, hence a new space.

It's a reasonable space in my mind. I mean, one of the ways we explained what we were doing back at Shape was the concept of turning a battleship on its side so that you don't have the enemy facing your broadside, you have them facing your narrow side. It makes a lot of sense that an organization would want to understand all of their exposure and then take steps to minimize it.

Correct. And specifically in the cloud, where it's much easier to find assets once you know that they exist. But it's not always easy. Like, you can't have a rogue server in the closet in Google Cloud. That doesn't exist. So that's good news. But the bad news is you can have somebody whip out a credit card and buy Google Cloud for his department.

That's right.

So in that sense, we solved the problem of a rogue server in the proverbial broom closet or wiring closet or whatever, but we now created a new problem of this whole shadow IT with a credit card. So attack surface management, to me, is primarily about the cloud. But of course, I've met people who think it's broader than that. It's about finding all the stuff that belongs to your org.

I think this is a case where cloud gets to mean a little bit more than Azure, AWS, Google. It also includes all of the software as a service providers and Salesforce and all of those.

Surely you mean Google, Azure, AWS, right? You didn't mean—

Of course, in that order, as always. And with that, perhaps let's turn it over to our guest today, Derek Abdeen, the CTO at Sensys. Derek, attack surface management, that's, I think, part of what we're talking about today. Is this a new toolset, a new category? It sounds— not that I was alive then, but it sounds a little bit like 1980s assets.

Yeah. I mean, you know, in the 1980s, you probably had like, what, you know, 9600 baud modems back then and, you know, lots of home usage. If you look at the last 20 years, what's really happened to the internet, what's happened to corporate IT, there's been, you know, a number of things that I think have shifted thinking around IT and infrastructure. And to kind of look at that a little bit more deeply, you know, one of the first things is that, you know, you saw this shift from procurement processes that took a long time and you had to go ask somebody centrally to go, you know, got a new server and then rack it. And then you heard it humming usually behind you at some point if you didn't it in a data center. And we went to this model where we started to look at virtualization, and then the cloud came up. And what these new types of infrastructure did was they unlocked organizations to be able to quickly start to adapt some of their business needs by getting new business applications built online more quickly. And so what we saw was this shift from this very static nature IT environment to this more dynamic ephemeral environment where, you know, with cloud environments first and foremost, a lot of people have been taking advantage of those And they've created a new type of asset management issue for a lot of organizations that need to kind of figure out, you know, the cybersecurity team, how do I really start to manage these devices? So that's one aspect. I think the second aspect that I think about with asset management and how it's really an inventory and how it's shifted is this whole notion of citizen IT with the release of having to go through central procurement processes and starting to look at organizations empowering their employees to build new applications. They can go swipe a corporate card now and they can get new applications online. And that's really cool, but it's also really scary for cybersecurity teams. that can create an issue where you have this shadow environment where you have these unmanaged assets now sitting around. Maybe they're on the internet, and that creates a risk for an organization. So that's one aspect. And the third that I think has really changed in the last couple of decades is this notion, you know, I don't want to be super buzzwordy, but I'm going to say digital transformation, because a lot of organizations have started to look at changing their business processes by doing that, you know, adopting new types of technology. And a lot of times it's technology they don't necessarily understand. And so by doing that, sometimes they open themselves up to new risks and new risk categories that weren't necessarily in the realm of their previous environment. So with those kind of 3 factors, we tend to see a much different environment and a much different interest with this type of inventory.

So it sounds like the time for it is now. It's like people misplaced assets in closets for 20, 30, maybe 40 years. But today, we seem to have this cusp of transformation, cusp of people deploying applications with nothing but a credit card. So it sounds like the need, to an extent, always existed, But today the need is becoming extreme to go and look for those applications, to go and look for those systems, right?

Yeah, absolutely. Especially with the cloud environment, people are just adopting at a rapid pace and being able to get a grasp on that quickly is a huge aspect of it. Not only that, you know, if you look at pen testing, a lot of companies have also just looked at, hey, if I can find that server in the closet using, you know, pen testers, but that's also a very slow process. So if you're going to use, you know, people to go out and try to find these hosts and bring them back into a centralized Excel spreadsheet or something, whatever you're using to actually accumulate all these assets into some type of pool, your CMDB, it's a very slow process. So being able to have a constantly up-to-date inventory, it's not just the aspect of finding those devices, but ensuring that that information is fresh and up to date. So you're not acting on something that's stale and old.

No, that makes sense. And I think it's time to kind of look at the actual machinery for doing it. Somebody who dealt with things like vulnerability scanners or pen tests back in my analyst days, my initial reaction is like, oh, we probably scan for it. But of course, we don't scan for it in the cloud because it may be— you don't know what IPs to scan. So how do we find those assets that may be misplaced? How can any technology do it reliably? It sounds like a really tough challenge.

I assume you guys aren't spelunking around people's cloud environments with flashlights looking for servers with labels on them.

No. Maybe in the kind of virtual sense, like in the very hand-wavy, like 100,000-foot view sense, you could potentially do that from internet scanning. But I think what it comes down to is really starting to look at new methods attributing hosts in cloud environments. Again, you You can have an application that has a cluster of hosts that are all ephemeral and they come online and offline very rapidly because they're part of an auto-scaling group. And that's a unique challenge because now you have to look at what's in your inventory more from a perspective of the application rather than the perspective of an individualized host. And so what you can do on the outside is start to look at what websites you have exposed, what are your domains that you have exposed, and even more so, one of the most interesting pivots that I like to look at is things like certificates. So if you can actually find multiple different hosts presenting the same certificate, usually you can tie those back to the same organization or even potentially the same application and potentially even the same business unit that owns that application.

Hmm. So it sounds like there's a lot more things one can do, but if it's a SaaS application, can you really help there as well? Because your point with credit cards and somebody at, I don't know, let's pick marketing, in a marketing or whipping a credit card and like buying a SaaS app, that's really tough to discover, right? How can you possibly automate that?

I mean, so what usually organizations will do, they'll probably tie some type of customization on their SaaS application. For example, you might create a subdomain for your company's, you know, sales Salesforce app.

Mm-hmm.

And so you might have your users in your company all direct to, you know, salesforce.mycompany.com, and then it'll actually redirect to the Salesforce site.

Mm-hmm.

And so you can actually start to do discovery of those types of applications that way. But I also like to think about it like the same way an attacker would. Like if I were an attacker and I was looking at finding all these types of applications that these organizations have spun up, what would I do? I'd look at other things too, like DNS, which is not just on the domain side, which is like what you pump into your browser, but like domain validation cookies. So if you're going even deeper and you want to see TXT records on a domain back for a particular company, You can usually find the IT folks on the company will probably create some type of validation that they own this specific website, and they'll dump that into their domain record, and they'll usually leave those behind. They'll go stale over some time, but it gives an attacker a really good sense of, hey, they're signing up for Office 365, they're signing up for, you know, G Suite, they're signing up for, you know, whatever type of tool out there. And so it gives you that additional sense of these SaaS applications that need that type of verification, and attackers look for that, and so do we.

That's a pretty interesting thing to look for. I was looking through some of your company materials before, and I saw a lot of thinking still about, you know, real layer 3 and 4 stuff— IPs, ports. We're in an age of like HPE endpoints driving everything in the cloud. Is that kind of, you know, '90s IPS-style thinking still relevant?

I think it is to a large extent. So one thing we typically tend to see on just the kind of IP and port level Organizations still have offices today. They're going to continue to have offices. They're going to continue to have data centers. They're going to have some level of static infrastructure, and that static infrastructure will have a netblock assigned, and it's going to have, you know, some exposure out on the internet. There's always going to be some risk out there. It's never going to be zero. But there is, of course, the cloud side that changes quite a bit. Now, when it comes to the specific IPs and ports, there's oftentimes what we'll find, you know, organizations that have Warmable protocols like SMB and RDP exposed. And those are things that you just don't want to have exposed.

That's on the ouch space at this point. It's like, no.

Absolutely. And usually we get people to jump out of their chairs once we see that pretty quickly. So those are the kind of low-hanging fruit. I do think that there is this higher level kind of concept of you do need to go a little bit deeper on the attack surface side. It's not just about IPs and ports, especially with applications that are hosted in the cloud. You usually have a load balancer in the way. You'll have something that's maybe put behind a single port. So you might have a load balancer flowing to your web application. In which case, you know, it's really about these other types of assets that are not just these network-connected machines that most IT and cybersecurity teams have thought about over the last 20 years, but now it's more about like, what are my certificates? What is the web application itself? That's an asset to me. It needs to be managed as part of my cybersecurity lifecycle as well. What are the domains that point back to this and when do they expire? That potentially creates a brand reputation for me too, reputational risk. And so you think about not just, you know, the direct exposures and the vulnerable protocols that are just the kind of like, yeah, that shouldn't be out there, but it's also what's behind those specific ports and the application that's running. Maybe you even have an admin portal. We've seen this before too, where an unintentional, you know, deploy of an admin portal that was publicly exposed to the internet existed out for an organization. And that can be a huge risk for organizations that just leave this stuff out there hanging.

Yeah, actually that's probably a good transition to the kind of risks and priorities, because when I was reading about this space back in my Gartner days, I was kind of curious because it sounds like the challenges that attack surface management solves They sort of were there 5 years ago, 10 years ago, but it's like the volume of those challenges is just increasing. So when do you think about the threats people face from unknown assets? Is this data exfiltration? Is this about people getting into your org? Is this about business disruption? How do you stack rank badness that comes from not doing attack surface management?

I think a lot of the risks end up being the same. It's just that the unknown part makes it even riskier, if you want to say, because the fact that it's unmanaged, it doesn't mean that you're going to be necessarily subject to any different type of novel attack. It just means that you're going to have a lot more likelihood or a higher probability of some type of attack occurring because of the fact that you don't have these types of processes that you're applying for the rest of your IT infrastructure. And so, you know, data exfiltration is top of the stack for sure. We see that quite a bit. In fact, just yesterday, a security researcher put out a report of a public-facing Elasticsearch server with no authentication that had a secret list of terrorist watchlist information in it.

Oh, that's nice.

Yeah, exactly. And so he alerted the right authorities to it and, you know, that was closed down. But this is a repeating pattern. We've seen this before. You know, we see databases popped on the regular and this information gets stolen. So exfiltration continues to be top of the priority aspect for a lot of companies that are looking at their attack surface. But I also come back to the original question. I would look at the fact that, you know, if this were a solved problem, if the current tools in the cybersecurity landscape solved this today, I don't think we'd be seeing as much of these incidents as we do today. So something in the current stack of the cybersecurity ecosystem is not solving this problem correctly. And again, I chalk that up to no one's really looking for those unknown assets. No one's raising the priority enough. You have vulnerabilities now, and I'm sure you know this, Anton, which is, you know, 2005, you probably had like 6,000 CVEs. I can't remember the exact count, but now it's like over easily 140,000 or so. Can't remember the exact count today too. I just did the analysis a couple weeks ago. I should, but it's a lot of noise and a lot of signal that you have to be able to extract on what's the most important thing for me to be fixing first. And having something on the outside that's telling you, hey, this is public-facing, hey, this is something that you should be fixing immediately, and mixing that in with the rest of your kind of risk-based management ecosystem can be vitally important to solving a lot of those issues.

That's a great transition to what I wanted to ask about, which is when an organization is getting ready to consume a service or the output of a service like yours, who actually handles this stuff and what does that lifecycle look like once you say, hey, this thing exists?

To boost the signal on this one, I've seen something similar happen with organizations that do similar things, but not exactly your space, where they get a signal, but there's no clear triage path. Like, you have a bot-infected machine in your company. This is not your area, but from an adjacent market. And then people kind of freak out because it's like an abuse email. Is it the CISO? So to me, many security alerts have a clear confirmation path, but from new technologies like unknown asset found in a publicly exposed area, It's not really clear who would it go to. So it sounds like a problem, right?

Yeah, I think what we're seeing right now is given the nature of the space, it's not new, but I think what you're finding is a lot of the teams that we tend to talk to, it'll vary depending on how large the organization is. For very large organizations that have a lot of subsidiaries, like I would say by and large, they're going to have a pattern of, they might have different teams that actually take part in this delegation where they are managing their own infrastructure. Maybe there's some centralization and coordination amongst them all. Ultimately, you know, you're triaging and discovering all these assets. You're kind of pumping those and having a system of record where you can store them all in. But then there's some organizations where I'd say it really just comes down to 2 teams to simplify the problem, which is there's the SOC team and vulnerability management team. On the SOC side, you can look at it as an incident. So, you know, pump the information into your SOAR tool, use your enrichment processes to actually identify, tag.

Yeah, but wait, wait, wait.

Sorry.

Sorry for interrupting. Like marketing bought an application from vendor X. is not something SOC would know how to handle.

Who handles it then?

So I'm not sure. I don't see the SOC as in the path. Yeah, like I don't really know how they would handle it.

Less for the SaaS application side, much more for the host side, I would say for that case.

Ah, okay.

For the SaaS application side, that I would probably pump through IT, 'cause usually like IT can probably better handle that. But usually what we see most of our organizations that are working with us today, they'll be more focused on the host side and tackling that first. I think the SaaS application side, you're probably gonna wanna start looking at IT security teams having that pump through information security analysts that are going to start looking at, are my SSO policies applied to this? Is everybody logging in through my SSO platform so I can get auditing and everything else that I want in place on this application that somebody just found and discovered and now is putting in there? So I think there is a triage path for that. Most companies right now we tend to see and work with, they'll utilize their vulnerability management teams and their SOC team depending on the type of incident that they're looking at. Is it an incident of a new system or port that's being exposed, or whether or not they want to incorporate their risk-based management program.

Okay.

No, that does make sense to me.

I think that this, this like infrastructure level stuff, it's much more clear where to go with this. Yeah. So any other advice on what to do with the signals from your type of a system? What else can they do to make it better?

I think where the industry is going to go as a whole, and I think it's a little early, right? If you look at the hype cycle in the attack surface management industry, but if you look at the problem of attack surfaces as a whole, the long term is really getting more proactive about them. So instead of being reactive where you're handling incidents, How do you start to reduce the load on teams and start to actually get ahead of these problems? And if you can plug more into automated systems where developers are the ones these days who are really running the infrastructure, they're using Terraform to deploy new infrastructure, getting infrastructure online, and you start to shift more of that left. And so there's less of a security team filing a ticket or maybe automating some of that and then pushing it eventually back to a developer, but having your ASM plug into your development lifecycle. And we can do that with our API. But what you can do is you can start to shift more of that towards the developer and then have them be dinged the second it maybe violates an organization security policy what should actually exist on the internet from my attack surface perspective.

Mm-hmm.

That's one aspect. I think the second aspect is, you know, teams these days do not need more red lights dinging in their face. They don't need more information kind of flying around. So figuring out a way to automate it more. So automating into your SOAR platform, automating potentially into your SIEM as well. And I know SIEM is evolving right now, day by day it seems to be evolving, but, you know, doing more of that downstream automation and finding a way to actually close these issues and proactively or virtual patching some of these issues, applying like a WAF rule and having a system that can actually use their API to actually apply some of those virtual patching methods, that can help out greatly for security teams. So I think, you know, it's really about the operational pieces. And then the last piece, just on like the breadth of information, I would just say there's a lot more to be discovered in terms of assets. Assets, again, are not just those hosts. They're not just the SaaS applications. They're domains, they're websites, they're certificates. And all of these play a role into your downstream ecosystem. Plug your websites into your AppSec scanning tool, find more SQL injection, XSS, protect those applications.

Yeah.

You know, so it's really about integrating it into your entire cybersecurity ecosystem and making sure that your attacks surface, your vulnerability management program, your CSPMs, your application security suite, they all work and gel really well together.

Do people ever argue with the findings from your tool? I know that in somewhat adjacent space, security rating services, people do argue and they say, no, I don't have a machine with bots. And occasionally they win, occasionally they lose. So what about your case? Do people ever say, no, your tool is wrong, I don't have this asset?

Yeah, that exists. And I think really it comes down to how good your algorithm is, what we call attribution. We pride ourselves in having some of the lowest in the industry right now false positive rates. And we hear that anecdotally through a lot of the folks that we talk to. But the way you need to really think about that is what are the sources of information you're using? How do you kind of tune the algorithm to find things? How manual is the algorithm? So a lot of, you know, different companies will use people to kind of like augment or supplement the way they do discovery and attribution so that, you know, an organization, a vendor might actually use those people to filter out any information before it gets to you. So that you cannot see that false positives potentially. But, you know, that's definitely a big problem because you don't want to spend your time, you know, wasting time on triaging something that's not yours. So finding a way to do that in the most efficient way is definitely top of mind.

To sort of start putting together the closing thoughts, I guess when I hear about people doing shadow IT or cloud, the old thinking again, 5, 10 years ago would be security needs to fight it. They need to clamp down on this and like make sure it's gone. It's very clear that it's not what people should be doing and would be doing today. Again, back in my Gartner days, they thought about the model of bimodal IT, like a fast IT that goes and breaks things and the traditional IT that goes slow. What's the typical like meta advice? So, okay, I bought your tool. I have a lot of findings. What do I do? Do I go fight them? Do I join them? Do I somehow harmonize it? Like, what's your meta advice on this?

To make that a little harder, maybe, is there preventive things people can do here? Like, this has been a very response detection-driven conversation.

Yeah, but wait, wait.

I'm curious.

They may not need to prevent it. That business may be right. Preventative feels like a wrong way to go simply because this is business doing business.

Well, let's ask Derek if he thinks preventative is the right way to go.

Okay, let's ask Derek.

On the subject though, you know, kind of of the first side, Anton, you're going to have to walk me through that a tiny bit more too, just so I can kind of understand that a little bit better.

Okay. So like if a company has lots of findings from your tool, does it mean they have to go like find the people who put those assets and like fight them to make sure they stop? Or is there any kind of like adopt the assets? Like, what's the meta conclusion? Meta conclusion is they're all wrong and security team is right or not?

Like, I wouldn't say it's like a finger-pointing game. I hope it doesn't come off that way. I think organizations need to grow. They need to be able to adapt and they need to focus mostly on building business value. You know, to kind of bring that back to ASM, what I would say is we should be helping organizations by empowering them to give them the right information at the right time so that they can make the right decisions on what to close. And for me, that comes down to helping organizations with the right context, so having deep results on each type of asset that we find. We want to have the most context to give folks that are triaging this information the information they need to quickly adapt and respond to them, triage them, and decide whether or not they own them or not. And from there, work that into their downstream processes. It really does make a lot of sense for companies to continue to build and focus on that value creation, and we can play and help in a central role of creating an environment that works for them really well. And then the last thing on the kind of VRM side I'll kind of point to is like, there are tools out there that will kind of tell you where you're not doing well, but they won't give you a lot of information on how to do it. And that gets a very frustrating process when you're getting a risk rating and it's telling you you're not doing so well on your attack surface, but you don't really know where to go to fix it. So again, I think you have to step back and say, you know, the meta advice is find your assets, triage them, incorporate them into your security program, and kind of move on. Having that process and reliability loop in the kind of background where your business is growing Just helps you reduce risk overall, helps you with your brand protection, and can overall, you know, just help you kind of continue to drive value.

So I was wondering if you had one practical tip for our listeners to improve their knowledge of their attack surface, and 2, if you have any recommended reading for our listeners to learn more.

You know, I think one piece of recommended reading is we did release kind of a shameful plug is a buyer's guide that we just put out there, which will tell you a lot about the attack surface management space and our take on it. That'll answer that question. The other side though is my tip for your attack surface is, The first step is just knowing. So just get something at least to give yourself an understanding of what your inventory and give you a baseline of what you have. From there, the second step is really understanding, contextualizing, and operationalizing it. So if you left with one thing, I think that the first thing to do is just know, do you know what's out there? And getting an answer to that question as fast as you can.

So it's really all about know thyself.

That's a great way to put it.

Awesome. Derek, thank you so much for joining us today. It's been an absolute pleasure.

Thank you for having me.

And now we are at time. Thank you very much for listening, and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. We typically release them every Monday. You can follow us on Twitter as well, twitter.com/cloudsecpodcast. And of course, your hosts, are on Twitter as well, @Anton_Chuvakin and _TimPeacock. Tweet at us, email us, argue with us, and if you like or hate what you hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.