Turn security rhetoric into action, Oracle warns

As senior principal program manager with Oracle, Evelyn Sell's role includes the supervision of part of Oracle's massive fleet of developers. In her experience, a variety of common and preventable factors -- ranging from developer laziness and ignorance of security issues, through to a lack of developer accountability, expectations that coders produce large volumes of code to strict timelines, and overall time-to-market issues -- often cause the security problems that explode into much bigger issues when they're let loose into the field.

Particularly in companies producing commercial software, blame can be traced to managers that maintain high expectations of coders but don't provide enough training to ensure adequate application security. "I am blown away by the billions of dollars that is invested in security [fixes] for something that really should be second nature," Sell explained. "It's very important to build in security up front."

Once code is complete, fixing the problem can often be much more difficult -- and far more expensive -- than getting it right in the first place. Customers build their own code on top of platforms like Oracle's database and business applications, and even a small security fix can potentially break all sorts of related, interdependent applications. That means security remediation must involve slow movement and extensive testing -- something, Sell admitted, that can be hard given commercial pressure to get products or bug fixes out the door quickly.

Sell described Oracle's four-pronged secure development strategy, which is encompassed in a "large, living document" that is constantly upgraded with new knowledge gained from the company's many development teams.

Regular analysis of the document reveals common themes that drive future investment. For example, Oracle recently responded to a perceived lack of security coding skills by introducing several mandatory online training modules on secure coding practices; developers that fall short of the 80 percent pass mark are reported to managers for more intensive training.

The company also uses a formal product security checklist that is regularly reviewed and used to drive frequent development team meetings. Prescriptive lists of acceptable tools, for applications such as cryptography and random number generation, aim to keep developers from rolling their own or using insecure code from elsewhere. An internal 'tiger team' of security experts constantly pounds Oracle code to identify potential problems before the code ships.

This may all sound like a bit much to organise for many managers. However, attention to the other presenters at SECURECon would quickly disabuse complacent managers of the idea that security is optional.

Presenters at this year's conference -- the fourth in the Melbourne University-organised event's history, combining two days of presentations with a full day of hands-on 'hackathons' -- discussed both the security of various common technologies, and how to bypass them.

Security specialist Chris Spencer highlighted techniques for exploiting buffer overflow problems in Windows, as well as discussing ways to circumvent buffer overflow protections built into Windows XP SP2. Microsoft IT Pro Evangelist shared techniques for hardening Windows Server 2003 SP1, while penetration testing expert Cédric Blancher highlighted the inherent lack of security of most WiFi networks and devices.

Other sessions delved into security in Mac OS X, Cisco routers, Unix servers, Apache Web servers, digital rights management (DRM) technologies, and identity based user authentication. Well-known US-based IBM developer Wietse Venema discussed his development of the secure and widely used Postfix e-mail server.

Although primarily intended for developers, the content of SECURECon nonetheless resonates for all business managers. Ultimately, they need to understand that code security must trump even commercially imposed deadlines; one major release of Oracle software was held up for more than two weeks while developers resolved a bug they'd identified. That's the kind of delay that gives marketing executives palpitations, but Sell believes that it's ultimately easy to argue the value of good security in terms even managers understand.

"All you need to do is show management the fallout line and let them know what [less than optimal security practices] are actually costing them," she said. "This is a small expense compared with the millions of dollars each individual security bug can cost a company. When you talk about the bottom line, all you really need to do is to show management how much less it would cost if they can drop the number of security vulnerabilities shipping in the products."