ASM in the Age of CTEM

(TC: 00:00:04) 

Aidan Murphy: Hello and welcome to The Dark Dive, the podcast that delves into the depths of the dark web and cyber security. My name is Aidan Murphy and I’m your host and, in this episode, we’re returning to the topic of Attack Surface Management also known as ASM. In particular, how it relates to a relatively new cyber security term, hold tight for another acronym, CTEM,...

(TC: 00:00:04) 

Aidan Murphy: Hello and welcome to The Dark Dive, the podcast that delves into the depths of the dark web and cyber security. My name is Aidan Murphy and I’m your host and, in this episode, we’re returning to the topic of Attack Surface Management also known as ASM. In particular, how it relates to a relatively new cyber security term, hold tight for another acronym, CTEM, Continuous Threat Exposure Management. CTEM, which we’re going to define has quickly gained traction, not least because of the emphasis placed on it by the analyst firm Gartner, but in many ways it can be seen as evolution or Attack Surface Management. Joining me to discuss exactly what CTEM is, its relevance to the cyber security industry and its relationship to Attack Surface Management are Ben Jones, CEO and Co-Founder of Searchlight Cyber, welcome back, Ben. 

(TC: 00:00:50) 

Ben Jones: Hi there and thank you. 

(TC: 00:00:51) 

Aidan Murphy: And Michael Gianarakis, Senior Vice President of Attack Surface Management at Searchlight Cyber. Welcome back, Michael.

(TC: 00:00:57) 

Michael Gianarakis: Thanks, Aidan. 

(TC: 00:00:59) 

Aidan Murphy: Michael and Ben were both on our previous Attack Surface Management 101 episode, but I will just ask you to re-introduce yourselves to listeners. Can we start with you, Ben. 

(TC: 00:01:08) 

Ben Jones: Hi, I’m Ben Jones. I am the Co-Founder of Searchlight Cyber and the CEO. We established the company in 2017 and have been working to help protect companies and society as a whole since then. 

(TC: 00:01:21) 

Aidan Murphy: Brilliant, thanks, Ben. And Michael. 

(TC: 00:01:24) 

Michael Gianarakis: Yes, I’m Michael Gianarakis. I’m the SVP of Attack Surface Management, as you mentioned earlier. I came into Searchlight through the Assetnote acquisition. I was one of the co-founders and the CEO of Assetnote and at Assetnote we pioneered the Attack Surface Management space. 

(TC: 00:01:41) 

Aidan Murphy: Brilliant, thanks, Michael. Before we start, I just want to say that this episode ties in with the new e-book we’ve released, ASM in the age of CTEM, which you can download for free from the link in the show notes. You don’t have to have read the book to enjoy this episode. We’re going to start from the beginning here but it’s certainly a good place to follow up after the episode if you’d like to know more. So, Michael, I’m going to begin with you and let’s start with CTEM. Can you explain to listeners where this new term has come from. 

(TC: 00:02:09) 

Michael Gianarakis: I mean, it’s primarily come from Gartner, the analyst firm. They’re pitching it as essentially a modern practice for managing exposure in your organization. I have some very strong opinions on this. 

(TC: 00:02:21) 

Aidan Murphy: Good. 

(TC: 00:02:22) 

Michael Gianarakis: Just given the history. One of the challenges that I have is that when we came up with the term ASM at Assetnote and we started building our product, what Gartner really describes is CTEM, in my opinion, is what ASM should have always been and it really is a more modern way to think about managing the exposure inside your attack surface and inside your organization more generally and I think ultimately, and I’ve said this on previous podcasts that security doesn’t operate in a vacuum, right? It is a reflection of the larger trends in business and IT in general and I think CTEM, ASM, whatever you want to call it, I think ultimately, really what it’s about is taking that into account and trying to come up with a systemized framework or a practice with which to manage those modern challenges, right? You know, highly dynamic attack surfaces, new and emerging threats, strained resources and I think that’s really the heart of it. I’ll save my stronger opinions about the analyst firms pushing this idea and perhaps there’s some other elements of play, but I think the heart of it is good and really, that’s my summary of what it’s about. 

(TC: 00:03:41) 

Aidan Murphy: That was really helpful, Michael. So, yes, it’s a funny thing, isn’t it? And I think a lot of people listening to this will know the feeling of a new term springing up. You know, sometimes we talk about cyber security jargon. Maybe that’s slightly unfair when it comes to CTEM but effectively, describing something that may have organically appeared anyway and like you say, from your perspective, CTEM almost describes what you were calling Attack Surface Management this whole time. Ben, how do you feel about Michael’s strong opinion there? From your perspective, is CTEM offering something new or is it just another buzz word that we need to off settle with? 

(TC: 00:04:16) 

Ben Jones: I think it is a good way of structuring the way in which you think about these things. I don’t think it’s revolutionary in the way that it totally changes the way everybody thinks about things. I think it is a way of trying to organize some of these thoughts and the fact that it’s continuous and the fact that it’s looking at it from an outside in, particularly from the Attack Surface Management side, I think that is a useful evolution of security, rather than just looking at your feet the whole time. I think another way to look at it is to contrast it with what came before and how it was common to manage this stuff before and that’s why I say it’s more of a modern interpretation of how customers or organizations rather can manage their exposure in their environment. If you looked previously, most processes were point in time, right? Vulnerability management as an example, you’d run a scan, or you’d do a pen test and that’s it until the next time you scheduled one or you did one. It was often very disjointed in terms of processes. You’d have theft intelligence over in one area and you’d have say vulnerability management is another example over in another area and they wouldn’t really inform each other. Very point in time, very static and I think the ideas or at least the core ideas behind CTEM is one, to really understand what it is that’s important to you, understand what you’re trying to protect and then look at that and monitor that on a continuous basis and in a theft informed manner and with a heavy focus on how to operationalize those issues and doing that in a more continuous and ongoing manner, rather than a static point in time, very reactive. The idea is to try and shift this to be a more proactive practice. 

