Learning Objectives

After completing this section, you should be able to:

• Explain why planning is essential before deploying a SOC.

• Design a repeatable virtual infrastructure.

• Develop a logical IP addressing scheme.

• Understand host naming conventions.

• Document a cybersecurity laboratory using professional engineering practices.

Introduction

One of the most common mistakes made by beginning cybersecurity students is starting installations immediately.

The process often looks like this:

• Install Windows.

• Install Ubuntu.

• Install Wazuh.

• Install Suricata.

• Hope everything works.

Professional engineers work differently. They plan first. Large organizations may spend weeks designing infrastructure before installing a single operating system. Although our laboratory is much smaller, the engineering methodology remains exactly the same. Good planning reduces installation problems, simplifies troubleshooting, and creates an environment that can be expanded throughout the remainder of the textbook.

Engineering Before Installation

Imagine constructing a hospital.

Would construction begin before creating architectural drawings?

Of course not. Cybersecurity laboratories deserve the same level of planning.

Before installing software, engineers answer questions such as:

• Which systems are required?

• How will they communicate?

• Which IP addresses will they use?

• Which systems monitor traffic?

• Which components require Internet access?

• Which systems generate telemetry?

• Which services depend upon other services?

Only after answering these questions does installation begin.

Analyst Corner

One habit has consistently distinguished successful cybersecurity professionals throughout my career:

They document everything. Documentation is not busy work. Documentation is a troubleshooting tool.

Three weeks after building a laboratory, you should be able to answer questions such as:

• Which version of Ubuntu am I running?

• Which IP address belongs to Suricata?

• Which interface operates in promiscuous mode?

• Which Emerging Threats rule set is installed?

• Which version of Sysmon am I using?

• Which Wazuh Agent version is installed?

If you cannot answer those questions quickly, your documentation is incomplete.

Laboratory Design Principles

Throughout this textbook, the laboratory follows six engineering principles.

Principle 1 — Simplicity

Every component should have a clearly defined purpose. Avoid unnecessary systems. If a machine contributes no operational value, it does not belong in the laboratory.

Principle 2 — Consistency

Every student should use:

• Similar hostnames

• Similar IP addresses

• Similar operating systems

• Similar software versions

Consistency greatly simplifies classroom troubleshooting.

Principle 3 — Repeatability

A professional laboratory should be reproducible. If the entire environment is lost, you should be able to rebuild it using only your documentation. This is one reason virtualization is so valuable.

Principle 4 — Isolation

The laboratory should remain isolated from production networks whenever possible.

Students will intentionally generate:

• Malware detections

• Port scans

• Password attacks

• PowerShell activity

• Network reconnaissance

• DNS testing

These activities should remain within the controlled environment.

Principle 5 — Expandability

Today’s four-machine laboratory becomes tomorrow’s enterprise network.

Later chapters will introduce:

• Active Directory

• Multiple Windows endpoints

• Kali Linux

• Linux servers

• Web servers

• Vulnerability scanners

• Docker containers

• Cloud logging

• Zeek

• pfSense

A good design anticipates future growth.

Principle 6 — Validation

Every installation step concludes with verification. Never assume a configuration works simply because no error appeared. Generate telemetry. Verify alerts. Confirm communication. Trust evidence—not assumptions.

Laboratory Documentation

Professional engineers maintain infrastructure documentation. Throughout this textbook, students will create and maintain a SOC Engineering Notebook.

The notebook records:

This notebook becomes one of the most valuable tools in the course.

Host Naming Standards

Large organizations rarely name computers randomly. Compare these examples.

Poor naming:

Computer1

Ubuntu

Jim-PC

Windows

LinuxBox

Professional naming:

WAZUH-SRV

UB2604

WIN11

SO14

Immediately, the second naming convention communicates purpose. Throughout this textbook we will use consistent naming standards.

Recommended Hostnames

As the laboratory expands, additional systems will follow the same convention.

Examples:

WIN11-B

UBU-WEB01

DC01

WEB01

Consistency simplifies investigations. Note that Wazuh agent names (set at enrollment) are lowercase — u2604, win11 — while hostnames are uppercase. Dashboard queries are case-sensitive, so this distinction matters the moment you search for events.

IP Address Planning

Good network design begins with predictable addressing. Throughout this textbook we use a dedicated laboratory subnet.

Example:

Students should avoid relying on DHCP whenever possible. Static addressing improves troubleshooting and documentation.

Figure 3-4

Laboratory Address Plan

Note. The figure summarizes laboratory Address Plan and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

As additional systems are introduced, addresses remain predictable.

Network Interface Documentation

One lesson learned from our own laboratory development is that network interfaces matter. For example, the Ubuntu sensor contains two interfaces.

Note that in this laboratory ens192 carries no IP address and runs in promiscuous mode — the silent sensor design introduced in Chapter 1. The interface receives every frame on the segment but cannot itself be addressed. Security Onion’s dedicated sniffing interface (eth1) uses the same design. What differs between the two is role, not addressing: UB2604 is a dual-homed host that also captures, while SO14 is a dedicated capture appliance.

Students should document:

• Interface names

• MAC addresses

• IP addresses

• Connected virtual network

• Operational purpose

Failure to document interfaces is one of the most common causes of Suricata troubleshooting problems.

SOC Tip

Do not refer to interfaces as “the first adapter” or “the second NIC.”

Instead, always use their actual Linux names:

• ens160

• ens192

Professional documentation should be precise enough that another administrator can identify the correct interface immediately.

Version Control

Another hallmark of professional engineering is version tracking.

Throughout the course, students will record:

When troubleshooting, version information is often just as important as configuration.

Think Like a SOC Engineer

Suppose another instructor asks you to duplicate your laboratory.

Could you rebuild it using only your documentation?

If the answer is no, your documentation is incomplete.

Professional engineers create environments that are:

• Repeatable

• Understandable

• Maintainable

• Expandable

• Recoverable

Those five characteristics will guide the design of every system throughout this textbook.

Looking Ahead

With the laboratory design complete, the next section begins building the virtual infrastructure itself. Students will learn how to configure VMware networking, choose the appropriate virtual network modes, assign adapters, create snapshots, allocate CPU and memory resources, and prepare each virtual machine for installation. By the end of the next section, the virtual foundation of the Security Operations Center will be complete and ready for operating system deployment.

Learning Objectives

After completing this section, you should be able to:

• Explain why virtualization is fundamental to cybersecurity.

• Describe the advantages of VMware Workstation for SOC laboratories.

• Differentiate between virtual machines, virtual networks, and virtual switches.

• Understand resource planning for a multi-system laboratory.

• Explain why snapshots are one of the most valuable cybersecurity tools available.

Introduction

Nearly every modern Security Operations Center relies heavily on virtualization. Whether deployed in a university laboratory, a corporate data center, or a cloud environment, security professionals routinely investigate systems that exist entirely as virtual machines. Virtualization has transformed cybersecurity by allowing analysts to rapidly deploy, modify, clone, snapshot, destroy, and rebuild complete computing environments within minutes. Without virtualization, building a Security Operations Center would require multiple physical servers, networking equipment, storage systems, and considerable financial investment. Instead, our entire SOC operates on a single workstation.

What Is Virtualization?

Virtualization is the process of creating software-based computers that behave exactly like physical computers.

Each virtual machine has its own:

• CPU

• Memory

• Storage

• Network adapters

• BIOS/UEFI

• Operating system

• Applications

• Security software

To the operating system, there is no practical difference between running on physical hardware or virtual hardware. Windows believes it is installed on a real computer. Ubuntu believes it is installed on a real computer. Suricata has no knowledge that the packets it analyzes originate from virtual network adapters. This abstraction makes virtualization one of the most important technologies in modern cybersecurity.

Figure 3-5

Physical vs. Virtual Infrastructure

Note. The figure organizes the major elements of physical vs. Virtual Infrastructure to clarify their roles, relationships, and escalation or inheritance paths.

| --- |

One physical computer now hosts an entire Security Operations Center.

Why Virtualization Changed Cybersecurity

Virtualization offers several significant advantages.

Rapid Deployment

Creating a new server often requires only a few minutes. No physical hardware needs to be purchased.

Safe Malware Testing

Students will intentionally generate:

• Malware detections

• PowerShell alerts

• Port scans

• Network attacks

• Authentication attacks

Virtual machines isolate these activities from production systems.

Repeatability

If something breaks, restore a snapshot. The laboratory immediately returns to a known-good configuration.

Cost Reduction

A four-system SOC laboratory requiring thousands of dollars in hardware can be operated from a single workstation.

Easy Recovery

Mistakes become learning opportunities rather than disasters. Snapshots allow complete recovery within minutes.

Analyst Corner

One phrase you’ll hear throughout this course is:

“Take a snapshot before making changes.” Professional SOC engineers never perform major upgrades without first creating a recovery point. Snapshots have saved countless hours of rebuilding laboratories after configuration mistakes, failed software updates, or accidental deletions. If you develop only one virtualization habit from this textbook, make it this one.

Understanding the Hypervisor

A hypervisor is the software responsible for creating and managing virtual machines.

Examples include:

Throughout this textbook we use VMware Workstation because it provides:

• Excellent stability

• Robust snapshot management

• Flexible virtual networking

• Strong hardware compatibility

• Enterprise-quality virtualization

VMware Components

Students often think VMware simply “runs virtual machines.” It actually provides several independent technologies.

Understanding these components greatly simplifies troubleshooting.

Hardware Resource Planning

Unlike physical computers, virtual machines share hardware resources. Proper planning prevents performance problems.

Recommended minimum resources for our laboratory:

Host computer recommendation:

These recommendations provide sufficient resources for smooth laboratory operation while leaving capacity for future expansion.

Resource Overcommitment

Virtualization allows more virtual CPUs and memory to be assigned than physically exist. This is called overcommitment.

While useful in enterprise environments, excessive overcommitment can lead to:

• Slow virtual machines

• Delayed alerts

• Dropped packets

• Missed Suricata detections

• Poor user experience

