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

I was part of a panel at a university recently speaking to prospective computer science students. The panel members were from industry — a few of the biggest companies and few smaller ones. We each had ten minutes to speak before QA, so I stripped my talk down to two simple points. The first point was that IT is fun. We truly build amazing things. I’ve been in the business 35 years, and I have never been bored. Each day offers a new challenge. The other point was that there will be plenty of jobs for decades to come just trying to get things right. Software sucks. No product on the market has more defects than software and no projects have a failure rate close to that of IT development work.

The next generation can live off the argument that they can certainly do better than the fogies doing the work now. The challenge for them, as it was for us we made the same claim, is living up to the bold promises. I have been through five distinct new approaches to building software, each designed to deliver better products and better delivery management. Each has moved the ball forward a bit, but we still have a LONG way to go.

Just how bad are we? There are many studies of failure in IT, but the results are all over the place. The most optimistic estimate I can find says that about 30% of projects fail. When I mention that number, a fair number of people tell me it is too low, but let’s grant ourselves the benefit of the doubt. We fail 30% of the time.

How does that compare to other industries? Before we take on the masters of quality lets start with an easier opponent – how about used car salesmen? Every year in United States, about 45 million used cars are sold. The Feds estimate that the odometers of about 450,000 of these have been tampered with, and that in another 500,000 cases the seller fails to disclose a serious known defect. That works out to a failure rate around 2%.

We in the IT business are 15 times worse than used-car salesmen. Yet, the demand for our products and services is tremendous. IT related professions dominate the top-20 positions on the US Department of Labor’s list of high-growth jobs. Why is this so, if our products are so bad?

The answer is that software, bugs and all, delivers real value. We would love our programs to work without error, to never crash, to never need patching, but even with these sorts of problems, software does amazing things. Once in awhile we all encounter a program that makes us go wow. Remember the first time you used online mapping? That was a wow, but we quickly get bored. The amazing becomes commonplace — part of the wallpaper. That’s sad. I wish it was possible to flip a switch, and show ourselves and the world juts how far we’ve come. It would be a cruder, poorer, and much more boring world without us.

That said, software is still crap – amazing crap so customers will continue buying, but crap nonetheless and we owe them better. The challenge of making software better is a difficult one. All of the Justice League blog entries are, at root, about this one subject. Sometimes we write about broad issues other times about the very specific, but our objective is always to make software better. Better functionality, more reliable, and more secure.

This blog, rather than being about solutions, is about the intriguing, challenging, and sometimes frustrating dichotomy of software, it is both amazing, with a capacity to dazzle and inspire while it is also mundane – just a bit of bug ridden code. The Roman God Janus has two faces – one facing forward, one backward.

Building software is much the same. We constantly envision the future and it drives us to imagine and to realize that imagination we build ever more complicated systems. There is the rub. The other face of Janus looks back to the past. In IT that is the hard job of not making the software, but making it good. Janus was the god of doorways, a wonderful image for IT. The doorway to the future in IT rests on equal measure on vision and quality, looking forward to what can be done and backwards at what we have. We must aspire to be Janus.

A final observation that will set the stage for a future blog entry. Our troubles lie in the imbalance between the forward looking face and the backward. There is so much potential in software that we are constantly reaching farther; farther in some cases than we can deliver. It is the reaching that gets us unto trouble, but it also the reaching that keeps us energized and fresh, and once in while makes our customers say “Wow.”

While reading last week’s Economist, I stumbled on an article on Innovation (available without a subscription online). The article discussed how commercial entities have changed the way they fund R&D. They’ve fundamentally changed the structure of research and development groups–as well as their interaction. I began my Cigital career in the company’s research division and later moved into a purely operational role as “Consultant.” “Principal,” my current role, demands artful compromise between the two, so the article immediately caught my attention.

When a client asked about “Getting in front of AJAX from a security perspective…” this week, I connected dots between organizations’ need to innovate and the realities development require.

The big change: Big research labs (such as PARC, Bell Labs, IBM’s labs) have become extinct and hoping for “tech transfer” after stand-alone research investment represents a fatal chasm between “Research” and “Development” unlikely to be crossed… or improperly exploited even when crossed.

I see an analog for this in today’s software shops, especially pursuant of security. Right now, organizations don’t understand software security well enough to treat it as development. For them, it’s still research. While not science, in its strict sense, people don’t know much about software security. They’ll have to read, think, experiment, and be very creative before moving into a engineering/development mode.

That’s why my client said, “We want to get in front of AJAX…”; he, his organization’s software security guardian, sees a problem development can’t solve, and he doesn’t yet have the answers either. He needs a leap or two forward before he can communicate solutions to hard problems well enough to empower development to “build security in.” These problems include personal data protection, authentication, and even the very process by which his organization creates software. That’s probably why he called Cigital.

