Path: detection engineering

Detection engineering is building and maintaining the logic that creates alerts. Engineers decide what to watch for, write the query or rule, test it against real data, and tune it so it fires on the right things and stays quiet otherwise.

Analysts make good detection engineers because they know what a bad alert costs. You have seen rules that fire on every backup job. You know which alert titles mislead. That knowledge is the hard part.

Signs this might be your path

• You often think "if this rule also checked X, it would be quiet".
• You enjoy writing queries more than closing tickets.
• You keep a list of tuning ideas without being asked.

How to start

1. Learn your SIEM's query language properly, beyond copying queries. Filters, joins, time windows, counting.
2. Pick one noisy rule and propose a tuning change with evidence: how often it fires, on what, and what your change would remove.
3. Learn a portable rule format such as Sigma, so you can read rules shared publicly and translate them.
4. Map each rule to an ATT&CK technique. It helps you see which tactics your team covers and which it does not.
5. Test your rule against known-bad activity, not only against yesterday's logs.

A good detection has a clear title, a description that says what it looks for and why, the data source it depends on, known false positives, and a short note on what the analyst should check first. Write rules you would want to receive at 3am.

You can start this path without changing jobs. Offer to own the tuning of one rule for a quarter. Track how often it fires before and after your change, and how many real cases it still catches. That record is the strongest case you can make for moving into detection work.

Rule of thumb:Rule of thumb: a new rule is not done when it fires. It is done when an analyst who has never seen it can triage its alert in a few minutes.