Threat Exposure Analytics: Measuring and Communicating Security Risk

00:01 Hello, and welcome to today's Dark Reading webinar, “Threat Exposure Analytics: Measuring and Communicating Security Risk”, sponsored by Synack and broadcast by Informa TechTarget. I'm Brandon Taylor from Dark Reading, and I'll be your moderator for our discussion today. Master the art of quantifying and visualizing threat exposure data to drive security improvements and communicate effectively with stakeholders. Today's webinar provides executive reporting tips that connect technical findings to business impact. Security leaders will gain practical approaches for implementing analytics programs that transform exposure data

00:31 into actionable insights and compelling risk narratives. And on that note, I'm very excited to introduce our speakers today. I'm joined by Roselle Safran, CEO and founder of KeyCaliber, and Tim Nordvedt, senior manager, North America Solutions Architecture for Synack. And we'd like to go ahead and thank them both, for joining us today. And before I hand the virtual stage over to Roselle, I just want to remind our audience of a few things. So this is an interactive webinar. At the bottom of your screen, there are buttons that you can click to learn more about today's speakers, download a copy of the slides,

01:01 share this webinar via social media outlets, and participate in the q and a session that takes place at the end of our presentation. You can also use this q and a area to let us know if you're experiencing any technical issues, and our team will do their best to assist you. Without further ado, Roselle, the floor is yours. Thanks, Brandon. Welcome everybody to our discussion today on threat exposure analytics. So exposure is name of the game today, especially in this AI environment.

01:34 And there is much that can be done to make sure that it's being addressed in the most efficient way and being conveyed in the most efficient way. So that's what we're gonna dive into today. So just to give you a little bit of background, before we get started so you understand the perspectives we're bringing to this discussion. I am the CEO and founder of KeyCaliber. Our technology provides asset and AI visibility and context.

02:07 And before leading KeyCaliber, I was a co founder of Uplevel Security, which was acquired by McAfee. Both of my startups have been based very heavily on my previous practitioner experience. So before becoming an entrepreneur, I was in your shoes. And during the Obama administration, I was leading cybersecurity operations for the Executive Office of the President. And before that, I was in the division of US...

02:39 Of the Department of Homeland Security that was then called US-CERT. Now it's CISA. So I'm bringing lots of perspectives from having felt the pain myself and also now seeing the challenges amongst our customers. And I'll let Tim introduce himself here. Thanks, Roselle. So I always joke with people that I started my life as a computer nerd, you know, a little over forty years ago when I was first introduced to a Commodore 64.

03:09 So for the better part of forty years, I've been living at the command line playing with ones and zeros. But, professionally, started my career in cyber with Booz Allen Hamilton as a consultant. Spent a number of years supporting lots of different federal agencies. Pretty much every aspect of security you can think of from the, you know, active penetration testing side to the, kind of deputy CSO management roles. The full spectrum there. Then about five years ago, I jumped over the commercial side, on... With Synack, penetration testing as a service company,

03:41 as a solutions architect, more recently moved into a leadership role. Then as of last week, Synack, we have officially merged with NetSPI, become a full spectrum offensive security platform for our customers. So what that means is that, you know, with, you know, Synack and NetSPI and Synack, I say with security leaders, help them understand what they need to know about their exposure, use and test and validate what's real, and then how do we communicate that to leadership board members and etcetera, which we're going to dive into a little throughout this conversation.

04:13 So I think before we kind of get too far, Roselle, you know, we talked about analytics and data and the first thing that comes with people minds is noise. It's just an overwhelming amount of stuff. So maybe you can start off kind of lay the groundwork of where this noise problem hits hardest for our audience. Yeah. So this is the big challenge that many folks are dealing with on the tactical side. So you have lots happening, but not all of it demands the same attention.

04:44 And some of it is just noise, whereas a small fraction is really the signal that needs to be addressed. So part of why this develops is because we all have multiple tools in our security stack, and they've got their own unique outputs. And it just creates this massive volume of data about exposures and just alerts in general. And often, organizations don't have it all

05:18 pooled into one spot, so you've got these siloed data sources and reports that may or may not be machine readable. And this leads to duplicated alerts or uncorrelated alerts. So the team ends up looking at the same type of issue multiple times. And on top of it, when an alert comes in, the vendors often have their predefined

05:51 severity, and that severity is just generic across the board, and it doesn't have any type of business context or any type of context that's related to the organization that... That's seeing this alert. It's just very generic. And so the result of that is then the teams, they can't prioritize based on what's most impactful to the organization.

06:21 And so then that leads to this unproductive use of resources. You're you're chasing what doesn't need to be chased. You're missing what you do need to address. And also, the metrics that are generated from all of this end up just not being useful to improving the situation. So these are some of the challenges that folks are dealing with today, and I'm sure everyone in this call has felt at least some of these problems firsthand,

06:52 if not all of them. So, Tim, what does all of this noise then actually look like from an offensive security perspective? Yeah. Again, we're probably reiterating stuff that everyone on this call deals with on a day in and day out basis. And kind of within the offensive security realm specifically, it's kind of interesting the title of your last slide was finding signal within noise, and that's kind of one of our core beliefs at Synack is how do we use offensive security to find that signal in the noise

07:23 because the vulnerability space, is very noisy. These are just some industry stats here that in 2025, you know, just over 48,000 new CVEs were published, which is 20% growth from the previous year. In the Verizon's 2026 breach report, they reported that remediating critical vulnerabilities rose to forty three days. Previous year was thirty two days. They also reported that, of their dataset, they were only seeing twenty six percent of [unclear vulnerability term; check audio] being fully remediated,

07:53 which was down from thirty eight percent the previous year. So the backlog is growing faster than teams can fix it because in reality, when everything is really critical, nothing is really critical. And for all the reasons you just mentioned, like teams just don't know where to start. It was about a month or so ago, I was talking with a recent, new customer that just onboarded with us. One of the first questions we always ask them is try to align on understanding what their SLAs are and how they look at vulnerability remediation. And they're still using just a CVSS based remediation,

08:23 and they only had SLAs for criticals and highs. They didn't even apply SLAs to anything mediums or lows because they had so many criticals and highs in their backlog. That's all they had the bandwidth to fix. And we're going to touch a little bit on throughout this conversation on why we need to start looking at that differently. But it's this noise is what makes it so hard to explain upward because we have so much information and so overwhelming. It's hard to communicate to leadership. So maybe you can take it, Roselle. And how does all this land with leadership as we look at communication?

08:56 Yeah. I mean, you're you're spot on. It becomes a big challenge to get it right. And part of it is, you know, as security folks, like, we talk in cybersecurity jargon. But folks that are not technical, they don't understand the jargon. They don't understand the metrics. The concept of a vulnerability folks may understand high level, but when you start using the term CVE, then that isn't even understood.

09:27 And the reporting doesn't focus on those high level KPIs, you know, key performance indicators that matter to leadership. They... The nuance and the minutiae doesn't resonate with them. What they need is that really high level. And, also, when we provide metrics that are showing that the team is really busy but doesn't relate to the outcomes that leadership

10:00 cares about, then it just looks like work, and the value, the outcome that the leadership team is looking for is missing. And part of what is particularly important for leadership to see is not necessarily all the detail about what's happening at one point in time, but the general gist of, are we getting better, or are we getting worse? And if the reports aren't showing that trend over time,

10:32 then it's hard for anyone to contextualize what's happening. And on top of that, if the metrics and the KPIs are not related back to business context and therefore business outcomes, then, again, it just doesn't resonate because it just seems like, well, this is a security issue. Is it really gonna affect the business? I don't know. Not necessarily, so I'm not going to spend my time on it.

11:04 Whereas if we can tie what's happening from a security perspective to what matters from a business perspective, then that gets leadership's attention. Because they ultimately are gonna end up dismissing any type of data that doesn't clearly connect to, Here's how it's a concern for us as a business. It's not just cybersecurity's lane,

11:34 it's the whole business that needs to be aware of this issue and be dealing with this issue. Tim, what reporting mistakes do you often end up seeing? Yeah, I definitely see quite a few of them because it's one of my roles as a solutions architect is working with customers from that consultative perspective. And again, how do you take offensive security beyond just a compliance check the box exercise but use the output to

12:04 reduce organizational risk and highlight where to focus efforts? And there's three common problems that I see on a regular basis. And problem is not really the right word because it's not I'm not saying we should stop doing these, but there's better ways to communicate this to leadership, and there's time and place to report each one of these. And you've already touched on some of these, like the first one being siloed totals. You know, reporting metrics based off of tools and teams, not a single view, not an organizational risk overview. It's kind of not tying things together. It's there's a better way that we can, you know, report that.

12:35 And like you mentioned, the delta since last review. I don't think I've ever met a single CSO that I've talked to where he doesn't ask, you know, how does that compare to last quarter? Like, they always want to know how are things are trending up, trending down. We have to be showing the trends. Another one is averages. MTTR is a big one. Everyone loves to report on MTTR. Again, it has its value, but when you really think about it, MTTR, it only counts what got fixed. So the old hard findings that are taking a long time, that's not always accounted for in MTTR.

13:07 [Unclear; check audio.] I just threw out there is my opinion. It's a recent metric. I've started to kind of get behind, somewhere they're starting to use it, half-life. For those that aren't familiar, half-life metric is basically of all your open vulnerabilities, how long does it take you to fix half of them. So that way, it accounts for those harder to fix ones, those long tail ones, and it's a reoccurring basis. You continually update the half-life of that. And then when you fix these averages remediation, I always say you need to add context in there,

13:37 like what... You know, what's your coverage? Like, how much of your attack surface are you actually testing? What's the frequency testing? Because testing 10% of your risk on an annual basis versus testing 80% on a quarterly basis, again, that's going to provide a much different context to averages. And the last one is compliance. Again, I'm not saying that we should stop reporting on compliance because it's something we're required to do, especially depending on the industry you're in. But the example I always give is that if you went on to a car lot and you're shopping for a car and you found a car you

14:07 like and you asked a salesman how much does this cost? If their response is, well, that's a medium yellow, you'd have no idea how to interpret that. And that's in a sense how sometimes how we report these metrics to leadership. They think in financial terms and we report in qualitative terms. It's just that, like you said, we need to connect back to the business value. So I know the analytics and data we're talking today are kind of around exposure management. So just to make sure the entire audience is aligned with how we're shaping this conversation,