(TC: 00:06:05) 

Aidan Murphy: Yes, that’s interesting. So, I guess the sense I’m getting from both of you is that this is a useful framework that encompasses a lot of where the security industry was going anyway and from both of your companies and previous companies’ point of view, something we were both coming at from the same direction and the new emphasize, I guess is on this continuous and more holistic approach. Michael, I guess there might be people listening to this who have never come across CTEM before, maybe that’s why they’re listening in the first place. It might be helpful before we go a little bit more depth into what makes up CTEM. What’s your sense of how it’s being used today? Like, how well defined do you think it is? How widely adopted? Do you get the sense that everybody in the industry is talking about CTEM or are we still very early in that Gartner hype cycle to use that phrase? 

(TC: 00:06:54) 

Michael Gianarakis: Yes, I think we are definitely very early stages and perhaps it’s the vendors that talk about CTEM a little bit more than the customers at this stage. However, I do see that growing because ultimately, this is the way whether they have a name for it, whether they came to it through Gartner, through their own evolution or through working with products like ours, right? This is the trend in terms of how people are shifting their perspective on how they manage exposure, and it is very much a practice, right? So, this is something that Gartner has pushed very heavily. Now, partially, that’s to try and avoid a whole bunch of vendors saying, ‘Hey, we’re a CTEM vendor.’ Because they want to make it clear that it’s a practice. I think they also want to use it as a bit of a Meta category for their analysis but putting all that analyst cynicism aside, it is the right way to think about it, right? You shouldn’t be thinking about these, sorts of, things purely in the perspective of tools. This is very much about how you manage your exposure. It is a framework for you to build around and adapt to your needs. It’s not overly prescriptive generally, it’s a bit more of a guide around the key areas that you should be thinking about and the key processes that you should be putting in place and so, I think in some respects there are many organizations that are coming to this on their own regardless of whatever they call it because as I said earlier, it’s a reaction to a need that they have, right? Point in time, siloed systems and processes that are ultimately very reactive and not without a heavy focus on remediation, operationalizing the issues and the findings. People who are doing it that way are struggling with managing this in their environments and so, they are looking for a new way. A way that’s going to be able to adapt to the current trends and the current needs that they have and so, I think many people are coming to it and have over the last few years are coming to it on their own, regardless of whether that’s come from Gartner formalizing it and putting it out there or they’re just figuring out that we need a better way and so, I think it’s getting there, and I don’t think it’s purely in reaction to Gartner. 

(TC: 00:09:13) 

Aidan Murphy: Yes, it’s an organic thing and then like we’ve been discussing, I guess, and Gartner’s put the term to it and it’s helpful and it makes it clearer for everybody. As Gartner defines it, there are five stages of CTEM. They are scoping, discovery, prioritization, validation and mobilization. Michael, maybe you can do the honors for us. Can you walk us through what each of these stages means in practice. 

(TC: 00:09:34) 

Michael Gianarakis: Yes. I will go through each of the stages but one thing to remember with CTEM is that this is continuous. One stage feed into the other and vice versa in a constant continuous cycle. So, it’s not necessarily a waterfall, it is a process or a practice as I mentioned earlier. So, starting with scoping, you know, scoping is really about fundamentally understanding what’s important to you and what’s important to your organization. So, it’s really understanding the scope of the CTEM practice and what it should cover as a baseline for informing the next stages in the process. Discovery then is once you understand what’s important to you, is understanding what you have there in those areas to protect, right? So, this is looking at whether it’s asset discovery, whether it’s discovery from a more data-based specific, you know, and understanding information that you have that you’re trying to protect, and it is really across the board to get your head around what you have to protect essentially. Then moving on is prioritization. So, this is recognizing ultimately resource constraints and other, sorts of, constraints that might exist to your organization. So, once you’ve figured out, ‘Okay, well, what’s the scope with this? What’s important to us? What do we have to protect?’ The next stage is to then take another lens to that in terms of understanding, ‘How am I going to approach that? What’s the most important areas to focus on and what are the more important parts of this process than others?’ And again, this is all very dependent on your organization, your threat environment as well as your resources and capabilities as well. And then ultimately, validation, that’s the next step. So, this is where you are identifying exposures and validating them. So, prioritization and validation, kind of, bleed into each other and you’ll often have, you know, these are the areas where exposures are coming up, right? And you’re taking those exposures, you’re running it through the lens of your prioritization, you’re validating these to then feed into the final step, which is mobilization, which is essentially, ‘What are you going to do to remediate these issues? And how do you know that they’re remediated?’ And then the whole cycle starts over again. Although, realistically, this scoping part doesn’t necessarily always happen continuously. Technically it should, right? But usually, it flows back into discovery and that’s where it happens, it tends to be in practice where the cycle continues but technically you should be thinking about your scoping element on an ongoing basis as well. 

(TC: 00:12:14) 

Aidan Murphy: Thanks, Michael. I think that’s a really, really great overview and Ben, I’m going to call on you next because I think when Michael spells it out, it makes a ton of sense but maybe just to be completely explicit about it, how does thinking about your security in these five stages and running through those five stages as part of CTEM, how does it help security teams? Is it a change for what they might have been doing before? How does it reflect their modern security needs? 

(TC: 00:12:39) 

