In April 2007, I published a darkreading article on the size of the software security space with some analysis of what was happening. It took me a bit longer to gather the numbers this year, but I finally got what I needed and published an informIT article recently explaining how software security is growing.

I am very optimistic about the growth of the software security field over the last few years. Things are certainly moving in the right direction (toward white box analysis instead of outside->in black box, out of the myopic focus on Web apps, and toward full-lifecycle programs based on the touchpoints). The numbers show this growth and these trends objectively.

On a top secret mailing list I participate in, there was some recent discussion about a recent article published by Fortify slamming the Open Source community for failing to adopt software security (you can find the article on the Fortify website). Here’s what I posted to the list (identities masked to preserve secret identities):

I just downloaded and read the Fortify study. It’s more of a white paper than it is science, but it is reasonably well presented and seems not to be too terribly fluffy. You can download a copy for yourself from the Fortify website. In the end what we have is some evidence that there are some open source projects that are behind the curve from a security perspective. I don’t think this should come as a surprise to anyone.

Some specifics based on other postings:

[DoD open source guy] sez>> First, it’s Java-heavy.

This is true. As far as I know, all of Fortify’s open source work has been Java-based (see the Java Open Review project). I don’t see why this impacts the results very much. Though open source Java projects may be a bit less responsive to security, the conclusions in the report are clear about just what set of projects were considered. Then again, I am not at all sure what methods were used to pick 11 out of 101 JOR projects.

[Apache leader] sez>> My experience on the security team at Apache…

Incidentally, when it comes to the results reported, Apache (Tomcat) is the only one of the eleven projects that is reported to have security-specific email, links to security info and access to security experts. One the other hand Apache (Struts) is reported not to have these things, which [DoD open source guy] argues is misleading since the Apache ASF page has these things.

[crypto open source guy] sez >> A better summary would have been “Many developers still don’t care about security.”

Sadly this is true. However as an evangelist in the space I will point out that the commercial world appears to be making much better headway in software security than the open source community (present company excepted of course but I am donning my asbestos suit anyway). I think many of the reasons why commercial software has an unfair advantage were covered in a panel on open source and security that Peter Neumann, Fred Schneider, and I all participated in at Oakland in 2000 (I can dig up e-copies if anybody cares).

One project was singled out for good software security practice: Mozilla. Should we all try to be more like Mozilla?

The debate did not rage on on the top secret list, but it must be raging on somewhere, because Roger Thornton just posted a response to the Fortify blog which you cab read here.

Frankly I was hoping that we killed this thing dead at Oakland in 2000. Guess again!

I’ve written before about how useful comics can be in security training. See a previous blog entry here.

In that brief article, I called out some of Markus Schumacher’s training animations. I’m pleased to report that Markus has asked Cigital to host some of his material. Here are some links:

Example 1: Car Auction

Example 2: Online Application

Cross Site Request Forgery

Forceful Browsing

You can also find these links together in one place on our resources page.

At RSA this year, I did a quick video interview with Dennis Fisher an old friend who is now the lead editor of Search Security. The resulting video is here

Here are the questions I answered during the interview (along with some bonus pointers that I’ll include in this posting). As you can see, we mostly talked about software security:

• Let’s talk about where things stand with the state of software security in the industry today. Are you optimistic?
• I’ve heard a lot of people say that solving the software security problem is going to cost a lot of time and money in the development process. Is that true?

  See this informIT article.

• I know there’s a lot of training that goes on in the professional world in terms of software security for developers, but is that happening more in colleges and universities right now compared to five years ago?

  See this IT Architect article.

• What about the commercial software vendors. How much progress are they making on this problem?
• Are there one or two problems that really worry you in software security right now?

  See this IEEE S&P article.

If you like this video, please let the Search Security people know so they feel compelled to do more.

There are three new books (recently released) that are worth a look. Once is an absolute necessity for any security practitioner. The others may be interesting for some readers of the blog.

The book that you MUST READ RIGHT NOW is the second edition of Ross Anderson’s Security Engineering book. Ross did a complete pass on his classic tome and somehow made it even better. It also comes in handy as a weapon as it is so heavy. Books like Ross’s are a refreshing reality check from the usual pablum published in computer security.

Simply put, this is a must read book for every security professional. I don’t have my real copy yet from the publisher (but they say one is on the way), but I did take a close look through the manuscript. Ross retains his number one slot on my list of top 5 things every software security person should read.

