Before You Write the Detection Rule

It is tempting to move straight from an interesting packet to a detection rule. But before writing a condition, I want to know what the observation means, which assumptions it depends on, and what legitimate behavior might look similar.

This sample note describes a way to organize those questions. It does not present a validated signature or results from a completed experiment.

Name the behavior

Start with a sentence that describes the behavior in plain language. “An unexpected endpoint performs a state-changing operation” is more useful than “this packet looks suspicious.” It gives the investigation something concrete to test.

Then separate the observable properties from the context needed to interpret them.

Observable
  Endpoint pair, operation, sequence, timing

Context needed
  Approved roles, maintenance activity, expected process state

Evidence still needed
  Device logs, change records, process observations

Build a baseline with boundaries

A baseline is a description of the traffic you observed under specific conditions. Record those conditions. A quiet capture from normal operation may say very little about planned maintenance or recovery after an interruption.

Useful questions include:

• Which operating modes are represented in the capture?
• Which expected activities were not observed?
• Where was the capture collected, and what could it miss?
• Are timestamps and endpoint identities reliable enough for this analysis?

Detection opportunities

A rule should express the behavior you intend to notice. An alert should explain which part of that expectation was violated and provide enough evidence for a person to review it.

False-positive considerations

Test the idea against examples that resemble the target behavior for legitimate reasons. Include maintenance traffic, expected retries, and transitions between operating states when those examples are available.

If representative examples are missing, record the gap. A passing test is only informative about the conditions that were actually tested.

From detection to virtual patching

An alert invites investigation. A blocking control changes which communication reaches its destination. That difference makes operational review essential.

Before evaluating a blocking control, define the intended effect, representative allowed behavior, failure conditions, and a way to restore the previous configuration. Keep experiments within an authorized isolated lab.

Key takeaways

The most useful first step is often a clearer question. Describe what happened, identify the context you need, and document where your evidence stops. A rule is easier to evaluate when its reasoning is visible.