Most security systems eventually have to answer a simple question:
Allow or block?
That model is useful.
But I think there is an interesting space between those two decisions.
What if the system isn't completely certain that an activity is malicious?
What if the behavior is suspicious, but blocking immediately would create unnecessary friction?
And what if the system has enough evidence to know that something is wrong, but instead of simply terminating the interaction, it can safely contain it and gather more defensive intelligence?
These questions led me to one of the core ideas behind CyberMoranda CIDS:
Adaptive Defense.
Detection Is Not the Same as Response
CIDS separates these two decisions.
Behavior
↓
Detection
↓
Risk + Confidence
↓
Policy
↓
Response
This distinction is important.
The detection engine should not decide:
"I found something suspicious, therefore BLOCK."
Instead, it should provide evidence.
The policy engine decides what that evidence should mean for the environment.
A Response Spectrum
The response architecture I'm working toward looks like:
┌── Allow
│
├── Monitor
│
Risk + Confidence ──┼── Slow / Challenge
│
├── Contain
│
└── Deception
These aren't simply five fixed risk levels.
The actual response should depend on context, confidence, asset sensitivity, policy, and observed behavior.
Why Not Block Immediately?
Imagine a request pattern that is unusual but not conclusive.
Risk: HIGH
Confidence: LOW
Immediately blocking could be a bad decision.
Instead, the system might increase observation:
Suspicious activity
↓
Increase monitoring
↓
Observe next actions
↓
Update context
↓
Re-evaluate risk
This gives the system more evidence before taking a stronger action.
That is the basic idea behind adaptive response.
Dynamic Friction
One concept I am particularly interested in is dynamic friction.
Instead of applying the same delay to every suspicious request, the response can be influenced by the current context.
For example:
Low concern
↓
Normal response
Moderate concern
↓
Additional observation
High concern
↓
Controlled friction / challenge
Very high confidence
↓
Containment
The exact implementation and thresholds need to be validated through testing.
I don't want arbitrary numbers to become part of the architecture simply because they looked good in an MVP.
Deception as a Defensive Layer
Deception is another part of the CIDS design.
The objective isn't to attack the attacker.
It is to create a controlled environment where suspicious activity can be observed without exposing the real application or sensitive resources.
Conceptually:
Suspicious Session
↓
Policy Evaluation
↓
Is Deception Appropriate?
↓
Controlled
Deception
↓
Observe + Record
The real application remains separated from the deceptive environment.
What Could Deception Provide?
A controlled deception environment could help collect information such as:
- Requested paths
- Request sequences
- Timing
- Interaction patterns
- Authentication attempts
- Tool/fingerprint signals
- Session behavior
- Commands or inputs attempted within the decoy
The goal is defensive visibility, not retaliation.
Honeytokens
Another concept that fits naturally into this architecture is the use of honeytokens.
A honeytoken is an intentionally placed piece of data designed to generate a signal when accessed or used unexpectedly.
For example:
Normal application
↓
Hidden defensive marker
↓
Unexpected access
↓
Security Signal
↓
Risk Evaluation
A honeytoken event can become one piece of evidence within the broader behavioral model.
It should not automatically mean:
Honeytoken → BLOCK
Instead:
Honeytoken
+
Session Context
+
Previous Behavior
↓
Risk Evaluation
Again, context matters.
Deception Should Not Become a Trap for Everyone
This is an important engineering constraint.
A defensive deception mechanism must be isolated.
It should not:
- expose real credentials
- provide access to production systems
- become an uncontrolled pivot point
- interact offensively with external systems
- create unnecessary risk for legitimate users
The deception environment should be treated as an isolated security boundary.
Feedback Changes the System
Another important part of the architecture is feedback.
Suppose CIDS makes a decision:
Behavior
↓
Risk
↓
Contain
Later, an analyst determines that the behavior was legitimate.
That information shouldn't disappear.
Conceptually:
Detection
↓
Decision
↓
Outcome
↓
Analyst Feedback
↓
Policy / Detection Tuning
This doesn't necessarily mean blindly training an AI model from every analyst action.
It means the system should have a structured way to learn from operational outcomes.
The Bigger Architecture
This brings the different CIDS components together:
Network / Host Telemetry
↓
Event Normalization
↓
Session Context
↓
Behavior Analysis
↓
Signal Engine
↓
Risk + Confidence
↓
Policy Engine
↓
Adaptive Response
/ | \
Allow Monitor Contain
↓
Deception
↓
Evidence / Audit
↓
Feedback
The dashboard is simply a window into this system.
The real product is the decision-making backend underneath it.
What I Am Trying to Build
I don't want CIDS to become another product that simply shows:
ATTACK DETECTED
IP BLOCKED
I want the system to answer a more useful set of questions:
What happened?
Why does it look suspicious?
How confident are we?
What has this session been doing?
What response is appropriate?
What did we learn from the response?
That is the direction behind the adaptive defense architecture of CIDS.
There is still a lot of engineering and validation ahead.
The architecture is evolving.
The prototype is only the beginning.
Observe. Understand. Adapt. Defend.
CyberMoranda CIDS — Think Before You Act.
Top comments (0)