As we mentioned in the last post, anti-malware tends to be the anchor in endpoint security control sets. Given the typical attacks that is justified, but too many organizations forget the importance of keeping devices up-to-date and configured securely. Even “advanced attackers” don’t like to burn 0-day attacks when they don’t need to. So leaving long-patched vulnerabilities exposed, or keeping unnecessary services active on endpoints, makes it easy for them to own your devices. The progression in almost every attack – regardless of the attacker’s sophistication – is to compromise a device, gain a foothold, and then systematically move towards the target.

By ensuring proper hygiene on devices you can reduce attack surface; if attackers want to get in, make them work for it. When we say ‘hygiene’ we are referring to three main functions: patch management, configuration management, and device control. We will offer an overview of each function, and then discuss some technical considerations involved in the buying decision. For more detail on patch and configuration management, see Implementing and Managing Patch and Configuration Management.

Patch Management

Patch managers install fixes from software vendors to address vulnerabilities. The best known patching process is monthly, from Microsoft. On Patch Tuesday Microsoft issues a variety of software fixes to address defects, many of which could result in exploitation of their systems. Many other vendors have adopted similar approaches, with a periodic patch cycle and out-of-cycle patches for important issues – generally when an exploit shows up in the wild.

Once a patch is issued your organization needs to assess it, figure out which devices need to be patched, and install it within the window specified by policy – typically a few days. A patch management product scans devices, installs patches, and reports on the success or failure of the process. Our Patch Management Quant research provides a very detailed view of the patching process, so check it out for more information.

Patch Management Technology Considerations

• Coverage (OS and applications): Your patch management offering needs to support the operating systems and applications you need to keep current.
• Discovery: You cannot patch what you don’t know about, so you need 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 vulnerability management (for active and passive monitoring for new devices), asset management and inventory software, or more likely all of the above.
• Library of patches: Another facet of coverage is accuracy and support of the operating systems and applications you use. We talk about the big 7 vulnerable applications (browsers, Java, Adobe Reader, Word, Excel, PowerPoint, and Outlook) – ensure those targeted applications are covered. Keep in mind that the word ‘supported’ on a vendor’s data sheet doesn’t mean they support whatever it is well. Be sure to test the vendor’s patch library and check the timeliness of their updates. How long do they take to package and deploy patches to customers after a patch is released?
• Reliable deployment of patches: If patches don’t install consistently – including updating, adding, and/or removing software – that means more work for you. This can easily make a tool more trouble than it’s worth. Do they get it right the first time?
• Agent vs. agentless: Does the patch vendor assess devices with an agent, or do they perform ‘agentless’ scanning (typically using a non-persistent or ‘dissolvable’ agent), and if so how do they deploy patches? This is almost a religious dispute, but fortunately both models work. If the patch manager requires an agent it should be integrated with any other endpoint agents (anti-malware, device control, etc.) to minimize the number of agents per endpoint.
• Remote devices: How does the patching process work for remote and disconnected devices? This includes field employees’ laptops as well as devices in remote locations with limited bandwidth. What features are built in to ensure the right patches are deployed, regardless of location? Can you be alerted when a device hasn’t updated within a configurable window – perhaps because it hasn’t connected?
• Deployment architecture: Some patches gigabytes in size, so some flexibility in distribution is important – especially for remote devices and locations. Architectures may include intermediate patch distribution points to minimize network bandwidth, as well as intelligent packaging to install only the appropriate patches on each device.
• Scheduling flexibility: Of course disruptive patching must not impair productivity, so you should be able to schedule patches during off hours and when machines are idle.
• Value-add: As you consider a patch management tool make sure you fully understand its value-add – what distinguishes it from low-end and low-cost (free) operating-system-based tools such as Microsoft’s WSUS. Make sure the tool supports your process and provides the capabilities you need.

Configuration Management

Configuration management enable an organization to define an authorized set of configurations for devices. These configurations control applications installed, device settings, running services, and on-device security controls. This is important because unauthorized configuration changes might indicate malware manipulation or operational error, perhaps exploitable. Additionally, configuration management can help ease the provisioning burden of setting up and reimaging devices in cas of malware infection.

Configuration Management Technology Considerations

