🏛️ Architecture

Jibril's architecture represents a fundamental reimagining of how runtime security tools should work. By replacing traditional event streaming with query-driven data retrieval, Jibril eliminates the performance bottlenecks that plague conventional security monitoring.

🎯 The Core Innovation: Query-Driven eBPF

❌ Traditional Approach: Ring Buffers

Traditional security tools push events from kernel to userspace through ring buffers:

⚠️ Problems with this approach:

• 💥 Ring buffers overflow during high-event scenarios
• 📈 CPU usage spikes exponentially under load
• 🔀 Memory consumption becomes unpredictable
• ❗ Critical events get dropped when you need them most

✅ Jibril's Query-Driven Approach

Jibril's revolutionary approach stores events in kernel maps and retrieves them on demand:

🌟 Advantages:

• ✅ Zero event loss - maps don't overflow
• ⚡ Constant overhead - CPU usage stays flat
• 📊 Bounded memory - configurable, predictable usage
• 🚀 Better performance at scale - higher loads improve caching

💡 Learn more about eBPF maps: eBPF Map Types

🏗️ System Architecture

Jibril consists of three main layers working together seamlessly:

1️⃣ Kernel Space (eBPF Programs)

📡 Event Capture

eBPF programs attach to kernel hooks and capture system events in real-time:

• ⚙️ Process execution and lifecycle
• 📁 File access and modifications
• 🌐 Network connections and communication
• 📦 Container operations
• 🔐 Security-relevant system calls

💾 In-Kernel Storage

Events are stored in high-performance eBPF maps:

• 🗃️ Hash maps for event metadata and context
• 📊 Array maps for configuration and counters
• ♻️ LRU maps for automatic memory management
• 🔒 Cryptographic hashing ensures data integrity

🔄 Uniform Execution

eBPF programs run consistently across all kernel versions without modules or recompilation (thanks to CO-RE).

2️⃣ Userspace Daemon

🔍 Query Engine

The daemon periodically queries kernel maps to retrieve relevant events:

• 🎯 Selective data retrieval reduces overhead
• 📦 Batch processing optimizes performance
• ⏱️ Configurable query intervals balance latency and efficiency

🛡️ Detection Engine

Retrieved events are analyzed against detection rules:

• 🔎 Pattern matching identifies suspicious behavior
• 🧠 Contextual analysis reduces false positives
• 📈 Real-time threat scoring prioritizes alerts

🧩 Plugin System

Modular architecture organizes detection logic by event type:

• ⚙️ Execution plugins - Process and binary monitoring
• 📁 File access plugins - Filesystem operation tracking
• 🌐 Network plugins - Connection and traffic analysis
• 🔗 Thread-based isolation ensures stability and performance

3️⃣ Output Layer (Printers)

🚀 Flexible Routing

Events can be sent to multiple destinations simultaneously:

• 💻 Standard output (stdout) for debugging
• 📝 Log files for persistence
• 🔍 SIEM platforms for centralized monitoring
• 🔌 Custom APIs for integration
• 📊 Dashboards for visualization

🔐 Secure Transmission

All external communication uses authenticated HTTPS with API tokens.

👁️ What Jibril Monitors

Jibril provides comprehensive visibility into all system resources and operations.

📊 Resources Tracked

👤 Identity & Access

• 👥 Users and groups
• 🔑 Permissions and capabilities
• 🔐 Authentication events

🖥️ Infrastructure

• 💻 Physical and virtual machines
• 📦 Container hosts and nodes
• 🏷️ Hostnames and namespaces

💾 Storage

• 💿 Disks and filesystems
• 📂 Volumes and mount points
• 📄 Files and directories
• 🔗 Symbolic links

⚙️ Execution Context

• 📦 Containers and pods
• 🔄 Processes and threads
• 📋 Binary executables
• 📚 Shared libraries
• 🐍 Interpreters

🌐 Network

• 📡 Network protocols
• 🌍 Domain names and DNS
• 🔌 Ports and sockets
• 🌐 IP addresses
• 🔄 Network flows and peers

🎬 Actions Monitored

🔄 Lifecycle Events

• ➕ Create, destroy
• ▶️ Start, stop, restart
• 🔀 Fork, clone, exit

✏️ Modifications

• ✂️ Truncate, link, rename
• 📂 Open, close
• 🗂️ Mount, unmount
• 🏷️ Attribute changes

📝 Data Operations

• 📖 Read, write, seek
• ▶️ Execute
• 📋 Copy, move

🔧 Advanced Operations

• 🗺️ Memory mapping
• 🔄 Synchronization
• 🔒 Locking and unlocking
• 🎚️ Capability modifications

🔄 Execution Flow

Jibril follows a structured initialization and execution sequence:

🚀 Startup Sequence

1. 🔧 Initialization - Core libraries and system checks
2. 🐝 eBPF and Caches - eBPF programs loading and caches setup
3. 🧩 Components - Components initialization
4. 🔌 Features - Features initialization (Netpolicy, Alchemies, Detect, etc.)
5. 📤 Printers - Printers initialization (Stdout, Varlog, etc.)
6. 🔄 Main Loop - Main loop execution

All components follow: Init → Start → Execute → Finish → Exit in an hiearchy of components.

⚡ Runtime Operation

