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

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

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.

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: touchpoints, software security, static anlaysis, Brian Chess, Jacob West

Benjamin Tomhave wrote about “tiering” security guidance when I cross-posted a comment to my last blog entry on the SC-L mailing list. Quoting him:

The higher up you are in the policy framework, the more general and time-enduring the content should be. The farther you progress down the framework to a more detailed level, the more perishable the content will be, out of necessity.

Later he continues:

…is because implementers need it. They’re not security experts (usually) and do not necessarily grok security the same way a seasoned (salty?) security person might.because “implementers need it”.

This tiering was implicit to my first post. In fact your most senior security resources can probably use nothing but Security Principals (as described by McGraw’s BSS Book and the famous Saltzer paper) and find both insidious vulnerabilities as well as brand-new “Game over” architectural flaws with new development technologies they aren’t familiar with. But, the more junior (inexperienced) or development-oriented (constructive) the person being targeted, the more specific the guidance must be in order to be valuable without requiring inordinate effort.

Because we’re trying to change the behavior of the majority of our Developers–who range in skill from OK to Hero and whom may have never had even a security awareness class–I find “technology-specific” guidance moves the ball the furthest.

In my previous two posts I talk about forms various levels of standards take, and the way in which one might create it. It occurs to me that I all but showed the bigger picture and might as well follow up to do so. Below, you’ll find a map of how I show security guidance flowing throw and effecting a software development team (click-through for full detail):

As information moves from top to bottom and from left to right it becomes more specific and actionable, but also more perishable (as has been said). To build security in, one must think about security’s implications throughout the lifecycle, so I see no reason why security knowledge (regardless of how specific) shouldn’t mirror artifacts used to construct the application itself: software requirements, design, and the code itself.

Though not central to this discussion, the diagram has been annotated to indicate who should produce and consume this information. Here, I’ll point out that your centralized Application Security Resources can probably most effectively and efficiently create the generic security guidance, but will need help of Security Architects to create the more technology-specific guidance and garner broad buy-in.

My last post presented a brief model of how one might organize and fund this in practice.
-jOHN

Technorati Tags: knowledge architecture, software security

Software security veterans have all certainly thought about the idea of ‘securing the SDLC’… I can tell because every consulting firm’s collateral that I’ve seen in the past year has a new bullet under their ‘services’ section referring to something like ‘Secure development process integration’ or ‘Secure SDLC services’. That being said, let’s talk about what this means for a second. Fundamentally, there are a few ‘different’ schools of thought out there (and as it’ll turn out, they’re not all that different at all).

I know of three popular ways of looking at the problem, 1) Microsoft SDL 3.0 (with a recent book by Howard and Lipner to codify the subject), 2) Software Security Touchpoints from Gary’s book Software Security, and 3) CLASP (originally developed by Secure Software, Inc, and now an open project through OWASP). BTW, if anyone knows of other publicly usable process methodologies, by all means email me since I’d love to read about them.

After spending a bit of time thinking through all these different ideas, a few interesting points emerge. First, there’s not much difference between SDL, the Touchpoints, and CLASP. There’s just about nothing I can see where these processes fundamentally disagree. The differences are really only in the timing and the extent of the prescribed activities (i.e. they each cover the bases of what you should be doing, some just give different orderings to the activities and talk about the sub-steps in different ways). My personal opinion is that SDL is particularly suited for companies like MS (large ISVs with large user populations) and process like the Touchpoints and CLASP are a bit more flexible and widely applicable.

So what’s the deal? Do we have the problem of dev process augmentation solved and put to bed? Heck no. Consider the following quote that popped up in a discussion my buddy Gunnar Peterson and I had at the recent OWASP conference in Milan: “Amateurs talk about tactics, debutants talk about strategy, but professionals talk about logistics.” (this quote has many variations and is hard to find a definitive source, but it’s likely from a US military officer many years ago). As the software security space was emerging, you bet we had to crawl from the primordial ooze by figuring out some tactics to stop the bleeding. Logically following, lots of smart folks sat down and figured out the right way (via experimentation, mostly) to look at the problem from a high-level. Hence, strategy for software security was born. Now, the proverbial last mile is the logistics of how you get the job done within an organization that’s got 50,000 real-world constraints that complicate everything.

