Transcript
increasing your protection while minimizing your disruptions. So my name's Abdul Azizi. I'm a sales engineer with Avanti specializing in security. And joining me today is Kieran. Want to introduce yourself, please, Kieran? Hey, Abs. Thanks for having me. Kieran Shelley, solutions engineer. And I'll be looking at how this kind of impacts our service management and change management processes while Abs walks us through how to minimize those disruptions. Thank you. So this session follows on from the previous session, which Kieran was in as well, by the way, with Shane Westcott around risk visibility to risk tolerance. So let's get into it. Now, one of the big things around the fixes that come out of the risk tolerance is looking at your patching. So we've ran a survey a while back, and the sort of result we got was 71% of IT security pros say patching isn't easy. Now, some people might be thinking, oh, well, it is. It might be the case for operating systems. But once you start looking at more complex things and start looking at risk-based approaches, it can get more difficult, especially around the third-party applications. So what we do around that is we take what we call a risk-based approach. So the points we've got here, scanners produce a lot of data. Data is great, but they can't always fix everything with scanners. Another point here around the CVSS scores, once again, they're really good, probably great for a point in time. But as threats advance and things change out in the greater web, I guess, those scoring might not be accurate. They might go up, they might go down. So we'll have a look at that side as well. Vulnerabilities that are weaponized and exploited in days. So you've got to be really ahead of that. And using a risk-based approach, you can get ahead of that. And then finally, urgent need to address exposures from ransomware and automated threats. So maybe something comes through security team, we've got to get this done now, guys, probably comes through something like RBVM. And then for things that can't be fixed by patches coming through there, we're going to look at neurons bots. So not all vulnerabilities can be resolved by patches, as mentioned. So what we've got in our bot space is we can do easy to create, I guess, automation that can go and fix problems around configuration, maybe ports or something like that. And I'll show you a good example of that. And I'll show you a good example of that that I've found. Cool. So this is the advanced neurons platform, probably seen it a bit already. The parts that we're going to be interested in today is going to be around the patch management side. So let's start by looking at patch intelligence. So from the previous session mentioned around the risk tolerance, what we had there was working through the RBVM platform to detect the data from your scanners and prioritize what you want to patch. Now that gets sent into here, which is our patch intelligence platform. What this does is effectively it's like a big research tool, but also can be used to then move into fixing. So what we're going to look at here is we're going to take a look at the group that was created in the previous one. Get that loaded up. And we can see that these are the patches that came through it. If we scroll across, we can see more information around reliability, for example. I can show how we can touch on that in a little bit. But effectively what this does will show you what will be required to, sorry, is there any known issues in rolling out this particular patch? We also have more information here around what they address. We can see CVE counts. We can see the RR, which I'll touch on in one sec. But let's take a look at what this means here with the log. So what that is, is there isn't actually an active exploit used that this would address. We can see here it's a dial service attack that it can be used on. And that's what we're seeing for that bug. It also gives you that list here. You can click on them and then go have a look at what those are. Let's just quickly move back here. Oops, let's open that back up. From here as well, we've also got the VRR ratings. So what these are is effectively a proprietary score that we give it. We base it on different metrics, such as what the vendor put forward. So for example, the CVSS scores, what the product is, how it's utilized, what is the vulnerability itself? Is it remote code execution? Is it privilege escalation? That sort of stuff. Is it being actively targeted? For example, like these two here, we can see they have active exploits. All of these come into play, including what threat actors are using it. From there, we can build our own score. So those will differ from the actual CVSS score. Now, how we utilize that, once it comes in from the RBVM platform, we can select these. Then we could go... Oh, apologies. Not sure what to do. It's already in part of the patch groups. That gets utilized by our patch settings. So why don't we take a look at those now. This is the one that we have here. Just hit edit to work backwards from it. Excuse me. We'll start right down the bottom in the zero-day response group. So we can see we've got three here. And this is what we take into account with our risk-based approach. So we have our routine, which will be a monthly check. Just check what we need to do. Our priority updates, anything weekly, maybe something that's deemed important, but not like a high or critical. We hit those every week. And then we have our zero-day. So let's start with a zero-day. The way that this is configured is we have everything turned off here, with the exception of deploy by patch group. You can see the RBVM group that we were looking at just then, that's the one that gets deployed here. Meaning every 24 hours, each machine will scan and check themselves against this group. If they need patches from it, it'll get applied. So that group can stay static, or you can add to it. So using the RBVM platform that you would have seen in the RISC session, through the processes in there, they can keep adding to that group. And by default, just completely automated, behind the scenes, these critical updates will keep rolling out. In the priority updates group, we have something similar as well. We have a priority desktop updates group that we've got here. That one's applied. It's doing exactly the same thing that we're seeing in the previous group. These are just going to be like a lower risk that we can roll out in a smaller amount of time. With these patch groups as well, let's say hypothetically there's certain things you don't want to update, we can actually just say select something. We'll just say this one for argument's sake. And we can hit exclude. So that might include things, say Java, that might break an application. Maybe you don't want those to roll out. You can exclude those as well and just keep your system happy. So those are the two big ones for the RISC-based approach. But the regular cadence, that's here in the routine maintenance. Now, this is where we can do things a bit differently. So I'll just click that off for the time being. You can set your schedule here. You can see this one we've set to patch Tuesday plus one day, but you can set that to whatever you want, what time you're going to run with, etc. And enforce it during maintenance windows and things like that that you might apply to your agent policies. With this one, we're going to be staging our patches. And this is looking specifically for any patch in our catalog that's deemed critical, important, either security or non-security. Very plain and simple. Now, if you do want to be a bit more targeted, you can turn it on here and find whichever patch that you want to do or whichever vendor. So we've got Microsoft, for example. Maybe you want to just apply these to, what's something interesting, Office. Why not? So maybe you just want to do it to Office. In that case, this group will only apply to Office. Or if you turn that off, it will just apply to everything that we've got there. Now, something that we've added in quite recently is ring deployment. Let's flick that on. You can run three rings or two rings, depending on what you want to do. The promotion can also be set to automatic or manual. So maybe you want to do your test manual and your early adopter automatic, depending on the results. So from here, you can configure days until production ring, so when you're going to kick off, days after patches as deployed, et cetera, like we saw before. What sort of success rate do you want to see? And what sort of soak time do you want to have? We can also set up patch surveys and user surveys. I'll show how we can configure those in a bit. But effectively, after we do, we can just come to this dropdown list and pick it. And then we can promote patches based on the survey results. So if it comes back and saying, oh, how did this patch go? It failed or broke something, we can then use that to promote certain ones and not all of them. We have the same settings here on the early adopter ring. The difference is we can see we've got one to manual, one to automatic. So we can configure what we want to do here, also use a survey. And once that goes through, it then hits everybody, production. So we'll just go through with that. If we're going to look at those surveys, they live under neurons bots. If we go to survey bots, then we can go and create one. Let's say we'll go patch, automatically defaults to devices, because that's how we target our patching, not by user, obviously. We can call this survey, because I'm very creative. Here, set it to active. And then we can set up our interactions. So let's say you want to do team's rating. We'll join her up. You have your stage timeouts and things like that. Not super relevant to us here. We can submit result to patch. So what this does here is it maps the user score to the patch record for problem analysis. So when you saw reliability and things like that, that can affect that as well. So from here, we can set it to auto detect users. And we call it patch testing. And the question could be something along the lines of, how was your patching experience? Then we can configure different types of choices. So we can have a binary, we could have emojis, simple radio buttons, or stars. So let's just leave that as stars for now. Now, following on from that, we can do a sentiment. So with this one, oops, link her up. Now, that gives us the option to associate it with a stage. We can associate it with a rating or testing. Give it a submit button, just a simple name of submit. We could say, so please elaborate on your experience. So staying with the bots, we talked about in the slides just before, about how we can remediate configuration-based vulnerabilities without using patches. So I've made one here that we can take a look at. So what this particular one is, is the CVE that got released, that was around Kerberos certificate authentication, where expired or non-trust certificates could actually still authenticate and move forward for Active Directory. So what the patch did was it gave the options to properly enforce this. So it didn't enforce it itself because it may have broken other people's environments and things like that, left it up to the customer or whoever to then go and resolve it. So what we've set up here is a pretty simple step-by-step bot that will go through and look at that. So the very first step is to check the OS. It needs to be a server for this particular one, so we're looking for Windows Server, you know, 20 or whatever, because this applies from 16 to 25. We check the build, and the purpose of the build is to ensure that the patch that enables these settings was actually applied. We filter on that to make sure we get those out of it, and then we make sure it's domain controller, and that's all it really applies to. We filter those results and we pass it through to here, but we then set the registry setting that will enforce the certificate authentication. So once that's all configured, you can go run this on a schedule and maybe just say, hey, run against the fleet and let's go from there, or you can run it as a custom action like I've got here. So let me just cancel out of this. We'll jump into devices. Cool. So to run that, we'll just select one of the devices, give it a sec there, it's just having a bit of a think. There they are. Now we can select resolve Kerberos cert-based auth. A bit of a tongue twister for me there. We'll just run it. There we go. Runs against it, sets what needs to be set, checks everything, and gets it done. So now over to Kieran to see how that all sort of plugs in to your ITSM and ITAM environments. Thank you, Abs. And yeah, really cool. I do like the patch surveys. You get an immediate feedback. You can do it through the emojis and you deploy a patch to a subset of devices through that ring deployment, and then you can get real feedback or real-time feedback. And even if a patch is perceived to be good, it could have a conflict in your environment. And yeah, you can get those unhappy emoji faces straight back into the team and they know there's something wrong. Exactly. And being able to promote as well based on the result of that particular survey for the particular patch as well. It's just, yeah, it's really useful. It means that you're not going to waste a patch cycle, right? Yeah, that's good. So how does that impact service management practice, and in particular around CMDB and change management? I'm a big believer that the more information we can get from a change management perspective, the better. So we can have all the CMDB information in there, dependency maps, SMEs and stakeholders for services and those devices that are supporting that service. But also, if we can get a security posture understanding, again, it's just adding to that repository of information we can use for risk analysis and running that successful change. And you can see here, just a few pointers where understanding our position really, really helps make those changes successful. I think just particularly just understanding vulnerabilities, you may be running a change management process against a service. Are all the servers up to standard? Are they all patched properly from an OS perspective and app perspective? If you know that information firsthand without having to go and find it and in real life, from a service management perspective, I don't know who the people are who are patching. I don't know the people who are looking at exposure management. If I can have that information just piped through from the platform, it makes my life a lot easier. We do have an integration straight into the CMDB where I can see the patches. So, what apps are showing there in terms of the patches that have been deployed to the various devices, I get that information back to each individual device. And again, I can have a look at that when I'm thinking about changes or it could be helping my incident management process, my problem management process. They're all being assisted here by understanding the security posture of that device. And we spoke about the RBVM ITSM integration in an early session with Shane where we were pushing through from the risk-based vulnerability solution. Shane was able to create some security incidents and then I could go on and do some risk analysis and checks there from a risk and compliance perspective, helping with change controls, which we've just been talking about. And also, when a device has an exposure on it and we get, as part of discovery, we can have that exposure management piece where the scanners or our native Advanti scanner is providing information about potential exposures. That's going to impact your digital experience score on your device. A lot of exposures, obviously bad experience, zero exposures, obviously that's going to be better. So we can capture that as well in those text scores. I will just pop into the service management tool now and I'll just quickly show us what that looks like. So I have a standard asset here. We've brought it in through discovery. We have all the information that we found, all the attributes to software, network information, but now I also have patch summary. So I'm able to grab those patches that have been deployed through patch intelligence. And also, I can quickly refresh that and see if there's anything new. And there we can see it's grabbed a few more. So every time we come in and check this individual device for information, I can get a refresh of those patches and not only see which patches have been deployed, but where they're up to. So I know that this device here is pending a reboot. So it's especially important if we're looking to make changes to service, et cetera. If I change, if I make an update to a server, what else is pending? And we can see here there's a few other application or other patch installs that are pending that reboot. So more configuration changes are going to be made, which I need to be aware of from a change management, change control perspective. And that's all for me. Abs, back to you just to finish up. No worries. So what we just looked at. So we had a quick look at vulnerabilities based on exploits and risks. So looking at those patch groups and how we can deploy them through what we saw in the second part, the risk-based approach for our patch strategy. We configured the ring deployments and looked at how they came together. Took a quick look at the patch surveys, how to create them. And then also looked at resolving a CVE, which cannot be fixed by a patch. And then finally, you bring it all back around, keeping the CMDB as the source of truth. Kieran showed us how that's all comes back in there and can be used for planning of your future changes and things like that. So the solutions used across this was neurons for patch management, neurons for healing, and of course, neurons for isolation. And that's what we had for you today. Thanks for hanging out with us and checking this out.
