Transcript
systems, applications, and other software components. Patches are deployed to plug security holes, fix bugs, or just generally improve software performance. However, when you think about the thousands of or tens of thousands of devices supported in the average business, managing patch deployments to all these endpoints can be difficult, time-consuming, costly, and impactful to business productivity. And that is where patch management comes into play, providing policy-based approaches to patch delivery that reliably meet business requirements and overcome inherent risks associated with traditional patch processes. In regard to patch management, there are actually a wide variety of risks to your business that need to be addressed, and perhaps even a few that you haven't even considered yet. Easily topping the list, of course, is security risks. In fact, I think it's safe to say that most businesses introduce patch management primarily to respond to security threats. Whenever an operating system component or application is identified as exploitable by attackers, a patch is released to eliminate that vulnerability. However, time is of the essence here. The longer it takes to deploy security patches, the longer your environment will be vulnerable to attacks. Now we call this zero-day response, with the day zero indicating the time a software vulnerability is discovered. Security risks are mitigated with rapid deployment of security patches on or shortly after day zero to minimize the window of time attackers have to take advantage of that security vulnerability. Patch deployment actions can also introduce risks to your business network performance. Thousands of devices at a common location are all downloading patch packages at the same time, and that can have a profound impact on your LAN and WAN performance, which in turn could prevent some devices from successfully deploying patches. It's kind of a vicious circle. So proactive steps need to be taken to ensure patch distributions do not negatively impact your network performance. Another risk to consider is the reliability of the patches themselves. Patches are created by software providers, Microsoft, Apple, Google, Adobe, and so on. But unfortunately, they don't always get them right. You've probably experienced this yourself at some point. Patches are deployed to your PC and it suddenly starts running slow, or applications suddenly don't work, or the system completely crashes. To state the obvious, you need to be certain that the patches you are deploying to your environment will not inadvertently damage the devices you're installing them on. Patching processes can also have an impact on overall business performance. The act of installing patches on endpoints can slow down their performance, reducing workforce productivity. Even worse, patch deployments almost always require a reboot after their installation. Shutting down employee devices in the middle of a workday, as you can imagine, can be extremely disruptive to the business operations. It is very notable that resolving this particular challenge is in direct contrast to supporting zero-day response for security patches. You need to deploy your patches quickly, but you want to minimize the impact on your workers. And finally, there is also the risk of not being able to achieve compliance attainment. Compliance requirements typically go hand-in-hand with security goals, but include some very specific criteria. For instance, businesses may be required to deploy patches to, say, 95% of devices within X number of days of their release. Regulations and security requirements also typically include requirements for regulatory proof of compliance. A failure to achieve compliance requirements can often result in fines, a loss of customers, damage to a company's reputation, really bad things happen. So with these in mind, I want to go through each of these patch management risks and provide some guidance on best practices you can adopt to reduce these risks in your own environment. And in particular, we're going to take a look at the specific features within Avanti Neurons for patch management that were specifically designed to address these risks. Before we get to that, though, I just want to level set a little bit and provide just a quick, brief overview of Avanti Neurons for patch management, or perhaps just a review for those of you who already know the product well. Avanti Neurons for patch management is an integrated component of the cloud-hosted Neurons platform. It was purpose-built to enable autonomous patch delivery to Windows, Mac, and Linux devices across a bunch of different platforms. This includes devices that are on-premises and remotely distributed devices. In addition to operating system patches, it includes a library of thousands of supported application patches. Key differentiators for the Neurons patch include the ability to perform risk-based patching and to ensure patch reliability, which are obviously things I'm going to go into detail about very shortly. Now, under the covers, here's a very, very simple diagram showcasing how Avanti Neurons for patch management is administered and works. On each of the endpoint devices, a lightweight agent is installed that can be deployed either manually or directly from the management console. Agents are configured on the management console by defining the agent policy. Agent policies include configuration options such as where and how you want the device to download patches, what reboot experiences you want to give the users, and schedules for maintenance windows. Agent policies also define where patch configurations, which specific patch configurations will be used to deploy the patches. Patch configurations define what patches will be deployed, the date and time that they will be deployed, and other settings that govern patch delivery. A patch configuration can be associated with multiple agent policies, but each agent policy can only be assigned one patch configuration. So you can see how this relationship works here. Settings in an agent policy, and then they are associated with a patch configuration, and these inform the endpoint agent when and how to deploy the patches. Okay, with those basic concepts clarified, let's dive into our best practices for remediating patch management risks. And I'm going to start with managing security risks. And you'll remember that the key issue here is enabling that rapid deployment of security patches. Now, if you want to just hit this with a sledgehammer, I suppose you could just push out every single patch to every single endpoint as soon as they become available, but I think you know that's just not realistic. This is going to cause severe disruption to your production environment. And the majority of the patches actually do not require that level of heavy-handed sort of forced and quick delivery. So the trick here is to rapidly deploy only the patches that require that level of urgency. In Avanti Neurons, we support this with several capabilities. First, when defining patch configurations, we offer three different separate options for setting deployment schedules. Now, we call these deployment behaviors. They're routine maintenance, priority updates, and zero-day response. And you can use just one, or you can use two, or you can use all three of these to define different conditions under which to deploy a patch. And here is our first recommended patch practice for you to consider. Use all three to define different levels of security risk. For example, in routine maintenance, that's often intended to configure your most common patch deployments. These would be low- to medium-risk patches, things like bug fixes, and also really just about anything that you typically find in a Patch Tuesday package. In fact, maybe you only want to deploy these once per month on Patch Tuesday. That's a very common occurrence for many customers. Priority updates can be used to define schedules for higher-risk security patches, in particular, those that have been identified as addressing vulnerabilities in your environment. You'll want to deploy patch, excuse me, priority updates more frequently. Of course, perhaps maybe once per week, as opposed to once per month for the routine maintenance. And of course, you'll want to address those critical risks with patches that deploy according to a zero-day response. These are going to be those urgent patches that cannot wait because they fix vulnerabilities that are known to have been exploited. These critical patches are rare, but when they come out, you probably want to deploy them very rapidly, such as within a day, to minimize your exposure. Once you have turned on these deployment behaviors, you can select configure this task underneath each one of these to configure deployment options for each. Now, most notably, you'll be able to select the level of risk that you want to be associated with each one of these particular deployment behaviors. And you can see on the image on the right-hand side of the screen, we have several options for defining a patch risk level for a deployment behavior. For instance, you can use a CVSS score, which is a standardized score published by NIST. You could set that to a value of, let's say, 8, as you see here on the screen, to indicate that only patches with that value or higher will be deployed with this configuration. Now, if you're familiar with CVSS scoring, however, you're probably also aware that NIST tends to err to the side of caution, let's say, by assigning higher scores than are likely necessary. So you get a lot of 9s and 10s. They become very common. But this, unfortunately, can result in many patches being misidentified as high risk when, in fact, the risk is more moderate. A better indicator is Avanti's proprietary vulnerability risk rating, or VRR score, which leverages machine learning to evaluate threat intelligence, exploitability data, and asset context to provide a more reliable metric on risk. So I would recommend using the VRR score to identify the risk value on patches. Alternatively, or actually in addition to, it's your choice, you can also define patches to be included based on the severity that is assigned to the patch by the software vendor that made it. Now, for instance, your zero-day response, perhaps you only want to include patches defined as security critical by the vendor, as you see selected here in the image. Switching over to managing network performance risks, let's take a look at how you can reduce the impact of patch distribution across the LAN and WAN networks. Certainly, stretching your patch deployments over a long period of time can certainly reduce their network impacts at any given moment. However, not all businesses have this option. Many are constrained to deploy patches during a specific limited period of time. Avanti Neurons actually includes several capabilities for addressing this particular issue. The most direct method is setting the bandwidth utilization in the agent policy. Now, for example, as you can see here, by setting LAN utilization to, let's say, 80% will prevent patch deployments from saturating your local networks. It will simply slow down the patch deployments so they never exceed this speed limit. It may take a little bit longer to deliver the patches, but your network won't be impacted, which is obviously the goal. Another approach you can use is peer-to-peer networking. Rather than having every device at a site download patches simultaneously, which would have a severe impact on the WAN, you can have one device download it and then pass that patch on to its peer devices, eliminating that WAN bottleneck. Expanding on this concept even further, we've also introduced the ability to deploy patches using a preferred server. Put simply, a preferred server is a dedicated device for staging software components such as application packages, agents, and, of course, patches. With a preferred server installed, patches only need to be downloaded over the WAN a single time and can then be transmitted to each of the managed endpoints locally. Agent profiles allow you to prioritize where you want a patch to be downloaded from. For instance, if you want to set it up to download from a preferred server, you can set that, but if that's not available, it can download from a peer, and if no peer has the patch, then it can be downloaded from the cloud. Patch distributions over networks is fully customizable by Neurons administrators. Moving on, let's talk about managing patch reliability risks. You don't want bad patches damaging your end user devices, but how can you know for certain that a patch is reliable before deploying it to all the devices in your environment? Well, the most effective method is to test it on just a few machines before deploying it to your production environment, which is a capability Neurons supports with a process we call ring deployment. Put simply, ring deployment enables the systematic and phased rollout of patches to different groups of devices. First, go to group A, then deploy it to group B, and then deploy to group C, as an example. With Neurons for patch management, you can deploy a two-ring configuration or a three-ring configuration. That's using two groups or using three groups of devices. With a two-ring configuration, patches are first deployed to a set of test devices, and if determined to be reliable, are then deployed to the broader production environment. Now, with a three-ring configuration, we also add a middle early adopter deployment phase for further reliability assurance. Devices may be added individually to each ring, test early adopter or production, or device groups may be aligned with specific rings. So, for example, if you have a device group defined that includes all of your test devices in your environment, you can associate that test group with your test ring. Then, anytime you add a device to the device group, it is automatically added to the associated test ring. For clarity about ring deployment, I just want to step you through a typical ring deployment process with three rings. The rollout initiates with a scheduled deployment of patches to the test ring. We recommend this ring consists of only about 1% of devices in your environment, and they should include sufficient representation of the applications and the operating system supported in your organization. After successful patch deployment, you're going to want to wait for a sufficient period of time to recognize if the patch has any adverse effect on those endpoints. We call this the soak time. Patches will not progress to the next ring until and unless a predetermined percentage of devices have successfully deployed the patch and no issues have been detected during the soak time. Also, a feature unique to neurons is one that allows you to send surveys to the owners of devices to provide direct verification that the patches have not adversely affected the device. If this is enabled, then the patch will not progress to the next ring until a predetermined percentage of survey respondents indicated that it is reliable. When this reliability requirements are met, the patch rollout can proceed to the next ring, which in a three-ring configuration is the early adopter ring. We recommend about 9% of devices be deployed in an early adopter ring, and the process continues as it did in the test ring. Deploy to the endpoints, wait a predetermined soak time, and only progress if sufficiently achieving deployment and survey rates. At the end of this process, you will have a high level of assurance that the patches are reliable and safe, and you can deploy them to the production ring, which consists of all the remaining devices in your environment, and you should have no problems with that patch. Another point on dealing with unreliable patches, what do you actually do if you do experience a problem with the patch? Maybe you didn't use ring deployment, or you sent it out to the test device and it's showing an adverse reaction to that device. Well, to simplify remediation of that patch, we've actually introduced the ability to perform patch rollbacks directly from the management console. Patches that include rollback instructions in them, which are most notably Windows OS patches, are now denoted with a special icon you can see here on the right here next to it, on the right here next to the patch name, and it has this little circle with a clock in it, and that indicates that this patch can be rolled back. You can now select the same patch for multiple devices, and then under the actions menu here, you can select with a single click the option to roll back that patch, and then it will immediately roll them back to the previously installed and stable patch version. On the managing business performance risks, or minimizing impacts on the production environment and workforce productivity, we've actually addressed a great deal of this in our previous sections. Deployment behaviors that enable you to only force quick deployments on high-risk patches, network controls to minimize LAN and WAN impacts, and using ring deployment to ensure patches are reliable before deploying them to production. So all of this will mitigate business performance risks, but there's one more related feature I would like to share, and that's maintenance windows. You may recall that I mentioned maintenance windows either as an option you can configure in the agent policy. Maintenance windows allow administrators to restrict patch deployments to a specific time period. For example, you can see here patches are allowed to deploy outside of business hours between 10 p.m. and 6 a.m. You can also set cutoff times for patch deployments and their reboots. So you have a sufficient time to complete the actual patch deployment and the reboot process before the end of the scheduled maintenance window. In this case, before the start of the workday, your workers may start crawling in at 6 a.m. You want to make sure those patches have been installed and the reboot has completed. If it falls outside of these cutoff times, it will not deploy until the next maintenance window opportunity to deploy those patches. With maintenance windows set, you can be sure that patches will only deploy during these times and are not going to impact workers with their work efforts. Okay, on to our final section here. It's on risk mitigation category. It is about managing compliance risks, and on this particular topic, I'm delighted to be able to give you a little sneak peek of a revolutionary new feature we'll be introducing just next month in April with our upcoming product release. We call it continuous compliance. As I mentioned earlier, most organizations have compliance targets that are required to meet. For example, they need to ensure that 95% of devices need to be patched within, say, I don't know, five days of a patch being released. It could be shorter. It could be related to the severity of the patch, but everyone seems to have this internal compliance requirement, either set as an SLA or regulatory compliance. Now, typically, we find that most Neurons customers can easily make it to about 90% compliance, falling just short of that full compliance goal, and just to be clear, the problem isn't with the patching solution. The problem is on the endpoints themselves. A device was down. There was a network issue. It had a hung process. Something happened in the environment that prevented that patch from being deployed to those endpoints. Now, even though that particular issue that caused the failure is resolved, the device has still missed its scheduled patch deployment and will have to wait until the next schedule opportunity in order for it to be updated, and sometimes that next opportunity may be outside of the required compliance timeframe. So, to meet these compliance objectives, administrators often have to manually deploy a patch outside of the regular schedules. In order to close this gap on the compliance shortfall, continuous compliance is being developed to identify new non-compliant devices and then automatically remediate them with an out-of-band deployment schedule. So, here's how that works. Anytime a patch is deployed successfully to any device using a particular agent profile, that patch is automatically added to a compliance baseline patch group. This is a special patch group specifically curated by neurons for the purpose of keeping track of which patches should be included, should have been deployed to each of the endpoints. Now, by comparing what is actually installed on the endpoint device against what is expected to be installed as listed in the compliance baseline, we can easily identify which devices are out of compliance and what patches need to be installed to bring them back into compliance. Knowing this, we can now enable you to schedule an out-of-band deployment for remediating any non-compliant devices. As you can see in this screenshot, continuous compliance will be added as a new deployment option sitting alongside routine maintenance, priority updates, and zero-day response. It's a little bit different. You don't have to activate it. If you want to continue using things the same way they work today, just keep that disabled. But if you activate it, you will be given a set of configuration settings for scheduling how frequently you want these catch-up deployments to occur. In this example, you can see that it is set to run daily at 12 a.m. That means every day at midnight, neurons will check to see if any devices using the associated Asian policy are missing any patches listed in the corresponding compliance baseline patch group. If there are, then it will automatically deploy those patches and bring them back into compliance. And most importantly, it does all this without the need for administrators to perform manual tasks to remediate the non-compliance devices. It's pretty cool stuff. I haven't met one administrator yet who actually enjoys deploying patches manually. So I imagine most administrators are really going to appreciate this ability to proactively set an autonomous process for these ad hoc patch deployments. Speaking of compliance, I should also point out that Neurons includes a number of pre-built and customizable report templates specifically for status reporting and proof of compliance attainment. For instance, you can generate a report for all patches deployed on a set of devices or all devices on which a set of patches have been deployed. Reports can be generated on demand or on a recurring schedule. You could set them for every day, once a week, whatever you want. And you can then export them in a PDF, CSV, or Excel format. Or you can actually have these automatically delivered to you or to others via email. Thank you very much for attending today's meeting, today's presentation. I hope you found it educational and look forward to interacting with all of you as you use the Neurons platform.
