learn-cyber · lesson 1 · fundamentals

From event to alert

The one mental model the whole business runs on — how a SIEM turns a hotel's everyday noise into something worth waking up for.

Your mission You're building an MSSP to monitor hotels with Wazuh. Before any install, you need the model in your head that you'll keep returning to — and that you'll one day explain to a hotel owner deciding whether to pay you.

The problem, in one sentence

Every device in a hotel is constantly writing down what it does — these notes are called logs, and each line is an event. The front-desk PC logs every login. The PMS logs every reservation lookup. The firewall logs every connection. A single mid-size hotel can produce millions of events a day.

Buried in that flood are the few events that mean someone is attacking. Nobody can read millions of lines. A SIEM is the machine that reads them for you and taps you on the shoulder for the handful that matter.

Key idea A SIEM (Security Information and Event Management) collects logs from everywhere, analyzes them for signs of trouble, and raises alerts. Wazuh is an open-source SIEM — the engine your whole MSSP is built on.

Why we bother: the CIA triad

Every attack you'll ever detect is trying to break one of three things. This is the oldest idea in security, and it's the "why" behind every alert.1

When you sell to a hotel, you're selling protection of these three things. Keep the triad in mind and every Wazuh rule will have an obvious purpose.

The pipeline: event → alert

Here's the model. Memorize this shape — everything in Wazuh hangs off it.

1. CollectAn agent on each device ships its logs
→
2. DecodePull fields from each raw line
→
3. Match rulesDoes this look bad? How bad?
→
4. AlertRaise it for a human
→
5. TriageYou decide: real or noise?

Walk it through with a real hotel example

Attacker tries to brute-force the hotel's PMS server over SSH:

  1. Collect. The agent on the PMS server reads its auth log and ships each line to your Wazuh manager.
  2. Decode. A decoder reads Failed password for admin from 203.0.113.9 and extracts the fields: user=admin, srcip=203.0.113.9, action=failed login.
  3. Match rules. One failed login is normal. But a rule watches for many failures from one IP in a short window — that's correlation — and fires at a high severity level.
  4. Alert. Wazuh raises one alert: "Possible SSH brute-force against PMS server, source 203.0.113.9."
  5. Triage. You (the SOC) look: is it an attacker, or the hotel's own IT guy fat-fingering his password? You decide and act.
The compression that makes this a business Millions of events → thousands of decoded records → a handful of alerts → one decision. Each arrow throws away noise. Selling that compression — so a hotel doesn't need to read a single log line — is your product.

Where Wazuh's four parts sit on the pipeline

You'll meet these properly in Lesson 2, but anchor them to the pipeline now:

Check yourself

Retrieval practice — answering from memory is what makes this stick. Don't peek back up; take the guess.

Question 1 of 3

In the pipeline, what does an agent actually do?

The agent does step 1, Collect — it lives on each endpoint and ships that device's logs to the manager. Decoding, matching, and alerting all happen on the manager.

Question 2 of 3

Ransomware locks the PMS so staff can't check guests in. Which part of the CIA triad just broke?

Availability is "systems stay up and usable." The data may still be secret and unchanged, but if nobody can use the PMS, availability is broken — and the hotel is losing money every minute.

Question 3 of 3

Why does seeing fifty failed logins matter far more than seeing one?

Correlation — connecting many events into one signal — turns harmless individual events into a meaningful "brute-force in progress" alert. It's the heart of what a rule does.

Primary source to read next
Wazuh — Getting Started. Read just the opening overview (5 min). Notice how it describes Wazuh as unifying "XDR and SIEM" — you now know exactly what the SIEM half means. Optional deeper "why": skim the intro of NIST SP 800-92 on log management.
I'm your teacher — ask me anything. Stuck on why decoding comes before rules? Curious how this maps to a specific hotel system? Want a harder example? Just ask in the chat. That back-and-forth is where the real learning happens.

You just earned: the event→alert mental model, the CIA triad, and where Wazuh's four parts sit. Everything else builds on this.

Up next (Lesson 2): Wazuh's architecture in detail — manager, indexer, dashboard, agents — and how one deployment can watch many hotels at once.

Reference: Glossary · All resources · Mission