September 10, 2009

Stop Assuming Security

Let's all just stop pretending that our connected applications and networks are secure. I mean, it, just stop it already. I don't care if you're PCI Compliant, use SSL with AES encryption and SHA-2 hashing algorithms. You can have IDS in place, and a 24-hour monitoring system with armed guards and Predators with hellfires ready to rain down fire on anyone that dares ping your DMZ. You're not secure....and you never will be.

Instead of approaching system security from the system side, we need to look at why the security is in place and begin architecting one-way data funnels into our connected systems. Once I've processed your credit card transaction, why do I have to continue storing your card on a connected data system (or store it all - but that's a different discussion). If I need to store vital information about my customers, the data system I do this on shouldn't be connected to anything, and it certainly shouldn't be accessible to any system connected to the Internet. System architects need to take much of the blame for system vulnerabilities because of the system design itself. Data is stored too close to the Internet, and easy and cheap interfaces like ODBC connections to our internal databases are too often shortcuts taken for saving money on development of single-use one-way data connectors.

In fact, system developers need to be woken up to the need for development of low-capability software, and how this software can play a vital role in secure system design. Why don't we see write-only database connectors on the market? How about packaged systems that have limited functionality (no-database read-only web server systems)?

We need to automatically assume that whatever multi-use software we are using is insecure and start limiting our exposure to vulnerabilities by removing capabilities that we don't want from our designed systems. When (not IF!) those vulnerabilities are discovered in our systems, the exposure risk will be limited to the capabilities of the software (and maybe the hardware!?!) that we use in designing the system. If the system is incapable of writing to the disk system at all, then when it gets hacked, the vulnerability won't expose the risk of writing data. If our customer service page gets hacked, if the page has no capability for querying the database through the one-way 'deposit-only' data connector, then the exposure will just be that they can write junk to our database. If our database is incapable of running shelled commands, they won't be able to do so.

Perhaps it's time for security analysts and software security architects to get religion...Luddism

No comments: