{
  "id": 6062188,
  "title": "Designing the Risk Engine Behind CIDS",
  "url": "https://urgent.news/2026/09/06/designing-the-risk-engine-behind-cids",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-06T23:33:58.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/cybermoranda/designing-the-risk-engine-behind-cids-59mm"
  },
  "original_language": "en",
  "account": "A security system gathers thousands of events, but the real challenge lies in discerning which events hold significance. This is where the Risk Engine plays a crucial role within CyberMoranda CIDS. Its objective is not merely to assign a high number to suspicious activity, but rather to integrate security evidence, context, and behavior into a justified risk decision. The flow of events in a simplified CIDS pipeline is as follows: Incoming Activity → Event Normalization → Session Context → Behavior Analysis → Security Signals → Risk Engine → Policy Engine → Response. The Risk Engine acts as a bridge between detection and response, a separation that is deliberate. While detection answers \"What appears suspicious?\", risk evaluation focuses on \"How concerning is the combined evidence?\" and policy determines \"What should be done about it?\" A common error is to assign point values to different types of requests and accumulate them, but this approach becomes cumbersome as the system expands. For instance, failing to login five times from a regular user might be suspicious, but the same activity from a known security testing environment might be expected. This highlights the need for context. In the Risk Engine, multiple dimensions should be factored in, including event evidence, session history, behavioral patterns, identity context, asset sensitivity, frequency/timing, and previous signals. By considering the sequence of events rather than isolated incidents, the system can better interpret the activity. One architectural approach being considered is to standardize security signals before calculating the final risk score. Examples of signals include AUTH_FAILURE_BURST, ENDPOINT_ENUMERATION, REQUEST_RATE_ANOMALY, and SESSION_BEHAVIOR_SHIFT, each carrying structured information like type, severity, confidence, timestamp, source, session, and evidence. This enables a clearer demarcation between detection and risk calculation. Risk and confidence are distinct concepts that should not be conflated. Risk questions \"How dangerous could this behavior be?\", while confidence inquires \"How confident are we in our interpretation?\" For example, a high risk with low confidence may warrant a different response than a high risk with high confidence. Additionally, temporal behavior plays a crucial role. A sequence of events can reveal hidden patterns that individual events might obscure. Thus, the Risk Engine must incorporate temporal context. Furthermore, the risk should not escalate indefinitely; it should decrease once the suspicious activity ceases. To prevent old events from continuously influencing a session, risk decay mechanisms must be devised and tested. Explainability is paramount. Analysts should not only see a numerical risk score, but also understand the rationale behind it. For instance, a risk score of 91 should be accompanied by details such as restricted endpoint probing, abnormal request frequency, authentication failure burst, and a suspicious session sequence. Lastly, the policy layer should have the ultimate authority over the response. Risk alone should not directly trigger actions. Instead, the policy layer should decide whether to monitor, contain, or apply controlled deception, depending on the risk level and confidence. The long-term vision for CIDS involves building a system that not only displays risk scores but also provides detailed explanations of why a particular risk score was assigned. This includes understanding the underlying events, signals, and confidence levels. The ultimate goal is to create a robust, adaptable, and explainable Risk Engine that can effectively assess and respond to security risks in a dynamic environment.",
  "summary": "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…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}