Author Archive

Three New Books

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.

security-engineering.jpg

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.

new-school.jpg

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.jpg

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!

Making a move

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:

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:

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!

On Open Source

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

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.

Kapow! Comic Book Security

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.

Figure 5.1 from Exploiting Software

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!

Software, the New Insider Threat

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: , , ,

Preface from Exploiting Online Games

(This entry is from the preface to the new book Exploiting Online Games that I co-authored with Greg Hoglund. The book is available in stores on Friday.)

Online games, including World of Warcraft, EverQuest, Second Life, and online poker, have taken the computer world by storm. Gaming has always been (and remains) among the prime drivers of PC technology, with deep penetration into the consumer market. In the last ten years, computer games have grown just as quickly as the Internet and can now be found in tens of millions of homes.

The Internet is experiencing plenty of adolescent growing pains along with its phenomenal growth. These pains are experienced mostly in terms of problematic and pervasive computer security issues. Online games, especially massively multiplayer online role-playing games (or MMORPGs for short), suffer from these security problems directly.

MMORPGs are made of very sophisticated software built around a massively distributed client-server architecture. Because these games push the limits of software technology, especially when it comes to state and time (not to mention the real-time interaction of hundreds of thousands of users), they are particularly interesting as a case study in software security. In fact, MMORPGs are a harbinger of technical software security issues to come.

Modern software of all kinds (not just game software) is evolving to be massively distributed, with servers interacting with and providing services for thousands of users at once. The move to Web Services and Service Oriented Architectures built using technologies like AJAX and Ruby follows hard on the heels of online games. What we learn here today is bound to be widely applicable tomorrow in every kind of software.

Adding to the urgency of the security problem is the fact that online games are big business. The most popular MMORPG in the world, World of Warcraft by Blizzard Entertainment, has over 8 million users, each of whom pay $14 per month for the privilege of playing. Analysts estimate the gaming market will reach $12 billion by 2009.

Inside the virtual worlds created by MMORPGs, simple data structures come to have value, mostly a reflection of the time gamers spend playing the game. Players accumulate and trade virtual wealth (or play money). Many of these virtual economies have per capita GDPs greater than most small nations. Not surprisingly, direct connections between the virtual economies of games and the real economy exist all over the place. Until recently, it was possible to buy in-game play money with real dollars on eBay; now many other well-developed middle markets exist. And the reverse is possible, too. This has led to the emergence of a class of players more interested in wringing virtual wealth out of the game than playing the game itself.

Wherever money is at stake, criminals gather and linger. Cheating happens. In the case of MMORPGs, cheaters have real economic incentive to break the security of the game in order to accumulate virtual items and experience points for their characters. Many of these items and even the characters themselves are then sold off to the highest bidder.

Sophisticated hackers have been working the fertile fields of MMORPGs for years, some of them making a living directly from gaming (or cheating at gaming). This book describes explicitly and in a technical way the kinds of attacks and techniques used by hackers who target games.

Why Are We Doing This?

As you can imagine, game companies take a dim view of cheating in their games. If cheating becomes rampant in a game, unsatisfied noncheating players will simply move on to another. Game developers have taken a number of steps to improve security in their games, some of them controversial (monitoring game players’ PCs behind the scenes), others legalistic (imposing strict software license agreements and terms of use), and some of them trivial to break (using symmetric cryptography but including the secret key in the game client code). Our hope is that by understanding the kinds of attacks and hacking techniques described in this book, game developers will do a better job with online game security.

We think our topic is important for several reasons: First, real money is at stake; second, many players are completely unaware of what is going on; and third, online game software security has many critical lessons that we can directly apply to other, more important software. Plus, it’s fun and controversial.

For example, some game companies have been known to use stealthy techniques most often seen in rootkits to monitor gamers’ PCs. They have also been known to resort to strong-arm tactics to suppress hackers, even those not attempting in any way to be malicious or to make money. Will manufacturers of other software or digital content adopt these techniques for themselves?

Not only are the technical issues captivating, the legal issues surrounding online games and their creative software license terms are also a harbinger of things to come. The legal battles between game companies, academics, and users are by no means over—in fact, they have just begun.