Incidentally, I interviewed Ross for Silver Bullet last year (in April). Ross’s episode is the most popular of all 24 episodes released to date with over 18,000 downloads. You might want to give that a listen as well.

The other two books that are worth a look are Crimeware and The New School of Information Security. Lets cover them in reverse.

The New School of Information Security is a book worth buying for the cover alone. I know of no other computer security book with a Kandinski on the front. Even though I know Adam Shostack from way back (and never could have predicted that he would become a Microsoft guy), I saw his book at RSA, bought it for the cover, and only then discovered that he was the author! My plan was to give the book to a good friend who I know is a huge Kandinski fan. On the way to complete that errand, I had a chance to look though the book and now I need a copy of my own! If you’re a follower of the economics of security school (which Ross and Bruce Schneier have helped spearhead), you’ll like this book.

Crimeware is an academic tome written by my friend Markus Jakobsson. I contributed a chapter on software security bug taxonomy. My copy showed up last night, and I have earmarked more time to read it thoroughly. The enemy has changed over the last decade, and criminals are bringing the game to a new level.

Spring may not be the best reading time, but it does appear to be the best time for a crop of interesting new security books!

I have been writing a monthly column on computer security and software security since October 2004. In the beginning, the column appeared in Network magazine. Later, that magazine was eaten by IT Architect. Here’s a set of pointers to those early articles:

• Who Should Do Security? (October 2004)
• Application Security Testing Tools: Worth the Money? (November 2004)
• How Do Real Bad Guys Break Software? (December 2004)
• Innovative Rootkits: The Ultimate Weapon? (January 2005)
• Are We In a Computer Security Renaissance? (February 2005)
• Where Does Trust Come From? (March 2005)
• Is Your Mac Really More Secure? (April 2005)
• How Does Security Fit With Engineering? (May 2005)
• Are Cell Phones the Next Target? (June 2005)
• Is Penetration Testing a Good Idea? (July 2005)
• Is VoIP Secure Enough For Prime Time? (August 2005)
• Is Cisco Naked? (September 2005)
• How Bad Is Intrusion Detection? (October 2005)
• Is Security Really About Getting Nothing Done? (November 2005)
• When Does Security Cross the Line? (December 2005)
• Is Sony BMG Run By Malicious Hackers? (January 2006)
• Is Application Security Training Worth the Money? (February 2006)
• How Flawed Is Microsoft? (March 2006)

We all know what’s happening to magazines and newspapers, though, don’t we–they’re turning to bits. When CMP killed IT Architect magazine (along with most of the rest of their paper publications), they repurposed much of the content into websites. I started writing for darkreading.com from the very beginning. Here’s a set of pointers to the darkreading articles:

• Microsoft’s Missed Opportunity (May 3, 2006)
• New Terrorist Profile: Phone Users (June 13, 2006)
• If You Build It, They’ll Crash It (July 7, 2006)
• Google is Evil (August 4, 2006)
• Keep Your Laws Off My Security (September 7, 2006)
• Diebold Disses Democracy (October 9, 2006)
• Boarding-Pass Brouhaha (November 2, 2006)
• Foxy Vista Henhouse (December 11, 2006)
• Hurray for Hollywood!? (January 12, 2007)
• Security’s Symbiosis (February 27, 2007)
• Compliance As Kick-Starter (March 12, 2007)
• Want Turns to Need (April 20, 2007)
• Certifiable (May 9, 2007)
• JSON, Ajax & Web 2.0 (June 7, 2007)
• Consolidate This (July 12, 2007)
• The Ultimate Insider (August 14, 2007)
• Mobile Insecurity (September 14, 2007)
• Online Games & the Law (October 11, 2007)
• Beyond the PCI Band-Aid (December 10, 2007)
• Software Security Strategies (January 9, 2008)
• The Truth Behind Code Analysis (February 13, 2008)

Just recently, I decided to move my monthly column to informIT. The readership is much larger, and I like the affiliation with the company who publishes my books. As part of that move, you can also expect to see Silver Bullet syndicated through informIT as well. You can help me make the move a success by keeping up with my column through informIT. (We’re also planning an RSS feed for articles too, so watch for that as well.)

The first column for informIT is just as much about business as it is about technology. One of the issues we constantly face at Cigital is the problem of helping our customers sell the idea of software security best practices up the chain. A common (and misguided) view is that software security best practices increase development time and add cost. As you can see in my first column, that’s simply not true. Here’s a pointer:

Software [In]security: Paying for Secure Software

I’m very much interested in your feedback on my column and any suggestions you have for topics. Feel free to use the forum below to get in touch. Thanks for reading!

