C-Sentinel

Most security monitoring tools are black boxes. They tell you something is wrong, but not why. They flag anomalies without explaining the reasoning. When the alert fires at 3 AM, you’re left guessing.

C-Sentinel takes a different approach: semantic observability. Every risk score comes with an explanation. Every alert tells you exactly which factors contributed and how much weight each carried.

The Problem with Traditional Monitoring

Traditional security monitoring operates on pattern matching. A process opens a network connection — is that suspicious? It depends on context that pattern matchers can’t see.

Consider a system administrator running curl to download a patch. Normal behaviour. Now consider the same command executed by a web server process. That’s worth investigating.

The difference isn’t in the action itself but in who is performing it, when, and why it deviates from established baselines. This requires semantic understanding, not just pattern matching.

How C-Sentinel Works

C-Sentinel captures “system fingerprints” — snapshots of system state that include process trees, network connections, file system changes, and user activity. These fingerprints are then analysed for anomalies using explainable scoring.

Explainable Risk Scoring

Every risk score is decomposed into contributing factors:

Risk Score: 73/100 (High)

Contributing Factors:
├── Process ancestry anomaly: +25
│   └── /usr/bin/curl spawned by httpd (unusual parent)
├── Network connection timing: +18
│   └── Connection established outside business hours
├── File access pattern: +15
│   └── Accessed /etc/shadow (sensitive file)
└── User context: +15
    └── Action performed by service account

You don’t just see the score — you see the reasoning. This transforms alert investigation from guesswork into directed analysis.

Auditd Integration

C-Sentinel integrates with the Linux audit framework to provide process chain attribution. When an alert fires, you can trace the exact sequence of events:

Process Chain:
systemd → httpd → /bin/sh → curl → [network connection]

Timeline:
14:23:01 httpd receives request from 192.168.1.45
14:23:01 httpd spawns /bin/sh with args "-c curl ..."
14:23:02 curl connects to 203.0.113.50:443
14:23:02 curl writes to /tmp/.cache_xyz

This attribution chain is essential for incident response. You can see not just what happened, but how the system got into that state.

Architecture

C-Sentinel is written in pure C with zero external dependencies. The entire binary compiles to 104KB.

This matters for deployment in constrained environments. No Python runtime. No Node.js. No container orchestration. Just a single binary that runs anywhere Linux runs.

Web Dashboard

The dashboard provides real-time visibility with multi-user authentication and role-based access control:

• Two-factor authentication with TOTP and QR code setup
• Role-based access — separate permissions for viewers, analysts, and administrators
• Public demo mode for showcasing without exposing sensitive data
• Email and Slack alerts with rich formatting

Security Posture Summary

Beyond individual alerts, C-Sentinel generates plain-English summaries of overall system security posture:

“System posture: Moderate risk. Three service accounts have accessed sensitive files in the past 24 hours. Network connection patterns show 12% deviation from baseline, primarily due to increased API calls to external services. No privilege escalation attempts detected.”

This summary helps communicate security status to non-technical stakeholders without drowning them in technical detail.

Design Philosophy

C-Sentinel follows the same principles as our commercial safety-critical work:

Minimal footprint. The smaller the codebase, the smaller the attack surface. Every line of code is a potential vulnerability.

Explainable behaviour. Security tools that operate as black boxes are security liabilities. If you can’t explain why an alert fired, you can’t trust it.

No external dependencies. Dependencies are inherited vulnerabilities. C-Sentinel’s only dependency is the Linux kernel itself.

Deterministic operation. Given the same system state, C-Sentinel produces the same risk score. This enables regression testing and makes behaviour predictable.

Getting Started

git clone https://github.com/williamofai/c-sentinel
cd c-sentinel
make
./c-sentinel --config /etc/c-sentinel/config.yaml

The default configuration provides sensible defaults for most Linux systems. Customisation is available for specific environments.

Roadmap

Current development focuses on:

• Solaris port — returning to my Solaris 2.6 roots
• macOS support — extending coverage to development workstations
• Container-aware probing — understanding container boundaries in risk assessment
• Historical trend analysis — detecting slow-moving attacks that evade point-in-time detection

Why Open Source?

Security through obscurity doesn’t work. The only way to build trustworthy security tools is to make them auditable. By releasing C-Sentinel under the MIT license, anyone can verify that it does what it claims and nothing more.

The open source also outlives us. When I’m gone, the code remains. Others can build on it, improve it, adapt it to their needs. That’s the point.

Built in the Scottish Highlands. MIT licensed. Zero dependencies.