Wazuh: open-source SIEM and XDR for DevOps and security teams

❗ Important information: Implementing an enterprise security platform such as Wazuh requires solid knowledge of system administration, networking and security concepts. The material is aimed at experienced administrators and security engineers.

Prerequisites:

Extensive Linux system-administration experience

Solid knowledge of networking and security

Understanding of container technologies and virtualisation

Experience with log management and monitoring systems

What is Wazuh?

In a time when cybersecurity is no longer optional but essential for every IT infrastructure, single security tools are not enough. Wazuh combines SIEM (Security Information and Event Management) with XDR (Extended Detection and Response) as an open-source platform and thereby provides a complete security solution.

Think of Wazuh as a modern security system: it does not only watch every entrance (logs, network traffic), but also analyses behaviour inside (system activity, file changes) and can react to threats automatically. Unlike traditional security products, Wazuh works with a distributed approach — a central server coordinates numerous agents that run on the systems to be monitored.

The platform integrates into modern DevOps environments and supports container monitoring, cloud workloads and traditional on-premises systems equally.


┌─────────────────────────────────────────────────────────────┐
│                   Wazuh overall architecture                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌────────────────────┐             ┌────────────────────┐  │
│  │ Endpoint agents    │ ──────────► │ Wazuh Server       │  │
│  │ (Linux/Win/macOS)  │             │ (Manager & Engine) │  │
│  └────────────────────┘             └─────────┬──────────┘  │
│                                               │ TLS Push    │
│                                               ▼             │
│  ┌────────────────────┐             ┌────────────────────┐  │
│  │ Wazuh Dashboard    │ ◄────────── │ Wazuh Indexer      │  │
│  │ (Kibana/OpenSearch)│             │ (Elastic/OpenSearch│  │
│  └────────────────────┘             └────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Components and architecture

Wazuh's architecture is modular, with each component taking a specific role in security monitoring.

Core components


┌─────────────────────────────────────────────────────────────┐
│                Wazuh ecosystem and data flow                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  [Endpoints] ────► [Wazuh Manager] ────► [Indexer & Dash]   │
│     Agents                Cluster                Frontend   │
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Cycle: Collect ──► Analyse ──► Index                  │  │
│  │         ├── Visualise in dashboards                   │  │
│  │         └── Automatic response (Active Response)      │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

1. Wazuh Manager:

Central nervous system of the platform
Processes and analyses inbound data
Runs rule evaluation
Generates alerts
Controls Active Response

2. Wazuh Agents:


┌─────────────────────────────────────────────────────────────┐
│               Wazuh agent function overview                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ 1. Collection:  System logs, events and integrity     │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ 2. Monitoring:  Processes, network and rootkits       │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ 3. Response:    Local actions, blocks and fixes       │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

3. Elastic Stack integration:


┌─────────────────────────────────────────────────────────────┐
│              Elastic / OpenSearch integration               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Wazuh Indexer / Elasticsearch: storage and indexes    │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Wazuh Dashboard / Kibana:      visualisation and GUI  │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Filebeat:                      secure log transport   │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

How it works and data flow


┌─────────────────────────────────────────────────────────────┐
│              Wazuh data-processing pipeline                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Agent      ──► Data collection on endpoints             │
│                       │                                     │
│                       ▼                                     │
│  2. Manager    ──► Receive, decode and buffer               │
│                       │                                     │
│                       ▼                                     │
│  3. Analysis   ──► Ruleset, decoder and correlation         │
│                       │                                     │
│                       ▼                                     │
│  4. Indexing   ──► Store and index in the indexer           │
│                       │                                     │
│                       ▼                                     │
│  5. Dashboard  ──► Visualisation, alerts and reports        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Comparison with other SIEM solutions

Feature	Wazuh	Splunk	ELK Stack	QRadar
Open Source	✅	❌	✅	❌
Active Response	✅	⚠️	❌	⚠️
FIM	✅	✅	⚠️	✅
Container Security	✅	⚠️	⚠️	⚠️
Cloud Integration	✅	✅	✅	✅
Scalability	✅	✅	✅	✅

💡 Important aspects:

Architecture advantages: Distributed architecture enables scaling, modular design for flexible extension, integrated analysis engine for real-time processing.

Differentiating features: Native integration of SIEM and XDR, full Active Response capabilities, free enterprise features.

Particular strengths: Container and cloud-native monitoring, rule-based and ML-assisted analysis, compliance monitoring (PCI DSS, GDPR, HIPAA).

Installation and base configuration

System requirements and preparation

Before installation, the system must meet the necessary requirements.

💡 Information: The examples use Ubuntu 22.04 as the sample distribution. The core concepts are the same on every Linux system, but package installation and some configuration paths can differ by distribution.

System requirements:

Correct sizing of the Wazuh system is decisive for its performance.


┌─────────────────────────────────────────────────────────────┐
│          System requirements for production                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Wazuh Manager:  4 cores CPU │ 8 GB RAM │ 50 GB SSD    │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Elastic Stack:  4 cores CPU │ 8 GB RAM │ 100 GB SSD   │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Capacity:       Up to 100 agents │ 5000 EPS │ 30d ret.│  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

⚠️ Important: These requirements apply to production environments. Tests can run with fewer resources, but you should still provide at least 4 GB RAM.

System preparation:


# Update the system
sudo apt update && sudo apt upgrade -y

# Install required packages
sudo apt install curl apt-transport-https unzip wget libcap2-bin software-properties-common lsb-release gnupg2 -y

# Adjust system limits
cat > /etc/sysctl.d/99-wazuh.conf << EOF
vm.max_map_count=262144
fs.file-max=65535
EOF

# Activate the changes
sudo sysctl -p /etc/sysctl.d/99-wazuh.conf

Wazuh server installation

Installing the Wazuh server is the foundation of the security-monitoring infrastructure. Official package sources keep the install clean and updateable.


# Add the GPG key
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import && chmod 644 /usr/share/keyrings/wazuh.gpg

# Add the repository
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | tee -a /etc/apt/sources.list.d/wazuh.list

# Install the Wazuh manager
sudo apt update
sudo apt install wazuh-manager -y

Elastic Stack integration

The Elastic Stack is the backbone for data storage and analysis in Wazuh.


# Elasticsearch installation
curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/elasticsearch.gpg --import
echo "deb [signed-by=/usr/share/keyrings/elasticsearch.gpg] https://artifacts.elastic.co/packages/7.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-7.x.list
sudo apt update && sudo apt install elasticsearch=7.17.9

# Elasticsearch configuration
cat > /etc/elasticsearch/elasticsearch.yml << EOF
node.name: node-1
network.host: localhost
http.port: 9200
cluster.initial_master_nodes: ["node-1"]
EOF

Dashboard setup

The Wazuh dashboard, based on Kibana, is the central place for analysis and monitoring.


# Kibana installation
sudo apt install kibana=7.17.9

# Wazuh plugin installation
cd /usr/share/kibana
sudo -u kibana bin/kibana-plugin install https://packages.wazuh.com/4.x/ui/kibana/wazuh_kibana-4.4.0_7.17.9-1.zip

Enable and start services


# Enable services
sudo systemctl daemon-reload
sudo systemctl enable elasticsearch wazuh-manager kibana
sudo systemctl start elasticsearch wazuh-manager kibana

# Check status
sudo systemctl status elasticsearch wazuh-manager kibana

⚠️ Important notes:

Security: Change default passwords, configure the firewall, enable SSL/TLS.

Performance: Adjust Elasticsearch heap size, set indexing strategies, define retention policies.

Monitoring: Watch service status, set up log rotation, implement a backup strategy.

Agent deployment and management

Wazuh agents are far more than simple data collectors. They form a complex network of security sensors that not only capture data but can also react to threats actively.

Agent architecture


┌─────────────────────────────────────────────────────────────┐
│             Modular structure of the Wazuh agent            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Collector: System logs, security events, custom logs  │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Monitor:   File integrity (FIM), processes and ports  │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Responder: Active Response scripts and policy check   │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Agent installation


# For Ubuntu/Debian systems
curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add -
echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list
apt update
apt install wazuh-agent


┌─────────────────────────────────────────────────────────────┐
│                 Agent installation options                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Package manager: APT (Debian/Ubuntu), YUM, WPK (Win)  │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Automation:      Ansible, Puppet, Chef playbooks      │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Containers:      Docker images and Kubernetes DSets   │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Registration and authentication

Registering an agent is a critical security process that goes beyond simply establishing a connection.


# On the Wazuh server
sudo /var/ossec/bin/manage_agents -a -n "WebServer01" -i "192.168.1.100"

# Extract the agent key
sudo /var/ossec/bin/manage_agents -e <agent_id>

# On the agent
echo "<extracted_key>" | sudo /var/ossec/bin/manage_agents -i


┌─────────────────────────────────────────────────────────────┐
│                 Agent registration process                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Agent      ──► TLS auth request to port 1515/TCP        │
│                       │                                     │
│                       ▼                                     │
│  2. Auth server──► Validate password or token               │
│                       │                                     │
│                       ▼                                     │
│  3. Manager    ──► Creates a unique agent key               │
│                       │                                     │
│                       ▼                                     │
│  4. Agent      ──► Stores key in client.keys and starts     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Group management

Groups in Wazuh are more than organisational units. They enable granular control over security policies.


# Create a group
/var/ossec/bin/agent_groups -a -g webservers

# Assign an agent to a group
/var/ossec/bin/agent_groups -a -i 001 -g webservers

# Group configuration
cat > /var/ossec/etc/shared/webservers/agent.conf << EOF
<agent_config>
  <localfile>
    <location>/var/log/apache2/access.log</location>
    <log_format>apache</log_format>
  </localfile>
</agent_config>
EOF

Remote deployment

Automated deployment is not optional in large infrastructures; it is mandatory.


# Ansible playbook example
- name: Deploy Wazuh Agent
  hosts: all
  tasks:
    - name: Add Wazuh repo
      apt_repository:
        repo: "deb https://packages.wazuh.com/4.x/apt/ stable main"
        state: present

    - name: Install Wazuh Agent
      apt:
        name: wazuh-agent
        state: present
        update_cache: yes

    - name: Configure Agent
      template:
        src: ossec.conf.j2
        dest: /var/ossec/etc/ossec.conf

💡 Important notes:

Security aspects: Configure secure communication, certificate-based authentication, regular key rotation.

Performance optimisation: Adjust buffer sizes, configure event filtering, set resource limits.

Maintenance: Develop an update strategy, monitor agent health, back up agent configuration.

Core functions

Security event detection

Detecting security events is far more than simple logfile analysis. In modern IT environments, many event sources must be correlated in real time.


┌─────────────────────────────────────────────────────────────┐
│             Event detection and rule analysis flow          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Log sources   ──► Syslog, journald and applications        │
│                       │                                     │
│                       ▼                                     │
│  Agent buffer  ──► Local filtering and spooling             │
│                       │                                     │
│                       ▼                                     │
│  Decoding      ──► XML decoder extracts fields              │
│                       │                                     │
│                       ▼                                     │
│  Rule analysis ──► Correlation and threshold checks         │
│                       │                                     │
│                       ▼                                     │
│  Security alert──► Indexing, dashboard and alerts           │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- Example rule for SSH brute-force detection -->
<rule id="100001" level="10">
  <if_sid>5710</if_sid>
  <match>^Failed password</match>
  <frequency>8</frequency>
  <timeframe>120</timeframe>
  <description>Multiple failed login attempts</description>
</rule>

File Integrity Monitoring (FIM)

File Integrity Monitoring is a critical security mechanism that goes far beyond simple checksum comparisons.


┌─────────────────────────────────────────────────────────────┐
│         File Integrity Monitoring (FIM) architecture        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Monitored system files (/etc, /bin, /sbin)                 │
│                              │                              │
│                              ▼                              │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ 1. Hash calculation: MD5, SHA1 and SHA256 checksums   │  │
│  │ 2. Permissions:      rights (chmod), owner and group  │  │
│  │ 3. File attributes:  inode, size, mtime and ctime     │  │
│  └───────────────────────────────────────────────────────┘  │
│                              │                              │
│                              ▼                              │
│  SQLite FIM DB ──► Integrity compare ──► Alerting           │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- FIM configuration for critical system paths -->
<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <ignore>/etc/mtab</ignore>
  <ignore type="sregex">^/etc/.*\.swp$</ignore>
</syscheck>

Vulnerability detection

Vulnerability detection in Wazuh goes far beyond simple CVE matching.


┌─────────────────────────────────────────────────────────────┐
│              Vulnerability detection workflow               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Package inventory ──► Agent collects installed packages │
│                          │                                  │
│                          ▼                                  │
│  2. CVE feed      ──► Manager matches against NVD/CPE       │
│                          │                                  │
│                          ▼                                  │
│  3. CVSS scoring  ──► Severity and risk rating              │
│                          │                                  │
│                          ▼                                  │
│  4. Reporting     ──► Dashboard alerts and patch priority   │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- Vulnerability detector configuration -->
<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>1d</interval>
  <feed name="ubuntu-20">
    <enabled>yes</enabled>
    <update_interval>1h</update_interval>
  </feed>
</vulnerability-detector>

Compliance monitoring

Compliance monitoring in Wazuh is more than a checklist of rule sets. It is a dynamic system that continuously watches and documents adherence to security standards.


┌─────────────────────────────────────────────────────────────┐
│               Compliance monitoring framework               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Standards: PCI DSS, GDPR, HIPAA, NIST, CIS Benchmark  │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Checks:    Security config, rights, audit log         │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Reporting: Deviations, compliance score and docs      │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Active Response

Active Response is the autonomous immune system of the IT infrastructure. Unlike passive security systems, Wazuh can react automatically to detected threats.


┌─────────────────────────────────────────────────────────────┐
│                Active Response control chain                │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Security event ──► Detection through the ruleset        │
│                           │                                 │
│                           ▼                                 │
│  2. Rule match     ──► Threshold or pattern met             │
│                           │                                 │
│                           ▼                                 │
│  3. Action trigger ──► Fire the response command            │
│                           │                                 │
│                           ▼                                 │
│  4. Local action   ──► Firewall drop, IP block, kill        │
│                           │                                 │
│                           ▼                                 │
│  5. Feedback loop  ──► Log entry in active-responses.log    │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- Active Response configuration -->
<command>
  <name>firewall-block</name>
  <executable>firewall-block.sh</executable>
  <expect>srcip</expect>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>firewall-block</command>
  <location>local</location>
  <rules_id>100001</rules_id>
  <timeout>600</timeout>
</active-response>

💡 Important notes:

Performance optimisation: Rule optimisation for minimal system load, efficient FIM configuration, adjusted scan intervals.

Minimise false positives: Rule tuning based on the environment, whitelist management, context-based analysis.

Integration: API use for automation, custom response scripts, external tool integration.

Integration and monitoring

A considered monitoring and integration design joins every security component into a coherent system.

Log collection

Log collection in Wazuh is a sophisticated system for capturing, normalising and correlating event data from many sources.


┌─────────────────────────────────────────────────────────────┐
│                 Log collection architecture                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Sources      ──► Servers, services, endpoints, cloud    │
│                         │                                   │
│                         ▼                                   │
│  2. Collection   ──► Wazuh agent and syslog forwarder       │
│                         │                                   │
│                         ▼                                   │
│  3. Processing   ──► Parsing, filtering and normalisation   │
│                         │                                   │
│                         ▼                                   │
│  4. Storage      ──► Indexer cluster and long-term archive  │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- Example of an extended log-collection configuration -->
<localfile>
  <location>/var/log/auth.log</location>
  <log_format>syslog</log_format>
  <frequency>10</frequency>
  <only-future-events>yes</only-future-events>
  <query>user failed|authentication failure</query>
</localfile>

Alert configuration

Alert configuration is the heart of security monitoring.


┌─────────────────────────────────────────────────────────────┐
│                  Alert management workflow                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Inbound event ──► Rule check (conditions/level)            │
│                              │                              │
│                              ▼                              │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Classification: severity (1-16), priority and impact  │  │
│  └───────────────────────────────────────────────────────┘  │
│                              │                              │
│                              ▼                              │
│  Notification  ──► Email, Slack, PagerDuty, SIEM            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Creating custom rules

Creating custom rules is one of the most powerful functions in Wazuh.


┌─────────────────────────────────────────────────────────────┐
│                  Rule hierarchy in Wazuh                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Base rules:      Standard detection (OSSEC core)      │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Extended rules:  Rules in local_rules.xml             │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Correlation:     Multi-event rule chains and timers   │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- Example of a complex custom rule -->
<rule id="100100" level="12">
  <if_sid>5710</if_sid>
  <match>^Failed password</match>
  <regex>user: (\w+)</regex>
  <frequency>8</frequency>
  <timeframe>120</timeframe>
  <if_matched_group>admin|root</if_matched_group>
  <description>Brute force attack on privileged account</description>
  <mitre>
    <id>T1110</id>
    <tactic>Credential Access</tactic>
  </mitre>
</rule>

API use

The Wazuh API is the foundation for automation and integration. The RESTful API not only queries data but also programmatically controls every Wazuh component.


┌─────────────────────────────────────────────────────────────┐
│                Wazuh RESTful API architecture               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Clients / automation / DevOps (Ansible, CI/CD, scripts)    │
│                              │                              │
│                              ▼                              │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ API gateway (port 55000/TCP): JWT token auth and RBAC │  │
│  └───────────────────────────────────────────────────────┘  │
│                              │                              │
│                              ▼                              │
│  Wazuh Manager: configuration, agent control, queries       │
│                                                             │
└─────────────────────────────────────────────────────────────┘


# Example of API interaction
# Generate a token
TOKEN=$(curl -u admin:admin -k -X GET "https://localhost:55000/security/user/authenticate" | jq -r '.data.token')

# Query agent status
curl -k -X GET "https://localhost:55000/agents" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json"

Reporting

The reporting system in Wazuh provides a complete analysis and documentation platform.


┌─────────────────────────────────────────────────────────────┐
│                 Reporting and audit framework               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Data sources ──► Raw data, metrics and events           │
│                         │                                   │
│                         ▼                                   │
│  2. Aggregation  ──► Filter, group and summarise            │
│                         │                                   │
│                         ▼                                   │
│  3. Analysis     ──► Trend analysis, anomalies and insights │
│                         │                                   │
│                         ▼                                   │
│  4. Output       ──► PDF/CSV reports and management boards  │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- Report configuration example -->
<report>
  <title>Security Compliance Report</title>
  <schedule type="weekly" day="1" time="23:59">
  <format>pdf</format>
  <sections>
    - compliance_pci
    - top_alerts
    - agent_status
  </sections>
  <mail_to>security@domain.com</mail_to>
</report>

💡 Important integration aspects:

Data consistency: Uniform data formats, lossless transfer, data validation.

Scalability: Load distribution, buffering, performance optimisation.

Security: Encrypted communication, access controls, audit logging.

Best practices and use cases

Security policies

Security policies in Wazuh are the foundation of the security strategy.


┌─────────────────────────────────────────────────────────────┐
│                  Security policy framework                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ Base rules:         Compliance baselines and CIS      │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Extended policies:  Exceptions and special cases      │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Automation:         Active Response and policy enforce│  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- Example of a complete security policy -->
<policy>
  <name>Critical Server Policy</name>
  <rules>
    - system_hardening
    - access_control
    - network_protection
  </rules>
  <exceptions>
    - maintenance_window
    - authorized_changes
  </exceptions>
  <actions>
    - alert_critical
    - block_access
    - notify_admin
  </actions>
</policy>

Alert management


┌─────────────────────────────────────────────────────────────┐
│                    Alert management flow                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Detection       ──► Event and context check             │
│                            │                                │
│                            ▼                                │
│  2. Classification  ──► Assignment by severity and type     │
│                            │                                │
│                            ▼                                │
│  3. Prioritisation  ──► Urgency and escalation level        │
│                            │                                │
│                            ▼                                │
│  4. Response        ──► Manual triage or automation         │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Performance optimisation


┌─────────────────────────────────────────────────────────────┐
│             Performance and scaling layers                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌───────────────────────────────────────────────────────┐  │
│  │ System layer:  Kernel parameters (sysctl), CPU, RAM   │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Agent layer:   Sampling rates, buffer limits, queues  │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Manager layer: Wazuh cluster, daemon threads, tuning  │  │
│  ├───────────────────────────────────────────────────────┤  │
│  │ Storage layer: Shard allocation, ILM, retention rules │  │
│  └───────────────────────────────────────────────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘


<!-- Performance optimisation example -->
<ossec_config>
  <global>
    <memory_size>2048</memory_size>
    <queue_size>131072</queue_size>
    <events_per_second>1000</events_per_second>
  </global>

  <syscheck>
    <frequency>43200</frequency>
    <max_files_per_second>50</max_files_per_second>
  </syscheck>
</ossec_config>

Incident response


┌─────────────────────────────────────────────────────────────┐
│                 Incident response workflow                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. Detection   ──► Alerting, log spike or IOC find         │
│                        │                                    │
│                        ▼                                    │
│  2. Analysis    ──► Forensics, timeline and correlation     │
│                        │                                    │
│                        ▼                                    │
│  3. Containment ──► Host isolation, quarantine              │
│                        │                                    │
│                        ▼                                    │
│  4. Recovery    ──► Cleanup, patches and hardening          │
│                                                             │
└─────────────────────────────────────────────────────────────┘


# Example incident response script
#!/bin/bash
case "$1" in
  'brute_force')
    iptables -A INPUT -s "$2" -j DROP
    logger "Blocked IP $2 due to brute force attack"
    notify_security_team "Brute force attack from $2"
    ;;
  'malware')
    isolate_system "$2"
    run_emergency_scan "$2"
    collect_forensics "$2"
    ;;
