Detection Requirements After a Missed Mailbox Forwarding Rule
At 02:14 a finance analyst's mailbox began auto-forwarding invoice PDFs to an external Gmail address. The rule was discovered 11 days later when a supplier called about an unpaid invoice. The SOC has four analysts across two shifts, a SIEM with 340 enabled rules producing roughly 1,900 alerts per week of which about 60 are investigated, and mean time to acknowledge of 19 hours. The only rule covering mailbox forwarding was disabled in 2019 and never reviewed. Invoice fraud cost $120,000, of which $70,000 was recovered. The CISO has asked for a requirements document for "improving detection" and has already named a specific EDR product in the request. There is no logging standard: three business units send logs to different SIEM tenants, and the finance SaaS keeps audit logs for only 30 days.
1. The CISO has pre-selected a product. How do you keep the requirements credible without appearing to obstruct?
Read the worked answer
I would not fight the product choice; I would make the requirements independent of it and let the choice be evaluated against them.
Approach:
- Start from the problem, evidenced. The incident timeline gives the business need: an unauthorised forwarding rule existed for 11 days undetected, and the data to detect it existed but was not used. That is a requirement about coverage and data availability, not about EDR.
- State the scope boundary explicitly. Requirements cover what must be detected, how quickly, with what data, and who responds - and note that endpoint EDR does not address a cloud-mailbox rule. This is a factual gap statement, not an objection to the product.
- Evaluate the named product against the requirement set as one option among others, recording where it satisfies, partially satisfies or fails each requirement. If it passes, the CISO gets a defensible purchase; if it fails on the mailbox scenario, the evidence does the arguing.
- Document the assumption that a tool decision may precede requirements, and the risk that follows: requirements written to fit a chosen tool tend to omit exactly the scenarios the tool does not cover - here, the one that caused the loss.
2. Write detection and logging requirements for the forwarding scenario, including where the needed data does not yet exist.
Read the worked answer
Detection requirement (example form): The organisation shall detect creation or modification of mailbox forwarding rules to external domains and raise an alert to the SOC queue within 15 minutes of the change. Fit criterion: a test rule created in a controlled mailbox generates an alert within the stated time, evidenced by timestamps in both systems.
Supporting requirements the detection depends on - these are where the real gaps are:
- Data availability: Audit events for mailbox rule changes shall be retained for 12 months and streamed to the central detection platform in near real time. Today the SaaS retains 30 days and the data lands in three separate tenants; the requirement cannot be met without a collection and routing change. I would write it anyway and let the gap analysis, not the current state, drive the design.
- Coverage: an inventory requirement - all log sources in scope shall be enumerated with owner, format, latency and retention - because "three tenants" means nobody currently knows what is missing.
- Response: an alert that nobody actions is not a control. Requirement for triage ownership and a defined response step for this alert class.
- Verification: each detection requirement is tested by simulation before go-live, and retested quarterly, which also catches rules disabled and never reviewed.
Note the chain: detection quality is bounded by data retention and routing, so those requirements must be prioritized alongside the detection rules, not after them.
3. With four analysts and 1,900 weekly alerts, which requirements do you prioritize, and how do you justify deferring others?
Read the worked answer
The binding constraint is analyst capacity, not detection coverage, so I would prioritize requirements that improve the signal-to-noise ratio before those that add rules.
Priority 1 - make the queue trustworthy. Requirements for alert triage criteria, a severity scheme, and retirement or tuning of rules with a demonstrated false-positive rate. 1,900 alerts for four analysts is roughly 68 per analyst per week; the 19-hour acknowledgement time and 60 investigations suggest the queue is being skimmed. Adding detection on top of this makes the missed-rule problem worse, not better.
- Fit criterion: alerts requiring investigation per week, and mean time to acknowledge, measured before and after.
Priority 2 - the scenarios that caused loss. External forwarding, impossible-travel-free sign-in from new geography combined with a mail rule, and invoice bank-detail change. Chosen because they are evidenced by the incident, not because they are easy.
Priority 3 - coverage expansion to the under-logged business units.
Deferred, with reasons recorded: broad new rule packs from the EDR product, and threat hunting. Deferral is justified by capacity arithmetic and by the fact that these do not address the detected failure mode; each deferred item carries a review date and the risk owner's name so it is a decision, not an omission.