This week saw the coming together of more than 30 US and international cyber security organisations who met in order to compile a list of the most dangerous programming errors. The group came up with a list of 25 errors in total that lead to ‘security bugs and that enable cyber espionage and cybercrime'.
The statement claimed that ‘shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organisations developing software for sale.'
Further details on what the 25 errors are can be found at www.sans.org/top25errors/, but what the findings do prove is that there is a large amount of concern that writing code has not been done efficiently to date, and much improvement is needed.
SANS director Mason Brown claimed that ‘now it is time to fix them. First we need to make sure every programmer knows how to write code that is free of the top 25 errors, and then we need to make sure every programming team has processes in place to find, fix, or avoid these problems and has the tools needed to verify their code is as free of these errors as automated tools can verify.'
The top 25 focuses on the actual programming errors that are made and have been made by developers that create the vulnerabilities. So now they have been identified, the first question that many will ask is how will the top 25 errors be used?
The authors claim that there will be four major impacts made by the top 25.
Firstly, that software buyers will be able to buy much safer software, as buyers will expect software vendors to certify in writing that the code they are delivering is free of these programming errors. This means that the certification shifts responsibility to the vendor for correcting the errors and for any damage caused by those errors.
The second impact will be that programmers will have tools that consistently measure the security of the software they are writing, as software testing tools will use the top 25 in their evaluations and provide scores for the level of secure coding in software being tested.
However, there is a level of suspicion with this declaration, as according to the statement ‘one of the leading software testing vendors is announcing that its software will be able to test for and report on the presence of a large fraction of the top 25 errors.'
The third impact will be that colleges will be able to teach secure coding more confidently, as the top 25 will be used as a foundation for curriculum that ensures students know how to avoid the critical programming errors.
Finally, employers will be able to ensure they have programmers who can write more secure code as they can use the top 25 errors list as a guide for evaluating and improving skills of programmers they hire.
More than 100 large employers are apparently already using a common assessment tool, the GSSP (GIAC Secure Software Programmer), to measure secure coding skills. Exams associated to the GSSP are being reviewed ‘in an effort to fully incorporate and highlight mastery of programming knowledge needed to find and eliminate or avoid the top 25'.
What we learn from the top 25 is that the authors see this as some sort of ‘genesis of secure code' and a point of reference for all those involved to work from.
The response to this report was generally favourable; the fact that it is creating awareness and documenting the primary failings has been welcomed outside of those involved with its creation.
Sam Masiello, vice president of information security at MX Logic, claimed that the article ‘points out something that I don't think we talk enough about - ingraining secure coding practices into software developers during their education at the high school and college levels'.
Masiello said: “If these best practices are part of how software developers are taught to code from the beginning businesses will receive the trickledown effect of having better applications released from version 1.0 which decreases the company's risk of a security breach and embarrassment.
Security awareness concepts reach far beyond teaching users what they should and shouldn't click on and what websites they should stay away from and where it is and is not safe to provide their personally identifiable information. It also extends down to your company's SDLC and releasing rock-solid code.”
To conclude, one expert who took a slightly more negative view of the list was Stuart Okin, managing director of Comsec Consulting, who claimed that although SANS had identified the top 25 – these were ‘classes' or groupings of common coding errors, and there are actually thousands of specific errors incorporated within these.
Okin said that there is a temptation to use a tool only as an approach for finding common coding errors and although it is important to use tools, often they can produce large quantities of potential errors which can be difficult to focus on. Therefore, there is a need to incorporate security throughout the lifecycle of a project so that it becomes part of the development process from start to finish.
There is no doubt that this will have a positive impact upon the sector, after all if it means that errors are ironed out at the beginning due to guidelines that have been set here, then it will be better for all. What may cause controversy, as exemplified by Stuart Okin's comments, is what has been missed out due to the grouping of the errors, and if one causes a major problem in the next few months – who will be take the blame?