Throughout this textbook we intentionally allocate conservative resources to ensure consistent performance.

Understanding Virtual Hardware

Every virtual machine receives simulated hardware.

Windows and Ubuntu detect devices such as:

• Network adapters

• Hard disks

• Display adapters

• USB controllers

• Firmware

• Sound devices (optional)

Although simulated, these devices behave much like physical hardware.

For example, Ubuntu identifies virtual NICs using predictable names such as:

ens160 ens192

These interface names become important when configuring Suricata.

The Importance of Snapshots

Snapshots are perhaps the single greatest advantage of virtualization.

A snapshot records:

• Virtual disks

• Memory state (optional)

• Virtual hardware configuration

• Machine state

Before making major changes, create a snapshot.

Examples include:

• Installing Wazuh

• Updating Ubuntu

• Modifying Sysmon

• Editing Suricata configuration

• Changing HOME_NET

• Installing Emerging Threats

• Testing malware

If something goes wrong, restore the snapshot. Recovery typically requires only minutes.

Figure 3-6

Snapshot Workflow

Note. The workflow presents the ordered stages of snapshot Workflow and highlights the validation and feedback steps that make the process repeatable.

Snapshots encourage experimentation because mistakes become reversible.

Snapshot Naming Standards

Professional engineers use meaningful snapshot names.

Poor examples:

Snapshot 1

Backup

Today

Test

Better examples:

Fresh Windows Install

Before Sysmon Installation

Before Wazuh Agent

Before Suricata Install

After ET Rules Configured

Lab 3 Completed

Consistent naming saves time during recovery.

Common Student Mistake

Students often create one snapshot at the beginning of the semester and never create another.

Professional engineers create snapshots:

• Before upgrades

• Before software installations

• Before configuration changes

• Before malware testing

• Before laboratory exercises involving significant risk

Snapshots are part of normal operational workflow—not emergency recovery.

Best Practice

Maintain at least three important snapshots for every virtual machine:

This strategy allows recovery to multiple stages of the laboratory lifecycle.

Think Like a SOC Engineer

Imagine your Suricata configuration becomes corrupted immediately before a classroom demonstration. If you created a snapshot five minutes earlier, recovery requires less than a minute. Without a snapshot, you may spend hours rebuilding the system. Professional engineers plan for failure before failure occurs.

Looking Ahead

With virtualization understood, the next section explores one of the most important—and most misunderstood—topics in cybersecurity laboratories:

Virtual networking. Students will learn how VMware virtual switches work, the differences between Bridged, NAT, and Host-Only networking, why promiscuous mode matters for network intrusion detection, and how to design a network that allows Suricata to observe the traffic it must inspect. This networking foundation will directly support the installation and validation of Suricata, Wazuh, and the complete telemetry pipeline later in the chapter.

Learning Objectives

After completing this section, you should be able to:

• Explain how virtual networking operates within VMware Workstation.

• Differentiate between Bridged, NAT, and Host-Only networking.

• Understand how virtual switches forward traffic.

• Explain why network architecture directly affects IDS visibility.

• Design a VMware network suitable for a Security Operations Center laboratory.

Introduction

Computers cannot investigate network traffic unless they can see network traffic. That statement sounds obvious. However, it is one of the most misunderstood concepts in beginner cybersecurity laboratories. Students often install Suricata correctly. The Emerging Threats rules load successfully. The Wazuh Agent runs normally. Everything appears operational. Yet no alerts are generated. The problem usually isn’t Suricata. The problem is that Suricata never receives the packets. Before configuring any Network Intrusion Detection System (NIDS), we must understand how packets move through VMware virtual networks.

Virtual Networks

Inside VMware Workstation, virtual machines communicate through virtual switches. A virtual switch behaves much like a physical Ethernet switch.

It:

• Connects devices.

• Learns MAC addresses.

• Forwards Ethernet frames.

• Separates broadcast domains.

• Maintains Layer 2 connectivity.

The difference is that everything occurs in software.

Figure 3-7

VMware Virtual Switch

Note. The figure summarizes vMware Virtual Switch and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Understanding VMnet Networks

VMware creates several virtual networks.

The most common are:

Additional VMnets may be created for specialized laboratory environments. Each virtual machine connects one or more virtual network adapters to one of these virtual networks.

Bridged Networking

In Bridged Mode, the virtual machine appears as an independent device on the physical network.

The VM receives:

• Its own MAC address.

• Its own IP address.

• Direct Layer 2 connectivity.

• Visibility from other devices.

Example:

Physical Switch

Figure 3-8

VMware Networking Modes

Note. The figure summarizes vMware Networking Modes and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

──────────────

Host PC

──────────────

VMware Bridge

──────────────

Windows VM

Ubuntu VM

Wazuh VM

Each VM behaves like a separate physical computer.

Advantages

Bridged networking provides:

• Full network visibility.

• Easy communication.

• Realistic enterprise behavior.

• Support for IDS monitoring.

For this reason, Bridged networking is frequently used for cybersecurity laboratories.

NAT Networking

Network Address Translation (NAT) behaves differently. Instead of exposing every VM directly to the physical network, VMware acts as a router.

Internet

Host Computer

VMware NAT

──────────────

Virtual Machines

Advantages:

• Internet access.

• Easy configuration.

• Additional isolation.

Disadvantages:

• Less realistic enterprise topology.

• Some packet visibility limitations.

Host-Only Networking

Host-Only networks are completely isolated.

Host Computer

VMnet1

──────────────

Windows VM

Ubuntu VM

Wazuh VM

No Internet access exists unless additional routing is configured.

Host-Only mode is useful for:

• Malware analysis

• Isolated attack labs

• Offline experimentation

Comparing Network Modes

No mode is universally “best.” The correct choice depends on laboratory objectives.

Analyst Corner

Students often ask:

“Which VMware network mode should I use?”

The answer is:

Use the network mode that supports your learning objective. Throughout this textbook, we intentionally use multiple network modes because professional environments rarely rely on only one. Understanding the strengths and limitations of each mode is far more valuable than memorizing a single configuration.

Multiple Network Adapters

One of the strengths of virtualization is that a single virtual machine may contain multiple network adapters. Our Ubuntu sensor uses this capability extensively.

Example:

These adapters perform entirely different jobs. Management traffic should never interfere with packet capture.

Figure 3-9

Dual-Homed Ubuntu Sensor

Note. The figure summarizes dual-Homed Ubuntu Sensor and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

This design closely resembles enterprise network sensors.

Why Suricata Needs Visibility

Remember one fundamental principle. Suricata cannot inspect packets it never receives. Imagine placing a security camera inside a room.

Can it monitor activity occurring outside the building?

Of course not. Network Intrusion Detection Systems behave similarly. Visibility determines detection capability.

Packet Flow

Consider a simple web request.

Figure 3-10

From Windows Browser to Dashboard

Note. The sequence traces how Windows Browser progresses to Dashboard, emphasizing the intermediate evidence and processing steps.

Every laboratory exercise later in this textbook follows this exact path. Understanding it now greatly simplifies troubleshooting later.

Promiscuous Mode

By default, network interfaces accept only packets addressed to themselves. Promiscuous mode changes this behavior.

When enabled, the interface accepts:

• Unicast traffic

• Broadcast traffic

• Multicast traffic

• Packets not specifically addressed to the interface (subject to the virtual networking architecture)

For Suricata, this greatly expands packet visibility.

Important Clarification

Many beginning analysts believe that enabling promiscuous mode alone allows an interface to see all network traffic. This is not correct. Promiscuous mode only allows the interface to accept packets that actually reach it. If the virtual switch never forwards the traffic to the monitoring interface, Suricata cannot inspect it regardless of the interface mode. Visibility is determined by both the network architecture and the interface configuration.

Figure 3-11

Packet Visibility

Note. The figure summarizes packet Visibility and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Why We Use Two Interfaces

Earlier in the textbook you configured Ubuntu with two network adapters. This design is intentional.

Separating management traffic from monitoring traffic provides several advantages:

• Easier troubleshooting

• Improved security

• Better performance

• More realistic enterprise architecture

• Simplified packet capture

This mirrors how many production network sensors are deployed.

Common Student Mistake

Students often configure Suricata to monitor the wrong interface.

Symptoms include:

• No alerts in eve.json

• Empty packet counters

• Wazuh receives no Suricata alerts

• tcpdump shows no traffic

Before modifying rules or reinstalling software, always verify:

• The correct interface is selected.

• The interface is up.

• The interface is receiving traffic.

• The expected packets actually traverse that network.

Many hours of troubleshooting can be avoided by validating these fundamentals first.

SOC Tip

Whenever Suricata appears “broken,” work backward through the packet path:

• Was the traffic generated?

• Did it traverse the correct VMware network?

• Did the virtual switch forward it?

• Did ens192 receive it?

• Did tcpdump observe it?

• Did Suricata inspect it?

• Was an alert written to eve.json?

• Did the Wazuh Agent forward the alert?

• Did the Wazuh Manager process it?

• Did the Dashboard display it?

This troubleshooting methodology reflects the same disciplined telemetry validation process introduced in Chapters 1 and 2.

Best Practice

Before installing Suricata, verify your virtual networking. A correctly configured IDS with poor network visibility is ineffective. Conversely, a modest IDS with excellent visibility often provides outstanding detection capability (Scarfone & Mell, 2007). Visibility always precedes detection.

Looking Ahead

With the virtual network architecture complete, the next section begins preparing the Wazuh Server itself. Students will learn how to validate the server, verify required services, understand the Wazuh directory structure, identify critical configuration files, and establish the baseline operational checks that will be performed before every future laboratory exercise. From this point forward, the textbook transitions fully into hands-on system construction using the exact SOC environment developed throughout this project.

Learning Objectives

After completing this section, you should be able to:

• Describe the role of the Wazuh Server within the SOC.

• Identify the major Wazuh services.

• Locate critical Wazuh directories.

• Understand where configuration files are stored.

• Perform baseline operational health checks.

• Recognize common service failures before beginning an investigation.

Introduction