14:38 maybe you could dive in and define exposure management for us, Roselle. Absolutely. Absolutely. So, yeah, exposure management in cybersecurity realm, it's a relatively new term, only a few years old. And what it generally means is it's the proactive and structured approach to identifying, assessing, prioritizing, and mitigating relevant cyber risks.

15:10 So it's it's it's a whole workflow and the opposite of just saying, let's try to tackle all the critical CVEs because there's so much more that is encompassed in the concept of an exposure, and it's that whole life cycle of identifying it and figuring out is it something that we need to focus on and then actually tackling the problem. So some of the cyber risks that are generally included

15:40 in this concept of an exposure. Well, certainly we all know about vulnerabilities. Similarly, misconfigurations often identified at the same time. Vulnerabilities are identified. Those are exposures as well. Then we have identity based issues like overprivileged access. Somebody getting... Or identity, maybe not even a human,

16:10 getting access to way more than is absolutely necessary. There's the problem of weak credentials, so not having MFA, or them being leaked and being on the dark web. There's publicly accessible or over shared data. We've all heard plenty examples of S3 buckets that ended up being public facing when that was not the intent of the organization. And Internet facing assets in general,

16:42 we come to think of as being exposed. Someone can find them, you know, on Shodan, for example. There's also third party access and dependencies, and we've seen over the years plenty of major breaches that have been the result of a third party being compromised and then that leading to compromises in the supply chain. Then there's the concept of security control gaps or

17:12 security coverage gaps, where you have an environment, you may have some tools that are supposed to be securing that environment, but they're not fully deployed. And this is something that we see all the time at KeyCaliber because we're we're looking at the asset level. So we're seeing here are all the assets that don't have EDR on them. Here are the... All the assets that don't have a vulnerability scanner on them. You can't even get to the point of knowing the vulnerability

17:44 exposures if the asset doesn't even have a vulnerability scanner on it. And then, of course, we have the challenge of shadow IT, shadow AI, where you don't know about it. So certainly, there are coverage gaps because you... You're not managing it at all. So what I'm really interested in hearing from you, Tim, is how these exposures combine into the paths attackers actually see, taking that offensive view of it.

18:19 Yeah. Yeah. It's interesting. You mentioned path because in reality, like, attackers, they're not just choosing one thing from the list. Like, they're gonna use a combination, put things together to find how to get access to the system they're going after. The other thing I think is interesting when I looked at your list, you know, you listed things like misconfigurations, overprivileged accounts, leaked credentials, just basic Internet facing. Those things aren't attached to a CVE. So if you're relying just on scanners to determine what your risk is, you're going be missing a lot of things because scanners

18:49 score; attackers chain. So an attack path, the way I define it, is a chain of real findings often unremarkable alone, but when you string them together, you can do something that matters. And so it's not just a matter of just mapping these attack paths. You have to validate which ones can actually be used to reach, you know, critical systems. And there are several reasons I think this matters when we're discussing exposure management is one is risk lives in the combinations. We already mentioned that a scanner alone is only going to define so much of your exposed risk.

19:20 It's the real risk that lies in those combinations. Next thing is we're going to kind of talk about this concept of choke points. Choke points is where you can once you've mapped your attack path, you can potentially find root causes or issues that allows you to block multiple choke points with one remediation, one fix. Because as I'll touch on a couple of slides, remediation is a fixed cost. We only have so many resources towards it. And the last one is we need to shift our mindset when we start thinking in the terms of attack paths is not just is this asset vulnerable,

19:52 but the better question is can this be used to reach what really matters? Can this be used to reach something that will make an impact on the business? And if you want to jump to the next slide, just a real quick example. At Synack, we published a blog series called Exploits Explained, where members of our SRT, our Synack Red Team, our researchers that do the offensive work a couple of times a month will release a blog on a unique or novel exploit, something interesting they found in a customer environment, completely anonymized,

20:22 but the attack details there. And back in July, Metin Yunus Kandemir released this one, which I think kind of demonstrates this philosophy that, you know, he found four different separate issues. One, he found a stored HTML injection in internal web app. By itself, that risk would typically be rated low or medium, something that most organizations do not pay attention to because by itself, can only do so much harm. He also noticed that an ordinary user within the domain had the ability to add a DNS record.

20:52 Again, that's not necessarily a risk. This was actually by design for the environment. He's also found that by default, Windows silently sends credentials to host it believes to be in the intranet. And then lastly, directory and certificate services in the default configuration accepted that relay credential. So only one risk. The other three are just default configurations or by design environment. But put them together, the exploit is fully explained in the blog, but the researcher was able to gain DCSync privileges,

21:24 which is effectively keys to the entire domain. So again, just reiterating, the first link is the only thing a scanner ever would have found. The other three are kind of going back to your list, misconfigurations, overprivileged access. You know, none of them are exotic exploits, but each one are enabling condition and a critical attack path that we should pay attention to. So that's just an example there. There's plenty more I could go into, but, know, Roselle, you know, in today's day and age, don't think we can have a security talk without kind of

21:55 touching on AI. So maybe we can take a minute and talk about how does AI just affect the overall landscape when we're talking about exposure management.

22:37 Sorry to jump in, Roselle. Don't think so. I think you are on mute. I'm sorry about that, folks. So I was just saying, yes, AI is a big additional factor that we have to take into consideration today. It's something that five years ago, we didn't have to think about at all. But now it's a part of any environment that we're working on. So to get started, with some of the new sets,

