IIBF Emerging Technologies study materials
IIBF Emerging Technologies study resources

Ransomware at 11 pm Through a Vendor's Laptop

IIBF Emerging Technologies · Put your knowledge to work in context.

All case studies

Ransomware at 11 pm Through a Vendor's Laptop

Suryodaya Retail Finance, an NBFC-MFI with 480 branches and ₹6,000 crore of assets under management, finds files on its loan-origination servers encrypted on a Friday night. The entry point appears to be a remote-access tool used by a third-party IT support vendor whose engineer's laptop was compromised. The attacker claims to hold 900,000 customer records including PAN, bank account numbers, loan schedules and masked Aadhaar. Lending is down; branches are recording collections on spreadsheets. The attacker is asking 3 BTC for a decryptor. The CEO wants to pay, 'get it over with', and delay informing anyone until the weekend is over. It is 11 pm; the incident was confirmed at 9:40 pm. The CISO is on leave and unreachable. The vendor's contract has no security clauses, no audit rights and no breach-notification obligation; the vendor is a proprietorship.

1. Set out the actions to be taken in the next six hours, including who reports what, to whom, and by when.

Read the worked answer

Clock first. Notice occurred at 21:40, so the CERT-In 6-hour deadline falls around 03:40 on Saturday and cannot wait for the CEO's comfort. RBI's cyber security framework expects incident reporting within 2–6 hours; the CISO's leave is irrelevant to the obligation.

Sequence:

  1. Contain without destroying evidence. Isolate affected servers at the network layer; do not power off - memory and volatile artefacts matter. Snapshot volumes. Revoke the vendor's remote-access credentials and all sessions immediately.
  2. Activate the incident response retainer and declare a crisis call at 23:30 with MD/CEO, ops head, legal and the board's audit committee chair.
  3. Report. CERT-In in the prescribed format via the portal; RBI in parallel. A named alternate for the CISO must be authorised tonight to sign these off. Prepare for the follow-up and final reports.
  4. Restore from clean backups. Verify integrity and confirm backups were not encrypted - that determines recovery time and therefore whether this is a one-day or one-week outage.
  5. Notify counterparties - the co-lending bank, the payment partner, and UIDAI if Aadhaar-linked data is confirmed exposed.
  6. Preserve logs and chain of custody; brief forensic counsel.

Delaying disclosure over a weekend is itself a reportable governance failure and converts a technical incident into an enforcement one.

2. The CEO wants to pay the ransom. Give your advice, with the reasoning the board should minute.

Read the worked answer

Advise against payment, and record the reasoning so the decision is defensible either way.

Why not:

  • There is no assurance of deletion. The claim of 900,000 records cannot be verified, and paying does not extinguish the breach-notification obligation - the data is already out.
  • Decryptors frequently fail or are incomplete; the real recovery path is clean backups, which the team is testing anyway.
  • Payment funds criminal infrastructure and carries sanctions and banking-counterparty risk via the wallet used.
  • It creates a documented precedent that this institution pays, inviting re-attack.
  • Lending recovery does not depend on the decryptor if backups are intact; it depends on how fast a clean environment can be stood up.

The decision is the board's, not the CEO's alone, and must be minuted: options considered, backup restoration status, legal advice, and the residual risk accepted. If the board nonetheless decides to pay, it needs external counsel, a sanctions screen on the wallet, a disclosed and documented rationale, and an immediate hardening plan - because payment treats a symptom, not the loss of control that let a proprietorship vendor's laptop reach production servers.

Either way, the parallel workstream is identity: every third-party credential in the estate gets inventoried by Monday.

3. The vendor contract is silent on security. What should the remediation programme cover - contractually and technically?

Read the worked answer

Treat this as a third-party risk failure, not a malware problem.

Contractual: inventory every vendor with remote access and tier them by privilege and data access. For material vendors, re-paper with: security baselines as obligations; mandatory MFA on all access; named personnel and prior approval for changes; incident notification to the NBFC within 24 hours; right to audit and on-site inspection; no sub-contracting without consent; data return and verified deletion; liability and indemnity for breach; termination and transition assistance. A proprietorship with no security posture should not hold production access at all.

Technical: remove direct vendor access to production. Put privileged access behind a vaulting solution with just-in-time approval, session recording and full keystroke logging; force access through a jump host; put endpoint detection on vendor devices or issue bank-managed devices; segment vendor networks from the core; alert on any access outside agreed windows.

Governance: a board-approved third-party risk policy with ownership, annual assurance for tier-1 vendors, and a register reviewed quarterly. RBI's outsourcing direction is explicit that the regulated entity remains responsible for the activity - 'the vendor did it' is not a defence. Assign a permanent owner for the vendor register and report the remediation plan to the audit committee within 30 days.