· Certification Training

SEC503 - GIAC Certified Intrusion Analyst

Date Earned: February 13, 2021
Proof: https://www.credly.com/badges/56086fc8-f848-4b13-b7e4-b6f2947e1028/public_url
Linky: https://www.sans.org/cyber-security-courses/intrusion-detection-in-depth/

This is frustration
This is frustration!

I loved this training and certification journey. This was my first SANS experience, and David Hoelzer was a proper rock star, but more on that below. Despite attempting the certification almost three years after sitting the training, I’m happy enough with the result (although part of me thinks I’d almost have rather gotten a 95%).

Who’s it for?

GCIA is for people who get down and dirty in networking. It suits SOC analysts who monitor, review and triage network intrusion detection / prevention systems, or who write detection logic for these systems. It suits incident response personnel who receive insanely large packet captures from clients and need to quickly triage, or investigate these collections for evidence of threat actor activity.It suits threat hunting staff flailing against the massive amounts of ingress / egress network traffic, searching for anomalies.It also suits security architects who want to be able to design and implement high quality intrusion detection and prevention systems across an organisation’s network.

A student who is familiar with general networking concepts (routing protocols, subnetting, NAT / PAT and a passing knowledge of the OSI model) will excel in this class. Skills with the linux command line will also be beneficial.

If you’re looking to get a head start on this training, or keep your skills sharp after taking the class, Malware Traffic Analysis has an impressive collection of scenarios, including pcap and alert data. It also has solutions to the problems, so you can continue learning even if you get proper stuck. All screenshots below have been taken from my processing of one of these scenario packages: Cupid’s Arrow Online.

Training

I took the OnDemand training in 2018. This provided me with mp3’s recorded from a class, downloadable VM’s with a collection of lab files. A few days after my start date, a box arrived with my physical course books and some swag (a SANS branded thermal cup that has a weird suction cup thing on the bottom, making it difficult to knock over. Had some real fun in the office slapping it around for an afternoon). Finally, I received 4 months access to pre-recorded lecture videos going over all of the content, and 4 months access to a VPN environment containing a CTF style server that seems to mimic the Day 6 challenge environment.

We start with the very core of how networking works, learning how packets are constructed at the byte level. We break down both the TCP/IP and OSI models, and how they work practically to make up frames, packets, and segments (but let’s be honest, in the real world they’re all packets ;) ). Furthermore, we dive deep into how different protocols work in isolation, and how they work together to make the internet work. If they weren’t already, jokes like this will suddenly be hilarious:I’d tell you a joke about UDP, but you might not get it.

Say hello to your new best friend
Say hello to your new best friend

On this part of the course, I would have loved to see a little more information on NAT / PAT and subnetting, but that could very well be a personal preference.

Once we’re familiar with how networking works generally, we start to learn how we can capture and filter network traffic. This has us using Wireshark and tcpdump with Berkely Packet Filters (bpf) to filter live network traffic, or previously captured traffic, with surgical precision. This is where the knowledge we acquired yesterday shows its value - with a single filter, you can very quickly find only UDP packets, or packets sent to port 80, or only packets with the TCP RST and ACK flags set.

Let’s see only the TCP SYN packets headed to port 80
Let’s see only the TCP SYN packets headed to port 80

We also learn how to follow specific network conversations, and how to pull transmitted files (like files transmitted over HTTP). If we were concerned about any of these, we can save them to disk and perform deeper analysis.

Standard web traffic… or is it?
Standard web traffic… or is it?

Now that we know how to deeply analyse specific networking conversations, we need to learn how to find those needles of interesting traffic in the haystack of business traffic. Here we learn what netflow is, and how we can use a suite of tools (known collectively as SiLK) to generate and review netflow data from either raw traffic or pcaps. SiLK provides a powerful capability in the identification and enumeration of trends, which is where netflow shines. This is largely where incident responders and threat hunters will derive a good deal of value.

Filtering for TCP (proto 6), and showing the top 5 results by source port. We’re probably monitoring some web servers here, but those high-ports are interesting.
Filtering for TCP (proto 6), and showing the top 5 results by source port. We’re probably monitoring some web servers here, but those high-ports are interesting.

We also learn about Snort and Bro (now Zeek), network traffic inspection systems that are going to be our detection or prevention bread and butter.

