A client-reported invoice fraud closed as spam: where the process broke
A Singapore-headquartered wealth manager (3,000 staff, S$14bn AUM) outsources level-1 triage to a service desk in Kuala Lumpur. On 3 March a client emails her relationship manager about an invoice 'from' the firm carrying the firm's logo, the correct supplier name, and a changed bank account number. The relationship manager forwards it to the service desk at 11:20. The agent selects category 'spam/phishing - blocked' and closes the ticket at 13:05 without contacting security. On 12 March the client's finance team pays S$480,000 to the fraudulent account; the bank recovers S$90,000. In the same week, a security researcher emails the press office about an unauthenticated API endpoint returning client statements, giving 30 days before publication. Both land with the CISO within an hour of each other. The service desk SLA reads 'all tickets acknowledged in 15 minutes, resolved within 4 hours', with no security-specific routing and no on-call security contact outside business hours.
1. Map the failure against the ISO/IEC 27035 process stages and identify the decision point that was missing.
Read the worked answer
Detect. Failed in substance. The signal existed - a client telling the firm that an invoice with its branding carried a changed account number - but was not recognised as a security signal. Detection includes human reports, not only tooling; a customer is a sensor.
Report. Failed at routing. The relationship manager reported to the right place on paper, but no path existed from the 'spam' category to the security function, and no out-of-hours contact existed at all. ISO 27035 expects a known reporting channel with escalation to the incident response team.
Assess and decide. Did not happen. This is the missing decision point: an authorised person must decide 'incident or not' against defined criteria, with a timestamp. The service desk agent was neither authorised nor equipped to make that call, and the taxonomy gave them a false terminal state.
Respond. Impossible, so the nine-day gap contained no containment: no bank recall, no client warning, no mail-gateway block, no lookalike-domain monitoring.
Learn. No feedback reached the relationship manager who did the right thing, so the behaviour will not repeat.
The design fault is the SLA. 'Resolved within 4 hours' measures closure speed and actively rewards closing rather than escalating. For a phishing report the correct outcome is frequently 'escalated, not resolved', and an SLA that cannot express that will keep producing this failure.
2. Design triage criteria and routing so that a report like this reaches the incident response team. Specify what the agent must capture and the timings you would impose.
Read the worked answer
Routing. Add a security queue reachable with one click from the ticket form, with automatic notification to an on-call security duty officer. The agent's job is classification-by-question, not judgement: Did this involve our brand, our domain, our suppliers, money movement, credentials, or client data? Any yes routes to security. That single question catches this case.
Mandatory capture fields (required to close): reporter and time received; time forwarded; sender address and domain, reply-to, headers where available; the account number and bank quoted, plus whether they match the supplier master record; whether any client or staff member is known to have acted on it; attachments and links left unopened.
Timings. Security queue acknowledgement 15 minutes; duty officer decision 30 minutes; if a payment may already have been made, an immediate phone call to the finance fraud line rather than a ticket. Out-of-hours coverage is a rota with a named deputy, not a mailbox.
Do not let 'blocked' close anything. Blocking a sender contains one message, not the campaign; the fraudulent account stays live and other clients remain exposed.
Feedback to reporters. A two-line outcome note to the relationship manager within 48 hours. Reporting is a control and it decays without acknowledgement.
Measure the right thing: time from report to security decision, and proportion of client-originated reports that reached security within the hour - not ticket closure rate.
3. How should the researcher's API report be handled within the same process? What distinguishes it from the phishing incident, and which decisions are needed?
Read the worked answer
Same process, different entry point. A vulnerability disclosure is not itself an incident; it becomes one on confirmation that the endpoint is exploitable and client statements are exposed. ISO 27035 handles this at assess-and-decide: verify, then classify. Because statements are returned without authentication, I would treat it as an incident on confirmation - confidentiality of client data is a regulated harm.
Decisions, in order:
- Verify within 24 hours - reproduce in production safely, read-only with one test account, and establish scope: authentication bypass, or only missing authorisation, and how many statements are retrievable.
- Contain - disable the endpoint or place it behind gateway authentication. Faster than a code fix and it shrinks the notification question.
- Preserve - access logs for that endpoint, to establish whether anyone else used it. Without this you cannot answer 'were clients affected?' and cannot decide notification.
- Engage the researcher - one named contact, acknowledge, agree a disclosure timeline, ask whether they will hold publication. Do not threaten and do not ask them to delete evidence.
- Legal and regulatory - a separate personal-data assessment from the fraud track, run in parallel rather than sequentially.
Key judgement. The 30-day publication clock can often be extended by good-faith engagement, but only if engagement starts on day one. Silence is what converts a researcher into a press story. Keep the two matters in separate register entries but under one incident manager, so that shared facts - client data, the same client base - are not assessed twice.