How do Network Analysts do what they do? (Network Analyst Lab Overview)

As a network analyst, your home base is the SIEM — the security information and event manager. This is where you lay eyes on all the juicy logs that tell the story of who, what, where, when, and sometimes why. Those are the core questions a network analyst is expected to answer. In essence, you're the detective of the network.

So how does a SIEM help you sleuth out the answers you're looking for? First, let's talk about logs. Devices, services, and applications all generate them to track what happened, when it happened, and who did it. Investigating logs on a single machine is straightforward: on Linux you check /var/log or journalctl, and on Windows you go to Event Viewer (eventvwr.exe). But no enterprise is made up of just one system. Even small organizations have many devices, many users, sometimes multiple locations, and almost guaranteed integrations with third-party applications — especially as more organizations move to the cloud. The point is, managing logs can get unwieldy. An investigation can't take place if you can't get your eyes on the security feed.

That's where the SIEM comes in. Agents are deployed to monitor logs and send them to a centralized location. The analyst monitors those centralized logs in the SIEM dashboard to put together the story and write their report. Those are the pieces that come together in the network analyst lab. A service called Filebeat monitors the access and error logs from an Nginx server — Filebeat is the agent. Filebeat then sends the logs to an Elasticsearch (ES) database — that's the centralization. ES is then queried and the results are sent to the custom dashboard where you, the analyst, can examine and build the story of what happened. This is exactly how things are done in the real world, only replacing the lab dashboard with Kibana. It's often referred to as the ELK stack (Elasticsearch, Logstash, and Kibana).

I do recommend setting up your own ELK stack lab. Trust me, you'll learn a ton about how a SIEM works, and it's open-source!

Knowing what a SIEM is is only half the battle. What is the actual job of the analyst? How do you use logs to tell the story? Well, what information can be extracted from logs? Here's how to break it down:

• The who = What IPs or user accounts are attached to the logs?

• The what = What do the logs say happened?

• The where = What device or service generated the logs?

• The when = When did it start, and when did it end?

• The why = What was the final result? Did anything change? Was anything extracted?

Logs will contain this information. Take our simulation for instance. What do we know? Well for one, they're web attacks. How do we know this? (And no, not just because of the simulation labs.) Look at the structure of the logs. Where do you see GET/POST requests, the HTTP protocol, or 200 and 302 status codes? When making web requests. If you don't know what I'm talking about, then I suggest you start with networking and how websites actually work. It's complex and fascinating and will really demystify the lab — and the internet in general.

Once you can read the logs, the next step is triage. In the real world, you'd use tools like VirusTotal and Wireshark to fill in the meat of the story — like what country a request is coming from, for example. Luckily for you, the tools provided in the lab give you enough information to finish the report. And once you understand the story and complete the report? All that's left is to notify the necessary management chain (at least as a junior analyst).

That's exactly the workflow the lab is built around — so you can visualize and immerse yourself in the role of a network analyst, analyze real logs, and see real attack patterns in action.