Snort takes signature files that take a single or combination of characteristics for a given network connection, and can alert on that traffic if the signature matches. This doesn’t just need to be networking characteristics (destination port, source IP address, protocol, etc), but can do complex matching against the packets themselves, known as Deep Packet Inspection. For example, destination port of 80 (HTTP, typically) but the application layer data doesn’t match HTTP, it’s all binary, or there’s no HEAD tag. We learn how to both read the alerts Snort generates, and write our own rules for newly identified malicious traffic.

Snort is alerting us to an oddity. Note the xref links. While not mandatory, if you write rules without them, I’ll cry.
Snort is alerting us to an oddity. Note the xref links. While not mandatory, if you write rules without them, I’ll cry.

With netflow, we don’t have enough information to perform a complete investigation. With Snort and full pcap, we have all the data in the world, but the infrastructure to support full pcap and the time to analyse it can be prohibitive. If only there was some form of middle ground…

Enter Zeek (formerly Bro). Zeek works to pull out the interesting parts of network traffic (files transmitted, certificate thumbprints, connection metadata, SNMP config’s pushed, etc) without the overhead of storing every packet transiting the network. Additionally, we can write our own rules to pull out specific metadata, if it matters for our particular environment. For example, maybe we write rules to log all commands sent from a central server out to ATMs, so that these can be audited and reviewed should anything go awry.

Stacking based on certificate issuer to find resources with a low frequency of occurrence.
Stacking based on certificate issuer to find resources with a low frequency of occurrence.

With our newly minted detection logic in place, we need to test it before throwing it straight into production (because that’s what we do as professionals, right? We test, then push into production. We never test in production…). To that end, we get down and dirty with Scapy, a python project we can use to easily generate our own packets / network traffic. Most importantly (I think), Scapy takes the guard rails off and lets us programmatically generate invalid packets (as different OS’s handle these packets differently, we need to be able to test them). Invalid checksums, miscalculated TCP sequence numbers or IP length values, all are easily generated and transmitted with Scapy.

Custom packet built and sent in Scapy to test our detections
Custom packet built and sent in Scapy to test our detections

All of this is tested on Day 6, with a massive CTF style challenge. The challenge questions guide you through three massive 10 gigabyte+ packet capture files, each captured from a different segment of a fictitious network. It walks us through identifying some anomalous traffic, then has us track down this activity through the network and enumerating exactly what the threat actor did in this attack. Being OnDemand, I was ineligible for a sweet sweet challenge coin, which was unfortunate.

All of this content was expertly delivered by David Hoelzer, author and instructor for this course. Coming into it, I was dubious as to how SANS could justify their training price tag. David did a fantastic job of showing how SANS stays in business :D. He has mastered the art of answering questions students may have before they get asked - this is difficult at the best of times, but when you add in a non-interactive medium like OnDemand (pre-recorded videos), it really lets his expertise shine through. This expertise and theory is backed by a truly impressive number of hands on labs that cement the knowledge we’re being bombarded with.

Certification

I didn’t get a certification attempt as a part of my initial training. I only revisited the idea of getting this certification a couple of years later when I was in a better financial position. Cheeky hint here, if you ever find yourself in the same position, you can reach out to SANS, and they may flick you a tasty wee discount. It worked for me, which I was grateful for.

The exam attempt comes with two practice tests, which are super closely aligned to the actual exam in content and format. My test was made up of 106 questions, 10 of which were VM-based hands on practical questions, to be answered in a four-hour testing marathon.

The idea of hands on practical questions scared the crap out of me. Thankfully, I got to trial these in the practice tests, and realised they weren’t the monsters I’d built them up to be in my head. They aren’t massive compounded questions, as long as you can do all the material in the labs (and it’s open book, so you can look up your notes), you won’t have any issues. After going through the whole process, I think I’d rather a test made up of 20-30 practical questions over the inclusion of multi-choice questions.

I do strongly recommend the creation of your own index to take in to the exam, but more as a learning technique than as a pass-the-exam technique. This is mostly because I think the value of a certification is the process of acquiring the understanding required to pass, instead of rote memorisation. I’ll cover my process of creating a SANS index in a future post.

Hopefully this has given you a better understanding of the SEC503 material and associated exam, and you can now make an informed decision about signing up, or be more confident going in to the exam. Either way, good luck! If you have any questions, you can reach me via the social buttons on the left.