Ben Jones: I think it is a reflection where you have this continuous element that your attack surface is constantly changing where you’re running things in cloud environments, where you’re spinning up new servers, maybe new services and websites and updates that the sooner you can discover if there is a particular issue, the safer you are because you’ll have people who are continuously scanning your site from the outside. So, that continuous part is really important. I think in terms of organizing these and thinking of it from a constraint point of view as well and what can be automated and what has to be done manually because this is ultimately what’s going to restrict you as a security team is how much you can get done and so, the scoping will obviously have to be realistic but you need to make sure that you cover everything that’s going to potentially be a vulnerability otherwise there’s no point of you doing any of this really if you just leave yourself with a gaping hole in your security and the discovery element will come down to the practice and discipline as an organization but realistically, you will have people spinning up new infrastructure, new services coming out within the products and maybe an attack surface which is far more amorphous now than it ever has been before. So, having that continuous discovery element in there is very useful and that’s something that you can automate and push out as part of a tool set which you’re using out there and then when it comes down to the prioritization and validation, this is more around with the resource constraint, what do you look at first and how do you ultimately cope with all of the alerts that you’ll be getting and so, you want to have a pure of a signal as you can and as little noise in there as possible. So, once again, you want to try and automate where you can to get the noise out of the signal but prioritization and validation to me feel very much around-, well, the prioritization is, which ones do we go on first, which is very much a resource constraint. Ideally, you would do everything all at once but that’s not going to be feasible. There’s going to be far too much coming at you to be able to do that and so, you need to have context behind you to help you prioritize those things and I think that’s where we started talking about some of the threat intelligence that can feed into that as well but ultimately, the validation will help give you a really pure signal in terms of what you’re looking at. So, there’s no point wasting time on threats which actually aren’t real and that is a major concern if people who are working on security at the moment is all of the alerts that you can be getting and the false positives associated with it. 

So, the better you can validate these exploits, the more you can automate that process, the more your team is going to be able to do to protect your infrastructure as a whole rather than dealing with these false positives. And equally again, when it comes down to the remediations, some of those things can be automated but some of those things are going to have to be manual. Thinking it through that lens of resource constraint and then what you can automate will save a lot of time with your team and so, when you implement that in real life, these are all the things that you’re going to have to consider as you get through that. 

(TC: 00:15:35) 

Michael Gianarakis: Yes, no, that’s a really good point and this is something that we talk about internally a lot. You picked up on signal, one of the core beliefs that we have is that low signal is endemic in security tooling and it ultimately reduces your security posture. There’s a bunch of stuff out there, you know, and there’s a little bit of this inside CTEM, some acknowledgment. To me, personally I don’t think prioritization and validation should exist as that separate, right? If we take identifying vulnerabilities, this is a core thing that our platform does, you’ll look at the common approach among security tooling and honestly, it’s the lazy approach where they’ll just try and match assets based on their characteristics up to a CV database and say, ‘Here’s a list of issues.’ It spits out far too many alerts and far too many false positive alerts while also allowing a lot of false negatives to exist. So, then you’ll have all these vendors come together and say, ‘Well, actually, what we’re going to do to help you prioritize is we’ll put in these various other metrics.’ So, it starts with CBSS, right? There was a study not too long ago where they looked at the common practice which is basic heuristics around we just prioritize everything that’s a CVS X or above and there was some research done that showed that that was no more effective than if they just picked the vulnerabilities at random to address and to fix. And so, then they go, and they evolve, and they say, ‘Oh, well, we’ve got this new system called the exploit prediction system.’ So, the EPSS system, which is designed to give you another layer of prioritization around, ‘Well, this one’s potentially more important because it’s more likely to be exploitable.’ But none of them think of the basic idea of, ‘Why don’t you just see if it’s exploitable when you identify it? And only raise it if it is actually exploitable.’ Which is the approach that we take and really, it feels like a lot of these solutions are simply solving problems that these vendors have created themselves. I think there is a better way with a lot of this stuff and again, bringing it back to this concept of, this is a practice, it’s not about tools but you should be looking at how your tools can impact the effectiveness of this process. 

Another thing that we talk about in the continuous element of this and the idea of being more proactive is a concept we call tool lag, which is simply based on the tools that you select, your ability to identify and remediate these and minimize your mean time of exposure is ultimately impacted simply because of the quality and the choice of tools that you have. While it isn’t the focus of CTEM, it does play an important role and I think the other thing which maybe we will touch on because we’ve spoken a little bit about the threat intelligence, a little bit about the ASM products and how they fit in, another thing that I would think of is also separating the idea of the practice and the idea of the tools. Gartner themselves but also, a lot of vendors will come, and they’ll be on one of two extremes, which is to say that, ‘We’re a CTEM platform and we do everything.’ Right? One stop shop. Whether you can trust that or not, whether that’s effective across all of it or not or flexible enough for your practice is another question, right? The other way of looking at it and Gartner is guilty of this is, so, to say, ‘Okay, well, these categories of tools will fit into each of these five stages of CTEM.’ If the scoping discovery, prioritization, validation, etc. but really, I think again, thinking of this as a practice, it shouldn’t necessarily be so clean cut. There are elements of the threat intelligence side of things, for example that fit into all five stages. Similarly, with ASM, that also fits into all five stages as well as other tools and practices. So, I think it’s important to consider those two concepts separately but also, how they slide in together. 

(TC: 00:19:54) 

Aidan Murphy: Yes, well, you’ve brilliantly led me onto what my next question was, it did occur to me while you were speaking, Michael and I know that you have this opinion that those five stages we’ve described, a lot of those are covered within what we would consider to be ASM. So, I guess, maybe let’s just start there and be explicit about it. What role does ASM have to play within this CTEM process, this framework? And can it be used at each stage and is there a role for it at each stage? 

(TC: 00:20:22) 

