Transcript for "Cyberhaven Unlocked: Content Inspection Rules for Success":
Hello, everybody. Thanks for joining today's session of Cyberhaven unlocked. My name is Amy Garel. I'm the director of professional services here at Cyberhaven. And today, we're gonna be focusing on content inspection. But before we get started, though, I wanted to share a quick reminder, to mark your calendars for next week on February 3. During our, live launch, we will be showcasing the first public demo of our unified AI and data security platform, built for the realities of 2026 and beyond. If you wanna be among the first to see how a unified DSPM and DLP platform can change the way our organ your organization protects its most critical data, please save your spot by using, the sign up link that we are gonna post in the chat right now. Thanks, Pat. So for today oops. There's the sign up. For today, this session is meant to be very practical and hands on. We're not just talking about features. Nick is gonna walk through how this works not only in the product, but build it live in the console. So by the end of this session, you should have three clear takeaways. The first is how CyberHaven identifies sensitive content. Second is how that content is organized into datasets. And third, how those datasets are then used in policies to monitor, warn, or block based on the actual content, not just the file names or metadata. The goal today is to show the end to end flow from the initial idea of this sensitive data in my environment all the way through to a real enforcement outcome. Most of the time will be sent inside the console. As I mentioned, Nick will explain why behind each step, not just the mechanics. If you follow the pattern we walk through today, you should be able to stand up new protected data types quickly, reduce noise in your environment, and move toward enforcement with confidence. So with that, I'll hand it over to Nick Dobbs, one of our senior analysts here at Cyberhaven, to jump into the console and start by grounding us in where content inspection lives and how all the pieces fit together. Awesome. Thanks for the intro, Amy. Much appreciated. So let me share my screen with everyone here, and we will get right into things. Okay. You should see our ProServe staging tenant here. Now the first thing that we're gonna wanna do, since we landed in risks overview, we're gonna wanna navigate over to the settings page and then open up the content matching rules drop down. So you're gonna see three things here. The first is content identifiers. Alright? Content identifiers are where all of your pattern based content inspection rules live within the console, and it's gonna be our primary focus today. There's also exact data match rules. Those are, actually a locally hashed database of specific values of interest, things like Social Security numbers or VIP account numbers, that are used to generate extremely high fidelity matches. It's very precise, but a heavier workflow and not a focus here today. Possibly, it could be in a future session. You'll also see document tags. This is a separate, tracking system that we have, interfaces with, you know, Microsoft Purview and soon Google labels. And it's meant for enhancing content classification through meta beta metadata based identification and custom document labeling. It has its place, but, again, not a focus today. So stepping back from the pure mechanics here, I want us to align quickly on the mental model that'll be informing our session today. So when we're thinking about creating an enforcement strategy for a new class of data within any CyberHaven deployment, There are really four layers that matter, and they always go in the same order. First one is going to be what you see here on the screen, content identifiers and their respective rules. This is where you're going to define what sensitive entities look like within your data, things like keywords, rejects, proximity context, confidence levels, everything like that. The next layer is inspection behavior. And inspection behavior is governed primarily by our default coverage, which if we open this link, we can always see from our console. This table will outline, what the default coverage is. There is also an advanced feature, for creating your own inspection policies. You can see here the super inspector where you can enhance, coverage up to sensor supported boundaries beyond the default. We won't be going into super depth on that, but if it's something that is relevant to your environment, definitely, you know, make contact with your CSM, and we can, you know, have that discussion, with your TAM or something like that. Now, the next layer, layer three, is datasets. Datasets are, the, I guess, the objects that ingest inspection results and then allow that to be leveraged by protection policies, as granularly as you may need for your use case. And then the final layer, of course, are our protection policies where and, you know, keeping in mind that we cannot interpret content with policies. Right? They can only act on datasets. So the outcomes you get from them are only as good as the underlying datasets. And, again, this order really matters because if you skip the first or second layer, content identifiers or inspection, your datasets are then necessarily going to rely on metadata proxies, for their meeting. Things like, you know, this file came from an HR SharePoint site. Therefore, it's HR data. Right? Or this file was created by a user in a legal group. Therefore, it is, you know, legal contract data. And those signals can be useful. They have their place. They are definitely expedient. But, the lack of contextual meaning for the underlying data itself sets conditions for excessive noise in most environments. So, therefore, when enforcement is built on a foundation without content inspection included, it can tend to feel more probabilistic than desired, even with good protection policy logic because your datasets are, in effect, scopes too broadly. And that's really the problem that I wanna help you solve today. Alright. And so kind of the North Star for all this is that, you know, as you start building datasets with strong content inspection, your policies should stop being complex objects and should become much more predictable. You should be in a position with good datasets to say, when this type of data moves to this destination, do this, and that's all you really need to delineate. Alright. So with this mental model in place, identifiers, inspection, datasets, and policies, we can start, getting into the nuts and bolts of things here. So we're going to start by taking a look at a very simple discovery dataset using some of the built in content inspection rules, that come with the cyber hidden tenant, just to see the chain working end to end before we do anything custom. So we have two really common use cases here. You can see here this US HIPAA data, dataset and then US personal data. So we'll start with HIPAA data because that one is kind of a popular one, a fan favorite, if you will. And all that's happening here is we have a discovery class, dataset, where we are being intentionally as broad as possible. And the only condition here is that the content being scanned, by the content engine must match the built in HIPAA, policy. And the reason that we do this is that we want to start by discovering every possible, yeah, every every possible hit for PHI HIPAA data, anything that could be credible. And, you know, once we start getting results for that, we can move into tuning it and stabilizing it to, you know, good sources and changing the logic of it, to suit our particular environment. So, again, this dataset is not anything that I would classify as enforcement ready at the moment, and we'll get into some of why. So if we want to maybe tune this as a, you know, built in rule, how would we do it? So, the method for doing so is gonna be back in content matching rules. We would come back to content identifiers. And then, quick and easy way to find anything that is active in here is going to be to use the handy dandy status search. You can see here, we have our United States health insurance portability and accountability act HIPAA policy. Now if we're trying to figure out, you know, why something matched or what it's actually doing, at a mechanical layer, we can open it up, duplicate it, which exposes the underlying logic of the policy. We can see here that what's going on is you have a top level end statement, and then you have within that, two other end statements. End statements just mean that anything within must fully match, for it to be considered a, a match. Within this first one, we have a simple you know, one of these conditions must be true. We can learn that from this or conditional here. We must have, you know, for example, a HIPAA medical content, low confidence hit or medium or a high or, you know, a single prescription drug mentioned. So you can see here, we have, like, minimum count, unique counts, various levers that we can toggle to determine, what is actually gonna be picked up by this policy. Down here, you have, you know, slightly more, interesting format where we're looking for, you know, any two of these kinds of common, PII datas essentially. And then we have some other, patterns down here as well. And so point I'm trying to make here is that you might start if you're looking to control PHI by throwing that default dataset against, you know, all of your data and seeing what gets, you know, what lights up on the board. And then at that point, you can start coming in here and saying, well, we don't really care about passports. Right? So we can set that to we can remove that outright from our custom HIPAA policy, things like that. You know, as an aside, common tuning for this, we tend to see prescription drug names, as a source of noise just because they show up in research papers and also in, you know, intake forms, things like that. Anyhow. Alright. Next thing. We're going to, talk about kind of the the other side of it. Right? So when you're building these discovery datasets with default rules, our recommendation is that as you do them, you use a two tiered system where you have a discovery, HIPAA dataset. And then you might have something like a, test HIPAA dataset where you would come in here, if we go back to our policy. And we'll we'll actually go ahead and create a custom one. So we'll come in here, and we will duplicate this and go custom. Alright. Now that we have our custom policy, all we're gonna do is we're going to come in here and increment up this minimum count. We're gonna say you need at least five prescription drugs, or you need at least, say, three, and they need to be unique. That way, we have, some certainty that what we're looking at here is is going to be, you know, unique to a user, not a research paper. It's gonna have all their PII and such, and it's just a better way to, you know, it's a better way to tune it. And more importantly, you'll see what I'm talking about as far as being able to okay. We gotta remove this as well. Okay. Well, regardless, you would save that and create a new dataset, with the custom HIPAA policy. And you would have both of those and be able to see over time which one is matching and be able to tune things from there. Alright. So that works really well if you have a universal data type, like, you know, a tax identification number or a passport number. But when you start getting into more custom use cases, like, say, you have an internal project code name, some kind of confidential research that's going on, for your org, how do you solve that? So that's what we're gonna tackle now. Custom content identification rules. Okay. And this is this is exactly the purpose of the session, really. This is the cool stuff, in my opinion. So, you know, what do we wanna do here? So we've set up some project Nebula rules here, and we'll dig into them and talk about the mechanics. Alright. So what we're gonna do here is we're gonna extend our consoles out of box capabilities with some custom unique patterns. So, the goal here is to identify immutable properties of the data itself, not just where it lives, who owns it, or what it's named. Our first rule is going to be this project Nebula simple rule. So we'll open that up, and we'll switch to the raw XML edit because it makes things a bit more clear, in my opinion. Now let's look at the actual, components that make up one of these rules. So the first thing that you'll see, we have this top level tag, this rule tag, and it's simply the container for one or more entity definitions and the keyword or Regex elements that they target. Right below that, we have, of course, our first entity. And this entity object is going to contain the attributes and pattern definitions that specify the content matching criteria. Important to note that an entity must contain at least one pattern definition. There are two attributes of entities that I wanna talk about here as well. The first is the pattern's proximity value. This is the number of characters that the entity's child pattern elements will consider surrounding content as corroborative corroborative evidence. It must be greater than one. It can be fairly large. You can set it to tens of thousands of characters if you like. Not I don't necessarily recommend that, though. The second piece is the recommended confidence. Recommended confidence threshold, is between one and one hundred, and it, needs to be met to consider an entity as matching, this rule. The combined confidence level of all matched entities for a given piece of content, will or must meet or exceed the threshold in order to generate a dataset match and, therefore, a policy outcome. Keep that in mind, please. So in this example here, we're using the simplest possible pattern where we have a single ID match, the primary ID match, in this case, named project Nebula keywords. We have the pattern's proximity set to one because it is just looking at these keywords with no other supporting context to worry about. And then the confidence interval for the singular pattern here is 80 so that whenever this pattern is a is evaluated as true, we do get a dataset match. Alright. So in plain English, what you're seeing here on the screen, is that if you have project Nebula, Nebula, or Nebula v two case insensitive anywhere in a document, you're gonna get a hit for this dataset. It's a very broad rule. It's more of a discovery rule in line with what we saw with, the HIPAA policy. That's most of it for this rule. The other things here to talk about are, the keyword, the ID there. You must make sure that the ID rep and the keyword IDs are the same and that also you're using unique, keyword IDs or, you know, rejects IDs, whatever they're gonna be, per rule. So you can't reuse them inside of the same rule. And, the other thing is that the group match style. So you see this match style tag here. That is going to define the type of string that can be matched. And some options that are available are things like letters, words, phrases, symbols, and numerical strings. And then, of course, the term tags, are gonna define, you know, each individual term. So just add more rows as you need more terms. Alright. So, again, this is pretty straightforward one, and we would use this for, you know, basic discovery to see where we find Nebula within an environment. Moving up one level, we'll go to our intermediate, policy here or our intermediate rule. Now this rule is a little bit more, fun. So for one thing, we're gonna introduce two new concepts. The first one is a secondary keyword group for context phrases. You can see that down at the bottom where we have sensitive context, and then we have things like do not share, internal only, confidential, under NDA. Right? And then, of course, because we have two, two keyword groups, we're going to need to have a secondary match, condition here, signal. And, you know, that's that's the other piece, right, is that what I'm what I want you to come away from this with is that patterns can have multiple match conditions, and you can have multiple patterns, per rule, which means that you can get pretty complex and encapsulate, you know, different kinds of data, have multiple pathways to a confidence level that you're comfortable with, you know, if you're looking at, you know, different kinds of structured data, for example. And we'll see another example of that shortly. We did also expand the patterns proximity out to 300 characters, which is to facilitate finding, you know, confidential in the context of Nebula usage throughout a file. And it means that, again, we're gonna be looking at a couple sentences before and after any hit for Nebula. Something else to call out here is that the ID match, again, you're always required to have one for each pattern, and it is the primary match condition. The match below it is supporting evidence, and it won't show up in results. So when we look at some of the sample data that we have, you'll see that the project Nebula keyword is generating the hit, but it won't do that unless this match condition is satisfied. You just won't see it in, in the UI. Alright. What else do we wanna talk about here? Let's see. Yep. So we set minimum occurrences, to one for sensitive content. So we only need one of these. And, effectively so what this rule is saying is only treat things that match this rule as Nebula content, or only treat as Nebula content if I see the code name and sensitive context near it. And it's this combination of context that improves signal quality in a pretty dramatic way, We'll we'll show some of that in a minute here. Alright. With all that said, let's move to a more production grade kind of rule. So if we look at the advanced example, you know, as you guys are probably familiar with, real data is very rarely uniform. Right? And we want multiple paths to a confident answer. So in rule three, we try and take that step. So what we have here is we're keeping the code name plus context pattern from rule number two. We're also adding a second pattern that looks for structured project IDs. You can see that here at the bottom. We have a Regex ID down here looking for Nebula and then, you know, project number. The pattern's proximity is also set to 600 to give us a wider context window. And that way, we can ensure that if we see a Nebula code name, a sensitivity phrase, and or project ID a few sentences apart, we can all they can all contribute to the same match window. The recommended confidence here is set to 80 for the overall entity, and that's because we have two patterns. One, the first one, from rule number two is still set at 90% confidence. The second pattern where we just have the project ID and a Nebula mention is set to 80. That way, we're still gonna pick it up and put it into our higher confidence dataset. But we are, you know, starting to delineate what we consider to be more sensitive data, than than others. Alright. Yep. So, again, either way, you'll trigger the rule and whatever, you know, outcome that you have assigned to the relevant dataset. We'll cover those in a minute. Alright. Now, the other thing that I wanna note here is that, you know, we have we have, more nuance here than you would get from a simple flat keyword list, but we're still not, we're still not as nuanced as we could be. Right? And so I wanna talk about one other thing to consider here, when we're talking about rules. So you see that we have these financial impacts and credentials and secrets, rules as well. These ones are structured similar similarly to the previous instances. In this case, we're, you know, looking for Nebula keywords and then some financial context. Hey, And. yep. So sorry to jump in. We're just getting some feedback that the dark mode is hard to see. Okay. Could you into light mode just so that, people have a easier time seeing? Yeah. Absolutely. Thank you so much. Alright. Sorry about that, folks. Anyhow, let's keep moving. So, credentials and secrets. Similar to financial data again, and really just here to call out that, you know, we can do a lot once we start using some of these more advanced patterns, especially when we start to combine them. So we have rules, and those rules need to be put into content identification policies to begin doing anything within your environment. You notice here that we have active and inactive rules. Any rule that is active will be scanned or will be, used anytime that content, scanning occurs within your environment. If it's not associated with the dataset, it'll still, you know, match. It just won't do anything because there's no linkage to a policy at that level. Now you see this project Nebula high risk. Actually, let me back up. Let me back up. I made a couple of policies here. So we have the Nebula test that has our super basic for the never mind. We have Nebula discovery, which has our super basic policy or rule. And, again, this is just for discovery purposes. We have our test policy, in place to mess around with and, you know, continue to refine things as we might want to. And then we have our prod policy, which we're going to use for primary enforcement, And this one represents the advanced rule that we looked at. And then finally, we have the, high risk, policy here. Now the high risk policy has a couple of key things to discuss and stuff that I think will be relevant to the group here. So, you know, as you noticed in the, rules themselves, you have the ability to create conditions. Right? You have the ability to create multiple patterns with different confidence levels that can be combined or that can match independently, to create, confidence that you're looking at a certain kind of content. Right? And, you know, the question is, you know, if you can do that, right, if you can create multiple patterns inside of a single rule, you know, do you ever need to combine your rules? Is there a good use case for that? And this high risk, policy is designed to kinda answer that. So inside the or inside, of our policy here, we are ordering a couple of things. So we have our advanced project Nebula, rule as the kind of base plate. So you have to have a Nebula mention plus sensitive context. But then also, crucially, we're saying, in order for it to be high risk Nebula data, it has to be of, you know, financial significance, or it has to contain some kind of credential or secret in the same context window. And so in this way, you can start to combine all of these building blocks that you're putting together in the rules into much more meaningful combined sets of data. And, again, the whole purpose here is that, you know, when we look at what matched and what didn't with some of these datasets, you'll see that as you start to refine these and combine them, you get much better policy outcomes, of much higher confidence. And that's really the purpose here that we're trying to communicate. Okay. So we talked a lot about these rules, and I think it's time that we look at how they fit in with datasets and policies. So, let's go take a look there. Alright. So we have a couple of datasets here. And, again, most of these are going to be fairly straightforward. We have, of course, our Discovery Nebula data, and that's just going to be composed of our project's Nebula discovery, rule and policy. So it's gonna be extremely broad matching. Right? When we look at what actually, you know, gets associated with it, we see you know, we have anything that includes a nebula hit inside of the content. Right? That's all it needs. And so it's going to be picking up everything, and that's by design. That's a good it's a good control for us as we you know, if we were to be testing this out. Do some risks overview. It'd be a little bit faster. Now, going up a little bit, we have our project Nebula data, flow and we have, yeah, we have a project Nebula data, our test version of it. And this is going to start getting a little bit more specific. We see 21 events matching against it. And you can see some of these are gonna generate multiple matches, and that is, again, intended, because they're operating at different levels of, kind of exclusion here. And we can see that in this case, you know, we have, the Project Nebula plus, some of this confidential stuff. Right. Now where it gets interesting and kind of the again, one of the major purposes of having this conversation is, you know, if you try and avoid doing content inspection to try and capture something like Project Nebula and you do it just off of file names like this dataset, you get some inconsistent results. Right? And, again, this is kind of what we want to avoid, and I think it's important to call it out. So notice here, we have a bunch of different file names here. And, you know, we have a couple we have all of them where the file name includes a mention of Nebula. However, kind of the crucial distinction is that sometimes that's meaningless, completely meaningless to our purposes. Right? And so in this case, we're talking about a Nebula like visual effect. It has nothing to do with anything related to a project. You know, in this case, in this next one, project Nebula q three forecast, this one is actually a true positive hit, but it's more or less dumb luck that a rule that is not doing content inspection would pick that up. Right? And, again, that's what we wanna be avoiding here. And so all of this to say, when you put everything together and you have your high risk dataset, you know, scoped appropriately, you can start to get really nice outcomes where you're only capturing the truly important stuff. Right? We can see here that we are only picking up on this nebula q three forecast. And the yeah. Well, the nebula q three forecast only. This internal document is the same or this entitled document. It just, the name got messed up as it was downloading. Yeah. Alright. And the the point here being that as you increase the confidence of the content inspection rule that's underpinning all of these datasets, you get to do less and less thinking about the policy logic and about, you know, exceptions, exclusions that need to happen at that level. And you get to start just thinking in terms of where do I not want this data to be going now that I can classify it appropriately. So yeah. That is, really the point here. And, you know, I think at this point, we can zoom back out and kinda recap. So, again, we started by grounding ourselves in the right mental model, which is content identifiers come first, followed by making sure that our inspection behavior is appropriate for the use case that we have. Then we have datasets and policies. From there, we walked through the full life cycle of what it looks like to put one of these rules together. We looked at the built in content identification rules, as far as how they can apply to discovery datasets and then how you might modify them into prod. And then, we looked at several layers of custom content identification rules of various complexities to detect proprietary data based on what is actually inside of files, not just metadata around where it lives or who owns it. Once we have those wired into datasets, we saw that it's relatively straightforward to take your high confidence, high risk datasets, and map them to your heaviest enforcement policies, in this case, blocking. And, really, the main takeaway for all of this is that you cannot hope to protect effectively what you cannot identify accurately. And if you invest in good content identification and clean datasets, your enforcement downstream will become increasingly more predictable and maintainable. Most of the pain that people experience with DLP comes from trying to fix classification problems at a layer above where that classification is happening. So if you follow the pattern that we walked through today, you should be able to stand up your own new protected data types relatively quickly, tune the noise safely over time, and move towards enforcement with a high degree of confidence. And if you're interested in going deeper, you know, there are because there are a bunch of topics here that we haven't really covered in great depth, things like exact data match, document tagging, all that stuff. You know, we're happy to have that conversation with you and reach out to your CSM to to get that process going, and that all builds on that foundation. So with that said, I'm going to hand things back to Amy to close this out. Thanks, Nick. And I know there were several questions in the chat. I'm gonna see if Pat or Ben Crocker wanna join me real quick to help answer, some of the questions that we saw in the chat here. Pat is joining. One second. Please, if is as we wait for Pat to join, if you have other questions, please feel free to add them in the chat. And then also, just again, a reminder that we have our product launch coming up next week. I will add the link into the chat again that you can click if you'd like to leave your spots. But with that, Pat, if you don't mind helping to answer a couple of those questions. Yeah. Of course. Nick, would you mind sharing your screen again so we can. take a look at some of the descriptions for conference intervals on some of the out of the box content inspection rules that we have? Sure. Let's take a journey. Let's go. Alright. So okay. Here we can see it, and I can't see this super clearly, so bear with me here. There was a question about the confidence intervals and how that would affect the detection. And each of the rules that are available in the CyberHaven console that use special capabilities from our engine or that are prebuilt here have predefined confidence intervals that you will be able to modify, in the content matching rules configurations here. And the confidence intervals here will affect essentially some of the formatting of some of the keywords or patterns that we're looking for. So there may be variations in, how medical diagnoses are formatted, whether they include spaces or capitalization, sensitivity, or insensitivity. There may also be a higher confidence threshold. May also introduce a related keywords or terms. So you'll see that, Nick, here under the HCPS or PCS, the health care common procedure coding system codes, there's two confidence thresholds here that introduce, kind of different heuristics. So the 60% and below would be looking at an individual code, Or if you were to turn that confidence interval higher above 85%, we would also be looking for a related term as associated with that code. Those related terms could be, any relevant keywords that are predetermined by these engine policies, So specific terms denoting that that code exists or other specific medical keywords that would give us higher confidence that that code is legitimate as associated with procedure coding systems. So there's a lot of variation here for the various policies. I know for first name and last name or person's name, there may also require that those are just a first name or just a last name or first name and a last name combined depending on the confidence intervals that you do select. So I do recommend if you have questions around this to reference the descriptions that are listed here in the UI because it will give you information in terms of what those confidence interval settings will produce in the detection. Great. I don't see any other questions over in the q and a. So with that, I will, I think I will close this out. Again, reminder to to sign up for the product launch. We will send I know there was a question around the recording. We will send the recording of this webinar to all those that have, joined today so that you can review it. Oh, I did just see one last question come in here. Pat and Nick, if you wanna take a look at that real quick. But, Yep. just again, as a reminder, we will send the recording, after this webinar so that you can review. Yep. I'm reading this question here for discovery versus enforcement. Would it make sense to use an out of the box policy for discovery and then a custom policy that modifies matches conference or both or one? I'm a fan of using the out of the box policies for discovery like you mentioned here. Mhmm. It is very nice to set them up fairly broad at first to discover that type of data in the environment. With that, you'll likely have evidence of that content or evidence of those types of files where you can then denote, hey. Is this the type of data that I am looking to match on, or is this correctly matching on the keywords that I care about? Post that, I recommend playing with the confidence intervals. If you need to make that detection stricter or less strict, you can do that with the confidence interval, changes there. And then if you discover that, hey. This out of the box policy is still too broad or it's not, performing at the level in which I wish it to, you can introduce either supplementary, content inspection rules, to supplement the out of blocks detection or go a custom route if something fits better. So if you're looking for very specific keywords that are, again, specific to the org or the type of business that you do that aren't in the out of the box detection, that may be a good route as well. But, again, I'm a fan of using them as a broad discovery tool. If you need to fine tune them up the conference intervals. If you need to go more customer out, you can use supplementary rules or pivot to a custom role as well. Nick, is that in line with something that you would do as well? Yeah. I agree broadly with everything you said there, Pat. You know, all I'd say is that I prefer to keep, a kind of, like, a control dataset with the default, content inspection, you know, out of the box rule if you're gonna go with that initially. Just until you have reasonable confidence that whatever you're testing with, for the, you confidence interval modified, you know, default rule is in line with what you want. Right? And then I would just keep those. I would roll that into the discovery one and then keep iterating. Right? So that you're Yeah. so you're always so you're not, like, losing progress. You're not, you know, gonna end up a month later, you know, confused about what you're trying to do. You know, you just wanna keep it straight, so that when it's time to enforce, you know exactly, you know, that you have good confidence in what you're in what you're matching. Agreed. And there's a second part to this question as well. Would you then apply both content matching policies to the same dataset but then have two DLP policies each utilizing one of the content matching rules? So I'm also a big fan of having, if you're doing this in a discovery phase or if you're doing some sort of enforcement based on these results, I'm a fan of having a, you know, either broad or low confidence detection. So low confidence dataset and then maybe also a high confidence dataset as well that maybe I'll use for enforcement, or I'll put that at a higher risk score or severity. One example here is I know for a lot of my health care customers that are looking at PHI, they might not care as much about single PHI records, but they may have a higher confidence content inspection policy looking at documents that contain 10 or more unique records. So they'll have two distinct datasets, one that's either broader or looking at single records or another one that's stricter looking at a high volume or high count of records within a single file. So the way in which you outlined this here where you have two DLP policies or you have two distinct datasets, I think is in line with some of the best practices that we would recommend as well. Yep. To echo that, what you're seeing on the screen here is effectively what we're talking about rec or as far as the recommendation. Right? I would have multiple datasets and potentially multiple DLP policies, but clones as we've kinda done here with this generative AI policy where we have a monitor, a warn, and a block instantiation of the same logic. That way, you can, you know, keep, the lower confidence dataset on monitor or warn until it gets tuned up or just for discovery purposes. And then you can focus the enforcement and save yourself the headache of all the false positives that come from the, lower confidence datasets with your actual preventative policies. Yeah. That's that's a good question. Cool. Anything else from the from the crowd? No. Alright. Thanks, everybody. Sorry. I was on mute. Yes. No other questions in the chat. Thank you both for jumping on and presenting and answering questions. Thank you all for those that attended. If you have topics that you'd like us to cover in Cyber Haven Unlocked, please share those as well, with us with your CSM or your analyst, whoever you work with at Cyber Haven. We look forward to speaking to you at the next one. Thank you so much.