Security Profession blog
Comment and discussion about the security industry of interest to the security professional. Blogs will be submitted by (ISC)2's management team and Advisory Board members.
Tuesday 31 March 2009, 1:50 PM
Will software ever be flawless?
More news this month of critical vulnerabilities in software – including but not limited to Cisco’s IOS software that powers the majority of Cisco routers and switches as well as HP OpenView’s systems and network management software and Sun’s Javascript too. At the same time a couple of security researchers have declared that software vulnerabilities should no longer be given away – in other words bugfinders should be paid for finding vulnerability flaws and no longer notify software vendors in advance of disclosure.
All too often, security is bolted on at the end of the development process in response to a threat or exposure. This is of course costly since the relative cost of fixing defects in production is something like 100 times more expensive than if proper security had been baked in during the design phase. Engraining security into the culture, processes and lives of software developers, testers and improvers of software is now critical if we are to close the massive number of unlocked doors in software.
Contrary to its intention, change will not be driven by governments wanting to legislate against software vendors (see Science and Technology Committee of the House of Lords published a report on “The Internet and Personal Security”: but, rightly, by customers who have started to question why they ever accepted the current release and patch cycle that is endemic within software. No longer just PCs to control, but smartphones and laptops too, patching and keeping the proliferation of endpoints operational as well as closed doors is getting more difficult and expensive to manage every day.
But software developers have yet to progress their profession with security in mind. They are driven by tight timescales, flexible and cost-effective development methodologies and an obsessive focus on usability. Security has been an afterthought, all too often introduced at the testing stage. Many argue that secure coding techniques have been developed, but this too is a limited approach. Little of the data that the software is designed to handle, and the associated risks to it are addressed by security coding alone. Clearly when the idea for a software program is developed, the associated risks to the data it will handle should be considered. The software on a iphone that accesses financial transactions, for example, should have robust security functionality built in – should it not? If change happens, we could well see a world where security is flawless – well at least with less holes than most software releases have today.
John Colley is managing director, EMEA at (ISC)2
All too often, security is bolted on at the end of the development process in response to a threat or exposure. This is of course costly since the relative cost of fixing defects in production is something like 100 times more expensive than if proper security had been baked in during the design phase. Engraining security into the culture, processes and lives of software developers, testers and improvers of software is now critical if we are to close the massive number of unlocked doors in software.
Contrary to its intention, change will not be driven by governments wanting to legislate against software vendors (see Science and Technology Committee of the House of Lords published a report on “The Internet and Personal Security”: but, rightly, by customers who have started to question why they ever accepted the current release and patch cycle that is endemic within software. No longer just PCs to control, but smartphones and laptops too, patching and keeping the proliferation of endpoints operational as well as closed doors is getting more difficult and expensive to manage every day.
But software developers have yet to progress their profession with security in mind. They are driven by tight timescales, flexible and cost-effective development methodologies and an obsessive focus on usability. Security has been an afterthought, all too often introduced at the testing stage. Many argue that secure coding techniques have been developed, but this too is a limited approach. Little of the data that the software is designed to handle, and the associated risks to it are addressed by security coding alone. Clearly when the idea for a software program is developed, the associated risks to the data it will handle should be considered. The software on a iphone that accesses financial transactions, for example, should have robust security functionality built in – should it not? If change happens, we could well see a world where security is flawless – well at least with less holes than most software releases have today.
John Colley is managing director, EMEA at (ISC)2
