Cyber, Risk & Internal Audit
Detection & Response / Security Operations
Where the alerts land. Increasingly an engineering role, because the manual version does not survive the volume.
Detection and response owns the question of whether anything bad is happening right now. The role has changed considerably: the analyst-staring-at-a-console model has largely been replaced by detection-as-code, where rules live in version control, get reviewed, and have tests.
| Time | What you are actually doing |
|---|---|
| 09:00 | Triage what came in overnight. Most of it is known-benign. The skill is not investigating faster, it is recognising the one that is not in the pattern. |
| 10:30 | Write a detection. A new technique was published; you build the rule, write a test that fires on a known-true positive, and open a pull request. |
| 13:00 | Tune. One rule generated 200 of yesterday's 500 alerts. You either narrow it, convert it to a correlation input, or retire it. |
| 14:30 | Threat hunt. A hypothesis rather than an alert: if an attacker were living off the land here, what would that look like in our telemetry, and can I find it. |
| 16:00 | Post-incident. Not the incident itself — the detection gap it exposed, and the rule that would have caught it eleven minutes earlier. |
The decisive round
“Walk me through investigating this alert.”
Interviewer: “You get an alert: a service account authenticated from a new country at 03:00 and enumerated group memberships. Go.”
A weak answer. “I'd check whether the login was legitimate, look at what else that account did, and escalate to incident response if it looks malicious.” Describes the shape of an investigation without doing one. No hypothesis, no specific data source, no idea what would confirm or refute.
A strong answer. “Two things stand out before I look at anything: it is a service account, which should have entirely predictable behaviour, and the action is enumeration, which is reconnaissance rather than use. Interactive authentication by a service account is itself the anomaly regardless of geography — the country is the least interesting part, because that is a VPN away.
First I establish the baseline: what does this account normally do, from where, at what times, and does it normally authenticate interactively at all? If it has never done so, that is close to conclusive.
Then scope. What did it touch after enumerating? Group enumeration is usually the step before privilege escalation, so I am looking for subsequent access to something it does not normally reach, or additions to privileged groups.
Then origin. Where is this credential supposed to live — a config file, a vault, a CI runner? If the answer is a file share or a pipeline variable, my working hypothesis becomes credential theft from that location, and I would look for who read it.
In parallel and immediately: I would not wait for certainty to contain. Rotating that credential is cheap and reversible, and if the account is genuinely compromised then every minute of enumeration is more reconnaissance. I would rotate, then confirm.
What would refute it: a change record showing someone deliberately ran an audit script from a new location. That is the first thing I would check, because it is the most common benign explanation and it takes two minutes.”
Naming the real anomaly rather than the obvious one, containing before confirming, and stating what would refute the hypothesis. Candidates who investigate to confirm rather than to test are the ones who chase false positives for hours.
- Write detections and put them in git, with tests. Sigma rules are portable and a public repository of them is a very strong artefact.
- Know one telemetry source deeply — Windows event logs, cloud audit logs, EDR — rather than five superficially. Depth is what triage speed comes from.
- Have an alert-to-action number from somewhere you have worked, and what you did about it.
- Map to MITRE ATT&CK, and be able to say where your coverage is genuinely thin rather than claiming broad coverage.
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $120k – $220k base | Detection engineering pays well above tier-one analysis |
| India | ₹10L – ₹40L total | Huge market including managed-service SOCs; product-company SOCs pay far more |
| Both | — | Writing code is the difference between the bottom and the top of these bands |
The book for this field
Security Engineering & Tooling
What each category of security tool structurally cannot see, what the evidence actually supports, how the market consolidated, and what the 5,197 postings say the job is.
Also read for this role
Infrastructure & Reliability
Reliability and error budgets, capacity arithmetic, networks, storage and the restore you have not tested, the physical layer, a debugging method that transfers, running production, and an honest look at Kubernetes. Plus a Middleware section — web and application servers, messaging (IBM MQ, Kafka) and managed file transfer, from basics to licensing and cost.
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 12 Security questions → · Back to Cyber, Risk & Internal Audit →