From my dead blog, 2006-04-15
I thought I was going to make one really long post, but I change my mind.
To preface, there’s an article (http://www.ranum.com/security/computer_security/editorials/dumb/) entitled “The Six Dumbest Ideas in Computer Security”. And like the OWASP Top 10, I think they’re spot on with a couple of them. But they’re completely off the mark on a few. I’ll start this post with where’re they’ve gone right.
Of course this is a dumb security practice. It’s completely against the Principle of Least Privilege.
This is where security practitioners seem to fall into two camps. The first camp is like plugging holes in a dam - when we find a problem, fix it - this has been the basic approach to security for years, and it simply doesn’t work (see a later post on Anna Kournikova and phishing). The second camp is to make secure systems where regardless of the type of hole that might come up, the system is able to deal with it anyhow.
An example of the second camp would be to create system policies that allow only certain types of attachments into the email system - PDF and picture type files would be good examples - the aim is to reduce the “surface area” of attachment viruses. The traditional approach to the problem of attachment viruses is to install antivirus on the mail server and/or client to remove viruses that we KNOW about. There have been a huge number of failures when a definition doesn’t exist for a new type of virus (see Anna Kournikova).
Another example of this is training developers to write secure systems from the ground up, rather than finding flaws in the system once it goes to production. It’s offensively expensive to fix a problem (regardless of type) once the code is in production - and much less expensive to code the thing properly from the beginning. Ultimately, the money saved by writing secure applications and securing code during development will offset the cost of the training involved to get developers to understand how to write it secure from the beginning.
More on the article later.