Every Security Operations Center has a central nervous system. In our laboratory, that system is the Wazuh Server. This section assumes the Wazuh Server has already been built and is reachable on the network. If you have not yet installed the Wazuh central components (Manager, Indexer, and Dashboard), complete Appendix A — Building the Complete Enterprise Cybersecurity Lab before continuing. Appendix A walks through the official Wazuh installation assistant end to end; this chapter picks up from that point to validate, operate, and integrate the server into the SOC (Wazuh, Inc., n.d.-b). Although students often focus on the Dashboard because it is visually appealing, the Dashboard is only one small part of the overall platform.

The Wazuh Server performs the critical operational work:

• Receiving telemetry

• Decoding logs

• Applying detection rules

• Managing agents

• Coordinating active response

• Storing indexed data

• Presenting information through the Dashboard

If the server is unhealthy, every downstream component suffers. For this reason, experienced analysts begin each day by validating the health of the Wazuh Server before reviewing alerts.

The Wazuh Server Is More Than One Service

Many beginning students think of Wazuh as a single application. In reality, several services work together to provide a complete SIEM platform.

In our laboratory, the primary services are:

Each service has a unique responsibility. If one service fails, the symptoms observed by the analyst will differ. Understanding these responsibilities greatly simplifies troubleshooting.

Figure 3-12

Wazuh Service Architecture

Note. The diagram identifies the primary components of wazuh Service Architecture and shows how they connect, exchange data, and support security operations.

This architecture should now be familiar. The difference is that students will soon begin interacting directly with each component.

Logging Into the Server

Most administrative work occurs from the Linux command line. Throughout this textbook, commands are shown exactly as they should be entered. Students should become comfortable using SSH or the VMware console to access the server.

A typical session begins with:

ssh student@WAZUH-SRV or, if working locally through VMware:

login:

Once authenticated, verify your identity:

whoami hostname pwd

These simple commands confirm:

• Current user

• Current system

• Current working directory

Professional administrators perform these checks almost automatically.

Verifying the Wazuh Services

Before investigating alerts, confirm that the major services are running.

For modern Wazuh installations using systemd:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo systemctl status wazuh-manager
sudo systemctl status wazuh-indexer
sudo systemctl status wazuh-dashboard

Alternatively, check all three at once:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard

A healthy service should report:

• Loaded: loaded

• Active: active (running)

Anything else deserves investigation before proceeding.

SOC Tip

Do not memorize the color of the output. Read the text. Terminal color schemes vary between Linux distributions, SSH clients, and terminal emulators. The words active (running) matter—not whether they appear in green, blue, or white.

Essential Operational Commands

These are commands every SOC analyst should know.

These commands form the foundation of operational health verification.

The Wazuh Directory Structure

One of the first skills every administrator should develop is understanding where things live. Although Linux provides thousands of directories, only a few are used routinely during Wazuh administration.

The primary installation directory is:

/var/ossec

Think of this directory as Wazuh’s home. Nearly everything you will configure during this textbook resides somewhere beneath it.

Figure 3-13

Simplified Directory Tree

Note. The figure organizes the major elements of simplified Directory Tree to clarify their roles, relationships, and escalation or inheritance paths.

As the semester progresses, every one of these directories will become familiar.

Critical Directories

Only a few directories beneath /var/ossec are used routinely. Each is described below.

/var/ossec/etc

Contains the primary configuration files.

Most importantly:

/var/ossec/etc/ossec.conf

This is the heart of the Wazuh configuration. Later chapters will modify this file many times.

/var/ossec/logs

Contains operational logs.

Examples include:

• Manager logs

• Alert logs

• Archive logs

One of the most important files is:

/var/ossec/logs/ossec.log

When troubleshooting, this is often the first place administrators look.

/var/ossec/ruleset

Contains the default:

• Decoders

• Rules

Students should avoid modifying vendor-supplied rules directly. Instead, later chapters will demonstrate how to create local custom rules that survive upgrades.

/var/ossec/queue

Contains information exchanged between agents and the Manager. Although students rarely interact directly with this directory, understanding its purpose helps explain how agent communication occurs.

/var/ossec/bin

Contains many administrative utilities.

Examples include:

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

/var/ossec/bin/manage_agents
/var/ossec/bin/agent_control
/var/ossec/bin/wazuh-control

Several of these utilities will be used throughout the remainder of the course. The manage_agents and agent_control utilities manage agent enrollment and status; their full syntax is documented in Appendix B — Command Reference.

Operational Health Checklist

Before beginning any investigation, verify the following:

This checklist takes less than two minutes to complete but prevents countless hours of troubleshooting later.

Analyst Corner

Throughout this course, I will occasionally ask a simple question:

“How do you know Wazuh is working?”

The correct answer is never:

“The Dashboard opened.”

The correct answer is evidence-based:

• Services are active.

• Agents are connected.

• Telemetry is arriving.

• Rules are firing.

• Alerts are being indexed.

• Searches return current events.

A healthy Dashboard alone is insufficient proof of a healthy SIEM.

Common Student Mistake

Students often restart services immediately after seeing an error. Experienced administrators investigate first.

Before restarting anything, ask:

• What changed?

• When did the problem begin?

• Which service failed?

• What do the logs report?

• Is the failure reproducible?

Restarting services without understanding the underlying problem may temporarily hide important evidence.

Best Practice

Develop the habit of checking the Wazuh Server before opening the Dashboard. A professional SOC analyst trusts verified telemetry—not assumptions based on a web interface. Operational discipline begins at the server.

Think Like a SOC Engineer

Imagine arriving Monday morning. The Dashboard loads normally. However, students report no new alerts since Friday afternoon.

Instead of restarting everything, your investigation begins methodically:

• Verify Manager status.

• Verify Indexer status.

• Verify Dashboard status.

• Check ossec.log.

• Confirm agents are connected.

• Generate a known test event.

• Trace the telemetry through the pipeline.

This systematic approach reflects the engineering mindset developed throughout the first three chapters.

Looking Ahead

With the Wazuh Server understood, the next section introduces the Wazuh Dashboard from an administrator’s perspective. Rather than focusing on investigations, students will learn how to verify platform health, interpret Dashboard metrics, identify disconnected agents, monitor service status, and establish the operational awareness required before conducting threat investigations. This completes the foundational operational knowledge before students begin installing and validating Ubuntu, Suricata, Windows 11, and Sysmon.

Learning Objectives

After completing this section, you should be able to:

• Log into the Wazuh Dashboard.

• Describe the major Dashboard components.

• Verify overall platform health.

• Confirm agent connectivity.

• Identify common operational problems.

• Establish daily operational awareness before investigating alerts.

Introduction

For most analysts, the Wazuh Dashboard is the first application opened each morning. Although many people think of the Dashboard simply as a place to view alerts, experienced analysts know it serves a much broader purpose. The Dashboard is the operational console of the Security Operations Center.

It answers questions such as:

• Are my agents connected?

• Is telemetry arriving?

• Have alert volumes changed?

• Which systems require attention?

• Are any sensors offline?

• Are security events being processed?

Only after answering these questions does the analyst begin reviewing alerts.

Logging into the Dashboard

After opening your web browser, navigate to the Wazuh Dashboard.

Example:

https://192.168.1.30 or https://WAZUH-SRV

(Use the hostname or IP address assigned to your Wazuh server.)

After authentication, the Dashboard opens to the main landing page. Do not immediately begin clicking alerts. Instead, spend a few moments understanding the operational picture.

The Dashboard Is an Instrument Panel

Imagine entering the cockpit of an aircraft. A pilot does not immediately take off.

Instead, the pilot verifies:

• Fuel

• Engine instruments

• Flight controls

• Navigation systems

• Weather

• Communications

SOC analysts perform a similar pre-flight check.

Before beginning investigations they verify:

• Services

• Agents

• Telemetry

• Alerts

• Infrastructure health

This mindset dramatically reduces troubleshooting later in the day.

Figure 3-14

The Dashboard as the SOC Instrument Panel

Note. The figure summarizes the Dashboard as the SOC Instrument Panel and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Everything on the Dashboard contributes to operational awareness.

First Look: What Should You Check?

Every analyst develops a routine. Throughout this textbook, we will use the following sequence.

Step 1 — Verify Connected Agents

Navigate to:

Wazuh

Verify:

• Every expected endpoint is connected.

• Status is Active.

• Recent keepalive timestamps are current.

Expected laboratory agents include:

Disconnected agents should always be investigated before continuing.

Step 2 — Verify Recent Activity

Navigate to:

Security Events

Set the time range to:

Last 24 Hours

Confirm that events continue arriving.

Questions to ask:

• Are new events appearing?

• Did events suddenly stop?

• Does activity appear normal?

A complete absence of new events is usually more concerning than a high volume of alerts.

Step 3 — Review Alert Severity

Most dashboards display alerts grouped by severity.

Example:

These generic categories map onto Wazuh’s numeric 0–15 rule levels, described in Section 2.5. Students often investigate every alert.

Professional analysts prioritize based on:

• Severity

• Business impact

• Critical assets

• Current incidents

Step 4 — Review Agent Health

Questions to ask include:

• Which agent disconnected most recently?

• Has an agent stopped reporting?

• Are multiple agents affected?

• Is one operating system reporting fewer events?

Operational changes frequently reveal infrastructure problems before users notice them.

Analyst Corner

One of the best habits you can develop is asking:

“What changed?”

Not:

“What alerts exist?”

Examples:

Yesterday:

• Three agents

Today:

• Two agents

That change deserves investigation.

Yesterday:

• Hundreds of Suricata alerts

Today:

• Zero

That change deserves investigation. Good analysts notice changes. Great analysts investigate them.

Dashboard Navigation

Although the Dashboard contains many features, students should become comfortable with several core areas first.

Master these areas before exploring more advanced features.

Searching the Dashboard

Searching is the single most important Dashboard skill.

Typical searches include:

Hostname

WIN11

Agent Name

u2604

Rule ID

5710

Event ID

22

Process Name

powershell.exe

