The issue of secure coding has been around since the first program was hacked by the first hacker and was caught. I am sure that someone asked the developer why he coded it that way and probably got a blank look in response. As Information Security (INFOSEC) professionals, we are often quick to fault the developers for our malicious software woes and for the most part, we have good reason. Software products are often raced to market to capture the almighty dollar. Software vendors often seem to pay lip service to validating their code before they go to market. I came up with an adage when I was actually involved in day-to-day IT operations. I believe it works here as well. It goes something like this: “Believe only half of what a software vendor tells you about his/her product and expect them to deliver only a quarter of what you believe.” Software vendors (the big guys Microsoft, Oracle, Cisco, etc aside) often live off their reputation so I believe that some code checking and validation does occur but probably not as much as they say they do.
Does this make the software vendors responsible for all the malicious software out there taking advantage of our naïve users and robbing us of valuable bandwidth? In some manner, yes it does. They are not the only one’s to blame though. How many years have we put up with this type of sloppy code? How many years have we put up with the endless cycle of patching? Have we passed the point where sufficient pressure can be put on the big software vendors to pay more attention to security? Apparently Microsoft is now trying to market themselves as having a secure operating system and is getting better (relative term) in getting their code cleaned up.
In a April 2004 article for Network World, Ellen Messmer quotes Steve Orrin, CTO at Sanctum as saying that “Many organizations try to stomp bugs by having the chief software architect and programmers work in a formal process with the security manager’s staff as part of the code-evaluation process.” While this is a good development, Ms Messmer goes on to point out that, Microsoft employed “about a dozen of these security specialists to interact with about 20,000 software engineers.”
Secure coding can be said to start at home. I have talked to too many software engineers over the years that say that they never learned about security when whey were learning about programming or that they were required to take one class about secure programming. I have heard too often from program managers on systems development projects that “we will worry about security controls later, after we get the system working.” How much is the education system to blame for not teaching secure coding from the onset of a project? How much of the “just get the thing working first” mentality comes from these days in academia?
There is a good article on this subject by David Wong; a principle consultant with Foundstone (at the time the article was written). He points out that it is “impossible to build bug-free, vulnerability-free software.” He approaches the point from a very realistic standpoint that software development, like INFOSEC itself, is an exercise of reducing risk to an acceptable level and by following best practices software developers can avoid 90% of the commonly exploited security vulnerabilities. He even indicates that there are automated tools to assist in the identification of these vulnerabilities. He also points out that it still takes a programmer to fix them.
This debate has been raging for years and unfortunately, everyone involved has stopped listening to the other side. Programmers are blaming the flaws on hackers or the rush to market or the security department for pointing out these issues. Security professionals are blaming the latest virus outbreaks on code that should never have been released in such a vulnerable state. Both sides have valid arguments and the best solution is probably right down the middle of both camps. Programmers and Software development companies need to invest more time and money into some of the simple measures enumerated by Wong before they release their software. Security Professionals need to take some basic steps to reduce their risk as well by implementing sufficient controls, turning off unneeded services and limiting access to only what is needed to perform specific functions. Is this the silver bullet? No but it is quite a bit better than where we are at now.
Entries (RSS)