when you have a single point of failure…

When writing about the inherent difficulties in a large cyber-broadside about a country’s critical infrastructure, I focused on the fact that different SCADA machines and computer networks have different implementations and hacks would require a different approach for each one. But the problem is that about 11 million devices in roughly 52 countries are now linked together by a platform called the Niagra Framework, which abstracts the APIs for all kinds of machines into common code objects. The result is the ability to remotely control every device that was hooked up to a network implementing Niagra, from elevator doors, to video cameras, to secure vaults, all monitored via Niagra’s makers’ servers.

Now this is all nice and neat, but linking everything together to make sure updates are sent to every customer as they come out and every action could be monitored and tracked to help ensure clients’ security into a single bundle poses a major problem. It creates a single point of failure for thousands of client companies and millions of their assets, and if that point isn’t adequately secure, you’re in trouble. So as more and more people invested in Niagra and linked their devices to its custom development tools, they were betting that Niagra was safe. You can probably see where I’m headed with this, right?

Well, Niagra, turned out to be somewhat easily hackable and this weakness represents a very real threat to the security of hospitals, factories, and power plants. Basically, the sins committed by Tridium, the creators of Niagra’s, include leaving clients’ configuration files used to store data like database passwords, access control settings, machine keys, and other credentials needed by applications at runtime far too easily accessible, and encrypting passwords with an outdated hash.

These are hardly Stratfor-type errors, and the average Joe or Jane is unlikely to hijack a Niagra server, but someone who knows how to hack would be able to do some serious damage fairly quickly. Even worse is that such issues are very common when it comes to well known security lapses. Contrary to popular opinion, very few Anonymous hacks happen due to the sheer cunning of LulSec/Anti-Sec members. Although they certainly do have some very determined and very creative minds at their disposal, hacktivists usually exploit old and well known vulnerabilities like SQL injection, poorly secured configuration files, easily hackable passwords or employee e-mail accounts secured by a password using old encryption that can relatively easily be broken with a brute force hack. Sadly this sort of stuff is all too common and has many infosec experts proclaiming that security doesn’t exist in the IT world.

That statement is, of course, hyperbolic because we do have tools and encryption standards that simply can’t be broken in practical terms. While even SHA-2 function family and the mighty AES cipher aren’t invulnerable, the amount of time and processing power it would take to break them pose a challenge even to the NSA, one of the world’s most experienced and best funded intelligence agencies, much less a rogue hacker. So why is the web so riddled with sites that use the outdated MD5 or SHA-0 if they use any encryption at all? Why do so few sites even bother with a salted hash to make things even a little difficult on their attackers?

There’s a wide range of libraries implementing SHA-2 ciphers for programmers and you can easily find another powerful and effective encryption standard called PGP in open source development kits, or at least buy tools to encrypt your sensitive data. Why not use them? Well, sophisticated encryption standards add to a computational overhead and can be a drain on performance. For a massive website with many users, reducing lag is simply a higher priority than security and they’d rather spend tens of thousands on new servers than on new certificates. Even if we were to accept and forgive that, however, I would think that Tridium’s executives would’ve taken security a lot more seriously since they have a little more to protect than blog posts or internal e-mails…