In the end, the topic of online game security poses a number of interesting questions, the most pressing one being this: How do you balance gamers’ privacy rights against game developers’ desires to prevent their games from being hacked?

Where Do We Draw the Line?

For the record, we do not condone cheating, malicious hacking, or any other game-related shenanigans. We are most interested in deeply understanding and discussing what’s going on in online game security. As practical security experts, we believe that only by gaining direct technical understanding of what happens when games are exploited can we begin to build systems that can withstand real attacks. Because in this situation money is at stake, you can be sure that attacks and exploits today are both concerted and organized.

We think it is acceptable and necessary to understand both how games really work and how they fail. The only way to do this is to study them carefully. We pull no punches technically in this book, showing you how online game clients fail from a security perspective in living detail. We also explicitly describe techniques that can be used to exploit online games. We don’t do this to create an army of online game hackers—that army is already brimming in numbers, and those already enlisted in it are unlikely to learn much from this book. We do this so that the good guys will know what they are really up against. Our main objective is to describe the kinds of weapons the existing active army of game attackers has.

In our research for this book, we have broken no laws. We expect our readers likewise not to break the law using the techniques we describe.

What’s In the book?

Like most books, this book starts out at a high level and becomes progressively more technical as it goes on.

Chapter 1, Why Games?, poses and answers some simple questions. How big are online games? How many people play? Why would anyone want to exploit them? What motivation is there to cheat in an online game? The answers to these questions will likely surprise you. Believe it or not, 10 million people play online games, billions of dollars are at stake, and some people even cheat for a living. We also provide a gentle introduction to game architecture in Chapter 1, describing the classic client-server model that most games use.

Things get more technical beginning in Chapter 2, Game Hacking 101, where we describe the very basics of game hacking. The chapter is organized around describing six basic techniques: (1) building a bot, (2) using the user interface, (3) operating a proxy, (4) manipulating memory, (5) drawing on a debugger, and (6) finding the future. We pay special attention to the topic of bots since most game exploits exist to create and operate them. Late in the chapter, we even show a very simple bot that we built so you can see exactly what bot software looks like. We then describe controversial moves taken by one game maker to thwart cheating—installing rootkit-like spyware on a gamer’s PC to keep track of what’s going on. We hold this approach in low opinion and have written a program to help you know what’s going on with these monitoring programs on your own machine. We believe game makers would be better off spending their resources to build games that were less broken than to build monitoring technology.

The next two chapters take a break from technical material to cover money and the law. In particular, Chapter 3, Money, helps us understand why some players might want to cheat. The recent book Play Money by Julian Dibbell (Basic Books, 2006) describes one (pathetic) man’s foray into professional game farming, something that a number of people actively pursue. There is enough money in play here that entire enterprises have grown up around providing middleman services for gamers, buying and selling virtual items in a marketplace. The biggest and most interesting company, Internet Gaming Entertainment, known as IGE to most people, deserves and gets a treatment of its own in this chapter.

Chapter 4, Enter the Lawyers, is about the law. Game companies (and indeed a whole host of other software makers) have created a licensing jungle in the form of end user license agreements (EULAs) and terms of use (TOU) documents. Though we are not lawyers, and by no means should you rely on our advice, we provide a brief description of U.S. copyright law and the Digital Millennium Copyright Act (DMCA). Then we go through an entertaining (and somewhat scary) parade of EULAs gone bad—from Sony’s rootkit debacle to viruses protected by EULAs. We end up with a discussion of your rights as a software user and gamer.

Technical aspects of online game security begin to pick back up in Chapter 5, Infested with Bugs. We spend this chapter talking about the kinds of vulnerabilities found in many games, explaining how attackers usethem to build working exploits. We pay particular attention to bugs involving time and state, which, as we alluded to earlier, are the kinds of bugs we can expect to see much more of as other software evolves to become more like game software.