23:08 we have sensitive data going out the window to the AI environment du jour, whatever the employees are using. This is a big concern for folks across the board. We see this with our customers a lot where they wanna see which assets are using AI because they are concerned about this. In addition, you have agentic AI where it can be accessing sensitive data,

23:38 either because it's been given the credentials to and the permissions to, or it's deciding to, you know, venture out on its own. And having overprivileged access given to agentic AI is a concern that we're we're seeing pop up very frequently these days, because an employee may just decide, okay, I want to give this agentic AI access to x, y, and z,

24:10 not thinking about the fact that it doesn't really need access to all of that. It needs access to maybe a fraction of it. And likewise, credentials could be given to or become accessible to agentic AI. So, again, data perspective, identity perspective, and AI can take actions on its own. And so that's leading to another set of potential exposures to be concerned with.

24:43 And we all know that AI, on occasion, tends to hallucinate, and that can also lead to it taking actions or doing an incorrect activity. And then an area where we're seeing a lot of concern, and this is one of the areas that KeyCaliber has been finding its customers are really interested in, is understanding when a SaaS vendor has AI embedded into its product and maybe

25:16 training on their data. So with a lot of these SaaS vendors, the contracts were signed two years ago before they had AI in the product. And so today, they're giving the SaaS vendor access to lots of data, and they don't know what's happening to that data from an AI perspective. Of course, just like any other technology, AI tools need to have security controls on

25:46 them, and those controls can often be missing and be a coverage gap. And sometimes that's just because they're shadow AI. The security team doesn't even have a handle on whether they're in the environment or not. Again, another issue we're we're seeing very common, in today's environments. So, Tim, you know, with all of these AI related challenges,

26:17 how is this impacting the volume of exposure findings that the organizations now have to deal with? Yeah. And I'll I'll kind of run through these numbers in a minute, but it goes back to what we were talking about earlier with noise that now with, you know, AI, be able to do risk discovery and vulnerability discovery, it's just adding to the noise. Know what? I always, you know, one of my favorite conversations recently is that I was at a conference a couple months ago talking to a CISO of one of our current customers.

26:47 And at Synack, we have an agentic AI pentesting offering for our customers. And he kinda... We were telling him about it, and he kinda interrupted and says, look. You know, I don't have enough resources to fix all the vulnerabilities I know about now. He says, like, I... We're we're barely keeping, you know, our heads above water. If you're gonna tell me that AI is gonna come in, just find more vulnerabilities and add to the list and tell me more things I can't fix, I'm not interested. What I really need is understanding where to focus my efforts. If AI can come and help me prioritize,

27:17 know where to fix first, then I'm interested. But just adding to more vulnerabilities, not interested. I think that's kind of the state of the industry is that, you know, AI has cheapened discovery. AI can easily find vulnerabilities, but remediation has remained a fixed resource. So in some aspects, remediation is almost a little slower and a more protected resource. So just an example to run through these numbers here, looking at one of the most capable vulnerability finding AI models in public view and what happens through the

27:48 discovery process. And I'm talking about Anthropic. You know, Anthropic, they publish disclosure dashboard for bugs that were uncovered by Claude Mythos Preview and some of their other models. And this is snapshot as of October 2. So as of today, these numbers are probably already outdated, but just to kind of give you an idea, so this Claude Mythos has already discovered just shy of 30,000, bugs and vulnerabilities. There's two routes those discoveries can get to

28:19 maintainers because this is focused on open source software. One is they send them to outside security firms for review. So they've sent just over 6,000 of these to security firms for review. Of that, 5,600 were confirmed as valid, so true positive, so tracking just shy of a 93% of true positive. They can also send them directly to maintainers. So of the two paths, a total of 6,100 have made it to the various open source maintainers, and about 500 have known to be

28:50 patched upstream. So we go through this process, and there's still things where you treat this as a floor, not a final count. But I want to highlight this isn't just a false positive story because if you look at the ones that go external, we're tracking almost a 93% true positive rate. That's more than nine out of every 10 findings are legitimate, but the pattern is clear, and Anthropic even calls this out themselves in their review that human triage is the rate-limiting step. That's kind of where the bottleneck is. And to be fair, this is open-source code maintainers, which is mostly maintained by volunteers,

29:21 and Anthropic even admits that most enterprises fix things a lot faster than open source. So don't treat these as a strict funnel that this is gonna remain true in most commercial and enterprise environments. But the point remains true that finding got cheap, fixing didn't. So the value moves from just finding vulnerabilities, finding risk to actually understanding how to prioritize them. Where do we focus our efforts and what do we actually fix first? So an agentic AI can help with coverage and speed, but we still need humans in there for oversight.

29:52 So when we talk about prioritization, one of the things we need to move beyond is just a severity based or a CVSS based prioritization. We need additional context. So, Roselle, maybe you can jump in and start talking through some of what is that additional context that we need to prioritize. Absolutely. Yes, I look at context as being the name of the game when it comes to exposure management. You could think of it as, you know, any house in the in The United States, it could be...

30:22 It could have a risk of tornadoes or hurricanes or snowstorms. And, you know, as a homeowner, maybe you can... You wanna focus on all three of them. And, yeah, that could be challenging and cost a lot of money. But, you know, if you're you're in Florida, you wanna focus on the hurricanes. If you're in Kansas, you wanna focus on the tornadoes. If you're in Michigan, you wanna focus on the snowstorms. And it's the same kind of concept of you wanna focus on