Regardless of your favorite security-enhanced SDLC method, you’ll notice that they really are, at their core, a collection of activities, procedures and artifacts (tactics). Don’t get me wrong, it’s great stuff in terms of what’s needed to do the job well and it’s generally assembled and presented in a full-blown, whole-hog, flying-car way (strategy). If you’re in the shoes of the person in charge of augmenting your company’s dev processes, you’re handed a large collection of great things to think about, but little that’s directly actionable in terms of answering ‘what do I do tomorrow?’ (logistics).

What I’m getting at is that I think we’ve gotten to the point where if you’re still debating tactics of what to do or the strategic vision of what needs done for process integration, you’re solving the wrong problem. It’s about rubber-to-the-road logistics. We need to build on the work that’s been done already and come up with plans that make it accessible and usable for an average human that hasn’t made a career on thinking about these things. That’s a serious challenge, but not an impossible one. At Cigital, that’s what our SDLC process gigs are all about (providing the company a detailed plan of how to get it done). What’s needed now is to get a more abstract way of looking at the various factors that contribute to logistical differences (e.g. type of business, market vertical, organizational hierarchy, regulatory constraints, etc.). I strongly believe that we can formalize these factors and I think that goes a long way to breaking the back of the problem. I fact, I’ve been working with folks in the OWASP community on this very problem (and would love to get anyone else with field experience involved). Much of that work will be released in a new version of CLASP in the next week or so, so stay tuned if you’re interested (I’ll post another entry here announcing it).

Technorati Tags: software security, sdlc

The process of writing security guidance is just as important to the quality of the resulting standards as is the target: technology-specific, code-centric constructive statements. How do you succeed? By using the same muscles you exercise when you conduct secure design.

When I write Security guidance, such as the technology-specific standards I blogged about last week, I start with a threat model for the system (or design paradigm) I’m trying to protect. This could be as specific as a single system or as generic as all my client’s customer-facing 3-tier J EE Apps. I aim to remove attack vectors with sets of standards. I don’t write standards that don’t directly prevent a particular attack I’ve already documented in the same way Agile Developers ignore abstraction not mandated by the current user stories. Eventually though, removing a subsequent attack vector will require a smidge of refactoring or (more likely) augmentation.

Thinking about each attack vector individually gives necessary focus to the process and will help get past hapless statements of context-free specificity. Years ago I saw, “All data must be protected with 128-bit encryption”, within a customer’s standards. Admirable though the specificity was, the limitations of this as a standard become immediately obvious. Would 128-bit encryption suffice for archival-grade needs—such as log files? What does the plain-text or cipher-text data get used for? If we’re looking at attacks on session management within our imaginary web-app, simply encrypting a session token doesn’t effectively protect against theft and replay does it? Remember last week’s entry. There, in my example, I sought to protect against the circumstance in which (due to omission or later maintenance) a Developer forgot to explicitly demand authentication prior to accessing a piece of functionality.

Think of security standards as requirements driving a design that resists the attacks you outlined in your model. This focuses authoring and often alleviates the writer’s block a blank page can impose. Improving and completing guidance becomes tractable. In my crypto example above, the client was attempting to secure exchange of data between two systems (thick Java clients) over the Internet in a circumstance in which they could not rely on SSL being present. Data from each transition persisted beyond a single session, but had a short span of value—say a day, or week (depending on the volatility present in pricing). You’re probably already conjuring ideas about what you’d expect to see in a secure implementation. With as little context as this, my explanation of the design begins to illuminate attack vectors. From these, you can begin to answer the questions I posed above about ciphers, structure of data, and from there secure design becomes an exercise in trading off difficulties of key maintenance, performance/overhead of the encryption, and others with resisting the attacks you’d enumerate.

