On this page

Security Platform Rollout

Security platform rollout establishes visibility into threats across organisational infrastructure through coordinated deployment of monitoring agents, log collection, and detection rules. This task covers implementation of Security Information and Event Management (SIEM) systems and Endpoint Detection and Response (EDR) platforms from initial deployment through operational handover.

The rollout sequence matters because security platforms generate substantial data volumes and alert traffic from the moment of activation. Uncontrolled deployment creates alert fatigue that undermines the platform’s value, while insufficient coverage leaves gaps attackers exploit. A staged approach builds coverage incrementally while tuning detection to organisational baselines.

Prerequisites

Complete these requirements before beginning deployment.

Requirement	Detail
Platform selection	SIEM and/or EDR platform selected and licensed; see Security and Monitoring Benchmarks
Sizing complete	Storage, compute, and network capacity calculated for expected log volume
Architecture approved	Deployment architecture documented including collector placement
Integration requirements	Target log sources identified with authentication credentials prepared
Network access	Firewall rules prepared for agent communication and log forwarding
Pilot group	20-50 endpoints identified for initial deployment
Monitoring team	Staff assigned for alert triage with time allocated
Runbook templates	Incident response procedures ready for customisation
Change approval	Change request approved per Change Management

Capacity Planning

Calculate storage requirements before deployment. SIEM platforms ingest logs at rates varying by source type.

Representative daily log volumes per source:

Source type	Events per day	Approximate size
Windows endpoint	50,000-200,000	100-400 MB
Domain controller	500,000-2,000,000	1-4 GB
Firewall	1,000,000-10,000,000	2-20 GB
Web proxy	500,000-5,000,000	1-10 GB
Email gateway	100,000-500,000	200 MB-1 GB
Cloud identity (Entra/Okta)	10,000-100,000	20-200 MB
Linux server	10,000-50,000	20-100 MB

For an organisation with 500 endpoints, 5 domain controllers, 2 firewalls, and standard cloud services, estimate 15-25 GB daily ingestion. Apply a 30% overhead for parsing expansion and metadata. With 90-day hot retention, provision 1.5-2.5 TB initial storage.

EDR platforms require 50-200 MB storage per endpoint for telemetry retention. The same 500-endpoint organisation needs 25-100 GB EDR storage depending on retention period and telemetry depth.

Procedure

Phase 1: Infrastructure Deployment

Deploy the core platform infrastructure before adding data sources or endpoints.

Deploy the SIEM platform following vendor documentation. For self-hosted deployments, install on dedicated infrastructure meeting the sizing calculations. For Wazuh, a representative single-node deployment:

   # Install Wazuh indexer (OpenSearch-based)
   curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
   chmod 744 wazuh-install.sh
   sudo ./wazuh-install.sh --wazuh-indexer node-1

   # Install Wazuh server
   sudo ./wazuh-install.sh --wazuh-server wazuh-1

   # Install Wazuh dashboard
   sudo ./wazuh-install.sh --wazuh-dashboard dashboard

For cloud-hosted SIEM (Graylog Cloud, Elastic Cloud), configure the tenant and note the ingestion endpoints.

Configure authentication integration. Connect the SIEM to your identity provider for analyst access:

   # Wazuh SAML configuration in /etc/wazuh-indexer/opensearch-security/config.yml
   authc:
     saml_auth_domain:
       http_enabled: true
       transport_enabled: false
       order: 1
       http_authenticator:
         type: saml
         challenge: true
         config:
           idp:
             metadata_url: https://login.microsoftonline.com/TENANT_ID/federationmetadata/2007-06/federationmetadata.xml
             entity_id: https://sts.windows.net/TENANT_ID/
           sp:
             entity_id: wazuh-saml
           kibana_url: https://siem.example.org
           roles_key: roles