30:54 what actually matters for your particular situation. And so that's that's security context and that... That's business context. And from a security context perspective, there are a number of additional elements we can bring into the fold when we're looking at any one given type of exposure. So first off, exploitability, something we in the industry been focusing on for the last few years.

31:24 CISA has its Known Exploited Vulnerabilities lists. There's also FIRST's EPSS score. They're the ones that we know actors are actively using and therefore become a high priority because it's not this obscure little issue that no one's heard about. It's something that people are working with building exploits against today. Also, there is reachability.

31:54 So going into that attack path analysis of, okay, is it Internet facing so an attacker can see it right off the bat? Or is it something that it can easily hop to once the attacker is in the environment? Then there's the concept of accessibility, which is, you know, sometimes related to this attack path analysis. You can potentially have asset a. Can the attacker get to asset b if they have any

32:26 type of credentials? Do they need to have domain access, or could any identity get them get them to that new hop point? And this is why the concept of defense in-depth is so important no matter what the size of your organization is because you wanna make sure that you have layers and layers of defense, like the castle. It's not just the moat. It's the moat and then the door and then all the guards.

32:56 It's all the components together that keep the attacks at bay. And so understanding, is there any defense? You know? Or is it once an attacker is in, it's a free for all. They can get to wherever they need to go. Or do you have microsegmentation and zero trust? You have ways to block in the lateral movement. And, of course, threat intelligence is important for understanding how attackers usually navigate

33:29 and the tools that they're likely to use and the attack paths they're likely to take. And in doing dark web analysis allows you to understand, has the identity already been compromised? So now there is that accessibility right off the bat. And, of course, there's there's the concept of historical activity, and I feel that this often gets neglected. And this is looking at the past incidents that have occurred in the environment,

33:59 seeing who are the attackers that did that, what was successful in the past, so that you can leverage that as a way of understanding what might be happening in the future. And so I know that CISA has now made some of this, this concept of applying security context part of a federal mandate. And, Tim, I know you have great insight into to how all of that shapes up.

34:29 So I’ll let you convey some of that information here. Yeah. Before I jump into this, I just have to shout out, I appreciate underexploitability how you included EPSS score. It's one that, as I talked to a lot of customers, they're not as familiar with that metric. And I've been a big evangelist of it. So if you're not familiar with it, definitely take a look at it. We've actually included that in our platform to help provide our customers with some of that contextual risk. So EPSS, big fan of that metric.

34:59 But, yeah, for Binding Operational Directive 26-04, CISA has made a move to codify some of the categories you talked about on the last slide into a mandate. This was released back in June of this year. It's about prioritizing updates based off of risk. It binds federal civilian agencies to specific SLAs, and it actually retires CVSS only prioritization. So when it comes to SLAs for discovered vulnerabilities, it uses the four signals listed on this slide.

35:31 One, is it publicly accessed... Is it publicly exposed? Is it a vulnerability on CISA's Known Exploited Vulnerabilities catalog? Can it be automated? Because, obviously, with AI, automation can be scaled very fast. And then what's the technical impact? Does it allow partial access or full control over a system? And the more risk a vulnerability carries across those four signals, the shorter the deadline. With... If it hits all four of those criteria, then it has a three day SLA. The lowest risk vulnerabilities can wait till the next

36:04 scheduled upgrade, and then there's several in between. And CISA even stated that part of the rationale behind this is that they wanted to include AI's effect on the volume of vulnerabilities that we discussed earlier and how fast attackers are moved. And I find this interesting because, you know, while most of us, you know, many in the audience probably don't work directly for a federal civilian agency, CISA does set a lot of standards that eventually make their way into the commercial as, you know, we... CISA KEV being a perfect example. What started as a federal standard now is adopted by most

36:36 organizations as this is signal we should pay attention to for prioritization. So even if we don't work for a federal civilian agency today, I think it's something we should pay attention to because either board members will start asking about it or it'll be adopted into various audit frameworks we'll have to start to adhere to. And so while this doesn't necessarily point to pentesting, you know, which is what I do at Synack, reason I find this interesting is because it points in the same direction because you have to prioritize based off evidence of real world risk.

37:07 It's not based off of theoretical or how scary CVE looks. It's understanding where does actual risk apply and where should we focus our efforts. And so testing is one of the ways that you can identify, you know, proactively before, you know, CISA comes and tells you to fix it, how can we get ahead of the threats here and identify where our risk lies. So, CISA, what they've done here is they've tried to provide some technical security context, which you talked about on the previous slide there and codify it. But we need more than just kind of the technical context.

37:37 We also understand how does it impact business. So maybe, Roselle, you can kind of take the next step and talk about what some of the business context, business impact we should be aware of. Yeah, absolutely. So you could think about it as, you know, security context is the likelihood side of the risk equation. And then the other side of the risk equation is the impact, and this is the business context side of it. And it's really important to incorporate this because at the

38:07 end of the day, this is what the business cares about. And so if you can make that connection and bridge security operations with business operations, then you're you're speaking the language of leadership, and you're gonna be able to convey what you want about cyber risk being business risk. So there's this concept that... That's been gaining traction over the last few years, which is this concept of a minimum viable organization,