IP Address

192.168.1.40

Nearly every investigation begins with one of these searches.

Time Selection

Students often overlook the time selector. This is one of the most important controls in the Dashboard.

Typical selections include:

When alerts appear missing, the first thing to verify is often the selected time range.

SOC Tip

When troubleshooting:

Always verify the time selector before assuming telemetry is missing. Many “missing alerts” are simply outside the selected time window.

Common Student Mistake

Students frequently focus only on the left side of the Dashboard.

Professional analysts continuously monitor:

• Agent count

• Event rate

• Alert trends

• Time window

• Search filters

• Active queries

Understanding the entire workspace leads to faster investigations.

Daily Operational Checklist

Before beginning any investigation:

✓ Dashboard loads successfully

✓ All expected agents connected

✓ Recent telemetry visible

✓ Suricata alerts present

✓ Sysmon events present

✓ Windows Defender operational

✓ Event timestamps current

✓ Time selector correct

✓ No unexpected service interruptions

This checklist should become routine.

Figure 3-15

Daily SOC Startup Workflow

Note. The workflow presents the ordered stages of daily SOC Startup Workflow and highlights the validation and feedback steps that make the process repeatable.

Notice that investigations occur only after operational validation.

Think Like a SOC Analyst

Imagine opening the Dashboard Monday morning.

Everything appears normal except:

• Windows agent connected ✓

• Ubuntu agent connected ✓

• Dashboard operational ✓

• No Suricata alerts for 18 hours ✗

Would you immediately conclude:

“The network is secure.”

Or would you ask:

• Is Suricata running?

• Is eve.json updating?

• Is the Wazuh Agent monitoring the file?

• Did the Emerging Threats rules load?

• Is the monitoring interface receiving packets?

Experienced analysts investigate the monitoring system before assuming an absence of threats.

Best Practice

The Dashboard should answer three operational questions within the first five minutes of your shift:

• Is my SOC healthy?

• Is telemetry flowing?

• What requires my attention first?

If you cannot answer those questions quickly, either the Dashboard or the workflow needs improvement.

Looking Ahead

The next section begins the first major implementation phase of the textbook: deploying and validating the Ubuntu 26.04 network sensor. Students will configure the operating system, verify networking, install the Wazuh Agent, prepare the dual-interface architecture, and establish the Linux foundation required for Suricata and Emerging Threats Open. From this point forward, each system will be built incrementally, validated thoroughly, and integrated into the complete Security Operations Center.

Learning Objectives

After completing this section, you should be able to:

• Explain the role of the Ubuntu sensor within the SOC.

• Validate the operating system before installing security software.

• Verify hardware resources and network connectivity.

• Confirm Linux services required for later chapters.

• Document the baseline state of the Ubuntu system.

Introduction

The Ubuntu system occupies a unique position within our Security Operations Center. Unlike the Windows workstation, which primarily generates endpoint telemetry, the Ubuntu system performs two independent roles. First, it operates as a monitored Linux endpoint by running the Wazuh Agent. Second, it serves as a dedicated network intrusion detection sensor running Suricata and the Emerging Threats Open rule set. Because this system becomes responsible for inspecting network traffic, it must be validated carefully before any security software is installed. Professional SOC engineers always establish a known-good operating system baseline before adding monitoring tools.

The Ubuntu Sensor Architecture

Throughout the remainder of this textbook, the Ubuntu virtual machine will serve multiple purposes.

Unlike many enterprise environments where these functions are distributed across multiple servers, our laboratory intentionally combines them into one system to simplify learning.

Figure 3-16

Ubuntu Sensor Responsibilities

Note. The figure summarizes ubuntu Sensor Responsibilities and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

This dual-role architecture is one of the defining characteristics of our laboratory.

Before Installing Anything

Students are often eager to install software immediately. Resist that temptation. First, validate the operating system.

Professional engineers verify:

• Operating system version

• Kernel version

• Network interfaces

• Hostname

• IP addresses

• Internet connectivity

• Available disk space

• Available memory

• Time synchronization

• Package repositories

Only after these checks succeed should software installation begin.

Verify the Operating System

Confirm the Ubuntu release.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

cat /etc/os-release

Expected output should identify Ubuntu 26.04 LTS.

Analyst Corner

At the time this textbook was written, Wazuh’s officially validated Ubuntu compatibility list topped out at 24.04 LTS. Ubuntu 26.04 is new enough that it may not yet appear on Wazuh’s published compatibility matrix, even though the Wazuh Agent .deb package installs and runs correctly on it in practice because Ubuntu LTS releases are ABI-compatible with the packages Wazuh builds for Debian-based systems.

Before installing, check the current supported operating systems list at the Wazuh installation guide. If your release is not yet listed, that is not necessarily a blocker — it simply means you are ahead of the official validation cycle and should test carefully rather than assume compatibility. This is a useful lesson in itself: production environments are frequently a version or two ahead of a vendor’s formal support matrix, and analysts need to know how to verify compatibility themselves rather than relying solely on a checklist. Next, verify the kernel.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

uname -r

Record both values in your SOC Engineering Notebook. Version information becomes invaluable during troubleshooting and future upgrades.

Verify Host Identity

Every server should know its own identity. Display the hostname.

hostname

Display the fully qualified hostname if configured.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

hostnamectl

Confirm that the hostname matches your documentation.

Example:

UB2604

Consistency between documentation and configuration prevents confusion later when multiple Linux systems are added.

Verify Network Interfaces

List all network interfaces.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ip addr

or, for a compact one-line-per-interface view:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ip -br addr

Expected output should identify both interfaces.

Example:

Confirm:

• Interface names

• IPv4 addresses

• Interface state

• MAC addresses

Document each value.

Verify Routing

Display the routing table.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ip route

Questions to answer:

• Which interface provides Internet access?

• Which network is the default route?

• Is the gateway reachable?

A correct routing table prevents many future troubleshooting problems.

Verify Connectivity

Before installing packages, verify connectivity. Ping the default gateway.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ping -c 4 192.168.1.1

Ping the Wazuh Server.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ping -c 4 192.168.1.30

Ping a public IP address.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ping -c 4 8.8.8.8

Finally, verify DNS.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ping -c 4 google.com

Each test validates a different part of the network stack.

Analyst Corner

Notice the progression:

• Local gateway

• Local server

• Public IP

• DNS hostname

This sequence helps isolate problems.

For example:

• If the gateway fails, investigate local networking.

• If public IP fails but the gateway succeeds, investigate routing.

• If public IP works but DNS fails, investigate name resolution.

Professional troubleshooting isolates one layer at a time.

Verify System Resources

Display memory usage.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

free -h

Display processor information.

lscpu

Display filesystem usage.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

df -h

Record:

• Available memory

• Number of CPUs

• Available disk space

Later chapters compare these values after installing additional software.

Verify Time Synchronization

Time accuracy is essential in a SOC. Display current status.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

timedatectl

Verify:

• Correct timezone

• NTP synchronized

• System clock synchronized

Even small time differences complicate event correlation across systems.

Update the Operating System

Before installing Wazuh or Suricata, ensure the operating system is current.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo apt update
sudo apt upgrade

After upgrades requiring a reboot:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo reboot

Then repeat the validation checks. Never assume updates completed successfully.

Create the Baseline Snapshot

At this point, the system should contain:

• Ubuntu installed

• Updates applied

• Networking verified

• Documentation completed

Create a VMware snapshot.

Suggested name:

Ubuntu 26.04 Clean Baseline

This snapshot becomes your recovery point before installing security software.

Common Student Mistake

Students often install multiple applications before taking a snapshot. If a later installation fails, they must rebuild the entire operating system.

Instead:

• Install Ubuntu.

• Validate Ubuntu.

• Snapshot Ubuntu.

• Install Wazuh Agent.

• Snapshot again.

• Install Suricata.

• Snapshot again.

This incremental approach dramatically reduces recovery time.

SOC Tip

Treat every major installation as a milestone. Create snapshots that correspond to those milestones. Later chapters will reference these snapshots when experimenting with custom rules, Active Response, and advanced Suricata configurations.

Ubuntu Baseline Validation Checklist

Complete the following before continuing.

Do not proceed until every item is complete.

Think Like a SOC Engineer

Imagine installing Suricata before verifying the operating system. Later, Suricata fails to download rule updates.

Is the problem:

• Suricata?

• DNS?

• Routing?

• Internet connectivity?

• Package repositories?

Because the baseline was never validated, every possibility remains open. Professional engineers eliminate uncertainty before introducing complexity.

Looking Ahead

The next section begins the installation of the Wazuh Agent on Ubuntu. Students will learn how the agent communicates with the Wazuh Manager, how to register and validate the agent, interpret agent status, troubleshoot connectivity issues, and verify that Linux telemetry successfully reaches the Wazuh Dashboard. This establishes the first operational telemetry pipeline in the laboratory before Suricata is introduced (Open Information Security Foundation, n.d.).

Learning Objectives

After completing this section, you should be able to:

• Explain the purpose of the Wazuh Agent.

• Install the Wazuh Agent on Ubuntu 26.04.

• Register the agent with the Wazuh Manager.

• Verify secure communication between the agent and the Manager.

• Confirm Linux telemetry is visible within the Wazuh Dashboard.

• Troubleshoot common agent connectivity problems.

Introduction

The Wazuh Agent is the primary mechanism through which Linux systems communicate with the Wazuh Manager (Wazuh, Inc., n.d.-a). Think of the Agent as the Ubuntu system’s ambassador to the Security Operations Center.

Its responsibilities include:

• Collecting Linux telemetry

• Monitoring log files

• Reporting security events

• Performing file integrity monitoring

• Executing active response actions (when configured)

• Maintaining secure communication with the Manager

Without the Wazuh Agent, Ubuntu becomes invisible to the SOC.

How the Agent Fits into the SOC

Before installing anything, understand the communication flow.

Figure 3-17

Ubuntu Agent Communication

Note. The figure summarizes ubuntu Agent Communication and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Every Linux event follows this path.

Installation Philosophy