• Coverage (OS and applications): Your configuration management offering needs to support your operating systems. Enough said.
• Discovery: You cannot manage devices you don’t know about, so you need a way to identify new deviceand get rid of deprecated devices – otherwise the process will fail. You can achieve this with a built-in discovery capability, bidirectional integration with vulnerability management (for active and passive monitoring for new devices), asset management and inventory software, or more likely all of the above.
• 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. This is especially important for highly regulated environments which need to support and report on multiple regulatory hierarchies.
• Policy editing: Policies generally require customization to satisfy requirements. Your configuration management tool should offer a flexible policy editor to define policies and add new baseline configurations and benchmarks.
• Scalability: Scanning each device for configuration changes can be demanding on both endpoints and the network, so understand how to distribute scanners effectively and be sure scanning frequency is flexible.
• Remote devices: How does assessment and management work for remote and disconnected devices? This includes field employees’ laptops as well as devices in remote locations with limited bandwidth. What kind of recovery features are built in to ensure devices are assessed in a timely fashion and remediated correctly, regardless of location? Can you be alerted when a device hasn’t updated within a configurable window – perhaps because it hasn’t connected?
• Agent vs. agentless: Does the configuration management vendor assess devices with an agent, or do they perform ‘agentless’ scanning (typically using a non-persistent ‘dissolvable’ agent), and if so how do they apply changes? This is almost a religious dispute, but fortunately both models work. If the configuration manager requires an agent it should be integrated with any other endpoint agents (anti-malware, device control, etc.) to minimize the number of agents per endpoint.
• Integration with operational process: Make sure any identified configuration issues are reported to the central help desk system to close the operational loop, ensuring a proper process for authorizing and applying changes. This may be managed within the endpoint security platform, but integration with enterprise systems can make things easier.
• Exception management: 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 configuration management detects (and perhaps reverses) the change. You must be able to handle these situations and without bogus alerts every time the device is assessed.
• Value-add: As you consider a configuration management tool, make sure you fully understand its value-add – what distinguishes it from low-end and low-cost (free) operating-system-based tools such as Microsoft’s SCCM. Make sure the tool supports your process and provides the capabilities you need.

Device Control

End users just love the flexibility USB ports provide for ‘productivity’. You know… the ability to share music with buddies and download your entire customer database onto their phones – it all got much easier once the industry standardized on USB a decade ago. The ability to easily share data really has facilitated employee collaboration, but it also greatly increased the risks of data leakage and malware proliferation. Device control technology enables you to enforce policy, both for who can use USB ports and how – and also to capture what is copied to and from USB devices. As an active control, monitoring and enforcement of device usage addresses a major risk on endpoints.

Device Control Technology Considerations

• Device support: The first order of business is to confirm the vendor supports the devices you need to protect. That means ensuring operating system support as well as the media types (removable storage, CDs & DVDs, tape drives, printers, etc.) on which to enforce policies. Make sure the product supports all the ports on your devices, including USB, FireWire, serial, parallel, and Bluetooth.
• Policy granularly: Make sure your product can support different policies per device. This enables you to set a policy to let an employee download any data to secure encrypted USB devices, but only non-critical data to smartphones. You should also be able to set up different policies for different classes of users and groups, as well as by type of data (email vs. spreadsheets vs. databases). You may want to limit the amount of data that can be copied by some users. This list isn’t exhaustive but make sure your product supports the policies you need.
• Encryption algorithm support: If you are going to encrypt data on removable media make sure your product supports your preferred encryption algorithms and/or hooks into your key management environment. You may also be interested in certifications such as EAL (Common Criteria), FIPS 140-2, etc.
• Small footprint, secure agent: To implement device control you need an agent on each protected device. Besides making sure the agent isn’t a pig, stealing massive amounts of compute power from each device, also ensure some kind of tamper resistance to protect the agents. It would be bad if an attacker disabled or subverted the agent…
• Integration with endpoint security platforms: Don’t reinvent the wheel – especially for cross-functional capabilities such as discovery, reporting, agentry, and agent deployment/updating/maintenance – so leverage your endpoint security platform to streamline implementation and for operational leverage. Ideally anti-malware, patching, configuration management, and device control can be handled by a common agent.
• Offline support: Devices aren’t always connected to the network, so make sure policies are still enforced even when they are disconnected. Also ensure you can configure policy violations alerts for disconnected devices, on reconnection.
• Forensics: In the event of data loss you will want forensics, so having the product log all user activity can be quite helpful. Some offerings also keep a copy of any files copied to protected device ports, which can serve as a smoking gun in the event of data loss.
• Exception management: There are times when policy may simply need to be overridden. Like when your CEO is trying to get a deal done at the end of the quarter and needs to share an agreement with a customer. Having the ability to allow certain employees to override policies (with proper alerting and audit trails) can make prevent tools from causing their own problems, and keep you employed.

Organizational Buying Considerations

These device hygiene tools are mature, so how should you choose? We will go into detail on the buying process later, but it depends on which group is responsible for these functions. If it is Operations, an operations-oriented platform with broad data center and server management capabilities is probably the way to go. On the other hand, if the endpoint/device team is responsible, a tool or platform optimized for endpoints makes sense. If auditors are driving the search focus on assessment for validation and reporting. If different teams handle different functions an integrated platform may not offer significant leverage. There is no right answer to this question, but make sure you are thinking about operational responsibilities as you work through the buying process.

Another point to keep in mind is that with mature technologies products rarely differ radically from each other. There are always differences in user experience and other marginal features, but primary feature sets converge over time. Our recommendation is to first decide how you want to work, and then find a tool or platform to automate it.

Our next post will discuss the impact of BYOD (employee-owned devices) and mobility on your endpoint security buying decision.