38:39 sometimes called minimum viable company or minimum viable business, same concept. And it's the smallest set of essential infrastructure and operations necessary to continue serving their customers or performing the required functions for the organization. So it's the bare essentials where if everything ends up being a mess, what you need to get back up and running immediately,

39:11 or better yet, don't let go down in the first place because this is where it's going to have the most severe impact to the organization. And generally speaking, it starts with a critical business process. And this is going to be the layer where leadership may be able to articulate what that is. It's okay, this process, this is what creates our revenue flow. They're not going to be able to get into the minutiae

39:42 of what that entails. They can only speak on that high level. But as a security folks, we need to be able to get down to that asset level to be able to take action. And so often, those critical business processes are a collection of critical business applications, and those applications are made up of critical assets and or critical SaaS vendors that are part of that. So being able to

40:14 create this organizational view of here's how these critical assets come together to form a critical business application, which then combines with other critical business applications to create this critical business process. That's where you get to the heart of being able to correlate the business context with what's going on the security side.

40:46 So now let's bring in the pentesting component of this. So, Tim, how does pentesting help assess the risk to the minimum viable organization? Yeah. So I mentioned earlier, you're kind of using testing to filter between theoretical risk and actual risk. And I think pentesting is one of the ways we can do that. And I think a lot of it is just the way you described MVO. I think that's the way and something we do with our customers,

41:18 how we should start looking at scoping penetration tests. Because more often than not, you know, we've been doing this for years that when I sit down and scope a penetration test with security practitioners, they usually start by the asset. Like, they know that they're what they refer to as the crown jewel, like what is the URL that hosts the web application that drives all the revenue for the company. Let's start with that. But the problem is, if you start at the asset level, you might not get all of the supporting APIs, databases, identity providers, third parties,

41:48 integrations, etcetera. Whereas if you treat scope and a penetration test the same way you treat, you know, defining your MVO, you can get a truly holistic test of the entire ecosystem to understand what the real risk is versus the theoretical risk. So understanding and defining the whole ecosystem behind it as opposed to just the individual asset, which is part of your asset inventory that has the label critical attached to it. So

42:19 once we kind of define the risk and we understand kind of, you know, prioritize what's real, what's not real, we have to quantify it. We already talked about it because most boards and boards, they think... More leadership, executive leaders, they think of financial terms. So how do you take, you know, this computer risk, the cyber terms and stuff and start transitioning it to terminology and things that we can actually quantify with leadership, Roselle? Yeah. So this is the important step for getting down to what you're

42:49 gonna actually tackle is being able to get it sorted out from a quantification perspective. So first off, this requires being able to essentially normalize the data and have all of the exposures and alerts, everything that we've talked about that's a type of exposure, all being pulled together and then correlated so that you can deduplicate and combine into one particular exposure when

43:20 it's not four different ones, it's just the same one being seen by four different products. So that's step number one. And then you layer in all that context, the security context, the KEVs, the EPSS scores, whether it's reachable, etcetera, as well as the business context. Is this a critical asset, a crown jewel, or part of a critical business process? And how can you navigate to that?

43:52 So what are the path that an adversary can follow to reach those important aspects of the business. And once you have that in place, then you can do risk calculation. And like I said, risk is a really basic equation. It's just likelihood times impact. You have security context, business context on the exposure. And so you can create this risk score,

44:22 and that will allow you to operate because then you can see, alright. Well, the ones that are really high risk using this score, these are the ones I'm going to tackle first. And it's baking in this concept of business risk because you've included the business context while you were doing this process. So scores work really well, especially when you're comparing against other exposures.

44:54 Now, in some cases, you may also be able to take those scores and translate them into financial risk. Now, this is something that really depends on the organization and whether they're they're at the point that they want to quantify financially. But even if they're not, even if there's no dollar sign in front of it, there needs to be a way to weigh which exposures are gonna get tackled and which aren't.

45:27 Because to all of the points that Tim mentioned earlier, you're not getting into everything. You're getting into a small fraction of it, and you want that small fraction to be what is most impactful to the business. So with that said, when we start to bring AI into the equation here and AI is doing some of this scoring, how should teams treat that output, Tim?

46:01 Yeah. So the last bullet point you had on your previous slide was, you know, tackle the highest business risk first. The question is who decides which risks are highest? And I think there's... As I'm talking with customers out there that are starting to kind of take this approach, a lot of them are starting to introduce AI into helping to gather and correlate all this information, which is tremendously valuable. We've already talked about the noise issue. It's a lot for a human analyst or practitioner to sit down and do this all on their own. So AI plays a tremendous value.

46:32 But I always tell people and remind them that AI is a useful first draft but a risky final one. Because as we already discussed, our remediation cost for most organizations is fixed. It's a very valuable resource. So before we start deploying our remediation resources, we want to make sure we're prioritized properly. And this is just an illustrative example I threw in there. But, you know, if AI is looking at all the information and it sees a publicly exposed web server that has multiple high and critical CVSS scores attached to it, it might prioritize that one,

47:02 where what it may not realize is kind of to your context point, there may be security controls deployed that block access to that service that has that CVE attached. But maybe on another hand, there's an overprivileged service that's linked to that web server rated as a medium that AI might throw way down on the list because of what it has access to. So it's always making sure that you review the output. You review the output with a human perspective because as powerful as AI is, AI still does not fully understand

