Software: Safe by design

As software applications become ever more complex and more deeply imbedded into our online experiences, the challenges of securing them become even greater.

The latest industry scheme to secure software by design is called SAFECode, an initiative founded by EMC Corporation, Juniper Networks, Microsoft, SAP and Symantec in October 2007. The mission statement talks of establishing software assurance methods and developing best practice in producing secure software.

"The genesis of this project is the five founding members' recognition that code development needs more thought," says Paul Kurtz, executive director of SAFECode. "All members were working on their own secure coding but felt a definite need to collaborate on this. We need representation across a wide field, and will eventually have members from across the hardware and mobile spectrum." The organisation has already signed up handset manufacturer Nokia, which joined at the end of March.

According to Kurtz, whose CV boasts senior positions on the US's National Security and Homeland Security Councils, the alliance aims to publish around four white papers a year, outlining best practice in specific areas. The initial release of guidelines for software development, already available on the website, is just the beginning. SAFECode will also seek to provide a reference point and knowledge base for developers and customers alike, and plans to define and publish consistent metrics and certification as well as produce processes for identifying and fixing vulnerabilities.

"We recognise there isn't a clear and proven ROI model for software assurance at the moment. There is a series of models that have traditionally been used by industry, and we will compile these into a coherent whole," Kurtz explains. "This will enable developers and IT staff to prove to senior management that developing more secure code upfront does have definite payoffs."

The first white paper from SAFEcode contains a list of best-practice pointers to enable a secure design, development lifecycle and deployment of software. The paper focuses on the development process, from the initial design of the code, the security training and checking of project members, through to distributing and deploying the finished product. Security measures such as controlling access to completed code, conducting thorough testing and peer review are emphasised, along with the importance of producing clear configuration documentation to accompany the software. The document also recommends that developers conduct a risk analysis and come up with contingency plans to deal with any unforeseen vulnerabilities.

Whether the initiative will actually succeed in making the software we use every day more secure is an interesting question. Although the size and experience of the companies involved is unique, the concept of secure-by-design software is not a new one.

"My first thought is that I've seen this before," says Donal Casey, a software security expert at IT consultancy Morse. "As software is increasingly used online and reaches a wider audience, it needs to be more secure, that's unarguable. However, these best practices are very similar to existing ones. Essentially, this will just end up as another set of guidelines that can be added to the list, along with SSADM (structured systems analysis and design method) and SQA (software quality assurance). Besides, the SAFECode guidelines are very US-centric."

The British Computer Society's code of practice, originated in 2004, already involves some of the principles laid out by SAFECode, according to the BCS. In April 2003, industry consortium Oasis (Organization for the Advancement of Structured Information Standards) developed a common language, application vulnerability description language (AVDL), designed to allow application vulnerabilities to be shared between different network boxes, such as vulnerability scanners and intrusion detection tools. AVDL, had it been widely accepted, might have provided some of the collaborative benefits that SAFECode now plans to offer.

Another more recent initiative from the US is the SANS Institute's secure coding initiative, the SANS Secure Software Institute (SSI), which wants to educate programmers about the need to anticipate malicious attacks on their applications. A set of technical guidelines covering secure Java development was published late last year, and SSI is offering developers security qualifications via an exam system. Alan Paller, director of research at the SANS Institute, believes that this work is essential. "The bulk of web applications were written by people who have no clue about security," he claims. "Two years ago this wasn't a problem, because nobody was attacking applications. Now, however, criminals are automating attacks on certain vulnerabilities. The trouble is that coders used to be taught about wrong inputs generated by users making mistakes, but not malicious attacks designed to exploit their code. Colleges need to admit secure programming into their syllabuses, and everyone has to take responsibility - we can't just blame the big software houses."

Kurtz insists that SAFECode offers a holistic approach when compared to these older initiatives. "Other initiatives have focused on a particular issue, such as applications for example. However, we're looking at everything, including the operating system. This is what differentiates us. We're not looking to supplant anyone already working in this area." He rejects the charge of US centrism: "European-based SAP is an important contributor to our work at the moment, so it's not just about the US."

Mounting challenge
Although SAFECode may differ from other secure software initiatives in its scope and reach, the challenges remain the same. On the one side are the malicious hackers, who are gaining in strength and numbers, and on the other a historically laissez-faire approach to security that is only just beginning to change. Internally, SAFECode may also struggle finding enough key vendors with sufficient gravitas to make the resulting standards the de facto ones.

In fact, it is in the area of standards that the initiative may run into difficulties. Open standards are subject to peer review and, without external moderation, purely industry-originated standards can become hijacked by interested parties.

"It's vital that end users working in increasingly deperimeterised environments are able to independently verify that code is written both securely, and in context for their individual deployment," says Paul Simmonds, a co-founder and board member of the Jericho Forum. "While I applaud any initiative that leads to better secure code being written, this scheme currently doesn't appear to include any details regarding independent verification, and the guidelines don't mention context, which is extremely important when architecting secure systems."

However, the need for secure software has never been greater, and the best-practice guidelines from SAFECode will inevitably improve security if developers follow them closely.

Casey believes that businesses need to pull their weight, too. "Most major software development houses already have similar steps in place. The real security issues are where a business has taken an application and used it for something it wasn't designed for - web front ends are a classic example where this happens," he points out. "It's also worth bearing in mind that an insecure platform will cause all applications built on top of it to be insecure as well, no matter how carefully the applicationss are crafted."

