The process of defending a network can be overwhelmingly complicated for any newcomer into the realm of cybersecurity. This process can include many tools, data types, and specific steps.
There are two main approaches to tackling a complex topic…
- Ready, fire, aim – Here we’re diving face-first into the “coolest” tools and following what everyone else is saying without much of an understanding behind “why”.
- Ready, aim, fire – Here we take a step back before jumping to understand the lay of the land. This approach helps us uncover the “what” and “why” underlying many complexities.
Both approaches have their place, but this time we’re going to aim before we fire (e.g. option 2).
This week I decided to read through a book that’s recommended often by cybergeeks called “The Practice of Network Security Monitoring”.
In this book, the author does a great job of mapping out the general layout of most “Network Security Monitoring” (NSM) operations. The beautiful thing about this book is that there’s a healthy combination of theory and practice, both of which are needed for true understanding.
NSM is an approach to finding intruders on your network and doing something about them before they have time to cause damage. NSM isn’t focused on prevention or active security, but instead, on passive security. The creators of NSM like many cyber geeks accept the fact that your network will be comprised and there’s no way to fully protect yourself. This philosophy of accepting the inevitable is extremely useful when designing a network from a security lens.
NSM is all about speed… When combating attackers you don’t “win” by preventing them from entering, you “win” by detecting, responding, and containing their bad intentions. If the attacker is unable to achieve their mission due to your speedy response, then you’re “winning”.
I’m not going to regurgitate the entire book here, instead, I’ll point out my main takeaways and useful bits you might find interesting.
Different Data Types
Within a “passive” network monitoring setup organizations collect different kinds of data to detect, respond, and contain attackers.
The original list consisted of seven data types (see below).
- Full content
- Extracted content
- Session data
- Transaction data
- Statistical data
- Metadata
- Alert data
But! The author wrote a blog post recently narrowing it done to only four “true” data types, so that’s what I’ll explain.
- Full content – This is all the information that’s flowing across your network, including not only the flow information but the actual payloads that can be examined.
- Extracted content – These are high-level pieces of content being extracted from the full content such as images, webpages, etc.
- Transaction data – Data focused on the movement of packets throughout the network emphasizing the connections and interactions between different machines.
- Alert data – Data that is pre-judged before being presented to the security analyst, showing that the traffic could be suspicious for some reason. This data usually comes from an intrusion detection system.
Whenever a security analyst goes through the process of detecting, responding, and containing there’s a good chance they’ll bounce around the different data types. Each data type is useful for uncovering different clues, so being familiar with each and how they’re used is critical for a successful NSM operation.
The NSM Platform
Most InfoSec organizations are seen by the business as a cost, not a revenue generator or saver. This is an uphill battle many security leaders have to combat internally, which usually ends in them being underfunded and lacking talent.
Whenever ever purchasing tools to secure a network it’s always important to figure out which pieces of this tooling are the priority, ensuring you get the most value for your money.
For NSM platforms this value comes in storage. An NSM platform mainly collects and stores information, so a company’s ability to store and sift through this data quickly directly correlates to its “success”. Being a cash-strapped security organization we’ll want to get the maximum amount of hard drive storage space, then as much RAM as possible.
After purchasing the main NSM platform we’ll need to purchase and implement sensors all throughout our network. These sensors come in two flavors, TAPs and SPANs (see below). The purpose of this sensor is to duplicate all the traffic running across your network into the NSM platform, so you’re able to analyze it in the future. TAPs are dedicated pieces of hardware that most organizations use.
Test Access Points (TAPs)
Port Mirroring (SPANs)
One of the most important parts of your TAP is where its located. Most companies need multiple tapes due to their network size and segmentation.
A general rule of thumb when incorporating sensors into your environment is to ensure you’re as close as possible to the “true” source and destination for all traffic. This distance is important, so we’re able to avoid network address translation (NAT), port address translation (PAT), and proxy servers.
Below we have a simple network with different segments and sensors sitting at points G, B, and H that can prevent obfuscation through NAT or PAT (close to the machine), while E prevents obfuscation through proxy servers (close to the internet).
NSM Software
Within this book, our author focused heavily on the open-source NSM suite called Security Onion, which has a long list of different software. Luckily, each piece of software has a generalized purpose and can be bucketed into either presentation, delivery, or collection.
As you can tell… Security Onion is just a culmination of different software combined into a single suite. Let’s zoom in on the presentation layer, specifically the packet analysis tools.
Packit analysis is as much art, as it is science and reminds me of the scene in the matrix where Cypher explains to Neo that by watching his screen long enough he begins to see images.
After analyzing a certain number of packets within a network your intuition around what’s “good” and what’s “bad” is heightened. Two approaches that are often used together are called the “Net Block” and “Protocol” approaches.
- Net Block – During the detection phase as an analyst you’ll start by looking through large IP address ranges using sites like “Robtex.com“, that provide the network owners. For example, Microsoft = 57.56.0.0/14, Amazon = 23.20.0.0/14, Apple = 17.0.0.0/8, Verizon = 6.224.0.0/11.
- Protocol – Further into the detection phase analysts will get more granular looking at specific TCP or UDP ports to understand what apps are being used. The SANS Internet Storm Center Port Report is useful for this kind of granular research. For example, Apple uses UDP ports 3544 for push notifications and 16386 for FaceTime.
Over time these IP address ranges and port numbers will become second nature, limiting the amount of time you’ll need reference sites like this. Building your Matrix reading skills! 😉
Fitting into the Enterprise Life Cycle
There are many different definitions for the Enterprise Life Cycle, but we’ll stick with the definition from this book…
NSM fits right into the last two sections of detect and respond. These two phases can be broken down further into collecting, analyzing, escalating, and eventually resolving attacks.
- Detect
- Collect – Our goal in this sub-phase is to decide whether the traffic we’re seeing is normal, suspicious, or malicious. Two sources of data feed into this decision, one is tech-oriented and the other is non-tech-centric. The tech-related data is being fed in through hosts, network devices, and event logs. Our non-tech data is being fed to us from external parties such as partners, customers, or employees.
- Analyze – Now its time to validate our previous assumptions. There are many ways to validate, but one common method is to cross-reference our traffic against “indicators of compromise” (IOCs).
- Respond
- Escalate – Here we’re going to notify those impacted, as well as the people labeled as “decision-makers” within your organization.
- Resolve – Taking no action is not an option, so once all of this pre-work has been completed its time we do something about this attacker. The first step is always to contain the attacker separating them from the network, which can be done by… putting computers into hibernation mode (avoiding memory loss), shutting down ports, implementing rules via local firewalls and ACLs, as well as making routing changes.
Remember… No network is safe… Attackers will gain access to your network, so your best chance of “winning” is through speedy detection, response, and containment via NSM.