There has been a recent flurry of activity regarding security assurance on a hush-hush open source mailing list I lurk on. The debate recently has to do with formal methods versus code scanning… apples and oranges in my view. However, there’s a new flurry of press over Coverity’s use of their tool to analyze well-known globs of open source. (One poster suggested that passing a scan like this with flying colors means security has been attained… argh!)

Some pointers:

From Slashdot
Posted by: kdawson, on 2008-01-09 01:20:00

Stony Stevenson alerts us to a US Department of Homeland Security program in which subcontractors have been examining FOSS source code for security vulnerabilities. InformationWeek.com takes a glass-half-empty approach to reporting the story, saying that for FOSS code [1]on average 1 line in 1000 contains a security bug. From the article: ‘A total of 7,826 open source project defects have been fixed through the Homeland Security review, or one every two hours since it was launched in 2006…’ ZDNet Australia prefers to emphasize those FOSS projects that [2]fixed every reported bug, thus achieving a clean bill of health according to DHS. These include PHP, Perl, Python, Postfix, and Samba.

Firstly, I am a big fan of code scanning and believe that use of static analysis tools should always be one of the basic security steps integrated into every SDLC. However, there are huge problems with declaring security after passing a code scan with an arbitrary tool and a random set of rules. The most obvious issue is that security defects come in two flavors—bugs and flaws—each accounting for roughly 50% of defects in practice. Code scanning tools can only find bugs. Here are two stupid examples for effect: can a code scanning tool determine that no user authentication was performed? How about whether or not a playback attack will work?

The second most obvious problem is that the list of rules enforced by a static analysis engine can never be complete. Discussion about this is left as an exercise for the reader.

Architectural risk analysis (crazily called “threat modeling” by Microsofties) is, like code scanning, an essential software security best practice. Formal methods are one way to go about attacking the flaw problem. In the US we rely on flakier heuristic-based approaches such as the one we use at Cigital. But no matter the approach, we can’t ignore the architecture.

References

1. http://www.informationweek.com/story/showArticle.jhtml?articleID=205600229&cid=RSSfeed_IWK_All
2. http://www.zdnet.com.au/news/security/soa/11-open-source-projects-pass-security-health-check/0,130061744,339284949,00.htm

Merry New Year to all. Here’s to even better software security in 2008.

As many of you know, I have a podcast called “The Silver Bullet Security Podcast with Gary McGraw.” The premise of the podcast is to interview various security gurus, both from industry and academia. We’ve done some great ones, including Ross Anderson, Bruce Schneier, and John Stewart.

For episode 21 of the podcast, I interviewed the Cigital principals…the very people who (supposedly) produce this blog. You can download the podcast here.

We’ve also made a transcript of the show available in pdf form.

During the show we talk plenty about some of the lessons we’ve learned about enterprise software security from our work with customers. We also compare and contrast the Touchpoints, CLASP, and Microsoft’s SDL.

While you’re surfing for multi-media, you might get a kick out of this Merry New Year message from Silver Bullet.

Everyone agrees that user education plays an important role in security, but does it really have to be so boring? How many security basics courses droning on about password security must we suffer through before we hit on a better way? Can comics help?

Cartoons certainly have popular appeal. They can get important messages across in a concise way. They can even be funny, boosting the chances that they’ll spread far and wide (like the latest silly youtube video). Plus, animated cartoons can be used to present very complex material in an easily digestable form—especially useful when such description requires an element of time.

Before we jump into the security cartoon pond, I have a confession to make—every night I read the comics pages published by my local paper, the Washington Post. I’m not sure I learn anything, but it sure is fun. This nightly ritual may color my thinking about security cartoons.

Cartoons for the masses

Security gurus often glibly state that if it weren’t for users, we wouln’t have any security problems. Is this anything more than a good laugh line? User behavior alone clearly can’t singlehandedly solve the security problem, but some critical aspects of security do in fact hinge on user behavior. Think about malicious code propagation through attachments in popular office formats like Adobe pdf for just a moment, and you’ll see what I mean.

The problem is that security can be complicated, and to non-geeks who don’t really grok technology (and who really don’t want to) the right security decisions can sometimes be hard to make. This is particularly apparent when it comes to user-faced attacks like Phishing and Pharming. How could opening an attachment really be that big a problem? Anyone even remotely familiar with security knows the answer, but many millions of others think security people are overly paranoid and only want to ensure nobody ever gets any work done. This is a situation where comics can help.