Deploy log collectors in each network segment requiring monitoring. Collectors aggregate logs locally before forwarding to the central platform, reducing bandwidth and providing resilience during network interruptions.

   +----------------------------------------------------------+
   |                   SIEM ARCHITECTURE                      |
   +----------------------------------------------------------+
   |                                                          |
   |  +------------------+          +------------------+      |
   |  | HQ Network       |          | Field Office     |      |
   |  |                  |          |                  |      |
   |  | +-------------+  |          | +-------------+  |      |
   |  | | Collector   |  |          | | Collector   |  |      |
   |  | | (syslog)    |  |          | | (syslog)    |  |      |
   |  | +------+------+  |          | +------+------+  |      |
   |  |        |         |          |        |         |      |
   |  |  +-----+-----+   |          |  +-----+-----+   |      |
   |  |  | Firewall  |   |          |  | Switches  |   |      |
   |  |  | Switches  |   |          |  | APs       |   |      |
   |  |  | Servers   |   |          |  +-----------+   |      |
   |  |  +-----------+   |          |                  |      |
   |  +--------+---------+          +--------+---------+      |
   |           |                             |                |
   |           +-------------+---------------+                |
   |                         |                                |
   |                         v                                |
   |               +---------+----------+                     |
   |               |   SIEM Platform    |                     |
   |               |                    |                     |
   |               | +------+ +-------+ |                     |
   |               | |Index | |Rules  | |                     |
   |               | |Store | |Engine | |                     |
   |               | +------+ +-------+ |                     |
   |               +--------------------+                     |
   |                                                          |
   +----------------------------------------------------------+

Figure 1: Distributed collector architecture with central SIEM

Configure base retention policies. Set hot storage retention based on investigation needs and compliance requirements:

   {
     "policy": {
       "phases": {
         "hot": {
           "min_age": "0ms",
           "actions": {
             "rollover": {
               "max_size": "50gb",
               "max_age": "1d"
             }
           }
         },
         "warm": {
           "min_age": "7d",
           "actions": {
             "shrink": { "number_of_shards": 1 },
             "forcemerge": { "max_num_segments": 1 }
           }
         },
         "cold": {
           "min_age": "30d",
           "actions": {
             "freeze": {}
           }
         },
         "delete": {
           "min_age": "365d",
           "actions": {
             "delete": {}
           }
         }
       }
     }
   }

Verify platform health before proceeding. Confirm indexing functions, dashboards load, and authentication works:

   # Check cluster health (Wazuh/OpenSearch)
   curl -k -u admin:PASSWORD https://localhost:9200/_cluster/health?pretty

   # Expected output includes:
   # "status" : "green",
   # "number_of_nodes" : 1,

Phase 2: Log Source Integration

Integrate log sources systematically, starting with authentication and identity sources that provide the highest detection value.

Configure identity provider log forwarding. Authentication logs detect credential attacks, impossible travel, and account compromise. For Microsoft Entra ID:

   # Enable diagnostic settings via Azure CLI
   az monitor diagnostic-settings create \
     --name "SIEM-Integration" \
     --resource "/providers/Microsoft.aadiam/diagnosticSettings" \
     --logs '[{"category": "SignInLogs", "enabled": true},
              {"category": "AuditLogs", "enabled": true},
              {"category": "NonInteractiveUserSignInLogs", "enabled": true},
              {"category": "ServicePrincipalSignInLogs", "enabled": true},
              {"category": "ManagedIdentitySignInLogs", "enabled": true},
              {"category": "RiskyUsers", "enabled": true},
              {"category": "UserRiskEvents", "enabled": true}]' \
     --event-hub-rule "/subscriptions/SUB_ID/resourceGroups/RG/providers/Microsoft.EventHub/namespaces/NAMESPACE/authorizationRules/RootManageSharedAccessKey" \
     --event-hub "siem-logs"

For Okta, configure the System Log API integration or event hook:

   {
     "name": "SIEM Log Streaming",
     "events": {
       "type": "EVENT_TYPE",
       "items": [
         "user.session.start",
         "user.session.end",
         "user.authentication.auth_via_mfa",
         "user.authentication.sso",
         "user.account.lock",
         "policy.evaluate_sign_on"
       ]
     },
     "channel": {
       "type": "HTTP",
       "version": "1.0.0",
       "config": {
         "uri": "https://siem.example.org/api/v1/okta",
         "headers": {
           "Authorization": "Bearer ${api_token}"
         }
       }
     }
   }

Configure network perimeter logging. Firewalls and proxies reveal external threats and data exfiltration attempts. Enable syslog forwarding to the local collector:

   # Fortinet FortiGate syslog configuration
   config log syslogd setting
     set status enable
     set server "10.0.1.50"
     set port 514
     set facility local7
     set source-ip "10.0.1.1"
     set format rfc5424
   end

   config log syslogd filter
     set severity information
     set forward-traffic enable
     set local-traffic enable
     set multicast-traffic enable
     set sniffer-traffic enable
     set anomaly enable
     set voip enable
   end

