DEV Community: Saurabh Pandit

I'm changing my logo

Saurabh Pandit — Wed, 23 Sep 2026 01:11:49 +0000

I changed the CIDS logo. Here's why.
During a brand review, I discovered that the previous logo had a strong visual resemblance to an existing stock design.
Rather than taking that risk into the future, I chose to redesign it now.
CIDS is meant to become a long-term cybersecurity platform, so its identity should have a foundation I can confidently build on.
New logo. Same mission.
CIDS — Security that thinks.

How CIDS Should Handle Conflicting Security Signals.

Saurabh Pandit — Sat, 19 Sep 2026 18:46:30 +0000

A behavioral security system rarely receives perfectly consistent evidence.

Imagine one session produces:

Network Signal
→ unusual request pattern

Identity Signal
→ authenticated legitimate user

Host Signal
→ no suspicious process activity

Behavior Signal
→ unusual endpoint enumeration

Now CIDS has a problem:

What should happen when different security signals disagree?

A simple security system might try to add all the scores together.

But that can produce misleading conclusions.

For CIDS, conflicting evidence should instead become part of the reasoning process.

Signals Are Evidence, Not Verdicts

A signal should answer:

What did we observe?

For example:

AUTH_FAILURE_BURST ENDPOINT_ENUMERATION RESTRICTED_PATH_ACCESS UNUSUAL_REQUEST_RATE

It should not automatically answer:

Is this an attack?

That decision belongs to the higher-level correlation and risk layers.

So the pipeline remains:

Telemetry
   ↓
Normalization
   ↓
Security Signals
   ↓
Behavior Correlation
   ↓
Risk + Confidence
   ↓
Policy
   ↓
Response

This separation becomes particularly important when signals conflict.

A Realistic Example

Suppose a developer logs into an internal application.

CIDS observes:

Identity:
Authenticated user

At the same time:

Behavior:
50 endpoints accessed quickly

And:

Network:
Unusual request frequency

But:

Host:
No suspicious process activity

There is no single obvious conclusion.

The evidence looks like:

┌───────────────┐
│ Authenticated │
│ Identity │
└───────┬───────┘
│
│
┌──────────────┐ │ ┌──────────────┐
│ Network │────┼────│ Host │
│ unusual │ │ │ normal │
└──────────────┘ │ └──────────────┘
│
┌───────▼───────┐
│ Behavior │
│ enumeration │
└───────────────┘

The correct response isn't necessarily to ignore the suspicious signals.

It also isn't necessarily to block the user.

The system needs to preserve the conflict.

Contradiction Is Information

This is an important design principle.

Suppose:

Signal A → suspicious
Signal B → suspicious
Signal C → normal

Signal C doesn't necessarily cancel A and B.

Instead:

Suspicious evidence
+
Contradictory evidence
        ↓
Risk assessment
        ↓
Confidence assessment

The contradiction itself can affect confidence.

Conceptually:

Risk:
Elevated

Confidence:
Moderate

Reason:
Behavioral evidence is strong,
but supporting telemetry is inconsistent.

That is much more informative than:

Risk = 82

Don't Simply Average Everything

A tempting design would be:

Network score = 80
Identity score = 20
Host score = 10
Behavior score = 90

Average = 50

But averages can hide important relationships.

For example:

Behavior = highly suspicious
Host = normal

doesn't necessarily mean:

behavior suspicion is cancelled

The host sensor might simply have insufficient visibility.

Therefore, CIDS should distinguish between:

Negative evidence

and:

Missing / non-confirming evidence

These are not the same thing.

"Normal" Does Not Always Mean "Safe"

Suppose the host telemetry reports:

No suspicious process activity

That could mean:

No suspicious process activity actually occurred.
The activity occurred somewhere the sensor cannot observe.
The behavior is purely application-level.
The relevant process telemetry arrived late.

Therefore:

No suspicious host signal

should not automatically become:

Strong evidence of benign behavior

The meaning depends on telemetry coverage.

Evidence Coverage

This suggests another useful concept:

Evidence
+
Coverage

For example:

{
  "network": "available",
  "identity": "available",
  "host": "partial",
  "application": "available"
}

Now the Risk Engine understands not only:

What evidence exists?

but also:

How complete is the observation?

Conceptually:

Signals
   +
Telemetry Coverage
   ↓
Risk + Confidence

This can prevent CIDS from becoming overconfident when part of the system is blind.

Independent Evidence Is More Valuable

Consider:

Network detector
→ suspicious

Behavior detector
→ suspicious

If both detectors are ultimately measuring the same HTTP request pattern, they may not represent independent evidence.

But:

Network
+
Identity
+
Host

may provide different perspectives.

This matters when combining signals.

A mature Risk Engine should eventually understand the difference between:

three signals

and:

three independent pieces of evidence.

They are not necessarily equivalent.

Signal Relationships

CIDS can conceptually maintain relationships between signals:

AUTH_FAILURE_BURST
        │
        ├── related to
        ▼
ENDPOINT_ENUMERATION
        │
        ├── followed by
        ▼
RESTRICTED_PATH_PROBING

Now the system is no longer just counting signals.

It is reasoning about their relationship.

For example:

10 failed logins
        ↓
endpoint enumeration
        ↓
restricted path probing

is more meaningful than simply:

3 suspicious signals

A Possible Signal Model

A future CIDS signal could contain:

struct SecuritySignal {
    signal_type: SignalType,
    severity: Severity,
    confidence: f32,

    session_id: SessionId,

    source: SignalSource,
    timestamp: Timestamp,

    evidence_refs: Vec<EventId>,

    coverage: TelemetryCoverage,
}

The exact implementation is still part of the evolving CIDS backend.

The important architectural property is that the Risk Engine receives structured evidence, not unexplained numbers.

Risk and Confidence Should React Differently

Imagine:

Risk = high Confidence = low

This could mean:

The potential behavior is concerning, but the available evidence is incomplete or conflicting.

Whereas:

Risk = high Confidence = high

could mean:

Multiple consistent sources strongly support the assessment.

This gives policy more information.

For example:

High risk + high confidence
        ↓
stronger response may be permitted

High risk + low confidence
        ↓
additional observation / controlled response

The exact action should remain policy-driven.

This Connects Directly to Adaptive Defense

CIDS does not have to choose only:

ALLOW
BLOCK

A policy engine could consider:

Monitor
Challenge
Rate-limit
Slow
Contain
Deception

For conflicting evidence, a deployment might choose a less disruptive response while collecting additional telemetry.

Conceptually:

Conflicting evidence
        ↓
Additional observation
        ↓
New telemetry
        ↓
Signal update
        ↓
Risk reassessment

The system gets another opportunity to make a better decision.

Deception Can Generate More Evidence

This also connects to the CIDS deception architecture.

Suppose:

Behavior:
highly suspicious

Identity:
legitimate

Confidence:
moderate

Instead of immediately taking the strongest response, policy could potentially use a controlled decoy in an environment where that is appropriate.

If the session interacts with the decoy:

Decoy interaction
       ↓
New telemetry
       ↓
New security signal
       ↓
Context update
       ↓
Risk reassessment

The response becomes another observation point.

The purpose is defensive observation, not retaliation.

Don't Let AI Resolve the Conflict by Itself

An AI analysis layer can eventually help explain conflicting evidence.

For example:

"The session belongs to an authenticated user, but its request sequence resembles endpoint enumeration. Host telemetry currently provides no corroborating process-level evidence."

That is useful.

But the architecture should remain:

Deterministic telemetry
        ↓
Structured signals
        ↓
Risk / confidence
        ↓
Policy

with AI assisting explanation or analyst workflows.

Not:

Raw logs
   ↓
AI
   ↓
BLOCK

The latter makes the security decision much harder to test and audit.

Testing Conflicting Signals

This feature should be tested deliberately.

Scenario 1: All signals agree

Network → suspicious
Behavior → suspicious
Host → suspicious

Expected:

consistent evidence

Scenario 2: Signals conflict

Network → suspicious
Behavior → suspicious
Host → normal

Expected:

conflict represented
confidence adjusted according to policy/model

Scenario 3: Telemetry missing

Network → suspicious
Host → unavailable

Expected:

missing ≠ benign

Scenario 4: One noisy detector

Detector A → suspicious
Detector B → normal
Detector C → normal

Expected:

no automatic high-risk conclusion

unless other evidence supports it.

Replay Testing
Conflicting-signal scenarios are excellent candidates for replay testing.

Recorded telemetry
       ↓
Normalizer
       ↓
Signal generation
       ↓
Conflict detection
       ↓
Risk assessment
       ↓
Expected result

A regression test could contain:

{
  "scenario": "authenticated_endpoint_enumeration",
  "expected": {
    "risk_state": "elevated",
    "confidence": "moderate"
  }
}

The actual values and policy semantics would need to be determined through implementation and testing rather than assumed in advance.

What Is Implemented vs. Planned?

The current CyberMoranda CIDS project has an MVP foundation and an evolving architecture around event normalization, session context, behavioral correlation, security signals, risk scoring, confidence, adaptive defense, and deception.

The conflicting-signal reasoning described here is an architectural direction, not a claim that the current MVP already implements a production-grade evidence graph, independent-signal weighting, telemetry coverage modeling, or formally validated conflict-resolution algorithms.

Those components need implementation and testing.

The goal is to define the reasoning model before adding unnecessary complexity.

The Larger Architecture

The idea fits into the broader CIDS pipeline:

RAW TELEMETRY
│
▼
┌──────────────┐
│ Normalizer │
└──────┬───────┘
▼
┌───────────────┐
│Session Context│
└───────┬───────┘
▼
┌───────────────┐
│ Signals │
└───────┬───────┘
▼
┌─────────────────┐
│ Behavior │
│ Correlation │
└────────┬────────┘
▼
┌───────────────────┐
│ Risk + Confidence │
└─────────┬─────────┘
▼
┌──────────────┐
│ Policy │
└──────┬───────┘
▼
RESPONSE

The key idea is that conflicting evidence does not break the pipeline.

It becomes another property of the evidence that the system reasons about.

Final Thought

Real security telemetry is messy.

One sensor says:

Suspicious.

Another says:

Normal.

A third might say:

I don't have enough information.

A mature security system shouldn't hide that disagreement.

It should represent it.

Signal
  ↓
Evidence
  ↓
Context
  ↓
Agreement / Conflict
  ↓
Risk
  ↓
Confidence
  ↓
Policy

That gives CIDS an important property:

Uncertainty becomes data instead of becoming a hidden assumption.

The goal isn't to make CIDS always certain.

The goal is to make its uncertainty explicit, explainable, and testable.

Think Before You Act.

Designing a Telemetry Pipeline for CIDS: Turning Raw Activity Into Security Signals

Saurabh Pandit — Fri, 11 Sep 2026 17:34:36 +0000

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.

Beyond Block or Allow: Designing Adaptive Defense in CIDS.

Saurabh Pandit — Tue, 08 Sep 2026 14:28:48 +0000

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.

Designing the Risk Engine Behind CIDS

Saurabh Pandit — Sun, 06 Sep 2026 23:33:58 +0000

A security system can collect thousands of events.

But collecting events is not the difficult part.

The difficult part is deciding:

Which events actually matter?

This is where the Risk Engine becomes an important part of CyberMoranda CIDS.

The purpose of the Risk Engine is not to simply assign a large number to suspicious activity.

Its purpose is to combine security evidence, context, and behavior into a defensible risk decision.

From Events to Risk
A simplified CIDS pipeline looks like this:

Incoming Activity
↓
Event Normalization
↓
Session Context
↓
Behavior Analysis
↓
Security Signals
↓
Risk Engine
↓
Policy Engine
↓
Response

The Risk Engine sits between detection and response.

That separation is intentional.

Detection answers:

What looks suspicious?

Risk evaluation answers:

How concerning is the combined evidence?

Policy answers:

What should we do about it?

Why a Single Score Isn't Enough

A common mistake is to create something like:

Normal request = +2
Admin request = +30
Failed login = +20

and simply add everything together.

That can work for a basic prototype, but it becomes problematic as the system grows.

Consider:

Failed login

Five failed logins from a normal user might be suspicious.

Five failed logins from a known security-testing environment might be completely expected.

The same event can have different meanings depending on context.

Therefore, CIDS needs more than a static point system.

Context Matters

The Risk Engine should eventually consider multiple dimensions:

┌── Event Evidence
│
├── Session History
│
├── Behavioral Pattern
│
├── Identity Context
│
├── Asset Sensitivity
│
├── Frequency / Timing
│
└── Previous Signals
↓
Risk Engine

This allows the system to reason about activity as a sequence rather than isolated events.

Signals Before Scores
One architectural decision I'm exploring is to standardize security signals before calculating the final risk.

For example:

AUTH_FAILURE_BURST
ENDPOINT_ENUMERATION
RESTRICTED_PATH_PROBE
REQUEST_RATE_ANOMALY
FINGERPRINT_CHANGE
SESSION_BEHAVIOR_SHIFT

Each signal should have structured information such as:

Signal
├── type
├── severity
├── confidence
├── timestamp
├── source
├── session
└── evidence

This creates a cleaner boundary between detection and risk calculation.

Instead of the detector saying:

Risk = 74

it can say:

Signal:
ENDPOINT_ENUMERATION

Severity:
HIGH

Confidence:
0.91

Evidence:
Multiple restricted endpoints accessed
within a short session window.

The Risk Engine can then combine that signal with other evidence.

Risk and Confidence Are Different

This distinction is important.

Risk asks:

How dangerous could this behavior be?

Confidence asks:

How confident are we that our interpretation is correct?

These should not automatically be treated as the same value.

For example:

Risk: High
Confidence: Low

could mean:

The potential impact is significant, but the system doesn't have enough evidence yet.

That should potentially produce a different response from:

Risk: High
Confidence: High<

This is one reason I don't want CIDS to depend on a single arbitrary threshold.

Temporal Behavior
Another important component is time.

Suppose a session produces:

10:01 Login
10:02 Failed authentication
10:03 /robots.txt
10:03 /admin
10:04 /.env
10:04 /internal

Looking at each event independently loses information.

Looking at the sequence reveals a behavioral pattern.

So the Risk Engine needs access to temporal context.

Conceptually:

Event A
↓
Event B
↓
Event C
↓
Event D
↓
Behavioral Pattern
↓
Risk Update

This is one of the areas where CIDS can move beyond simple rule matching.

Risk Should Decay Too
Risk shouldn't necessarily increase forever.

If suspicious behavior stops, the system should eventually be able to reduce the active risk associated with a session.

Conceptually:

Suspicious activity
↓
Risk increases
↓
No further suspicious activity
↓
Risk gradually decays

This prevents an old event from permanently defining a session.

The exact decay model needs to be tested rather than chosen arbitrarily.

Explainability Is Mandatory
A security analyst shouldn't have to trust a mysterious number.

If CIDS reports:

Risk: 91

the system should also be able to answer:

Why?

Restricted endpoint probing
Abnormal request frequency
Authentication failure burst
Suspicious session sequence

Confidence: High

This becomes especially important when automated responses are involved.

Risk Should Not Directly Trigger Everything

I want to keep another boundary inside CIDS:

Signals
↓
Risk
↓
Policy
↓
Response

Not:

Risk > X
↓
BLOCK

The policy layer should have the final authority over the response.

For example:

High Risk + Low Confidence
↓
Monitor

while:

High Risk + High Confidence
↓
Contain

And a controlled deception policy could be applied where appropriate.

This separation also makes CIDS easier to adapt to different environments.

The Architecture I'm Building Toward

The longer-term backend direction looks roughly like:

Telemetry
↓
Event Normalizer
↓
Session Engine
↓
Behavior Analysis
↓
Signal Engine
↓
Risk Engine
/ \
Risk Score Confidence
\ /
Policy Engine
↓
Response Engine
/ | \
Allow Monitor Contain
↓
Deception
↓
Audit / Feedback

Additional telemetry sources such as host-level telemetry, eBPF and fingerprinting signals can feed into this architecture as the system evolves.

The Hard Part

The architecture is easy to draw.

The real engineering challenge is proving that the Risk Engine works.

That means testing questions such as:

Does it detect meaningful behavioral changes?

How many false positives does it produce?

How quickly does risk change?

Does risk decay appropriately?

Can every decision be explained?

What happens under high event volume?

Can the system recover from failures?

Can the scoring model be tuned without rewriting the detection engine?

These are the questions I want CIDS to answer with experiments and measurable results.

Not marketing claims.

Where CIDS Is Going

My current goal isn't to build a dashboard that simply displays:

Threat: HIGH
Risk: 91

I want to build the engine underneath it that can explain:

Why is this behavior suspicious?

What evidence supports that conclusion?

How confident is the system?

What should happen next?

That is the direction I'm taking with the CIDS backend.

Observe the behavior.
Build the context.
Evaluate the evidence.
Then act.

CyberMoranda CIDS — Think Before You Act.

Why CIDS Looks at Behavior, Not Just Individual Requests

Saurabh Pandit — Sun, 06 Sep 2026 12:06:18 +0000

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.
*

cybersecurity

threatdetection

security

rust

opensource

CyberMoranda CIDS: Building a Security System That Thinks Before It Acts

Saurabh Pandit — Sat, 05 Sep 2026 20:00:12 +0000

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:

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.

cybersecurity

rust

security

opensource

devops

cybermoranda

Why CIDS?

Saurabh Pandit — Sat, 05 Sep 2026 04:47:37 +0000

Traditional security often focuses on what happened.
CIDS focuses on how the behavior develops over time.
A single request may look harmless. But when multiple actions form an unusual pattern, the context can tell a very different story.
That is the problem I’m trying to solve with CIDS.
Observe the behavior. Understand the context. Then act.

CyberSecurity #CIDS #CyberMoranda #ThreatDetection #BehavioralSecurity

CyberMoranda CIDS: Building a Security System That Thinks Before It Acts

Saurabh Pandit — Thu, 03 Sep 2026 10:20:03 +0000

I’m building CyberMoranda CIDS — Cognitive Intrusion Defense System, a behavior-based approach to cybersecurity.
Instead of reacting to every request individually, CIDS aims to understand behavior, context, and intent before deciding how to respond.
Observe → Understand → Assess → Adapt
The project is still under development, but the goal is clear:
Build security that thinks before it acts.
CyberMoranda CIDS — Think Before You Act.

CyberSecurity #CIDS #CyberMoranda #CyberDefense #SecurityEngineering