A detection is useful when its conditions match the telemetry you actually collect. A convincing rule can still refer to fields your pipeline does not emit or match routine administrative work.
Bring a small set of synthetic or sanitized events and the target rule format. Use the conversation to express the behavior, examine false positives and build a validation checklist. Deployment and rule execution stay in your own detection workflow.
Start with this material
- The behavior to detect, with evidence from an advisory, analysis note or observed event.
- The target rule format and the exact available field names and event sources.
- One expected positive event and several benign counterexamples, with sensitive values removed.
Work through the evidence
- Describe the behavior without relying on a malware-family name. Identify which event fields could express it.
- Ask for a draft rule tied to the supplied schema. Mark unavailable fields and unsupported syntax explicitly.
- Build a small test set: expected match, near miss, common administrative behavior and missing-field events.
- Validate syntax and matching in the actual rule engine. Document data dependencies, tuning assumptions and the behaviors this rule will miss.
A prompt to adapt
Adapt to your evidence
Draft a detection for the behavior in these sanitized events using only the supplied schema. Explain every condition. Provide positive, near-miss and benign administrative test events, identify likely false positives and list required telemetry. Do not invent fields or claim the rule has been deployed or tested.
Check the result
- The target engine accepts the syntax and every referenced field exists in collected telemetry.
- Positive and benign fixtures produce the intended results in the real engine.
- The rule documentation states scope, data dependencies, tuning decisions and known blind spots.
Bring your own evidence into a conversation and work through the next question.
Open chat