Skip to main content

​
Rule Management

Rules are the heart of CHAD. They define what security events to detect using the Sigma rule format.

​
Understanding Sigma Rules

Sigma is a generic signature format for SIEM systems. It’s vendor-agnostic, meaning rules written in Sigma can be translated to any backend. A basic Sigma rule: 
title: Failed Windows Login Attempt
status: test
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
  condition: selection
level: low
tags:
  - attack.credential_access
  - attack.t1110

​
The Rule Editor

CHAD provides a Monaco-based editor with:
  • Syntax highlighting for YAML
  • Schema validation against Sigma specification
  • Autocomplete for common fields
  • Error highlighting with helpful messages

​
Editor Features

FeatureShortcutDescription
FormatShift+Alt+FAuto-format YAML
FindCtrl+FSearch within rule
CommentCtrl+/Toggle line comment
AutocompleteCtrl+SpaceShow suggestions

​
Creating a Rule

  1. Navigate to Rules in the sidebar
  2. Click Create Rule
  3. Write your Sigma rule in the editor
  4. Click Validate to check for errors
  5. Click Save to store the rule (not yet detecting)
  6. Click Deploy to activate detection

​
Required Fields

Every rule needs: 
title: Descriptive name for the rule
logsource:
  product: windows  # or linux, network, etc.
  service: security # optional, depends on product
detection:
  selection:
    Field: Value
  condition: selection
level: low  # informational, low, medium, high, critical

​
Optional Fields

status: test  # experimental, test, stable
description: |
  Longer description of what this rule detects
  and why it matters.
references:
  - https://attack.mitre.org/techniques/T1110/
author: Your Name
date: 2024/01/15
tags:
  - attack.credential_access
  - attack.t1110.001
falsepositives:
  - Legitimate admin activity

​
Detection Logic

​
Selection Blocks

Selections define field conditions: 
detection:
  # Simple equality
  selection:
    EventID: 4625

  # Multiple values (OR)
  selection:
    EventID:
      - 4625
      - 4624

  # Multiple fields (AND)
  selection:
    EventID: 4688
    CommandLine|contains: 'mimikatz'

​
Modifiers

Modifiers change how values are matched:
ModifierDescriptionExample
containsSubstring matchCommandLine|contains: 'whoami'
startswithPrefix matchPath|startswith: 'C:\\Temp'
endswithSuffix matchFileName|endswith: '.exe'
reRegex matchCommandLine|re: '.*mimikatz.*'
allAll values must matchTags|all: ['admin', 'sensitive']

​
Conditions

Conditions combine selections: 
detection:
  selection1:
    EventID: 4688
  selection2:
    CommandLine|contains: 'powershell'
  filter:
    User: 'SYSTEM'

  # Logical combinations
  condition: selection1 and selection2 and not filter
Operators:
  • and - Both must match
  • or - Either must match
  • not - Must not match
  • 1 of selection* - Any selection matches
  • all of selection* - All selections match

​
Field Mapping

CHAD translates Sigma field names to your actual log field names using ECS (Elastic Common Schema) mappings. For example:
  • Sigma CommandLine → Your logs process.command_line
  • Sigma User → Your logs user.name
Configure mappings in Settings > Field Mappings.
Rules fail validation if fields don’t exist in your index mapping. Configure field mappings before deploying rules.

​
Testing Rules

Before deploying, test your rule:

​
Sample Log Test

  1. Click Test Rule in the editor
  2. Paste a sample log (JSON format)
  3. See if the rule would match
{
  "EventID": 4625,
  "User": "admin",
  "SourceIP": "192.168.1.100",
  "@timestamp": "2024-01-15T10:30:00Z"
}

​
Historical Test (Dry Run)

Test against real historical data:
  1. Click Historical Test
  2. Select time range (last hour, day, week)
  3. See matching documents without creating alerts
Historical testing helps estimate alert volume before deployment.

​
Deploying Rules

Deployment creates a percolator in OpenSearch that matches incoming logs in real-time.

​
Deploy a Single Rule

  1. Open the rule in the editor
  2. Click Deploy
  3. Rule status changes to “Deployed”

​
Bulk Deploy

  1. Go to Rules list
  2. Select multiple rules with checkboxes
  3. Click Bulk Actions > Deploy

​
Rule Status

StatusIconMeaning
Deployed🟢Actively detecting
Undeployed⚪Saved but not detecting
Snoozed💤Temporarily disabled

​
Version Control

Every save creates a new version. View history in the Activity panel:
  • See all previous versions
  • View diff between versions
  • One-click rollback to any version

​
Rollback

  1. Open the rule
  2. Click Activity panel
  3. Find the version to restore
  4. Click View Diff to compare
  5. Click Restore to rollback

​
Rule Snoozing

Temporarily disable a rule during maintenance:
  1. Open the rule
  2. Click Snooze
  3. Choose duration:
    • 1 hour to 168 hours (7 days)
    • Indefinite (until manually re-enabled)
Snoozed rules remain deployed but don’t generate notifications.

​
Best Practices

New rules should start as level: low until you understand false positive rates.
Always run historical tests to estimate alert volume.
Include what and why: “Mimikatz Execution via CommandLine” not “Suspicious Activity”.
Tags like attack.t1110 enable coverage mapping and help prioritization.
Use the falsepositives field to help analysts understand expected noise.

​
Next Steps

Exception Rules

Tune out false positives

SigmaHQ Import

Import community rules

Threshold Alerting

Count-based detections

Field Mappings

Configure field translation