The Cybersecurity Canon: The Practice of Network Security Monitoring

The Cybersecurity Canon is official, and you can now see our website here. We modeled it after the Baseball or Rock & Roll Hall-of-Fame, except for cybersecurity books. We have 20 books on the initial candidate list but we are soliciting help from the cybersecurity community to increase the number to be much more than that. Please write a review and nominate your favorite. 

The Cybersecurity Canon is a real thing for our community. We have designed it so that you can directly participate in the process. Please do so!

Book Review: The Practice of Network Security Monitoring: Understanding Incident Detection and Response (2013) by Richard Bejtlich

Executive Summary

Richard Bejtlich is one of the most respected security practitioners in the community. If he publishes something, we should all take notice. In The Practice of Network Security Monitoring, Bejtlich provides the theory and the hands-on tutorial on how to do network security monitoring the right way.

The book is a primer on how to think about network security monitoring and incident response. For seasoned security practitioners, working through the examples in this book will only increase your understanding of the subject. For the beginners in the crowd, Bejtlich provides step-by-step instructions on how to install, configure, and use some of the best open-source tools available that will help any security program improve its network security monitoring capability. Newbies working through the examples in this book will demonstrate to themselves, once and for all, if they have what it takes to work in this field. This book is absolutely a Cybersecurity Canon Candidate and you should have read it by now.

Introduction

I have been a fan of Bejtlich for a long time. He has been a cyber security book reviewer for many years, and he was the inspiration for me to start doing my own book reviews. He is a no-nonsense kind of guy and has been practicing and advancing the craft of network security monitoring and incident response since he started in the industry as a US Air Force officer in 1998.

Since then, he has risen in the ranks at some prominent security-minded companies—Foundstone, ManTech, and GE—and today he is the chief security strategist for FireEye. He knows a thing or two about network security monitoring and response. I happen to agree with his general philosophy of cybersecurity defense, and this book provides an introduction to that philosophy as well as an in-depth, hands-on look at the best open-source tools available.

I am often asked what skills a wannabe cybersecurity analyst needs to get into the industry. My glib go-to answer, and the first question I ask any candidates asking to work for me is this: Can you install a Linux distribution on your home computer?

If a newbie can’t get through that basic exercise, he or she should probably seek employment somewhere else. After reading this book though, I plan to up my game. My new question is, can you work through all of the examples in this book and make sense of it all? If you can, you may have a future in the cybersecurity industry as a SOC analyst or an incident responder. If you can’t, then cybersecurity might not be for you.

The Network Security Monitoring Story

In my own career, I have routinely seen organizations buy every shiny and new cybersecurity tool that they could get their hands on and deploy them within the enterprise. Their leadership’s grand strategy seemed to be that shiny equals good. In my early days, I may have even subscribed to that theory. Today, I do not have the energy to chase every bright light that appears on the cybersecurity market. I mostly just want to see what I have already deployed work the way that I thought it should have worked when I originally bought it.

Network Security Monitoring Is More Than Just a Set Of Tools

Buying and deploying new technology is relatively easy compared to training the people and developing the processes necessary to fully use it. Organizations tend to forget this. They think that if they just buy the latest tool—pick your tool, it does not matter which one—that it will miraculously configure itself, monitor itself, and forcefully eject any intruders by itself. In the real world, this does not happen.

Bejtlich agrees:

“Products and technologies are not solutions. They are just tools. Defenders (and an organization’s management) need to understand this. No shiny silver bullet will solve the cybersecurity problem. Attacks have life cycles, and different phases of these life cycles leave different evidence in different data sources that are best exposed and understood using different analysis techniques. Building a team (even if it is just a team of one) that understands this and knows how to effectively position the team’s assets (including tools, people, and time) and how to move back and forth between the different data sources and tools are critical to creating an effective incident response capability.”

In a previous job, I had all of the best toys pumping mountains of data to a 24/7 security operations center, but finding an advanced adversary in all of that data was way too hard. The SOC analysts performed Herculean tasks, but we did not have the processes in place, nor the people trained to develop the processes, to fully use all of that advanced technology. It was frustrating. The bottom line is that if you buy the tool, make sure you spend some resources training your people and developing a plan to incorporate the tool into your overall security program.

Bejtlich also says that your traditional tools are not going to help much with our new cloud environments. Customers of cloud environments just do not have access to the networks that a network security monitoring team needs. As we move more and more to the cloud, this can be either a liability or a major opportunity for a young entrepreneur to solve the problem.

Operate Like You Are Compromised: Kill Chain Analysis

In a previous blog, I said that kill chain analysis is one of the three great innovations that have come down the pipe from the security community this past decade. Bejtlich says that Lockheed Martin’s paper on kill chain analysis is unique because followers of the philosophy align their security program along the same lines that adversaries must use to penetrate their victim’s network.

He confirms the notion that I have had for a few years now that the very old “defense-in-depth” model—which we all adopted in the early 1990s to keep the adversary out of our networks—is dead. It is simply not possible. On the other hand, it does not necessarily mean that you have a disaster on your hands just because one or more adversaries manage to work their way down a couple of links of your kill chain. The idea is to detect these adversaries before they can accomplish their ultimate goal: crime, espionage, hacktivism, warfare, mischief, or whatever.

