The price tag for writing secure code

At the Embedded Software Summit, held in Santa Barbara, Calif., this week, the consensus is that it costs, on average, between $100 and $1000 per line to write truly secure code.

The Embedded Software Summit is an annual press-and-analyst schmoozefest by Green Hills Software, which is based in this beautiful resort town. The company uses the summit to fête press and analysts, while pushing its latest initiatives and trashing its competitors.

For the past couple of years, GHS has been touting that its INTEGRITY separation kernel has been accepted into a EAL6+-level certification program. (The evaluation has been underway since late 2005, and should be completed soon.) By contrast, Windows and Linux are certified no higher than EAL4+. Thus, the summit now focuses on the security of Green Hills’ products, almost to the exclusion of everything else the company offers.

Dan O’Dowd, the competitive-minded founder and CEO of GHS, pointed out that EAL4 is defined as “only appropriate for an assumed non-hostile, well managed user community requiring protection against threats of inadvertent or casual attempts to breach system security.” That level of certification is not appropriate when “protection is required against determined attempts by hostile and well-funded attackers.”

So, during the summit (I stayed for the first day of the 1 1/2-day event), O’Dowd and his colleagues, such as CTO David Kleidermacker, frequently referred to Windows and Linux as “certified hackable.” (“How do you make systems more secure? Stop using Windows and Linux, that’s easy,” Kleidermacker said at one point.)

Indeed, O’Dowd’s kickoff address was very similar to his talk last year, when GHS introduced its platform for secure computing. At that time, O’Dowd (pictured) pointed out several well-publicized security hacks covered by the media. The problem, he said over and over again, is that the hacked systems were running Windows or Linux. (Read my comments about the 2006 Green Hills Software Embedded Software Summit.)

This year, O’Dowd was a bit more creative, and illustrated his talk with video clips from the movie “Live Free or Die Hard” (read my review of the credibility of that movie). For each of the hacks shown in the movie, he also cited a similar real-world hack. The reason for the hack? In each case, because the systems were using the “certified hackable” Window and Linux.

Oh, wait, there was one exception. In Die Hard 4, the bad guys hack into an F-35’s fighter’s communication system to steal its “go codes.” That wouldn’t be possible, O’Dowd bashfully admitted, because the F-35 Joint Strike Fighter uses software from Green Hills.

Two of the highlights of the conference (well, of the first day, at least) were a talk by Rob Dobry from the National Security Agency, and a panel on security moderated by Patriot Scientific’s Jim Turley.

The NSA guy, who was involved with the creation of security standards like Common Criteria and the Orange Book, was an incredible speaker. He didn’t provide much information – as you’d expect – but his anecdotes and off-hand comments about government security initiatives were fascinating. Sadly, I lost much of what he said; Dobry held up something, there was a bright flash, and my notes were gone.

The security panel didn’t reveal a whole lot of new information either until the Q&A portion. One analyst in the audience asked what it costs to write truly secure code – that is, code that’s designed and tested to meet quality standards comparable to what the aviation industry uses when it writes software for, say, the Airbus A380 or the F-35 fighter.

The panelists agreed that secure code is about an order of magnitude more expensive than writing “typical” software. The price tag is several hundreds of dollars per line of code – definitely under $1,000, said panelist Jess Irwin from Northrup Grumman, but definitely more than $100, said Green Hill’s O’Dowd. Everyone nodded. A useful data point indeed.

This year’s big announcement from Green Hills was a “padded cell” secure hypervisor for virtualization. It looks interesting.