One incident per attack story: entity-centred cases

The fragmentation problem

Most SIEM and SOAR deployments create cases from rules. One rule fires, one case opens. Grouping, where it exists, is usually by rule name and a short time window. That works when attacks are simple and fast. Real intrusions are neither. A single attacker may trigger a credential alert, a suspicious process alert, a lateral movement alert and a data access alert over several days, each from a different rule and often from a different product.

The result is fragmentation. One attack becomes several cases, sometimes handled by different analysts on different shifts. Each one looks moderate on its own. The analyst who closes the third case as "probably admin activity" may never see that the first two cases on the same host already showed credential theft. Alerts that arrive late, after a related case was closed, often start a fresh case instead of joining the story they belong to.

Fragmentation costs twice. It wastes effort, because the same context is gathered again for every case. And it hides risk, because the pattern that would make the incident obvious is split across records that nobody reads together.

Put the entity at the centre

The alternative is to organise work around entities: the hosts, accounts, IP addresses and applications that alerts are about. An entity has a history, a normal pattern of behaviour, a role in the business and a set of related entities. When every alert is attached to the entities it involves, the question changes from "what does this alert mean?" to "what is happening to this host, and is it different from usual?".

Entity-centred work needs good entity resolution. The same machine appears as a short hostname in one log, a fully qualified name in another and an IP address in a third. The same person may have several accounts. Until those aliases are joined into one canonical entity, entity-centred grouping just recreates fragmentation under a different name.

Why the decision unit should stay small

If grouping by entity is good, is grouping everything on an entity better? Not quite. A long-lived entity, such as a busy server, can accumulate benign activity and real attacks over months. Closing "the entity" as benign would sweep a real attack away with the noise. Measurements across real SOC data consistently show the trade-off: grouping by rule produces many small errors, while grouping by whole entity produces fewer but larger ones.

The practical answer is to use the entity as the view and the key, and a time-bounded cluster of behaviour on that entity as the unit that is decided and closed. That keeps closures small enough to be safe while keeping the full history visible.

Hubs should not merge unrelated stories

Some entities touch almost everything. Domain controllers, identity providers, central file servers and management consoles appear in a large share of all activity. Treating them as ordinary links causes over-merging:

• Two unrelated intrusions both authenticate through the same domain controller, and a naive grouping turns them into one giant incident.
• A single noisy service account links dozens of hosts that have nothing else in common.
• An incident grows so large that nobody can read it, which is fragmentation in reverse.
• The better pattern: hubs are shown as context in each story but do not, on their own, bridge two stories together.
• Links between entities should be bounded in time, so that activity weeks apart is not chained without other evidence.
• Each affected entity keeps its own coherent chain of activity, and the incident shows how those chains connect.

Measuring success

Teams moving to story-level incidents should measure more than ticket counts. Useful questions include: when people confirmed a real incident, how many separate cases had it been split into? Did late-arriving alerts join the right story? How many alerts does a single closure sweep, and how often does a closure include something later confirmed as malicious? Is each incident readable, or has it become a dumping ground? Tracking both fragmentation and over-merging keeps the grouping honest in both directions.

How ApexAI approaches it

The ApexAI Autonomous SOC is entity-centred by design. Alerts from your SIEM and EDR are attached to canonical entities that join their aliases, cases are formed around an entity and its behaviour over time, and incidents link the cases that make up one attack story, with the evidence for each link. Shared infrastructure such as domain controllers is shown as context without merging unrelated stories. Analysts see one story per attack, with the history they need, instead of the same attack in several tickets.

Questions