Michael Gianarakis: Yes, I mean, it’s a tricky question because there’s ASM as we define it and how we’ve built our product, which is actually closer to CTEM. So, it is built around, (1) the idea that this is a holistic, continuous practice and, (2) with a heavy focus on particularly the mobilization stage, right? The remediation phase as well as we’ve just discussed, very opinionated perspectives on things like prioritization and validation. ASM in the broader market context for better or for worse didn’t evolve down that path, the majority of the market looks at ASM as simply as asset discovery. I do think the market is shifting and is catching up, but I think things like the CTEM framework have spurred that a little bit but in terms of what we do with ASM, with our product is we fit into all those stages in some form or fashion, right? Obviously, there’s going to be a heavy predominance on some more than others. For example, I think scoping and discovery are, kind of, linked. So, the discovery side in terms of mapping out what you have to protect is definitely a key part of the platform and not only discovering the breadth of the attack surface but also, going to a certain level of depth as well. What’s running on those assets? What are the applications? What data is being showed? Are there any APIs? The full extent of the attack surface but scoping as we discussed earlier, I think is really more of an organizational question rather than anything that’s tool led, or tool supported. It’s like, what is important for you to focus on ultimately? And that’s an organizational question, but certainly discovery, definitely and then that bleeds into prioritization as well in terms of understanding some of the characteristics across the attack surface that might cause more exposure, that might be more challenging to deal with whether it’s your cloud attack surface which is generally pretty dynamic, your third party attack surface, which we’ve spoken about previously in terms of that being a real blind spot for a lot of organizations in terms of their exposure in their attack surface. And then from there, there’s the identification piece and identifying these exposures, which really fits in the prioritization, validation phase. Now, we combine those two to a certain extent. The way that we approach identifying exposures is very high signal. So, so we, for example, for vulnerabilities but for all of the different exposure types. We will only raise it if there is real impact already that we can demonstrate. 

So, for a vulnerability, we don’t raise it unless we determine that it’s actually exploitable in your attack surface in the context of all your mitigations, all your controls, all of the pre-conditions necessary, whatever the case may be, we determine that it’s exploitable and then we raise it and so, that cuts down on some of the headache and the burden in implementing a process like this because you’re not then having to take a large list of mostly garbage issues and then taking it through a prioritization layer first to cut that down to something more manageable and then going through another layer of validation to weed out all the false positives and the issues before you can even start looking at fixing this. We try and cut that cycle short through more intelligent and ultimately, and I’m biased here, a better approach there. And then the other key element of our platform in particular is-, you know, and we’ve spoken about this previously on other podcasts but one of the core ideas that we have at Assetnote, why we built our ASM in this way and our product in this way is we firmly believe that a list of assets is not the ending of itself. It’s what you want to do with it and so, the whole product has been designed with a heavy focus on, ‘How can you take these and embed that into your existing processes? Or create processes around this information to effectively operationalize this information and the remediation of these.’ Because if it’s not muscle memory, if it’s not baked in, if it’s not process driven and it’s reactive all the time, then you’re always playing catch up and that’s really, I think what the draw of CTEM is for a lot of organizations is that they hate that and they want to get ahead of this. There’s also, I’ve just spoken about the ASM side, there’s also a number of ways in which the intelligence piece comes into it but I’m sure Ben’s raring to go on that one. 

(TC: 00:25:04) 

Aidan Murphy: Yes, you’ve pre-empted me again, Micheal. Yes, so, Ben, you have mentioned threat intelligence already, but where does it fall within the CTEM area? Is it mostly around this prioritization? So, you were talking about establishing threats based on what you see out there in the world as well, or is there more of a role for intelligence to play here? 

(TC: 00:25:25) 

Ben Jones: I think that the threat of intelligence can go into discovery through to the rest of it. I mean, the mobilization is obviously depending on what you do with the data but with the prioritization and the validation, it can feed into that. I think that’s maybe, Michael, where we can go back and forth on this a little bit as well is in terms of how maybe some other companies deal with this prioritization element of it and then how we deal with it and how that can vary and how threat intelligence can also feed into that as well because my understanding of some of what other companies do is more based around heuristics and looking at maybe some level of context but it’s effectively correlation with some, sort of, level of filtration over the top of it and so, they’ll be looking at, ‘Okay, we have this particularly vulnerability. We know in the wild X number of companies are exposed to this, so it’s going to be a high level of exposure. The potential outcome of it is going to be pretty high, so we’ll push it up that way.’ And maybe they’ve seen some evidence of it being used out in the wild in some way as well and then therefore, they’ll then push this up as being something important for you to go in and address but I guess, ultimately, it is a bit of a sticky plaster for trying to work out whether it is a genuine threat to you or not and it feels to me that the best way of finding out whether it’s a genuine threat or not is to just go and test it and see if it is a real threat or whether it’s something you’re actually protected against, where it doesn’t really cause you a problem. So, I think from the audience point of view, it’ll be interesting to find out the specifics of how you guys do that in terms of the ASM product and then we can talk about some of the other areas and how threat intelligence can feed into that, but I think other companies do in terms of that prioritization element, do rely a lot more on threat intelligence than we do. I think it still has a place to play within that whole area, and I think even with those which are proven to be genuine vulnerabilities within your system, you’re still going to have to have some way of ranking those and also, getting some additional context behind that as well, but maybe if you can just talk us quickly through it about how you guys actually validate this stuff within the platform. 

(TC: 00:27:31) 

