Implementing and Managing Patch and Configuration Management: Integrate and Deploy Technologies
By this point planning should be complete. You have designed your patch and configuration management processes, defined priorities to manage the devices in your environment, figured out which high-level implementation process to start with, discovered the devices in your environment, and performed initial testing to make sure the new technology doesn’t break anything. Now it’s time to integrate the patch and configuration management tools into your environment. Enough of this planning stuff, let’s get down to business! But you won’t actually remediate anything yet – the initial focus is on integrating technical components, installing agents as necessary, and preparing to flip the switch. Component Overview We are grouping patch and configuration management together, so we will talk about generic concepts like management servers and agents. A management server might be specifically associated with a patch management product and/or the configuration management environment. Obviously you want leverage between the two, but depending on which technologies you selected you might have different consoles and agents. But the deployment considerations are similar, regardless of the specific use case. Before we describe specific components we need to briefly go over the inherent security requirements of the different components. If an attacker can change the configuration of a device or apply a malicious patch, it’s pretty much game over. So it’s important to make sure the components are deployed correctly with appropriate security controls. Most solutions use some type of cryptography, both for authentication and to protect communications between components. We are not religious about specific authentication mechanisms (PKI or Windows or whatever), but be sure to check for recent attacks or vulnerabilities for whichever technologies you depend on. You may also want to consider two-factor authentication or some kind of privileged user management technology to better protect the management console. You will also need to coordinate with the network team to make sure the proper firewall ports are open (and/or proxies identified) to receive updates/new patches from vendors, and to communicate with the relays and/or endpoints using the ports specified by your endpoint security management vendor. Be considerate of the network security team, of course, who will likely resist opening up all sorts of ports throughout the environment. Default deny is still your friend – so when planning the deployment make sure you understand where the servers, distribution points & relays, and agents will be implemented, and how they communicate. Management Server/Appliance The management server is the brains of the operation. It holds the policies and provides the focal point for data aggregation, analysis, visualization, and reporting. You have a few options for how to implement the management server, so let’s discuss the pros and cons of each. Software: The most common choice is to install software on a dedicated server. Depending on your product this might actually run across multiple physical servers for different internal components such as a back-end database, or to distribute functions for better performance. Some products require different software components running concurrently to manage different functions. This is frequently a legacy of mergers and acquisitions – most products converge on a single software base, although integration may not be as complete as you would expect. Management server overhead is generally fairly low, especially outside large enterprises, so this server often handles some network monitoring, functions as the email MTA (for alerting), and manages endpoint agents. A small-to-medium-sized organization generally only needs to deploy additional servers for load balancing or hot standby. Integration is easy – install the software and position the physical server wherever needed, based on deployment priorities and network configuration, ensuring visibility to the relays and/or agents that need to communicate with it. Appliance: In this scenario the endpoint security management software comes preinstalled on dedicated hardware, presumably with a locked-down secure operating system. There is no software to install, so the initial integration is usually a matter of connecting it to the network and setting a few basic options – we will cover the full configuration later. As with a standard server, the appliance usually includes the ability to run multiple functions (though you might need licenses to unlock capabilities). Virtual Appliance: The endpoint security management software is preinstalled into a virtual machine for deployment as a virtual server. This is similar to an appliance but requires work to get up and running on your virtualization platform of choice, configure the network, and then set up the initial configuration options as if it were a physical server or appliance. For now just get the tool up and running so you can integrate the other components. Do not deploy any policies or turn on monitoring yet. Agents (or Not) Endpoint agents are, by far, the most varied patch and configuration management components. There are huge differences between the various products on the market, with far more severe performance constraints running on general-purpose workstations and laptops than on dedicated servers. Fortunately, as widely as features and functions vary, the deployment process is consistent. Test, then test more: We know we keep telling you to test your endpoint agents, but that’s not an accident – inadequate testing is the single most common problem people encounter. If you haven’t already, make sure you test your agents on a variety of real-world systems in your environment to make sure performance and compatibility are acceptable. That’s why choosing test devices in the preparation step is so important. Create a deployment package or enable in your EPP tool: The best way to deploy any agent is to use whatever software distribution tool you already use for normal system updates. There is no need to reinvent the wheel here. This means building a deployment package with the agent configured to connect to the patch and/or configuration management server. Remember to account for any network restrictions that could isolate endpoints from the server. In some cases the agent may be integrated into your existing EPP (Endpoint Protection Platform) tool. More often you will need to deploy an additional agent, but if it is fully integrated
