I was reading a column from CIO Insight magazine last night that made a very good point. The context was testing, but it applies to security as well. In Testing, Testing, John Parkinson discusses how complex systems are today and that this means that testing can never cover the entire system in the time allowed. His main point was that good practices up front are far more important than trying to find problems later.
This certainly applies to secure development as well. It is much better if we actively design systems to be secure than if we go through it later and try to test for all possible security vulnerabilities. Getting to this state is much harder than it sounds though, since most developers primarily focus on getting things to work, not giving much thought to making them secure, since that is often not even covered in the requirements. Developers will aim at what they are testing on and companies are only at the start of doing a good job integrating secure functionality as part of the requirements of new systems.
So far so good. This is the common message of those working in the secure development area today and it is even starting to take hold, though we have a long ways to go.
He made one good point that jumped out at me. He noted that we commonly think that code that has been around a long time is often more robust, since no problems have been found. This attitude is wrong though! Older code gets patched repeatedly during its life and those patches can have unexpected impacts on the system. Testing rarely covers as much of the system for changes than for a brand new system. Thus the older system is much more likely to have undiscovered problems.
The same is true with security. We think systems that have been around a long time and that have not been breached are secure, but all the ongoing changes are more likely to have caused security vulnerabilities we don't know about. Older systems are not necessarily more secure, even if we haven't found the problems yet!
This is certainly not a comforting thought, though it makes a lot of sense.