Michael Gianarakis: Yes, in terms of validating this and how we’re bringing the intelligence piece that we have, particularly the market leading dark web intelligence piece that we have into this process is like you said, the core of how it’s done today is essentially filtering, right? It’s filtering out a large bit of information and try to base it on very basic characteristics, you know, filter that down to a list of possible things that you might care about. I think one of the challenges with intelligence in general is that it’s not very actionable, generally speaking. It’s not able to be applied. It’s not really applied intelligence. I think that’s, sort of, where we come at it, you know, at Searchlight, very differently. One of the things that, you know, we look at when it comes to this sort of intelligence is it does map to all the stages, just as our approach with attack surface management and exposure management does, in general. I would actually go one step further, Ben. You said it doesn’t really apply to scoping. I think it can absolutely also apply to scoping, in terms of understanding the broader threat landscape, and having a deeper understanding of the broader threat landscape, but as it comes into, you know, discovery prioritization-, there’s simplistic ways which, you know, is that filtering mechanism, where it’s like, ‘Okay, we’re seeing generalized activity related to these vulnerabilities, in terms of threat actors. So, if you’re seeing them-,’ if the Assetnote is highlighting them as exploitable issues that exist today, on your attack surface, that certainly leads to a potentially higher level of priority, but you’re looking to take that, you know, one step further, and being able to utilize the deep understanding that we have of the attack surface-, not just your list of assets, but a real deep understanding of what’s running on those assets, the traffic to and from those assets. 

Then, taking that to provide an even more, I guess, personalized perspective on the threat landscape is another one, but I think the one that I’m most excited about is thinking about it, you know, coming out into that mobilization piece. I was talking to a customer the other day, and we were going through our zero-day vulnerabilities that we had discovered on their attack surface. We’re talking about it. We’re talking about how to fix it. As soon as they were done, right off the bat, they then turned around and said, ‘Okay, let’s look at our dark web products and see if there’s any breaches, or any issues related to this particular exposure.’ So, it’s not just about the front end of it, but the back end of that. What really struck me about that is, you know, using all our product suite together, but it was very much just candid, just the way that they do things. It’s just the process. It’s not, ‘Hey, here’s an issue,’ or, ‘Here’s an incident,’ and then we need to respond to it. It’s the day-to-day course of managing the whole life cycle of the exposure. It’s not just then fixing it, and addressing, you know, the immediate hole that we were finding in the platform, but then it’s going that next step, and being holistic about it, and just doing that as an everyday thing. I think that’s really the ultimate vision of how we can bring these two elements together, and how they can fit into all the stages of CTEM. 

(TC: 00:31:08) 

Ben Jones: Yes, I like the way that threat intelligence can extend in terms of that discovery as well, because the attack surface management-, you have your attack surface, which is your infrastructure, and everything around you, but there is an extended attack surface, beyond that, which is out of your control, really. So, this is other data that’s going out there. If you think of your employees, and your customers, and your supply chain, and other information that goes out there as also part of your attack surface-, the usual things that could potentially be used against you in order to get into your security-, so, finding out things around your employees, if any of their systems have been breached, which then can potentially get access into your system. Stuff that’s being published out there, on maybe Git repositories, or in other file sharing sites, or in open buckets, or anything like that, that could also cause you a security risk. So, feeding into that with the threat intelligence, in terms of the discovery, I think is powerful, and just looking at your entire extended attack surface there. Obviously, the vulnerabilities that lie on your system will be one of the ways in which they get into your system directly, but there are indirect ways in which you could potentially become vulnerable as well. 

So, providing the context and the background not just in that discovery, but then also, ‘Okay, well, how much of a threat at those things?’ Then to find some way of testing them, as well, is also really powerful. 

(TC: 00:32:28) 

Michael Gianarakis: Absolutely. I think this is one of the key things that-, where we think a little bit differently to everybody else, right? When we think about attack surface management products, as we’ve spoken about earlier, in terms of the market being just focused on basic asset discovery-, because we think about this as a practice, and we think about this holistically, it does encompass all these other areas, right? That is your attack surface. Your employees are an attack surface. All of the data that you have, whether that’s on assets and systems you control, or whether that’s in the hands of third parties, or various other SaaS platforms, like you mentioned GitHub as an example, that’s all part of your attack surface. These all have their own unique considerations, in terms of how you monitor for exposure, and how you then manage and mediate it. So, yes, there is that sort of concept of the extended attack surface. I think the only reason we need to call it out on a podcast like this is because a lot of other approaches in this space do demarcate that very heavily, whereas we think about it holistically, as all of that as part of your attack surface, and all of that needs to come in under a unified way of managing it, right? 

Again, going to the point of-, to me, that’s just attack surface management, but it’s also CTEM. I use those terms interchangeably, but that is the idea of it, is taking a broader approach to this, rather than being siloed and limited in each of these areas.

(TC: 00:33:59) 

Aidan Murphy: Another way I want to look at this, and maybe, Michael, this might come to some of your more controversial opinions-, because we’ve spoken a lot, now, about the benefits of the CTEM approach, but are there any pitfalls? I’m not going to say negatives, but any pitfalls, any traps you can see, maybe, organizations falling into if they don’t come about this the right way, or anything they should be aware of they’re just starting on this journey?

(TC: 00:34:20) 

Michael Gianarakis: Yes. I think the biggest one, ultimately, is something that we’ve already discussed, which is that looking at this purely as it’s a tools-based approach, where they’ll look at a big platform and say, ‘Hey, this’ll tick the box.’ That may be true. I mean, we’ve spoken about how, at Searchlight, we cover all of these areas in various ways, and our products do support all of the stages of CTEM. However, I think, for an organization looking to implement this, and get the most out of it, they still need to come at it from the base of looking at this as, ‘This is how we are going to do this going forward. This is how we’re going to manage exposure in our environment, for our organization in general,’ and treating it like the practice that it is, and that the tools and the platforms are just there to support that practice. So, starting from that, sort of, process-first perspective I think is the right way to go. That should also inform, you know, the tools and the platforms. As a core design principle, we build the tools to be very flexible, very extensible, heavily integrated into other tools and other processes, and it’s for that reason, right? It’s so that you can then take this and embed that in various ways, you know, that work for you, in terms of implementing a system like that. So, I think that’s, sort of, the first pitfall. 