My client faces a common situation. Organizations drive their businesses, for the most part, reactively. Product companies react to customer needs (features, deadlines) and IT shops react to opportunities and risk the businesses they support face. Unless driven by compliance, publicized incident, or a similarly dramatic driver, these businesses’ development teams don’t react to software security’. As a result, development doesn’t possess engineering skill and experience in software security.

What to do about it: Organizations depending on innovation must 1) foster practical engineering (development) behaviors in those individuals with the horsepower for research and 2) embed them in development teams towards a practical end.

First, get qualified individuals. But, I’m not referring to wild-haired mathematicians. You probably already employ some of what you need in your org. I’m talking about your gifted individuals that attend conferences, avidly consume literature, and possess an advanced degree in computer science (or similar). These individuals frame the problem, hypothesize a solution, observe, then iterate.

This person probably has an uncanny knack for coming up with lateral approaches to your design problems. They may be a complainer–ineffectively shackled by their current position. A former mentor to me used to comment, “You seem to always have ‘just read something’ useful in every meeting I bring you to.” That’s what you’re looking for.

I like to focus on “Security Architecture,” so I look for these types in the Enterprise Architecture group (though, the do-nothing librarian type need not apply). Specifically, you don’t want someone that ONLY reads, or with no (or outdated) hands-on technology experience. We’ll call these people your innovators.

Second, embed these people IN development teams. Preferably, innovators should be ‘leased’ to the team solving the difficult problem: securing credit card data without increasing its (representational) size unduly, for instance.

As part of a development team, innovators should be held to a schedule and budget, like everyone else. I like the idea of managing them to a final delivery a release or two out, but with important constructive deadlines within the current release, showing progress. Managing these interim deadlines between “Hail Mary checkpoint” and “incremental main-line progress” depends on how ambitious the overall goal is.

I argue that organizations lose when they fund research with development project money directly or comp. (bonus) innovators with project metrics directly. Having these individuals report to someone else (shared services?) will allow them to focus on their technology goals. If their manager sits as a peer to those managing development, tough conflicts regarding project schedule and security program priority can be resolved reasonably.

However, that’s not to say that the development team shouldn’t participate in cost though a “tax.” After all, they do benefit from the extra horsepower applied to their project. Likewise, the researcher should be evaluated, in part, based on development project impact.

This approach naturally lends itself to a consulting model. You can hire someone or use your own internal team (which one of our clients does particularly effectively). First, make sure they’re qualified: exploiting code can be pretty easy and some consultants give bad advice generalizing quickly from something they’ve seen once. The “use POST not GET” advice OWASP gives serves me consistently as an example. I’ll cover this example and poor advice in a later post.

Beware the “’sploits-and-splash” failure mode. Embedded security resources must be constructive. Simply pointing out how not to do things doesn’t produce secure code faster and disenfranchises developers. Advice about how to pay and measure these individuals applies here. Instead, focus innovators on the tough design problem it will likely take two-to-three releases to iron out, and that might be useful on a whole class of products within a line of business. Make them responsible for producing a solution; not just pointing out problems in every product team’s smaller attempt at one.

Cigital believes in research, in the true sense of the word. We talk about the value a lab provides in each of our strategy meetings. We believe in practically applying more theoretical solutions in a consulting model as well. I believe injecting a research mentality, as a ‘thread’, into development serves as counter-weight to reactive mentality, helps solve software security problems, and gives the necessary horsepower boost to “build security in.”

I think you’ll find that architectural flaws your organization’s software exhibit require solutions “bigger than a single release” and set the stage for this topic nicely. The alternative? Fall prey to a purely engineering mentality making small incremental improvements that remove a single attack vector but leave the endemic flaw at large. This causes continual development churn and leaves the software exposed, ultimately.

Technorati Tags: ajax, software security, enterprise software security

Sure, you can’t throw out all your existing code and start over, but you also can’t hide it forever. It wouldn’t surprise me even a little bit to find that your super-slick, Ajax-improved front-end that’s written in the latest Java is actually using a JNI call to kick off some C code that no one knew how to rewrite because it’s calling some COBOL that no one has looked at since before Y2K that may actually rely on some Fortran 77 for a particularly complex calculation. And, of course, your authorization and entitlement database is on some Unix-clone variant on, say, an old IBM mainframe somewhere that talks some weird protocol that only one guy understands (and he’s about to get a gold watch in his stocking). In addition, did I mention that imminent end-of-life notice about both the hardware and the software you’re running on that box in the corner that no one touches (the one that spits out quarterly financials).

If you’re waiting for the one and only security answer to appear before you start making improvements in this installed base, you should probably polish up the old resume. You’re going to be selling yourself before you’re able to sell that wait-and-see strategy. To put an even finer point on it, even if the perfect security solution came along today, it would probably still take you years to get it in place because you’re not set up for success (because you’ve been waiting for the perfect drop-in software security solution).

Software security isn’t going to happen that way. No one knows the one-size-fits-all answer yet, or even if there can be one. But we sure have a pretty good handle on how “…chance favors only the prepared mind” (with apologies to Mr. Pasteur). Even if you can do only a few things, get started.