47:33 business context, what's important to us as a company, what our risk appetite is. And so while AI is a great tool, we should use it accordingly. So one of the things we talked about already is, you know, we just talked about remediation resources. So when we talk about a finite resource, like what does remediation look like in the world of exposure management? It's just not, you know, pushing patches and stuff.

48:04 There's more to it than [unclear; check audio]. So how do you define that, Roselle? Yeah. Well, so at the end of the day, remediation is the name of the game. We have to get to the point where, you know, we see these exposures and we're dealing with the ones that are the biggest concern. And so it's all about focusing on priorities. You know, this extends far beyond security.

48:34 You know, with any aspect of folks' lives, you know, you can't get to everything. You gotta focus on what truly matters, and that's what's high risk to the business. It's what you can identify as the root cause of a problem, you know, not just treating a symptom, but getting to... It's it's this issue of us not... Of having overscoped credentials, is this something that we need to address as a one off, or is this just a system...

49:05 Systemic issue? And then, of course, attack path chokepoints. The more we can get to that, the more we're we're taking care of a whole slew of problems all in one process without having to address each one individually. And taking action is... It could very well be patching. That's still big aspect of closing exposures. It could be reconfiguring when something is misconfigured.

49:37 From an AI perspective, it could be adding guardrails, so, like, certain databases aren't accessed or certain tools aren't used. It could be addressing those coverage gaps so you have that full that security stack fully leveraged within the environment. Could be implementing compensating controls, you know, when you can't get to a vulnerability, can't patch on the machine because of the risk of the downtime, what can you layer in as defense in-depth to

50:10 instead handle the situation? And from an access perspective, there's always reducing the scope of an identity, or removing access in some cases, or hardening it with MFA and the like. And then there are times where the work that's gonna need to be done to remediate is not going to be something that the security team has the ability to tackle.

50:40 And in those cases, it's really important to be able to work well with the IT team, the networking team, the cloud team, and provide justification of here's why we need to address this. And having that quantification goes a long way in saying, look, this is a high business risk, and therefore, we need to address it, get the right owners involved, track how they're doing with actually remediating, and then just confirming, making sure that everything

51:13 happens, as they said it should. So in terms of finding and fixing these challenges, these exposures, Tim, how are you finding that teams can avoid just dealing with the same issues over and over again? Yeah. And I'm I'm only gonna spend a minute here. I'm... I wanna watch the time here and be respectful of the audience.

51:44 And I know you got some more couple more slides to get through, Roselle, that have some valuable information. But I think it's important to touch base on this real quick because as I work with teams on remediation, what we find is very common is that the programs are a treadmill where they find, triage, submit, fix vulnerabilities, and then find the same things all over again. It's just this reoccurring kind of this whack a mole is what we refer to. And so we always recommend four things to our customers to kind of get out of this and kind of like you mentioned, fix root causes, fix those choke points,

52:14 like how to prioritize. So one is pull the output, like so from all across all silos, teams, scans, tickets, pull them together into a central repository. From there, look at find patterns, you know, group by cause, vulnerability class, component, teams, pipelines, configuration source, a variety of ways you can start batching this. Next is fix upstream. Once you identify the pattern, look for the upstream root cause, like where is that coming from. Is it secure defaults? Is it shared libraries?

52:44 Is it pipeline checks? Is it training that needs to be addressed kind of at the root cause? And then lastly is measure recurrence. Like, if you've done the first three, you want to make sure that it truly is fixed and doesn't keep coming back on the same basis. You know, the example there is if you see six injection flaws in six apps, that's a chance to sit back and think, well, maybe that points to a shared library or reoccurring development pattern as opposed to just opening six ticks and fix... Six tickets, fixing them, and calling it a day. I know one of the things we've touched on a couple times with

53:15 Roselle is just kind of deltas over time. We don't want to just show static metrics. So how do you show progress over time and what do you recommend? Yeah, so the reporting aspect is essential for any organization. And just a couple of items related to that. First of all, there are internal metrics for your team related to how you improve, which are separate from the external metrics that you provide to leadership about how you are providing value.

53:49 And then there's the current posture look of here we are, here's the snapshot of what's happening today versus that trend over time. Now current posture, important for what you're you're doing on a tactical level, trend over time is what leadership cares about. And then you also wanna distinguish what the team is actually doing versus what the technology is just finding. And so it comes down to being able to

54:19 look at overall risk level and progress towards reducing that risk level. And that could be financially reducing that risk or just systematically and empirically reducing that risk. And you want to show that you're doing this burn down of the critical exposures, the high exposures, and what that means when you do tackle that. And so I've provided here just the high level

54:49 groupings of the types of areas where you want to report. But I just wanna make clear, you don't wanna get into minutiae when you're talking with leadership. You just wanna say high level, look. We have this risk level that we're currently at. Here's today, and here's where we wanna be in six months, in twelve months, and here's how we're working towards it. These are the levers that are getting us to where we wanna

55:20 work towards. But, ultimately, it's all about this overall risk level. It's not about any one of these just being hyper focused on. And so, you know, with that, I'd love to hear, Tim, your perspective on something technical like an attack path and how that can be articulated in a way that's

