Ed Felton and the gang at Princeton have struck again! This time they've figured out how to defeat the disk encryption schemes built into Vista, MacOS X, and others. The attack works because the values held in RAM don't disappear instantly when a computer is switched off. They decay slowly over a period of seconds, and that can be extended to minutes with a little bit of coaxing. That's long enough to boot up a second OS and read out the contents of memory. After that, it's just a matter of extracting the crypto keys, and the game is over. Awesome work. Read about Cold Boot attacks on Encryption Keys.

If there's a lesson to be re-discovered here, I think it's the amazing way we end up building security systems on what seem to be solid ground (as in "computers forget stuff when you turn them off"), and only when it's too late do we find out that our premise was strong enough for trying to explain computers to someone like your old uncle Hugo, but not strong enough to adequately secure your data.

It appears to me that this attack is still too sophisticated for the average thief who steals laptops in coffee shops, but it's plenty easy for the forensics guy down at the police station.

Some inspired soul has reworked the New Face of Cybercrime trailer. Watch this. My favorite bit: the cat and the baby.

It's been a while since Brian or I posted anything about Secure Programming with Static Analysis, and Gary McGraw's mention of the book in his recent article on Dark Reading seems like as good an excuse as any. Gary concludes his post, The Truth Behind Code Analysis, with the following:

"If you’re interested in static analysis for security (and you should be), buy and read Secure Programming with Static Analysis by Brian Chess and Jacob West."

The book was also recently reviewed in a recent blog post by the folks over at the Denim Group.

And the following are just a few of the other relevant mentions it has received:

• SDTimes
• Dr. Dobb's Journal
• Sylvan von Stuppe
• Justice League (Cigital)
• SANS
• Deep Inside | Security & Tools

I've also been (pleasantly) surprised by how much interest we've gotten in the warez scene. I won't post those links, however.

We don't get that many cartoons about code review, so when a new one crops up, it's cause for celebration. If you don't think it's hilarious, you need to do more code review. Many thanks to Mark Curphy.

NIST has announced what they call a Static Analysis Tools Exposition (SATE). Participating static analysis tools will be used to analyze a small set of programs selected by NIST. Eventually all of the results will be made public. I like the idea a lot, and I'm going to make sure Fortify takes part in both the C and Java tracks.

Running a bunch of programs against the same test cases might seem like a straightforward exercise, but it's not. Finding an even-handed way to examine complicated tools is tough, and the fact that NIST is emphasizing the detection of security vulnerabilities makes it that much tougher. (Tell me again, what exactly constitutes a "vulnerability" in source code?) Just browse through the steps in the SATE protocol to get a feel for the complexity involved.

To make the exercise even more difficult, everyone who makes a tool can't help but worry that they'll come out looking bad. After all, this sounds a little bit like the setup for a product review. We've seen those before. (Here's a link to the one Network Computing did in the middle of 2007: link.) Product reviews generally have winners and losers. NIST says they'll work hard to avoid these kinds of labels, but it's not going to be easy. All of this makes test case selection a touchy subject, and comparative presentation of the results is an absolute minefield.

The problems are many, but there's also a lot to be gained. Here are the three reasons I'm looking past all of the complexity and anxiety and participating in SATE:

1. People who want to run their own tool comparisons will benefit. You might like the way SATE works or you might not, but you'll be able to see what they did and where it took them.
2. Tool builders will benefit. Static analysis for security is a hot topic in both industry and academia. The results will give us a little bit of insight into which problems we've conquered and which ones require more work.
3. The security community will benefit. Being able to compare output from different tools will give us a better idea about how the tools classify code, and my guess is that we'll learn that our nomenclature still needs improvement. Better nomenclature makes it easier to talk to the 99% of humanity that doesn't think about software security every day.