“I have three mailboxes in my office : IN, OUT, and TOO HARD. I was joking with the MIT students that I should have a TOO HARD bin” – Warren Buffett
Even for a great investor like Warren Buffett, most investing ideas wind up in the TOO HARD bin. Investing is a great in that way, where you can pick and choose which problems to tackle. There is no penalty for sitting it out when things are too complicated.
Unfortunately, in security we do not have this luxury. Our dev teams need to ship. Preferably sooner rather than later. Oh, and attackers will be looking for holes from minute one.
Like Warren Buffett’s mailboxes, virtually EVERYTHING that comes into an Information Security team’s inbox is TOO HARD. But unlike investing, we cannot really sit it out and wait for all the planets to align, we have to act.
There is a lot of evidence that information security is TOO HARD. Over the years, there have been plenty of examples of breaches where the victim companies did not do the basics – they did not have a firewall, they did not hash/salt passwords and so on. But nowawdays the victim companies are increasingly doing many things right and still getting hit. Its not a mystery, the design, deployment and operational challenges are hard. What to do?
This brings me to another of my favorite Buffett quotes- “The sign above the players’ entrance to the field at Notre Dame reads ‘Play Like a Champion Today.’ I sometimes joke that the sign at Nebraska reads ‘Remember Your Helmet.’ Charlie and I are ‘Remember Your Helmet’ kind of guys. We like to keep it simple.”
Security is too important to be left to development teams. But integrating security is too hard to be done by the security team alone. We talk constantly about threats and vulnerabilities and 0 day and SQL Injection, but our real problem is complexity management. There are ways to improve our security, but we have to choose wisely and make the things we choose simple enough to deploy.
Keeping it simple starts with ensuring the system has the right structural security pieces in place. For many apps today like Mobile apps this means adding an API security layer. Before getting wound up about the latest and greatest threats, remember your helmet, ensure that your DMZ, Middleware and Data tiers have protection in place, not just at the network layer but at the Application and message data layer too. Its often the case that too much focus on latest and greatest security topics obscures more fundamental issues.
We know security architecture is TOO HARD. We know that whatever we do today won’t be good enough next year, threats are too adaptable and most sotware assets that we protect are not particularly resilient. We cannot predict what the next threats will be, we cannot predict what will be the right identity standard in 2016 (OAuth? SAML? Something some kid at Caltech is cooking up right now?). But we can say with confidence, we’ll need a place to patch and defend against threats. We’ll need a place to deploy new identity protocols.
Engineering is about embracing constraints. For technical complexity and economic reasons, we simply cannot defend everywhere in the whole system. We have to choose where to locate our stronger defenses.
Boundary crossings are crucial to security, you leave one trust zone and enter a new one. The API layer is a very important boundary, it’s the logical place to drive security controls that can effectively handle application, identity and message data threats and countermeasures. When you are deploying Web, Cloud, and Mobile apps, remember this boundary. Remember your API Security.