Security often conflicts with short-term business objectives. When given the choice to build a feature that provides benefit to customers or developers, but that conflicts with security best practices, startups in particular are likely to take the less secure route.
The reasoning goes something like this: we need this feature now, the chances of us being hacked are slim, and we can always fix it later when the business is on an even keel. Of course, it doesn’t get fixed later, and at some point, the business’s users find their personal data and passwords spread across the Internet.
The alternative approach — the one that’s better in the long-term — is to build systems from the beginning that offer a layered security model. Building networks with layered security is a technical problem, of course, but at heart it’s a management and process problem. Without executive support for a layered and comprehensive approach to security, developers and other employees are unlikely to be properly incentivized to incorporate security best practices into their decision making.
The company’s network engineers and system administrators — those responsible for securing the edge of a company’s network — may do their jobs properly, but internal networks, employee behavior, and application development are likely to be riddled with security holes.
A layered approach puts security at the forefront of decision-making and business process design — networks, servers, applications, and employee training incorporate security from the start and processes are implemented such that the business relies on no single layer of security.
Phishing attacks are the number one vector for the compromise of corporate networks. A layered approach would mandate extensive training to reduce the risk of successful phishing attacks along with technological measures to make phishing attacks more difficult. But it should also be acknowledged that those security measures are almost certain to fail at some point and must be backed by several other layers of security.
In the Ashley Madison case, gigabytes of highly sensitive data were exposed. I don’t want to focus on the bulk of that data, but on the way passwords were stored. In theory, Ashley Madison did exactly the right thing with their users’ passwords. They were hashed using a slow hashing algorithm. If the password database leaked, it would take decades to successfully extract the plaintext passwords. Unfortunately, a programming error led to those passwords being stored elsewhere in the system; they were hashed, but using the very fast and insecure MD5 algorithm. The result is 13 million cracked passwords accompanied by user emails — the worst possible outcome.
The weakly hashed passwords were stored in a variable and probably leveraged for a function that improved user experience. Feature trumped security on a service where security and privacy should have been considered sacrosanct.
Compare the situation at Ashley Madison to that of LastPass. As with Ashley Madison, LastPass’s master password database was leaked. The company’s security failed at the network level. But the passwords were stored with multiple passes of a slow hashing algorithm that made the leaked hashes practically useless to the attackers. It would have been quite convenient, no doubt, to have a more easily retrieved version of the passwords stored so that the company could quickly access them, but because a layered security model incentivized secure development processes, that didn’t happen and LastPass’ user passwords stayed safe.
If there’s a lesson to be learned from Ashley Madison’s blushes, it’s that a layered security approach that builds security into decision-making at all levels of the business — from employee training to network design — will benefit businesses in the long run even if there are short-term costs.