In the world of cybersecurity, the process of monitoring a network is daunting and when you’re new to this field it can get overwhelming quickly. The reason for this immediate overwhelm is due to all the different tools and terminology thrown around by more experienced cybergeeks. A way to speed up the learning process and reduce this overwhelming feeling is to uncover the structure in this chaos.
Luckily, I’ve found a book that brings that needed structure, at least for the network monitoring piece of cybersecurity, which is called “Applied Network Security Monitoring” (Applied NSM).
Before diving into this book, I’d recommend reading “The Practice of Network Security Monitoring”, which is a good starter book helping you understand the theory behind NSM before diving too deep.
Applied NSM is a big book and spends a good amount of time walking you through the tools and processes for creating, as well as operating an NSM-centric SOC.
If you’re interested in getting into the world of cybersecurity as a security analyst, this is the book you need.
As always, I’m not going to regurgitate the entire book because that’s a waste of my time and yours, so we’ll cherry-pick two interesting sections. 🙂
How to be “intelligent”
What is “intelligence”
From the perspective of a cyber geek “intelligence” is all about context. When a network or system is attacked having this context can reduce the amount of time needed to respond dramatically. But this isn’t always the case…
This “intelligence” topic in the cybersecurity community is a sensitive one, depending on who you’re talking to. One camp of people feels that “threat intel” is a waste of time and money, but the other camp finds real value in it. Honestly, both camps are “right”.
These opinions have evolved from each camp’s previous experience leaving either a negative or positive association with “intelligence”, similar to any other debate. The negative experience was most likely derived from a basic “threat intel” data feed that created more work for the security analyst, which is the opposite of why “threat intel” exists.
In Applied NSM the author does a great job of explaining why people have negative experiences with “threat intel” and how to avoid this.
Threat intelligence is a process that sits inside a larger lifecycle (see below). Different people define this lifecycle in different ways, but there are patterns. We’ll stick with the Recorded Futures definition for now.
- Direction – This is an important step that is often ignored or poorly done. During the “direction” phase we’re setting a direction, figuring out which intel is relevant to the assets we’re protecting, and ensuring we’re asking the “right” questions.
- Collection – Now that we know which “direction” we’re headed it’s time to set up the data sources needed for that plan.
- Processing – Once the data has been captured, we’ll need to process it, so both machines and humans can read it.
- Analysis – This is where most of the action happens when an analyst combines both internal and external intelligence to investigate an event quickly and accurately.
- Dissemination – After figuring out the issue, it’s time to spread the love via some kind of report, email, or simple notification to those impacted.
- Feedback – At the end of this cycle we’ll take the lessons learned and feed them back into the “direction” stage helping improve the intelligence our security team is taking in.
As I mentioned before… Many companies do this wrong, causing a lot of extra work, pain, and negative association with anything “threat intel” related.
When hearing the word “intelligence” in cybersecurity most people default to “threat intelligence”, but this is only one part of intelligence. On the other side, there’s “friendly intelligence”, which is where most companies fail.
Mapping all the connections and devices sitting on a network can be difficult, mundane, and painful at times, but this “friendly intelligence” is necessary if you want to have any chance of securing it. How do you protect what you can’t see? I know… This sounds obvious, but it’s a common issue with many companies…
The author of Applied NSM compares mapping a network to a doctor doing an examination on a patient. In a medical exam, the doctor looks at two things, the current “physical” status of the patient and their previous medical history. This “historical and physical” (H&P) process can be applied to networks too.
- Physical (devices) – Using a tool like Nmap a security team could get a good understanding of their current physical status by mapping all the devices (e.g. IP address, DNS name, VLAN location, device role (workstation, server, etc.), O/S, and physical location). This physical mapping process should repeat at different times during the day/week due to new devices being added and removed constantly. Today it seems that 100% visibility is a pipe dream, so aiming for 80% visibility is more realistic.
- History (connections) – It’s not enough to just know what devices are sitting on your network, we also need to understand the nature of each connection between them. Looking historically at the connections gives us a baseline of “normal” and this baseline will change over time, so it’s important to continuously monitor these connections. “Passive Real-time Asset Detection System” (PRADS) is a good tool for this due to its ability to track devices and their connections over time, letting the analyst know whenever a new device pops up or an old device disappears.
Now that we’ve looked internally understanding what’s “normal”, now it’s time to look externally and see what threats we should concern ourselves with.
There are three different types of threat intelligence – Strategic, operational, and tactical. 99% of companies need to only concern themselves with tactical, the other two buckets are for governments and large critical infrastructure companies (e.g. energy grid, internet service providers, etc.).
Strategic and operational threat intelligence focuses on the attacker’s psychology, while tactical intelligence focuses on the actions and tools used by the attacker. Most companies need to focus on the tactical, so they’re able to develop detection and prevention tools for their network.
After mapping our network we’re better able to pick the right threat feeds and tailor them to our specific needs, making the alerts we’re receiving contextual to our issues.
Once you’ve been attacked it’s always good to look outside of the threat intelligence you’ve got being funneled into your SIEM. The author provided a list of free open resources, which the industry calls “Open-source Intelligence” (OSINT), these tools are used to learn more about hostile devices detected on your network, see below…
IP address owner
- “Internet Corporation for Assigned Names and Numbers” (ICANN) is a great place to look when attempting to pinpoint who the owner is of a hostile IP address or domain.
- “Robtex” is similar to ICANN, but provides a bit more information and is my preference.
- IPVoid: This website tells you if an IP has been placed on a blacklist
- URLVoid: This website tells you if a domain name has been placed on a blacklist
- Virus Total: Hands down one of the best free tools I’ve come across. This tool curates 70 antivirus engines into a single location, checking each engine for the file, URL, IP address, or file hash you’ve uploaded.
- Cuckoos Sandbox: Once you’ve spotted the attacker and malware on your machine, it’s time to find out exactly what this malware has been up to. One way to do this is by uploading the malware to a virtual sandbox that can observe every action the malware takes.
Important note! > Whenever using an open-source intelligence tool you need to remember that the attackers have access to these tools as well, so whatever you upload they’ll see. A strategic attacker will create automated scripts that check these sites on a recurring basis to find out when their attack has been discovered, once they’ve found out they’ll change tactics.
Analysis from start to finish
This last chapter was my favorite!
The author did an amazing job stringing everything together… When learning about cybersecurity, I’ve found many disparate pieces of information, where one person talks about a tool, another about processes, and another about technical fundamentals, but rarely have I come across someone that strings all these concepts together into a real-world scenario.
This chapter does just that. 🙂
When a security event happens on a network the analyst is usually the first to find out and it’s their job to investigate this event. Sadly, every analyst has their own special way of investigating an event, which can be chaotic for newcomers and creates massive learning curves that can take months or years to overcome. This longer timeframe directly impacts the company’s ability to spot and prevent attackers from getting into their networks.
I’ve not come across any industry-wide standards for investigating security events and honestly, I don’t think they exist. Luckily, this author gives two intuitive approaches that can be adapted to most situations.
These approaches are called “relational” and “differential”.
- Relational (Police Investigation) > This approach mimics the investigation process every police officer experiences when arriving at the scene of a crime. At the beginning of this relational approach, we’ll examine the “primary” friendly and hostile devices involved in the event. Once we’ve mapped out the devices, we’ll dig through the connections between these primary devices. Each step can be repeated going into secondary, tertiary, and quaternary devices/connections until the investigation is complete. This approach is ideal for newcomers in cybersecurity and that’s why we’ll dive deeper into a real-world example below.
- Differential (Doctor) > The relational approach mimics what doctors do when examining a sick patient. First, they I.D. symptoms, second consider the most common diagnosis, third they list all possible diagnoses, fourth they prioritize that list by severity and lastly eliminate each item starting with the most severe until a solution is found. By replacing sickness with a cyber-attack we’re able to use this approach for cybersecurity. This approach is more suitable for experienced security analysts due to its heavy reliance on intuition.
From start to finish – Relational Analysis
Imagine… It’s 4:30 p.m. on a Friday and you’re wrapping up your first week of work as a security analyst at a large pharmaceuticals company.
All of a sudden an alert pops up on your SIEM showing
ET WEB_CLIENT PDF With Embedded File
The first step here is to figure out which “primary subjects” are involved in this event and this should be sitting in the more detailed section of this alert. After looking through the detailed section we notice that the external source (hostile) IP address is 192.0.2.5 and the internal destination (friendly) IP address is 172.16.16.20.
By quickly glancing at the traffic traveling between the two subjects we see that a PDF has been downloaded onto the friendly device. We grab the full PCAP data from this conversation and extract the PDF using WireShark. The MD5 hash of this PDF is submitted to Virus Total and it determines that 23% of the antivirus engines think this file is malicious.
We decide to continue this investigation…
Next, we’ll want more intelligence on both devices.
Friendly intelligence for 172.16.16.20:
- With a simple Nmap scan, we can see that this device is running Windows 7 and has no listening services or open ports
- By looking through our PRADS data (remember H&P above) we see that this system browses the web frequently and multiple New Asset Notifications exist
Hostile Intelligence for 192.0.2.5:
- Now we’ll research this IP on a few different OSINT tools. IPVoid returns 0 matches on this IP address, but URLVoid returns 5 matches on the domain name the PDF was downloaded from.
- Our NetFlow data shows this IP address has not communicated with any other devices on the friendly network, which seems to be a good sign.
Onto step two, figuring out the relationship between these devices!
The rule of 10’s comes in handy here… This rule helps with reducing the amount of data pulled when first investigating an event, so we’ll pull 10 minutes before and 10 minutes after the event.
By using tcpdump or WireShark we’ll be able to pull this packet data. After doing some packet analysis we discover the friendly device was redirected to the malicious host from a third-party advertisement on a legitimate website, which downloaded the PDF.
To dive a bit deeper into this relationship we inspect this malicious PDF by submitting it to Cuckoos Sandbox. During the automated malware analysis, we see that this PDF has a hardcoded secondary hostile IP address of 192.0.2.6.
We’ve now found ourselves moving onto the “secondary subjects” in this investigation and it’s time we find out more about this secondary hostile device.
Hostile Intelligence for 192.0.2.6:
- IPVoid returned 2 matches for this IP address
- Our NetFlow data shows that the friendly primary device 172.16.16.20 has communicated with this hostile device, which happened thirty minutes after the initial alert.
- Our NetFlow data also shows that two other friendly devices on our network have been communicating with this hostile IP address periodically for the past several days. The secondary friendly IP addresses are 172.16.16.30 and 172.16.16.40.
Last we’re going to want to understand the “secondary relationship” between our primary and secondary friendly devices.
We gather the full PCAP data between our primary friendly and secondary hostile devices, which shows they’re communicating over port 80, but with a custom protocol and not the expected HTTP protocol. This custom protocol enables our primary friendly device to send system information, as well as reoccurring callbacks to the secondary hostile device.
We now check out the communications between our secondary friendly and secondary hostile devices, finding the same custom protocol being used over port 80.
That simple alert turned into something much more serious… A “command and control server” has penetrated our network taking over three of our friendly devices.
Remember! Nothing is wrong with using a standard relational approach as a newcomer to cybersecurity. Without this standard process, we would’ve missed this attack on our first week on the job and opened up that pharmaceutical company to a world of hurt.