Throughout this textbook we follow a disciplined workflow. Each installation consists of five stages.

Figure 3-18

From Install to Document

Note. The sequence traces how Install progresses to Document, emphasizing the intermediate evidence and processing steps.

Notice that installation represents only one step. Validation is equally important.

Installing the Agent

Install the Wazuh Agent using the official repository.

(The exact commands are provided in Lab Exercise 3.1 and should always follow the current Wazuh documentation for your installed version.)

After installation completes, verify the package.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

dpkg -l | grep wazuh

Expected output should identify:

wazuh-agent

Record the installed version in your SOC Engineering Notebook.

Verify the Service

Confirm the service exists.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl status wazuh-agent

Expected:

Active: active (running)

If the service is inactive, do not continue. Investigate the problem first.

Enable Automatic Startup

The agent should start automatically after every reboot.

Verify:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl is-enabled wazuh-agent

Expected output:

::: {custom-style="CodeLabel"} UB2604 · Expected output :::

enabled

If necessary:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl enable wazuh-agent

Verify Network Connectivity

Before assuming the agent has failed, verify communication with the Wazuh Manager.

Example:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ping WAZUH-SRV

Next, verify that the Manager port is reachable.

nc -vz 192.168.1.30 1514

Expected:

Connection succeeded

This confirms basic network communication.

Analyst Corner

Many students immediately reinstall the Wazuh Agent when it fails to connect. Experienced administrators verify the network first.

Ask yourself:

• Can I reach the Manager?

• Is the Manager running?

• Is TCP 1514 open?

• Is DNS working?

• Is the correct Manager IP configured?

Software is often blamed for networking problems. In reality, networking problems are usually the cause.

Verify Agent Registration

Log into the Wazuh Dashboard.

Navigate to:

Wazuh → Agents

The Ubuntu system should appear.

Example:

Agent Names vs. Hostnames. The hostname (UB2604) identifies the machine; the agent name (u2604) is the identity assigned to the Wazuh Agent at enrollment. In this laboratory, agent names are lowercase by convention (u2604, win11). Because Dashboard queries are case-sensitive, agent.name:“u2604” returns events while agent.name:“U2604” returns nothing. Record both values in your SOC Engineering Notebook. If the agent does not appear, do not continue. Investigate before installing Suricata.

Validate Telemetry

Simply appearing in the Dashboard is not sufficient. Generate Linux activity.

Example:

logger “Ubuntu agent validation test”

This creates a message in the Linux system log. Within a few moments, search the Dashboard.

Example search:

u2604

Locate the generated event.

This confirms:

• Linux generated telemetry.

• Agent collected telemetry.

• Manager received telemetry.

• Indexer stored telemetry.

• Dashboard displayed telemetry.

Congratulations. Your first telemetry pipeline is operational.

Figure 3-19

Telemetry Validation

Note. The figure summarizes telemetry Validation and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

This validation methodology will be repeated throughout the textbook.

Verify Log Collection

Linux system logs are stored in several locations depending on the distribution.

Common examples include:

/var/log/syslog /var/log/auth.log /var/log/kern.log /var/log/dpkg.log

Students should become familiar with these files because later chapters will monitor them using the Wazuh Agent.

Common Agent Commands

These commands will become part of your routine operational toolkit.

Reading the Agent Log

The agent maintains its own operational log.

Example:

/var/ossec/logs/ossec.log

When troubleshooting, look for:

• Connection failures

• Authentication problems

• Registration errors

• Communication timeouts

• Configuration issues

Develop the habit of reading logs before changing configurations.

Common Student Mistake

Students often stop troubleshooting once the agent appears in the Dashboard. However, an agent may be connected without forwarding meaningful telemetry.

Always verify:

• Events are arriving.

• Current timestamps are visible.

• Searches return expected results.

• Generated test events appear.

Connectivity alone does not prove functionality.

SOC Tip

Every time you install a new agent, generate a known test event immediately. Never wait until weeks later to discover the telemetry pipeline was incomplete. Testing immediately after installation saves enormous amounts of troubleshooting time.

Baseline Validation Checklist

Before proceeding, confirm:

Do not continue until every validation succeeds.

Think Like a SOC Analyst

Imagine arriving Monday morning. The Ubuntu Agent appears Active. However, new Linux events stopped arriving six hours ago.

Would you conclude:

“The Agent is healthy.”

Or would you investigate:

• Agent logs

• Network connectivity

• Queue status

• Service restarts

• Disk space

• System time

• Log collection configuration

Professional analysts recognize that an active agent is only the beginning. Healthy telemetry—not merely connectivity—is the true indicator of a functioning monitoring system.

Looking Ahead

With Ubuntu successfully reporting telemetry to the Wazuh Manager, the next section introduces Suricata, the network intrusion detection system that transforms the Ubuntu host from a monitored endpoint into a dedicated network sensor. Students will install Suricata, understand its packet-processing architecture, configure the monitoring interface, integrate the Emerging Threats Open rule set, and validate the first network-based detections flowing into the Wazuh Dashboard. This marks the transition from endpoint monitoring to full network security monitoring within the SOC laboratory.

Learning Objectives

After completing this section, you should be able to:

• Explain the purpose of a Network Intrusion Detection System (NIDS).

• Describe how Suricata processes network traffic.

• Understand the Suricata packet-processing pipeline.

• Differentiate between packet capture, protocol decoding, and rule evaluation.

• Identify the major Suricata components.

• Explain how Suricata integrates with Wazuh.

Introduction

Until now, every security event in our laboratory has originated from an endpoint.

For example:

• Windows generated Sysmon events.

• Ubuntu generated Linux logs.

• Windows Defender generated malware alerts.

These events describe what occurred on individual computers.

But what about the network itself?

Attackers do not interact directly with operating systems. They communicate across networks.

Every:

• DNS query

• HTTP request

• TLS session

• SSH connection

• Port scan

• File download

must traverse the network before reaching its destination. If we can observe that traffic, we gain another powerful source of evidence. This is precisely the role of Suricata.

What Is Suricata?

Suricata is an open-source Network Intrusion Detection System (NIDS) and Network Intrusion Prevention System (NIPS) developed by the Open Information Security Foundation (OISF) (Open Information Security Foundation, n.d.). Unlike endpoint software that observes activity occurring on a single computer, Suricata examines packets moving across the network. Think of Sysmon as observing inside the computer. Think of Suricata as observing between computers. Together they provide complementary visibility.

Figure 3-20

Endpoint vs. Network Visibility

Note. The comparison highlights the operational differences represented by endpoint vs. Network Visibility and shows why the distinction matters during analysis.

No single tool provides complete visibility. SOC analysts combine endpoint and network telemetry to develop a comprehensive understanding of events.

Why Monitor the Network?

Imagine malware successfully deletes itself after execution. Endpoint evidence may disappear. However, the network communication that occurred during the attack may still exist.

Suricata can observe:

• Command-and-control traffic

• Malware downloads

• Data exfiltration

• DNS tunneling

• Port scanning

• Protocol abuse

• Exploit attempts

• Web attacks

The network often preserves evidence that endpoints cannot.

The Packet Journey

Every packet follows a predictable path through Suricata. Understanding this pipeline is essential.

Figure 3-21

Suricata Processing Pipeline

Note. The pipeline shows how information moves through suricata Processing Pipeline, from its source through processing to the analyst-visible result.

Nearly every troubleshooting exercise later in this textbook follows this exact pipeline.

Step 1 — Packet Capture

Suricata begins by capturing packets from a network interface.

Examples include:

ens160 ens192

In our laboratory, Suricata monitors:

ens192

This interface has been dedicated to network monitoring. If packets never reach this interface, Suricata cannot detect anything.

Step 2 — Flow Tracking

Individual packets rarely tell the complete story. Suricata groups related packets into flows.

Example:

Figure 3-22

From Client to HTTP Response

Note. The sequence traces how Client progresses to HTTP Response, emphasizing the intermediate evidence and processing steps.

Instead of evaluating isolated packets, Suricata evaluates complete conversations.

Step 3 — Protocol Identification

Once packets are grouped into flows, Suricata determines the protocol.

Examples include:

• HTTP

• HTTPS

• DNS

• SSH

• FTP

• SMTP

• SMB

• TLS

• ICMP

Suricata identifies protocols using protocol detection rather than relying exclusively on port numbers. This improves detection accuracy.

Step 4 — Protocol Parsing

After identifying the protocol, Suricata extracts useful information.

For example:

HTTP

• URI

• User-Agent

• Method

• Host Header

DNS

• Query Name

• Record Type

• Response Code

TLS

• Server Name

• JA3 Fingerprint

• Certificate Information

This metadata becomes extremely valuable during investigations.

Step 5 — Rule Evaluation

Finally, Suricata compares packet contents against thousands of detection signatures.

Examples include:

• Malware traffic

• Port scans

• Exploit kits

• Web attacks

• Command-and-control

• Policy violations

• Suspicious downloads

If a rule matches, Suricata generates an alert.

Analyst Corner

One of the biggest misconceptions about Suricata is that it “detects hackers.” It does not. Suricata evaluates packets against rules. The rules determine what constitutes suspicious activity. Improving detection therefore often means improving the rule set rather than changing the software itself.

The Suricata Output

Most important information is written to a single file.

/var/log/suricata/eve.json

Throughout this textbook, this file becomes one of our most important data sources. Unlike traditional log files, eve.json contains structured JSON records.

Each record describes:

• Timestamp

• Source IP

• Destination IP

• Ports

• Protocol

• Signature

• Severity

• Metadata

The Wazuh Agent monitors this file continuously.

Figure 3-23

Suricata to Wazuh

Note. The figure summarizes suricata to Wazuh and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Notice that Suricata never communicates directly with the Dashboard. Wazuh serves as the integration platform (Wazuh, Inc., n.d.-a).

Detection Versus Prevention

Suricata can operate in different modes.

Throughout this textbook we operate Suricata in IDS mode.

Why?

Because students should first learn to observe, validate, and investigate traffic before introducing automated blocking. Understanding what is happening on the network is a prerequisite to deciding what should be blocked.

Common Student Mistake

Students often assume that:

“Suricata is running, therefore it must be inspecting packets.” Not necessarily.

Verify:

• Correct interface selected?

• Interface is up?

• Traffic reaches the interface?

• Packet counters increasing?

• Rules loaded successfully?

• eve.json updating?

A running process is not proof of a functioning sensor.

Best Practice

When troubleshooting Suricata, validate one stage at a time:

• Packet reaches the interface.

• Interface captures the packet.

• Suricata processes the packet.

• Rules evaluate the packet.

• Alert is written to eve.json.

• Wazuh Agent forwards the alert.

• Wazuh Dashboard displays the alert.

Breaking the pipeline into stages isolates problems quickly and prevents unnecessary configuration changes.

Think Like a SOC Analyst

Suppose a student reports:

“Suricata didn’t detect my Nmap scan.”

Before changing rules, ask:

• Did the scan actually generate packets?

• Were the packets visible on ens192?

• Did tcpdump observe them?

• Were the appropriate ET Open rules loaded?

• Was an alert written to eve.json?

• Did Wazuh receive the alert?

The objective is not to guess—it is to trace the packet through the entire detection pipeline.

Looking Ahead

With the Suricata architecture understood, the next section begins the actual deployment. Students will install Suricata on Ubuntu 26.04, verify package integrity, understand the directory structure, examine the default configuration, identify critical files, and prepare the sensor for integration with the Emerging Threats Open rule set. This installation will build directly upon the validation methodology established throughout the previous chapters, ensuring that every configuration step is immediately tested before moving forward.

Learning Objectives

After completing this section, you should be able to:

• Install Suricata on Ubuntu 26.04.

• Verify the installed version.

• Understand the Suricata directory structure.

• Locate critical configuration files.

• Validate that Suricata is operational.

• Troubleshoot common installation problems.

Introduction

Suricata is one of the world’s most widely deployed open-source Network Intrusion Detection Systems (NIDS). Unlike endpoint monitoring tools such as Sysmon, which observe activity occurring inside a computer, Suricata analyzes packets traveling between computers. Once integrated with Wazuh, Suricata becomes the laboratory’s primary source of network-based security telemetry. The goal of this section is not simply to install software—it is to establish a validated network sensor capable of reliably inspecting traffic.

Installation Workflow

Throughout this textbook, every software installation follows the same engineering process.

Figure 3-24

Software Deployment Lifecycle

Note. The workflow presents the ordered stages of software Deployment Lifecycle and highlights the validation and feedback steps that make the process repeatable.

Never skip the validation stage. A successful installation command does not guarantee a functional sensor.

Installing Suricata

Install Suricata using the official Ubuntu repositories or the approved package source for the version used in this course. After installation completes, verify the package.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

dpkg -l | grep suricata

Expected output:

suricata

Next, verify the version.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

suricata --build-info

Record the following information in your SOC Engineering Notebook:

• Suricata version

• Build date

• Enabled features

• Capture methods

• Rule engine version

This information becomes important during troubleshooting and future upgrades.

Verify the Service

Check that the service exists.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl status suricata

Expected:

Active: active (running)

If the service is inactive, do not proceed. Investigate before continuing.

Enable Automatic Startup

Confirm Suricata starts after every reboot.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl is-enabled suricata

Expected:

enabled

If necessary:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl enable suricata

Understanding the Directory Structure

Suricata stores configuration, rules, logs, and runtime files in several locations. Students should become familiar with these directories immediately.

Nearly every configuration change performed throughout this textbook will involve one of these locations.

Figure 3-25

Suricata Directory Tree

Note. The figure organizes the major elements of suricata Directory Tree to clarify their roles, relationships, and escalation or inheritance paths.

Students should recognize this structure before editing any configuration files.

The Main Configuration File

The heart of Suricata is:

/etc/suricata/suricata.yaml

This file controls nearly every aspect of the IDS.

Examples include:

• Network interfaces

• HOME_NET

• EXTERNAL_NET

• Logging

• Rule paths

• Packet capture

• Output configuration

• Performance tuning

Two variables in this file deserve special attention. HOME_NET defines the IP ranges Suricata treats as your protected internal network (in this laboratory, 192.168.1.0/24), while EXTERNAL_NET defines everything else. Many detection rules only fire when traffic crosses between these two — for example, a scan is only interesting if it targets HOME_NET. A misconfigured HOME_NET is one of the most common reasons a correctly installed sensor generates no alerts. Throughout the semester this file will be modified repeatedly. Professional administrators always create backups before editing it.

Analyst Corner

Never edit a major configuration file without first making a backup.

Example:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo cp /etc/suricata/suricata.yaml /etc/suricata/suricata.yaml.bak

If a configuration mistake occurs, recovery becomes trivial.

Validating the Configuration

Before starting Suricata, validate the configuration syntax.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo suricata -T -c /etc/suricata/suricata.yaml

Expected output ends with something similar to:

Configuration provided was successfully loaded.

or

Suricata configuration test passed. If errors appear, correct them before continuing. Never ignore configuration test failures.

Starting the Sensor

Restart the service after validation.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl restart suricata

Confirm:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl status suricata

The service should remain active. If it exits immediately, review the logs.

Reviewing the Logs

Primary log location:

/var/log/suricata/

Common files include:

During troubleshooting, suricata.log is usually the first file to examine.

Validate Packet Processing

At this point, the service is running.

But is it actually inspecting packets?

Generate simple network activity.

Example:

ping 8.8.8.8 or curl https://example.com

Monitor packet counters. sudo suricatasc -c uptime or inspect the statistics log (depending on configuration). The goal is to confirm that packets are flowing through the engine.

Validate the Output File

Confirm that the primary event file exists.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

ls -lh /var/log/suricata/eve.json

Watch the file update in real time.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo tail -f /var/log/suricata/eve.json

Generate additional network traffic. If new JSON records appear, Suricata is successfully processing events.

Figure 3-26

Initial Validation

Note. The figure summarizes initial Validation and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

This is the first proof that the sensor is functioning correctly.

Common Student Mistake

Students often verify only that:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

systemctl status suricata returns **active (running)**.

They never confirm:

• Packets are captured.

• Rules loaded.

• eve.json exists.

• Events are written.

A running process without telemetry provides no security value.

Best Practice

After every configuration change, follow this sequence:

• Test the configuration: sudo suricata -T -c /etc/suricata/suricata.yaml

• Restart the service: sudo systemctl restart suricata

• Check service status: sudo systemctl status suricata

• Review suricata.log for errors.

• Generate test traffic.

• Confirm eve.json updates.

Following this sequence prevents many configuration errors.

Baseline Validation Checklist

Before continuing, verify:

Do not proceed until every item has been verified.

Think Like a SOC Engineer

Suppose a student reports:

“Suricata installed successfully.”

Ask:

• How do you know?

• Did the configuration pass validation?

• Did packets reach the monitoring interface?

• Did eve.json update?

• Did you inspect suricata.log?

• Can you prove the sensor processed live traffic?

In professional SOC operations, evidence is the definition of success.

Looking Ahead

With Suricata operational, the next section introduces the Emerging Threats Open (ET Open) rule set. Students will learn how Suricata’s detection engine relies on signatures, how ET Open is organized, how to update and manage rules safely, how to distinguish vendor rules from local custom rules, and how to validate that newly installed signatures generate alerts during controlled laboratory exercises. This completes the network detection foundation before integrating Suricata telemetry into the Wazuh Dashboard.

Learning Objectives

After completing this section, you should be able to:

• Explain the purpose of intrusion detection signatures.

• Describe the Emerging Threats Open (ET Open) project.

• Understand how Suricata uses detection rules.

• Identify the ET Open rule directory.

• Update and validate ET Open signatures.

• Differentiate vendor rules from locally developed rules.

Introduction

Installing Suricata provides a powerful packet inspection engine (Open Information Security Foundation, n.d.). However, an inspection engine without detection rules is much like a spell checker without a dictionary. It can process information. It cannot determine what is important. The intelligence behind Suricata comes from its rule sets. Throughout this textbook we use Emerging Threats Open (ET Open), one of the most widely deployed community-maintained intrusion detection rule sets in the cybersecurity industry. Every time Suricata generates an alert in our laboratory, one of these signatures made the detection possible (Proofpoint, n.d.).

What Is Emerging Threats Open?

Emerging Threats Open (ET Open) is a continuously updated collection of Suricata-compatible detection signatures maintained by the cybersecurity community and supported by Proofpoint (Proofpoint, n.d.).

The project provides thousands of rules designed to identify:

• Malware communication

• Command-and-control traffic

• Port scanning

• Web attacks

• DNS abuse

• Policy violations

• Exploit attempts

• Botnet activity

• Protocol anomalies

• Reconnaissance

Unlike commercial rule subscriptions, ET Open is freely available and ideally suited for education, research, and many production environments.

Figure 3-27

Detection Pipeline

Note. The pipeline shows how information moves through detection Pipeline, from its source through processing to the analyst-visible result.

Notice that ET Open performs the decision-making while Suricata performs the packet inspection.

Anatomy of a Detection Rule

Although Suricata rules may appear intimidating initially, they follow a predictable structure.

Consider the simplified example below:

alert tcp any any -> $HOME_NET 80 (msg:“Example HTTP Alert”; sid:1000001; rev:1;)

Every rule consists of several logical components.

Later chapters will explore rule writing in detail. For now, it is enough to understand that every alert originates from one of these signatures.

Signature IDs (SID)

Every rule contains a unique Signature ID (SID).

Example:

sid:2010935; The SID uniquely identifies the rule responsible for generating an alert.

During investigations, analysts frequently search for:

• SID

• Rule revision

• Alert message

• Metadata

Understanding the SID allows analysts to research why a rule fired and whether tuning is necessary.

Rule Categories

ET Open organizes rules into logical categories.

Examples include:

Grouping signatures makes rule management significantly easier.

Analyst Corner

Students sometimes ask:

“Why are there so many rules?” Because attackers use many different techniques. No single signature detects every attack. Instead, thousands of specialized signatures collectively provide broad coverage across multiple attack stages. Detection is layered—just like defense.

Where Are the Rules Stored?

In a default installation, ET Open rules reside in:

/var/lib/suricata/rules/ or, depending on your deployment:

/etc/suricata/rules/

Always verify your installation rather than assuming the location.

List the rule directory:

ls -lh /var/lib/suricata/rules or ls -lh /etc/suricata/rules

Document the actual location in your SOC Engineering Notebook.

Updating the Rule Set

Threat intelligence changes continuously. New malware families, vulnerabilities, and attack techniques appear every day. For this reason, ET Open must be updated regularly. Suricata provides suricata-update to manage rule downloads.

A typical update process is:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo suricata-update

After updating:

• Review the output for errors.

• Validate the configuration.

•                                           sudo suricata -T -c `/etc/suricata/suricata.yaml`

• Restart the service.

•                                           sudo systemctl restart suricata

• Confirm the service remains active.

Updating signatures without validating the configuration risks disabling the sensor.

Vendor Rules vs. Local Rules

A common mistake is editing vendor-supplied ET Open rules directly. This approach causes problems because updates overwrite vendor files. Instead, keep custom signatures separate.

A typical local rule file is:

/etc/suricata/rules/local.rules

This file is reserved for custom detections developed by your organization. Throughout this textbook, every custom rule you create will be stored here.

Figure 3-28

Rule Management

Note. The figure summarizes rule Management and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Separating vendor and local rules is a fundamental best practice.

Validating Rule Loading

Installing rules is not enough. Confirm they loaded successfully.

Review the Suricata startup log:

sudo journalctl -u suricata or examine:

/var/log/suricata/suricata.log

Look for messages indicating:

• Rules loaded

• Configuration successful

• No syntax errors

• No duplicate SIDs

• No missing files

Successful rule loading is a prerequisite for detection.

Generating a Test Alert

The simplest way to verify ET Open is operational is to generate known network activity.

Examples used later in the book include:

• Nmap port scans

• EICAR antivirus download

• HTTP requests

• DNS lookups

• ICMP traffic

After generating traffic:

• Confirm Suricata processed packets.

• Verify an alert appears in eve.json.

• Confirm the Wazuh Agent forwards the event.

• Verify the alert appears in the Dashboard.

The complete telemetry path should always be validated after major changes.

Common Student Mistake

Students often run:

sudo suricata-update and assume the new rules are active. Not necessarily.

Always verify:

• Rules downloaded successfully.

• Configuration passed validation.

• Suricata restarted successfully.

• New rules loaded.

• Test traffic generated alerts.

A successful update command alone does not prove successful detection.

SOC Tip

Maintain a simple update checklist whenever you modify ET Open:

• Update signatures.

• Validate configuration.

• Restart Suricata.

• Check logs.

• Generate known test traffic.

• Confirm alerts in eve.json.

• Confirm alerts in Wazuh.

Following this workflow ensures confidence in your detection capability.

Baseline Validation Checklist

Before continuing, verify:

Think Like a Detection Engineer

Imagine your organization experiences a newly disclosed vulnerability.

Your first question should not be:

“Does Suricata detect it?”

Instead ask:

• Does ET Open include signatures?

• Are our rules current?

• Do we need temporary custom rules?

• Should we tune existing signatures?

• How will we validate detection?

Professional detection engineers recognize that the quality of an IDS is directly tied to the quality, maintenance, and validation of its signatures.

Looking Ahead

With Suricata and Emerging Threats Open fully operational, the next section integrates the network sensor with Wazuh. Students will configure the Ubuntu Wazuh Agent to monitor eve.json, validate JSON decoding, trace Suricata alerts through the Wazuh Manager, and confirm end-to-end visibility in the Dashboard. This completes the network telemetry pipeline and prepares the laboratory for the first realistic attack simulations and incident investigations.

Learning Objectives

After completing this section, you should be able to:

• Explain how Suricata communicates with Wazuh.

• Configure the Wazuh Agent to monitor eve.json.

• Validate JSON log collection.

• Trace a network alert from packet capture to the Dashboard.

• Troubleshoot the complete telemetry pipeline.

• Verify end-to-end network visibility.

Introduction

By itself, Suricata is an excellent Network Intrusion Detection System. However, it has one limitation. Suricata only knows what it detects.

It has no knowledge of:

• Windows processes

• Sysmon events

• Windows Defender

• Linux authentication

• File Integrity Monitoring

• Wazuh Active Response

Likewise, Wazuh has no knowledge of network activity unless Suricata shares it. This section connects both systems into a single Security Operations Center.

The Complete Telemetry Pipeline

Throughout this textbook we have discussed telemetry as a series of independent components. Now we connect them together.

Figure 3-29

Complete Network Detection Pipeline

Note. The pipeline shows how information moves through complete Network Detection Pipeline, from its source through processing to the analyst-visible result.

Every alert generated throughout the remainder of this textbook follows this path.

The Role of eve.json

Suricata generates several log files.

The most important is:

/var/log/suricata/eve.json

Unlike traditional text logs, eve.json stores structured JSON records.

Each event may contain:

• Timestamp

• Source IP

• Destination IP

• Source Port

• Destination Port

• Protocol

• Signature ID

• Alert Message

• Severity

• Category

• Flow Information

Because JSON is structured, Wazuh can decode fields automatically.

Why JSON Matters

Traditional log files require extensive parsing.

Example:

Jun 15 14:35:12 IDS ALERT TCP 192.168.1.40 …

JSON stores information as individual fields.

Example:

{ “src_ip”:“192.168.1.40”, “dest_ip”:“192.168.1.10”, “proto”:“TCP”, “signature”:“ET SCAN Potential SSH Scan” }

Structured data dramatically improves searching and correlation.

Analyst Corner

One reason modern SIEM platforms prefer JSON is that analysts search fields, not text.

Instead of searching an entire line, you can search only:

• Source IP

• Destination Port

• Protocol

• Alert Category

• Signature

Structured telemetry makes investigations much faster.

Configuring the Wazuh Agent

The Ubuntu Wazuh Agent must monitor:

/var/log/suricata/eve.json

Within the Wazuh Agent configuration (ossec.conf), a log collection entry should specify:

• Log format: json

• Location: /var/log/suricata/eve.json

This instructs the agent to monitor the file continuously and forward newly written events to the Wazuh Manager. Instructor Note: Throughout this textbook we focus on understanding the configuration rather than memorizing XML syntax. The complete configuration examples are provided in Appendix B and the accompanying laboratory files.

Restarting the Agent

After modifying the configuration, restart the Wazuh Agent.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl restart wazuh-agent

Confirm:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo systemctl status wazuh-agent

Expected:

Active: active (running)

Never assume the restart succeeded. Always verify.

Validate the Agent Log

Review the agent log.

::: {custom-style="CodeLabel"} WAZUH-SRV · Terminal :::

sudo tail -f /var/ossec/logs/ossec.log

Watch for messages indicating:

• Configuration loaded

• JSON monitoring enabled

• File opened successfully

• No parsing errors

• Connection established

Errors should be corrected before continuing.

Generate a Test Alert

Now generate known network activity.

Examples include:

• Nmap scan

• DNS lookup

• HTTP request

• EICAR download

For example:

curl http://example.com or, from Windows:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

nslookup example.com

The objective is to generate traffic that traverses the monitored interface.

Validate eve.json

Immediately verify that Suricata recorded the event.

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

sudo tail -f /var/log/suricata/eve.json

You should observe new JSON records appearing. If no new events appear, the problem exists before Wazuh. Do not troubleshoot Wazuh until Suricata is generating telemetry.

Figure 3-30

Validation Stage 1

Note. The figure summarizes validation Stage 1 and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Only after this succeeds should you continue.

Validate the Wazuh Dashboard

Log into the Dashboard.

Navigate to:

Security Events

Set the time range to:

Last 15 Minutes

Search for:

• Suricata

• The Ubuntu hostname

• Source IP

• Destination IP

• Signature

Locate the generated alert. This confirms the complete telemetry pipeline is functioning.

Figure 3-31

Validation Stage 2

Note. The figure summarizes validation Stage 2 and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

This is the first complete proof that the network detection pipeline is operational.

Correlating Network and Endpoint Telemetry

The real strength of Wazuh becomes apparent when multiple telemetry sources describe the same activity.

Example:

Notice that no single technology tells the complete story. Together, they reconstruct the attack. This principle—telemetry correlation—is the defining capability of a modern SIEM.

Common Student Mistake

Students often search only for the alert title.

Professional analysts also examine:

• Source IP

• Destination IP

• Flow ID

• Signature ID (SID)

• Alert category

• Timestamp

• Hostname

• Related endpoint events

The objective is not simply to locate an alert. The objective is to understand the activity that generated it.

Troubleshooting the Pipeline

When alerts fail to appear, work through the pipeline sequentially.

This systematic approach isolates the failure without unnecessary changes.

SOC Tip

Never troubleshoot from the Dashboard backward. Always troubleshoot from the packet forward. Packets become telemetry. Telemetry becomes events. Events become alerts. Working in the direction of data flow is faster and more reliable.

Baseline Validation Checklist

Before continuing, verify:

Do not proceed until every item has been validated.

Think Like a SOC Analyst

Imagine a student says:

“Suricata isn’t working.”

Your first response should not be:

“Reinstall Suricata.”

Instead, ask:

• Is traffic reaching the sensor?

• Does tcpdump see packets?

• Does eve.json update?

• Is the Wazuh Agent monitoring the file?

• Is the Manager receiving telemetry?

• Can the Dashboard retrieve indexed events?

By asking these questions, you are no longer acting as a software installer—you are thinking like a Security Operations Center analyst.

Looking Ahead

