Who's Still Hoarding Millions of Records?

# Who's Still Hoarding Millions of Records? I’ve spent most of my adult life cleaning up digital crime scenes. When I started in the early 2000s, we were dealing with worms like Code Red—things that moved fast and broke things because they could. Today, the speed is still there, but the appetite has changed. Attackers aren't just trying to crash your server; they're treating your databases like a buffet. Look at this week's tally. We’ve seen 395 data breaches. Let that number sink in. That isn't a "spike." It's a baseline. If you're running a business and you think you're safe because you haven't heard the alarm, you're just the only person in the room who hasn't noticed the house is on fire. The scale is what gets me. We’ve got three UK airports losing data on 8.7 million customers. Then we have a general healthcare breach exposing 3.75 million patient records and Baylor Genetics dropping another 2.8 million. That's over 15 million people whose private lives are now sitting on some forum for the price of a few Bitcoin. Whenever these stories break, the corporate PR teams release a statement saying they were hit by a "sophisticated" attack. I hate that word. It’s a lie used to hide the fact that someone probably left an S3 bucket open or failed to patch a known flaw for six months. If it were sophisticated, it wouldn't be happening 395 times a week. Most of this is just basic hygiene failure scaled up to a catastrophic level. The real question isn't how they got in. The question is why the blast radius was so enormous. Why does one compromised credential or one zero-day in something like Metabase—which hit Tixel recently—give an attacker the keys to the entire kingdom? It’s about data hoarding. We keep every scrap of info "just in case" it's useful for marketing or analytics three years from now. But you aren't just storing data; you're storing a liability. Every record is a tiny piece of radioactive waste. When you hoard millions of them in one place, you aren't building an asset. You're building a bomb. The second-order effect here is the real nightmare. If you're one of those 8.7 million airport passengers, your problem isn't just that a hacker has your email. It's that they might have passport numbers and travel patterns. That doesn't stay in a vacuum. It flows downstream to identity thieves who can now spoof your identity at a border or open credit lines in your name for the next decade. The airport is the victim today, but the passengers are the victims for the next ten years. Some of you will argue that this data is necessary for business operations—that you can't run a modern airport or a genetics lab without massive centralized databases. Maybe. But I’ve seen what happens when the walls come down. During NotPetya, it wasn't just about the encryption; it was about the total loss of visibility and control. The only thing that saved people back then—and now—was a clean, offline backup and a very small blast radius. If your architecture allows one breach to compromise millions of records, you don't have a security problem. You have an architectural failure. *** **MAILBAG** **Gary from Omaha: "I see all these healthcare breaches in the news. I run a small clinic and we use a few different software vendors for our patients. If they get hit, am I responsible? What should I even be doing?"** Gary, here is the cold truth: the regulators and the lawyers won't care that it was your vendor's fault. They'll see your patients' data leaked and they'll come to you. Stop looking at your vendors as "safe" boxes where you put your problems. Assume every single one of them is already breached. The move here isn't more software; it's less data. Look at what you're sending those vendors. Do they really need the full social security number for every entry? Do they need to keep records from 2012? If you don't have a strict data retention policy—meaning you actually delete things once they aren't legally required—you are just volunteering to be a victim. Figure out what you can prune. It's much harder to steal data that doesn't exist. **Sarah from London: "I'm a junior admin and I've been told that as long as we have MFA on everything, we're pretty much safe from the kind of session hijacking I'm reading about with those Claude AI accounts. Is that true?"** Sarah, you're asking the right questions, but I have to give you the bad news. MFA is a great first step—it stops the low-hanging fruit—but it isn't a magic shield. Those infostealers hitting Anthropic users aren't guessing passwords; they're stealing active session tokens. Once a user is logged in, the attacker just clones the cookie and walks right through the door, MFA and all. It's like someone stealing your keycard after you've already been buzzed into the building. Don't let your team get complacent. Shorten your session timeouts and teach people that "logged in" doesn't mean "safe." You're doing fine, just keep questioning the "silver bullets." **Marcus from Berlin: "We're seeing more zero-days like the Metabase one hitting our peers. We patch as fast as we can, but it feels like we're always behind. Should we be investing more in an AI-driven detection system to catch these faster?"** Marcus, please stop chasing the shiny objects. An "AI-driven" tool is just another piece of software that can be misconfigured or breached. If a zero-day hits your Metabase instance and it allows the attacker to dump your entire customer list, the problem isn't that you didn't "detect" it in milliseconds. The problem is that your database was reachable from the web server without any internal segmentation. Ask yourself: what would this cost me on a Tuesday? If the answer is "everything," then your network is too flat. Stop spending your budget on tools that promise to predict the future and spend it on locking down your internals so that when—not if—a zero-day hits, the attacker finds themselves trapped in a tiny room with nothing to steal. That's the only way to sleep through the night.