Performance and Integration

Monitoring Alert Performance

Navigation: ELS Console → SIEM → Alert Rules

Check:

  • Processing time.

  • Last run status.

  • Total alerts generated.

Troubleshooting Alert Rules

Alerts Not Firing

Diagnostic steps:

  1. Check rule syntax - Verify YAML rule definition syntax.

  2. Test with smaller dataset - Use Discover to test query logic.

  3. Verify index patterns - Ensure data exists in specified indices.

  4. Check time ranges - Confirm events fall within detection window.

  5. Review logs - Check ELS logs for processing errors.

High False Positive Rate

Solutions:

  1. Tune alert thresholds - Increase event counts or severity levels.

  2. Add exclusions - Filter out known good activities.

  3. Refine time windows - Adjust detection time frames.

  4. Use risk scoring - Focus on high-risk events only.

Integration with Other Modules

The SIEM module works with data collected by the Network Probe, which provides network monitoring, IDS/IPS, and NetFlow analysis capabilities.

External System Integration

UI Notification

  • Email: Sends information about an alert to defined email addresses.

email:
  smtp_host: "smtp.company.com"
  smtp_port: 587
  recipients: ["soc-team@company.com"]
  subject: "SECURITY ALERT: {alert_name}"
  html_body: true
  attach_logserver-gui_discover_url: true

  • User: Sends information about an alert to defined system users.

  • Command: Performs system tasks, e.g., triggers a script to create a new event in the customer ticket system.

Example of an alert rule definition using the “command” alert method:

index: op5-*
name: change-op5-hoststate
type: change

compare_key: hoststate
ignore_null: true
query_key: hostname

filter:
- query_string:
    query: "_exists_: hoststate AND datatype: \"HOSTPERFDATA\" AND _exists_: hostname"

realert:
  minutes: 0
alert: "command"
command: ["/opt/alert/send_request_change.sh", "5", "%(hostname)s", "SYSTEM_DOWN", "HOST", "Application Collection", "%(hoststate)s", "%(@timestamp)s"]

  • The Hive: Creates an Incident in The Hive.

Configuration:

  1. Edit /opt/alert/config.yaml:

hive_host: https://127.0.0.1/base
hive_apikey: APIKEY

  1. Rule definition options:

    • Alert type: Type of alert (alert or Case)

    • Follow: If enabled, updates set status to Updated and update related case.

    • Title: The title of alert.

    • Description: Description of the alert.

    • Type: The type of the alert.

    • Source: The source of the alert.

    • Status: The status of the alert (New, Ignored, Updated, Imported).

    • Severity: The severity of alert (low, medium, high, critical).

    • TLP: The Traffic Light Protocol (white, green, amber, red).

    • Tags: Tags attached to alert.

    • Observable data mapping: Key and value observable data mapping.

    • Alert text: Text content of the alert.

  • RSA Archer: Forwards alert information to RSA Archer via Command alert method.

Configuration steps:

  1. Save scripts to /opt/alert/bin:

    • ucf.sh (SYSLOG):

#!/usr/bin/env bash
base_url="http://localhost/Archer" ##set the appropriate Archer URL

logger -n $base_url -t logger -p daemon.alert -T "CEF:0|LogServer|LogServer|${19}|${18}| TimeStamp=$1 DeviceVendor/Product=$2-$3 Message=$4 TransportProtocol=$5 Aggregated:$6 AttackerAddress=$7 AttackerMAC=$8 AttackerPort=$9 TargetMACAddress=${10} TargetPort=${11} TargetAddress=${12} FlexString1=${13} Link=${14} ${15} $1 ${16} $7 ${17}"

  • ucf2.sh (REST API):

#!/usr/bin/env bash
base_url="http://localhost/Archer" ##set the appropriate Archer URL
instance_name="Archer"
username="apiuser"
password="Archer"