55:50 clear to leadership. Yeah, it's kind of building off one of the last points you made there. We don't need to get into the details of the minutiae. Like, they don't need to know the specific service accounts that are provisioned and the open ports and everything. But a clear way to get to them, kind of going off that concept of attack paths. And in this illustrated example here, I said crown jewel because this is an example we talk to customers about from a pentesting perspective, but you can replace this with MVO. Like, what is that defined minimum viable organization and how

56:20 many verified validated paths do you have to that organization? Let's say it's three and you've identified a choke point. Maybe this quarter you show we've identified three paths to our MVO, and next quarter you can show how we fixed the choke point. All three of those have been remediated against. And so it's showing progression over time. And again, keep it simple. We don't need to get into details when we're communicating this up. One picture, one number, one sentence, that's all we really need to portray to them and show that delta over time.

56:54 So, yeah, how do you communicate this to stakeholders? What are your recommendations, Roselle? Yeah. So I'll just get you to the high level of this of, you know, with stakeholders, you first need to understand what their risk appetite is because everything needs to tie back to that. And you have to have this aspirational state of what good looks like because that's point b. That's where you're you're going towards. And you discuss all those components like that pie chart I had as part of the whole program,

57:25 and it's a high level of the whole program. Don't include any technical jargon that you're going to have people glaze over that. Align it with the business, the MVO, the crown jewels, the business objectives. Try if you can to align it with how your peers are doing because that gets the competitive edge going, and folks are gonna say, well, oh, if our peers are better, then we need to up our game.

57:57 Make sure the presentation is really clear and consistent colors of red, yellow, green. Don't don't use it for other purposes, but besides what it's known for. And make sure that when you're interacting with other departments, you're showing these expectations of what you expect them to be able to provide and timing, and have that all sorted out before you start interacting with them with policies in place.

58:29 So, Tim, how would you say you could carry the same message across to these engineering and IT teams and these other departments that you have to interact with. Yeah. So I know the main purpose of this is kind of communicating the leadership, but the same way we need to communicate back to the people that are managing these assets and these resources we're talking about. So in the same way we're trying to relate business context up to leadership. We need to relate that business context back to the people that

58:59 own these assets, the people that are responsible for it because they need to understand the business because business context provides urgency and help them understand why we're asking them to do what they do. So maybe we've... We got like a minute or two left here, Roselle. Maybe you can just define some keys to successful implementation here. Yeah. Absolutely. I always like to end with this concept of key level... Keys to successful implementation. Make sure that you understand the risk appetite of leadership.

59:29 They... That has to be articulated first. And get their buy in for everything that you're working on because then it greases the skids for when you actually have to work on something. Add that security and business context in all of the work that you're doing and use a consistent and automated process for incorporating that context. Make sure that you're prioritizing the exposures based on what matters to the business. And what you report on is, again,

1:00:01 from that same lens of what matters to the business. Start very small, don't try to boil the ocean, and then build on that. And as with everything in cybersecurity, you're going to continuously be iterating and updating as you go along. I think, Tim, you have some other great points to add to that. Yeah. I mean, I think we can probably just skip this and kind of let them read it, because I'm just kind of reiterating the points that you already made. There's just a different perspective here because I know

1:00:32 we are at time. Yes. We are at time. So thank you, Roselle and Tim. You know, Dark Reading. We really appreciate both of your time and expertise on today's topic, really driving home AI's impact on threat exposure in addition to the management and remediation of these threats. And before we go, actually, I'll pose one question, to you both, and this is kinda to piggyback a little bit off of Reginald's question in the chat. But I know during your presentation, Roselle and Tim,

1:01:02 you know, Roselle, you touched on an MVO example that kind of focused on, accounting for foundational assets. And I know Tim's pentesting background had him kind of speak more so to scoping the process, not the asset. And so, as Reginald said, in the chat, you know, can you speak more to what a MVO is or what is the MVO? Minimum viable organization. So it's the least amount of functioning that still has to function in order for the business to

1:01:33 keep up and running. So you think of it as if we have this totally terrible situation and everything else is going down, what still needs to stay running? Thanks, Roselle. And Tim, is there yes. Definitely. And is there anything you'd like to add before we close here, Tim? Yeah. The only thing I would just add is kind of, you know, in the pentesting world, we kind of find it as, a business critical process. So kinda looking at it more than just at an asset

1:02:04 perspective, but how does the entire... What supports the entire ecosystem? So don't just test the IP or the URL. Like, what's... Everything that could potentially touch that because everything that touches it is a potential access point to that process and could be exploited. So... Yeah. Just look beyond just the asset. Definitely. Thank you, Tim. And that is all the time that we have for questions today. So we would like again to thank, both Roselle and Tim, for their time today. We'd also like to thank our sponsors, Synack, as well as everyone in our live audience.

1:02:34 We really appreciate your attention and participation in today's broadcast. Within the next twenty four hours, you all will receive a personalized follow-up email with details and a link to today's presentation on demand. Please feel free to invite your colleagues and peers who may have not been available to listen to the live event. This webinar is copyright 2026 by Informa TechTarget. The presentation materials are owned by or copyrighted by Dark Reading and Synack, and the individual speakers that you heard today are solely responsible for their content and their opinions. On behalf of our guests, Synack and the Dark Reading team, I'm Brandon Taylor.

1:03:04 Thank you all for your time, and we'll see you at the next Dark Reading live webinar.

No lines match that search.