The other one is-, we also touched on it earlier, just around the concept of, you know, picking the tools in this space, and the issues that come with the base approach to that, and where that might be in contrast to your goals, from a process and practice perspective, which is why it’s important for it to come first, right? So, you’re not bound, necessarily, by the limitations of the tools, in terms of how you implement your practice, because, you know, that’s the approach you’ve taken. If you take it as a practice-first, and a process-first perspective, then you can, kind of, craft that actually support that process. So, some of the pitfalls that we are just things like following, blindly, the output and the way that tools work, and saying, ‘This is me doing this.’ So, for example, the prioritization and validation piece, and not really thinking about that in terms of what you’re trying to achieve, but just being exacerbated, or being let down, I suppose, is a better way to put it, by the limitations of the tool. So, prioritization-, I spoke about the really rudimentary ways in which companies will approach prioritization, really basic, heuristic approaches that are based on simplistic, you know, heuristics. So, CVSS scores, even EPSS scores, they’re not really giving you much, in terms of supporting this process. 

So, look at different ways that-, whether it’s through a tool-, but, again, come at it from, ‘How do you want to approach this, and what are you looking for?’ Look at different ways that you can optimize this process, you know, without being held back by the existing tooling. I think those are probably the biggest ones, and then, ultimately, and finally, I would say-, I know we’ve been talking about CTEM and its value, and I do think it has value, but, again, go back to what’s important to you. Don’t just do something because it’s what Gartner are saying. The reality is that most of the Gartner analysts do not have any practical security experience. At the end of the day, you’re the ones that are on the ground dealing with this. You’re the ones that are dealing with the risk. It’s your job to manage this exposure. So do what works for you. Whatever you call it doesn’t matter, but, again, you know, coming back to the core principles of it, it needs to be something that is continuous, because attack surfaces, these days, are very dynamic and constantly evolving. It needs to be threat-informed, so it needs to be realistic for your organization, and matter to your organization, and it needs to be outcome-focused, and focused on being proactive and, you know, addressing these issues as quickly as possible, as a matter of day-to-day process. That’s really the idea. 

Whether we call it CTEM, whether we call it ASM, whatever you guys want to call it-, you might have your own name, internally, for the way that you do things. That’s really the idea. So, start from those principles, and then work from there, and I think you’ll be okay. 

(TC: 00:38:50) 

Aidan Murphy: I think it’s a really important point. I think a lot of what you’ve touched on there comes under that, which is-, like you say, this is a way that it’s been defined by Gartner, but these are quite-, like you said, it’s, kind of, good in its flexibility, but that also leaves a lot of scope for different interpretations. So, yes, like you say, mobilization, or prioritization, or discovery, these mean different things to different people, and it’s that thing of, like, practically-, it’s not a tick-box exercise of, ‘We’ve done prioritization.’ It’s thinking about, ‘What does that mean for my organization? How does it work best for me? What tools do I need?’ Rather than just saying, ‘We’ve ticked the Gartner box,’ basically. 

(TC: 00:39:25) 

Michael Gianarakis: Absolutely. One of the sayings that we have, internally, on the product team, that we really like, is ‘Progress not perfection’. I think that just applies to security as well. You should always be looking to optimize and improve your process, and your practice of exposure management, and really that’s the goal. So, I wouldn’t stress too much about, you know, ‘Are we implementing something like this perfectly?’ I wouldn’t think about it as a framework or a standard, in the sense of, ‘I’m at a certain level, and I need to get to another level, and I need to tick all these boxes.’ If that’s the take-away, I personally feel like you’re not looking at it the right way. I guess what I’m trying to say is, like, give yourself a bit of grace here, right? Managing exposure in an attack surface is hard, and it is complicated, and organizations, for the most part, are certainly resource-constrained. I’ve never met a CISO who wasn’t, you know, begging for more resources. So, take this as an iterative process. Think about these principles, and then build from there, and build as you go, and bed down the stuff that’s most important to you. Start with that scoping piece, and then build from there, and I think, you know, then you’ll start to be heading in the right direction, in terms of how to get the most out of this more modern approach. 

(TC: 00:40:47) 

Aidan Murphy: Brilliant. Ben, from your perspective, are there any pitfalls people should be thinking about, red flags or warning signs if people are starting on this CTEM process?

(TC: 00:40:54) 

Ben Jones: Well, more widely with some of this security stuff that I’ve seen in the past is where companies start off with their own tool-set. They build it out, and then they then have to manage those things. It is actually very difficult, and I can understand the temptation of wanting to do that, from a cost-effective point of view, but also just from a transparency point of view, in terms of what you’re doing with the tools, and building things out which are customized for you. The difficulty that you have is that just maintaining those code bases and those tool sets become a distraction for the team as a whole. Where you are resourced-constrained, it’s to be able to buy the best-in-breed tools, and then use your resource to then go away and apply those in the best way possible. So, I think it may seem more expensive, initially, to go out and buy these different tool-sets, but I think it actually saves you a lot of time where it really matters, in terms of the resource and the bandwidth that you have internally. So, using those tool-sets, making sure that you have the best information available. So, once again, some of these things can just be tick-box exercises, where you say, ‘Okay. Well, I’ll get some threat intelligence.’ 