Not shockingly, HOW you build this guidance is as important as ending up in courier font. And, (again) it shouldn’t surprise you that I’ve chosen to get end up with code (courier) through design (via threat modeling). This is how software is built—and security should be no different. This does mean you’ll need security architects (who can code—not the corporate librarian types) to write good, detailed security standards though.

Technorati Tags: software security

While speaking at a conference out west an interested attendee challenged me: “You said I should make my security standards as specific as possible, but the other speaker said, ‘Keep them general’, what gives?” This type of exchange happens all too often in the software security space these days. I could do a piece on that alone, but instead, I’ll address the challenge.

The confusion stems from two competing goals driving standards creation: 1) providing useful security know-how that benefits developers and 2) obtaining ‘coverage’ of all the security concepts, technology stacks, and development/deployment platforms your organization uses. To be useful to developers–to truly change the way they behave when “Their butt hits the seat in front of their compiler”—one has to speak their language. Developers speak and write code. Documents like security policy, tend to be written by Corporate Security, or worse: lawyers. These groups speak and write legalese. There’s a big difference and it’s easily detected: one usually comes in 12pt. Courier.

Your objective: answering questions about how to do things right for developers by showing them the right way… while leaving enough flexibility and room in the guidance for them to remain creative and solve the business problems their application was intended to.

Writing technology-specific guidance engages Security Architects in helping directly solve Developer problems. Rather than specifying “Do not allow direct access to Servlets by name” (a decent agnostic standard, when used in concert with others) show them how:
——
Using Struts, map an impossible-to-assign role, such as noaccess to every Servlet but one–a single front controller–that mediates access to your other Action Servlets like this:

 <web-resource-collection>
   <web-resource-name>Application</web-resource-name>
              <url-pattern>/functionality</url-pattern>
       </web-resource-collection>
  <auth-constraint>
   <role-name>noaccess</role-name>
  </auth-constraint>
 </security-constraint>
 <login-config>
  <auth-method>DIGEST</auth-method>
 </login-config>
 <security-role>
  <role-name>noaccess</role-name>
 </security-role>

Place all Action Servlets in a single directory, for ease of maintenance (/functionality in the example above). Demand authentication prior to access to the single front controller and delegate actions from that Servlet.
——

Alternatives may be necessary. For instance, while the standard prescribes lumping functionality in one directory–that may not be possible. For those cases, the standard should describe how extension based url-patterns can aid in casting the broadest net possible.

Standards, at this level, should always state a preference however. The worst offense of failing to do so is nearly every J2EE book’s discussion of both declarative and programmatic means of authorization without indicating which should be used when.

Next week I’ll move on and discuss detailed, technology-specific security guidance in more detail, but first I would like to recognize the value less specific guidance provides. Detailed, technology-specific guidance requires significant time and effort to produce. Such guidance is perishable and becomes useless as you upgrade or update your technology stack. Technology agnostic guidance, or guidance kept at the level of security concepts insulates you a bit more. Organizations should certainly start with this level of guidance, getting coverage over the broad array of security topics needed to educate their developers before diving down a rabbit hole and writing technology-specific guidance.

In other words, one level of guidance does not replace the other. Instead, less specific guidance serves as safety net underneath the more specific, catching inquiring minds when the specific guidance hasn’t been written yet or when it doesn’t apply (as often happens when a team faces constraints like deploying an old version of Tomcat).

I hope, however, that in the meantime I’ve shown an example of how being technology-specific, code-centric, and detailed about standards can engage security folk in development, engage Developers in their own language, and actually push projects forward more quickly by making hard security decisions for them. This is just one of the activities your Security Architects can undertake when they parachute into development teams… a concept I introduced in my blog entry on research in the 50’s.

Technorati Tags: software security

My wife recently made the comment about how it seems as though bad things come in threes. I thought it was an odd thought to see random events as coming in sets, but then again she also thinks that there are a finite number of good weather days in New England. But then I realized that there have been three occurrences that have set a course for part of my intellectual pursuits here at Cigital. These three events are completely un-related, but all evolve around the issue of security testing and how it seems like security testing should be the next technical pursuit for software test engineers.

