The IEEE has linked with ten IT and security organisations - including Google, Twitter, Cigital and RSA - to form the IEEE Centre for Secure Design (CSD). The CSD's first step has been to issue an advisory report for software developers - and allied staff - on how they can make their applications more secure.
According to Jim DelGrosso, a principal consultant with one of the CSD's founders, Cigital, the report - entitled `Avoiding the Top Ten Software Security Design Flaws' - is based on real-world data collated by the CSD's member organisations.
"We came up with the idea of the CSD back in April of this year at a security workshop and have developed the report to act as guidance for software developers on how to code their applications with security in mind," he said, adding that, generally speaking, there are two methods of analysing software for security issues: static analysis and dynamic analysis.
Whilst software development, as a process, goes back several decades to the earliest days of computing, DelGrosso said that applications are still being released with security flaws. The aim of the CSD, he adds, is to help developers make better decisions and so make software more secure - from the ground upwards.
It's still early days with the security software initiative and DelGrosso said the CSD is not at the code implementation stages with its advisories yet, although the plan is, he explained, to work with developers to help them re-use existing secure code, where it is available.
"Over the next couple of years, we want to get broad global support for the CSD initiative," he said, adding that it is not reasonable to expect a developer to know about code security issues.
And this, he explains, is where the CSD and its report comes in, since it will help to create a universe that helps software developers to avoid making mistakes on the security front as they code up their applications.
Rob Bamforth, a principal analyst for business communications with Quocirca, the business and IT research house, told SCMagazineUK.com that the creation of the IEEE CSD is an interesting initiative.
"I must admit I like the shift of emphasis from ‘fixing bugs' to ‘design flaws' - when I was a programmer in the long lost past, I adopted a highly defensive strategy, even capturing conditions which could ‘never' happen, just in case they did – of course it was ‘C', so the seemingly impossible could always occur if an aberrant pointer ran amok," he said.
"I also spent a while working in the realms of safety critical software, where we had to test the software really hard and completely to validate and verify, in the fields of satellite control systems and fingerprint recognition," he added, noting that with this background, it comes as no surprise that he is something of a software cynic.
Bamforth went on to say that, when it comes to software development, there should also be the view that any improvements that come out of the initiative may be necessary, even if they are not sufficient to counter the security issues.
"The last thing I think any of those involved would like to happen is for individuals to treat initiatives like this as a check box, and so absolve those adopting them of any responsibility," he said, adding that life - and digital life in particular - is never that simple.
Despite these caveats, the Quocirca analyst says that the CSD initiative seems like a worthwhile approach, and it is good, he says, to see the IEEE taking a positive stance.
"I think it helps the industry - and those outside it - move on from the idea that software is pixie magic dust assembled by alchemist programmers to a more engineering-like approach. Absolute precision and certainty cannot be guaranteed, as failure is - sadly - always a possibility and all software has some vulnerabilities, but if they can be handled well, with little effort and rigour, any security consequences in the development process can be avoided,” he explained.
Sarb Sembhi, a director with Storm Guidance, said that the CSD's report seems to assume the responsibility on the secure program development lies solely with the software coders themselves.
Sembhi, who is a also a leading light in ISACA, the not-for-profit IT security association, said that when the association published a report on the topic a few years ago, it was clear that coders need to be taught about security at the learning stages in their careers, as once they entered the commercial world, the main focus was - usually - to get the software out of the door as quickly as possible.
"From the security perspective, the horse had bolted by the time the developers started coding professionally," he said, adding that there is also the issue that business analysts - who often oversee the coding process - do not usually worry about security at the coding level, for the simple reason that it does not concern them, and, of course, he explained, adding security to the mix also adds to the cost.