curl -k -u $username:$password -H "Content-Type: application/xml" -X POST "$base_url:50105/$instance_name" -d {
"CEF":"0","Server":"LogServer","Version":"${19}","NameEvent":"${18}","TimeStamp":"$1","DeviceVendor/Product":"$2-$3","Message":"$4","TransportProtocol":"$5","Aggregated":"$6","AttackerAddress":"$7","AttackerMAC":"$8","AttackerPort":"$9","TargetMACAddress":"${10}","TargetPort":"${11}","TargetAddress":"${12}","FlexString1":"${13}","Link":"${14}","EventID":"${15}","EventTime":"${16}","RawEvent":"${17}"
}

  1. Alert rule definition:

index: alert*
name: alert-sent-to-rsa
type: any

filter:
- query:
    query_string:
      query: "_exists_: endTime AND _exists_: deviceVendor AND _exists_: deviceProduct AND _exists_: message AND _exists_: transportProtocol AND _exists_: correlatedEventCount AND _exists_: attackerAddress AND _exists_: attackerMacAddress AND _exists_: attackerPort AND _exists_: targetMacAddress AND _exists_: targetPort AND _exists_: targetAddress AND _exists_: flexString1 AND _exists_: deviceCustomString4 AND _exists_: eventId AND _exists_: applicationProtocol AND _exists_: rawEvent"

include:
- endTime
- deviceVendor
- deviceProduct
- message
- transportProtocol
- correlatedEventCount
- attackerAddress
- attackerMacAddress
- attackerPort
- targetMacAddress
- targetPort
- targetAddress
- flexString1
- deviceCustomString4
- eventId
- applicationProtocol
- rawEvent

realert:
  minutes: 0

  • Alert Method: command

  • Path to script/command: /opt/alert/bin/ucf.sh

  • Jira: Opens a ticket on Jira when an alert is triggered.

Configuration steps:

  1. Create /opt/alert/jira_acct.yaml:

user: user.example.com
password: IjP0vVhgrjkotElFf4ig03g6

  1. Edit /opt/alert/config.yaml:

jira_account_file: "/opt/alert/jira_acct.yaml"
jira_server: "https://example.atlassian.net"

  1. Rule definition options:

    • Required:

      • project: The name of the Jira project.

      • issue type: The type of Jira issue.

    • Optional:

      • Components: Component(s) to set the ticket to.

      • Labels: Label(s) to set the ticket to.

      • Watchers: User ID(s) to add as watchers.

      • Priority: Issue priority (Lowest, Low, Medium, High, Highest).

      • Bump tickets: If true, comments on existing tickets newer than max_age.

      • Bump Only: Skips ticket creation if no ticket to bump.

      • Bump in statuses: Statuses for commenting instead of new ticket.

      • Ignore in title: Removes value from Jira subject when searching.

      • Max age: Maximum ticket age for bumping (default: 30 days).

      • Bump not in statuses: Statuses to exclude for bumping.

      • Bump after inactivity: Comments only on inactive tickets (default: 0 days).

      • Transition to: Transitions ticket to given status when bumping.

  • Webhook Connector: Sends POST or PUT request to a web service.

  • URL: Host of application or web application.

  • Username: Username used to send alert.

  • Password: Password of the username.

  • Proxy address: Proxy address.

  • Headers: Request headers.

  • Static Payload: Static payload of the request.

  • Payload: Payload of the request.

To enable https, add to /opt/alert/config.yaml:

webhook_verify_ssl: true
webhook_ca: /etc/logserver/ssl/rootCA.crt
webhook_cert: /etc/logserver/ssl/clientCert.crt
webhook_key: /etc/logserver/ssl/clientKey.key

  • Slack: Sends notification to a predefined Slack channel.

  • Webhook URL: URL with auth data and channel ID (from Slack’s Incoming Webhooks).

  • Username: Username or email address in Slack.

  • Slack channel: Channel name (default if empty).

  • Message Color: Message color (default: ‘danger’).

  • Message Title: Title of the Slack message.

  • ServiceNow: Creates a new Incident in ServiceNow.

Configuration steps:

  1. Create /opt/alert/servicenow_auth_file.yml:

