Monday, August 21, 2006
Techforum: Thoughts on Secure Software
I will be speaking at the upcoming Techforum in New York City on October 19th on a variety of security topics. Hopefully folks who read my blog will be in attendance...
Folks such as Gary McGraw have talked enough about the notion of writing secure code but this simply hasn't been on the radar of most enterprises nor many software vendors for that matter. While open source projects such as Liferay Enterprise Portal, ServiceMix and JBoss have been independently validated to be more secure than their closed source counterparts, industry analysts never seem to think that security is an important consideration in terms of their placing closed source vendors into leaders positions.
Maybe the real problem is that folks need to change the conversation and ask is there ever going to be sufficient economic incentive to write secure code? We know out of the gate that the current model of industy analysis simply won't help the enterprise become more secure as validation would require industry analysts to actually install the software vs simply listening to conversations.
Some folks are of the belief that insecure software is caused by economic reasons of which I disagree. Of course vendors make it a priority to add new features to each release of software while not necessarily fixing defects that were introduced in previous releases. One can acknowledge that there is an economic incentive to put features over security.
I am of the school of thought that the quality of software or lack of is not a matter of economics but is a matter of knowledge. If one could build security in vs making it an after thought, the average software vendor could do both at the same time with no increase in cost.
Someone within a large enterprise recently commented how they would love to work for Microsoft as they are sick and tired of working with folks who simply don't know how to code. There is something to be said for Microsoft in that they have folks such as Michael Howards whose job it is to help others write more secure code. What Michael is working on should be a discipline that makes it to corporate America as the exposures to leakage of personally identifiable data are even higher.
Unlike at Microsoft, most corporations will allow folks to walk in from the street or even telecommute from countries such as India without even knowing how well they actually code. They can rationalize (rationalization is a trap) in that they look for years of experience but never ask the question of does this person have five years of experience or did they have one year of experience five times.
It would be intriguing if enterprise information protection programs could be empowered by creating corporate policy to stop the creation of insecure code within enterprises that would extend to things they also procure. This is the only thing that would change the game. Of course, those enterprises who have IT executives who lack strong technical leadership upon learning that their competitors are ahead of them in this regard will practice management by magazine and think they could throw money at the problem and get it all twisted.
Economic incentives simply won't work in helping produce secure software. If you don't know how to do the job better, more money won't help. If you know how to develop better software, it will be cheaper, both in the long and the short term, to develop higher quality software than lower quality software. I wonder if IT executives will start respecting the role of software developers and start getting them some real training...
| | View blog reactionsFolks such as Gary McGraw have talked enough about the notion of writing secure code but this simply hasn't been on the radar of most enterprises nor many software vendors for that matter. While open source projects such as Liferay Enterprise Portal, ServiceMix and JBoss have been independently validated to be more secure than their closed source counterparts, industry analysts never seem to think that security is an important consideration in terms of their placing closed source vendors into leaders positions.
Maybe the real problem is that folks need to change the conversation and ask is there ever going to be sufficient economic incentive to write secure code? We know out of the gate that the current model of industy analysis simply won't help the enterprise become more secure as validation would require industry analysts to actually install the software vs simply listening to conversations.
Some folks are of the belief that insecure software is caused by economic reasons of which I disagree. Of course vendors make it a priority to add new features to each release of software while not necessarily fixing defects that were introduced in previous releases. One can acknowledge that there is an economic incentive to put features over security.
I am of the school of thought that the quality of software or lack of is not a matter of economics but is a matter of knowledge. If one could build security in vs making it an after thought, the average software vendor could do both at the same time with no increase in cost.
Someone within a large enterprise recently commented how they would love to work for Microsoft as they are sick and tired of working with folks who simply don't know how to code. There is something to be said for Microsoft in that they have folks such as Michael Howards whose job it is to help others write more secure code. What Michael is working on should be a discipline that makes it to corporate America as the exposures to leakage of personally identifiable data are even higher.
Unlike at Microsoft, most corporations will allow folks to walk in from the street or even telecommute from countries such as India without even knowing how well they actually code. They can rationalize (rationalization is a trap) in that they look for years of experience but never ask the question of does this person have five years of experience or did they have one year of experience five times.
It would be intriguing if enterprise information protection programs could be empowered by creating corporate policy to stop the creation of insecure code within enterprises that would extend to things they also procure. This is the only thing that would change the game. Of course, those enterprises who have IT executives who lack strong technical leadership upon learning that their competitors are ahead of them in this regard will practice management by magazine and think they could throw money at the problem and get it all twisted.
Economic incentives simply won't work in helping produce secure software. If you don't know how to do the job better, more money won't help. If you know how to develop better software, it will be cheaper, both in the long and the short term, to develop higher quality software than lower quality software. I wonder if IT executives will start respecting the role of software developers and start getting them some real training...
