A behavioral security system is only as good as the information it can observe.
If the telemetry is incomplete, inconsistent, or impossible to correlate, the detection layer has to make decisions with missing context.
For CyberMoranda CIDS, this leads to an important architectural principle:
Don't send raw events directly to the risk engine. Normalize them first.
The telemetry pipeline is the layer that turns different observations into a consistent stream of security-relevant events.
The Problem With Raw Security Events
Different components can produce completely different data.
A network layer might observe:
source IP
destination
port
protocol
request rate
fingerprint
An application might produce:
user
endpoint
HTTP method
status code
authentication result
A host telemetry source might provide:
process
PID
file
socket
system call
parent process
If every detector handles these formats independently, the architecture quickly becomes difficult to maintain.
Instead, CIDS needs a common event model.
A Normalized Event Model
Conceptually, the pipeline looks like:
Network Telemetry ─────┐
│
Application Events ────┼──→ Event Normalizer
│ │
Host Telemetry ────────┘ ↓
Canonical Event
↓
Session Context
↓
Security Signals
↓
Risk Engine
The normalizer should not decide whether something is malicious.
Its job is to make the data consistent and usable.
A conceptual event might look like:
{
"event_type": "http_request",
"timestamp": "2026-09-09T16:00:00Z",
"source": {
"address": "example",
"fingerprint": "example"
},
"session_id": "session-123",
"request": {
"method": "GET",
"path": "/admin",
"status": 403
},
"metadata": {
"sensor": "application"
}
}
The exact schema will evolve as CIDS develops.
The important idea is that downstream components should not need to understand every individual telemetry source.
Preserve Evidence
Normalization should not mean throwing information away.
A dangerous mistake would be reducing an event immediately to:
SUSPICIOUS = true
That destroys useful evidence.
Instead, CIDS should preserve enough context to answer:
- Where did the event originate?
- When did it happen?
- Which session was involved?
- Which sensor produced it?
- What was actually observed?
- Which fields were inferred?
- How reliable is the observation?
That gives later stages more information to work with.
Event Time vs Processing Time
Security systems also need to distinguish between two concepts:
`Event Time
↓
When the activity actually happened
Processing Time
↓
When CIDS received/processed the event`
These aren't always identical.
Network delays, buffering, dropped packets, overloaded collectors, or asynchronous processing can introduce differences.
For behavioral analysis, this matters because sequences depend on time.
For example:
A → B → C
could be interpreted differently if the timestamps are wrong.
So the telemetry layer should preserve timestamps carefully rather than treating them as an afterthought.
Correlation Is Where Telemetry Becomes Useful
A single event is often weak evidence.
A correlated sequence can be much more informative.
Consider:
Event 1
Failed login
↓
Event 2
Endpoint enumeration
↓
Event 3
Restricted path access
↓
Event 4
Abnormal request frequency
The telemetry pipeline can associate these events with a common session or behavioral context.
Then the detection layer can produce something like:
Behavioral Signal
AUTH_FAILURE_BURST
ENDPOINT_ENUMERATION
RESTRICTED_PATH_PROBE
REQUEST_RATE_ANOMALY
The Risk Engine can then evaluate the combined evidence.
A Useful Separation of Responsibilities
One architecture I'm working toward is:
┌──────────────────────┐
│ Telemetry │
│ "What was observed" │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ Normalize │
│ "Make it consistent"│
└──────────┬───────────┘
↓
┌──────────────────────┐
│ Context │
│ "What is related?" │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ Detection │
│ "What looks unusual?"│
└──────────┬───────────┘
↓
┌──────────────────────┐
│ Risk │
│ "How concerning?" │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ Policy │
│ "What should happen?"│
└──────────────────────┘
Each layer has a different responsibility.
That separation should make the backend easier to test and evolve.
Reliability Matters
Telemetry itself can fail.
A collector can disconnect.
An event can arrive late.
A field can be missing.
A sensor can produce duplicate observations.
CIDS therefore shouldn't assume:
If an event is missing, nothing happened.
Instead, the system should know the quality of its observations.
A future event model could include concepts such as:
source
confidence
timestamp
sequence
sensor
schema_version
This allows downstream components to reason about the reliability of their inputs.
What About eBPF?
Host-level visibility is one of the areas I want to explore further for CIDS.
eBPF can provide a powerful foundation for observing certain kernel-level activity without requiring a traditional kernel module.
In a future CIDS telemetry architecture, host signals could flow through the same normalization boundary:
┌─ Network
│
├─ Application
│
Telemetry Sources ──┼─ Host / eBPF
│
└─ Other Sensors
↓
Event Normalizer
↓
Common Event Model
This is an architectural direction, not a claim that every eBPF telemetry component is already production-ready in CIDS.
That distinction matters.
Don't Let Telemetry Become the Bottleneck
A behavioral system can generate a lot of data.
If every raw event is stored forever and every component processes everything synchronously, scalability becomes a problem.
A more scalable direction is:
Sensors
↓
Ingestion
↓
Normalization
↓
Event Stream
├── Session Correlation
├── Detection
├── Storage
└── Observability
This allows different consumers to process the information they actually need.
It also creates a cleaner path toward distributed deployments later.
Testing the Telemetry Layer
Before trusting the Risk Engine, I want to be able to test the telemetry pipeline independently.
For example:
Input Event
↓
Normalizer
↓
Expected Canonical Event`
Then:
`Multiple Events
↓
Session Correlator
↓
Expected Behavioral Sequence`
And finally:
`Telemetry
↓
Detection
↓
Expected Security Signal
This makes debugging much easier.
If the final risk score is wrong, we can ask:
Was the telemetry wrong?
↓
Was normalization wrong?
↓
Was correlation wrong?
↓
Was the signal wrong?
↓
Was the risk calculation wrong?
Without these boundaries, every detection failure becomes difficult to diagnose.
What Is Built vs What Is Planned?
One principle I'm keeping throughout CIDS development is to separate the prototype from the target architecture.
The existing MVP established the initial CIDS concept and basic defensive workflow.
The broader telemetry architecture described here represents the engineering direction I'm building toward, including richer correlation, host telemetry, eBPF integration, and scalable event processing.
I don't want to present architectural diagrams as if they were already production systems.
The gap between:
“This is the design.”
and
“This works reliably under real conditions.”
is where most of the engineering actually happens.
The Bigger Picture
The telemetry layer may not be the most visible part of CIDS.
There is no flashy dashboard here.
No giant threat score.
No dramatic animation.
But it may become one of the most important foundations of the system.
Because behavioral detection depends on context.
And context depends on good telemetry.
The direction is:
Observe
↓
Normalize
↓
Correlate
↓
Understand
↓
Evaluate
↓
Respond
↓
Learn
That's the foundation I'm continuing to build for CyberMoranda CIDS.
Think Before You Act.
Top comments (0)