BSIMM2 is the 30 firm version of BSIMM. I wrote up an article with Brian Chess and Sammy Migues (my BSIMM co-creators) called “Software [In]security: What Works in Software Security — Fifteen Common Activities from BSIMM2.” In addition to highlighting the fifteen most common BSIMM activities, the article also provides the 30 firm data for all 110 activities in public for the first time.

We’re unveiling some statistical results at RSA this week that will enhance and expand the dataset published in the article. We’ll do an official BSIMM2 launch within the next couple of months.

Apparently the time has come to re-release the SANS/CWE 25 — something that we can expect annually. The good news is that exercises like this do plenty to hype up software security and its importance. In fact, in many ways the target of these lists is “the reporters who cover software security.” So hype = good.

So why am I not a big fan of these lists? Well, I wrote that down a year ago and what I said then still applies. Sure would be nice to see a reasoned response to my criticisms instead of repetition of the same tired ideas. If you haven’t had a chance yet, go read my January 2009 informIT column “Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work.”

There are some important improvements in this year’s top25 list that have been discussed on sc-l. But there is also a problem that really bothers me. The SANS guys are trying to tie the top25 list to software liability (?!) and apparently think they can hold developers accountable for their bugs..well, 25 of them at least. I think this is a wrongheaded approach to software security. I would much rather talk about the real progress the field has made than to hype up yet another list and make the list a critical aspect of software contracts?! Can you imagine what such a move (if it succeeded) would do to the price of software and to the hourly rates of developers? Developers would be compensated like lawyers!

Top-n lists do have their place. In the BSIMM we note 10 firms (of 30) who follow activity [CR1.1]. Here is the activity cut from the BSIMM:

Create a top N bugs list (real data preferred). The SSG maintains a list of the most important kinds of bugs that need to be eliminated from the organization’s code. The list helps focus the organization’s attention on the bugs that matter most. A generic list could be culled from public sources, but a list is much more valuable if it is specific to the organization and built from real data gathered from code review, testing, and actual incidents. The SSG can periodically update the list and publish a “most wanted” report. (For another way to use the list, see [T2.2] Create/ use material specific to company history.)

In my view, a tailored top-n bugs list is way more useful than a generic “world list” like the SANS/CWE25. To think about why this is, consider the differences between code bases from Intel, Microsoft, Symantec, and Nokia (not to mention Wells Fargo)…all BSIMM participants. Whose bugs do you want to eradicate? Yours? Or your neighbors?

Press coverage of the “controversy”:

• SANS Institute, MITRE release new top 25 dangerous coding errors list, TechTarget.
• Top 25 Programming Errors: Should Software Developers be Liable?, Bank Info Security.
• Hold vendors liable for buggy software, group says, ComputerWorld.
• 25 ways to better secure software from cyber attacks, Scientific American Observations.
• Security agencies release Top 25 programming errors, Washington Technology.
• Proposal Would Hold Software Developers Accountable For Security Bugs, Dark Reading.
• Group Proposes Suits Over Faulty Code, Gov Info Security.

The BSIMM study data set has more than tripled in size and now includes data from 30 firms. We are busy working with Betsy Nichols to crunch the numbers now that we have a statistically significant data set. The plan is to announce our results at RSA.

One question that comes up in the BSIMM work fairly consistency is the difference between BSIMM and other maturity models for software security. To answer that question, I wrote an article for informIT entitled “Cargo Cult Computer Security: Why we need more description and less prescription.”

Download audio [mp3]

David Rice, the author of Geekonomics (as well as the 46th Silver Bullet Security podcast victim), and I discuss the BSIMM in a webcast about the upcoming SANS software security event in San Francisco.

The time for science is upon us. And the first step in any scientific approach is measurement.

Our sincere congratulations to Howard Schmidt for taking on one of the most important jobs in computer security—US Cybersecurity Coordinator for the White House. Howard knows what he’s getting into, because he already did it once. (You’re crazy Howard!)

Here’s what the White House has to say.

Back in July I talked about what I would like to see in the position in a Justice League post and a video for Gartner. I stand by my statements from July. However, I am psyched that Howard is taking the job. He understands the importance of building security in and will be a powerful advocate for software security.

What a great way to start 2010!

The BSIMM study focuses attention on software security in large organizations and just at the moment covers the work of 1554 full time employees working every day in 26 software security initiatives. One phenomenon we observed consistently in the BSIMM is that every large initiative has a Software Security Group (SSG) to carry out and lead software security activities.

I wrote about our observations around SSGs in my December informIT article.

Simply put, an SSG is a critical part of a software security initiative in all companies with more than 100 developers. (We’re still not sure about SSGs in smaller organizations, but the BSIMM Begin data (now hovering at 75 firms) may be revealing.)

Cigital’s SSG was formed in 1997 (with John Viega, Brad Arkin, and me as founding members). Since its inception, we’ve helped plan, staff, and carry out ten large software security initiatives in customer firms. One of the most important first tasks is establishing an SSG.

Interacting with academia is an important part of what I do as CTO of Cigital. Though I have been known to lecture at Stanford, CMU, Cornell, Harvard, NC State, Purdue and a bunch of other places, I have a special place in my heart for the University of Virginia (where I studied Philosophy as an undergraduate) and Indiana University (where I earned a dual Ph.D. in computer science and cognitive science).

