Sony Network Communications has confirmed a data breach that compromised approximately 2.5 million records containing current and former customers' personal information. The company's investigation put the final figure at 2,585,481 customer records. The breach occurred on October 19 and was detected four days later.
What happened
The internet service provider subsidiary said the exposed data covers both current and former customers. In the breakdown of exposed records, Sony Network Communications says there are 2,141,986 So-net entries and 443,495 plala (S Course) records.
An additional 54,401 email addresses from several email services were also exposed along with account passwords. That detail matters more than the record count alone, because exposed credentials can be replayed against other services where customers reused them.
The investigation confirmed that a total of 2,585,481 customer records had been exposed.
How it was done
The published account does not describe the initial access method or the party responsible. What is stated is the timeline and the response: the breach occurred on October 19 and was detected four days later, when the company shut down the compromised servers and blocked external communication.
The four day gap between the event and its detection is the part worth studying. Anything that sits on a server holding subscriber data for several days has time to enumerate, stage and move records out. The containment steps named, taking servers offline and cutting external communication, are the standard pair once an exposure is confirmed.
What to check
Use this as a prompt to test detection and containment on the systems that hold your subscriber or customer data.
Measure your actual detection delay
Pull the last few incidents or detection tests from your SIEM and compare the event timestamp with the first alert timestamp. Run a controlled bulk read against a non production copy of a customer table and time how long it takes to fire. If nothing alerts within hours, your coverage is reporting rather than detecting.
Alert on bulk reads from customer datastores
Enable database audit logging, for example pgaudit on PostgreSQL or the MySQL audit plugin, and build a rule on row counts per query and per session. A query returning hundreds of thousands of rows from an account that normally returns dozens should page someone.
Inventory what each server can reach outbound
List the egress rules on security groups or firewall policies for every host holding personal data. Check for any default allow to 0.0.0.0/0 on ports 443, 22 or 53. Servers that only serve internal traffic should have no general outbound path at all.
Confirm you can isolate a host quickly
Document and rehearse the exact steps to detach a server from the network while keeping disk and memory intact for analysis. Time the drill. If isolation requires a change ticket or a vendor call, fix that before you need it.
Review how account passwords are stored
Check the hashing algorithm and work factor in your authentication service configuration. Anything other than a modern slow hash such as bcrypt, scrypt or Argon2 should be scheduled for migration, and plaintext or reversible storage is an immediate finding.
Check retention for former customers
Query your customer tables for records with no activity past your stated retention window. Former customer data that is still live expands every future exposure. Confirm the deletion job exists, runs and logs what it removed.