Sysmon & Security Onion, Part 1: Rise of the Encrypted Web

This is part one of a series of posts that contain key excerpts of my paper, Using Sysmon to Enrich Security Onion’s Host-Level Capabilities.

In the eleven years since Richard Bejtlich wrote his seminal book on Network Security Monitoring, practitioners have seen a number of issues in the last few years that have shown some of the limitations of network-centric monitoring. The rise of encrypted-by-default web traffic, which blinds defenders to most NSM data types is one of those issues.

The collection of NSM data is typically through a TAP or SPAN on a strategic chokepoint in the network. If the network data between the client and server is encrypted, a number of types of NSM data will be useless to the analyst—full content, extracted content, and certain types of alerts. With the revelations of the past few years that a number of governments around the world have been intercepting their citizen’s unencrypted communications, there has been significant interest in encrypting most, if not all of the web traffic around the world. In 2014, CloudFlare, which hosts a content delivery network (CDN) and security services for two million websites, enabled free SSL for all of their customers. They stated, “Having cutting-edge encryption may not seem important to a small blog, but it is critical to advancing the encrypted-by-default future of the Internet. Every byte, however seemingly mundane, that flows encrypted across the Internet makes it more difficult for those who wish to intercept, throttle, or censor the web.” (Prince, 2014)

From a recent study, The Cost of the “S” in HTTPS,  twenty-five thousand residential ADSL customers saw HTTPS usage in uploads accounting for 80% of traffic compared to 45.7% in 2012. (Naylor, et al.) This trend is expected to continue for the foreseeable future.

This increase of encryption will typically be seen in north – south traffic, not necessarily east – west traffic, which means NSM sensors deployed to monitor internal traffic may not be so readily affected. However, sensors deployed at network egress points will certainly be affected unless some type of mitigations is put into place. These mitigations would include proxying the SSL traffic so that the network data could be read, though this solution is limited in practice due to performance, privacy, and liability concerns.

References

Prince, M. (2014, September 29). Introducing Universal SSL. Retrieved February 12, 2015, from Cloudflare.com: https://blog.cloudflare.com/introducing-universal-ssl/

Naylor, D., Finamore, A., Leontiadis, I., Grunenberger, Y., Mellia, M., Munafò, M., . . . Steenkiste, P. (n.d.). The Cost of the “S” in HTTPS. Retrieved February 12, 2015, from cs.cmu.edu: http://www.cs.cmu.edu/~dnaylor/CostOfTheS.pdf

Tagged , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s