CENTINELA Security Suite

1. Abstract & Motivation

Modern infrastructure security solutions are dominated by closed-source, vendor-locked black boxes that operate on trust — trust in the vendor, trust in the update pipeline, and trust in the data handling policies of third parties. The ORZ Holdings identified this as a systemic vulnerability for any ecosystem that claims to value sovereignty.

CENTINELA (Spanish: sentinel, watchman) is Orzatty's answer: a fully open, institutionally controlled security engine written from scratch in Rust. It operates as the first-class security layer for OrzattyOS, OrzattyCloud, and all services communicating over the Orzatty Protocol mesh. It provides:

• Kernel-level threat detection and enforcement via system call interception
• Network flow analysis with stateful tracking and anomaly detection
• Military-grade cryptographic primitives in a no_std embedded-ready crate
• MITRE ATT&CK-aligned threat classification with automated countermeasures
• Four security levels: Development → Production → Enhanced → Military

2. System Architecture: 7-Crate Workspace

CENTINELA is structured as a Rust Cargo workspace with 7 specialized crates, each with a single responsibility. This separation enables independent testing, versioning, and deployment of each layer.

Build Configuration

The workspace is configured for maximum performance and minimum attack surface in production:

[profile.release]
opt-level    = 3        # Full LLVM optimization
lto          = true     # Link-Time Optimization across crates
codegen-units = 1       # Single codegen unit for maximum LTO effectiveness
panic        = "abort"  # No unwinding — deterministic behavior in security code

The panic = "abort" setting is critical for security code: unwinding-based panics can leave the system in an inconsistent state that an attacker may exploit. Aborting immediately ensures the system fails closed.

Async Runtime

All I/O-bound components (network monitoring, gateway filtering, event processing) use the tokio async runtime with features = ["full"]. This provides:

• Non-blocking packet inspection without thread starvation
• Concurrent processing of multiple threat classification streams
• Structured concurrency with task cancellation for shutdown safety

3. Cryptographic Engine: ChaCha20-Inspired Stream Cipher

The CENTINELA cryptographic layer is deliberately minimal and self-contained. It does not use OpenSSL, ring, or any third-party crypto library. The core centinela-crypto crate is compiled with #![no_std], making it deployable on embedded targets and microcontrollers — including potential future integration with CENTINELA Hardware Modules.

The CENTINELA Stream Cipher

The primary cipher is a ChaCha20-inspired stream cipher implementing the standard quarter-round construction. It operates on a 16-word (512-bit) state matrix:

pub struct Cipher {
    state: [u32; 16],  // Constants (4) + Key (8) + Counter (1) + Nonce (3)
}

impl Cipher {
    pub fn new(key: &[u8; 32], nonce: &[u8; 12]) -> Self {
        let mut state = [0u32; 16];
        
        // "expand 32-byte k" — RFC 8439 magic constant
        state[0] = 0x61707865;
        state[1] = 0x3320646e;
        state[2] = 0x79622d32;
        state[3] = 0x6b206574;
        
        // 256-bit key loaded as 8 × u32 (little-endian)
        for i in 0..8 {
            state[4+i] = u32::from_le_bytes([
                key[i*4], key[i*4+1], key[i*4+2], key[i*4+3]
            ]);
        }
        // Counter initialized to 0, then 96-bit nonce
        state[12] = 0;
        for i in 0..3 {
            state[13+i] = u32::from_le_bytes([
                nonce[i*4], nonce[i*4+1], nonce[i*4+2], nonce[i*4+3]
            ]);
        }
        Self { state }
    }
}

Quarter-Round Function

The mixing function applies 20 rounds (10 iterations × 2 rounds per iteration) of the ChaCha quarter-round. Each round consists of 4 ARX operations (Add, Rotate, XOR) applied across the state matrix:

// Column round
self.quarter_round(x, 0, 4,  8, 12);
self.quarter_round(x, 1, 5,  9, 13);
self.quarter_round(x, 2, 6, 10, 14);
self.quarter_round(x, 3, 7, 11, 15);
// Diagonal round
self.quarter_round(x, 0, 5, 10, 15);
self.quarter_round(x, 1, 6, 11, 12);
self.quarter_round(x, 2, 7,  8, 13);
self.quarter_round(x, 3, 4,  9, 14);

