From Discovery to Risk Reduction:
Operationalizing CTEM
Walk through all five stages of Continuous Threat Exposure Management and see how security teams can turn exposure visibility into a repeatable process for reducing risk.
Visibility is only the beginning.
CTEM is designed to create a continuous process for understanding exposure and deciding what to do about it. In this webinar, Ricoh Danielson and Avery Rozar walk through that process from both the business and technical sides.
Ricoh covers Scoping, Discovery, and Prioritization, including how organizations can determine what matters to the business and focus security resources accordingly.
Avery then covers Validation and Mobilization, including validating whether exposures create real risk, coordinating remediation, finding root causes, and verifying that the risk actually went down.
See what your exposure looks like.
Start a 14-day free trial of TrollEye's CTEM platform.
Transcript
Read the complete webinar transcript or select a timestamp to jump directly to that point in the recording.
All right, welcome everybody. Thank you for joining us for our webinar on operationalizing CTEM. Today we're joined by Ricoh Danielson, Enterprise CISO at CorroHealth, and Avery Rozar, CEO of TrollEye Security, to walk us through all five stages. Ricoh and Avery, would like to introduce yourselves briefly for us?
Go for it, Avery. Alright, yeah, I'm Avery Rozar, CEO of TrollEye Security. Started our operations in two thousand nineteen, focused on penetration testing and pen test as a service. And a few years ago we've transitioned to full CTEM platform as well as services.
Awesome. Hey folks, my name is Ricoh Danielson. I'm the Enterprise Chief Information Security Officer. I preside over all the products for CorroHealth and Virtix Health and using the product to actually help us mitigate quite a bit of threats and get ahead of quite a bit of things.
Excellent. All right. So Ricoh will walk us through the first three stages of CTEM, kind of focusing on the business side, how you take your assets, focus on what matters, prioritize what matters, and then Avery will take validation and mobilization, which is our specialty as a company. So Ricoh, go ahead and take it away.
So scoping. Let's talk about scoping, right? So when we look at scoping, it's a matter of understanding your product and your environment. If you say deploy everything at any given time, man, that's a lot of money and you're gonna fatigue your people. You need to be very, very precise with regards to scoping. Okay, so if we have an AWS environment, what is that AWS environment? Do we truly need X amount of logs? Do we truly need X amount of telemetry? And if we don't, then why don't we? Why do we? Right? And that provides the overall definition of scoping.
In regards to curtailing that, like actually really focusing in on that. So when we define it, it's a matter of understanding the risk lens. Okay. So let's just say everybody has S3 buckets. Got it? No problem. And when we define the S3 buckets and we define who's accessing it, why is it being accessed, what type of environment, at the best of your ability, you should have some sort of ability to risk rate it. Right. Now, if you don't know, throwing the dart against the wall does and does not help. But at the same aspect, what I'm realizing that the platform does is kind of says, hey, based upon these attributes right here, this is how your risk approach is going to be looking at from a risk lens.
And at that point, remember, red is bad, right? We can actually say, hey, we need to go address red. And then the way we do that is dollars towards risks or efforts towards risk. The other part is environment drift, right? I want to say 99% of people, 99% of developers, DevSecOps, even CISOs, do things with the right intention in mind, but sometimes do them in the wrong manner. And that causes environment creep, environment drift.
And what that means is that what you truly conceptualized something with and started with has kind of scaled outward, right? So when it comes to the bigger question, what are the assets that we do have? What are the assets that we don't have? That's the question I've been asking recently. Like, show me what we see, but show me what I don't see. And the reason I'm asking that is because I don't know my sector's on fire and then I need to be able to point my labor pool, my talent pool in the right direction. And that actually gives me the ability of who gets which ticket and which avenue is it being pursued.
So let's go with discovery, okay? So when we talk about discovery across the environment, you want to be able to expand the knowledge and the visibility of exposure across your vulnerabilities. The best way to do that is doing vulnerability scan, right? And not just kicking off a scan saying, no, we're good to go. Because I've been in organizations with like, well, that's good, right? But the bigger thing is, what's your exposure management, what's your vulnerability management around identity? That's a big one. Because remember this. About eighty percent of threat acting, they wanna compromise an identity.
Whether it's a service account, whether it's a business account, or whether it's a personal account, right? And then on top of that, one of the things I always say is blast radius. If you don't understand the external surface attack framework and you don't have a good visualization on that, you don't know what you're up against here, right? The surface attack understanding is gonna give you a path forward, an attack path, right? And this is where the threat modeling comes in and plays like, hey, how can we put this together to show us more than likely this is how we're going to get attacked, this is where we're gonna get attacked, and this is how the TTPs and IOCs are gonna be leveraged against us and the CVEs.
And that'll give you a good depiction of more than likely which threat acting group is gonna try to hit you. And at that point you can kind of inverse and say, okay, based upon our application threat modeling, based upon our exposure management and our attack framework, we need to shore up our cloud and our infrastructure. Now, one thing I always say, absolutely you're right, it's not a matter of lacking of data, it's a matter of lacking of vision, right? Where does it need to go? Who needs to be on point? And then the other part of that is, what tools are available to the most common person to make things happen?
The execution part is a big part of discoverability, right? Because you can say, hey, we discovered a bunch of bad stuff, and if nobody takes action, then you just have information just sitting there, right? Finding some things in isolation kind of tells a story of like, hey, I have something wrong, but the same aspect of it, it's a matter of, what do we do with it? As an executive, you have to understand that once you have something of finding, you have a risk, and then how does that affect your business?
And if you don't think it's gonna affect your business, I would recommend just going and take down your application and see who yells real quick. And then also on top of that, if you don't have any risk per se, go ahead and hit the off switch and see how much money you lose. And the reason I say that is because there is no bigger lesson learned than a point of pain. Point of pain, I've seen breaches, I've worked over 1500 different breaches, I've seen incidents over 250 incidents, and every one of those has been painful enough to make a decision saying, hey, we need to have these discoverable items and map them to critical business functions to measure some sort of business impact.
Now, something that is not being said today is that there are new vulnerabilities all the time. All the time. And then there's new changes all the time. I mean, with AI now here, our point of vulnerability and the point of exploit now, I think, is less than four minutes now. That means we have to get it that much faster, that much smoother, four times faster than the threat actor and also AI. And how do you get ahead of that? And the best way to kind of do that is actually establishing relationships, right?
And not only internally but externally, because I'll give you an example. In a past life I saw an organization develop relationships outward and said, I gotta do these things, gotta do these things. Let's go ahead and integrate our environments together. And nobody was paying attention to the outliner of these other vendors that are slowly connecting. And in a past life, studying some of the biggest breaches, this could have been mitigated if, one, a relationship was developed. And number two, that authentic conversation of new assets, new changes were actually brought forward.
So as we hit into prioritization, you can't fix everything, right? If everything's a priority, then nothing's a priority. So you're gonna have a high volume, right? When I was working a project for one of the biggest casinos in the world, I've never seen sixty-three million vulnerabilities in my life. And it was wild. And so the best thing, I remember sitting with the vulnerability manager, it was a matter of like, hey, the best thing we can do is prioritize here because if not, you may be swinging for the fences and you might not hit something.
So one thing I always correlate prioritization with, back in the Army, right, I had the privilege of being a 249 machine gunner, right? And it's like accuracy by mass volume. Well, that doesn't work here, right? You just can't go spray and pray. You have to be very precise, almost like a sniper, right? And actually break down those silos and break down those different elements of remediation for capability. Now, while some avenues, some attack frameworks, some different type of severities, findings, and whatnot may have different severities or the same severities, right? The biggest thing is they have different outcomes.
Okay. So patching over a .NET framework might have a different patch, might have a different decision and also impact of patching over like Tuesday or something like that, or an application that's completely out. So it really depends, right? So one thing I'll have to say is during your vulnerability management aspect, you're trying to prioritize these days: does it truly apply to your organization? I've seen Microsoft say, hey, there was a vulnerability on a ship and you should do that. I'm like, I don't do shipping, right? So it makes no sense to do it. So whenever you're looking at these different decisions, how are you prioritizing those different things?
So yeah, and this is one thing I kind of live and breathe by, is meaningful risk. Everything's a risk at any given time with every given fire. Got it, no problem. But the question is with these culminating factors here of exploitability, attack path, business continuity, and threat intelligence, do we truly have a vulnerability? Do we truly have meaningful risk? Or is it just loud noise to distract us? Because the worst thing we need to do is apply one of our analysts, or better yet our senior architects or senior security or forensics or incident response, to something that just doesn't matter, right?
We have to have something that's very, very meaningful. Another approach is risk ranking it, right? If you rank the risk and you rank the statements, you're not just planning to reduce it, you're actually prioritizing, risking it, and then also saying, hey, here's our point of illustration. Something to be very mindful of during this time is that it's your responsibility to rank these based upon your business need. If you take somebody else's, then it might be a little bit different.
Awesome. Thank you, Ricoh. So I'll take over here. Validation. So this is definitely where we start specializing. And you move from a theoretical risk to something that actually has evidence. Were you actually able to exploit this vulnerability? And you have to ask yourself a number of different questions whether or not this actually is a valid risk outside of just a theoretical vulnerability that may or may not need to be patched or configuration may need to be changed.
Couple questions. So does the weakness actually exist? And is it reachable? So you could have a vulnerability that shows up on a vulnerability scan, but when a threat actor actually goes and tries to access this vulnerability, it gets them nowhere.
It doesn't move the needle at all. So those kind of things obviously would not need to be prioritized as high as things where you can actually reach the vulnerability, like for instance, an open S3 bucket or accessible RDS database that's accessible to everybody all over the world. And then the next thing is can it actually be exploited? So you may have an open RDS database, but are there any breach records that show any level of access?
That give you any level of access, can you brute force it? Or is there an actual exploitable vulnerability like Apache Struts? Something that can actively be exploited and you get some type of shell. So that kind of takes us to the next one. If it is exploited, what can happen next, right? Can you get access not only to the system itself, but is there data on that system that could potentially be used against the target organization?
Maybe there's not, but maybe you can pivot from this exploited asset to another more vulnerable asset within the organization. So you start moving from the DMZ directly to an internal network layer that then has more accessibility. Because a lot of times organizations, they may have really hardened firewall rules on the outside, but once you breach that first level of rule set, on the inside they've got nothing.
So then once you're inside, you can start pivoting and start scanning and start doing other things that really take you deeper into the network and maybe not even be seen at all. So every step strengthens or weakens the case for action. So the next step is automation. Either automation or human validation.
Don't position this automation versus humans. You do need to do both, right? So a lot of times what we do is we'll have automation on a lot of the low-level stuff. So then my pen testers can actually focus on more complex attack chains that maybe they chain three or four, five different vulnerabilities together to actually reach the golden goose inside the network. Humans have the ability to really focus on business logic more so than an automated tool might be able to focus on.
Humans, they can actually pivot better from, hey, I've got these set of credentials and I've got these emails. Let's start a phishing campaign now that then allows you to dig deeper and possibly get in another avenue, whereas some of the automated tools may not have that. They just kind of go out, they hit a couple of scans and then they're done.
So one of the biggest issues that I've seen in the career as a pen tester is when a so-called security analyst will give a developer a long list of vulnerabilities. They'll say, hey, your application is vulnerable to all of this. You know, fifty thousand different SCA and SAST vulnerabilities. Whereas it actually may not be. There may be a lot of false positives. So have you actually validated? Have you actually gone through the code to determine whether or not this is an exploitable function? Is the function even being used in the application?
Not only that, is it actually accessible from the UI or API? The worst thing you can do is pass it off to engineering and they have to then do all the legwork. Their time is valuable. They hire you, they hire us to determine whether or not these vulnerabilities are actionable vulnerabilities. And then once we tell them, hey, yeah, we were able to exploit this vulnerability, we got a shell, we actually pivoted over to your database servers, and then we were able to start dumping all of your databases. Well, that is definitely something. Something that needs to be fixed.
So when you start sending unvalidated vulnerabilities to engineering or development teams, that really does create a lot of friction between the two teams. So one of the worst things you could do is have your security team and your engineering team at odds with each other. They stop listening to you. You just become white noise at that point. You're just another cog in the wheel and I don't care what you say, and that doesn't help the organization at all.
So better evidence always changes the conversation when you can prove that this is actually an actionable vulnerability. For instance, even like dark web. I've seen some dark web analysis where it just says, hey, your email address showed up in this breach four years ago. You're like, okay, well, what am I gonna do with that? Well what we do is we actually can take that information and can we use that for phishing? Can we escalate from phishing over to some sort of actual credentials?
Does the dark web information actually give us credentials that are usable? Even if I give the organization credentials that we know look legit but they're not usable, that's not actionable. Now, could we use that later? Sure. We can use that in a later attack and possibly come up with different password schemes that the company may be using and determine, okay, well, next change is gonna be one, two, three, four, or something of that nature. But until it's actionable, it doesn't necessarily matter.
So instead of the scanner says this is critical, you want your team to demonstrate why it actually matters, why the vulnerability makes sense to spend their time and their cycles on. So validation does not mean everything is escalated, right? So you can exploit a vulnerability from the web on a system that gets you nowhere. That doesn't make sense to actually fix.
Whereas if you exploit a vulnerability on a system and then you can pivot deeper into the network and then get more information that you could use in a different attack. And then you start branching off and you start scanning from this, say, printer. I got access to a printer. Well who cares? Well, some people may care. And what happens is then I can start digging in and start scanning and start looking deeper into your network and the security team may not even know because they're thinking, well, I don't care about this printer.
It doesn't matter. What's a printer gonna do? But then you find something exploitable deeper in the network and then you pivot from that printer onto an actual database server or web host that has credentials to your database and then you start dumping data, exfiltrating data. So those types of vulnerabilities have a higher priority. They're easier to validate. They need to be prioritized to actually be fixed.
So, is the risk real enough to the organization that you need to act on it? Mobilization is where CTEM turns identified and validated exposures into measurable risk reduction. So this is the last mile of CTEM. Finding and prioritizing risk is often easier than getting it fixed. Security identifies the risk, but security doesn't usually own the asset. Business or technical owners have to accept the responsibility for the work, and then engineering determines how and when to make the changes without disrupting the business.
Operations executes the remediation, and then security will revalidate that the exposure is actually gone. And the challenge here is coordination. Every handoff creates an opportunity for the remediation to stall. Mobilization is about turning security findings into coordinated action and ultimately measurable risk reduction. So root cause is incredibly important.
Mobilization shouldn't always happen finding by finding. Multiple findings often share the same underlying root cause. 47 tickets can mean 47 investigations, 47 handoffs, and 47 opportunities for the problem to come back. CTEM lets us group related exposures and remediate the systemic issues. Fix the template, fix the configuration, the process, or the control one time, then validate the entire affected estate.
The goal is risk reduction at scale, not ticket closure. So for example, if you don't have true patch management in place and you're going one by one to update individual servers or workstations, you're spending a lot of time and a lot of resources. Where if you take a step back and you decide how do we actually fix all of our patches with automation utilizing a tool like Ansible or Terraform, something of that nature, you're gonna spend your time more wisely by doing that.
Also something like SQL injection or cross-site scripting. You can fix those line by line in the code, or you can write a single shared input validation class that's used across the application and even multiple applications that do the same thing and fix that across the board versus spending ticket after ticket after ticket. So we don't measure success by how many vulnerabilities you've fixed.
You measure it by how much exposure you've eliminated. So here you want to group related findings by asset, technology, control, configuration, or pattern. You look for the shared condition behind them. Ask yourself what would cause these findings to come back over and over again? You identify the upstream source, whether that's through configuration, template, process, code, architecture, or control.
And you validate that fixing the source eliminates the related exposures. Root cause is the thing that you fix once and you don't have to keep fixing the symptoms. So remediation closes the ticket, it does not always close the exposure. So applying a patch or changing a configuration is an action, not proof that the risk is gone.
The remediation may fail, be incomplete, or not even address the actual exposure. So you want to retest the exposure the same way you validated originally. Verification should answer one question. Can this still be exploited? CTEM closes the loop by measuring the outcome and not simply whether work was performed. A closed ticket tells me somebody did something. Verification tells me whether it actually reduced the risk.
So you retest the actual environment, you recreate the original exploit path, check the broader estate, confirm the root cause was removed, not just the symptom, make sure the fix persists through deployment, development, and configuration changes, and you verify remediation did not create new exposures. Revalidation means proving the original path to the risk no longer exists and not simply proving that change was made.
So here Ricoh is going to share his experience working with TrollEye Security and provide a customer perspective on the CTEM journey.
So overall, you know, TrollEye is actually providing a need, what the market needs right now. And what is that? That's continual pen testing, that's continual threat adversarial mitigation, advanced adversarial threat and mitigation, and also a proactive approach. And being a CISO myself, I can just say that from an executive perspective, I can kind of rest my mind now at this point saying, you know what, that box is checked. I needed that. The tool, the product, the people behind it know what I need from a product perspective, from a security perspective, from an infrastructure perspective, an incident response threat mitigation perspective.
And wholeheartedly I can say that TrollEye is actually doing an amazing job meeting those needs.
Thank you very much, Ricoh. So yeah, if you want to, just jump online. You can go to our website. There's a start a free trial section page and you can jump in, create an account and get a 14-day trial. We have CTEM packages that start as low as $995 a month. They go up from there. You add more modules, add more services, and we would definitely love to help you out with your threat exposures and partner with you.
Find it. Prioritize it. Validate it.
Remediate it. Prove the risk went down.
Put the process from the webinar into practice with TrollEye.
Start a 14-Day Free Trial →