Alf Weaver, a CS professor at UVa recently asked me to lecture to his Electronic Commerce Technologies course. I was happy to oblige. When I asked what I should lecture about, I got back a one word answer—startups.

Not quite sure of what to do, I decided to draw on my own experience at Cigital. In 1995 when I joined Cigital, it was known as Reliable Software Technologies (or RST) and had a grand total of seven employees. I’m proud to say that today Cigital has over 120 employees and offices in Virginia, NY, Boston, Silicon Valley, India, and Amsterdam.

Helping Cigital evolve has been both hard work and a joy. Here is a list of seven lessons I’ve learned through my own startup years, each boiled down to four words or less:

1. Think and write.
2. Build a network.
3. Follow the Categorical Imperative.
4. Achieve the Buddha calm.
5. Develop a rhythm.
6. Follow your passion.
7. Build great stuff.

The original powerpoint from the CSCS 4753 “Electronic Commerce Technologies” lecture can be found here.

An article version of the talk can be found here.

I am the editor of the Addison-Wesley Software Security series. When Christian Collberg came to me with an idea for a book about software protection, I had a really hard time figuring out whether or not it belonged in the series. Christian is a brilliant researcher and an important guiding light in the field. But should we consider software protection part of software security? Good question! To make matters worse, half the software security people I polled said “yes” and the other half said “no.”

In the end, I held out to see what Christian and his co-authors (who eventually boiled down to one—Jasvir Nagra) came up with. The answer is the excellent book Surreptitious Software. It’s in the series.

I believe that software protection will play a larger and larger role in protecting software from certain security attacks. To name a few concrete cases, imagine these scenarios:

• you’re a game producer and you need to protect your intellectual property against pirates (at least for a month or two after your game is released so you can make some money)
• you’re charged with developing a music playback solution that protects both the player and (maybe) the content (iTunes anyone?)
• you’re a defense contractor storing important military secrets electronically in the very hardware that you fly over enemy territory on purpose. what happens when a predator drone is shot down in Pakistan? what about an American spy plane forced to land in China?
• you’re a smart card vendor making chip cards for payment systems, and the cards will be distributed to good guys and criminals alike
• you’ve built a new game console and you want to protect it from some kinds of tampering
• you’re a programmer with a hot new algorithm that you don’t want your competitors to have
• you want to crash any debuggers that attach to your code and thwart easy disassembly

These and many other problems are directly addressed in Surreptitious Software. The book covers software obfuscation, watermarking, birthmarking, tamperproofing and other aspects of software protection. And it covers them in an exhaustive, scientific, technically-thorough way.

Software protection in many ways turns software security on its head. Imagine a discipline that can be used to cloak virus code, put bugs into code on purpose (which are tripped when the code is tampered with), scramble things up so badly that they are much harder to understand than normal, slow things down (in certain cases), create vast swaths of meaningless nonsense in the middle of real code, and so on. How on earth could any of that be a good thing?

Read this book and find out.

John Pescatore from Gartner convened a virtual panel on the cybersecurity issue at the 2009 Gartner Information Security Summit. I provided a video for the panel answering two questions that John posed. The two questions get to the heart of the cybersecurity issue:

Question 1: What should the US government do to drive real improvements in the security level of internet use?

Question 2: What are things that you believe the US government should specifically not do in the name of increasing cybersecurity?

Click below to watch the video:

Press coverage:

• Gov’t Official: We’re Serious About Cybersecurity This Time
• Moving U.S. Cybersecurity Beyond Cyberplatitudes (InformIT)

IEEE S&P: Securing Online Games (vol.7, no.3)

IEEE Security & Privacy magazine remains the most important trade periodical on security published today. Though the content is on rare occasion esoteric, the magazine is always technically accurate and detailed. Only a peer reviewed publication can offer readers a look at computer security as a science. Think of it as applied academics.

I am pleased to announce that IEEE Security & Privacy magazine’s May/June 2009 edition was recently released. The issue (volume 7: number 3) covers Securing Online Games in a series of four peer reviewed articles that help define the state of the practice.

For more about the issue, see: http://www.computer.org/portal/site/security

Also in the same issue is a print transcript of Silver Bullet 36. That’s the episode where James McGovern turned the tables and interviewed me. That transcript is on the web here.

Beautiful Security

Also of note is a book of thoughtful essays on security put together by John Viega (once a Cigitalite) and Andy Oram. Here’s my original blurb from the back cover:

“This collection of thoughtful essays catapults the reader well beyond deceptively shiny security FUD (the drum major of the bug parade) toward the more subtle beauty of building security in. Security is an essential emergent property for all modern systems—something that most people implicitly expect and few people explicitly receive. This book demonstrates the yin and the yang of security, and the fundamental creative tension between the spectacularly destructive and the brilliantly constructive. Read. Learn. Emulate.”

I’m still working my way a second time through the assembled essays from security stars including mudge, Betsy Nichols, Phil Zimmermann, Mark Curphy, and Jim Routh. This is a must read for 2009.

I just published a little ditty on Twitter security that is bound to get some interesting feedback. My bet is that much of the feedback is less than 140 characters long!

My friend Joe Faber (of Spaghettios fame) sent me this Youtube video, which I think sums up Twitter nicely:

Your longer feedback is welcome below!