Integrate cloud platform logs. Cloud control plane events detect configuration changes and suspicious administrative activity:

   # AWS CloudTrail to SIEM via S3 and Lambda
   # Create S3 bucket for CloudTrail
   aws s3 mb s3://org-cloudtrail-logs --region eu-west-2

   # Enable CloudTrail
   aws cloudtrail create-trail \
     --name organisation-trail \
     --s3-bucket-name org-cloudtrail-logs \
     --is-multi-region-trail \
     --enable-log-file-validation

   aws cloudtrail start-logging --name organisation-trail

For Azure, enable Activity Log export:

   az monitor log-analytics workspace create \
     --resource-group security-rg \
     --workspace-name siem-workspace \
     --location uksouth

   az monitor diagnostic-settings subscription create \
     --name "Activity-to-SIEM" \
     --subscription SUB_ID \
     --logs '[{"category": "Administrative", "enabled": true},
              {"category": "Security", "enabled": true},
              {"category": "Policy", "enabled": true}]' \
     --workspace "/subscriptions/SUB_ID/resourcegroups/security-rg/providers/microsoft.operationalinsights/workspaces/siem-workspace"

Configure endpoint logging for servers. Windows Security event logs and Linux auditd provide host-level visibility:

   <!-- Windows Event Forwarding subscription for security events -->
   <Subscription xmlns="http://schemas.microsoft.com/2006/03/windows/events/subscription">
     <SubscriptionId>Security-Events</SubscriptionId>
     <SubscriptionType>SourceInitiated</SubscriptionType>
     <Description>Security events from all servers</Description>
     <Enabled>true</Enabled>
     <Uri>http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog</Uri>
     <ConfigurationMode>Custom</ConfigurationMode>
     <Query>
       <![CDATA[
         <QueryList>
           <Query Id="0" Path="Security">
             <Select Path="Security">*[System[(EventID=4624 or EventID=4625 or EventID=4648 or EventID=4672 or EventID=4688 or EventID=4697 or EventID=4698 or EventID=4720 or EventID=4728 or EventID=4732 or EventID=4756 or EventID=1102)]]</Select>
           </Query>
         </QueryList>
       ]]>
     </Query>
     <ReadExistingEvents>false</ReadExistingEvents>
     <TransportName>HTTP</TransportName>
     <Delivery mode="Push">
       <Batching>
         <MaxItems>10</MaxItems>
         <MaxLatencyTime>60000</MaxLatencyTime>
       </Batching>
     </Delivery>
   </Subscription>

For Linux servers, configure auditd rules and rsyslog forwarding:

   # Monitor authentication
   -w /var/log/faillog -p wa -k auth
   -w /var/log/lastlog -p wa -k auth

   # Monitor privileged commands
   -a always,exit -F arch=b64 -S execve -F euid=0 -k privileged

   # Monitor file changes
   -w /etc/passwd -p wa -k identity
   -w /etc/shadow -p wa -k identity
   -w /etc/sudoers -p wa -k privileged

   # Apply rules
   sudo augenrules --load

Validate log ingestion for each source. Query the SIEM to confirm events arrive within expected latency:

   # Wazuh API query for recent events by source
   curl -k -X GET "https://localhost:55000/events?limit=10&q=agent.name=dc01" \
     -H "Authorization: Bearer $TOKEN"

Expected ingestion latency: under 60 seconds for real-time sources, under 15 minutes for batch sources.

Log volume monitoring

Monitor ingestion rates during integration. A misconfigured source can generate 10-100x expected volume, exhausting storage and licence allocations within hours. Set ingestion rate alerts at 150% of baseline before enabling new sources.

Phase 3: EDR Agent Deployment

Deploy EDR agents in stages to control the change scope and identify compatibility issues before full rollout.

Prepare deployment packages. Download agents and create configuration profiles for your environment:

   # Wazuh agent silent installation package (Windows)
   wazuh-agent-4.7.0-1.msi /q WAZUH_MANAGER="siem.example.org" \
     WAZUH_REGISTRATION_SERVER="siem.example.org" \
     WAZUH_AGENT_GROUP="windows-endpoints"

   # Linux agent installation
   curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg --dearmor -o /usr/share/keyrings/wazuh.gpg
   echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" > /etc/apt/sources.list.d/wazuh.list
   apt update && apt install wazuh-agent

   # Configure agent
   sed -i 's/MANAGER_IP/siem.example.org/' /var/ossec/etc/ossec.conf
   systemctl enable wazuh-agent && systemctl start wazuh-agent

Deploy to the pilot group. Select 20-50 endpoints representing different hardware, operating systems, and use patterns. Include at least one device from each category: standard workstation, developer workstation, server, laptop used for travel, shared device.
For deployment via MDM (Intune example):

   <!-- Intune Win32 app detection rule -->
   <Detection>
     <File>
       <Path>C:\Program Files (x86)\ossec-agent</Path>
       <FileOrFolder>ossec-agent.exe</FileOrFolder>
       <DetectionType>Exists</DetectionType>
     </File>
   </Detection>

Monitor pilot deployment for 5-7 days. Track agent health, resource consumption, and user impact:

Metric	Threshold	Action if exceeded
CPU usage (agent)	5% sustained	Adjust scan schedules
Memory usage	150 MB	Check for memory leak, update agent
Network bandwidth	10 MB/hour	Reduce telemetry verbosity
User complaints	Any	Investigate and resolve before expansion

Expand deployment in phases. Roll out to 25% of endpoints, monitor for 3-5 days, then proceed to 50%, 75%, and full deployment:

   +-------------------------------------------------------------------+
   |                       EDR ROLLOUT TIMELINE                        |
   +-------------------------------------------------------------------+
   |                                                                   |
   |  Week 1        Week 2        Week 3        Week 4        Week 5   |
   |    |             |             |             |             |      |
   |    v             v             v             v             v      |
   | +------+     +-------+     +-------+     +-------+     +-------+  |
   | |Pilot |     | 25%   |     | 50%   |     | 75%   |     | 100%  |  |
   | |20-50 |     | ~125  |     | ~250  |     | ~375  |     | ~500  |  |
   | +------+     +-------+     +-------+     +-------+     +-------+  |
   |    |             |             |             |             |      |
   |    +------+------+------+------+------+------+------+------+      |
   |           |             |             |             |             |
   |        Monitor       Monitor       Monitor       Monitor          |
   |        3-5 days      3-5 days      3-5 days      ongoing          |
   |                                                                   |
   +-------------------------------------------------------------------+

Figure 2: Staged EDR deployment timeline for 500-endpoint organisation

Verify agent coverage reaches target. Query the platform for enrolled agents and identify gaps:

   # List agents by status
   curl -k -X GET "https://localhost:55000/agents?status=active&limit=500" \
     -H "Authorization: Bearer $TOKEN" | jq '.data.affected_items | length'

   # Identify missing endpoints
   # Compare agent list against asset inventory from CMDB

Phase 4: Detection Rule Configuration

Configure detection rules after establishing baseline telemetry. Rules deployed too early generate excessive false positives from unknown-normal activity.

Enable built-in rule sets appropriate to your environment. Most platforms ship with hundreds of pre-built detections:

   # Wazuh ruleset activation in /var/ossec/etc/ossec.conf
   <ruleset>
     <decoder_dir>ruleset/decoders</decoder_dir>
     <rule_dir>ruleset/rules</rule_dir>
     <rule_exclude>0215-policy_rules.xml</rule_exclude>
     <list>etc/lists/audit-keys</list>
     <list>etc/lists/amazon/aws-eventnames</list>
     <list>etc/lists/security-eventchannel</list>
   </ruleset>

Start with high-fidelity rules that rarely produce false positives:

Rule category	Example detections	Expected false positive rate
Known malware hashes	Commodity malware execution	Under 1%
Credential dumping	LSASS access, mimikatz patterns	2-5%
Persistence mechanisms	Scheduled task creation, service install	5-15%
Lateral movement	PsExec, WMI remote execution	10-20%
Data exfiltration	Large outbound transfers, archive creation	15-30%

Establish baseline alert volume. Run rules in alert-only mode (no automated response) for 2 weeks to measure normal alert generation:

   Week 1-2 baseline measurement (500 endpoints):

   Critical alerts:   2-5 per day    (investigate all)
   High alerts:       10-30 per day  (investigate all)
   Medium alerts:     50-200 per day (sample 20%)
   Low alerts:        200-500 per day (review weekly)

   Total analyst time required: 4-8 hours per day

If alert volumes exceed analyst capacity, proceed to tuning before enabling additional rules.