So, I’ll just buy in some cheap dark web feed from somewhere else, and then I’ll just apply that, and I’ll say, ‘Okay. Well, I’ve got that one covered. I have the threat intel element covered,’ or you go and, sort of, deploy something around which is based on Shodan or some other tool-set, where it’s not scanning constantly. So you end up with those, sort of, snapshots in time. It seems continuous, because you’re constantly asking the same data the same question, over and over again, which feels continuous, but actually it’s not continuous, because the data that you’re asking the questions of is pretty old. So, I think making sure that you spend your resource in the best way possible, in terms of actually protecting yourselves, using the best tool-set, I think sets you up well as a business. Building out and maintaining your own tools is quite a complex thing to do. If you have the resource to be able to do that, as well as the security stuff on top, then, sure, go ahead and do it, but if you actually have a limited number of security professionals that can help protect your organization, I would go out and get those best-of-breed tools, which will give them the best start, in terms of being able to protect you, because, as we see constantly, and some recently, in the UK and elsewhere, these cyber attacks are crippling for companies. 

So, you just need to make sure that you can do the best job possible. As Michael said, you can’t get perfection within this, because it’s a constantly moving target. You just have to do your best, and you have to be ahead of the attackers, which is why viewing it from an attacker’s point of view is really important. 

(TC: 00:43:31) 

Aidan Murphy: That leads me really nicely onto something I did want to just ask Michael about, before we wrap up, which is about, I guess, measuring success. Again, looking at the e-book, which I will remind people we have for free in the show notes. Please download it. One thing that occurred to me is, I guess, that we’ve been discussing how CTEM solves a lot of modern security problems, or at least is an approach people can take. So, the fluidity of modern infrastructure, time constraints within your team, overload, specificity of intelligence to your organization, but one thing that I think stood out to me was that it also provides a way that you could measure success, and you could measure benefits to your business, without just pointing to the negative space and saying, you know, ‘We stopped an attack that never happened,’ which I think-, sometimes I think is quite difficult for security people to explain to the board, you know, the benefit of money not spent to a ransomware group or rebuilding infrastructure. So, Michael, how would you suggest that people go about measuring the success of their CTEM process, if this is the approach they choose to adopt? 

(TC: 00:44:37) 

Michael Gianarakis: Yes, it is tricky, and this is a very different discussion, in terms of, you know, how to prove your value, generally, and how do you prove the value of an attack that never happened? The reason the attack didn’t happen is because, you know, you are implementing this practice day-to-day, and you are doing it effectively. That’s the reason. I’ll park how you can convince other people that there’s value in that. 

(TC: 00:45:04) 

Aidan Murphy: Maybe a conversation for a different podcast episode. 

(TC: 00:45:06) 

Michael Gianarakis: Yes, certainly, but I think, for this, I’ll focus on the security team. Most security teams do understand where they’re at, and how to do this better, and it really is around, you know, how can we be more optimized and effective in this ongoing process? In the book, you know, we’ve got some stages around different, sort of, levels of capability of what that looks like. So, you can get a sense of what’s a more mature, I guess, implementation of this process. As I said, though, it’s not rigid. It’s not like a tick-box kind of exercise. This is more of a guide to help you, sort of, understand not only what you’re doing right now, but also, you know, what you could maybe implement next, and what could maybe be the next step on that journey to be more optimized. So, if you want, I’m happy to walk through those. 

(TC: 00:45:59) 

Aidan Murphy: Yes, go for it.

(TC: 00:46:00) 

Michael Gianarakis: Yes. So, starting on, sort of, the low end, in terms of capabilities, is what we’ve called the generic feeds capability, which is simply basic IoCs consuming threat reports, and just the volume of that information. It’s certainly better than not, but it’s not very optimized, right? It’s just raw information. Typically it’s not very practically applied. So, that’s, sort of, the starting point, and then the next step is asset-centric intel. So, it’s taking that intelligence, and it’s taking those IoCs, the threat reports, and then trying to apply it to what you have, and what you’re trying to protect. So, that’s the next layer above. It’s taking your attack surface, understanding what it is, and then, you know, doing a basic application of that to your attack surface. Moving up is really around, ‘Okay, now that we’ve got that, how do we get better at understanding what’s actually a problem in the attack surface, and what the actual exposures are?’ That’s where we start to look at exploit validation in an automated perspective, right? So, this is, rather than using those basic heuristics, like we mentioned earlier, actually having your process, and how you implement that process, be based on identifying real exploitable exposures that, you know, can be exploited by attackers, and that are on assets that are being focused on by attackers. So, it all builds on each other. 

That’s, sort of, the next stage, right? So, you can really, then, cut down the noise, and start to become a lot more proactive. The next phase above that is what we call research-driven detection. So, this is then, you know, taking a more mature look at the intelligence, the attack surface insight that you have, as well as the approach, now, to identifying exposures, and acting in more of a proactive manner, based on research-driven approaches, whether that’s through the product, and the nature of the product that you’re buying, or the service that you’re buying, but, again, taking it out of a product-centric perspective, that might be a level of customization. That might be a level of personalized to your organization, with your process, that’s based on this research. Then, the next evolution goes to the saying that I mentioned earlier, which is feedback-informed improvement. So, this is, sort of, that progress not perfection perspective. It’s constantly improving. So, then you take what you’ve got so far, and your process so far, and then every issue that comes up, everything that’s resolved, is then fed back, continuously, to improve the process, and improve the tooling, to make it more intelligent, and more effective over time, through its application. Then, finally, the final stage, is fully adaptive intelligence-oriented CTEM solution. 

So, this is where everything, for the most part, is as automated as possible. Automatic prioritization, automatic validation, having complete visibility, a system and a process that is constantly adapting based on what’s going on. So, that’s obviously the most mature element-, or most mature level that you have, where the process is, you know, working so well, it’s improving constantly, that it’s just, kind of, keeping up as a natural part of the process. It’s not something that you’re having to force, and adopt, and change. The natural process feeds into itself, so that it’s constantly improving. So, that’s, kind of, the ultimate goal, I suppose, that you should be working towards, but, again, no matter where you sit on this spectrum, it’s just a bit of a guide. Find where the gaps are for you, and find where you’re going to get the most value, and, you know, take it one step at a time. It’s a journey. It’s a not a destination. So, you know, think about what the next step. Think about where your pain points are, and what can be optimized in this process, and go with that, and then move on to the next one. The key here is, again, and we’ve stressed this point throughout the whole podcast, which is it’s a practice, not a tool. So, again, the practice is what’s important. So, find areas in that practice that aren’t working so well, aren’t driving outcomes that you want, and then address those. 

