One of the largest distribution companies in Lebanon got hacked recently. The attackers took the database, cut the company's access to it, and called asking for money to give it back.
The company ignored the calls. They trusted their developers โ the system was built properly, surely there was a way back. There wasn't. The database is gone, and a business that moves millions of dollars of goods has been close to a week without operating. Nobody knows exactly what should be delivered, which customers owe what, or what's already been paid. Right now, staff are going through the paper trail to rebuild it by hand.
A multi-million-dollar company, running on printed receipts, because of holes that should never have been there.
Trust was the security plan
I don't blame the owners for trusting their developers. That's what you're supposed to do. A business owner can't audit code, can't tell a safe database configuration from a dangerous one, and shouldn't have to. He hires people for that.
Which is exactly why this is on the developers. When the client can't check your work, the responsibility doesn't shrink. It gets bigger. Security doesn't show up in the demo, nobody asks for it in the spec, and the client will never notice it's missing โ right up until the day it's the only thing that matters.
Ignoring a ransom demand is the right call if you have backups. Without them, it isn't a decision. It's a gamble.
The company made a reasonable choice based on a belief about their system. The belief was wrong, and nobody had ever tested it.
The questions nobody could answer
I don't have the incident report, and I won't pretend to know the exact way in. I don't need to. These are the questions any developer should be able to answer about any system they've shipped โ and in this case, clearly, somebody couldn't:
- Where are the backups? Not "we have backups." Where, exactly, and when was the last one taken?
- Where are the off-site backups? A backup sitting on the same server, or the same network, goes down with it. Attackers look for backups first, precisely because they know this.
- Has anyone ever restored one? A backup nobody has tested is a hope with a file extension.
- Why could the attacker reach the database at all? A database shouldn't be reachable from the internet. Only the application server should talk to it.
- Why could the attacker delete everything? The account the application uses shouldn't have the power to drop the database. Most of the time, it's running as the all-powerful admin account because that was easier during development.
- Was SQL injection possible? It's one of the oldest holes in the book. Every modern framework closes it by default. It's still out there, in systems built by people who concatenated user input into a query because it was faster.
None of those are advanced security questions. They're the software equivalent of asking whether the doors lock.
Developers don't need to be security experts
I want to be fair here. I'm not saying every developer should be a penetration tester or hold a security certification. That's a separate profession, and a serious one.
An electrician isn't a firefighter. But an electrician who leaves bare wires behind a wall isn't a good electrician, and nobody would accept "I'm not a fire expert" as an excuse. The standard for developers is the same: you don't have to know how to fight every attack, but you do have to not leave the holes.
And the holes get found faster than ever. Access to data is easy now โ automated scanners sweep the internet around the clock looking for exposed databases and known weaknesses, and the tools to exploit what they find are cheap and widely available. Nobody has to target you specifically. An open door gets found whether or not anyone was looking for your door. I wrote about how quickly large Lebanese databases have fallen before. This is the same story with a ransom note attached.
The basics that belong in every system
We're developers too, so here is the standard we hold ourselves to. This is not a security programme. It's the floor โ the things that should be in every system before it goes live, whether the client asked or not:
- Parameterized queries, always. User input never gets glued into SQL. The framework already does this correctly; stop working around it.
- The database is not on the internet. It sits behind the application, reachable only from the servers that need it.
- Least privilege. The application's database account can read and write what it needs and nothing more. It cannot drop tables. It is not the admin.
- Automated backups, with a copy off-site. At least one copy lives somewhere an attacker who owns your server can't reach or delete.
- Restores are tested. On a schedule, by actually restoring. You find out a backup is broken on a quiet Tuesday, not on the worst day of the year.
- No passwords in the code, no default passwords anywhere. Credentials live in configuration, and every default gets changed before launch.
None of that list is expensive. Most of it is a few days of work at the start of a project, and some of it is literally a setting. The cost of skipping it is the rest of this post.
What a week without a database costs
Do the honest calculation. Every day the system is down, trucks don't go out, or go out on guesswork. Collections stop, because nobody can prove who owes what. Staff are on the payroll to read paper receipts. And customers who can't get their orders start calling the competitor โ some of them won't come back when the system does.
Put that next to what it would have cost to have off-site backups and a locked-down database from day one. There's no comparison. There never is, and that's the part that frustrates me most: this was never a budget problem.
If you build software for a living, security is part of the job, whether it's in the spec or not. If you own a business that runs on software, you're allowed to ask.