Tune rules to reduce false positives. Create exceptions for known-good activity:

   <!-- Wazuh custom rule to exclude known backup software -->
   <rule id="100001" level="0">
     <if_sid>61138</if_sid>
     <field name="win.eventdata.image">C:\\Program Files\\Veeam</field>
     <description>Ignore Veeam backup file access</description>
   </rule>

   <!-- Exclude IT admin tools from suspicious execution -->
   <rule id="100002" level="0">
     <if_sid>92052</if_sid>
     <field name="win.eventdata.user">DOMAIN\\svc-admin</field>
     <field name="win.eventdata.commandLine">psexec.exe</field>
     <description>Ignore PsExec usage by admin service account</description>
   </rule>

Configure alert severity and routing. Map detection categories to response priorities:

   +-----------------------------------------------------------+
   |                    ALERT ROUTING FLOW                     |
   +-----------------------------------------------------------+
   |                                                           |
   |  Detection    Severity     Response        Notification   |
   |  fires        assigned     time            channel        |
   |     |            |            |                |          |
   |     v            v            v                v          |
   |  +------+    +--------+    +--------+    +-----------+    |
   |  |Rule  |--->|Critical|--->|15 min  |--->|Page + SMS |    |
   |  |engine|    +--------+    +--------+    +-----------+    |
   |  |      |                                                 |
   |  |      |    +--------+    +--------+    +-----------+    |
   |  |      |--->| High   |--->|1 hour  |--->|Email+Slack|    |
   |  |      |    +--------+    +--------+    +-----------+    |
   |  |      |                                                 |
   |  |      |    +--------+    +--------+    +-----------+    |
   |  |      |--->| Medium |--->|8 hours |--->|Dashboard  |    |
   |  |      |    +--------+    +--------+    +-----------+    |
   |  |      |                                                 |
   |  |      |    +--------+    +--------+    +-----------+    |
   |  |      |--->| Low    |--->|24 hours|--->|Weekly     |    |
   |  +------+    +--------+    +--------+    |report     |    |
   |                                          +-----------+    |
   +-----------------------------------------------------------+

Figure 3: Alert severity routing and notification channels

Create custom rules for organisation-specific threats. Develop detections for scenarios relevant to your operating context:

   <!-- Detect access to protection/safeguarding data outside business hours -->
   <rule id="100100" level="12">
     <if_group>windows_security</if_group>
     <field name="win.eventdata.objectName">\\\\fileserver\\protection</field>
     <time>8 pm - 6 am</time>
     <description>After-hours access to protection data folder</description>
     <group>protection_data,policy_violation</group>
   </rule>

   <!-- Detect bulk download from case management system -->
   <rule id="100101" level="10">
     <if_sid>86601</if_sid>
     <field name="data.url">^https://casemgmt.example.org/api/export</field>
     <frequency>5</frequency>
     <timeframe>300</timeframe>
     <description>Multiple case exports within 5 minutes</description>
     <group>data_exfiltration,case_management</group>
   </rule>

Phase 5: Operational Handover

Prepare the monitoring team to operate the platform independently.

Develop runbooks for each alert type. Document investigation steps, escalation criteria, and resolution procedures. Use the template structure:

   ## Alert: Credential Dumping Detected

   ### Severity: Critical
   ### Response time: 15 minutes

   ### Initial triage
   1. Verify alert is not false positive (check exclusion list)
   2. Identify affected endpoint and user
   3. Check user's recent activity for anomalies

   ### Investigation
   1. Query SIEM for related events in 1-hour window
   2. Check for lateral movement indicators
   3. Review user's authentication patterns

   ### Containment
   1. Isolate endpoint from network
   2. Disable user account
   3. Revoke active sessions

   ### Escalation
   - If credentials confirmed compromised: Invoke Account Compromise playbook
   - If multiple endpoints affected: Invoke Incident Commander

Train analysts on platform operation. Cover these competencies over 2-3 days:

Session	Duration	Content
Platform navigation	2 hours	Dashboard, search, filtering
Alert triage	4 hours	Investigation workflow, severity assessment
Query language	4 hours	Search syntax, building queries
Runbook execution	4 hours	Step-through of common scenarios
Escalation procedures	2 hours	When and how to escalate

Establish alert review cadence. Define the rhythm for ongoing operations:
- Critical/high alerts: Triage within response SLA
- Daily alert review: 30-minute standup to review previous 24 hours
- Weekly tuning review: 1-hour session to identify false positive patterns
- Monthly metrics review: Coverage, alert trends, analyst workload
Configure dashboards for operational visibility:

   {
     "dashboard": "Security Operations Overview",
     "panels": [
       {
         "title": "Alert Volume (24h)",
         "type": "metric",
         "query": "count() where timestamp > now() - 24h"
       },
       {
         "title": "Alerts by Severity",
         "type": "pie",
         "query": "count() by severity where timestamp > now() - 24h"
       },
       {
         "title": "Mean Time to Acknowledge",
         "type": "metric",
         "query": "avg(acknowledged_at - created_at) where status='acknowledged'"
       },
       {
         "title": "Agent Coverage",
         "type": "gauge",
         "query": "count(distinct agent_id) / 500 * 100"
       },
       {
         "title": "Top Alert Sources",
         "type": "table",
         "query": "count() by rule_name | top 10"
       }
     ]
   }