servicenow_rest_url: https://dev123.service-now.com/api/now/v1/table/incident
username: exampleUser
password: exampleUserPassword

  • Short Description: Incident description.

  • Comments: Work notes or comments.

  • Assignment Group: Group to assign the incident.

  • Category: Incident category (must exist).

  • Subcategory: Incident subcategory (must exist).

  • CMDB CI: Configuration item to link.

  • Caller Id: Caller’s email address.

  • Proxy: Proxy address if needed.

  • EnergySoar: Creates a new Incident in Energy Soar.

Configuration:

  1. Edit /opt/alert/config.yaml:

hive_host: https://127.0.0.1/base
hive_apikey: APIKEY

  1. Rule definition options:

    • Alert type: Type of alert (alert or Case).

    • Follow: Updates status to Updated and related case if enabled.

    • Title: Alert title.

    • Description: Alert description.

    • Type: Alert type.

    • Source: Alert source.

    • Status: Alert status (New, Ignored, Updated, Imported).

    • Severity: Alert severity (low, medium, high, critical).

    • TLP: Traffic Light Protocol (white, green, amber, red).

    • Tags: Tags attached to alert.

    • Observable data mapping: Key and value mapping.

    • Alert text: Alert content text.

Definition-based Notification

  • Microsoft Teams Alerts

Required settings:

  • ms_teams_webhook_url: Webhook endpoint with authentication and channel ID (from Teams → Connectors → Incoming Webhook).

  • ms_teams_alert_summary: Short summary (may not display in current Teams version).

Optional settings:

  • ms_teams_theme_color: HEX color code for alert border (e.g., #ff0000 for red).

  • ms_teams_proxy: Proxy in hostname:port format if needed.

  • Telegram Alerts

Required settings:

  • telegram_bot_token: Authorization token (e.g., 110201543:AAHdqTcvCH1vGWJxfSeofSAs0K5PALDsaw) from BotFather.

  • telegram_room_id: Chat or channel ID (e.g., -xxxxxxxx).

Optional settings:

  • telegram_api_url: Custom Telegram Bot API domain (default: api.telegram.org).

  • telegram_proxy: Proxy in hostname:port format if needed.

  • Google Chat Alerts

Required settings:

  • googlechat_webhook_url: Webhook endpoint (from Google Chat → Configure Webhooks).

Optional settings:

  • googlechat_format: Notification layout (basic or card).

  • googlechat_header_title: Header title for card format.

  • googlechat_header_subtitle: Header subtitle for card format.

  • googlechat_header_image: URL to image/icon for card header.

  • googlechat_footer_logserver-guilink: URL to Energy Logserver UI for card footer.

Wazuh Agent Configuration

Energy Logserver integrates with Wazuh to provide endpoint detection capabilities. The following Wazuh features are available when the SIEM Plan is active:

  • File Integrity Monitoring (FIM) — monitors file system changes on monitored endpoints. Results are visible in the SIEM → FIM dashboard.

  • Log Data Collection — collects logs from endpoints, applications, and system sources via the Wazuh agent. Collected data is forwarded to the Energy Logserver Data Node.

  • Active Response — automatically executes response actions on endpoints when alert conditions are met (e.g., blocking IPs via firewall rules).

  • Vulnerability Detection — scans endpoints for known vulnerabilities. Results are visible in the SIEM → Vulnerability dashboard.

Configuration of these features is performed in the Wazuh agent configuration file (ossec.conf) on each monitored endpoint. For detailed configuration reference, see the official Wazuh documentation:

VirusTotal Integration

Energy Logserver supports VirusTotal file scanning through the Wazuh Integrator module. When FIM detects a new or modified file, the Wazuh agent can submit the file hash to the VirusTotal API for malware analysis. Results are forwarded as alerts to the Energy Logserver Data Node.

Configuration is performed in ossec.conf on the Wazuh manager. For configuration reference, see: Wazuh VirusTotal integration

Custom Integrations

The Wazuh Integrator module supports custom integrations with external services using scripts triggered by alert conditions. This can be used to forward alerts to ticketing systems, messaging platforms, or custom APIs.

For configuration reference, see: Wazuh Integrator