Additionally, commercial pressures may not allow companies to implement all the recommendations all the time. According to Casey, in-house developers are often under the most pressure and, as a result, this is where much of the least secure code originates from. "In-house coders are often working in a pretty fragmented way, and don't necessarily have the training and awareness of the overall business that software houses would. The work can be very piecemeal and so the overall importance of changes made to code isn't always appreciated."

Kurtz agrees that there is plenty to do: "There are design issues, education issues, and that's just the beginning. We're considering whether to offer education products, it's a question of what to concentrate on first.

"As an industry we need to take a long view too - although around 70 per cent of attacks now take place through applications, we need to be looking to the issues of tomorrow as well," he warns. "There's certainly a growing feeling of urgency within government - recent developments in the UK and US include a new cyber security bill from President Bush, and the MI5 letter to British industry late last year - these stress the importance of security. This is really how to solve this issue, you need to have senior leadership getting involved, across the board from government through the whole of industry. Too often in the past security has been seen as an add-on."

It's fair to say that the jury is still out on SAFECode - no one denies the importance of its goals, and no one in the security industry is willing to shoot it down out of hand. However, the alliance will need to present an impartial face to the rest of the industry to have any chance of long-term success, and will need to widen it's membership considerably to have the breadth of experience and knowledge to achieve its aims.

10 TIPS FOR SECURE SOFTWARE

1. Train your developers The development team must be well-versed in information security - including security and privacy issues that may affect people who use the product.

2. Define your requirements Ensure that security is part of the earliest stages of the production process. Define how the requirements will be measured throughout the project, via reviews or code audits.

3. Secure the design Identify and address potential threats to the application and find ways to reduce the associated risks to a negligible level. Use threat modelling and mitigation planning to identify potential vulnerabilities.

4. Code security Ensure secure programming practices are implemented, for example source code review and/or automated analysis tools to minimise code errors.

5. Code handling Make sure that source code access is carefully tracked and managed so that only authorised persons are permitted to view or modify its contents.

6. Testing Use as many tests as you can, including vulnerability analysis, penetration testing, or techniques such as "fuzzing" or varying external inputs to identify potential buffer overflows and other errors.

7. Documentation Produce detailed user documentation that includes information on how to treat security issues and how configuration options may affect security.

8. Readiness and response Before releasing a new application, assess the risks posed by potential security gaps in it. Ensure there is an incident response process in place in case of a vulnerability being discovered.

9. Verify integrity Integrate a method for end users to verify that the code they plan to install is the same as the one you issued. Some companies use public key technology to sign code, for example.

10. Encourage security research Developers should keep up to date with new attack vectors and how to mitigate them.

IN-HOUSE DEVELOPMENT IN ACTION

Networking solutions vendor and SAFECode founding member Juniper Networks uses a TL 9000-certified process to manage product development, which is audited regularly. "Prior to SAFECode, we had a pretty pragmatic approach," says Tim Lemaster, Juniper's director of systems engineering.

"We decided many years ago that a single code train was the only way to ensure security and practicality issues were met. This sounds like common sense, but it's difficult to stick to. The problem is that if you provide products to big, specialised customers, they often want specific patches. And once you start doing this, you've split the code line and have to deal with testing and checking each version individually. "

Juniper uses a seven-phase process for its code. First, concept and feasibility requirements are defined, tracked and managed via a database before being approved by the customer. In phase two, the engineering team is formed. A manufacturing plan, as well as a diagnostic test plan is also defined. The next phase sees a software manager and software engineers assigned to the project. Code reviews are conducted in this phase and a member of Juniper's security research team is included in the process. External auditors may be engaged at this point as necessary for certification processes such as FIPS or Common Criteria.

All source code is derived from a single train of code, checked in and out of the mainline via a source code management system (SCM) to track changes, and any changes made must be documented and peer-reviewed. Any bugs discovered are entered into a tracking system.

"It's after this point that the single train becomes vital," explains Lemaster. "If you're splitting your efforts by having to test several versions of the same release, you are losing time. This can soon add up."

In phase four, hardware and software unit testing is performed and the product is evaluated by an internal team. Beta plans are defined and training plans are then created. Prototypes are built during this phase. Lemaster places a lot of weight on the testing stage: "It's critical that all changes are peer-reviewed and that proper, in-depth code-scanning and fuzzing tests are used. Even with the growing automation in this area, we're still testing for weeks at a time, but the tricky bit is making sure it's done at the right time in the development cycle."

Phase five sees the product move into beta testing, which occurs in parallel with any regulatory testing. The logistics sparing plan, the training plan and all documentation are also completed. Penultimately, the product is reviewed again by the team before being committed to a specific release of software. Product bugs or vulnerabilities during production are reported and tracked. Resulting code changes are tracked within SCM. The code changes are again peer reviewed and code scanning may be employed if appropriate. After verification of code, the product is regression tested. The final phase is the public launch and formal announcement of the product.

Lemaster believes that while previous best-practice concepts are widely recognised, more companies need to take them seriously. "There are a lot of companies around that simply don't have good enough discipline with regard to their in-house coding practices. Education is a big part of it, but it's a moving target - updates will always be necessary, we are working with a living, breathing network now ... "