esac

Compliance checking


<!-- Compliance check configuration -->
<rootcheck>
  <check_unixaudit>yes</check_unixaudit>
  <check_files>yes</check_files>
  <check_trojans>yes</check_trojans>
  <check_dev>yes</check_dev>
  <check_sys>yes</check_sys>
  <check_pids>yes</check_pids>
  <check_ports>yes</check_ports>
  <check_if>yes</check_if>

  <system_audit>/var/ossec/etc/shared/cis_debian_linux_rcl.txt</system_audit>
  <system_audit>/var/ossec/etc/shared/pci_dss_rcl.txt</system_audit>
</rootcheck>

💡 Critical success factors:

Process integration: Documented procedures, clear responsibilities, regular reviews.

Resource management: Capacity planning, performance monitoring, scaling strategy.

Continuous improvement: Feedback loops, metrics-based optimisation, regular evaluation.

Compliance in modern IT environments is more than ticking checklists. Wazuh provides specific functions for various standards.

PCI DSS compliance:


<!-- PCI DSS specific configuration -->
<pci_dss>
  <requirement_10>
    <rule_id>80700</rule_id>
    <description>Log all access to cardholder data</description>
    <monitoring>
      - file_integrity
      - access_control
      - audit_logs
    </monitoring>
  </requirement_10>
