Steve Lipner is no stranger to the challenge of building software programs without security bugs. The director of security engineering strategy at Microsoft started trying to write secure software code in the seventies. "My idea at the time was that we'd build a full mathematical model of security," Steve Lipner says, recalling a plan to write a set of specifications that would guarantee a secure piece of software. "We'd build our systems to implement the specifications. We'd prove that the mathematical model was consistent, and that the specificiations corresponded to the model, and that the code would conform to the specifications. Then we'd all go home and work on something else."
It was a nice idea even if didn't pan out and now Lipner is one of the people responsible for Microsoft's Secure Development Lifecycle (SDL),a software development model introduced following a major turnaround for the company in 2002. Bill Gates recognised that Microsoft's software portfolio faced significant security challenges, and embarked on a major cultural change in the organisation - he wanted people to develop secure software. Better late than never. The company froze development of all products for several months and focused on training its staff in secure coding. "That encompasses things like threat modeling, code inspection, security testing, and so on," Lipner says.
Microsoft wasn't the only one who needed to teach its staff to develop code properly. "Big companies use coders straight out of university, and they're trying to make the funcationality simply work, rather than make it work securely," warns Tony Fogarty, principal security consultant at DNV IT Global Services, which specialises in reducing technology risk for its clients.
One of the biggest technology risks is code filled with holes, but such code often passes quality assurance, says Bruce Potter, founder of security consulting firm Ponte Technologies. "People don't often say, 'oh, and we don't want this software to be subject to an SQL injection attack'," he says. "It's not seen as a feature." Clearly, the first step to solving the problem is to outline proper security specifications when gathering requirements. The second step is to teach developers that the value in code lies not simply in its functionality, but in how secure it is.
Categories of software security flaws
To do that, we have to understand the crucial security mistakes that can be made when writing software, explains Gary McGraw, CTO at Cigital, a company that specialises in advising on secure code development. That involves collecting common exploits together and looking at the common mistakes that make them possible, he says: "We identified the top seven categories of software security flaw, which we called the seven pernicious kingdoms," he says.
These broad categories of rules can be broken down into more specific ones that can then be checked for in software. Such rules may often involve not using functions that have been deprecated, for example. Microsoft put a moratorium on several C++ functions that if found were vulnerable to exploits such as buffer overflow attacks. Putting new functions in the library and checking that programmers are using them is relatively easy to do, and can solve a lot of the security problems in code development up front.
Such rules will be of limited use on their own, however. They must sit within a framework to be formalised properly. McGraw points to three: Microsoft's SDL (which the company has published in book form) his own methodology, based around security 'touch points' and the comprehensive, lightweight, application security process (Clasp), produced by the Open Web Application Security Project, a community of application developers trying to make Web-based software more secure.
Clasp tries to put security considerations into the software development process at an early stage. It uses a series of perspectives to examine the software development process at a managerial level. These are broken down into activities, that in turn process specific components. For example, one view is based on roles, enabling a separation of duties among people involved in software development.
"If you stand all the way back, the methodologies look very similar," Says McGraw, although he argues that his own and the SDL are more mature and singles out Touchpoint as more generic, because it is not written by a vendor of operating systems.
Regardless of which methodology a company chooses to implement, there is a big gap between understanding how mistakes find their way into code - and how they can be avoided - and actually executing on this knowledge. Gordon Alexander, technology manager at Compuware, highlights a fundamental problem here: developers' mistakes rarely affect them directly. "Defects manifest themselves in operation, and the cost of that will be borne out of the operational budget, and the development budget doesn't see that cost ," he says. "That makes it difficult for developers to invest in the process to fix these security problems."
How can managers bridge that gap? Software security is effectively a governance issue, if badly coded software puts your software - and your customers' data - at risk. Making a cultural change that will spread throughout the company requires engagement and training at all levels, says McGraw, from low-level coders all the way up to senior management. It can also result in the involvement of people you might not normally expect to see in the process. For example, he says, one way to make sure developers actually code properly is by training them. However, many developers won't be interested in coming to the training. Something will always come up. So he suggests enlisting the human resources department to ensure that developers actually attend and learn. "If you'd like to get a raise, you're going to have to go on the training course. So go do it," he quips.
Rolling together coding practices with other business functions can help ensure developers follow guidelines at an operational level, too, McGraw says. Static analysis tools can be used to find mistakes, but he suggests attributing mistakes to individual coders and linking the issue to bonuses. If a developer continually contravenes programming security guidelines and has to be repeatedly corrected during the quality assurance phase, it means they are not following company policy. They are not doing their job properly. Why shouldn't they be penalised in the same way as a salesperson who fails to meet targets, or a line manager who doesn't hit key performance indicators, asks McGraw.
One common best practice is to encourage regular feedback between developers and quality assurance teams. Dan Bodart, technical lead at global IT consultancy Thoughtworks, says this is central to his firm's process and connected to its coding practice of using agile programming techniques. Agile development encourages the coding of applications in relatively small chunks, enabling development teams to test code and interact with users on a more frequent, regular basis. Extreme programming, a methodology originally conceived by Kent Beck, advocates the use of paired programming to help bolster code quality. This involves two people coding a particular function, building an additional layer of quality control into the process.
Ultimately, secure coding comes down to a mixture of well-trained, engaged developers, and management who are prepared to instigate robust processes and oversee them. This will require a considerable investment from companies who have hitherto paid only lip service to software security. But as with many risk management exercises, the return on investment lies largely in prevention. If you don't do it, and your applications suffer an embarrassing breach as a result, how much will that end up costing you?