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.
Top comments (0)