Rule Engine

🧩 InfraSight Sentinel — Rule Engine

InfraSight Sentinel is the rule based detection microservice within the InfraSight architecture. While the anomaly detection module focuses on unknown or unseen behaviors, Sentinel is designed to detect known attack signatures and policy violations by evaluating incoming syscall events against hardcoded and user defined rules.

🎯 Overview & Purpose

The main goal of InfraSight Sentinel is to identify known attack patterns or violations of predefined policies in real time. It receives syscall signature events from Kafka and evaluates them against a set of:

✅ Built in rules (for common attack signatures or security baselines)
🧩 User defined rules (custom YAML definitions, dynamically reloadable)

When a rule condition matches an incoming event, Sentinel triggers an alarm and logs the detection to standard output. This makes it a powerful complement to InfraSight’s anomaly detection, combining rule based and AI driven detection strategies.

⚙️ Architecture & Workflow

Sentinel runs as an independent microservice in the InfraSight ecosystem. Its workflow consists of the following stages:

Event Ingestion: Sentinel consumes serialized syscall signature events from Kafka. Each event type corresponds to a tracer from the eBPF Programs module (e.g., execve, open, connect).
Rule Loading:
- All hardcoded rules are loaded at startup.
- User defined rules are loaded from YAML files located in a configured rules directory.
- Sentinel supports hot reloading: any modification to rule files on disk automatically triggers an in memory update without restarting the service.
Evaluation: For each incoming event, Sentinel retrieves the list of active rules matching that event type and evaluates them against the event’s fields. The available fields for each event type can be found in the Database Schema section, which defines the structure and attributes emitted by each tracer.
Alerting: When a condition matches, Sentinel generates an alert that is logged to standard output.

🧱 Rule Definition Format

Rules are defined in YAML using a structured and expressive format that supports nested logic and subconditions. Below are examples illustrating how Sentinel rules are structured using YAML.

⚠️ Note: These examples are provided only for demonstration of rule syntax and logic nesting they are not real detection rules and should not be used in production without validation.

Condition Schema

type Condition struct {
    Field          string       `yaml:"field"`
    Operator       string       `yaml:"operator"`
    Value          string       `yaml:"value"`
    Logic          string       `yaml:"logic,omitempty"`
    Subconditions  []Condition  `yaml:"subconditions,omitempty"`
}

Rule Schema

type YAMLRule struct {
    RuleName    string      `yaml:"rule_name"`
    EventType   string      `yaml:"event_type"`
    Description string      `yaml:"description"`
    Logic       string      `yaml:"logic,omitempty"`
    Conditions  []Condition `yaml:"conditions"`
    Message     string      `yaml:"message"`
}

📜 Example Rule

Simple OR Rule

rules:
  - rule_name: "Root SSH Connection (Simple OR)"
    event_type: "connect"
    description: "Triggers when the user is root OR the destination port is 22"
    logic: "or"
    conditions:
      - field: "user"
        operator: "equals"
        value: "root"

      - field: "network.Dport"
        operator: "equals"
        value: "22"

    message: "Possible SSH connection or root activity detected"

This rule triggers an alert when:

The user field equals "root", or
The destination port (network.Dport) equals 22.

Complex Nested Logic Example

The rule logic can be expressed hierarchically using logic and subconditions fields to represent nested AND/OR combinations. This allows the user to define complex expressions that evaluate multiple layers of conditions.

rules:
  - rule_name: "Complex Network Behavior"
    event_type: "connect"
    description: "((Dport=22 OR Dport=23) AND (user=root OR comm contains ssh)) OR Daddrv4 contains 10.0.0."
    logic: "or"
    conditions:
      - logic: "and"
        subconditions:
          - logic: "or"
            subconditions:
              - field: "network.Dport"
                operator: "equals"
                value: "22"
              - field: "network.Dport"
                operator: "equals"
                value: "23"

          - logic: "or"
            subconditions:
              - field: "user"
                operator: "equals"
                value: "root"
              - field: "comm"
                operator: "contains"
                value: "ssh"

      - field: "network.Daddrv4"
        operator: "contains"
        value: "10.0.0."

    message: "Possible SSH/Telnet or internal network connection detected"

This example shows a multi-level logical structure:

The top-level logic is or, meaning either of the main branches can trigger the rule.
The first branch uses an AND group, containing two nested OR groups:
(Dport = 22 OR Dport = 23)
(user = root OR comm contains ssh)
The second branch checks if the destination IPv4 address contains "10.0.0.".

The final evaluated expression is equivalent to:

((Dport=22 OR Dport=23) AND (user=root OR comm contains ssh)) OR Daddrv4 contains 10.0.0.

This flexibility allows Sentinel to represent both simple and highly complex detection logic in YAML without requiring manual expression parsing by the user.

⚙️ Evaluation Logic

Sentinel constructs an expression tree from the rule’s logic and evaluates it dynamically at runtime.
Each rule can use logical operators like and or or, and can define nested subconditions for complex matching scenarios.
Fields within an event (e.g., user, filename, network.Dport) are referenced directly in the rule definition.

🔄 Dynamic Reloading

Sentinel features hot reloading of rule files:

When a YAML file is created, modified, or deleted in the rules directory, the service detects the change.
The new rules are validated to ensure syntax and schema correctness.
Once validated, they are reloaded into memory immediately, allowing real time updates without service restarts.

🚨 Alerting & Output

When a rule matches:

Sentinel logs an alert to standard output with details including:
Rule name
Event type
Matched condition(s)
Timestamp
Descriptive message