Carolina Pinto

Helping organizations turn regulation into practical security.

6 minute read

Ever wonder how IT and security teams figure out exactly what happened when something goes wrong? Like, how do they know that someone logged into a system at 2am from a weird location, or that malware tried to sneak past a firewall? The answer is simpler than you’d think: logs.

Let’s break down what logs are, why they matter, and how to actually read them — without the jargon overload.

Logs Are Basically a Diary for Your Devices

Think about it this way: every time something happens on your phone, laptop, or a company’s server — a login, an error, a file getting deleted — the system writes it down. That written record is a log, and each individual entry is like one diary entry describing a single event.

Originally, logs were just for troubleshooting. Your app crashed? Check the error log to see what went wrong. But today, logs do so much more — especially in security. When something suspicious happens, security analysts dig through logs to answer the same questions a detective would ask: who did it, what happened, when, where, and why.

Security teams usually don’t dig through logs on individual devices one by one (imagine how exhausting that would be). Instead, they use SIEM tools — think of these as a big filing cabinet that pulls in logs from everywhere in the organization into one central place, so analysts can search through everything at once.

Not All Logs Are Created Equal

Just like your diary might have entries about school, work, and your weekend plans, organizations generate different types of logs depending on what’s producing them:

  • Network logs — from routers, firewalls, switches (the “traffic cops” of your network)
  • System logs — from the operating system itself (Windows, macOS, Linux)
  • Application logs — from specific software, like a banking app logging when you check your balance
  • Security logs — from antivirus or intrusion detection tools
  • Authentication logs — literally just “who logged in, and when”

Here’s a simple authentication log entry:

Login Event [05:45:15] User1 Authenticated successfully

Nice and short. But you can also crank up the detail with verbose logging, which is like the difference between texting “omw” versus giving someone your exact GPS coordinates, your route, and your ETA:

Login Event [2022/11/16 05:45:15.892673] auth_performer.cc:470 User1 Authenticated successfully from device1 (192.168.1.2)

Same event, way more context.

The Golden Rule: Don’t Log Everything

Here’s a mistake beginners (and honestly, a lot of orgs) make: thinking “more logging = better security.” Nope.

Imagine keeping a diary where you write down literally every single thing you do all day — every step you take, every blink. Sure, you’d technically have “all the data,” but good luck finding the one entry that actually matters when you need it. That’s basically what overlogging does. It jacks up storage costs, slows systems down, and buries the important stuff under a mountain of noise.

There’s also the privacy angle — things like phone numbers, emails, and names count as personally identifiable information (PII), and depending on where you operate, you might not even be legally allowed to log that stuff without special handling.

And speaking of legal stuff — certain industries have rules about how long you have to keep logs around (this is called log retention). Healthcare has HIPAA, finance has PCI DSS and SOX, government has FISMA. It’s basically the compliance version of “keep your receipts for tax season.”

Protecting the Diary from Getting Rewritten

Here’s a scary thought: what if a burglar broke into your house, but before leaving, they edited your diary to remove any evidence they were ever there?

That’s exactly what attackers try to do with logs — tamper with them to erase their tracks. That’s why storing logs on a centralized server, separate from the original device, is so important. It puts a wall between the attacker and the evidence, so even if they compromise one machine, they can’t quietly rewrite the whole story.

Okay, But What Do Logs Actually Look Like?

This is where it gets fun. Logs come in different formats, kind of like how a recipe could be written as a numbered list, a paragraph, or a table — same information, different structure. Here are the five you’ll run into most.

1. JSON — The “Neatly Labeled Boxes” Format

JSON (JavaScript Object Notation) is probably the friendliest format for beginners because it’s basically labeled data. Think of it like a form with clearly marked fields:

"Alert": "Malware"

That’s a key-value pair — “Alert” is the label (key), “Malware” is the actual info (value). Add curly brackets { } to group related info together (called an object), and square brackets [ ] when you want an ordered list (called an array):

"User": {
  "id": "1234",
  "name": "user",
  "role": "engineer"
}

It’s readable almost like plain English once you get the hang of it — no wonder it’s everywhere in web apps and cloud platforms.

2. Syslog — The OG Standard

If JSON is the new kid, syslog is the classic that’s been around forever, especially on Unix/Linux systems. A syslog entry has three parts: a header (timestamp, hostname, app name), structured data (extra details in brackets), and a message.

<236>1 2022-03-21T01:11:11.003Z virtual.machine.com evntslog - ID01 [user@32473 iut="1" eventSource="Application" eventID="9999"] This is a log entry!

Yeah, it looks intimidating at first glance, but break it into chunks and it’s not so bad:

  • <236> = priority (lower number = more urgent, kind of like a hospital triage system)
  • Timestamp, hostname, app name = the “who/when/where”
  • The bracketed stuff = extra details
  • The final sentence = the actual message

Syslog is also a protocol (a way to ship logs to a central server) and a service (that does the shipping) — same name, three jobs.

3. XML — Windows’ Favorite

XML uses tags that wrap around data, like little labeled envelopes:

<Event>
  <EventID>4688</EventID>
  <Version>5</Version>
</Event>

Here, <Event> is the “parent,” and <EventID> and <Version> are its “children” tucked inside. Tags can also carry extra attributes, like a nametag with additional info pinned to it:

<Data Name='SubjectUserName'>JSMITH</Data>

4. CSV — The Spreadsheet Format

CSV is exactly what it sounds like — comma-separated values, like a spreadsheet squished into one line of text. The catch? The field names often aren’t included, so you need to already know what each position means (kind of like memorizing that in a friend’s contact info, it’s always “name, phone, email” in that order, even if they never label it):

2009-11-24T21:27:09.534255,ALERT,192.168.2.7,1041,x.x.250.50,80,TCP,ALLOWED,1:2001999:9,"ET MALWARE BTGrab.com Spyware Downloading Ads",1

5. CEF — The Security-Specific Format

Common Event Format (CEF) is built specifically for security tools and uses pipes | to separate its main fields, then key-value pairs for extra details:

Sep 29 08:26:10 host CEF:1|Security|threatmanager|1.0|100|worm successfully stopped|10|src=10.0.0.2 dst=2.1.2.2 spt=1232

Translation: “On Sep 29 at 8:26am, a security tool called threatmanager stopped a worm from spreading from 10.0.0.2 to 2.1.2.2 through port 1232, and rated it a high-severity (10) event.” Once you know the pattern, it reads almost like a headline.

The Takeaway

Logs might look like walls of confusing text at first, but they’re really just detailed diaries — and once you know the format, they tell a clear story. The real skill isn’t memorizing every format perfectly; it’s learning to recognize the pattern so you can quickly spot the who, what, when, where, and why when it actually matters.

You May Also Enjoy