1. 📡 Event Capture - eBPF programs capture system events in kernel space
2. 💾 Storage - Events stored in eBPF maps with metadata and context
3. 🔍 Query - Daemon queries maps at configured intervals
4. 🛡️ Detection - Retrieved events analyzed against detection rules
5. 🎯 Action - Matching events trigger alerts or reactions
6. 📤 Output - Results sent to configured destinations

🔒 Data Immutability

Once captured, event data is immutable:

• ✅ Ensures forensic integrity
• 🛡️ Prevents tampering
• 📋 Creates trustworthy audit trails
• 🔍 Enables reliable investigation

⚡ Performance Characteristics

• A pre-defined cadence stipulates deterministic CPU behavior. CPU consumption is reduced with higher cadence values.

• Minimal CPU consumption can be obtained controlling cache size and cadence values. There is no security event processing loss.

📊 Deterministic Resource Usage

💻 CPU Consumption

• 📉 Constant overhead regardless of event volume
• ⚡ Typically less than 2% CPU even at 100,000+ events/second
• 🎯 No performance spikes during attacks or high activity

💾 Memory Usage

• 📦 Bounded, configurable memory footprint
• 📏 Predictable allocation based on map sizes
• ♻️ Automatic LRU eviction prevents unbounded growth

⏱️ Latency

• 🚀 Sub-second query response times
• ⚡ Immediate threat detection
• 👁️ Real-time event visibility

📈 Scaling Behavior

Traditional tools degrade under load. Jibril improves:

• 🎯 Higher event volumes create better cache hit ratios
• 📦 Batch processing becomes more efficient
• 🔄 Query-driven model naturally handles bursts
• ⚡ Kernel-space storage eliminates context-switching overhead

🚀 Jibril has been designed and tested on high workload environments.

🔐 Security Model

🛡️ Tamper-Proof Operation

🔒 Kernel-Level Enforcement

• 🚫 Cannot be bypassed from userspace
• 👑 Root processes cannot evade detection
• 📦 Container escapes are visible

✅ Verified Execution

• 🔍 eBPF verifier guarantees program safety
• 💚 No kernel crashes possible
• 🏖️ Sandboxed execution environment

📚 Learn more about eBPF security: eBPF Verifier

👁️ Comprehensive Coverage

🎯 No Blind Spots

• 🌐 System-wide monitoring
• 👀 All processes visible
• 📋 Complete event capture
• 🔍 Full context for every action

🛡️ Defense in Depth

• 🔄 Multiple detection mechanisms
• 🏗️ Layered security checks
• ♻️ Redundant event capture

🎨 Extensibility

🔧 Custom Detections

Jibril supports custom detection rules for organization-specific threats:

• 🔍 Pattern matching on events
• 🧠 Contextual analysis
• 🔗 Multi-event correlation
• 📊 Threat scoring

📖 Learn more: Customization

🤖 Reaction Engine

Automatically respond to detected threats with JavaScript-based reactions:

• 🚫 Block malicious processes
• 📦 Isolate compromised containers
• 📢 Alert security teams
• 🔧 Trigger automated remediation

⚡ Learn more: Reactions

🔌 Integration Points

Seamlessly integrate with existing security infrastructure:

• 🔍 SIEM platforms (Splunk, Elastic, etc.)
• 📢 Alert management (PagerDuty, Slack, etc.)
• 🎫 Ticketing systems (Jira, ServiceNow, etc.)
• 🔗 Custom APIs and webhooks

🚀 Deployment Modes

📦 Standalone

Single binary with no dependencies:

• ✅ Simple installation
• ⚙️ Minimal configuration
• 🚀 Quick deployment
• 🔄 Easy updates

📖 Standalone

⚙️ System Service

Run as a systemd service:

• 🔄 Automatic startup
• 👁️ Process supervision
• 📝 Log management
• 📊 Resource limits

📖 Systemd Service

🐳 Container

Deploy in containerized environments:

• 🐳 Docker container
• ☸️ Kubernetes DaemonSet
• ⎈ Helm chart
• 🔄 GitOps ready

📖 Kubernetes Deployment

⚙️ Configuration

Jibril uses a simple YAML configuration file:

cadences:
  file-access: 3 # File access cadence
  network-peers: 3 # Network peers cadence
  network-flows: 3 # Network flows cadence
  env-vars: 3 # Environment variables cadence

caches:
  rec-tasks: 32 # * 1k of recent tasks
  tasks: 64 # * 1k of tasks
  cmds: 32 # * 1k of commands
  args: 32 # * 1k of arguments
  files: 32 # * 1k of files
  dirs: 16 # * 1k of directories
  bases: 32 # * 1k of bases
  task-file: 32 # * 1k of task-file mapping
  file-task: 32 # * 1k of file-task mapping
  task-ref: 32 # * 1k of task-ref tracking
  flows: 32 # * 1k of network flows
  task-flow: 32 # * 1k of task-flow mapping
  flow-task: 32 # * 1k of flow-task mapping
  flow-ref: 32 # * 1k of flow-ref tracking

📖 Learn more: Configuration File

⚖️ Comparison with Traditional Architectures

Aspect	❌ Traditional Streaming	✅ Jibril Query-Driven
📊 Data Flow	Push (ring buffers)	Pull (on-demand)
💾 Memory	Unpredictable	Bounded & configurable
💻 CPU Overhead	Increases with load	Constant
📉 Event Loss	Common under stress	Impossible by design
⏱️ Latency	Variable, degrades	Consistent sub-second
📈 Scalability	Decreases with load	Increases with load