Institute some governance. If your executive group has application and software security on their radar, then it’s much more likely to get in the budget.

Know your business. You cannot make informed and wise security decisions if you don’t know what you’re trying to accomplish.

Document your software development lifecycle. If you can describe and demonstrate your process, then your process can be improved when the time comes.

Give skill-appropriate awareness training. If your product managers, architects, business analysts, developers, and testers develop a sensitivity to the security issues associated with what they’re working on right now, it will get better. And the next thing will be better still.

Go start now.

Technorati Tags: software security

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!)

I 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: software security, badness-ometer

Because Cigital spends time helping clients document “technology-specific” security standards, to aid developers and architects, I get asked, “What do you think about [new technology XXXX]” alot. Questions regarding AJAX have crossed the threshold, so I’ll post what I think here.

Quick disclaimer: I make no comment about the technologies or security in a Web 2.0 world (I’ll leave that to Captain Technology Curmudgeon, Scott).

The world still wrestles with how to best use AJAX, so a lot remains in flux. But, I believe if you’ve got teams prototyping its use, you’ll need to consider the following:

1) Picking an AJAX toolkit - There’s a quite a few out there and each covers different ground. What’s more, people are plugging in their own approaches to things (like password management) into toolkits and riding the wave.

People always used to ask, “Websphere or Weblogic?”. I’m no product’s salesman. Usually each possesses strong advantages and disadvantages. I wanted organizations to understand tradeoffs and make an informed decision themselves. One group heard me out, took a look at price, and picked Weblogic. Their rushed decision forced them to need _me_ to implement clustering robust enough to handle the scale they desired; Plain shortsighted.

Just like your choice of containers in the Enterprise Java world, your choice of AJAX toolkits provides much of the backdrop for your software development efforts. Because the toolkit handles a lot of client-server plumbing, the security posture of your application will depend on the toolkit’s implementation. Do not make this choice lightly. Consider elements of security along-side supportability, usability, and the other decision factors.

You need to technically vet the toolkit. As I said in the case of containers, this toolkit will act as a security “table cloth” that could be pulled out from under ALL the applications you implement on top of it. Have your security group leverage any existing threat models it’s constructed for n-tier applications so that they’re not starting their analysis from scratch.

My next entry will indicate what “development scenarios” one should put each toolkit through the paces on in order to help their development teams be productive.

Moral: Spend enough time prototyping with candidate toolkits to make an informed decision about “best for you” and the realities of integration.

2) Exploring Toolkit Architecture - A natural ‘next step’ after #1, perhaps the later stage of a thorough technical assessment into a particular toolkit. Any time you move to a new technology, you need to “get smart”. Most people skip this step unfortunately. An architecture team can save security guys a lot of time by steeping themselves in a technology, writing a primer, and distributing it to developers.

When financial companies started writing their back-ends in Java, they all fell down on String processing. They just weren’t prepared for how differently (and expensively) this ‘new’ technology manipulated strings. I spent a lot of time with development teams showing them, on a whiteboard, how XML-processing affected Java’ memory management–and how to ‘game’ it. You want to “fight these battles” once, centrally, and then share the battle scars before they occur again.

In AJAX, we’re finding toolkits handle different segments of requests client-side and impose differing amounts of requests on client-server interaction. Find out how your candidate toolkits handle requests and which side of the client-server divide weight for those factors affecting security fall. WRITE THIS DOWN. Get an adoption and user’s guide out to your earlier adopter teams. Have them write version 1.1 of the document.

Moral: Share institutional knowledge gained by vetting toolkits.

3) Don’t leave real design time with short-shift to ‘buzzword’ architecture - Selection of a platform, framework, or toolkit (perhaps all three) does not constitute an architecture. Patterns, messaging protocols, threading/event models, state machines, and similar high-brow concepts constitute the language of Design. Design should address both the structure and behavior of a system. Toolkits may help address design concerns and certainly impact design–but they do not themselves constitute the design.

During an architectural analysis of a 1.0 –> 2.0 product transition, the chief architect said, “Well, we’re just going to use struts on top of tomcat, the end. Oh, for authentication we’re using Acegi.” After extended silence I asked, “In terms of how many factors does the authentication decision get made and how will you represent those factors in Acegi and elsewhere?” The answer to these questions plagued their development team for over a month. As it turns out, they couldn’t just ‘outsource’ authorization design to the fine members of the Acegi framework.

“Buzzword” architecture produces no better a result when AJAX makes the list. You still have decide what’s asynchronous and what you’ll make more persistent connections to resolve. The matter of dividing model, view, and controller (especially the last: controller) between components and tiers becomes more difficult. With a distributed application controller, application state transition becomes sticky.

Moral: Don’t let enterprise or application architects off the hook for design because they say [Technology: AJAX] will handle it. Make them specify real design; it’s their job.

More news @ 11…

-jOHN

Technorati Tags: software security, ajax