Careers / Detection
Detection Engineering at ManySignal
Detection engineers at ManySignal write the rules that decide what matters. Their work runs in the triage engine on every alert, for every customer, continuously. The stakes are real.
MITRE ATT&CK techniques covered
1,142
across Endpoint, Cloud, Identity
Rule updates shipped last quarter
847
average 65 per week
Mean time to new detection (MTTD)
< 48 hrs
from published CVE or intel report
Detection library false-positive rate
0.34%
measured quarterly across all tenants
The work
What you will do
-
Research attacker tradecraft across endpoint, network, cloud, and identity layers and translate findings into high-fidelity SIGMA and ManySignal-native detection rules
-
Tune behavioural baselines and statistical thresholds to reduce false-positive rates without degrading true-positive recall — and document every tuning decision with evidence
-
Build and curate the threat-intelligence feeds that inform the entity graph and power automated threat-context enrichment in the triage pipeline
-
Partner with engineering to implement new detection capabilities — you will write production detection logic, not just specifications
-
Publish adversary-tracking research and detection guidance on the ManySignal blog and contribute to the security community through conference talks, open-source rule sets, and threat intelligence sharing
-
Conduct red-team emulation exercises using Atomic Red Team and custom tooling to validate detection coverage across the MITRE ATT&CK framework
-
Review and triage false-negative reports from customers, investigate root cause, and ship improved rules within 72 hours for high-severity gaps
The person
Who you are
We value practitioners who have written and operated detection rules under pressure. Academic background is irrelevant; demonstrated capability is everything.
-
A practitioner first — you have written detection rules in production environments and understand the difference between a rule that fires in a lab and one that works at scale
-
Fluent in query languages used in production SIEMs: KQL (Sentinel), SPL (Splunk), EQL (Elastic), or equivalent — SIGMA is a plus
-
Familiar with the attacker's perspective: you understand common lateral movement, persistence, and exfiltration techniques well enough to write detections that survive evasion attempts
-
Comfortable with Python for data analysis, rule generation, and automation of detection-validation workflows
-
A clear technical writer — detection logic, threat research, and rule tuning decisions must be documented so the whole team learns from your work
-
Interested in applying machine learning and statistical analysis to detection problems, even if you are not currently a data scientist
Hiring process
How we hire detection engineers
We test what we actually need: rule-writing quality, threat knowledge, and communication. Nothing abstract.
Recruiter screen (30 min)
Introductory conversation about your background in detection engineering and your experience writing and operating detection rules in production.
Detection research conversation (60 min)
A deep technical conversation with our VP of Research about a threat you have tracked or a detection you are proud of. Bring a specific example — we want to discuss it in detail.
Detection challenge (take-home, 3–5 hours)
We provide a realistic set of log samples and a hypothetical attacker scenario. You write detections, document your reasoning, and explain coverage gaps. This is the closest thing to the actual job.
Rule review and defence (60 min)
You walk the team through your detection challenge submission, explain your rule logic, discuss tuning decisions, and take questions. This is a conversation, not a test.
Cross-functional panel (45 min)
Conversations with an engineer and a customer success manager to explore how you collaborate across teams and communicate technical findings to non-technical stakeholders.
Offer
We target a 3-week end-to-end process. References run in parallel with the offer stage.
Detection engineers own the outcome
Every rule you ship runs against real attacks in real customer environments. That accountability is the point. If that sounds like the right level of stakes, we want to talk.
Apply to detection engineering