After the Phishing Email: A SACCO With No Logs
A savings cooperative with 60 staff across eight branches lost KES 2.3 million after a finance officer entered credentials on a lookalike login page and an attacker approved three transfers over two days. The investigation found that all eight branches share one domain administrator account whose password is written in a drawer at head office, that workstation logs are kept only locally and overwritten weekly, that USB ports are unrestricted, and that no one reviews who approves transfers above KES 500,000. The board has approved KES 6 million for remediation and wants visible improvement within 90 days. Staff are already complaining about any control that slows payments.
1. Rank the remediations by risk reduction per shilling and justify why the cheapest controls come first rather than the most technically impressive ones.
Read the worked answer
Ranking
- Remove the shared domain administrator account; issue named admin accounts and a password vault (≈KES 200,000). This is the single highest-leverage fix. A written-down shared password means every one of the 60 staff, plus any visitor to that drawer, is effectively a domain administrator. Named accounts also make logs attributable, which every later control depends on.
- Enforce multi-factor authentication on email, VPN and the core banking portal (≈KES 400,000-800,000). The incident was a credential theft. MFA breaks that specific attack chain at near-zero operational cost to staff, since it triggers on login, not on every payment.
- Centralise logging and retain 90 days (≈KES 500,000). Local logs overwritten weekly mean the two-day attack window may already be gone. Without retention, the institution cannot detect or investigate the next incident. Note this is ranked below MFA because detection without prevention still allows the loss.
- Dual approval for transfers above KES 500,000, with segregation between initiator and approver. Costs little in cash, but it is ranked fourth because it depends on items 1 and 3 to be meaningful: with a shared admin account, an attacker can alter the approval trail.
- USB port control and endpoint protection. Real but slower-moving risk compared with an active attacker using stolen credentials.
Why cheap first. The ranking is driven by which control breaks the observed attack chain, not by price or sophistication. A firewall upgrade would have stopped none of this.
2. The attacker was never identified and the money left the cooperative's account. Should the incident be reported externally, and to whom? Justify the decision.
Read the worked answer
Report. The decision is not discretionary once customer funds and personal data are involved.
Who
- The banking partner and payment switch operator immediately, because recall of the three transfers is time-limited; every hour reduces recovery odds.
- The financial sector regulator within its prescribed incident-notification window. A KES 2.3 million fraud at a regulated deposit-taking institution is a reportable operational risk event regardless of recovery.
- The data protection authority if any customer records were exposed. Credential compromise on a finance workstation should be treated as possible unauthorised access until proven otherwise; the assessment must be documented either way.
- Law enforcement for the fraud itself.
Reasoning against silence. Arguments for keeping it internal are reputational and the fear of supervisory action. But the loss is already discoverable through reconciliation, and late notification is treated more severely than the incident itself in most supervisory frameworks. Silence also destroys the institution's ability to recover funds through the payment chain.
Practical step. Preserve evidence first: export logs, image the affected workstation, and record chain of custody before rebuilding it, otherwise the report cannot be substantiated.
3. The board asks for a 90-day plan with measurable evidence of improvement. What would you commit to, and what would you explicitly refuse to promise?
Read the worked answer
Commit to (measurable)
- Days 0-15: contain. Disable the shared admin account, reset all privileged credentials, revoke active sessions, image the affected machine. Measure: zero shared privileged accounts in the directory.
- Days 15-45: prevent. MFA on email and banking portal for all 60 staff. Measure: percentage of accounts enrolled, target 100%, with exceptions listed and time-limited.
- Days 30-60: detect. Central log shipping from all eight branches, 90-day retention, and two alert rules (impossible travel, after-hours transfer approval). Measure: log coverage per branch and mean time to alert on a simulated test.
- Days 45-75: control. Dual approval above KES 500,000 with system-enforced segregation. Measure: sample 20 transfers and confirm no single-person approvals.
- Days 75-90: prove. One tabletop exercise replaying this exact attack. Measure: time to detect and time to contain, recorded and reported to the board.
Refuse to promise
- That no breach will occur in 90 days. That is not a deliverable any control set can guarantee, and promising it would be dishonest.
- That staff will not be inconvenienced. MFA and dual approval will slow payments; I would state the expected delay (seconds per login, one extra approval per large transfer) rather than deny it.
- That the KES 2.3 million will be recovered. Recovery depends on the banks and is outside the institution's control.