For a long time, I have been working on an idea called CyberMoranda CIDS.
CIDS stands for Cognitive Intrusion Defense System.
The idea started with a simple question:
What if a security system could understand behavior before deciding how to respond?
Traditional security systems often make decisions from individual events, signatures, rules, or predefined patterns.
But real attacks are not always a single event.
Sometimes the intent becomes visible only when multiple actions are connected over time.
That is where CIDS begins.
The Core Philosophy
Think Before You Act.
CIDS is being designed around this pipeline:
Observation
↓
Context
↓
Behavior
↓
Security Signals
↓
Risk + Confidence
↓
Decision
↓
Adaptive Response
↓
Feedback
Instead of immediately treating every suspicious request as an attack, the system builds context around the behavior.
The Backend Is the Product
One thing I have become increasingly clear about while developing CIDS is that the dashboard is not the product.
The security engine is the product.
The backend needs to understand:
What happened?
Who/what generated the activity?
What happened before it?
Is this behavior normal for the session?
Which security signals were triggered?
How confident are we?
What is the current risk?
What response should the policy allow?
This leads to a more structured architecture.
Traffic / Host Telemetry
↓
Event Normalizer
↓
Session Context
↓
Behavior Analysis
↓
Signal Engine
↓
Risk Engine
↓
Policy Engine
↓
Response Engine
↓
Audit / Events
Behavioral Detection
The goal is not simply:
Request → Rule → Block
Instead, CIDS should be able to observe a sequence such as:
Login
↓
Repeated authentication failures
↓
Endpoint enumeration
↓
Restricted path probing
↓
Abnormal request frequency
Each individual event may not be enough to make a decision.
Together, however, they can form a much stronger behavioral signal.
Adaptive Defense
CIDS is not designed around a single response.
Depending on context and risk, the response layer can move through different levels:
ALLOW
↓
MONITOR
↓
SLOW / CHALLENGE
↓
CONTAIN
↓
DECEPTION
The purpose is defensive.
CIDS will not hack back or retaliate against attackers.
The goal is to protect the system while making malicious activity less useful.
Where I Want to Take It
The architecture is evolving toward several areas:
Host-based telemetry
eBPF-based observability
JA4 and fingerprint-based signals
Context-aware deception
Honeytokens
Feedback loops for detection tuning
Standardized security signals and rules
Event-driven processing
Strong auditing
Replay-based testing
Performance and reliability testing
These are part of the engineering direction, not claims that every component is already production-ready.
From a Phone-Built MVP
The first CIDS MVP was built with extremely limited resources.
It was built on a phone.
It is not the final system.
But building that MVP proved something important to me:
The idea could become a working system.
Now I want to take that prototype much further.
The next goal is not simply to make CIDS look impressive.
The goal is to make its backend technically strong, explainable, testable, and scalable.
I am still building.
And I am documenting the journey as I go.
CyberMoranda CIDS
Think Before You Act.
Top comments (6)
"Thinks before it acts" is an interesting framing for an IDS — most detection systems I've seen are reactive by design. Curious how CIDS decides when to intervene vs just flag and log. Looking forward to reading the full breakdown!
Hey Ghouzlan, glad the idea caught your attention!
The main idea behind CIDS is pretty simple: it doesn’t immediately block something just because it looks unusual. It first tries to understand what the actor is doing and how their behavior is changing.
Low risk: CIDS mostly observes and logs. It gives the actor some time and keeps building their activity history.
Medium risk: If the behavior starts looking more suspicious, like repeated scanning or unusual requests, CIDS can slow the interaction down using a Cognitive Tarpit instead of immediately blocking it.
High risk : If the behavior strongly suggests malicious intent, such as probing decoy paths like /admin or .env, CIDS can move the actor into a controlled deception environment and continue collecting useful signals.
So basically, CIDS tries to understand first, escalate gradually, and intervene when the evidence becomes strong enough.
That’s the direction I’m exploring with CIDS v4.
That makes a lot of sense — treating behavior as a spectrum instead of a binary "block/allow" decision feels a lot closer to how a human analyst would actually reason about it. Does the system get more conservative over time as it learns what "normal" looks like for a given environment, or is the baseline mostly fixed once it's set up?
The baseline is dynamic, not something that gets fixed on day one.
For example, if someone does something unusual once and then goes back to their normal behavior, their score gradually comes down. So one mistake doesn’t permanently label them as a threat.
The more interesting part for v4 is what I’m calling “Insider Drift.” CIDS will look at how someone’s behavior changes over time. If a normally trusted user slowly starts doing unusual things -testing boundaries, jumping between unrelated resources, or accessing things at odd hours -
that change in behavior becomes important.
And instead of looking at every request separately, CIDS tries to build a story around the actor:
“Does what they’re doing now actually make sense based on what they’ve been doing before?”
So the goal isn’t simply to make the system more strict over time. It’s to make its confidence more context-aware and adaptive as the actor’s behavior evolves.
That’s one of the areas I’m exploring in CIDS v4.
Interesting approach — moving from reactive to proactive decision‑making in security systems is definitely the direction things are heading.
One challenge I’ve run into with behavior‑based systems is balancing sensitivity and specificity: too sensitive and you flood the operator with false positives; too conservative and you miss real threats. How are you handling that trade‑off in CIDS, especially when it comes to differentiating between genuinely malicious behavior and legitimate but unusual activity?
Also curious about how you handle state persistence — do you keep a full session context, or do you evaluate events in isolation and rely on the model to infer context?
Thanks for the insightful questions, Darkssel. You’ve touched on two of the hardest challenges in behavior-based security. Here is how we are designing CyberMoranda CIDS to address them:
Balancing Sensitivity and Specificity
CIDS is designed around the assumption that legitimate users can occasionally behave unusually. Instead of making an immediate binary “allow/block” decision, the system builds confidence from behavioral signals.
Dynamic Intent Decay: Each observed action contributes to an intent/risk score, while that score can decay over time. This prevents a single unusual action from becoming a permanent label.
Deception as a Filter: When behavioral confidence crosses a threshold, CIDS can move toward deception rather than immediately dropping the connection. This could include controlled latency or a decoy resource such as a fake administrative interface. The interaction with the decoy becomes another behavioral signal that can increase confidence.
Handling State Persistence
CIDS is designed around maintaining session-level context rather than evaluating requests completely in isolation.
Actor-Centered Tracking: The goal is to track how an actor’s behavior evolves throughout a session.
Behavioral and Temporal Lenses: We evaluate patterns such as navigation/probing behavior, feature hopping, request velocity, and how these behaviors change over time.
Narrative Engine: With this accumulated context, CIDS can eventually turn individual events into a readable behavioral narrative — showing how an actor entered, what they probed, what changed in their behavior, and which defensive/deception mechanisms they interacted with.
The current implementation is still an evolving MVP, so these capabilities are being built incrementally. The goal is to move from isolated event detection toward understanding the sequence, context, and intent behind activity.
I appreciate the questions — these are exactly the problems we’re trying to solve with CIDS.