Much has been written on the pages of the SBN about application insecurities, we are honoured to have Jeremiah Grossman putting his ideas down in print, and I still have the occasional contact with Mark Curphey - founder of OWASP - even though I stood him up for lunch in his first month back in the UK - which I vow to make up for in the new year. In short, there are better men than I to talk about application holes and how to stop them occurring.
My experience is with data-security, and whilst it is undoubtedly the best way forward, I have grown used to the idea that it will never be complete on its own. Whilst I dislike using firewalls to plug holes, I admit they have their place, especially whilst data security is relatively expensive and applications are such a minefield. And whilst it would be too easy to argue about 'an ideal world', where applications had no holes, and networks had no points of insecurity, even best case reality has issues.
Consider a database, any database, any flavour on any OS from any company, you will all have your favourite. Now encrypt it with your favourite encryption method, encrypt the password files, prevent access to all part of the filesystem that you deem sensitive. You will still need a DBA. That DBA can write triggers. That DBA can write a trigger which, with no access to data himself, rewrites sensitive data to a file whenever a legitimate user accesses it. This is a hole.
How do you start to code around that? Obviously no-one thought of it, or it wouldn't be there. No-one thought to encrypt, so why would they make it harder for the DBA to do his job after all?
Of course, now there are other tools to cover this and many other issues around databases, we partner with them to plug the holes which encryption alone cannot fix. The problem is, with applications smaller than databases (i.e. pretty much every other application ever written), the issues come to light much slower, or rather once an attack is found, it can be kept quiet for far longer - insecurity by obscurity.