Chapter 6, Hacking Game Clients, really digs in and gets technical. As we move more deeply into games, we are forced to use a game or two as a particular target. We don’t do this to single out any one game; instead, we do this to make our examples salient and technical. We have chosen to concentrate on World of Warcraft (WoW), a game produced by Blizzard Entertainment, mostly because it is the number one online game in the world. The kinds of techniques we demonstrate using WoW as an example can be applied by analogy to almost any online game (and to modern Web 2.0 software, for that matter). Chapter 6 begins with a discussion of the attacker’s toolkit (many of the tools we describe are standard software testing tools). We then organize our discussion of game hacking techniques into four equally important areas: (1) getting over the game by using its user interface directly, (2) getting inside the game by manipulating memory, (3) getting under the game by interposing on services like video drivers, and (4) getting way outside the game by intercepting and manipulating network traffic. Chapter 6 is in some sense the heart of the book, introducing a large number of techniques commonly used by game attackers.

Chapter 6 has lots of data in it, probably too much. Sometimes it is easier to understand these kinds of techniques by seeing how they are put into practice. Toward that end, in Chapter 7, Building a Bot, we put together all of the lessons of Chapter 6. Chapter 7 is technical, with plenty of example code showing how the ideas in Chapter 6 work in concert to exploit a game.

Chapter 8, Reversing, is even more technical, focusing its attention on reverse engineering techniques that many attackers use to exploit software. Though the techniques we describe in this chapter are intense, they are by no means new. As we describe in our book Exploiting Software (Addison-Wesley, 2004), disassemblers and decompilers are used in computer security every day, both by good guys and by bad guys.

The final technical topic in our book is presented in Chapter 9, Advanced Game Hacking Fu. This chapter discusses what is known in the trade as total conversions and game mods. We describe the process by which some people take apart game data files in order to build their own games or combine different aspects of games in interesting ways. Though some game companies try hard to quash all discussion of total conversion, it happens anyway. We describe how.

Of course, our purpose in this book is to help those who build games understand how to do a better job with security. Chapter 10, Software Security Über Alles, provides a flyover of the new field of software security. Game developers would do well to adopt some of the best practices in common use in the financial vertical today. We also describe a set of questions that everyday gamers can ask their game companies about security. Our fervent hope is that this book will lead to more secure software—both in the game community and beyond.

The Software Security Series

This book is part of the Addison-Wesley Software Security Series of software security books for professional software developers. The series includes the following titles:

  • Exploiting Online Games: Cheating Massively Distributed Systems
  • Secure Programming with Static Analysis
  • Software Security: Building Security In
  • Rootkits: Subverting the Windows Kernel
  • Exploiting Software: How to Break Code
  • Building Secure Software: How to Avoid Security Problems the Right Way

More books in this series are planned for the future. Contact Addison-Wesley or Gary McGraw for more information. Also see the Web site.

From the foreword to Secure Programming with Static Analysis

This is the foreword that I wrote for Brian Chess and Jacob West’s excellent new book Secure Programming with Static Analysis. I recommend this book for all software security practitioners. Developers, in particular, will find the book extremely helpful. For more on other books in the software security series, see http://www.buildingsecurityin.com.

On the first day of class, mechanical engineers learn a critical lesson—pay attention and learn this stuff or the bridge you build could fall down. This lesson is most powerfully illustrated by a video of the Tacoma Narrows Bridge shaking itself to death. Figure 0-1 shows a 600-foot section of the bridge falling into the water in 1940. By contrast, on the first day of software engineering class, budding developers are taught that they can build anything that they can dream of. They usually start with “hello world.”

Tacoma Narrows bridge

Figure 0-1: A 600-foot section of the Tacoma Narrows bridge crashes into Puget Sound as the bridge twists and torques itself to death. Mechanical engineers are warned early on that this can happen if they don’t practice good engineering.

An overly-optimistic approach to software development has certainly led to the creation of some mind-boggling stuff, but it has likewise allowed us to paint ourselves into the corner from a security perspective. Simply put, we neglected to think about what would happen to our software if it were intentionally and maliciously attacked.

Much of today’s software is so fragile that it barely functions properly when its environment is pristine and predictable. If the environment that our fragile software runs in turns out to be pugnacious and pernicious (as much of the Internet environment turns out to be) software fails spectacularly, splashing into the metaphorical Puget Sound.

The biggest problem in computer security today is that most systems aren’t constructed with security in mind. Reactive network technologies such as firewalls can help alleviate obvious script kiddie attacks on servers, but they do nothing to address the real security problem—bad software. If we want to solve the computer security problem, we need to do more to build secure software.

Software security is the practice of building software to be secure and function properly under malicious attack. This book is about one of software security’s most important practices—code review with a static analysis tool.

As practitioners become aware of software security’s importance, they are increasingly adopting and evolving a set of best practices to address the problem. Microsoft has carried out a noteworthy effort under its Trustworthy Computing Initiative. Many Cigital customers are in the midst of enterprise scale software security initiatives. Most approaches in practice today encompass training for developers, testers, and architects; analysis and auditing of software artifacts; and security engineering. There’s no substitute for working software security as deeply into the development process as possible and taking advantage of the engineering lessons software practitioners have learned over the years.

In my book Software Security, I introduce a set of seven best practices called touchpoints. Putting software security into practice requires making some changes to the way most organizations build software. The good news is that these changes don’t need to be fundamental, earth shattering, or cost prohibitive. In fact, adopting a straightforward set of engineering best practices, designed in such a way that security can be interleaved into existing development processes, is often all it takes.

Figure 0-2 specifies the software security touchpoints and shows how software practitioners can apply them to the various software artifacts produced during software development. This means understanding how to work security engineering into requirements, architecture, design, coding, testing, validation, measurement, and maintenance.

Software Security Touchpoints

Figure 0-2: The software security touchpoints as introduced and fleshed out in Software Security: Building Security In.

Some touchpoints are by their very nature more powerful than others. Adopting the most powerful ones first is only prudent. The top two touchpoints are Code review with a static analysis tool, and Architectural risk analysis. This book is all about the first.

All software projects produce at least one artifact—code. This fact moves code review to the number one slot on our list. At the code level, the focus is on implementation bugs, especially those that static analysis tools that scan source code for common vulnerabilities can discover. Several tools vendors now address this space, including Fortify Software the company that Brian and Jacob work for.

Implementation bugs are both numerous and common (just like real bugs in the Virginia countryside) and include nasty creatures like the notorious buffer overflow, which owes its existence to the use (or misuse) of vulnerable APIs (e.g., gets(), strcpy(), and so on in C). Code review processes, both manual and (even more important) automated with a static analysis tool, attempt to identify security bugs prior to the software’s release.

Of course, no single technique is a silver bullet. Code review is a necessary but not sufficient practice for achieving secure software. Security bugs (especially in C and C++) are a real problem, but architectural flaws are just as big a problem. Doing code review alone is an extremely useful activity, but given that this kind of review can only identify bugs, the best a code review can uncover is around 50% of the security problems. Architectural problems are very difficult (and mostly impossible) to find by staring at code. This is especially true for modern systems made of hundreds of thousands of lines of code. A comprehensive approach to software security involves holistically combining both code review and architectural analysis.

By its very nature, code review requires knowledge of code. An infosec practitioner with little experience writing and compiling software is going to be of little use during a code review. The code review step is best left in the hands of the members of the development organization, especially if they are armed with a modern source code analysis tool. With the exception of information security people who are highly experienced in programming languages and code-level vulnerability resolution, there is no natural fit for network security expertise during the code review phase. This may come as a great surprise to those organizations currently attempting to impose software security on their enterprises through the infosec division. Even though the idea of security enforcement is solid, making enforcement at the code level successful when it comes to code review requires real hands-on experience with code.

The problem is that most developers have little idea what bugs to look for, or what to do about bugs if they do happen find them. That’s where this book, Secure Programming with Static Analysis, comes in. The book that you have in your hands is the most advanced work on static analysis and code review for security ever released. It teaches you not only what the bugs are (what I sometimes call the “bug parade” approach to software security), but how to find them with modern static analysis tools, and more importantly what to do to correct them. By putting the lessons in this book into practice, you can go a long way toward helping to solve the software security problem.

You can purchase a copy of Secure Programming with Static Analysis from Amazon.

Technorati Tags: , , , ,

Software Security Now: 2006 Shows Impressive Growth