You don’t have to, you know, bite off everything. Just iterate. That’s the idea. That really comes back to that continuous part. That’s why it’s in the iterative, kind of, thing, because you should be doing this continuously. Don’t think about it, ‘I have to be perfect from the get go.’ Just build on it. As more capability, or more resources open up, you know, expand. Constantly look at, you know, the outcomes and the output that you’re getting, and look at ways in which you can address issues, and then you’ll get there, right? You’ll get to something that works for you, naturally, if you take that approach, and you think about it as, ‘This is the process I’m taking to manage exposure. This is the practice of exposure management,’ not just the classic, sort of, silver bullet thinking, ‘I’m going to buy an all-in-one platform from a gigantic vendor that’s going to do everything.’ It never works that way, because it’s never effective, and it’s not driven by what your needs are. It’s driven by the tool, and it should be the other way around. 

(TC: 00:51:24) 

Aidan Murphy: That’s really helpful. Thanks, Michael, for talking that through, and hopefully that gives the listener a, kind of, path they can follow. Just to tie things up, then, I’m going to be a little bit provocative. So, if we imagine that there may be a listener who we’ve converted to the idea of CTEM, it’s not something they were focused on before, but now they think this maybe helps them conceptualize some of their challenges they’re having, but also maybe some of the ways they were already thinking about their security practices, and the way they wanted to go, so this is what they want to do now. How would we advise them to start? I mean super-practically. Is it go away and read a bunch of Gartner papers about CTEM? Is it sit down with your board, and say, ‘This is my new approach’? Is it sit down with your security team? Ben, I’m going to, quite unfairly, just call on you to begin with. How would you say you would go about beginning with this? 

(TC: 00:52:14) 

Ben Jones: The reality is that, if they’re working in a security team, they’re probably already doing something of this. So, I think you can look at what you’re currently doing through this lens, think about it, once again, through continuous, and the various different elements of what can consist of your attack surface. So, I guess, if you start at the beginning of the process, you’ve got that scoping element. So, you can run that scoping process to make sure that you are covering what you need to, and then just follow it through. I don’t think this is a change, in terms of the way-, or a quantum leap in terms of the way in which security is approach. I think it is a good way of structuring some of the stuff which a lot of people were already doing. So, I would look at what you’re currently doing, and organize that into the process, and then look for gaps around that, and run that scoping process. I think, like I said, there’s probably elements of this which you’re already doing, but it may highlight some areas where, actually, you need to put a bit more focus into that particular area. Maybe you need to invest in a bit more here. Maybe you need to up the way in which you’re scanning it. Maybe you need to make sure that your scans are a bit more comprehensive, and looking at more of an extended attack surface. 

Maybe you need to look at the way in which you prioritize and actually take action on some of these things. As I said earlier, I think you’re probably already doing something, so you look at organizing it, structuring it, and then seeing where your gaps are. 

(TC: 00:53:35) 

Aidan Murphy: Brilliant. Well, you were talking about the gaps as well, Michael. Was there anything else you’d add to that, if someone’s just approaching this for the first time? 

(TC: 00:53:42) 

Michael Gianarakis: No, I think that’s exactly the right way to think about doing this, right? Nobody’s not doing anything for security right now, right? Everybody’s got a bunch of these elements already, in some form or fashion. Look at what you’re doing, and start at the pain points. Are you missing things? Are you always feeling like you’re reacting, rather than you’re on top of it? So, start there. Is it because you don’t have-, you’re constantly getting blindsided by issues on unmanaged assets, or assets that you have no visibility on? Well, look at ways that you can improve that. Is it that your processes are too slow? Why is that? Is that because, you know, the tools that you’re using can’t keep up with how dynamic this attack surface is? Look for ways to speed that up. Is it because you’re just drowning in alerts from threat intel programs, or other ASMs or vulnerability platforms, and the output is not high-signal enough? How do you address that? Focus on that. Once you start picking these things off, that’s when you start to elevate your maturity. One of the things that, you know, we’ve tried to avoid with the book is having a very prescriptive, kind of, step-by-step to the maturity levels, because, again, you might be more mature in other areas. You might be comfortable with certain things, and there might be areas that are gaps. 

That will be obvious to you, and then you can start-, this provides a bit of a framework with which to not only think about where those gaps are, but then how you might address those gaps, and optimize your process. I’d 100% agree with Ben. The best place to start is, look at what you’ve got, look at what your pain points are, look at the high level of the practice, and the ideal, and then just start to move various bits and pieces towards that. You’ll start addressing a whole bunch of problems, and, before you know it, you’ve solved a bunch of problems, right? So, that’s really the approach that I would echo as well. 

(TC: 00:55:43) 

Aidan Murphy: Amazing. That’s a very positive end. So, that seems like a good note to draw a line under this episode of the Dark Dive. A big thank you for Ben and Michael for joining me. A reminder, that if you’d like to find out more about this topic, you can download the e-book ‘ASM in the Age of CTEM’ for free by following the link in the show notes, where you can also find our contact information, if you have a question for us, a topic you’d like us to cover, or a suggestion for a guest. Please also remember that you can follow us for free on Apple Podcasts, YouTube, Spotify, or whatever app you use to listen to podcasts, to access our back catalog, and make sure you don’t miss new episodes as they’re released monthly. Until next time, stay safe.