As we discussed in the Endpoint Security Management Lifecycle, there are controls you use periodically and controls you need to run on an ongoing basis. This post will dig into the periodic controls, including patch and configuration management.

Patch Management

When Microsoft got religion about the security issues in Windows XP about a decade ago, they started a wide-ranging process called Trustworthy Computing to restore confidence in the integrity of the Windows operating system. That initiative included a monthly patch cycle to fix software defects that could cause security issues. Patch Tuesday was born, and almost every company in the world has since had to patch every month.

Over the past decade, many software companies have instituted similar patch processes across many different applications and other operating systems. None are as regimented or predictable as Microsoft’s, and some have tried to move to a silent install process, where no effort is required of the customer organization. But most security and operations personnel don’t feel comfortable without control over what gets installed and when. So organizations needed to look beyond tactical software updates, considering patching as an operational discipline. Once a patch is issued each organization needs to assess it, figure out which devices need to be patched, and ultimately install the patch within the window specified by policy – typically a few days. Let’s dig a bit deeper.

Patching Process

Patching is an operational discipline, so an organization’s patching process must first be defined and then automated appropriately. Securosis documented a patch process in Patch Management Quant and if you are looking for an over-arching process for all your patching we recommend you start there. You can see the process map is detailed and granular – just use the parts that make sense in your environment.

Let’s hit the high points of the process here:

• Define targets: Before you even jump into the Patch Management process you need to define what devices will be included. Is it just the endpoints or do you also need to patch servers? These days you also need to think about cloud instances. The technology is largely the same, but increased numbers of devices have made execution more challenging. In this series we largely restrict discussion to endpoints, as server operations are different and more complicated.
• Obtain patches: You need to monitor for the release of relevant patches, and then figure out whether you need to patch or you can work around the issue.
• Prepare to patch: Once the patch is obtained you need to figure out how critical fixing the issue is. Is it something you need to do right now? Can it wait for the next maintenance window? Once priority is established, give the patch a final Q/A check to ensure it won’t break anything important.
• Deploy the patch: Once preparation is done and your window has arrived you can install.
• Confirm the patch: Patches don’t help unless the install is successful, so confirm that each patch was fully installed.
• Reporting: In light of compliance requirements for timely patching, reporting on patching is also an integral function.

Technology Considerations

The good news about transforming a function from a security problem to an operational discipline is that the tools (products and services) to automate operational disciplines are reasonably mature and work fairly well. Let’s go over a few important technology considerations:

• Coverage (OS and apps): Obviously your patch management offering needs to support your operating systems and applications. Make sure you fully understand your tool’s value – what distinguishes it from the low-end operating system-centric tools such as Microsoft’s WSUS.
• Discovery: You can’t patch what you don’t know about, so you must ensure you have a way to identify new devices and get rid of deprecated devices – otherwise the process will fail. You can achieve this with a built-in discovery capability, bidirectional integration with asset management and inventory software, or (more likely) both.
• Library of patches: Another facet of coverage is accuracy and support of the operating systems and applications above. Just because something is ‘supported’ on a vendor’s data sheet doesn’t mean they support it well. So make sure to test the vendor’s patch library and check on the timeliness of their updates. How long does the vendor take to update their product after a patch is released?
• Deployment of patches and removal of software: This is self-explanatory. If patches don’t installed consistently or devices are negatively impacted by patches, that means more work for you. This can easily make the tool a net disadvantage.
• Agent vs. agentless: Does the patching vendor assess the device via an agent or do they perform an agentless scan (typically using a non-persistent or ‘disolvable’ agent), and then how to do they deploy patches? This borders on a religious dispute, but fortunately both models work. Patching is a periodic control, so either model is valid here.
• Remote devices: How does the patching process work for a remote device? This could be a field employee’s laptop or a device in a remote location with limited bandwidth. What kind of recovery features are built in to ensure the right patches get deployed regardless of location? And finally, can you be alerted when a device hasn’t updated within a configurable window – perhaps because it hasn’t connected?
• Deployment architecture: Some patches are hundreds of megabytes, so it is important to have some flexibility in patch distribution – especially for remote devices and locations. Architectures may include intermediate patch distribution points to minimize network bandwidth, and/or intelligent patch packaging to only install the appropriate patches to each device.
• Scheduling flexibility: Of course it’s essential that disruptive patching not impair productivity, so you should be able to schedule patches during off-hours or when machines are idle.

There are many features and capabilities to consider and discuss with vendors. Later we will provide a handy list of key questions.

Configuration Management

As we described in the ESM Lifecycle post: Configuration Management provides the ability for an organization to define an authorized set of configurations for devices in use within the environment. These configurations govern installed applications, device settings, running services, and security controls. Where patch management focuses on addressing vulnerabilities, configuration management protects against inadvertent changes (typically during operational updates or reconfiguration) by defining entitlements for what should run on each device, and identifies non-compliant devices. Configuration management also detects and remediates changes made by malicious software. It’s important to see both sides of the coin – an unnecessary service or listener can compromise even a patched device.

Configuration Management Process

