Security systems are very good at answering one question:
“Is this request suspicious?”
But sometimes that is not enough.
An attacker does not always reveal their intent through a single request.
The intent can emerge through a sequence of actions.
That is one of the main ideas behind CyberMoranda CIDS.
A Single Request Can Be Misleading
Consider a normal-looking application request:
*GET /admin
*
By itself, this may not be enough to classify the activity as malicious.
Now consider the sequence:
GET /login
↓
Multiple failed authentication attempts
↓
GET /robots.txt
↓
GET /admin
↓
GET /.env
↓
Multiple endpoint probes
↓
Abnormally high request frequency
The individual requests are not the complete story.
The sequence is the story.
CIDS is being designed to preserve and analyze that context.
From Events to Behavior
A traditional event-based approach might look like:
Request
↓
Rule Match
↓
Allow / Block
CIDS is being designed around:
Request
↓
Session Context
↓
Previous Activity
↓
Behavioral Signals
↓
Risk Evaluation
↓
Decision
This means that the system doesn't have to make every security decision from a single isolated event.
What Is a Behavioral Signal?
A behavioral signal is an observable characteristic of activity that contributes evidence to a security decision.
For example:
Authentication failures
Endpoint enumeration
Request frequency
Restricted path access
Session history
Fingerprint changes
Unusual request sequences
Each signal can contribute different evidence.
The important part is that the system should be able to explain the evidence.
Instead of:
Threat detected.
Risk = 87
CIDS should eventually be able to provide something closer to:
Risk Score: 87
Contributing signals:
- Repeated authentication failures
- Restricted endpoint probing
- Unusual request frequency
- Suspicious request sequence
Confidence: High
Decision: Contain
That makes the decision much easier for a security analyst to understand.
Context Changes the Meaning of an Event
Imagine an authenticated employee accessing:
/api/profile
That may be completely normal.
The same identity suddenly starts doing:
*/.env
/admin
/config
/internal/
**
within a short period of time.
The important question is no longer simply:
“Is this user authenticated?”
The better question becomes:
“Is this behavior consistent with the context of this session?”
This is where behavioral security becomes interesting.
Risk Should Be Accumulated From Evidence
CIDS is being designed around an incremental risk model rather than a single binary verdict.
Conceptually:
┌─ Signal A
│
Session ────────────┼─ Signal B
│
├─ Signal C
│
└─ Historical Context
↓
Risk Evaluation
↓
Policy Decision
The exact scoring model still needs to be tested and calibrated.
That is important.
A security system should not produce impressive-looking numbers without evidence behind them.
Detection and Response Should Be Separate
Another principle I'm following is to keep detection separate from response.
*Behavior
↓
Detection
↓
Risk
↓
Policy
↓
Response
*
Why?
Because detecting suspicious behavior and deciding what to do about it are two different problems.
One environment might want:
**High Risk → Monitor
Another might want:
High Risk → Rate Limit
Another might want:
Critical → Contain**
Separating these layers makes the system more adaptable.
The Goal Isn't More Blocking
This is probably the most important part.
CIDS isn't being designed with the philosophy:
“Block everything suspicious.”
The objective is:
Understand enough context to choose an appropriate defensive response.
That response could be monitoring.
It could be rate limiting.
It could be containment.
And in controlled circumstances, it could involve deception.
The system should remain defensive and should never retaliate against an attacker.
Where This Goes Next
Behavioral detection is only one layer.
The larger CIDS architecture is moving toward combining:
*Network / Application Events
+
Host Telemetry
+
Fingerprint Signals
+
Session Context
+
Threat Intelligence
+
Behavioral Analysis
↓
Security Signals
↓
Risk Engine
↓
Policy Engine
↓
Adaptive Response
*
The difficult part isn't drawing this architecture.
The difficult part is building it, testing it, measuring it, and proving that it works without creating unacceptable false positives or performance problems.
That's the part I'm working toward.
CIDS is not finished.
I'm building the foundation first.
Observe the behavior.
Understand the context.
Then act.
*CyberMoranda CIDS — Think Before You Act.
*
Top comments (0)