Transcript
continuous compliance, one threat after another. I'm Steve Brayson, Product Manager for Ivanti Neurons for Patch Management, and I will be your host for what I think will be an informative discussion about the challenges and solutions for achieving patch compliance in your organization. And in particular, we're going to take a look at Ivanti Neurons' new revolutionary continuous compliance functionality, what it does and how it works. Please note that you can submit questions at any time. I would very much encourage that. As time permits at the end of the presentation, I will try to answer as many of these as I can. Now, if you're struggling with meeting your patch compliance objectives, do not feel too bad. You're certainly not alone. Achieving patch compliance continues to be one of the most significant challenges in cybersecurity today. I want to start our discussion with a quick story. Back in the innocent pre-COVID days of 2017, Equifax, the credit rating agency, was breached by attackers taking advantage of vulnerabilities in some Apache software. The breach exposed the personal information of approximately 147 million people or roughly half the US population. The stolen data included social security numbers, birthdates, addresses, driver's license numbers and credit card numbers, making it one of the most damaging breaches in history. Now, after the breach, Equifax deployed patches to close that vulnerability. And they just assumed that they had resolved the problem. Well, flash forward a few years to 2020, three years later, Equifax conducted an internal audit and discovered, surprise, a number of forgotten servers were still out of compliance because they were offline during the patch deployment. Those unpatched devices caused extended regulatory scrutiny that cost Equifax millions of dollars in remediation and monitoring costs. Patch compliance is not something to take lightly. And unfortunately, it continues to be one of the greatest challenges in cybersecurity. And most businesses are not fully prepared to meet those requirements, especially with the shifting security landscape. Now, with apologies to Jeff Foxworthy, listed here are some indications you might be in need of a better patch management approach in order to enable patch compliance. So let's jump into reviewing some of those key challenges to achieving patch compliance today. And I imagine most of these will seem very familiar to you. First and probably most common challenge that businesses struggle with is the need to balance security objectives with business demands. Now on the one hand, patching is the cornerstone of cybersecurity. Roughly 60% of all data breaches are attributed to the exploitation of an unpatched vulnerability. That's 60%, very, very high. And the timeliness of the patch deployment is key. Immediately after a patch is released, hackers evaluated to see what security holes it is fixing that could otherwise be exploited. So your devices are particularly vulnerable from the time a patch is released until it is actually deployed in your environment. The longer it takes you to patch your systems, the longer you are vulnerable. Now on the other hand, it is important to minimize the impact on business performance when you do your patch deployments. Now let's face it. If all you really care about is security, you could just push out all the patches as soon as they are released. But I think you know what that will result in. Every worker's computer is going to reboot four or five times each day. Productivity will drop and you will have a very, very unhappy workforce. I think the first time the CEO complains about that particular impact to business productivity will be the last time that you'll be allowed to do that. Also if everyone downloads patches simultaneously, it could actually significantly impact your network performance. So it's not something you want to do. These two factors are constantly struggling against each other and you need to determine the correct balance between them based on your organization's risk appetite. That is the amount of risk you are willing to accept to support business demands. Patch reliability is another challenge to compliance achievement. It should come as no surprise that not all patches distributed by software vendors work the way they are supposed to. You've likely experienced this multiple times yourself. Patches are deployed to your PC and then suddenly it starts running slow or applications suddenly don't work right or the whole device crashes. As you can imagine, broadly deploying a bad patch across your company can bring your business to a screeching halt. Patching best practices suggest you should always test patches prior to broad deployment. But this can take time and that slows down your patch distribution, placing your patch compliance in jeopardy. So we've been talking about patch compliance requirements, right? But I want to be clear what we mean by that. When people think about patch compliance, they most frequently think about regulatory compliance. However, compliance objectives can also be defined in SLAs or by internal security auditors. Patch compliance requirements may also be needed to be defined to align with cybersecurity insurance requirements, if that's important to your organization. Typically, patch compliance is defined as a percentage of endpoint devices that must be patched within a fixed period of time. For instance, maybe 70, 97% of Windows devices must be patched within seven days of Patch Tuesday or something like that. More granular patch compliance requirements define scaled completion times based on the patch severity. For example, as you can see on the image on the right, 90% of all critical patches would have to be completed within seven days and then 75% of all high-priority within 14 days and medium-priority patches within 30 days. So whatever your internal requirements are, they will be very particular about how frequent you need to do your patching and when they need to actually be completed by. Regulatory requirements for patch compliance that I was just talking about are often the most stringent, especially for organizations with high security requirements such as government and financial institutions. Now, most of these regulatory frameworks allow businesses to define their own patch compliance requirement. But I've listed a few here that explicitly call out minimum expected patch deployment timeframes in order to achieve compliance. In working with many, many companies, we've discovered that it is typically easy to get close to defined patch compliance goals, but they are sometimes challenged to get over the finish line. Now, for example, they may have, say, a 95% compliance goal, but they top out at about 92% or 93%, falling just short of that compliance requirement goal. And to be clear, the reason they are falling short has nothing to do with whatever patch managing solution they're employing. The problem is with the endpoint. The system crashed. There was a network outage. The device had a hung process or a system complex. Something happened with that device to prevent the patch from being deployed successfully. So here you can see a timeline that represents a common scenario. A patch is released by a vendor. It is scheduled for deployment by the local patching service, that blue line on the left. But it then fails to deploy on one or more devices because, for whatever reason, those devices were unavailable or not operating properly. The devices may be repaired or powered down in the next day, but the problem is that the next patch deployment is not scheduled to execute until after the compliance deadline. For instance, if you had a one-week compliance deadline for delivery, but your patches are only delivered every two weeks, you got a one-week compliance gap between the time the device is now available and the time the patch would actually be deployed. Now in order to close this gap and ensure patches are deployed before the deadline, administrators are frequently required to manually patch out an ad hoc patch deployment to the non-compliant devices. And as you can imagine, putting this manual effort week after week to close that compliance gap can be time-consuming, frustrating, and really often error-prone because it is a manual process. A patch management should not require that level of babysitting, quite frankly. And unfortunately, all of these challenges are only accelerating. Now you've probably heard the term, the patch apocalypse. It's a real thing. I didn't make this up. This is something that is actually happening today. Basically to give you a high-level overview of what's going on, Anthropic, the AI company, recently introduced a new class of AI solutions. It was part of their project Glasswing approach, and the solution itself is called Mythos. It discovers vulnerabilities in software, and during the trial period alone when Mythos was first activated, it discovered more than 1,000 vulnerabilities in like 90 days. It was really crazy how many it discovered. And all of those vulnerabilities now need to be patched. So as more and more of these AI tools are being introduced, and there are more, Anthropic certainly was the one that garnered the most attention to it in the media, but there are many others. Basically every AI solution provider today is developing an equivalent. In fact, you may have seen that the new Daybreak solution was also announced by OpenText. So you're going to be seeing more and more of these tools become publicly available. And as more and more of these AI tools are being introduced, the number and frequency of patches is going to increase exponentially. Current estimates suggest we may be looking at tens of thousands of patches that need to be released each year. You think Patch Tuesday is bad? That's only once a month. Now imagine every Tuesday is Patch Tuesday, or imagine when Google patches for Chrome need to be deployed daily to close critical patches. The other element to this is that the AI is actually identifying vulnerabilities in old software that everybody kind of thought was safe. It's finding vulnerabilities that nobody knew about. So these are being surfaced. So now you need to patch these old software components in addition to the newer software components. So if you're struggling with patch compliance now, just wait. It's only going to get much, much worse. What can you do to meet your patch compliance requirements? Well, obviously, the platform that is near and dear to my heart is Vanti Neurons for Patch Management. And I want to share with you just some of the ways that we address the patch deployment issues that directly solve a lot of these challenges to patch compliance. To begin with, I want to very briefly provide an introduction to the platform for those who are unfamiliar with how it works. Vanti Neurons for Patch Management is a cloud-hosted, autonomous patch management and delivery platform that has been purpose-built for risk-based prioritization and compliance attainment across Windows, Mac, and Linux endpoints from a single unified console. Here is a very simple architectural diagram showing how Neurons for Patch Management functions. A lightweight agent is installed on all of the managed endpoints. On the Neurons cloud console, an agent policy is configured, which defines how these endpoint agents will function, things like where they will download the patches from, when will devices reboot, and if you want to limit patch deployments to a specific maintenance window. The Neurons console also enables you to configure a patch configuration, which defines which patches will be deployed and schedules when you will deploy them. Patch configurations are assigned to an agent policy, and the instructions are passed down to the client agent. Patch configurations allow you to set different schedules for three different deployment behaviors. For example, routine maintenance can be set for low and medium risk patches, so maybe just deploy these once per month, such as every Patch Tuesday, for example. Quality updates schedules are for more higher risk patches, so maybe you want to run these every week, and zero-day response schedules are for those critical patches with active known exploits. You'll want to patch these out as soon as possible, perhaps even every day. Within each schedule, you can define the level of risk you want to apply based on the VRR scores, which is Avanti's proprietary scoring method for risk. You could use the more common CBSS scores or vendor-assigned severity ratings. For example, for a zero-day response schedule, perhaps you only want to deploy patches with a VRR score of 9 or higher, and so you can dial in your deployments based on the level of risk that the patch deploys, and that will decrease the number of patches that need to be deployed at any given time in order to meet your compliance windows. One additional feature I want to share is also ring deployment. Now, earlier I talked about the dangers of deploying untested patches. Well, ring deployment solves this with a planned rollout through groups of devices. For example, patches may be deployed to a test environment consisting of just one of the devices. If patches are determined to be reliable, then they can be deployed to a second group of devices, the early adopter ring, consisting of about 9% of devices. If all goes well there, then they can be rolled out to the remaining 90% of production devices with a high level of confidence that they will not cause problems in your environment. With a basic understanding of Neuron's core patching functionality, I can reveal our latest and very exciting new feature, continuous compliance. Continuous compliance periodically checks endpoints to determine if all the required patches have been installed and automatically deploys any that are missing to ensure the devices are always in compliance. Now, the first step to identify what patches are expected to be deployed in order to be compliant, Neuron's automatically creates a list of patches for you. We call this list the compliance baseline patch group. Without going into too much description, it's actually an easy concept to understand, but I think it's better explained visually, so I've prepared a short video that demonstrates how this works. Continuous compliance is Avanti Neuron's for patch management's revolutionary feature for creating standardized compliance reports and the automated remediation of out-of-compliant endpoints. At the heart of continuous compliance is the dynamically curated compliance baseline patch group, which is automatically propagated at the time of scheduled patch deployments and operates autonomously and invisibly to the end users. Each agent policy will now have associated with it a unique patch group, which can be identified in the patch group list by a gear icon followed by the policy name. For example, selected here is the compliance baseline patch group associated with the AndyFF agent policy. This compliance baseline patch group will be automatically populated as patches are deployed in your environment. To help visualize how this works, here is a very simple Neuron's environment supporting two endpoints. Each endpoint is using the same agent policy, and Neuron's will now automatically create a corresponding compliance baseline patch group for that policy. When a patch is successfully deployed to either device, it is automatically added to the compliance baseline patch group. In this example, a second patch is also deployed, but is only successfully installed on the first device. Therefore, when comparing the patches that were actually installed on the endpoints against the compliance baseline, we can easily see that only the first device is fully compliant. With continuous compliance, devices are determined to be in or out of compliance as soon as patches are added to the compliance baseline patch group. This trigger is handled differently between standard scheduled deployments and ring deployments. With a standard scheduled deployment, a patch is added to the compliance baseline patch group shortly after one device using the associated policy successfully installs the patch during a routine maintenance deployment. Note that there can be up to a 15-minute delay between the successful patch deployment and the patch addition to the compliance baseline patch group. When using a ring deployment, compliance baseline patch group updates operate somewhat differently. In this case, patches are added immediately upon successful promotion to the final or production ring. This ensures that patches have been properly vetted in the prior ring before being identified as a compliance objective. Functionally, the compliance baseline patch groups are no different than any other patch group. Administrators can manually add patches to the compliance baseline or remove patches that are unnecessary for their compliance attainment. Please note though that once a patch is manually removed from a compliance baseline patch group, it will not be automatically re-added the next time that patch is deployed. However, the patch can be manually added back into that compliance baseline. Now that the baseline patch groups have been propagated with patches that were attempted to be deployed, administrators can easily monitor the success rate of expected deployments when creating a new report. Admins, of course, can select the policies they wish to review. We can then compare the status against the automatically populated compliance baseline patch group and run the report. Naturally, we can see these have all completed successfully, achieving a 100% compliance score. However, should any peer devices using the same policy be missing patches in the compliance baseline, it will be reflected as a negative in that score. Over time, this report will identify the actual success rate of expected deployments, providing a standardized indicator for compliance attainment. The first piece to this, the creation of a compliance baseline patch group, and I think it's very important to note that the curation of that compliance baseline patch group is all taken care of automatically by Neurons. As you're deploying patches, we are creating a list for you. You don't need to do anything to maintain this list, unless, of course, you want to go in there and make alterations by adding or removing patches to this list. I think that's going to be an unusual use case, but it might be in the case where you want to have a very specific compliance goal for attainment in your organization. Only these specific patches do we need to meet for our compliance. You can curate your own list if you want to. Now that we have the compliance baseline patch groups, though, things get really interesting because we can discover which devices are out of compliance and initiate a deployment to bring them back into compliance before the compliance deadline and without the need for manual administrator interaction. I actually have another short video to share to demonstrate how this new continuous compliance scheduling works. Continuous compliance scheduling and optional settings are visible and accessible as a deployment behavior option under patch settings, located beneath the routine maintenance, priority updates, and zero-day response scheduling options. With the initial release, continuous compliance is only supported on Windows deployments. However, Mac and Linux support our plan for future delivery. When activated, continuous compliance tasks will execute at a designated time. For example, seen here, continuous compliance is scheduled to execute every day at 11 p.m. At that time, two tasks will be performed on every device utilizing that policy. First, neurons will compare patches actually installed on the endpoints with those listed in the associated compliance baseline patch group. And second, any devices determined to be missing required patches are immediately brought back into compliance by executing an out-of-band patch deployment. Continuous compliance schedules are fully customizable, with options consistent with other patch deployment schedules. These include the ability to initiate continuous compliance on a daily and weekly basis. And you can honor maintenance windows. If selected, missing patches will be deployed to endpoints at the start of the next defined maintenance window following the continuous compliance execution. Content can also be staged on the endpoint for up to 23 hours before a continuous compliance deployment. And pre- and post-deployment reboot options are also included for consistency with other deployment behaviors. There you have it. Continuous compliance. I think you can see why we're so excited about this new feature. Devices can set a recurring schedule defining when neurons will check for noncompliant devices and then automatically bring them back into compliance without the need, most notably, to perform manual or ad hoc patch deployments. Thank you very much for your time today. I hope this was helpful for you. And we'll talk to you on the next event. Thank you. Thank you. Thank you.