With endpoint telemetry from Sysmon, network telemetry from Suricata, and centralized visibility through Wazuh, the laboratory now possesses a complete security monitoring capability. The next section introduces end-to-end validation testing, where students intentionally generate known events—including Nmap scans, EICAR antivirus detections, PowerShell execution, DNS queries, and web requests—to verify that every component of the SOC functions correctly. This operational validation becomes the standard health check performed before every future lab exercise and investigation (EICAR, n.d.).

Learning Objectives

After completing this section, you should be able to:

• Validate the complete SOC telemetry pipeline.

• Generate known-good test events.

• Confirm endpoint and network visibility.

• Verify Wazuh correlation across multiple telemetry sources.

• Troubleshoot failures using a structured methodology.

• Establish a repeatable daily operational validation routine.

Introduction

One of the most dangerous assumptions in cybersecurity is believing that a monitoring system is working simply because it is powered on. Professional Security Operations Centers validate their monitoring infrastructure continuously.

Why?

Because sensors fail. Agents disconnect. Disk space fills. Rules stop loading. Interfaces change. Updates introduce unexpected behavior. A monitoring system that silently stops collecting telemetry is often more dangerous than one that fails loudly. Throughout the remainder of this textbook, every laboratory exercise begins with a complete operational validation.

Why We Validate

Consider the following statement:

“No alerts appeared today.”

Is this good news?

Maybe.

Or perhaps:

• Suricata stopped.

• Sysmon is no longer logging (Russinovich & Garnier, n.d.).

• The Wazuh Agent disconnected.

• eve.json stopped updating.

• The Dashboard is displaying yesterday’s data.

• The Indexer has failed.

• The time filter is incorrect.

Professional analysts never assume that silence means security. They first prove that the monitoring system is capable of detecting activity.

Figure 3-32

Operational Validation

Note. The figure summarizes operational Validation and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Daily SOC Startup Checklist

Before investigating alerts, verify the following:

Wazuh Server

Ubuntu Sensor

Windows Endpoint

Only after all systems pass validation should investigations begin.

Validation Test 1 — Linux Telemetry

Generate a Linux log entry.

Example:

logger “SOC Validation Test”

Expected Result:

• Linux log updated

• Wazuh Agent forwards event

• Event appears in Dashboard

This validates endpoint telemetry from Ubuntu.

Validation Test 2 — Windows Sysmon

Generate a PowerShell event.

Example:

powershell.exe

Expected Result:

Sysmon Event ID 1 appears.

Then verify:

• Wazuh receives the event.

• Dashboard displays the alert.

Validation Test 3 — DNS Activity

Generate a DNS lookup.

Example:

::: {custom-style="CodeLabel"} WIN11 · PowerShell :::

nslookup www.example.com

Expected Result:

::: {custom-style="CodeLabel"} WIN11 · PowerShell :::

Sysmon Event ID 22.

Verify:

• Event Viewer

• Wazuh Dashboard

Students have already practiced this workflow in previous laboratories.

Validation Test 4 — Suricata

Generate simple network traffic.

Examples:

curl https://example.com or ping example.com

Verify:

• Traffic observed

• eve.json updated

• Dashboard receives telemetry

Validation Test 5 — Nmap Scan

Perform a controlled scan against the Ubuntu sensor.

Example:

::: {custom-style="CodeLabel"} UB2604 · Terminal :::

nmap -sS 192.168.1.10

Expected Result:

::: {custom-style="CodeLabel"} UB2604 · Expected output :::

ET Open generates:

• Port Scan alerts

• Network reconnaissance detections

Students should locate these alerts inside Wazuh.

Validation Test 6 — EICAR

Generate an antivirus detection. Download the EICAR test file.

Expected:

Windows Defender:

• Detects EICAR

• Quarantines file

Wazuh:

• Receives Defender telemetry

Students should correlate:

• Defender

• Sysmon

• Wazuh

Analyst Corner

Notice something interesting. None of these tests attempts to simulate an advanced attacker.

Why?

Because the purpose of operational validation is not to test sophisticated detection.

The objective is much simpler:

Prove that every component of the monitoring pipeline still works. Advanced attack simulations come later.

Correlation Exercise

Students should now correlate events from multiple technologies.

Example timeline:

Question:

Could any individual technology explain the entire sequence?

No. Only correlation provides the complete picture.

Figure 3-33

Multi-Source Correlation

Note. The figure summarizes multi-Source Correlation and highlights the relationships among its principal elements, evidence sources, and analytical outcomes.

Measuring Success

At this stage of the laboratory, students should be capable of proving that:

• Windows generates telemetry.

• Ubuntu generates telemetry.

• Suricata detects network traffic.

• ET Open generates signatures.

• Wazuh receives endpoint logs.

• Wazuh receives network logs.

• Wazuh correlates events.

• Dashboard displays searchable alerts.

This represents a fully operational introductory Security Operations Center.

Common Student Mistake

Students often stop after seeing one successful alert.

Professional engineers verify:

• Multiple telemetry sources

• Multiple event types

• Multiple hosts

• Multiple timestamps

A single successful alert demonstrates functionality. A complete validation demonstrates reliability.

SOC Tip

Develop a personal habit:

Never trust yesterday’s validation. Validate your SOC today.

Monitoring systems change constantly due to:

• Reboots

• Updates

• Configuration changes

• Network changes

• Rule updates

• Human error

Operational confidence comes from current validation—not historical success.

End-to-End Troubleshooting Matrix

This table becomes one of the most frequently referenced troubleshooting resources throughout the course.

Baseline Validation Checklist

Before proceeding to the next chapter:

Students should complete and initial this checklist at the beginning of every major lab exercise.

Think Like a SOC Engineer

Imagine arriving at work and discovering no alerts overnight.

Rather than celebrating, ask yourself:

• Did the network become perfectly secure overnight?

• Or did my monitoring infrastructure stop working?

The only way to answer that question is through systematic validation. Professional SOC engineers earn confidence through evidence, not assumptions.

Chapter Connection

At this point, the Security Operations Center laboratory is fully operational. Students have:

• Built the infrastructure.

• Validated the Wazuh Server.

• Configured Ubuntu 26.04.

• Installed the Wazuh Agent.

• Deployed Suricata.

• Integrated Emerging Threats Open.

• Connected Suricata to Wazuh.

• Verified endpoint telemetry.

• Verified network telemetry.

• Performed end-to-end operational validation.

Beginning in Chapter 4, students shift from building the SOC to using it. The focus changes from installation and validation to investigation, introducing the Wazuh Dashboard in depth, advanced searching, saved queries, timeline analysis, and the first structured incident investigations using the laboratory they have just engineered.

Chapter 3 Key Terms

Knowledge Check

Select the best answer for each question.

1. Why does the Ubuntu sensor in this laboratory use two network interfaces?

A. To separate management traffic from dedicated packet-capture traffic

B. To increase Internet download speed

C. Because Wazuh requires two interfaces to install

D. To allow dual-booting

2. Which VMware network mode is most commonly used for cybersecurity laboratories that need realistic network visibility?

A. NAT

B. Host-Only

C. Bridged

D. Airplane mode

3. What is the primary purpose of a VMware snapshot?

A. To increase virtual machine performance

B. To provide a recovery point before making changes

C. To back up files to the cloud

D. To install new software automatically

4. Where does Suricata write its structured alert and event data by default?

A. /var/log/wazuh.json

B. /etc/suricata/suricata.yaml

C. /var/ossec/logs/ossec.log

D. /var/log/suricata/eve.json

5. What must be true before Suricata can detect a given packet?

A. The packet must be encrypted

B. The Wazuh Manager must request it

C. The packet must actually reach the monitored interface

D. The packet must originate from the Internet

6. What is the purpose of the Emerging Threats Open rule set?

A. It provides community-maintained detection signatures for Suricata

B. It replaces the Wazuh Manager

C. It encrypts agent-to-manager communication

D. It is a replacement for VMware networking

7. Where should custom, locally developed Suricata signatures be stored?

A. Inside the ET Open rule files directly

B. In suricata.yaml

C. In the Wazuh Manager configuration

D. In a separate local.rules file

8. Which command validates Suricata’s configuration file syntax before restarting the service?

A. suricata-update

B. suricata -T -c /etc/suricata/suricata.yaml

C. systemctl enable suricata

D. tail -f eve.json

9. If no Suricata alerts appear in the Wazuh Dashboard after a scan, what should be verified first?

A. Whether the Wazuh Dashboard theme is set correctly

B. Whether the scan was run twice

C. Whether the complete telemetry pipeline — packet, interface, Suricata, eve.json, Agent, Manager, Indexer, Dashboard — is intact

D. Whether Windows Defender is enabled

10. What is the recommended workflow before performing a major software installation in this lab?

A. Take a snapshot, then install, configure, and validate

B. Install first, document later

C. Disable all logging to improve performance

D. Skip validation to save time

Answer Key

Chapter Discussion Questions

• Why is planning (naming conventions, IP addressing, network design) important before installing any software?

• Explain why the Ubuntu sensor uses two separate network interfaces rather than one.

• Describe the difference between Bridged, NAT, and Host-Only VMware networking, and explain when each is appropriate.

• Why is a “successful” installation command insufficient proof that a service is functioning correctly?

• Walk through the complete telemetry path from a network packet to a visible alert in the Wazuh Dashboard.

• Why should vendor-supplied Suricata rules never be edited directly?

• Explain why snapshots are considered one of the most valuable tools available to a SOC engineer.

• Why does this chapter recommend validating one configuration change at a time rather than making several changes at once?

Further Resources

• Wazuh — Installation Guide (https://documentation.wazuh.com/current/installation-guide/index.html) — Authoritative install steps if your build diverges from this chapter.

• Suricata — Quickstart (https://docs.suricata.io/en/latest/quickstart.html) — Official install and first-run guidance.

• Emerging Threats Open Ruleset (https://rules.emergingthreats.net/) — The community signature set your sensor downloads.

• Sysmon (Microsoft Learn) (https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon) — Download and command-line reference.

• Security Onion Documentation (https://docs.securityonion.net/) — Reference for the second NSM platform in the lab topology.

    Version 8       Page  of