Category: Tech

Chris Sanders kindly sent me a review copy of Applied Network Security Monitoring, written by Sanders along with Jason Smith, David J Bianco, and Liam Randall. It’s a very solid work, with much to recommend it to IT people who either have been told to implement security monitoring or who think that they should.

Some of Applied Network Security Monitoring will be very familiar to anyone who has read any other security book–I’ve read many times that risk equals impact times probability. Every book on this topic needs this information, however, and Sanders and company cover it in sufficient detail to ground a probie while letting the rest of us easily skim it as a refresher.

Then they take us through selecting data collection points and how they make decisions on where to collect data and what kind of data to collect. Ideally, of course, you collect full packet data everywhere, but in my semi-rural gigabit ISP world I don’t have enough electricity to spin that much disk. Where can you get by with session data, and where do you need full packet capture? ANSM takes you through the choices and the advantages and disadvantages of each, along with some guidance on the hardware needs.

Data is nice, but it’s what you do with the data that makes security analysis interesting. ANSM uses Security Onion as an underlying toolkit. Security Onion is huge, and contains myriad tools for any given purpose. There’s reasons for this–no one NSM tool is a perfect fit for all environments. ANSM chooses their preferred tools, such as Snort, Bro, and SiLK, and takes you through configuring and using them on the SO platform. Their choices give you honeypots and log management and all the functionality you expect.

Throughout the book you’ll find business and tactical advice. How do you organize a security team? How do you foster teamwork, retain staff, and deal with arrogant dweebs such as yours truly? (As an aside, ANSM contains the kindest and most business-driven description of the “give the arrogant guy enough rope to hang himself” tactic that I have ever read.) I’ve been working with the business side of IT for decades now, and ANSM taught me new tricks.

The part of the book that I found most interesting was the section on analysis. What is analysis, anyway? ANSM takes you through both differential analysis and relational analysis, and illustrates them with actual scenarios, actual data. Apparently I’m a big fan of differential diagnosis. I use it everywhere. For every problem. Fortunately, Sanders and crew include guidelines for when to try each type of analysis. I’ll have to try this “relational analysis” thing some time and see what happens.

Another interesting thing about ANSM is how it draws in lots of knowledge and examples from the medical field. Concepts like morbidity and mortality are very applicable to information technology in general, not just network security monitoring, and adding this makes the book both more useful and more interesting.

Applied Network Security Monitoring is a solid overview of the state of security analysis in 2014, and was well worth my time to read. It’s worth your time as well.

postscript

Not long ago, I reviewed Richard Bejtlich’s The Practice of Network Security Monitoring. What’s more, I have corresponded with both Sanders and Bejtlich, and while they aren’t “help me hide a body” friends I’d happily share a meal with either.

The obvious question people will ask is, how does Applied NSM compare to tPoNSM?

Both books use Security Onion. Each book emphasizes different tools, different methodologies, and different techniques. Practical NSM shows Bejtlich’s military background. While Sanders has worked with the military, Applied NSM reads like it’s from an IT background.

I can’t say either is a better book. Both are very very good.

Personally, I have never implemented any plan from a book exactly as written. I read books, note their advice, and build a plan that suits my environment, my budget, and–most importantly–my staff. Reading them, I picked between tools and strategies until I found something that would work for my site. Security monitoring is a complex field. Maintaining, let alone building, a security monitoring infrastructure requires constant sharpening of your skills.

I recommend anyone serious about the field read both books.

DANE, or DNS-based Authentication of Named Entities, is a protocol for stuffing public key and or public key signatures into DNS. As standard DNS is forged easily, you can’t safely do this without DNSSEC. With DNSSEC, however, you now have an alternative way to verify public keys. Two obvious candidates for DANE data are SSH host keys and SSL certificate fingerprints. In this post I take you through using DNSSEC-secured DNS to verify web site SSL certificates via DNSSEC (sometimes called DNSSEC-stapled SSL certificates).

In DNSSEC Mastery I predicted that someone would release a browser plug-in to support validation of DNSSEC-staples SSL certificates. This isn’t a very difficult prediction, as a few different people had already started down that road. One day browsers will support DANE automatically, but until then, we need a plug-in. I’m pleased to report that the fine folks at dnssec-validator.cz have completed their TLSA verification plugin. I’m using it without problems in Firefox, Chrome, and IE.

DNS provides SSL certificate fingerprints with a TLSA record. (TLSA isn’t an acronym, it’s just a TLS record, type A. Presumably we’ll move on to TLSB at some point.)

A TLSA record looks like this:

_port._protocol.hostname TLSA ( 3 0 1 hash...)

If you’ve worked with services like VOIP, this should look pretty familiar. For example, the TLSA record for port 443 on the host dnssec.michaelwlucas.com looks like this:

_443._tcp.dnssec TLSA ( 3 0 1 4CB0F4E1136D86A6813EA4164F19D294005EBFC02F10CC400F1776C45A97F16C)

Where do we get the hash? Run openssl(1) on your certificate file. Here I generate the SHA256 hash of my certificate file, dnssec.mwl.com.crt.

# openssl x509 -noout -fingerprint -sha256 < dnssec.mwl.com.crt
SHA256 Fingerprint=4C:B0:F4:E1:13:6D:86:A6:81:3E:A4:16:4F:19:D2:94:00:5E:BF:C0:2F:10:CC:40:0F:17:76:C4:5A:97:F1:6C


Copy the fingerprint into the TLSA record. Remove the colons.

Interestingly, you can also use TLSA records to validate CA-signed certificates. Generate the hash the same way, but change the leading string to 1 0 1. I’m using a CA-signed certificate for https://www.michaelwlucas.com, but I also validate it via DNSSEC with a record like this.

_443._tcp.www TLSA ( 1 0 1 DBB17D0DE507BB4DE09180C6FE12BBEE20B96F2EF764D8A3E28EED45EBCCD6BA )

So: if you go to the trouble of setting this up, what does the client see?

Start by installing the DNSSEC/TLSA Validator plugin in your browser. (Peter Wemm has built the Firefox version of the plugin on FreeBSD, and he has a patch and a binary. Use the binary at your own risk, of course, but if you’re looking for a BSD porting project, this would be very useful.)

The plugin adds two new status icons. One turns green if the site’s DNS uses DNSSEC, and has a small gray-with-a-touch-of-red logo if the site does not. Not having DNSSEC is not cause for alarm. The second icon turns green if the SSL certificate matches a TLSA record, gray if there is no TLSA record, and red if the certificate does not match the TLSA record.

So: should you worry about that self-signed certificate? Check the TLSA record status. If the domain owner says “Yes, I created this cert,” it’s probably okay. If the self-signed cert fails TLSA validation, don’t go to the site.

You can use a variety of hashes with TLSA, and you can set a variety of conditions as well. Should all certificates in your company be signed with RapidSSL certs? You can specify that in a TLSA record. Do you have a private CA? Give its fingerprint in a TLSA record. If you want to play with these things, check out my DNSSEC book.

TLSA gives you an alternate avenue of trust, outside of the traditional and expensive CA model. Spreading TLSA more widely means that you can protect more services with SSL without additional financial expenses.