Implementing and Managing Patch and Configuration Management: Leveraging the Platform
This series has highlighted the intertwined nature of patch and configuration management. So we will wrap up by talking about leverage from using a common technology base (platform) for patching and configuration. Capabilities that can be used across both functions include: Discovery: You can’t protect an endpoint (or other device, for that matter) if you don’t know it exists. Once you get past the dashboard, the first key platform feature is discovery, which is leveraged across both patch and configuration management. The enemy of every security professional is surprise, so make sure you know about new devices as quickly as possible – including mobile devices. Asset Repository: Closely related to discovery is integration with an enterprise asset management system/CMDB to get a heads-up whenever a new device is provisioned. This is essential for monitoring and enforcement. You can learn about new devices proactively via integration or reactively via discovery – but either way, you need to know what’s out there. Dashboard: As the primary interface, this is the interaction point for the system. Using a single platform for both patch and configuration management; you will want the ability to only show certain elements, policies, and/or alerts to authorized users or groups; depending on their specific job functions. You will also want a broader cross-function view track what’s happening on an ongoing basis. With the current state of widget-based interface design, you can expect a highly customizable environment which lets each user configure what they need and how they want to see it. Alert Management: A security team is only as good as its last incident response, so alert management is critical. This allows administrators to monitor and manage policy violations which could represent a breach or failure to implement a patch. System Administration: You can expect the standard system status and administration capabilities within the platform, including user and group administration. Keep in mind that larger and more distributed environments should have some kind of role-based access control (RBAC) and hierarchical management to manage access and entitlements for a variety of administrators with varied responsibilities. Reporting: As we mentioned in our discussion of specific controls, compliance tends to fund and drive these investments, so it is necessary to document their efficacy. That applies to both patch and configuration management, and both functions should be included in reports. Look for a mixture of customizable pre-built reports and tools to facilitate ad hoc reporting – both at the specific control level and across the entire platform. Deployment Priorities Assuming you decide to use the same platform for patch and configuration management, which capability should you deploy first? Or will you go with a big bang implementation: both simultaneously? That last question was a setup. We advocate a Quick Wins approach: deploy one function first and then move on to the next. Which should go first? That depends on your buying catalyst. Here are a few catalysts which drive implementation of patch and configuration management: Breach: If you have just had a breach, you will be under tremendous pressure to fix everything now, and spend whatever is required to get it done. As fun as it can be to get a ton of shiny gear drop-shipped and throw it all out there, it’s the wrong thing to do. Patch and configuration management are operational processes, and without the right underlying processes the deployment will fail. If you traced the breach back to a failure to patch, by all means implement patch management first. Similarly, if a configuration error resulted in the loss, then start with configuration. Audit Deficiency: The same concepts apply if the catalyst was a findings document from your auditor mandating patch and/or configuration. The good news is that you have time between assessments to get projects done, so you can be much more judicious in your rollout planning. As long as everything is done (or you have a good reason if it isn’t) by your next assessment, you should be okay. All other things being equal, we tend to favor configuration management first, because configuration monitoring can alert you to compromised devices. Operational Efficiency: If the deployment is to make your operations staff more efficient, you can’t go wrong by deploying either patch or configuration first. Patch management tends to be more automated, so that’s likely a path of least resistance to quick value. But either choice will provide significant operational efficiencies. Summary And with that we wrap up this series. We have gone deeply into implementing and managing patch and configuration management – far deeper than most organizations ever need to get the technology up and running. We hope that our comprehensive approach provides all the background you need to hit the ground running. Take what you need, skip the rest, and let us know how it works. We will assemble the series into a paper over the next few weeks, so keep an eye out for the finished product, and you still have a chance to provide feedback. Just add a comment – don’t be bashful! Share:
