Endpoint Security Management Buyer’s Guide: Ongoing Controls—Device Control

By Mike Rothman

As we discussed in the Endpoint Security Management Lifecycle, there are controls you run periodically and others you need to use on an ongoing basis. We tackled the periodic controls in the previous post, so now let’s turn to ongoing controls, which include device control and file integrity monitoring. The periodic controls post was pretty long, so we decided to break ongoing controls into two pieces. We will tackle device control in this post.

Device Control

Device control technology provides the ability to enforce policy on what you can and can’t do with devices. That includes locking down ports to prevent copying data (primarily via removable media), as well as protecting against hardware keyloggers and ensuring any data allowed onto removable media is encrypted. Early in this technology’s adoption cycle we joked that the alternative to device control involves supergluing the USB ports shut. Which isn’t altogether wrong. Obviously superglue doesn’t provide sufficient granularity in the face of employees’ increasing need to collaborate and share data using removable media, but it would at least prevent many breaches.

So let’s get a bit more specific with device control use cases:

  • Data leakage: You want to prevent users from connecting their phones or USB sticks and grabbing your customer database. You would also like to allow them to connect USB sticks, but not copy email or databases, or perhaps limit them to copying 200mb per day. Don’t let your intellectual property escape on removable media.
  • Encryption: Obviously there are real business needs for USB ports, or else we would all have stopped at superglue. If you need to support moving data to removable media, make sure it’s encrypted. If you think losing a phone is easy, USB sticks are even easier – and if one has unencrypted and unprotected sensitive data, you will get a chance to dust off your customer notification process.
  • Malware proliferation: The final use case to mention gets back to the future. Remember how the first computer viruses spread via floppy disks? Back in the day sneakernet was a big problem, and this generation’s sneakernet is the found USB stick that happens to carry malware. You will want to protect against that attack without resorting to superglue.

Device Control Process

As we have mentioned throughout this series, implementing technology controls for endpoint security management without the proper underlying processes never works well, so let’s quickly offer a reasonable device control process:

  • Define target devices: Which devices pose a risk to your environment? It’s probably not all of them, so start by figuring out which devices need to be protected.
  • Build threat models: Next put on your attacker hat and figure out how those devices are likely to be attacked. Are you worried about data leakage? Malware? Build models to represent how you would attack your environment. Then take the threat models to the next level. Maybe the marketing folks should be able to share big files via their devices, but folks in engineering (with access to source code) shouldn’t. You can get pretty granular with your policies, so you can do the same with threat models.
  • Define policies: With the threat models you can define policies. Any technology you select should be able to support the policies you need.
  • Discovery: Yes, you will need to keep an eye on your environment, checking for new devices and managing the devices you already know about. There is no reason to reinvent the wheel, so you are likely to rely on an existing asset repository (within the endpoint security management platform, or perhaps a CMDB).
  • Enforcement: Now we get to the operational part of endpoint security management: deploying agents and enforcing policies on devices.
  • Reporting: We security folks like to think we implement these controls to protect our environments, but don’t forget that at least a portion of our tools are funded by compliance. So we need some reports to demonstrate that we’re protecting data and compliant.

Technology Considerations

Now that you have the process in place, you need some technology to implement the controls. Here are some things to think about when looking at these tools:

  • Device support: Obviously the first order of business is to make sure the vendor supports the devices you need to protect. That means ensuring operating system support, as well as the media types (removable storage, DVD/CDs, tape drives, printers, etc.) you want to define policies for. Additionally make sure the product supports all ports on your devices, including USB, FireWire, serial, parallel, and Bluetooth. Some offerings can also implement policies on data sent via the network driver, though that begins to blur into endpoint DLP, which we will discuss later.
  • Policy granularly: You will want to make sure your product can support different policies by device. For example, this allows you to set a policy to let an employee download any data to an IronKey but only non-critical data onto an iPhone. You will also want to 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 can support 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 to your central key management environment. You may also be interested in certifications such as EAL (Common Criteria), FIPS 140-2, etc.
  • Small footprint agent: To implement device control you will need to implement an agent on each protected device. You’ll need sufficient platform support (discussed above), as well as some kind of tamper resistance for the agent. You don’t want an attacker to turn off or compromise the agent’s ability to enforce policies.
  • Hardware keylogger protection: It’s old school, but from time to time we still see hardware keyloggers which use plug into a device port. The device control product protects the ports, so it should be able to detect hardware attacks.
  • Integration with endpoint security management platforms: Don’t reinvent the wheel – especially for cross-functional capabilities like discovery, reporting, agentry, and agent deployment/updating/maintenance – so leverage your endpoint security management platform to streamline implementation and for operational leverage.
  • Offline support: Many devices aren’t always connected to the network, so make sure policies are still enforced even when disconnected. You will also want to ensure you get 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 helpful. Some offerings also keep a copy of any files copied to any protected device ports, which can serve as a smoking gun in the event of data loss.
  • Override or temporary grace period: Finally, there are times when a 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 deployment work out much better.

Endpoint DLP Overlap

There are many areas of overlap between policies you can implement using device control and what endpoint DLP offers, and many device control offerings claim have DLP capabilities as well. The good news is that Securosis offers a ton of research on DLP. Check out the following links for more on DLP:

The relevant findings from our DLP research: DLP is really about deep content analysis, which offers much more granularity than a typical endpoint device control product. As an example, device control can build a policy based on file type (.doc vs. .pdf), whereas real endpoint DLP will allow a policy to detect and block mention of a research project within a large .doc file. Obviously DLP also adds significant capabilities for classification of sensitive data and offers enforcement beyond endpoints – it extends to the network (data in motion) and on storage devices (data at rest). Additionally, endpoint DLP agents can typically block functions such as Copy & Paste and Print Screen.

Endpoint DLP generally does not offer built-in encryption for removable media, nor can it normally assess or protect against malware attacks via removable media. Although with the consolidation of many standalone DLP vendors, endpoint DLP agents now tend offer more than just content analysis. So device control vendors are also adding more DLP-style content analysis to their offerings, again blurring the lines between these product categories.

Finally, another emerging issue to consider for to device control is the fact that “removable media” may not actually be removable anymore. Cloud offerings such as Dropbox and have in many cases replaced removable media. So over time your device control offerings should be able to restrict data going to cloud-based storage services and/or encrypt it, using on the same kinds of policies as protect traditional removable media.

In the next post we will wrap up our discussion of ongoing controls with file integrity monitoring.

No Related Posts

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.