learn-cyber · lesson 10 · capstone

Onboarding your first hotel: the runbook

Everything you've learned, sequenced into one repeatable checklist — the path from a handshake to a delivered, paid-for monitoring service.

Why a runbook, not a hero project

The difference between a hobbyist and an MSSP is repeatability. A hobbyist installs Wazuh once, heroically, and can never remember how. An MSSP has a checklist: same phases, same order, every client. The checklist is the product — it's what lets you onboard hotel number two in a week instead of a month, and what lets you hand work to a teammate one day.

The onboarding runbook

Work the phases in order. Each links back to the lesson that taught the skill, so you can drop in for a refresher at any point. We'll use Seaside Inn as the running example throughout.

1. Phase 1 — Scoping call & asset inventory

   Sit down with the hotel — ideally on-site — and list every system that touches data or the network: the PMS (Seaside runs Oracle OPERA), the restaurant POS terminals, the firewall, switches, the 4 front-desk PCs, the Wi-Fi (guest and staff), and any remote or vendor access (the OPERA support tunnel, the POS vendor's dial-in). For each, ask: what does it do, and does it touch cardholder data? Identify the crown jewels — the systems whose compromise would end the business — using the lens from Lesson 8 (hotel threat model). Anything that takes cards drags you into PCI scope (Lesson 9), so flag it now. Output: an asset / risk register — one row per system, with owner, role, card-data flag, and rough risk. This single document drives every phase that follows.

2. Phase 2 — Network & data-flow review

   Now trace the wires. Where does a swiped card number actually go — from the POS terminal, through which switch, to which processor? Is the guest Wi-Fi truly segmented from the PMS and POS networks, or is it all one flat LAN (alarmingly common in 60-room properties)? Sketch the data flow and mark the gaps. Be honest about your role: you monitor; you usually don't re-architect. Segmentation fixes may be advisory notes in your report, or a job for the hotel's network partner — but you must know the topology to place sensors well and to scope PCI correctly.

3. Phase 3 — Stand up (or extend) the Wazuh deployment

   For your first hotel, a single all-in-one node — manager, indexer, and dashboard on one box — is perfectly fine and gets you live fast. Follow Lesson 3 (install the server) exactly as you did in the lab; this is the same procedure, now in production. Keep the bigger picture from Lesson 2 (architecture) in mind: as you add hotels three, four, five, you'll split into a cluster — multiple managers feeding a shared indexer. Don't build that yet. Build the smallest thing that works, and plan the seam for growth.

4. Phase 4 — Create the client's isolation first

   Before a single agent is deployed, build Seaside Inn's compartment so everything lands in the right place. Create the agent group seaside-inn (Lesson 6, agent groups), an RBAC role scoped to that group, and a dashboard tenant for the hotel (Lesson 7, RBAC & tenants). Doing this before deployment is the whole trick: agents enrolled into seaside-inn inherit the group's config automatically, and their data is walled off from every other client from the first event. Set up the room before you let the guests in.

5. Phase 5 — Deploy agents, crown jewels first

   Now enroll agents, in order of value: the OPERA PMS host first, then the POS terminals, then the 4 front-desk PCs — the same enrollment flow you practiced in Lesson 4 (first agent & detection), each joined to the seaside-inn group. The firewall and switches can't run an agent, so ingest their logs agentless via syslog instead (the manager listens; the device forwards) — recall the collection paths from Lesson 2. Then push what to watch through the group's agent.conf (Lesson 6): file-integrity monitoring on the POS binaries and OPERA config files, authentication logs, and so on. Configure once at the group; every Seaside host obeys.

6. Phase 6 — Tune detections

   Out of the box, Wazuh's built-in rules already fire on SSH brute-force, new accounts, and the like — confirm they trigger on Seaside's hosts. Then write the custom decoders and rules for this hotel's specific log formats: OPERA's audit lines, the restaurant POS's transaction log. Build and test them with wazuh-logtest exactly as in Lesson 5 (decoders & rules) before you trust them. The goal here is fewer, truer alerts: chase down false positives now, because an analyst who learns to ignore the dashboard is worse than no analyst at all. Trustworthy alerts are the foundation everything operational rests on.

7. Phase 7 — Define alerting, triage & escalation

   A firing rule is only half a service; someone has to act. This is the triage step from the very first pipeline you learned (Lesson 1, event → alert). Decide: which severity levels page a human at 3 a.m. versus wait for the morning queue; who is on call; and what the response playbook says for the common cases (brute-force on OPERA, malware on a front-desk PC, POS file change). Write down an SLA — "critical alerts triaged within 30 minutes" — and mean it. The SLA is what the hotel is actually buying.

8. Phase 8 — Reporting & PCI evidence cadence

   Set a recurring reporting rhythm — monthly and quarterly — pulled from Seaside's own dashboard tenant: log-review summaries, file-integrity changes, alert counts and outcomes, all mapped to the PCI-DSS requirements (Lesson 9) the hotel must satisfy (log review, FIM, access monitoring). This recurring deliverable is not busywork — it's the proof of value the owner can hand to their acquiring bank and their QSA, and it's what justifies your monthly retainer. A hotel forgets the install in a week; it remembers the report that arrives every month.

9. Phase 9 — Pilot, review, expand

   Run a defined pilot period — say 60 days. At the end, sit down with the hotel again: walk the findings, show the alerts you caught and what you did, tune out whatever still cried wolf, and adjust the SLA against reality. Then expand: add coverage you skipped at first (staff laptops, the booking-engine server), and use the now-proven runbook to onboard the next property. The pilot's real output isn't just a happy client — it's a validated, repeatable process you can sell again.

On pricing & positioning (briefly): the value you sell is the recurring monitoring and the monthly PCI evidence — the SLA, the triaged alerts, the report that lands every month. That's a retainer. Do not sell a one-off "install Wazuh and walk away" project; it underprices the real work, leaves the hotel unmonitored the day after, and trains the market to see you as a contractor instead of a service. The install is the cheap part; the watching is the business.

Check yourself

Retrieval practice — pull the runbook from memory. Don't peek back up; the sequencing is the whole point.