#[inline(always)]
fn quarter_round(&self, x: &mut [u32; 16], a: usize, b: usize, c: usize, d: usize) {
    x[a] = x[a].wrapping_add(x[b]); x[d] ^= x[a]; x[d] = x[d].rotate_left(16);
    x[c] = x[c].wrapping_add(x[d]); x[b] ^= x[c]; x[b] = x[b].rotate_left(12);
    x[a] = x[a].wrapping_add(x[b]); x[d] ^= x[a]; x[d] = x[d].rotate_left(8);
    x[c] = x[c].wrapping_add(x[d]); x[b] ^= x[c]; x[b] = x[b].rotate_left(7);
}

Key Design Decisions

• All operations are constant-time: wrapping_add and rotate_left never branch on data values, preventing timing side-channels.
• 64-byte block size: The cipher generates 64-byte keystream blocks. Processing larger data is chunked into 64-byte slices, with the counter incremented per block.
• Symmetric encryption: process(&mut self, data: &mut [u8]) applies XOR with the keystream in-place, making encryption and decryption the same operation.
• No heap allocations: All operations are stack-based, making the cipher safe for interrupt handlers and kernel modules.

Quantum Resistance Roadmap

The centinela-crypto/src/quantum.rs module is a reserved namespace for future post-quantum cryptographic primitives. Current plans include evaluating NIST PQC finalist algorithms (CRYSTALS-Kyber for key encapsulation, CRYSTALS-Dilithium for signatures) as the standardization process matures toward widespread adoption.

4. Threat Taxonomy & MITRE ATT&CK Alignment

CENTINELA's threat classification system is derived from the MITRE ATT&CK framework and encoded as a Rust enum, ensuring compile-time exhaustiveness checking. Every incident must be assigned one of the following threat types before a response action can be triggered:

Attack Vector Enrichment

Every detected threat is enriched with an AttackVector struct containing MITRE ATT&CK technique identifiers:

pub struct AttackVector {
    pub technique_id: String,   // e.g., "T1190" (Exploit Public-Facing Application)
    pub tactic:       String,   // e.g., "Initial Access"
    pub description:  String,
    pub confidence:   f64,      // 0.0 – 1.0, ML-derived confidence score
    pub mitre_id:     Option<String>,
}

The mitre_id field links directly to the MITRE ATT&CK knowledge base, enabling CENTINELA alerts to be correlated with threat intelligence feeds and SIEM platforms using the standard ATT&CK taxonomy.

5. Indicator of Compromise (IoC) Framework

CENTINELA maintains a live IoC registry — a tracked dataset of known-malicious artifacts observed in the wild. The IoC type supports eight indicator categories:

pub struct IoC {
    pub ioc_type:   IoCType,
    pub value:      String,
    pub confidence: f64,         // 0.0 = speculative, 1.0 = confirmed malicious
    pub first_seen: SystemTime,
    pub last_seen:  SystemTime,
    pub source:     String,      // e.g., "orzatty-threat-intel-v2", "crowdstrike-feed"
}

The confidence score enables tiered alerting: IoCs with confidence < 0.5 generate informational events, those between 0.5–0.85 trigger investigation workflows, and those above 0.85 activate automated blocking via the response system.

Registry Feed Architecture

The IoC registry is designed to consume threat intelligence from multiple sources and is updateable at runtime without restart. In production deployments, CENTINELA subscribes to:

• The internal Orzatty Threat Intelligence feed (orzatty-threat-intel)
• Public MISP (Malware Information Sharing Platform) instances
• Community-curated lists (abuse.ch, emergingthreats.net)

6. Network Flow Analysis & Traffic Monitoring

The centinela-network crate provides stateful flow tracking at the network layer. Each connection is tracked as a unique FlowId:

pub struct FlowId {
    pub src_ip:   IpAddr,
    pub dst_ip:   IpAddr,
    pub src_port: u16,
    pub dst_port: u16,
    pub protocol: Protocol,   // TCP | UDP | ICMP | Other(u8)
}

Flow tables are maintained in memory with configurable TTL eviction. For each active flow, CENTINELA tracks cumulative bytes, packet counts, connection states, and behavioral deviations from learned baselines.

Traffic Statistics Model

pub struct TrafficStats {
    pub bytes_in:             u64,
    pub bytes_out:            u64,
    pub packets_in:           u64,
    pub packets_out:          u64,
    pub connections_active:   u32,
    pub connections_new:      u32,
    pub bandwidth_utilization: f64,  // 0.0 – 1.0
}

DDoS Detection Heuristics

CENTINELA employs a multi-signal detection approach for volumetric attacks:

1. Packet Rate Anomaly: Exponential moving average baseline with 3-sigma threshold triggers alert if sustained for >10 seconds
2. Connection Exhaustion: SYN-to-SYN/ACK ratio monitoring detects SYN flood patterns
3. Source IP Diversity: Rapid increase in unique source IPs signals reflected/amplified DDoS
4. Protocol Abuse: UDP amplification factors (DNS, NTP, SSDP, memcached) trigger immediate isolation

7. Automated Response System

CENTINELA's response pipeline is a prioritized decision tree. When a threat exceeds the configured threshold for a given security level, the system escalates through response actions in order of severity:

Countermeasures are defined as structured objects with effectiveness scores and risk levels, enabling governance-compliant automated decision making:

pub struct Countermeasure {
    pub id:               Uuid,
    pub name:             String,
    pub description:      String,
    pub actions:          Vec<ResponseAction>,
    pub effectiveness:    f64,        // Expected threat reduction
    pub risk_level:       f64,        // Risk of false-positive impact
    pub execution_time_ms: u64,       // Expected time to full effect
}

8. Security Levels & Deployment Modes

CENTINELA supports four named security levels, each with distinct detection thresholds, response aggressiveness, and performance trade-offs:

Deployment Modes

• Standalone: Single node — all 7 crates run in one process. Suitable for OrzattyOS workstations.
• Cluster: Distributed across multiple nodes; events are synchronized via an internal event bus. Suitable for OrzattyCloud production.
• Edge: Ultra-lightweight deployment targeting gateway nodes. Only centinela-network and centinela-crypto are active.
• Cloud: Cloud-native deployment with Kubernetes operator for lifecycle management, metrics export to Prometheus, and integration with cloud-native WAF rules.

9. Real-Time Security Metrics

CENTINELA exposes a comprehensive security metrics stream via its observability API. All metrics are timestamped with microsecond resolution and exportable to Prometheus:

pub struct SecurityMetrics {
    pub timestamp:          SystemTime,
    pub threats_detected:   u64,    // Total threats identified since boot
    pub attacks_blocked:    u64,    // Total attacks stopped by automated response
    pub false_positives:    u64,    // Operator-confirmed false positives (for ML tuning)
    pub system_load:        f64,    // CPU load of CENTINELA processes (0.0 – 1.0)
    pub memory_usage:       f64,    // Heap usage in MB
    pub network_throughput: u64,    // Bytes/sec monitored
    pub response_time_ms:   u64,    // P99 latency from detection to response action
}

The response_time_ms field is the most operationally critical metric. For the Enhanced and Military security levels, the design targets a P99 latency of under 5ms from threat detection to active blocking — a constraint that drives the decision to use Rust's async runtime rather than a language with garbage-collected pauses.

10. Ecosystem Integration

OrzattyOS Native Integration

On OrzattyOS, CENTINELA ships as a native .deb package (centinela-security) installed during system setup. It integrates at three levels:

• AppArmor profiles: Predefined MAC profiles for all OrzattyOS applications, managed by centinela-kernel
• nftables firewall: CENTINELA manages kernel firewall rules via centinela-network, updating nftables rule sets in response to active threats with sub-second latency
• auditd integration: Kernel audit events are consumed by CENTINELA and correlated with network events for lateral movement detection

OrzattyCloud CDN Integration

The CDN worker (cdn.orzatty.com) reports security events to a CENTINELA Gateway endpoint via authenticated webhooks. This enables correlation of CDN-level anomalies (e.g., unusual package download patterns, SRI failures) with broader infrastructure threat data.

OrzattyAccount Integration

Authentication anomalies detected by OrzattyAccount (credential stuffing, impossible travel, token replay) are forwarded to CENTINELA as Intrusion or SocialEngineering events, enabling cross-service threat correlation that would be invisible to each service operating independently.

11. Research Roadmap