Most disaster recovery plans assume the cloud provider is the part that survives. The attack on IDC Frontier is a reminder that this is an assumption, not a guarantee. The SoftBank Group subsidiary says it detected unauthorised activity on 7 October in its IDCF Cloud service, and that a disruption in its East Japan Region 1 was caused by a ransomware attack from a third party. teiss reports that the company puts the number of affected organisations at 495, a mix of businesses and local governments.
What is known, and what is only claimed
The confirmed part is short. The attack began in the early hours of 7 October, the affected systems were isolated and shut down, customer access to management consoles was disabled across all regions, and the company is checking whether other regions are affected. It has brought in outside specialists and told the police. It has not named the attacker, given a restoration date, or said whether data was stolen.
The larger numbers come from the attackers. Per screenshots from customers cited by BleepingComputer, and relayed by Aviatrix, the actor says it got in and finished its work within seven minutes, claiming 225 encrypted databases (3.6 PB), 239 hypervisors reached, 16,000 virtual machine disks sealed and 554,153 snapshots wiped. None of that has been verified by IDC Frontier, so treat it as a boast. The shape of it still matters: the claimed target was the hypervisor layer and the snapshots, which is exactly where a customer's own "restore from snapshot" plan usually points.
BleepingComputer also notes that a separate Japanese firm, Nissui Logistics, suffered an outage tied to suspected unauthorised access at a third-party data centre. The two are not confirmed to be linked, and we would not draw a line between them yet.
The lesson is about where the copies are
If your snapshots, your backups and your production workloads all sit in the same provider region, a provider-side compromise treats them as one thing. Cloud providers draw a line between what they secure and what the customer secures, but that line says nothing about what happens when the provider's own control plane is the thing that gets hit. In a case like this, the customer's controls are largely irrelevant and the customer's copies are all that is left.
Questions to put to your own estate this week
- For each critical system, name the one copy of its data that would survive the loss of your primary provider region. If the answer is "a snapshot in the same region", you do not have one.
- Check whether that copy is immutable and held under credentials that nothing in the primary environment can reach.
- Look at who can restore. If the restore process needs the provider's management console, and the console has been switched off for everyone, what is the plan?
- Write down which of your suppliers are hosted on the same provider. Your outage may be your payroll supplier's outage too.
- Do a table-top with a specific scenario: the provider tells you on a Wednesday morning that a region is gone and cannot give a date. What do you tell customers by lunchtime?
- Decide in advance what a "good enough" degraded service looks like, and who is allowed to declare it.
None of this requires abandoning a provider. It requires treating the region as a failure domain that can be lost entirely, and testing that belief at least once. If you want an outside review of your recovery design, email sales@halfteck.com.