In my April darkreading column, “Want Turns to Need,” I describe the state of the market for software security. I am very much optimistic about the software security space. In a few short years, we have created a space with a small ($250-275 million) but growing market niche. Last year, the tools market doubled in size, with services also showing very strong growth. Weighing in at about a quarter billion dollars, software security is a field that can no longer be ignored. As a field, we’ve successfully moved past philosophy and well into action. It’s a good time to make sure your firm is on board.

Back when I helped to invent software security in 1997 (after writing Java Security with Ed Felten from Princeton), there were zero books and only a few papers. That’s one of the reasons John Viega and I wrote Building Secure Software–we wanted to write something for software developers and architects interested in building security in. In the eight years since then, the field has blossomed. Today, an entire shelf full of books exists. Here’s a chronological list of eleven good ones (including three that I wrote):

  • Building Secure Software (Viega and McGraw, 2001)
  • Security Engineering (Anderson, 2001)
  • Writing Secure Code (Howard and LeBlanc, 2002)
  • How to Break Software Security (Whittaker and Thompson, 2003)
  • Exploiting Software (Hoglund and McGraw, 2004)
  • 19 Deadly Sins of Software Security (Howard, LeBlanc, and Viega, 2005)
  • Software Security (McGraw, 2006)
  • The Security Development Lifecycle (Howard and Lipner, 2006)
  • The Art of Software Security Testing (Wysopl, et al., 2006)
  • The Art of Software Security Assessment (Dowd, et al., 2006)
  • Foundations of Security (Daswani, 2007)

Even with all of this progress, many people remain pessimistic about the space. Though the Yankee Group estimates that the entire market is between $250-275 million dollars, they state the case in pessimistic terms. I am much more optimistic about the growth of the field than Andrew Jaquith appears to be from the title of his report (though check out his excellent new book on security metrics!).