</pci_dss>

GDPR compliance:


<!-- GDPR monitoring example -->
<gdpr>
  <article_32>
    <security_measures>
      - encryption_at_rest
      - encryption_in_transit
      - access_logging
      - breach_detection
    </security_measures>
    <monitoring>
      - data_access
      - unauthorized_changes
      - security_events
    </monitoring>
  </article_32>
</gdpr>

💡 Compliance best practices:

Documentation: Complete evidence trails, automated report generation, incident documentation.

Continuous monitoring: Real-time compliance monitoring, automatic notifications, regular audits.

Adaptability: Flexible rule adjustment, scalable controls, update management.

Troubleshooting and maintenance

Performance monitoring

Performance monitoring of a Wazuh installation needs a holistic approach.


# Comprehensive performance-monitoring script
#!/bin/bash
echo "=== System Resources ==="
ps aux | grep -E "wazuh|ossec" | awk '{print $2, $3, $4, $11}'
free -m
vmstat 1 5
iostat -x 1 5 | grep -E "Device|sda"
netstat -anp | grep -E "wazuh|ossec"

Debugging


# Extended debug script
#!/bin/bash
echo "=== Wazuh Debug Analysis ==="

debug_level_check() {
    echo "Checking Debug Levels..."
    grep -r "debug" /var/ossec/etc/internal_options.conf
    grep -r "debug" /var/ossec/etc/local_internal_options.conf
}