Markus Jakobsson and Sukamol Srikwan are academics who specialize in computer security. Markus is particularly well-known among scientific researchers for his work in ecrime with a focus (and some impressively-heavy published tomes) on phishing and pharming. Markus and Sukamol believe that poor user education is an important risk that must be addressed if we want to get a handle on identity theft and botnets. To address the awareness problem, they created a website called SecurityCartoon.com.

Securitycartoon.com is devoted to describing user-related security issues in easy ways. The material published so far covers spoofing, malware, phishing, pharming, passwords, and electronic voting. The latest security cartoon can be pasted into your own website with the following Javascript:

<script src="http://www.securitycartoon.com/today.js"></script>

Here’s a copy of today’s comic:

In an academic paper, Markus and Sukamol discuss the reasons they believe cartoons are an effective education technique. You can download their paper “Using Cartoons to Teach Internet Security” from the DIMACS website. In the paper, they describe the reasons they created SecurityCartoon.com and cover a number of technical examples of what works and what doesn’t in terms of user education. Critical to their approach is a focus on what and why (and not just what) behind real user-faced attacks. Using an entertaining medium helps solve a difficult problem.

Cartoons for security people

The use of cartoons does not need to be limited to non-technical users. Even experienced security people can benefit from cartoons. As an example, consider the well-publicized but not that well-understood cross-site scripting (XSS) attack.

Here’s how Greg Hoglund and I introduce XSS in Chapter 5 of Exploiting Software (Addison-Wesley 2004):

Cross-site scripting (XSS) has become a popular subject in security, but XSS is really only yet another example of in-band signals being interpreted by client software—in this case, the Web browser. XSS is a popular attack because Web sites are both common and numerous.

To carry out an XSS attack, an attacker can place a booby trap within data using special escape codes. This is a modern form of using terminal escape codes in filenames or talk requests. The terminal, in this case, is the Web browser that includes advanced features such as the capability to run embedded Javascripts. An attack can inject some toxic Javascript or some other mobile code element into data that are later read and executed by another user of the server. The code executes on the victim’s client machine, sometimes causing havoc for the victim. Figure 5–1 shows an example of Web-based XSS in action.

Find that explanation a bit opaque? Many people do. The problem is the nature of XSS, which unfolds over time.

An animated cartoon can itself unfold over time and make understanding XSS much easier. Markus Schumacher of the German company Virtual Forge GmbH has created a number of movies describing complicated security attacks. His explanations not only describe the what and why (as user-related cartoons must do as I describe above) but also covers the how in explicit detail. These kinds of movies are extremely useful as technical training examples.

You can watch Schumacher’s XSS animation here. You will see that understanding XSS in this medium beats what can be done in the printed word any day.

My all time favorite security cartoons are those that use humor. There are numerous Web-based cartoons that cover technical issues. One, called xkcd describes itself as a “webcomic of romance, sarcasm, math, and language. xkcd sometimes covers security issues. In a strip entitled “Exploit of a Mom,” xkcd covers SQL injection (another very popular attack that is not well-understood) in a very silly fashion. This comic was so popular that I got pointers to it from 5 different people over the course of a week as it made the email rounds. Check it out yourself, I think you’ll find it pretty funny.

In the end, I think it’s clear that cartoons can help with the education problem. They are certainly a far site less boring than generic training!

The insider threat has always been invoked and then ignored by computer security types. That kind of treatment may have worked (accidentally) during the network security days, but such old-fashioned thinking is quickly becoming a problem as distributed software becomes more complex. The problem is really one of trust, and the new insider is built right into modern software.

Put on your software architect hat for a moment. Most architects think in terms of boxes and arrows. The boxes roughly correspond to software components, with the arrows being connections between components. In a standard view like this, there is little or no notion of trust. That is, all components are equal in the eyes of the designer.

The problem is that in new massively distributed software architectures (think Google Desktop or World of Warcraft clients) have components that run entirely on untrusted machines. If part of your software architecture runs on a potential attacker’s box you really need to think hard about what happens when it is manipulated. If you don’t, you quickly become subject to insider attacks of a new sort. Your own software will attack itself.

When building a boxes and arrows architecture for modern software (especially SOA software), make sure that you explicitly consider the trust model and take into account the new twist on insider attacks. Be especially mindful of time and state problems. Make sure that trusted servers think carefully about any state that they consume from untrusted clients.

For a couple of examples of this and a slightly more formal treatment, see my Darkreading column from 8/14/07.

Technorati Tags: software security, world of warcraft, WoW, software