We haven’t documented the configuration management process as thoroughly as patching, but let’s take a high-level look to see how it works.

• Establish configuration baselines and/or benchmarks: First define acceptable secure configurations for each managed device type. Many organizations start with the benchmarks from CIS or NIST for granular guidance on how devices should be configured.
• Discovery: Next find the devices that need to be managed. It helps if you can leverage an endpoint security management platform with an integrated asset management repository. You will also want to categorize and group assets to avoid unnecessary services. Engineering workstations, for example, require different configuration than Finance systems.
• Assess, alert, and report changes: Once devices are discovered and categorized, define a frequency for assessments. How often will you check them against policy? Some vendors use the term “continuous assessment”, but their assessments aren’t really continuous. Fortunately this isn’t normally a problem – not least because most operational groups wouldn’t be able to validate alerts and perform corrections in real time anyway.
• Remediate: Once a problem is identified, either it needs to be fixed or someone needs to grant an exception. You are likely to have too much work to handle it all immediately, so prioritization becomes a key success criterion. We have offered perspective on prioritization for vulnerability management, but the concepts are the same for configuration management. You will also probably need to verify that changes actually took place for the audit.

Technology Considerations

As with patching, configuration management tools have been around for a while and are reasonably mature. There are many similarities to the technology considerations presented above for patch management. There is significant leverage to be gained from a single platform which handles both periodic endpoint security management functions.

• Coverage (OS and apps): Of course your configuration management offering must support your operating systems. And make sure you understand its value over and beyond low-cost operating-system-centric tools such as Microsoft’s SCCM.
• Discovery: You can’t manage configurations you don’t know about, so you need to ensure you have a way to identify new devices and purge deprecated devices. This can be managed through a built-in discovery capability, bidirectional integration with asset management and inventory software, or more likely both.
• Supported standards and benchmarks: The more built-in standards and/or configuration benchmarks offered by the tool, the better your chance of finding something you can easily adapt to your own requirements.
• Policy Editing: Policies generally require customization to satisfy your needs. Your configuration management tool should offer a flexible policy editor to define policies and add new benchmarks.
• Scalability: Scanning each device for configuration changes can be demanding of both the endpoint and the network, so understand how to distribute scanners effectively and make sure scanning frequency is flexible.
• Dealing with remote devices: How does assessment work for a remote device? This could be a field employee’s laptop or a device in a remote location with limited bandwidth. What kind of recovery features are built in to ensure the correct remediations are implemented regardless of location? And finally, can you be alerted of devices which haven’t been assessed recently – perhaps because they haven’t connected?
• Agent vs. agentless: Does the configuration management vendor use an agent to perform assessment, or do they perform agentless scans (typically using a non-persistent ‘disolvable’ agent), and then how to do they apply changes when necessary? This borders on religion, but fortunately both models work. Configuration management is a periodic control, so either model is valid here.
• Integration with operational process: Make sure any identified configuration issues are reported to the central help desk system to close the operational loop, authorizing and applying changes. This may be managed within the endpoint security management platform but integration with enterprise systems can make things easier.
• Process to deal with policy exceptions: As mentioned above, there may be situations where a configuration change represents an authorized exception. To make things more fun, authorization is often granted after the configuration management detects (and perhaps reverses) the change on initial detection. You must be able to handle these situations and without bogus alerts every time the device is assessed.

More Food for Thought

Despite the maturity of patch and configuration management, a number of emerging technologies impact these processes. For instance, some organizations are considering virtual desktops (VDI) to improve endpoint management. You need to understand how your tool supports VDI and which virtualization infrastructure products it can manage. The goal is to avoid a separate management capability for the virtual environment. Cloud instances are similar but generally handled within the server context. We could write an entire series on that – and probably will – but for now we just note that managing cloud devices adds a layer of complexity for patching and configuration management.

We also need to recognize the impact of mobile devices on endpoint security management. For the time being, mobile device management (MDM) offerings have emerged to address the management need, but we expect to see leverage from managing all devices (both PC and post-PC) from a single platform.

Finally consider alternative deployment models – which many include Software as a Service (SaaS) or cloud management console alternatives. Obviously to assess and patch internal devices, you need some kind of internal device (usually a virtual machine or physical appliance) as the inside control point, communicating results and taking direction from the cloud. This is another semi-religious decision, and we still see a majority of organizations deploying onsite platforms for endpoint security management. But that looks likely to change over the next few years.

Initial Buying Considerations

Patch and configuration management tools are mature. So how should you choose? We will go into detail later but it depends on who is responsible for patching and configuration management. If it’s Operations, an operations-oriented platform with broader data center and server management capabilities would be a better fit. On the other hand, if the endpoint/device team is responsible, a tool or platform optimized for endpoints makes sense. If auditors are the driver focus on assessment capabilities to validate and report. If different teams handle different functions an integrated platform may not offer leverage.

With mature technologies products are rarely radically different from each other. There are always differences in user experience and marginal features, but primary feature sets are consistent. First decide how you want to work, and then find a tool or platform to automate it. That’s why we start with process and then automate as appropriate.

Our next post will move on to ongoing controls: device control and file integrity monitoring.