The first event was at SD West. I went to hear Herbert (Hugh) Thompson talk about fuzzing. Hugh is a great speaker by the way and you should definitely hear his presentation about his escapades as a young teen fuzzing his high school’s soda (”pop” for all us midwesterners) machine. But, I digress… In any case, the question that came up at Hugh’s talk was whether security testing was the domain of developers or testers.

I’ve been doing some work with one of our clients about moving security testing into their testing organization. That’s the second of the three coincidences. Our client has realized that in order to implement the Software Security Touchpoints throughout their SDLC, that they need to train and empower their testing organization and not assume that the developers to write secure code. Good assumption.

The third is that Joe Jarzombek, Bob Martin and I were asked to give a talk on Software Security at the Boston Software Process Improvement Network (SPIN) and Software Quality Group for New England (SQGNE) meeting. The talk is on May 9th for anyone in the Boston area. My talk is titled “Software Security Testing - The Next Frontier”.

Does this mean security testing is a bad thing because it “comes in threes”?

I was starting to worry that it was after my wife told me about the “bad things come in threes” thing. Then, the other day one of my co-workers, Paco Hope, and I were talking. Turns out that he’d already started blogging about security testing and some of the challenges. He’s started with a couple of book reviews which provide some insight into the challenges. He and I started talking about and the relationship of Cigital’s Risk-based Security Testing methodology and other negative testing methodologies like equivalence classes. Paco’s definitely got some great ideas about how Software Security and Software testing relate.

So, there aren’t three incidents - there are actually four. Phew - because I really do believe that testing organizations are going to need to provide the security training, tools and resources to empower their test engineers. It also creates a natural, technical growth path for those engineers. Engineers progress from manual testing of features to being able to write test automation. Security testing requires even deeper technical knowledge than automation, so it’s a natural evolution to start getting underneath the constrained environment of traditional automation tools and start working on testing the security related aspects of the software.

So, Security Testing is definitely not a bad thing, since it doesn’t come in threes. Now, if I gotta start working on the weather in New England.

Technorati Tags: security testing, fuzzing

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: software security, essf, tools, services

Did you ever catch a box turtle when you were a kid? They are beautify, affable and interesting little fellows. If you see one, catching them is no problem. You just walk over and pick it up. Even though it has a razor sharp jaw, its instinct is not to bite, but to pull in it head and legs and hope for the best. In a little while, after it realized you are not some bad actor, it comes out of its shell and begins the slow, deliberate process of escape. By my experience, turtles are pretty patient. If there is a tasty bit of lettuce along the route, they are content to stop and eat if, even if you sitting a foot away. Still, when the lettuce is done, they will continue their escape AND THEY WILL SUCCEED.

Their astounding rate of success has always amazed me. Without fail, I as a child, and each of my children in their day would put a turtle down somewhere in the yard and then go about some game or chore. We would glance back at the turtle every few minutes noting its slow progress to the fence or bushes. When the turtle got close, we would haul it back to the center. Then, patiently, it would resume its long walk. We would catch them a few times, repeating the cycle, but finally we would turn around the turtle was gone.

There are two possible explanations for this. The one I would like to believe is that turtles are wonderfully canny creatures and fleet afoot, who consciously lull us into a false sense of security before they dash to the perimeter with lightning quickness. I would like to believe that because I rather like turtles and would quite enjoy the thought that they are clever as well a cute. The more likely explanation is that it is simply impossible for us to pay sufficient attention to events that unfold so slowly. Turtles almost live in an alternate universe, with a wholly different time constant.

I like writing about turtles, but this is an IT blog, so let me extend the parable to something related to computing. My discourse goes through San Francisco. San Francisco has a great rail system – Bay Area Rapid Transit or BART which is highly automated. Back in the later 1970s they had an interesting accident. BART trains are largely computer controlled, with human operators monitoring for safety. Trip after trip, day after day, year after year, the computers would sense that the train was reaching the end of the route, slow the train to a stop, and start off on the return trip. The operator would walk to the opposite end of the train to once again be at the front. The system worked very reliably, so the operator grew comfortable relying on the computer, and would start his trek through the train before it had actually come to stop. You can see where this is going – one day the train missed the end of line single and didn’t stop, and the operator, who could have saved the day, was not at the controls.

