IF WE COULD only fix all those software bugs, security would be a very dull job. Thanks to human nature, however, it appears that knowledgeable security folk are going to be occupied for a long time.

Take the OpenBSD project that has been auditing the source code of its operating system since 1996; the coders are still at work. Given that an operating system or any application is an ambitious code-audit project for anything less than an army of people, what can a corporate manager do to successfully initiate one? We've recently contributed to several large product and application code audits for major technology companies, and here's some of what we've learned on those jobs.

Software is never "done," so plan an audit with a discrete series of milestones in mind. These milestones should parallel development stages -- alpha, beta, release, dot release, Version 2, and so forth -- to help "embed" security into the evolution of the code base. Plan an audit between key milestones, but be aware that these often slip. Try to stick with consistent versions so that you can properly track your findings.

Timing is critical. How long does it take to audit a given module of code? Some count lines of code to reach a rough estimate, but it is difficult to judge on a line-by-line basis because the flow of interrelationships must be understood. A rule of thumb: Double your initial estimate.

Another good idea is to prioritize functional areas of the product or application being audited. Identify "front-facing" functions, such as Internet server API filters, custom communications protocols, remotely accessible object interfaces, and others, that will receive a lot of attention from external attackers and perhaps even malicious authorized users.

From a logistical perspective, a solid issue-tracking system is a requirement for meaningful audits. For example, a separate Concurrent Versions System tree or a stand-alone bug-tracking database could serve as a repository of security issues raised during the audit. Make sure to label security issues as distinct from garden-variety bugs so that they are given the proper attention.

The experts will tell you that there is no substitute for manual code review; we concur. Although simple problems can be identified with automated validation tools, these products are really just a starting point. They do, however, provide good yardsticks of progress over the life of the code base.

Because automated code auditing is inferior to manual review, how does one select the appropriate personnel to perform such a review? Not surprisingly, seasoned coders make the best auditors, especially when they have security savvy and know the standard classes of software bugs -- buffer overflows, protocol implementation weaknesses, format strings issues, and so on. Look for people who are experts in the language of your application code, talented with debuggers such as SoftIce and IDA Pro, and proficient at rapid development of exploit code. It is common to employ at least two auditors, as there is usually more than one way to work with code and it helps to have two informed opinions about which is more secure. If your product or application involves cryptography, make sure the auditors are experienced at implementation in this field.

Strong references and a careful interview process also help in selecting third-party analysts. There are few people who can do this work well; when you finnd code auditors you like, make a strong effort to stick with them.

As with anything having to do with security, risk assessment is paramount. Code is generally messy, and potential problems abound. Possible security vulnerabilities should always be weighed based on the ease of exploitation, but don't hesitate to fix the easily addressed problems, whether or not they are immediately exploitable.

The classic problem is the all-too-common buffer overflow. More sophisticated issues include such classic cryptographic mistakes as improper secret handling, poor algorithm selection, blurring of encryption and authentication, and failure to wipe scratch buffers. In general, auditors should make sure that data confidentiality and integrity mechanisms are implemented at the proper layer without leaving information exposed at inappropriate junctures. As always, legacy interoperability should be examined in-depth, as it is typically a source of design compromise that leads to security flaws.

An auditor's task is to assess the overall availability and accessibility of security functionality throughout the product, both from a developer's and user's point of view. This is a lofty goal. If security is not readily available within a product -- indeed, if it is not heavily automated, conveniently packaged, and endemic to the architecture -- it will not be used. For example, a centralized point of access to cryptographic services makes it easy to employ encryption at key junctures.

Sounds simple, right? Yes, we know -- it's easier said than done. Keep an open mind, and send your code-auditing tips to security_watch@infoworld.com.

www.infoworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine