Video: Cyberhaven Unlocked: Designing Your Deployments | Duration: 3164s | Summary: Cyberhaven Unlocked: Designing Your Deployments | Chapters: Welcome and Introduction (71.565s), Profiles and Configurations (203.98s), Configuration Profiles Overview (421.76s), Detection and Configuration (984.575s), Policy Configuration Settings (1294.58s), Creating Global Base Profile (1469.225s), Server Profile Configuration (1650.84s), IT Pilot Configuration (1975.105s), Comprehensive Security Configurations (2129.43s), Overrides and Customization (2376.26s), Best Practices Overview (2716.32s), Future Endpoint Enhancements (2820.565s), Recap and Conclusion (3018.31s)
Transcript for "Cyberhaven Unlocked: Designing Your Deployments": Hey, Donnie. How are you? We'll give it a couple of minutes, for to let others join, and then we'll kick off here in just a few minutes. Alright. I think we'll go ahead and get started here. Hello, everybody. Welcome to today's webinar where we're gonna be talking about designing your deployments. We're gonna be discussing, you know, the new profiles, configurations, and the new endpoint management redesign. I will go ahead and hand that off to Ben Crocker to start start our conversation off. We'll dive back into some demos, and then wrap up with best practices and recap on a couple of items. So, if you don't mind, Ben, I'll pass it to you. Thank you, Ben. You you have the Ben show today, everybody. We're gonna talk, about some new functionality. We've been working on this actually for quite a long time. Our intent with, with the profiles and configurations work that we've done is to expand the availability of functionality in the platform for customers to manage their own deployment, to understand what's going on with the endpoints that are deployed, the sensors that are out in your environment, and to be able to control that. And also, eventually, to be able to troubleshoot, to be able to understand statistics and all of the things that are going there. Ben, if we could have the next slide. If we compare what you may have seen in the platform up until now, and in fact, in in many instances, none of you would have been able to see the configurations that were in the platform. What we had was deployment groups as they were called. You would select the set of devices that you were, that you wanted to send a specific configuration down to. You'd be able to select the policies that were going down there, the content inspection rules that were being associated with those. But they were delivered in this one huge block of monolithic sets of settings, that included actually a whole bunch of things that weren't exposed in the UI of the platform at all. We were using manually targeting those. You had to pick those devices for yourselves. You had to be able to, decide the the groups manually once they connected to the platform or when you did the install of the devices. And then there was this very large and quite complex, JSON configuration that went down there. And then as mentioned, in a lot of cases, you guys wouldn't have been able to see it. It would have been Ben and the other guys from the the support of the CX organizations that would have managed those for you. As we look at what we'll show you, yeah, in the platform in a moment and Ben is gonna walk you through that, we changed that into something that I think represents, a well known workflow for delivering configurations. You have a profile that takes a set of reusable objects of configurations, connects them together, and allows you then to target them down to the devices inside your environment. That profile is built at those separate building blocks of configurations where you can set a configuration that allows you to decide about maybe the performance or the detection characteristics or the update characteristics of that set of devices, put those into a into a group and apply that to the set of devices. Dynamic targeting allows you then to say, I it doesn't matter if that device has been connected to the platform before or not. If I set these characteristics when that device connects, it'll be applied in into that group of devices. And then I'll show you how that works the targeting in there. So when you have dynamic targeting, there are some things where you need to allow for those to overlap, and we've covered that in the settings as well. And then for the issues where you do need to look at at setting very specific configurations or you're talking to the support organization and you need to set a particular setting, there's an option for overrides. So while we have a lot of those things exposed in the UI, the capability to get down in the weeds and be specific about stuff is already included. So all of those things inside the platform available to you guys. The other thing to mention here is, at the same time as this functionality is delivered, the APIs are all available. So all of the things that that Ben will show you as he go through and shows the profiles and the configurations and even the overrides for those things, all available inside the, inside the API and, available for you to integrate with all of those systems that you use, whether that's conflict management or or actual configurations. And next one, please, Ben. And so as mentioned, we're having those kind of building blocks, and we wanted to allow for reusability inside inside your environments. As you look at how you deploy changes in configuration, you may have one config that represents the vast majority of the devices in your environment. And so that might have one set of policy configurations or or one set of resource utilization configurations, and you want to have that and use that everywhere. But then for another set of devices, you might want to change either the policy or the utilization or the detection characteristics to be very specific. And so taking those things, splitting them into reusable objects, allowing you to reuse those in a in a one to many scenario, one configuration to many deployment groups if necessary. Or, of course, if you really wanna be specific one to one, I've got this set of devices. It's my test set of devices. I turn on everything in there, and then I can filter those through. So allowing, intentionally allowing for that reusability and that the settings there to allow you to roll things through into your environment, test it in the set of devices, move into a bigger set of devices, and make sure you're there. So really hoping to give all that flexibility. What is there, of course, is that default profile mentioned at the bottom. And when Ben shows you about the, the priorities, you'll see how we've set that up. Every device will always have a profile associated with it. If it if it falls through all of the ones that you've created as dynamic ones, then it'll hit the default profile and it'll be there. But they will always have a config. A device will always, land in the group there and be able to do those things. So that's the kind of overview for that. Ben is gonna take you through some of that stuff, in the UI and show you what's there. I'll come back afterwards and maybe talk a little bit about the other things we're we're gonna, add into that. What I would say is there is a q and a. Please ask any questions if you got in there while Ben's tapping away. I'll do my best to answer all of the questions, that are going on there. Thank you, Ben. Thank you. Alright. So before we we dive into the platform, just kinda set up what we're gonna be doing here. I'm gonna go over the console. We're gonna talk about, you know, where where these new enhancements live in the console, the endpoints, the installers, the profiles, the configurations. We'll we'll touch on each of those. I'll probably start with the endpoints first, and then we'll pivot from there. But let me go ahead and share my screen here, get the live console. We'll stop sharing the presentation. Oops. Share. Alright. So we should see the console here. We are in a staging environment. So as many of you are probably aware, previously, this is what the endpoint sensors page look like. This will go away once we migrate or turn on the setting for you. This will eventually go away, so you will no longer use this. But I just wanted to to start by saying, hey. This is where you do all of your work now. This is changing, and I'll show you, what that looks like. So here at the bottom left, we have the new navigation for endpoints. We have various sections here, profiles, endpoints, configurations, and installers. I'll start with endpoints. You land in an endpoint inventory, similar to the previous endpoint management, page, but we've called out some additional context for each endpoint here on this particular view. As you can see, the endpoint status is at a glance. We also have some icons for, various operating systems. You can see that immediately and, you know, have a takeaway from from what, you know, devices you're looking at, whether they're active, last time they've communicated, all the standard stuff you're you're typically used to. However, we also added the, ability to click on to each of these sensors and get additional information about the endpoint itself. So in this case, we have, just an environment. This is just an example, endpoint, but we can see whether or not it's healthy, any particular errors that may have been attached or statuses that are attached to an endpoint. If you have, like, an Outlook plug in that needs updating or browser extension, all of those particular, statuses will show up here. There will be tabs to allow you to tab through, you know, critical, minor, those types of things as well. I don't have any to show there, but statuses are pretty straightforward. We also collect some additional, metadata from the endpoint that will display here in the system info. And it will tell you, you know, what's the profile last assigned to the device when it checked in. Pretty straightforward. We also allow you to run the diagnostics from the screen as well. There is a little actions menu, which is similar to the previous, endpoint management, which allows you to perform similar actions, you know, request a diagnostic, view the pop out, or you can delete as well. You may notice that at the top here, we have various columns and they're filterable. But what we did a little bit different here from the previous endpoint management page was allow you to filter from this filter menu. So all of the filterable, columns or options will be available here on the left side once you click the filter. And then you can go ahead and select your various filters, apply those, depending on what what you're looking to filter on your criteria. There there's quite a few filters here. Just depends on your use case, what you're trying to to narrow down, but pretty pretty straightforward. Again, gives you a live inventory of your environment. I will hop into installers. Won't spend much time here. I think we all understand what this is, but this was previously in a drop down menu on the endpoint, sensors page. Now we have a dedicated page for that separated by operating system here at the top. All of the standard stuff you would expect to see, so the MDM profiles, the installation commands, the various versions as well. So, you can just grab those from the endpoint installers page. Pretty straightforward. Won't spend any time there. I think the most important stuff we wanna cover here is profiles. So profiles and configurations. What is a profile? Ben sort of already you set the foundation for you here, but I'll I'll recap. So profile is, as you can see here, a set of configurations, targeting criteria, and a priority. So targeting criteria, you're going to define, based on what groups of devices or it could be a very specific device, that you want to apply this particular profile to. I'll walk through that example here in just a few minutes. But a profile is made up of these six configurations. Well, five configuration profiles essentially that you'll be able to modify and then one configuration that's just attached to the profile or excuse me, the profile itself, which is the uninstall protection. I'll talk a little bit about each of these as I move forward. Let's see here. One of the things you'll notice outright and I'll just I'll touch on and this is really a topic for probably a different conversation, but migration. Right? So all of the existing customers are using the old endpoint management. Once we enable the feature flag for this, there's an automatic migration that occurs where we take your existing deployment groups, all of the associated configurations for those, combine them into a profile, migrate them over. You'll see those profiles here. This is just a default profile that existed in the environment before we migrated. One thing to note about these migrated profiles are is that they are read only. You cannot modify these. So we can turn on the the feature, the migration occurs. These are in there as a base for you or at least to keep your your environment running as it was prior to the migration. But it gives you at least an ability to go in and take a look at the preexisting settings and how they apply here. But one thing to note as well, all of those settings that were previously in the, remote config, they're brought over as overrides for and I'll talk about overrides towards the end, but you'll see an override section here where you can apply overrides to the overall profile. There's various reasons why you might wanna do that. Could be support related cases where you're troubleshooting or maybe you want to override a particular feature. You can do that through the overrides. I'll talk about that in a few minutes. So default profile is great. But as Ben mentioned, you'll wanna start thinking about profiles after the migration. And default profile is a good place to start. It gives you a good foundation. But in my organization, we'll want a default or a global base profile. So we're gonna walk through creating a a base a global base profile for my hypothetical organization here. So before we can do that, we have to visit the configuration sections for, the profile. So I'll dive into that now. As you can see in the configurations here, we have five, default profiles that will allow you to have a base for for configuration and operation of the sensor. We'll start at the bottom. The performance, default here, these are the performance related knobs that we've exposed so far. Whether it's offline storage as you can see here, there's various other settings, how much cache we take up on the endpoint, I guess total directory size of the the, directory that we're we're taking up on disk, various other settings as well, how often the device is gonna communicate, if you have VDI environments, whether we're, you know, scaling, appropriately with that with the VDI, you can set those configurations here as well. Pretty straightforward, but we'll we'll we'll dive into that once we start creating a base profile. Talk quickly about detection. Detection is basically all of the the the knobs that we can turn on and off for telemetry collection. Right? So what is the sensor inspecting? What is it looking for? Browser extension enablement, ports for a particular use of browser extension. You may have, you know, endpoints or servers or other applications that are using our port. We allow you to now configure, to a custom port so that, we can continue operation with the browser extensions. We've exposed a lot of the settings that were typically in the remote config that you had to reach out to support, to actually change or modify. We're trying to to empower the users to have more visibility into what settings are enabled, what what telemetry is being collected. So it's complete transparency on the overall, configurations for for an endpoint. So detection related items here. We'll we'll we'll talk about these as I create the the sample profiles. But content inspection default, these are all the content inspection related, settings. You know, how big of the files by default that we're gonna send to the content inspection, data and motion settings. The default here has data at rest disabled and, you know, discovery scan and content inspection scan. But we'll in one of our scenarios here, we'll we'll configure one that that has data at rest enabled. Software, policy here or configuration defines your update policy for for endpoints. The default here is latest standard. So you'll probably, in most organizations, are gonna want to, as I mentioned, create a default or base for their org where you probably will set different update configurations, maybe an n minus n minus one previous standard scenario as well. You also have some controls around the browser extensions, whether you want those to update to the latest or turn it off completely. You have the ability to do that. And then policy default. So this is basically all policies that you currently have in your environment are applied to this default policy. So if you just ran with this out of the gate and you had block policies applied throughout your environment, they would apply to all endpoints that match this particular profile. So you just wanna think through that. Maybe you want to target your deployment in a specific way. Maybe you want only monitor policies for your default group. But we'll go ahead and and create that now. So starting out, we'll just, clone or duplicate the existing configurations here, and we'll just call this performance global oops. Global base. We'll just use that as our our naming here. And we'll it's not the default. We'll just call it global base. Move through here the settings. We can see the various settings as I mentioned, in the little overview. We're gonna leave this all default for now. You'll get a confirmation or a section for you to review before saving. It's very important that you do this. You wanna make sure that any configurations that you're modifying, that you are sure, in what you're changing because as soon as if this is applied to an existing profile when I hit save, those settings are gonna be picked up by the sensor. So it's just important to make sure before you move on from this particular screen that all of the intended settings are are correct. So we'll save this. We have a performance global base, and we'll do the same for each of these. So we have, a particular global base that we'll use for our overall profile. So from a detection perspective, we'll do the same. Duplicate. We'll call this it's not a default. We'll call it global base. Great. We'll see there are various settings here in my organization. I don't think it makes sense to have screenshots enabled for all of my devices. Maybe I wanna do that, a targeted approach. So I'm gonna go ahead and turn that off for now. But then you have other options as well. And, again, this is default, so I won't go through changing a ton of these. But to kind of explain, you have the ability to pick and choose what features you want enabled for the sensor in terms of how it's collecting telemetry. Maybe you wanna enable Teams visibility, you can do that here as well. Maybe in your organization, you do not have, you know, Safari in use or you don't allow Firefox. It's blocked. Maybe it's just Chrome and Edge. Right? You're able to modify these particular, settings to either turn up the visibility or turn down the visibility depending on, your environment's requirements. So I'll just proceed forward here. Again, it's always important to review these, settings before you save. I'm reviewing. We'll go ahead and save, move on. I'll do the same for content inspection quickly. Create a global base here. Moving forward, you'll see I don't have a bucket configured for this, so please ignore this message for now. But if you did have a storage bucket configured in the environment, you would get some additional settings here to control where where that data gets stored in your storage bucket. These are our default settings as I mentioned. Right? What's the max file size we'll send to DLP scanner? 25 megabytes here. These are all pretty standard. We'll just leave those as is for now. Moving forward, in my org, I do not wanna turn on data at rest globally. I'll do that in a targeted approach. So I think the default settings are good. Data in motion, is perfect. So anytime some file moves around, we want we wanna send that off to the DLP scanner and get some information, back based on its classification. These default settings are fine as well. We're not gonna enable any content, discovery or content inspection for data at rest. We'll move forward here. Go ahead. Always confirm. Best practice. Save. Alright. That was content inspection. Now we'll hop into software. And this is one that will probably be different for most orgs. Right? You're not gonna and and unless you like the latest and greatest software all the time for your for your global fleet. But in most orch, you're probably gonna set some sort of, deviation from from the default. So we'll just move forward. My org, I think we're gonna go previous standard. It makes sense for me. I like to have at least a n minus one or even in some cases an LTS. But we'll just say, n minus one in this case. And then browser extension is fine. We we're gonna leave that on the latest. We'd like to keep that extension updated to the latest. I think 3600 is probably a little long. I wanna just set a default to sixty minutes to have my agents check-in if there's an update. Just gonna double check those settings. Everything looks good moving forward. Alright. And then finally is the policy default. We're gonna want to probably make some modifications here as well. Again, every order is gonna be slightly different. We'll maybe I just want, monitor policy set in my environment because as you can see, the default here has all. And again, if you have block policies at play, they're gonna be applied to all devices. Maybe that is okay for your environment, but maybe you wanna be a little bit more targeted in your approach there. So in this case, we're gonna select specific policies. There's a few sample policies in here for default, but we're just gonna monitor, some flows to, you know, GenAI, chat apps, and USB in this particular scenario. We're gonna apply that globally to all of our devices. We'll go ahead and we'll see the policies that we chose here. Click next. We get a confirmation as always, and we're gonna wanna save. Ben, I might add one comment into this one, specifically about the policy stuff, guys. This is to, to allow the fact that you can go through and decide about a new policy that you put in an environment and how you can target that and do that kind of staged rollout. Currently, the default behavior is every policy you make has to be targeted to all of the devices. In this case, it means you can make a policy. You don't have to do the complex targeting in the policy itself to restrict it to a set of devices. You can use the profiles. You can target those devices that you want, and you can put that policy in there. So that's a a change that's relatively new to us in in the platform as a whole, but we really think it allows you to decide who gets the policy when they when they get it and the impact that it has. So, we're we're really pleased about that one. I think it's gonna give you guys a lot of flexibility. Yeah. Absolutely. Being able to target specific endpoints with policies, through this mechanism is great. Not having to add a list to a a particular policy itself and define users, this really makes it a lot easier. Okay. So now that I have my configurations set and made, aside from the defaults, of course, we're gonna wanna go ahead and create that profile I mentioned. So the global base profile. Right? So you can clone the existing. You have the ability to do that. We'll just clone it. We have the default. We'll call this global base. Whoops. Global base. Actually, we'll just get rid of the default because it's not what we're gonna call it. Global base moving forward. And this is where we talk about the targeting. Actually, the default here, I'm not able to select. So we'll we'll we'll add a profile here. We'll call it global base. Global base, we'll give it the same description, move forward here. Here's the targeting that I wanted to show you. So from here, you're able to specify what types of endpoints you want to target, whether it's by OS, if you have host name. There's other, couple of other fields here as well. So right now, we offer host name, serial number, and OS for targeting. There is some plans to expand that. I'll let Ben talk a little bit about that towards the end of the presentation about what direction this is heading. But for my org here and for this example, we're just gonna say host excuse me, OS because we wanna target all OSs in my environment. Linux, Mac, Windows, we'll just do that. We'll immediately see that the global base previewed 30 plus endpoints or plus 30 endpoints, for this particular, profile. Now this is where we wanna make sure that we're setting the priority appropriately for for the environment or for the profile's use. Excuse me. In this case, we're gonna wanna just set it just above the default. I'll probably give it something like a 10 to keep it low, but not all the way to the bottom. You never know what scenarios might come up where I want to adjust. So we'll just, for now, leave it at ten, five. It could be two for for, your purposes, but 10 is a good number for for us here. We'll hit next. And now we get to select what configurations we want to apply to that particular device population. In this case, defaults, we want to avoid. We want to just add our performance global, content inspection global, detection global, software update global, keep everybody on n minus one, and then policy global, only monitor policies pushed out to the environment. You'll see uninstall protection here as well. That's that sixth configuration. That's not tied to an actual configuration itself. It's more tied to the profile. You can go ahead and enable that here. We'll just do it for demo purposes. Once you click next and then save at this point, you'll see a pop up for that password, for you to note it down. Keep it safe place. Otherwise, you'll have to reset. Got it. Cool. We've created a default profile, global base, that should be targeting all of our devices. It takes a moment before you see that number reflect. So as agents start to check-in and and and that the system does its targeting, you'll see that, that number will reflect here. But that's the typical base global base scenario that you'll wanna probably follow once this gets turned on in your environment. You you'll again, you'll have the default profiles migrated from excuse me. Your deployment groups migrated from the previous version, but you can't modify those. So you'll start to you'll need to start thinking about, like, what steps do I need to take to actually create new profiles in this environment. And we'll touch about it on it at the end in in the recap, but, your CSM or TAM, will be in touch for that, you know, low effort migration process, on story short. So let me go ahead and just see here. We'll bounce around. I'll pop back just to see if the numbers change. We don't see the numbers change just yet, but I would expect that we should see the targeting change here because it's for all Mac Linux and the priority is 10. So it's above the default and my migrated group. So I would imagine that this number is gonna start changing here in just a moment. But instead of waiting for that, we'll just continue to motor through some of the existing, scenarios that might might come up in your environment. So now I have a global base with an n minus one update policy set across the board. That might not be good for all of my devices. Maybe I have servers. They're managed by a server team. They are controlling all the updates through SCCM. So I wanna exclude those devices from from this group. So before I do that, I wanna create a server update, software update policy or or configuration. So we'll just actually, in this case, clone the one we just created. We'll call this one software update servers. We'll say Windows servers. Call it that. Let's give it a little description. I won't bother with that for now. Then we'll go in here and just turn off updates for things that are not applicable in my Windows environment. Again, managed by SCCM, so I want this particular update policy to apply. And also, nobody's browsing the web on my servers, so we're gonna turn this off. I hear laughter even though it's muted. I hear laughter. Okay. And we're gonna wanna confirm, make sure that that's exactly what we intended. It is. So we'll save it. And then from the profile section, now I wanna create a server profile. We're gonna do that. Call this one Windows Servers. We'll go next. I'll leave the description out. And this is where we can use the dynamic targeting to target very specific groups of devices as mentioned. So I know my servers, there's two particular data centers I have in mind. One is in Northern Virginia, so we'll they're they'll contain an IAD in their their name. We'll also add some additional criteria because I only wanna focus on Windows servers there. We do have some Linux servers as well, so we'll just, focus on Windows. And they also contain another string within their host name, SVR. So this will give me all of my Windows servers in my Northern Virginia Dulles data center, and they also contain SVR. We'll wanna also include my Atlanta data center. Those ATL, host name contains SVR, slightly different than the order I did up here, but that's okay. The end result will be the same. We'll set the OS to Windows as well. And then we'll want to adjust the priority. In this case, we see five, which is below the global base, so we'll want to push it above that. I'll go ahead and make that 15, because again, the higher priority. If your criteria matches more than one group, the priority is what takes precedence. Right? So if the higher the priority, that's gonna be the profile that applies to those devices. We see in this case, it's 14. That's great. That's the number of devices I have in my data center. We can go with that. So we'll go next. And then from the configuration perspective, we're gonna wanna select I'm okay with the performance settings for the for the global base. That's fine as well. Same for content inspection. We'll do that. Detection is the same. Software update is the one that really I wanted to make sure it was off because server team would get pretty upset. We'll just go ahead and select the update policy for servers and then the global base for, our policies as well. We'll leave uninstall protection off in this case. We want the, you know, simplicity for our server admins and being able to work on their servers. Go ahead and hit next. You'll see the confirmation of the criteria we set up, the priorities, all of the settings in the configuration itself. We'll hit save and then we should start to see devices populating there as well. Interestingly enough, I don't see the number, but it's possible because it's just dummy endpoint data for this demonstration purposes, but we'll we'll have to look at that. That's typical scenario that might come up. Another, maybe you have IT pilot group. It's similar in this scenario, but maybe you have an IT pilot group. You know, the canary group of sorts where you want to have the latest and greatest for a specific, set of devices. We'll call this IT pilot. Move forward here. And in this case, we'll we'll just target all of the host names that start with Jacks, so out of our Jacksonville office and have ops in the name. This will target all of those devices. We we think that they're a good, pilot or test crew. We'll give this a priority above the default as well. So I'll just call this 20 for now. Could be 100 set at the top. Not quite sure. It just depends on the scenarios and how many profiles you have where you want it to fall. We'll go ahead and hit next. This will be all of my my Jacksonville, devices. That's where my IT ops team, resides. Performance default or global base is fine. Content inspection global base is fine. Detection, same. But if you recall, our global base for software update is n minus one. We want latest and greatest, and the software default that was applied from the default profiles is latest and greatest. So we'll leave that selected for this group and then policy base as well. Moving forward, we'll leave uninstall protection as well off. Go ahead and move forward. We can confirm. And that would account for, you know, the IT pilot group, the the canary, group, as well. So they will get the latest and greatest configurations. We can see that through the confirmation here. These are the different configurations assigned, and they have the software default. So they'll be n minus one or excuse me, latest standard latest standard for software default. Alright. That's typical scenarios that we might run into where it's Windows Server updates, the the canary. If we want to target specific device populations for policies, let's go ahead and do that as well. Let's go ahead and create a configuration. So maybe you have we'll use an example here for my for my environment. I want special, policies applied to my finance team. We want block policies. We don't want any egress. Maybe we also want more comprehensive, content inspection policy as well. So let's go ahead and create those really quick. So content inspection base, we'll we'll we'll copy that, we'll duplicate it. We'll call this content inspection comprehensive, and then we'll move forward through here. Let's see. Those are fine for the default, but we'll wanna turn on discovery scan, data at rest, configuration settings here as well. We wanna wanna make sure that we're inspecting all content on these devices, discovering files that are sitting there dormant. We just wanna know everything that's on on these finance, devices. So moving forward, we'll get confirmation. Again, I don't have a bucket configured for this environment. So, in in yours, you may, and you would see options for configuring that as well. So go ahead and save this configuration, as well, and then we'll want to create a policy version as well. Let me just clone our base policy, duplicate that really quick. We'll call this policy comprehensive as well. Oops. Apologies for that. Next, we see okay. We have since we cloned it from our global base, we have those monitor policies selected, but that's not what I want. I want to turn on the blocking for this particular environment. We still wanna monitor maybe Flows USB, but we wanna start blocking the other items. It's very important that they can't egress any data. Go ahead and save this. Confirmation. Everything looks good. Moving forward. Okay. Got it. So now we have a policy comprehensive and a content inspection comprehensive. So let's go ahead and create a profile targeting our finance devices. So we'll call this finance. Skip the description for now. You'll wanna add descriptions because it'll help with managing this in the future. And we know our host names start with in this case, it'll be out of our Jacksonville office. They also have, FIN in the host name as well as their only max as well. So we can go ahead and limit scope here by OS to max only. Alright. So let's see here. We see finance is actually not matching any devices. Let's let's remove the oh, from the demo here. Okay. We'll set this above all of the others, 25, just to give it a higher priority. I don't know why we're not matching. Maybe it's not Jax in my demo here. We'll just say f I n. There we go. Perfect. We'll use that as an example. We'll jump to OS because again, I know those finance individuals are on macOS and I don't want to target any other devices with that might have that as a partial match. We can see seven devices now match that particular profile. We'll hit next that we have our targeting right. And here's where we can set the the different configurations as mentioned. Content inspection, we want the comprehensive one. We want data in rest on, discovery scanning on. Detection, we'll leave it at global base. Software update, global base is fine. And then this is where we made the policy the comprehensive policy as well. So targeting blocks as well. We don't want them to be able to uninstall. And we'll go ahead and move forward here. Save. Make note of your password. So now we have a finance, profile that's targeting finance devices specifically with our comprehensive policy, configuration, and our content inspection, as well. And you could take this even further. Maybe you want screenshots enabled for this particular set of users. You would go ahead and create a detection policy, modify that, and then you could target screen captures as well. But, again, will require a bucket to be set up in your environment, as well. Again, you could take this a little bit further if you had VDI environment, and you wanted to adjust performance settings for those particular VDIs like the scaling factor or limit the resource use utilization, you would just clone a performance configuration, modify those particular settings, and then create a profile to assign to those particular VDIs. Maybe your VDIs have VDI in the host name, and you can target those pretty easily. Pretty pretty straightforward. One thing I will wanna talk about before, running through all of the examples here is overrides. I did mention, overrides. So the I mentioned them in the context of your migrated profile. So the default or excuse me, the remote configurations that are existing today for you and those groups are tied together. When the migration happens, we flatten all of those configs out into the overrides, and you'll see that here from an override section. I'm not gonna explain what all of this really means, but these were the the overrides that were previously in that particular group. And, again, we've applied them here at a profile level, not configuration level, but profile level. But maybe in my finance, devices, I want to turn on fail closed and also maybe customize, oops, customize, the fail closed messaging. Right? So let's go ahead and navigate to the override section. You'll see this here. This is because I set a password or uninstall password. This is the the information it dumps in there as an override. We'll toggle the editor here. And on my other screen, I have some configurations we'll want to add here as well. This is just an example. And I will caution that the overrides really should be used sparingly, and with guidance from support. Shouldn't be modifying these yourself unless you have a clear understanding of what you could be modifying. But in this particular example, I'm just showing how the overrides would function. We're gonna drop in here fail closed. So we're gonna set that to true. You can configure this in the detection portion, but I just wanted to highlight the fact that you're able to to create, overrides because maybe you do have it enabled in your your detection profile or configuration, but you don't have custom verbiage set up for the prompt that is displayed when it happens, you can come in here, modify that, and then override for for your user base. So we'll go ahead and hit save. Next. Save. Good to go. So now that particular finance, profile has, fail close enabled. It's also going to allow me to customize that prompt as well. So if we wanna display custom messaging, you know, give them a short link to, I don't know, documentation, something that they're able to, you know, understand what's occurring. Pretty straightforward. There's also probably one other override scenario that we may run into in the wild here, and and you may encounter it in your organization. You may need to disable a sensor. Right? There will be future enhancements that you're you're able to disable sensors, I believe. Ben will talk about that in just a moment. But really quick, we'll call this disable sensor, and I'll show you what that looks like. We're gonna be very specific in this case. I'll just make up a name, JAX ops Ben. This this device won't exist, but I'm just gonna give you an example because you wouldn't wanna apply this to unless you wanted to, for whatever reason, disable a group of devices. You wanna be very specific here what you're targeting. Right? So in this case, I'm gonna set it a profile of 100 or priority of 100 because I just want it to be at the top. I don't want any other profiles to interfere with me disabling this particular device. We're gonna hit next. We're gonna just gonna give it all of the base configurations which is fine. I mean, you could have left this default if you'd like. I'm just gonna do it out of, demonstration purposes here. We'll just set to all of the global base. Uninstall protection doesn't really matter. Here's where the override will want to set an override for disabling the Windows sensor in this case. These are Windows devices. We'll drop that in here. So now sensor will be disabled when it matches this particular profile. Save. Got it. Anything that matches this particular is a very dangerous one. Right? You would want to make sure that you're targeting very specific devices or knowing the pattern of those devices, with that criteria, or you could potentially disable your entire fleet. But that's an example of common scenarios you might see in your environment, you know, setting update policies, targeted profile or excuse me, targeted policies that you're applying to devices, whether it's monitor, you know, blocking, what whatever they might be, or, you know, configuring various customizations for content inspection, performance, and all of the other settings we went over. Alright. I I think that wraps it for the demonstration purposes, of the different scenarios. I don't know if there were any questions that you wanted me to answer specifically, or I can pass it back to Ben to discuss a couple of items here. Yeah. There's, there's one question that I didn't get to answer in the, in the chat, so I'll do that live. Andrew, overrides are only for the devices that are targeted by that profile. So if you set, an override in there, that override will be sent to all of the devices in in that profile. The priority part you mentioned is about ensuring that only ever one profile is applied to any other device. And so that's why those numbers are there, because dynamic targeting could allow for you to to overlap those things, you could say Windows and host name contains a and there are lots of host names in that, but the the priority makes sure that only one of those would ever apply to those things. Yes, it should mean that if you apply an override, it will, only apply to the devices that are targeted by that one profile. Alright. Then I will go ahead and stop sharing here. Get the slides back. Give me one second. Alright. Actually, I'll talk really quickly about the best practices. We we we talked about the, you know, what profiles are. It's basically who gets what. Right? And the configurations are how the the sensor behaves, like what it's gonna do, the telemetry collection, all of that. You'll wanna start with a base profile. Those defaults are are okay from or excuse me. The migrated profiles are okay because they're your existing settings, but you'll wanna start thinking in the new paradigm here with profiles and configurations. And any changes that you make going forward, you'll you'll definitely need to do that because migrated profiles are, read only. As we mentioned here, clone the the default profiles. These are good. You can consider them as vendor managed templates in a way, because we're gonna put all of the optimal settings or the settings that will work out of the box for sensors to start collecting all of the the default telemetry that we expect. As I mentioned, you'll definitely want to test, these out on small groups, making sure that that criteria is defined properly and you're not over scoping and apply these, profiles, especially in the case of disabling a sensor to the wrong devices. Again, plan to move off of the default or legacy profiles. The these will be read only. You won't be able to do anything with them. Your TAM, CSM, or even support will be able to help facilitate, some of that conversation. And, again, overrides only for advanced use cases and often with supports guidance or TAM from from the TAM org as well. And that that that's pretty much it for the best practices, Ben. I'll hand it off to you for the road map slide. Perfect. And so to answer this, actually, we'll answer a little a couple of the questions that came through, in the q and a as we were going through. This is what we have called internally phase one of endpoint management, a a big step in the right direction to enable all of you guys to be able to manage and understand what's going on with configurations for your endpoints. But there will be one or two more phases of this where we look at delivering new things. And so the road map is is about allowing you to completely understand what's going on with those endpoints, to be able to see detailed information with regards to status and issues that are happening there, and actually support in the future to use, the integrations capability in the platform to send those things out as a as an incident or an event going into your third party systems, your civil, whatever it might be. There was a request about disable and enable. Absolutely. That functionality Ben showed you, we want to be able to enable that from the UI to be able to target an individual device and say, hey. I want to disable this one. Right now, you put it in a profile and target all of the devices. In the future, we'll be able to allow you to target an individual device and say, I only wanna look at Ben's one device and so I don't have to make a profile for that to do it. I can send an individual configuration down. Actions like restart or or those kind of things or maybe even do the troubleshooting the diab bundle, to be able to do that. Uninstall and update. Update if you're using SiteBehaven to deliver software, that's relatively easy to go and do. Uninstall is actually a little bit harder because uninstalling yourself, of course, means you can't validate that you uninstalled. But we think we've got a workflow for being able to do that, and so we'll look at all of those capabilities going forward. So, really, there'll be another section in there where we look at reporting metrics, troubleshooting, all of those, to really put in your own hands. I kind of I guess it's an overused term, but kind of shift left the support of your own endpoints, allow you to look at those things, allow the CX guys to help you with troubleshooting, send documentation, all of those kind of things, and you to get into the weeds and be able to do those things for yourself. So that's, planned for early in in next year. I guess somewhere between q one and q two, we'll, we'll be looking at delivering that. And, I as the as that becomes a reality, the CX team will be able to help you guys out with, with when that that's ready to go. And, Ben, I'm not sure if you mentioned this. Apologies in the beginning, but the API is available. Yes. I did. Yeah. You're you're absolutely right, Ben. We really tried hard, and we are trying hard with all of the functionality that we deliver to kind of come to an API first world. And if it's not exactly API first, maybe API very close second. In this case, in twenty five ten o two where we released the endpoint management functionality, the full set of management APIs are there. So everything that you can do in the configurations that Ben showed you, you can do via the API. You can see those things. You can get the list of devices. You can export those. You can get and manage the configurations. So if you want to work in a kind of configuration as code type environment, maybe pull it into your source code repository and keep it as a backup and those things, the APIs are there to help you do that work. Alright. And I can just kinda give a recap really quick here. So existing profiles, they're migrated as read only. I mentioned that a couple of times. Really wanna drive that home. You won't be able to make any changes after they migrate. The endpoint sensors view that you have currently today, once we do the migration or flip that feature flag, you won't be able to access that previous screen. Yeah. And then again, the the migrated profiles preserve the current behavior. So we we take all of those remote configs, flatten them out, apply them to the profile level. Obviously, not editable. Datatate changes, you'll wanna move those to new profiles. So you'll see your existing migrations and you'll try to start to think, how do I convert this to an existing, you know, profile and set of configurations? And as I mentioned, your CSM or TAM will get in touch with you about the, you know, low effort migration. I mean, it's really no effort in terms of migration. It happens automatically when we flip the the flag. But you'll have to start thinking in a different way going forward, and and we're here to help facilitate, some of that migration as well. And, all of the documentation is already online, so please feel free to check that out. API is available in the console as well. So the API spec, for that, feel free to check that out. If you have any questions, of course, always feel free to reach out. And, that concludes the presentation. Thanks so much, everyone. Really appreciate everyone's time. Obviously, if there we still have a couple of minutes here. If there are any other final questions, feel free to to answer or or pose them, and we'll we'll answer. Alright. Well, thanks again, everybody. Appreciate your time. Thank you.