There is a common lesson in the cases of the turtle and the BART train. Human beings cannot catch rare events. We simply cannot maintain the concentration. It is bad design to build a system where the human backs up the computer. The human WILL be day dreaming when things go wrong. It is better design to keep the human active and in the loop, literally running things or at least sharing responsibility, even when the computer can probably do it better. When the human fails (and he will) the computer will be there to back him up. A human and computer together can provide system redundancy, but only if the human is at the forefront and the computer as the backup.

Clearly we shouldn’t get carried away with this principle. We don’t want an accounting system where the math is done by hand with the computer checking the addition. In design of real time systems, though, this is a very important principle. It surfaced last week in a trading system I was reviewing. The system is used for large block trading (BIG deals). In my tests I found that you can enter an asking price that makes no sense (transposed digits or a shifted decimal point, for example). As I said, these are big deals, so you have to confirm the price before the deal closes, but you confirm not by entering the price twice, but by simply clicking “confirm.” In the heat of an active trading day, the traders who are very confident individuals will certainly hit confirm automatically, without actually reading the data. Ninety-nine percent of the time, this is not a problem.

Lest you think this sort of design problem is rare, you can trace the wreck of the Exxon Valdez and the navigational error that led to the shooting down of Korean Air Lines Flight 007 over the Kamchatka Peninsula to precisely the same human factors problem – using people to back up computers, not the other way around. The key message here is that when we design and test a system, we must focus on the whole system performs people included, not just the software.

When jOHN first accused me of being Captain Technology Curmudgeon, I was a little peeved because I’ve been of the opinion that its more how to make Ajax secure and not if it can be made to be secure. How can THAT stance be curmudgeonly? It was Gary that took the stance that Ajax is to be avoided.

So, I set about writing a talk for SD West about how to write Ajax applications that aren’t insecure (I do hate double negatives, but with security one can never really state that something IS secure). I based my talk on work I’d done with our client, research from the Web and my own experience writing Ajax.

At first, things seemed pretty encouraging. Ajax seemed to heighten the existing problems on the web. For example, there was the problem of good, API design for all of the additional services and the associated need for solid input validation and output encoding (albeit encoding for XML and JSON instead of XML). This all seemed pretty tractable because there are known solutions even if those solutions may not be wide practiced yet.

I should have sensed that the party was starting to end when I ran across “dynamic script tags”. I’m not sure why they are called “dynamic script tags” and why they aren’t called “subverting the JavaScript sandbox”. Here’s the deal. Say, I want to “mashup” content from two sites. Tres Web2.0. But the XMLHTTPRequest object limits me to downloading content from a site other than the one that supplied the calling JavaScript. So, instead of doing something more secure like doing the mashup on the server, why not just use an HTML tag that isn’t restricted by the same JavaScript sandbox rules.

In my younger days, I would have said “Nice hack”. Now, I just shudder because this subversion of the JavaScript sandbox is being promulgated on the Web as a feature instead of the rude flaw that it exploits. Okay, so this is slightly curmudgeonly…

I then found a paper by Stefano Di Paola and Georgio Fedon that described an attack called Prototype Hijacking. Now, “Prototype” isn’t in reference to the popular JavaScript framework - it’s in reference to the fact that JavaScript uses prototype-based inheritance rather than class-based inheritance. Due to the dynamic nature of JavaScript, I can change the prototype for any JavaScript object. Most excellent. Let’s change the prototype of, say XMLHTTPRequest. Maybe the “Send” method?

So, securing Ajax applications is going to be harder than I thought. I’m not sure how to prevent Prototype Hijacking - well not yet at least. So, jOHN, how can THAT be curmudgeonly?

Technorati Tags: AJAX, AJAJ