Detecting the Invisible Part 2: "Once More Unto the Breach, Dear Friends"

Our approach to securing the enterprise has changed, and breach detection technology has been largely instrumental in this process. This report from NSS Labs is the second in a three-part series on the impact of the breach detection system (BDS).

The importance of breach detection technology is well understood – breach detection systems (BDS) are here to stay. However, the definition of breach detection system is broad; different products have different features, and one of the key challenges facing organizations is understanding how to differentiate which features are necessary for their own environments. The second in a three part series, this report compares the early and emerging features of breach detection systems.

Because of tremendous market interest, breach detection technology has undergone considerable change over a relatively short period of time. The short development cycles have been good for the industry, not only because more features are available, but also because rapid product development creates an unpredictable – and thus more challenging – environment for malware authors.

Not long ago, the malware detection features of a breach detection system could be categorized quite simply, e.g., sandbox type, deployment mode, form factor, and scanning type. As the market has matured, however, new differentiators have emerged, such as an increased number of scanned ports and protocols, an increased number of sandbox number and types, and custom sandbox capabilities.

Breach detection products range from single appliances that contain anti-malware products to forensics suites that comprise multiple technologies. Because today’s breach detection products offer such a wealth of features, enterprises considering a BDS must establish which features are essential for their own environment and map these to current products prior to purchasing.

  First Generation BDS Features Emerging BDS Features
Purpose
  • Malware detection
  • Threat feed
  • Forensics portal with visibility into command & control (C&C) traffic and other indicators of compromise (IoC)
  • Alert prioritization per host
Sandbox 
  • Local hardware appliance with virtual sandboxes; limited operating systems; limited applications
  • Cloud service
  • More operating systems supported; more applications supported
  • Emulation vs. virtualization vs. bare metal
  • Local appliance + cloud service
  • Custom operating system and applications (e.g., “gold image”)
Deployment
  • Network out-of-band; network in-line
  • Single appliance
  • Agent-based
  • Product suites
  • Integration with other security products
Form Factor
  • Hardware
  • Virtual appliance
  • Software (limited)
  • Cloud service
Scanning and Analysis
  • Support for basic protocol for scanning (typically HTTP, SMTP and SMB)
  • Additional ports and protocols
  • SSL (HTTPS and TLS) scanning
Traffic Enforcement
  • Detect
  • Block
Management
  • Single device management
  • Centrally managed
Host Remediation
  • None
  • Through host agent
System Management
  • None
  • Through host agent
Integration
  • Point product
  • Part of security infrastructure


The many options concerning the location of a BDS sandbox perfectly illustrate how quickly breach detection product features are changing. Depending on the vendor, today’s BDS sandboxes may be installed in any of the following locations:

  • Local appliance sensor and sandbox “all in one”
  • Local appliance sensor and local appliance sandbox
  • Local appliance sensor tied to cloud sandbox (no local sandbox)
  • Local appliance sensor and local appliance sandbox tied to cloud sandbox
  • Cloud sandbox only (traffic forwarded by existing firewall)

For some organizations, the location of the sandbox and the product’s architecture will not be important; but for others, these are critical concerns; for example, where regulatory compliance prohibits the movement of data off premises. Sandbox location is one example of why the capabilities of different breach detection products must be carefully evaluated against an organization’s overall policies, not just its security policies.

Breach detection products deliver important security capabilities, but these single point products are only the first step. To reduce the likelihood for a breach and to decrease the time taken to recover from a breach, i.e., to achieve real cyber resilience, organizations must build defensive architectures that work in conjunction with installed security products.

Next up: The third and final installment in this series, in which I present key findings and potential next steps for the breach detection security market.

Jason Pappalexis is a Research Director at NSS Labs, Inc. the world's leading information security research and advisory company. Follow him on Twitter @jsnppp
 

Follow us on Twitter (@NSSLabs) to keep informed as new research is released.

TAGS: