[00:00:14] Speaker A: Welcome to the security Serengeti. We're your host David Swineger, and Matt Keener.
[00:00:18] Speaker B: We're here to talk more about cybersecurity. Each episode we will focus on a specific topic or two of interest to the community city. Today we are talking attack Surface management, yet a new acronym to keep track of.
[00:00:31] Speaker A: And of course, as usual, the views and opinions expressed in this podcast are ours and ours alone, and do not express the views or opinions of our employers.
[00:00:39] Speaker B: Attack surface management for humans is bug spray and sunscreen. So tax surface management. This one has come up recently, a bunch kind of like XDR. It seems to be the latest buzword bingo this year. So I'm sure that all the conferences are going to be a lot of attack service management, a lot of XDR, a lot of soar, and a lot of machine learning. Drink. So there was a sans conference about this the other day that I attended. Virtual conference. It was four or 5 hours long. It was a short one. It was sponsored by one of the vendors who I'm not going to mention here. And I thought it'd be an interesting topic to kind of dive into a little bit, because one of my favorite things to do for this podcast is pick stuff that I don't know very much about, and it forces me to actually research it and dive into a little bit tax surface management. I have stolen the following definitions from Pierre Ladome. He wrote a white paper that's really good on attack surface management, and it will be linked in the show notes. So attack Surface, let's start with which is all Internet accessible hardware, software, software as a service, and cloud assets that are discoverable by an attacker.
First of all, that's interesting that he includes software as a service in there. I don't know that I would consider that part of the attack surface, but that's an interesting one. David, you added a note in here about whether email addresses are considered attack surface assets.
[00:02:05] Speaker A: Right. I was kind of thinking that if you're looking at this from the attacker perspective, workstations are practically on the front line with the phishing attacks. So I'm wondering if you can consider that an attack service and how you would include that in your tax service management.
Because quite frankly, I don't think SaaS makes any sense at all. Because what are you going to do about it?
[00:02:30] Speaker B: I know, right?
Full disclosure here. I've demoed and done pocs on two attack surface management products. So I'm not an expert. I haven't used all of them, but neither of the two that I used included email addresses and neither of them included software as a service. So those were definitely not part of those POCs.
[00:02:51] Speaker A: I mean, infrastructure as a service would make know if you're running AWS, cloud or azure or whatever. That would make sense. SaaS does not make sense.
[00:03:00] Speaker B: Yeah, I think I can agree with that. All right, second definition, we define the attack surface. Attack surface management is an emerging category of solution that uses an external attacker's perspective to help organizations better manage risk associated with their attack surface. It combines three things, unknown asset discovery, vulnerability scanning and prioritization, and targeted threat intelligence.
We'll dive into those in half a second, but this seems super similar to the other week's discussion on XDR. It's a new acronym, it's a air quotes new technology. But what it really is is it's a recombination of existing technology into a slightly new form, maybe more well packaged for less mature organizations, but it's also.
[00:03:51] Speaker A: Kind of an offering from somewhere else. Whereas all the three things that you just talked about, at least the first two alone, are generally done internally by people who have more than one job versus a dedicated outside entity, that this is what they do for a living.
[00:04:11] Speaker B: Well, from what I saw, it's not really people doing this. It's 100% automation. It's clever scripts and probably machine learning, I don't know.
[00:04:24] Speaker A: Well, I would assume those are dedicated people writing those scripts.
[00:04:27] Speaker B: Yeah, yeah, that's fair. Although some of them are more hands on than others. There's definitely a big gap between them in terms of UI and customization for sure, but I'll talk about that later. All right, so the three things that they combine, the first one is unknown asset discovery. This one is actually what I think is the secret sauce here, because the vulnerability scanning prioritization piece, at least one of the tools that I did a POC with, they're just using the open source version of tenable nessus. Like the vulnerability scanning part is not the secret sauce. It is bog standard vulnerability scanning that anybody could do, literally anybody.
The secret sauce seems to be in the asset discovery and in the merging with the threat intel part. So these guys that I did pscs with, they did it through a combination of, I think one of them you gave them a list of your domain names you wanted them to spider off of, and the other one just took your main corporate domain name. And what they did was they looked at all the registration records they would pull out, what's the email address of, who registered it, what's the infrastructure? It's on. Do you own the infrastructure? Who owns the net blocks? And they take your name from the registration xx name, and then they're going to go out and look for everything registered by that name. Then they're going to find all those net blocks and all those domain names, and they're going to repeat the process. They're going to take certificates, they're going to look for everything. If there's other domain names on the certificate, they're going to look for links that come off of your website. And this one's a good and a bad one, because sometimes, many times, you link to maybe subsidiaries or companies you own, but sometimes you're going to link to third parties that you don't own, and they may get pulled in and included in there. So I think that's the secret sauce there is the asset discovery part.
[00:06:17] Speaker A: Well, actually, there's probably a couple more.
Well, at least the targeted threat intelligence, because you assume that they're digging into the dark web, and that's probably more of a much more manual process to find people who are actively targeting you or information about them targeting you on the dark web. No, that's not what they're talking about.
[00:06:36] Speaker B: That is not what they're talking about.
I'm sorry, hold on. Let me rephrase of the ones that IPOC. That is not the targeted threat until they're talking about. The targeted threat until they're talking about is what they call the attacker's perspective.
Both of the ones or just one of them? At least one of the ones I looked at provided an attractiveness score, which they're like, oh, we've got a team of red teamers, badass hackers that are always looking at things. And this score represents how attractive they would find the asset. And that was also mentioned in more than one webcast I listened to over the past couple of weeks, where the idea is that they're able to tell you which of those assets that is online is the one that is most likely to be attacked based on a combination of what services it's providing, how easily found is it, what vulnerabilities it has. That's what they mean by targeted threat intel.
Okay, which is, okay, yeah, it's just a little useful.
[00:07:42] Speaker A: It's not what I assumed based on that statement. Targeted threat intel is like, okay, targeted threat. And so people are targeting you. Where are you going to find that information about that target?
[00:07:52] Speaker B: Then they would charge you another half a million dollars for that.
[00:07:55] Speaker A: Something else I was just thinking a second ago, when you were talking about you give them the domain name or whatever and they spider off of that.
It would probably be more beneficial to say, here's our company name. Now go. Because what I don't see included in here, and this kind of goes back to the email addresses thing, is like, are they searching LinkedIn to see what your executive panel looks like, your executive team looks like, or your CIO or a network administrator in there?
Because those individuals are also kind of attack services as well. But I guess based on the definition you have in here, that's outside of scope for this particular acronym for attack service management. Maybe we could call it attack service management. Plus for including the human element or something.
[00:08:47] Speaker B: Where I've seen that before is under brand monitoring.
There's a couple of brand monitoring vendors that do like the social media aspect and yeah, watch for mentions of your executive team and watch for new groups and people on LinkedIn and stuff. So I don't know why that's put there, but you're right, it's kind of what you're talking about. The email addresses and the people are part of your tax surface. I think they defined it in just a very narrowly scoped way that matches the capabilities they had.
[00:09:16] Speaker A: Right. See, it's unlike Gartner inventing a magic quadrant. This is a couple of vendors creating their own magic quadrant and trying to get Gartner to latch to it, maybe.
[00:09:28] Speaker B: Well, it's got the same problem that XDR does. Like one of the things we looked at when we looked at the XDR is a lot of them had different capabilities and were claiming to still be XDR. I don't think it's fully defined yet, and that may be part of the problem. Maybe in the future, as vendors have better capabilities or maybe they purchase people that account for that social media, they're going to lump that into this.
[00:09:50] Speaker A: Yeah, see, that's going to be really hard for that to happen, though, because I'm trying to think about emergent standards for a light socket or a power outlet or whatever. It makes sense for different manufacturers to latch onto that standard for those items. But when you're talking about this type of thing, you've got one vendor that provides what they're calling that capability this way, and you've got this vendor providing it this way. Neither of those guys are going to want to shift the definition away from what they're saying their offering is. So it's going to be really hard to get a consensus around a definition when it's not in the best interest of the companies to come to that.
[00:10:38] Speaker B: Point, I think we can eventually all the sim kind of settled down into the same place with mostly the same, different methods of doing it, different uis, different capabilities with them, but they're all kind of comparable. Same thing with Av. AV really kind of settled down and.
[00:10:55] Speaker A: EVR settled down as it's, it's just mean. As much as I like to bash on think you know them, Forrester, Einz, those kinds of think tankish type places would be more like the ones to kind of pull everything together into a standard definition and kind of get some consensus around will.
[00:11:21] Speaker B: I just think it will. I just think it'll know a round of mergers and when it condenses down to two or three or four vendors instead of all the ones that are currently sprouting up right now. But I'm sure a bunch of them will know. Palo Alto will buy one and it'll be, oh, they did. They bought one called expanse. I don't know if they folded into their XDR product, but they did buy one. So all the big players are going to buy and include this into their suites.
[00:11:46] Speaker A: Man, I hope they don't ruin that show's brand name.
[00:11:54] Speaker B: All right, so like I said, this is similar to the other week's discussion on XDR. The first time I remember seeing this specifically was a brand called security scorecard, I don't know, probably six or seven years ago. I remember their big selling point at the time, though, was monitoring partners and vendors where the assumption was that the external security mirrored the internal security. And by looking for issues on the edge, you could predict whether it would have issues internally as well.
[00:12:21] Speaker A: Yeah, I'm not sure if they still do this, but if I remember correctly, I think security Scorecard also had a trending thing. So they said they would follow the third party over time and say they're improving or they're getting worse, or this has changed, which means that the likelihood of x happening or the risk here is increased or decreased based on the trend over the past x number of days or x number of months.
[00:12:51] Speaker B: But I'm definitely seeing a trend here of combining old products and calling them new names. And I was going to ask what the next combination was, but I think you've already predicted it. I think it's going to be the combination of email protection and social media, like all the various methods of phishing into a single product.
[00:13:12] Speaker A: Actually, that's something that I just thought of is for the attack service we're talking about at least thinking about emails. Is that how many organizations are watching for bounce emails, because if your email address is bob
[email protected] that's your corporate email address.
Are they just throwing emails at any kind of pattern that looks like that and looking at what emails you're bouncing to see if a particular email address or a sender is kind of probing, if you will, your email space?
[00:14:02] Speaker B: Well, I know that if you had proofpoint, it might make it a little easier to do this since proofpoint just passes along emails, it doesn't go and check if the email exists or not, it just passes it along before it classifies it as malicious. So you might be able to do kind of a comparison because if you're just looking at all emails that might be noisy, but you might be able to take what proofpoint if you're feeding into your SiM, take the stuff that proofpoint has and then look for ones that don't match existing users. And that way you can at least only look for ones that have been classified as malicious as opposed to all of them.
[00:14:36] Speaker A: Yeah, proofpoint being the large vendor that it is, you could feed that kind of information back into proofpoint and they could probably start flagging those senders or those sources as potentially malicious to improve the overall environment for all their customers as well, which is pretty big.
[00:14:54] Speaker B: It's manual, though. They don't have an automated submission.
[00:14:58] Speaker A: Of course not.
[00:14:59] Speaker B: Yeah, it's a known problem.
All right, well, so attack surface management, what are some common use cases for attack surface management? And some of these are pretty simple and easy. The big one is external asset identification.
Asset inventory and asset management is a problem everywhere. I don't think I've ever worked anywhere that's been able to do it completely.
So that's definitely a big part of it is being able to get a good handle on your external surface, especially the way that they work using things like DNS, registration data, what's living on various IP subnets, certificate data, all that. You are almost guaranteed to find assets you did not know you had.
[00:15:42] Speaker A: Yeah, I would assume then if that vendor would be able to tie into a CASb that you'd have sitting at your edge as well.
They would be able to identify or maybe even having their own tool identify if your organization is reaching out or connecting to an AWS or an azure, because all you need is a credit card to start putting stuff in the cloud and your IT department may not even know about that shadow it also.
[00:16:13] Speaker B: Well, and you make a good point there too, because stuff that the attack surface management vendor would not be able to find would be stuff that's in a completely different infrastructure, like Azure maybe, when the rest of your stuff is in AWS and it's registered by somebody else so it doesn't have the appropriate company name and all the other normal things you do when you register. So I don't know. I haven't heard if any of them do so in with a CASB, but if they did, I think it'd be a big help in trying to identify kind of the shadow it stuff that won't be picked up in the normal ways.
[00:16:46] Speaker A: Yeah, because they could actually add that as an offering, saying, we'll deploy a CASB because like working with any kind of MSSP or something like that, they always like, well, you have to deploy our appliance. These types of organizations or vendors that offer this kind of service could also say that, saying, oh, well, we're going to deploy this thing which adds this additional capability rather than the organization itself buying a CASB. Because if they have it, why pay this vendor to link into it?
[00:17:14] Speaker B: Use case number two, identify gaps in visibility, the external asset identification that you have. It's a real good idea to turn around and compare that to your sim if you have one, if you haven't already gone down the XDR route and make sure that you're bringing in all of those external assets. There's definitely arguments on either way for internal assets, whether you should be collecting logs from everything or not. But I think pretty much everybody agrees that you should be collecting all of the logs from all of your external facing assets.
[00:17:44] Speaker A: Some people say all the things, not.
[00:17:46] Speaker B: Just all the external, you know, I would love to, but there's always that pesky budget part that just ruins my day.
[00:17:54] Speaker A: I'm kind of on the fence with that. Are you adding more hay to the pile to find that needle, or really you have to determine the value of the hay you're throwing on there. I think.
[00:18:05] Speaker B: No, and I get that. I get that for sure. I know for sure there's two kind of schools of thought on the whole sim event log thing, where one school of thought is you bring in one log source at a time, you fully plumb that log source and figure out all your detection logic from that one, and then you go to the next log source and you fully plumb that one, et cetera, et cetera, versus starting by dumping everything in there and then trying to find stuff. I think the big problem with the one log source at a time, I think there's two problems with it. I agree that it makes sense. I agree that it's very budget friendly, it's very straightforward, especially if you don't really. Well, there's two things that worry me about it. The first one is if you do have an incident with that first log source, you're going to have to go and manually get those other log sources as well, because you may not have enough information to actually fully triage or investigate that incident if you've only got that one log source in there. And my second issue is the whole, you don't know what, you don't know where. If you don't know that a log source exists. Or maybe, for example, if you've got a lot of applications and you don't understand the application, you may not know to ask for that log source. So I don't know. I understand. Dumping a whole bunch of log sources kind of willy nilly in there definitely leads to a much more complex and expensive environment, for sure. And this is why I'm not a manager, because I don't have to make those decisions.
[00:19:31] Speaker A: I was about to say that this is an entire nother episode all into itself. Log management.
[00:19:36] Speaker B: Yeah, I think I agree that the right way to do it for most businesses is probably the one data source at a time. It just hurts my soul a little bit as an analyst, that's all.
[00:19:49] Speaker A: You still have a soul as an analyst.
[00:19:53] Speaker B: Hasn't been beaten out of me yet. All right, use case number three, risk based vulnerability prioritization. This is kind of the big one. We talked a little bit about this the other day when we talked about. I think there's an article where we discussed that only 10% of cvs are actually exploited.
You can't patch everything. We would love to patch everything. Depending on if you're in the government or not. They may tell you you have to patch everything, but it's unfortunately not possible.
So this is a lovely way to help you prioritize some of those ones you may have missed.
Finally, assessment of mergers and acquisitions and fully or partially owned subsidy risk. Now this was a use case that was identified by that white paper I saw, and I actually am curious about this one and where it falls on a legal scale. The reason I asked this is one of the ones that IPOC, part of their vulnerability scanning. They were using the free and open source version of Nessus. It logs into default credentials. Is that a computer fraud and abuse act violation? To log in like vulnerability scanning is one thing, but actually exploiting the vulnerability or logging into the default credentials, is that a legal issue?
[00:21:08] Speaker A: It would depend on the contract. Because pen testers probably do that. Right?
[00:21:12] Speaker B: Hold on, though.
Okay, there's two things here. First of all, they called out as assessment of merger and acquisition risk before you sign the contract, before you finally sign the Merger. And acquisition, you don't own the company. Now, you might have it written to the contract that you can perform red team tests or whatever, but there's another kind of thing here where some of these guys, because they spider off of pages that link to your web page, they find third party companies and they will scan and do their magic on third party companies and partners and vendors and things like that.
[00:21:52] Speaker A: Okay, I see what you're saying.
I'm wondering if that's your problem.
[00:21:57] Speaker B: Well, technically, I guess it's not, right? You hired this company to do it for you.
I think that's what I was told when I asked about it somewhere else is I was told, well, it's them. It's not you.
[00:22:08] Speaker A: Yeah, because if you're paying them to do x and they kind of go overboard with doing that thing, I think the liability would still be completely on them. It's not like you told them explicitly to go and do that.
[00:22:22] Speaker B: Yes, I hope so.
[00:22:26] Speaker A: Another caveat. We are not. Lawyers don't claim to be, nor did I say, nothing here constitutes legal advice.
[00:22:38] Speaker B: No, absolutely not.
[00:22:39] Speaker A: My lawyer had you say that.
[00:22:42] Speaker B: I don't even have a lawyer. Should I get one?
All right, so here's their conceit. And we talked about this a second ago, their whole conceit, because frankly, anybody can vulnerability scan yourself and anybody can go and look at your passive DNS. Go look at your infrastructure, look at your certificates.
[00:23:01] Speaker A: Really?
[00:23:02] Speaker B: Anybody could kind of do that. It'd be painful to do it manually, for sure.
But their idea is they look at the attack surface like an attacker. And one of the ways that they do this is they add an attractiveness factor to the calculation. They'll add, how hard is it to do? I'm using as a specific example, one of the companies that I did the POC with, they'll add like, this asset was very hard to find.
We had to follow links.
We went through a whole series of things to find it. It's kind of tucked away and hidden. I don't know if they search Google for it or any of the other publicly available sources of intel, but they'll tell you that they think it was very easy or very hard to discover.
They will create a risk score based on how hard it was to attack the severity of the cves and whatever internal magic pixie dust around how exploitable those cves are.
[00:24:06] Speaker A: Do they have anything in there about the current trends in scanning?
[00:24:12] Speaker B: I don't think so. And the reason I say that I don't think so is because during that Sans conference I was on, there was a presentation by a guy from Canada Air and one of his use cases he talked about, about how they were implementing attack surface management at Canada Air is they were combining the attack surface management asset stuff and vulnerability stuff with data from their threat intel provider on. They were looking up recent news reports. Most threat intel providers will send like a daily email with what's going on today and they were scanning for cves from those emails and then comparing that to what was exposed on their attack surface and then that's how they're prioritizing vulnerability remediation.
[00:24:57] Speaker A: I'm thinking if you had a showed in enterprise account, I forget what they call their offering or whatever, you can get trending from that on what people are searching for to see if that lines up with any of your exposure.
[00:25:18] Speaker B: Yeah, that actually be really interesting to combine that. All right, so we're going to talk a little bit about what to look for when comparing solutions. I'm not going to go over all of the things that I wrote down because a lot of them are pretty obvious and they're things you look for when you compare any security solutions, but big ones to call out for attack surface management when you are comparing them, when you're doing discussions, when you're doing pocs and I 100% all these are cloud based. You should be able to do a POC with these guys very easily. This is not something where like an AV product, where you have to install it on a bunch of things and someone's got to maintain it and someone's got to uninstall it and all that stuff. These are all cloud based products. You can just give them your domain name and they will run with it. So absolutely should do a POC and should actually compare these. I know this is definitely something I struggle with when I sit there and listen to vendors just talk about how good their product is. I can't tell the difference between them. I have to get hands on keyboard and actually look at the results.
[00:26:16] Speaker A: Well, if they are using scanners that do authenticate to default credentials, I want to make sure you keep that in mind.
[00:26:29] Speaker B: You should sign paperwork with them and maybe limit the scope of the POC possibly for sure. That's fair. All right, so first thing you should look for is we talked about their magic pixie dust is not in the vulnerability scanning, it's in the asset discovery and it's in the targeted threat intel. So the first thing is look at that asset discovery. How much infrastructure did they find? Did they find compare them. Did one find six hosts within whatever your POC was and the other found 24? That's pretty interesting. You're going to want to look at in that inventory that they create, are there false negatives that you can find? Are there pieces of equipment they miss that they should have had? And how bad is that miss? Is it another host that's on the same subnet that they should have found, or is it on completely different infrastructure? It's got a different registration name. There's no real reason they could have found it.
Also, is the solution allow you to import those missed items?
That would be nice, because otherwise you're kind of stuck with whatever they find.
[00:27:36] Speaker A: Yeah. And do they have a process to make sure that that doesn't happen in the future so that you don't have to continually import?
[00:27:42] Speaker B: Yeah. Can they fix whatever the problem was? Can they adjust their scanning methodology?
Also, you might want to check yourself. Do things like compare the running services and the detected vulnerabilities against your own scans. Maybe reach out and validate that the vulnerabilities found are actually vulnerabilities. Look for false positives.
You're probably not going to have time to do all of it if you're doing a POC. We're all super busy people, but take a selection, take three or four and go through and just validate all the findings you'll want to look at. How often does it look for new assets? Does it look daily, does it look weekly? Does it look monthly? Does it look on demand? Because a big part of this is going to be continuous monitoring as well. So those are some thoughts around the coverage in terms of the risk scoring and the threat intel functionality. Does it tell you how attractive it is? And will the company tell you how they determine attractiveness? Are they willing to share that with you? Does it tell you how hard to find the asset is? And will they tell you how they determine that?
I was just thinking myself earlier, the one that I poC'd with, I don't think it searched Google for it necessarily, but that be because maybe it was hard to find know. It had to pivot off this website and then it to pivot off that infrastructure and then it had to look down this certificate chain to find it. But maybe you guys, maybe it's like a public portal of some kind and the company's just actually literally posted it on Google and is doing search engine optimization. So maybe the ASM company thinks it's hard to find, but it's really not. Does it include current intel and what's being exploited currently and in the a? That's actually a real big one for some of these, because as somebody that personally I haven't done vulnerability management for probably seven or eight years, I don't necessarily know what's big and being exploited right this second, unless it came up on my research or I've seen it exploited at the company before. So that'd be a big one.
[00:29:48] Speaker A: One thing I'm wondering also is are they taking into account industry trends if you're in retail, is your score relative to your peers as far as what's being looked at, or are you at the same level of the risk? Are you falling, not victim necessarily, but are you doing the same things your peers are, which is making you at risk, or better, worse, et cetera kind of thing?
[00:30:21] Speaker B: I'm not going to speak to specifics on that, but I have not seen comparisons between peers on either of the products I've looked at in depth, and I don't think either of the products I looked at really called out things that were being attacked in depth. I'm not going to call out a specific vulnerability. It turns out it was on a third party anyways, which is how I know that there are lots of false positives for third parties in here. But there was a very well known, highly exploited vulnerability found during one of the pocs and again it ended up being on a third party company, but it didn't have any sort of special flagging other than being flagged as critical.
Although I guess you could say that critical is serious enough, but it was a pretty serious CVE on its own. I don't recall seeing anything special saying like bright blinking. If you have this open in your environment, it's already exploited.
[00:31:17] Speaker A: Well, if identifying these kind of risks and third parties are part of the offering, it would be important for you to be able to take what they're finding here and also marry that up with your understanding of your relationship with that vendor.
Because if they are like that air conditioning company that had the connection in to target it. Right, that's important.
But if they're doing something where you are not transmitting data to them, or there are various levels of interaction or relationships with your third parties, which may or may not still put you at risk.
[00:31:55] Speaker B: Yeah, both companies we POC'd did provide the ability to tag. So you could probably create like a custom tag for that. But I don't know how you'd apply it to all the stuff for that company. You'd have to have them scan their whole infrastructure and this is not as fully automated as you want it to be because unfortunately when these companies scan your infrastructure they're listing these third parties under you because it linked off of your website. So someone has to go in and manually recalibrate, classify and tag them.
[00:32:33] Speaker A: If you're using something like we were talking about with security scorecard though, which is kind of third party focused, I think it would be certainly to your advantage to be able to have that kind of association or linkage based on what that report comes back with.
[00:32:49] Speaker B: Yep, that makes sense. All right, you also want to look at what intel feeds into the scoring, what vulnerability scanner does it use and how often does it scan and really does it make sense? Like look at the criticals, look at the ones they tell you are the most important ones and think about it critically and say all right, what does the CVE do? Is the CVE well known? Is it highly exploitable, is it being exploited right now or recently in the past?
Because that's commonly a problem we find with vulnerability management, right. Is a lot of stuff comes through as highs and criticals and may not due know existing context on the system or where it is or what data has access to. That may not be true necessarily.
[00:33:32] Speaker A: Something you also might want to consider then is how does this information relate back to you because can you feed that into your existing vulnerability management process in a simplistic manner versus creating an entirely new process in order to deal with these kind of reports?
[00:33:51] Speaker B: Yeah, there's definitely some UI things in there and again this one comes from, I'm going to go back into that, but I'm following the order of my questions because otherwise I'm going to forget it.
The UI varies widely on these. Some of these are super easy to use and some are really hard.
But next one, how does it inform you of the new assets? Is there a dashboard, are there email alerts, are there API related, is there an API connection? Can it be configured to generate alerts based on your criteria? Especially if you have a large attack surface, you're not going to want them to send you 3500 emails every week on newly discovered assets or vulnerabilities.
And if something changes on an existing system, is that called out as well? Like Port 22 wasn't open last week but now it is. That's definitely something worth looking at so this is something that can be a weak point on new companies. And a lot of these ASM companies are new companies where they're working on getting a minimum viable product out. I couldn't tell you if I'm speaking from experience, but a lot of new companies may prioritize the flashy upfront stuff, not the fully functional API stuff in the back.
[00:35:07] Speaker A: And if they have an API, I would suggest you find out that level of API because they may say they have an API, but it might be a very minimalistic one. So you want to ask for a full API. And when you define full, this is my definition of full anyway, is there's nothing you can't do with the API, which is not.
Or there's nothing you can do in the UI, which you can't also do with the API.
[00:35:34] Speaker B: Yep, full read, full write.
[00:35:36] Speaker A: All right.
[00:35:37] Speaker B: Now these tax surface management, sorry, products are not perfect. They have a couple of issues that I have seen myself recently. Number one, they can be very effective at finding assets in your external service list, but that will also include a lot of third party and partner infrastructure depending on how they do the asset discovery. We've talked about this several times. It may be a good thing in some ways if you want to monitor those third parties, but it may be a bad thing because it may generate a lot of excitement if something easily exploitable and really popular with attackers shows up on your alert list for the week. We have what available externally? Oh, it's not us. It's a third party.
[00:36:16] Speaker A: You may also want to make sure your third parties are aware of your new capability because there are two things here. One, you could be triggering alarms over there by having this company do these things. And two, it would probably still to your benefit, even if there isn't a direct connection back into your organization, to tell these third parties that they've got some issues or what those issues are and to improve their security also, or.
[00:36:47] Speaker B: To find new partners if they're running their system off a Windows XP server.
[00:36:55] Speaker A: There's an XP server?
[00:36:56] Speaker B: No, but apparently some companies will use one as one. All right. They can be quite noisy depending on how large your external footprint is. Like I said before, you're really going to want to do something like only look at the critical alerts or only look at a subset of them at first. Because if you have a big company, you will have hundreds of thousands of external assets.
I'm defining assets here, at least the ones that I looked at. They'll split them up and they'll be like the IP address is one asset, the domain name is one asset, the web application is one asset. Now those three things may all reference the same application and the system where it lives, but they'll be considered multiple separate assets from the perspective of the sorting and the vulnerabilities and all that.
And finally, if the external assets are not connected in some way, it's not going to find them. We talked before, we mentioned it earlier, the shadow it. If you stood it up in a separate infrastructure, Azure, where you normally use AWS, you didn't use your normal DNS server, shadow it, somebody put it on a credit card and they just put their own name there. They registered it under like it's not going to show up in attack surface monitoring. So in summary, it's cool. It's not really new. It's really kind of a simplification and a combination of previously existing technologies. That being said, I like it. And I like it for actually the reason that David mentioned earlier is they are applying some automation and some consolidation to what used to be three separate workflows done by potentially three separate teams, and they're putting it all together into one product and accessible from one place and they're doing the majority of the legwork on it.
[00:38:41] Speaker A: Yeah, one thing I'd say, even if you can't or don't want to go down this route of getting an attack service monitor or a tech service management organization, the vulnerability assessment part. A lot of organizations don't scan from the external. They scan an internal interface on a server and assume that that's what the outside looks like as well. So consider getting a box in the cloud and some vulnerability scanner companies offer that already where that's just part of your subscription. But consider actually looking at the outside from the outside and not making assumptions about internal scanning being what the outside looks like as well.
[00:39:30] Speaker B: I don't know the exact price and what, but these didn't seem too expensive compared to some other things. So I think even if you're on a budget, it may be worth at least kind of asking around and asking for some pocs and demos.
It's certainly less than the threat intel stuff I've been quoted before. That stuff is bullshit.
[00:39:51] Speaker A: There goes that ivory back scratcher though.
[00:39:56] Speaker B: All right, I think I'm good on this one. Do you have anything else you want to mention, David?
[00:40:00] Speaker A: I do not.
Take us out. Thanks for listening to the security Serengeti podcast. Follow us on twitter at serengeti Sec, and of course download and subscribe on your favorite podcast app. Now immediately.