service_health_check() {
    echo "Analyzing Service Health..."
    for service in wazuh-manager filebeat elasticsearch kibana; do
        echo "=== $service Status ==="
        systemctl status $service --no-pager
        journalctl -u $service --no-pager | tail -n 50
    done
}

config_validation() {
    echo "Validating Configurations..."
    /var/ossec/bin/ossec-logtest -t
    /var/ossec/bin/ossec-analysisd -t
}

debug_level_check
service_health_check
config_validation

Backup and recovery


# Comprehensive backup script
#!/bin/bash
BACKUP_DIR="/backup/wazuh/$(date +%Y%m%d)"
CONFIG_DIR="/var/ossec/etc"
DATA_DIR="/var/ossec/data"

mkdir -p "$BACKUP_DIR"/{config,data,state}

backup_config() {
    echo "Backing up configurations..."
    cp -r "$CONFIG_DIR"/* "$BACKUP_DIR/config/"
    tar czf "$BACKUP_DIR/config.tar.gz" -C "$BACKUP_DIR" config/
}

backup_data() {
    echo "Backing up data..."
    systemctl stop wazuh-manager
    cp -r "$DATA_DIR"/* "$BACKUP_DIR/data/"
    tar czf "$BACKUP_DIR/data.tar.gz" -C "$BACKUP_DIR" data/
    systemctl start wazuh-manager
}

backup_state() {
    echo "Saving system state..."
    systemctl status wazuh-* > "$BACKUP_DIR/state/services.txt"
    netstat -tulpn > "$BACKUP_DIR/state/network.txt"
    ps aux | grep -E "wazuh|ossec" > "$BACKUP_DIR/state/processes.txt"
}

{
    backup_config
    backup_data
    backup_state
} 2>"$BACKUP_DIR/backup.log"

Updates and upgrades

Updating a Wazuh installation is a critical process that needs careful planning, testing and validation.


# Update script with safety measures
#!/bin/bash
UPDATE_LOG="/var/log/wazuh_update.log"
BACKUP_DIR="/backup/wazuh/pre_update_$(date +%Y%m%d)"
WAZUH_VERSION="4.4.0"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$UPDATE_LOG"
}

pre_update_check() {
    log "Starting pre-update checks..."
    if ! systemctl is-active --quiet wazuh-manager; then
        log "ERROR: Wazuh-Manager is not running"
        exit 1
    fi
    FREE_SPACE=$(df -m /var/ossec | awk 'NR==2 {print $4}')
    if [ "$FREE_SPACE" -lt 5000 ]; then
        log "ERROR: Insufficient disk space"
        exit 1
    fi
}

perform_backup() {
    log "Creating pre-update backup..."
    tar czf "$BACKUP_DIR/etc.tar.gz" /var/ossec/etc/
    /var/ossec/bin/wazuh-control info > "$BACKUP_DIR/version_info.txt"
}

perform_update() {
    log "Starting update process..."
    systemctl stop wazuh-manager
    apt-get update
    if ! apt-get install wazuh-manager="$WAZUH_VERSION"; then
        log "ERROR: Update failed"
        restore_from_backup
        exit 1
    fi
}

validate_update() {
    log "Validating update..."
    systemctl start wazuh-manager
    sleep 10
    if ! systemctl is-active --quiet wazuh-manager; then
        log "ERROR: Service failed to start after update"
        restore_from_backup
        exit 1
    fi
}

restore_from_backup() {
    log "Initiating rollback procedure..."
    systemctl stop wazuh-manager
    tar xzf "$BACKUP_DIR/etc.tar.gz" -C /
    systemctl start wazuh-manager
    log "Rollback completed"
}

{
    log "Starting Wazuh update process to version $WAZUH_VERSION"
    pre_update_check
    perform_backup
    perform_update
    validate_update
    log "Update completed successfully"
} || {
    log "Update failed - check logs for details"
    exit 1
}

⚠️ Critical update aspects:

Preparation: Full system analysis, backup validation, dependency check, resource planning.

Execution: Stepwise migration, continuous monitoring, error logging, rollback readiness.

Follow-up: Function tests of every component, performance analysis, documentation of changes.

System monitoring and log management


# Extended system-monitoring script
#!/bin/bash
LOG_DIR="/var/log/wazuh-monitoring"
RETENTION_DAYS=30

log_message() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" >> "$LOG_DIR/system_health.log"
}

monitor_resources() {
    log_message "=== System Resource Check ==="
    CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}')
    CPU_WAZUH=$(ps aux | grep ossec | awk '{sum+=$3} END {print sum}')
    log_message "CPU Usage: Total=${CPU_USAGE}%, Wazuh=${CPU_WAZUH}%"

    MEMORY_TOTAL=$(free -m | awk 'NR==2 {print $2}')
    MEMORY_USED=$(free -m | awk 'NR==2 {print $3}')
    MEMORY_WAZUH=$(ps aux | grep ossec | awk '{sum+=$4} END {print sum}')
    log_message "Memory: Total=${MEMORY_TOTAL}MB, Used=${MEMORY_USED}MB, Wazuh=${MEMORY_WAZUH}%"
}

manage_logs() {
    log_message "=== Log Management ==="
    find "$LOG_DIR" -type f -name "*.log" -mtime +$RETENTION_DAYS -exec rm {} \;

    for LOG_FILE in /var/ossec/logs/*.log; do
        SIZE=$(du -h "$LOG_FILE" | cut -f1)
        ENTRIES=$(wc -l < "$LOG_FILE")
        ERRORS=$(grep -c "error" "$LOG_FILE")
        WARNINGS=$(grep -c "warning" "$LOG_FILE")
        log_message "Log File: $LOG_FILE - Size: $SIZE - Entries: $ENTRIES - Errors: $ERRORS - Warnings: $WARNINGS"
    done
}

analyze_alerts() {
    log_message "=== Alert Analysis ==="
    ALERTS_TODAY=$(grep -c "$(date +%Y/%m/%d)" /var/ossec/logs/alerts/alerts.log)
    FALSE_POSITIVES=$(grep -c "level 0" /var/ossec/logs/alerts/alerts.log)
    CRITICAL_ALERTS=$(grep -c "level [789]" /var/ossec/logs/alerts/alerts.log)
    log_message "Alert Statistics: Total=$ALERTS_TODAY, False Positives=$FALSE_POSITIVES, Critical=$CRITICAL_ALERTS"
}

{
    mkdir -p "$LOG_DIR"
    monitor_resources
    manage_logs
    analyze_alerts
}

Resource management

The balance between system resources and monitoring capacity decides the effectiveness of the Wazuh installation.


# Comprehensive resource-management script
#!/bin/bash
WAZUH_PATH="/var/ossec"
ES_PATH="/var/lib/elasticsearch"
ALERT_THRESHOLD=85

monitor_resources() {
    DISK_USAGE=$(df -h "$WAZUH_PATH" | awk 'NR==2 {print $5}' | sed 's/%//')
    ES_DISK_USAGE=$(df -h "$ES_PATH" | awk 'NR==2 {print $5}' | sed 's/%//')

    if [ "$DISK_USAGE" -gt "$ALERT_THRESHOLD" ] || [ "$ES_DISK_USAGE" -gt "$ALERT_THRESHOLD" ]; then
        find "$WAZUH_PATH/logs/archives" -type f -mtime +30 -delete
        curl -XPOST "localhost:9200/_forcemerge?only_expunge_deletes=true"
        curl -XPOST "localhost:9200/_cache/clear"
    fi
}

optimize_shards() {
    CLUSTER_STATUS=$(curl -s "localhost:9200/_cluster/health" | jq -r '.status')
    if [ "$CLUSTER_STATUS" != "green" ]; then
        curl -XPUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
        {
            "transient": {
                "cluster.routing.allocation.disk.threshold_enabled": true,
                "cluster.routing.allocation.disk.watermark.low": "85%",
                "cluster.routing.allocation.disk.watermark.high": "90%",
                "cluster.routing.allocation.disk.watermark.flood_stage": "95%"
            }
        }'
    fi
}

optimize_performance() {
    cat > "$WAZUH_PATH/etc/local_internal_options.conf" << EOF
    wazuh_database.sync_agent_info_max_time=10m
    analysisd.event_threads=4
    remoted.recv_counter_flush=128
    remoted.comp_average_printout=0
EOF

    cat > "/etc/elasticsearch/jvm.options.d/heap.options" << EOF
    -Xms4g
    -Xmx4g
EOF
}

{
    echo "Starting Resource Management at $(date)"
    monitor_resources
    optimize_shards
    optimize_performance
    echo "Resource Management completed at $(date)"
} >> /var/log/wazuh-resource-management.log 2>&1

Network optimisation


# Network optimisation script
#!/bin/bash
WAZUH_CONF="/var/ossec/etc/ossec.conf"

optimize_network() {
    cat > /etc/sysctl.d/99-wazuh-network.conf << EOF
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_max_tw_buckets = 1440000
net.core.somaxconn = 1024
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 87380
net.core.wmem_default = 87380
EOF
    sysctl -p /etc/sysctl.d/99-wazuh-network.conf
}

optimize_communication() {
    cat > "$WAZUH_CONF.tmp" << EOF
<ossec_config>
  <remote>
    <connection>secure</connection>
    <port>1514</port>
    <protocol>tcp</protocol>
    <queue_size>131072</queue_size>
  </remote>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>no</logall>
    <memory_size>8192</memory_size>
    <process_pool_size>4</process_pool_size>
  </global>
</ossec_config>
EOF

    if /var/ossec/bin/ossec-logtest -c "$WAZUH_CONF.tmp"; then
        mv "$WAZUH_CONF.tmp" "$WAZUH_CONF"
        systemctl restart wazuh-manager
    else
        rm "$WAZUH_CONF.tmp"
    fi
}

optimize_network
optimize_communication

💡 Critical network aspects:

Communication optimisation: TCP stack tuning, buffer-size adjustment, protocol optimisation, connection management.

Security aspects: Encrypted communication, certificate management, port security, traffic control.

Performance monitoring: Latency monitoring, throughput analysis, connection quality, resource use.

Practical examples

Brute-force detection


<!-- Context-based brute-force detection -->
<group name="brute_force">
  <rule id="100100" level="10">
    <if_sid>5710</if_sid>
    <match>^Failed password|Failed auth</match>
    <frequency>8</frequency>
    <timeframe>120</timeframe>
    <if_matched_ip>known_malicious_ips</if_matched_ip>
    <description>SSH authentication failures from suspicious IP.</description>
    <mitre>
      <id>T1110</id>
      <tactic>Credential Access</tactic>
    </mitre>
  </rule>

  <rule id="100101" level="12">
    <if_matched_sid>100100</if_matched_sid>
    <same_source_ip />
    <frequency>2</frequency>
    <timeframe>3600</timeframe>
    <if_matched_group>authentication_success</if_matched_group>
    <description>Pattern suggests sophisticated brute-force attempt.</description>
  </rule>
</group>

Malware detection


<!-- Extended malware detection -->
<group name="malware_detection">
  <rule id="100200" level="12">
    <if_group>syscheck</if_group>
    <match>WinExec|CreateRemoteThread|WriteProcessMemory</match>
    <regex>\.exe$|\.dll$|\.ps1$</regex>
    <description>Suspicious file operation detected</description>
    <mitre>
      <id>T1055</id>
      <tactic>Execution</tactic>
    </mitre>
  </rule>

  <rule id="100201" level="14">
    <if_sid>100200</if_sid>
    <if_matched_group>network_connection</if_matched_group>
    <timeframe>60</timeframe>
    <description>Process injection with network activity</description>
  </rule>
</group>


# Malware-detection script
#!/bin/bash
monitor_processes() {
    while true; do
        ps auxf | grep -E "cmd\.exe.*powershell|bash.*nc" >> /var/log/suspicious_processes.log
        top -b -n 1 | grep -E "crypto|miner" >> /var/log/cpu_anomalies.log
        netstat -tupan | grep -E ":(4444|8080|6666)" >> /var/log/network_anomalies.log
        sleep 60
    done
}

yara_scan() {
    for dir in /bin /usr/bin /tmp; do
        yara /var/ossec/etc/rules/malware_rules.yar "$dir" >> /var/log/yara_detections.log
    done
}

{
    monitor_processes &
    while true; do
        yara_scan
        sleep 3600
    done
} 2>&1 | /var/ossec/bin/ossec-csyslogd

Custom rules


<!-- Advanced custom rules -->
<group name="custom_detection">
  <rule id="100400" level="3">
    <decoded_as>sshd</decoded_as>
    <match>authentication success</match>
    <description>SSH login succeeded</description>
  </rule>

  <rule id="100401" level="8">
    <if_sid>100400</if_sid>
    <if_matched_group>software_change</if_matched_group>
    <timeframe>300</timeframe>
    <description>Suspicious activity after SSH login</description>
    <mitre>
      <id>T1078</id>
      <tactic>Initial Access</tactic>
    </mitre>
  </rule>

  <rule id="100402" level="12">
    <if_group>web</if_group>
    <match>SELECT.*UNION|INSERT.*INTO|UPDATE.*SET</match>
    <regex>\.php$|\.asp$</regex>
    <description>SQL injection attempt detected</description>
    <options>no_log</options>
    <group>attack,sql_injection</group>
  </rule>
</group>


#!/bin/bash
RULES_DIR="/var/ossec/etc/rules"
BACKUP_DIR="/var/ossec/backup/rules"

create_rule_template() {
    local RULE_ID="$1"
    local DESCRIPTION="$2"
    cat << EOF > "$RULES_DIR/custom_${RULE_ID}.xml"
<group name="custom_${RULE_ID}">
    <rule id="${RULE_ID}" level="0">
        <if_sid>530</if_sid>
        <description>${DESCRIPTION}</description>
        <mitre>
            <id>TXXXX</id>
            <tactic>Detection</tactic>
        </mitre>
    </rule>
</group>
EOF
}

test_rule() {
    local RULE_FILE="$1"
    if ! /var/ossec/bin/ossec-analysisd -t -c "$RULE_FILE"; then
        echo "Syntax error in rule file"
        return 1
    fi
    logger "TEST: Custom rule test event for $RULE_FILE"
}

case "$1" in
    "create") create_rule_template "$2" "$3" ;;
    "test") test_rule "$2" ;;
    *) echo "Usage: $0 {create|test} [rule_id] [description]"; exit 1 ;;
esac

💡 Rule development:

Design principles: Precise conditions, minimal false positives, efficient processing, scalable structure.

Implementation: Rule-group organisation, dependency management, performance optimisation, error handling.

Maintenance: Regular review, performance monitoring, adaptation to new threats, documentation.

Command Reference (Cheatsheet)

For quick access in administration and incident-response work, the following reference table summarises the most important Wazuh commands for service control, agent management and rule detection:

Command / syntax	Description and practical use
`/var/ossec/bin/wazuh-control status`	Shows the current runtime status of every Wazuh manager daemon.
`/var/ossec/bin/wazuh-control restart`	Performs a clean restart of every manager service.
`/var/ossec/bin/manage_agents -l`	Lists every registered agent including ID, name, IP and status.
`/var/ossec/bin/manage_agents -a -n <name> -i <ip>`	Adds a new agent manually to the server database.
`/var/ossec/bin/manage_agents -e <agent_id>`	Extracts the symmetric authentication key for an agent.
`/var/ossec/bin/agent_control -l`	Shows active endpoints connected to the manager.
`/var/ossec/bin/agent_control -i <agent_id>`	Outputs detailed system and connection information for an agent.
`/var/ossec/bin/agent_control -r -u <agent_id>`	Restarts the FIM (syscheck) or rootkit scan on the target agent.
`/var/ossec/bin/wazuh-logtest`	Interactive test tool to check logs against decoders and rules.
`/var/ossec/bin/wazuh-analysisd -t`	Validates XML ruleset and decoder syntax before reload.
`/var/ossec/bin/syscheck_control -i <agent_id>`	Shows the File Integrity Monitoring (FIM) database of the agent.
`/var/ossec/bin/rootcheck_control -i <agent_id>`	Lists found system anomalies and rootkit suspicions.
`systemctl status wazuh-manager`	Checks the systemd service status of the Wazuh manager.
`systemctl status wazuh-agent`	Checks the systemd service status of the local Wazuh agent.
`systemctl status wazuh-indexer`	Checks the cluster and indexing service (Wazuh Indexer).
`systemctl status wazuh-dashboard`	Checks the web user interface (Wazuh Dashboard).

Further Resources

The following official documentation, frameworks and community projects go deeper into the security and automation concepts covered here:

Resource	Description
Wazuh documentation	Official technical documentation on installation, configuration and modules.
Elastic Stack docs	Handbooks and API references for Elasticsearch, Filebeat and Logstash.
MITRE ATT&CK Framework	Global knowledge base of tactics and techniques used by cyber attackers.
OSSEC	Open-source HIDS basis on which the Wazuh architecture historically builds.
Suricata IDS	High-performance network threat detection and deep packet inspection.
ELK Stack	Central log-management and analysis platform from Elastic.
Wazuh Google Group	Official discussion forum for administrators and developers.
Wazuh GitHub repository	Source code, release branches, rulesets and issue tracker.
PCI DSS	Official security standard for protecting payment-card data.
GDPR	General Data Protection Regulation and requirements for incident logging.
HIPAA	US health-data protection standard for audit trails and access control.
CIS Benchmarks	Standardised hardening guides for operating systems and server services.
NIST Cybersecurity Framework	Guide for risk management, threat detection and incident response.
ISO 27001	International standard for information security management systems (ISMS).

Conclusion

Implementing Wazuh as a complete security platform requires deep technical understanding and careful planning. Wazuh provides capable tools for threat detection, compliance monitoring and incident response.

As IT infrastructures grow more complex and cyber threats increase, integrated security solutions such as Wazuh will matter even more. Future development is likely to lean more on AI-based analysis, cloud-native security and automated response mechanisms. Administrators and security teams should treat continuous training and adaptation of their security strategies as an essential part of the job.

👉 Overview: All DevOps articles