In my darkreading article, I describe why software security is transforming from a nice-to-have into a necessity. Many companies are trying to determine how to get started. The article goes on to describe software security tools (including badness-ometers and source code analysis tools. The combined market for these tools was between $90 and $100 million in 2006. I believe that the black box testing tools are driving demand for solutions that do more than identify the problem. Source code analysis tools are selling into this demand. This is great news for companies like Fortify and Ounce Labs.

Software security services are equal in tools to revenue, with numbers between $80 and $120 million in 2006. These services ran a large gamut, from simple minded penetration testing (usually wielding a black box testing tool) at one end, all the way through sophisticated enterprise initiatives at the other. In 2006, services surrounding more complete software security initiatives at the enterprise level came into vogue. These large scale initiatives include training for thousands of developers, the creation of enterprise-specific knowledge and guidance, and the integration of software security best practices (which I call the touchpoints) into the software development lifecycle. Cigital specializes in the strategic delivery of enterprise software security initiatives.

Check out the darkreading column for a list of ways to get started in software security. I briefly touch on:

  • Using badness-ometers to make the problem apparent
  • Hiring outside help to carry out deeper analysis of critical programs
  • Introducing code review to the dev team
  • Basic software security training

But by far, the most efficient way to approach software security is through a well planned enterprise software security initiative. We have several such initiatives underway at a number of our most important customers. This is no trivial undertaking, but it has always resulted in marked improvement for Cigital customers.

Software security is quickly becoming a business necessity. SOX and PCI compliance activities serve to help corporations better understand their software risk. Because the impact of software failure (maliciously caused or otherwise) is great, many corporations are already working dilligently on software security. The time has come for everyone to get started.

Technorati Tags: , , ,

Badness-ometers are good. Do you own one?

Never one to mince words, I coined the term badness-ometer to describe “application security testing tools” like the ones made by SPI Dynamics and Watchfire. For whatever reason, people read more into the term than I intended. I guess they see the term as having only negative connotations. I stick by my nomenclature–black box application security testing tools are in fact badness-ometers–but badness-ometers are a good thing and everyone should use them!

Here’s part of what I wrote about badness-ometers in my book Software Security:

That said, application security testing tools can tell you something about security—
namely, that you’re in very deep trouble. That is, if your software fails any of the canned tests, you have some serious security work to do. The tools can help uncover known issues. But if you pass all the tests with flying colors, you know nothing more than that you passed a handful of tests with flying colors.

Put in more basic terms, application security testing tools are “badness-ometers,” as shown in [the Figure below]. They provide a reading in a range from “deep trouble” to “who knows,” but they do not provide a reading into the “security” range at all. Most vulnerabilities that exist in the architecture and the code are beyond the reach of simple canned tests, so passing all the tests is not that reassuring. (Of course, knowing you’re in deep trouble can be helpful!)

Badness-ometerI also wrote an article for Dr. Dobbs called “Beyond the Badness-ometer.” That article stresses the fact that solely relying on a badness-ometer as your only software security activity is a really bad idea.

So what’s good about badness-ometers, and why do I think you should buy one right away? Well, many organizations that build software are woefully in the dark about their software security risk. A badness-ometer can do wonders to turn the lights on with respect to software security, especially when it comes to Web applications.

The sad fact is that many purveyors of Web applications believe that their apps are “bulletproof” if they use simple security features like authentication and SSL. Of course we all know by now that software security goes well beyond security features and deep into enemy territory, concerning itself with things like software defects (bugs and flaws) that lead to software security failure and unacceptable business consequence. Badness-ometers can help expose this “myth of security features” for what it is–a myth–by automatically attacking and taking down Web applications through obvious everyday security tests. Automated testing is cheap and sometimes powerful.

The great irony of badness-ometers is that you can be sure that your enemy will use them. In fact, throughout the decade that I have been practicing software security, bad guys have been more adept at adopting advanced tools and techniques than the good guys generally have.

When it comes to deciding whether your organization needs a badness-ometer, you should ask yourself whether you already know your software is at risk or whether you need some more convincing. If you, or anyone else in your organization, need more convincing, grab a badness-ometer and find out whether your code is in “deep trouble.” I bet it is.

If you are using a badness-ometer today, and it’s finding issues in your code, don’t simply fix the issues and call it a day. Never forget that the badness-omemter can’t tell you that you’re secure. It can only tell you that you’re not. To get beyond simple badness-ometer tests or to fix the problems that your badness-ometer is finding, seek professional help from Cigital.

Technorati Tags: ,



Resources
> Overview
> Your Account
> Podcast
> Blog
> Case Studies
> White Papers
> Publications
> Books
> Security Articles
> Presentations


RSS

About the Bloggers
  • Pravir Chandra
  • Scott Matsumoto
  • Gary McGraw
  • Sammy Migues
  • Craig Miller
  • John Steven
  • Categories
  • Admin (3)
  • Assurance (6)
  • Data Security (3)
  • Defects, Bugs, and Flaws (3)
  • Enterprise Software Security (11)
  • General Interest (3)
  • Governance and Regulation (5)
  • Risk Management (4)
  • Security Features (2)
  • SOA and Web 2.0 (2)
  • Software Quality (4)
  • Software Security (32)
  • Software Security Touchpoints (7)
  • Software Testing (2)
  • Training (3)
  • Archives
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007
  • February 2007
  • By Blogger
  • Craig
  • Gary
  • John
  • Pravir
  • Sammy
  • Scott
  • Guest bloggers
  • Recent Comments
  • Rafal Los on Is Penetration Testing Security Testing?: John, Fascinating analysis. I would like to...
  • gem on Three New Books: Thanks Adam (and sorry not to make your role explicit Andrew). I’m...
  • Adam on Three New Books: Thanks Gary! your copy is on its way. Just a little nit, I’m the...
  • Andre Gironda on Is Penetration Testing Security Testing?: From a book I recently read: Functional...
  • Tom Van Vleck on Security And Market Forces: I can’t come up with a number for how much money I...
  • Recent Entries
  • Unsafe at any bitrate?
  • Three New Books
  • Is Penetration Testing Security Testing?
  • Externalizing Access Control Quandary
  • Making a move
  • Links
  • Cigital
  • Silver Bullet Podcast
  • Blogroll
  • 1 Raindrop
  • Fortify Software's Blog
  • Freedom to Tinker
  • In the Wild
  • Jon Udell
  • Michael Howard's Blog
  • Microsoft Security Vulnerability Research and Defense
  • News.com Security Blog
  • Schneier on Security
  • Security Fix
  • SilverStr's Blog
  • Tao Security