Bejtlich says,

“Prevention eventually fails … Rather than just trying to stop intruders, mature organizations now seek to rapidly detect attackers, efficiently respond by scoping the extent of incidents, and thoroughly contain intruders to limit the damage they might cause.”

My own personal goal is early detection, quick eradication, and automatic prevention of those observed attacks going forward before these adversaries can claim victory. With the old defense-in-depth model, we were trying to prevent all penetrations into the network.

Bejtlich says,

“It’s become smarter to operate as though your enterprise is always compromised.”

Journalist Kelly Jackson Higgins interviewed Steve Adegbite, the director of cyber security for Lockheed Martin (LM), in 2013 regarding how LM used kill chain analysis to discover that the company’s RSA token deployment had been compromised. Adegbite said that,

"The goal of the Kill Chain is to make sure [the adversaries] don't get to step 7 [of the Kill Chain] and exfiltrate.”

In other words, it is acceptable for adversaries to penetrate your networks as long as you have installed the processes to contain the damage they might cause.

Network Security Monitoring as a Decision Tool, Not a Reaction Process

Bejtlich’s take on network security monitoring is subtly different than what I would expect from most other security practitioners who have not had a lot of experience actually doing it. According to Bejtlich, these practitioners use network security monitoring for forensics and troubleshooting. His take is to use the discipline as a decision tool for how to contain the detected adversary. He also believes you have to measure your team’s effectiveness by measuring things like:

• How long it takes to detect adversaries once they have entered your network
• How long it takes to contain adversaries once you have detected them

In the 2014 Verizon Data Breach Investigations Report, researchers show that of the 1,367 known data breaches in 2013, security teams discovered less than 25 percent of them (341) within days of the initial compromise. Security teams discovered the rest (1,026) many days and weeks later. Bejtlich says that for a network security-monitoring program do be effective, teams must measure how they reduce that time.

Incident Response and Threat Intelligence Go Together

Bejtlich talks about the various approaches to handle a breach within your organization. Some incident response teams elect to identify the compromised asset, take it offline, maybe do some forensics on it, re-image it, and then put it back online so that they can wait for the next breach to happen. I call this the whack-a-mole approach to incident response. This process provides you no context about what the adversaries did and why. Other organizations engage their threat intelligence group and are able to understand the impact of what these adversaries are trying to accomplish. Bejtlich explains that incident response teams can frame the attacks from different perspectives: a threat-centric approach and an asset-centric approach. He says that threat intelligence teams track adversaries by campaigns but that incident response teams respond to the adversary’s actions in waves. He provides practical guidance about what kind of skills and capabilities an incident response team and intelligence team require.

So that’s the story: build a network security monitoring program by deploying the right tool, training your people how to use the tool properly, and developing the processes necessary to incorporate the tool into the overall program. Assume that your network is already compromised, and aggressively track adversaries down the kill chain. Remember, the network security monitoring team’s goal is to prevent adversaries from accomplishing their goals. Use the program to make decisions about how to contain the adversary quickly and efficiently, and use your intelligence team to understand the context of how and why the adversary is attacking your network.

Let’s talk about the tech.

The Network Security Monitoring Tech

This is where it gets really good. The theory is one thing—and I like the theory part—but the actual doing is what really matters. Bejtlich provides a hands-on tutorial on how to deploy the best open-source tools to do network security monitoring. If you are a young person thinking that you want to be a cybersecurity professional or if you are transitioning careers and you think cybersecurity is something you can handle, get this book and work through the examples. If you can do them, then I want to talk to you about a job. If you can’t, then maybe consider a less technically demanding career.

Bejtlich says that there are two types of network security monitoring data: full content and extracted content. He says that network security monitoring tools help analysts review these different data types and make a decision about containment based on an organization’s network security process. He points practitioners to Doug Burks’ Security Onion (SO) distribution to get three types of tools: data collection, data presentation, and packet analysis.

Data Collection Tool: Argus

Data Presentation Tools:

• Tcpdump
• Tshark (the command line version of Wireshark)
• Argus’s Ra client
• Dumpcap in concert with Tshark

Packet Analysis Tools:

• Wireshark
• Xplico
• NetworkMiner

Conclusion

Richard Bejtlich is one of the most respected security practitioners in the community. If he is speaking somewhere, take the time to hear what the man has to say. The same goes for his writing. If he publishes something, we should all take notice. In The Practice of Network Security Monitoring, Bejtlich provides the theory of and the hands-on tutorial on how to do network security monitoring the right way. He tells you why you should be doing it and how it should work together, and he gives you step-by-step instructions on how to deploy and use the best open-source tools available.

If you are already a seasoned security practitioner, working through the examples in this book will only increase your understanding of the subject. If you are a newcomer to the subject, working through the examples will indicate once and for all if you have what it takes to work in this field. This book is absolutely a Cybersecurity Canon candidate, and you should have read it by now.