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?
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
PreviousComments on this post
This comment has been deleted at the users request
In my experience developers, in the main, write good functional code, they love to solve problems and provide functionality to fulfil the design criteria and the user/business requirements. Developers do not tend to write performant/secure code and as you say these aspects are often an afterthought which is bolted on.
What users/businesses are not good at is specifying clearly, unambiguously, completely and without making assumptions, what they want either in terms of functionality or non-functional requirements for performance, security etc.
Through the correct application of "Static Testing"; reviews, inspections and walkthroughs of Analysis/Requirements, Design/Specifications and Code, increased clarity and completeness can be driven into the requirements and design from the outset and ambiguity and assumption can be reduced.
To err is human and therefore I am sure the answer to the question "will software ever be flawless?" is no, but software could, if engineered correctly from the outset, contain far fewer flaws and cost significantly less to build, support and maintain as a result. Testing and Quality Assurance, engaged from the beginning of the lifecycle, are key to this improvement becoming a reality.
Ian Londesbrough is a Consultancy Partner at Transition Consulting Limited www.tcl.eu.com.
