Yes, water based sprinklers are not the best choice for inside the server-room proper. But that doesn't mean you can't have other automated fire suppression systems. In the days of yore Halon systems were mostly used for this particular application. Halon has some issues though and has mostly been banned / replaced with cleaner alternatives. These days you see things like FM-200 used for fire suppression in these kinds of applications.
All of that said, speaking as a former firefighter, I'd take a water based sprinkler over nothing, even in that setting. Why? Because at the end of the day, human life is more valuable than a data-center full of computers and data, and if stopping a fire early saves even one life, but ruins a room full of computers, that's an acceptable tradeoff. And of course sprinklers are absolutely invaluable outside of the server-room. I don't have all the numbers memorized now, but to summarize in a succinct form, "sprinklers are wildly effective at preventing incipient stage fires from growing large, and at saving lives and property."
And as @WalterBright continues to say below - you are storing backups off-site, right? And you have a DR data-center on another continent that can be spun up in a matter of minutes by toggling a load-balancer or DNS setting somewhere, right?
Even counting 9-11, as the plane crash cut the water pipes.
But still, relying on sprinklers to save your IT business is a bad idea. Offsite backups are needed.
Yep, totally agreed. Resiliency comes from having offsite backups, cold/warm standby sites, testing your backups and ability to switch to the DR site, etc. The sprinklers are mainly about saving human lives.
Sure you install sprinklers in a data center to sprinkle water on servers and other electric devices in a context where there might or might not be broken or other wise un-isolated wires due to the fire...
What you can use instead is to flood the room with CO2 to suffocate the fire.
The problem with that is that it's also deadly to humans.
Still e.g. for rooms with long term data storage it's not uncommon to have measurements like that.
Besides that there are docent of other reasons why a data center might go down (temporary).
So the better answer is make sure you system is distributed over multiple data center, i.e. eliminated any single point of failure.
And even a closed door in a residential building can slow things down enough to make the difference between life and death. This is why the fire service encourages people to sleep with their bedroom doors closed and to have a smoke detector near said bedroom door.
The downside to a heavily partitioned building, especially a very large building, is that it may become a maze that is hard to exit, and lots of doors between different areas slightly increase the risk that somebody will have a brain-fart and lock/chain doors that should never be locked, or otherwise do something that effectively traps people inside. Note to everybody: never chain/lock/barricade a door that must be used to exit a building in an emergency, in such a way that it can't be opened from the inside.
1. don't store everything on the machine(s) accessible via that root password
2. don't allow any employee unfettered access to everything
3. don't allow one piece of software to have access to everything
4. do not store backups in the server room, or even in the same building
5. buy computers that do not have USB support in any form
6. full disk encryption on laptop. Minimize sensitive data on laptop. Use smallest capacity disk drives on laptop. Don't allow any laptops to have access to secure network. Issue hardwired desktops to employees. No wifi to secure network.
Neither detection or prevention can be perfect like nothing human-designed, but rather detection should be used to hedge yourself in situations where prevention fails.
None of the mitigations that were described were aimed at preventing a breach or disaster. Instead all were designed to mitigate the damage that happens when a breach occurs.
These are not new concepts in the security industry. In fact very much of the opposite; manifestations of them like zero trust have been one of the main buzzwords for the last ten years or so in the cyber industry.
It's a different thing sketching something on paper and how it actually works when trying to apply it into the chaotic mass corporate IT usually is. I work in this industry and talk to a lot of corporations from all over the globe about their security postures. I don't see a huge amount of companies who have the resource to pull off a well segmented environment. Truth is it is expensive, quite complex to pull off, potentially disrupts business and it's still just an internal security cost that when you present it to your boss they will ask "why are we spending all that money on firewalls then?"
Anyhow the point was that if you build your security posture on the assumption that you can successfully lock everything down and you don't need to do any monitoring internally, you're setting yourself up for that massive disruption when the stars align for the attacker and they get a free roam environment in your internals. And it happens very often, as we can see.
As reported on "60 Minutes" yesterday.
The security company did not compartmentalize their own system. They relied on monitoring, which failed.
Furthermore, it was said on the segment that firmware on the hardware can be infected, so reinstalling the system software won't get rid of it. The obvious solution to that is to put the firmware in ROMs, so it cannot be electrically reprogrammed. But nobody does that.
Inconvenient? Yes. But sometimes appropriate.
1. make the root password unguessable and change it often
2. background check employees
3. audit trusted vendor's security procedures
4. install sprinklers (!)
5. jam all USB ports with glue
6. train CEO on laptop security protocol