Document the deployment for future maintenance. Create records including:
- Architecture diagram with all components
- Log source inventory with configuration details
- Custom rule documentation
- Tuning decisions and rationale
- Runbook library location
- Escalation contacts

Verification

Confirm deployment success against these criteria.

Coverage verification:

# Count active agents versus target
ACTIVE_AGENTS=$(curl -sk "https://siem:55000/agents?status=active" \
  -H "Authorization: Bearer $TOKEN" | jq '.data.total_affected_items')
TARGET=500
COVERAGE=$(echo "scale=2; $ACTIVE_AGENTS / $TARGET * 100" | bc)
echo "Agent coverage: $COVERAGE%"
# Target: 95% or higher

Log source verification:

# Check each log source received events in last hour
for source in entra-id okta firewall cloudtrail; do
  COUNT=$(curl -sk "https://siem:9200/wazuh-alerts-*/_count" \
    -H "Content-Type: application/json" \
    -d "{\"query\":{\"bool\":{\"must\":[{\"range\":{\"@timestamp\":{\"gte\":\"now-1h\"}}},{\"match\":{\"data.source\":\"$source\"}}]}}}" \
    | jq '.count')
  echo "$source: $COUNT events (last hour)"
done

Expected output shows non-zero counts for all configured sources.

Alert functionality verification:

Generate a test alert using a benign trigger:

# Trigger EICAR test file detection (Windows endpoint with AV)
$eicar = 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'
[System.IO.File]::WriteAllText("C:\temp\eicar.txt", $eicar)
# Alert should appear in SIEM within 60 seconds

Analyst capability verification:

Analyst can log into platform using SSO
Analyst can execute saved queries
Analyst can acknowledge and close alerts
Analyst can locate and follow runbooks

Troubleshooting

Symptom	Cause	Resolution
Agent fails to connect	Firewall blocking agent communication	Open outbound TCP 1514-1515 to SIEM server
Agent shows disconnected status	Agent service stopped or crashed	Check service status: `systemctl status wazuh-agent`; review agent logs at `/var/ossec/logs/ossec.log`
No events from Windows endpoint	Windows Event Forwarding misconfigured	Verify WEF subscription active: `wecutil gs Security-Events`
Log source shows zero ingestion	Authentication failure to log source	Verify credentials; check SIEM connector logs
Ingestion rate exceeds licence	Verbose logging enabled on high-volume source	Reduce log level; filter events at source
Alerts not appearing	Rules not enabled or syntax error	Verify rule file loaded: `cat /var/ossec/logs/ossec.log
High false positive rate	Rules not tuned to environment	Create exclusions for known-good activity; see Phase 4 step 3
Alert storms overwhelming analysts	Single noisy rule or infrastructure issue	Identify rule generating most alerts; add rate limiting or exclusion
Dashboard shows stale data	Index pattern not refreshing	Refresh index pattern in Kibana; verify indexer health
Search queries timeout	Index too large or under-resourced	Increase indexer resources; implement index lifecycle management
Agent consuming high CPU	Full scan running or malware present	Check scan schedules; investigate if malware detected
Agent installation fails silently	Insufficient permissions or conflicts	Run installer with logging: `msiexec /i agent.msi /l*v install.log`
Linux auditd events missing	auditd rules not loaded	Verify rules: `auditctl -l`; check audit.log for errors
Cloud logs delayed	API rate limiting or batch job scheduling	Check cloud provider status; verify diagnostic settings
Custom rules not triggering	Rule syntax error or wrong log format	Test rule against sample events; verify field names match actual data

Rollback

If deployment causes operational issues, rollback in reverse order.

To remove EDR agents:

# Windows
msiexec /x {package-guid} /qn

# Linux
apt remove wazuh-agent
# or
yum remove wazuh-agent

To disable log forwarding, reverse the configuration changes at each source. For SIEM infrastructure, snapshot virtual machines before deployment to enable rapid rollback.