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

“We have long had death and taxes as the two standards of inevitability. But there are those who believe that death is the preferable of the two. ‘At least,’ as one man said, ‘there’s one advantage about death; it doesn’t get worse every time Congress meets.’”

~Erwin N. Griswold

Just look at them grow… they’re like weeds. Unfortunately, in this case it’s not a compliment for your sibling’s kids. This particular growth is in the data breach lists at Privacy Rights Clearinghouse, Attrition, PogoWasRight, and others. (And please accept my thanks for the time you all put into this public service; I apologize for not including you all by name.)

I have no doubt these disclosures represent the tip of the proverbial iceberg of data that have actually left the control of those to which it has been entrusted. I also have no doubt that we’ve been given this glimpse into the shoddy treatment afforded many of our most intimate personal details solely through some forward-looking state legislation (thanks, California, for helping to start a good thing in the U.S.).

Let’s just jump ahead of all this piecemeal personal information loss for a minute. (Did the WABAC machine have a “forward” lever?) Let’s declare it not only inevitable, but also unavoidable, that, for each and every adult American, their name, social security number, top one or two credit card numbers, street address, date of birth, brief genealogy, and a few other interesting data items are known, collated, and cross-referenced.

But, not by legitimate companies like Experian, TRW, and Equifax. Let’s assume that individuals and groups who do not have our best interests at heart have all of these bits of information correctly assembled into mini-virtual-self-referentially-consistent identities, even if they have no “real life” information on the actual person (e.g., photo, current job, salary, type of vehicle, where your kids go to school, etc.). And, let’s assume they have the ability to keep this information current enough to meet their goals of acceptable cash flow for acceptable risk.

[Aside: Is this feasible? How many databases would I have to subvert in order to get most of this information? One at the IRS, one at a credit agency, one each at a few major banks, and maybe a few others? Remember, I don’t actually have to hack in, I can use social engineering, pay someone, coerce someone, steal the back-up tapes, and so on, and on, and on.]

What then? Is it the collapse of American civilization? I doubt it, but I think it would certainly accelerate some good things and some bad things.

The good things might include something like two-factor credit card use at all times (e.g., you have to show a [new government issue?] driver’s license for all card present credit/debit card transactions). But, what would have to change to allow card-not-present credit card transactions to continue to happen (e.g., most Internet orders, catalog phone orders, Chinese food orders, etc.)? What would it take for Americans to embrace single-use credit card numbers, for example? What parts of the infrastructure would have to change? How would we get and carry around these numbers? And so on.

The bad things might include a new state or national ID that would be required by the credit card companies in order to get a “secure” (whatever that would mean) credit card and a lot of high-end establishments that would start accepting only “VMCAMEXD Secure” for transactions over certain dollar limits or that meet certain risk profiles (e.g., buying for delivery to another country). A treaty with foreign countries could require that “secure” credit cards are the only ones accepted in some situations (e.g., buying a one-way plane ticket to the U.S.).

Beyond that, what would have to change at the IRS now that all SSNs are “public”? What about elsewhere in the Federal government? What would this mean to the Privacy Act? And so on. The mind reels, but it still feels like a good thought exercise.

For me, the question is not “What happens if someone else knows all the data associated with me?” The question is “What financially and socially acceptable capability will make it such that I can unequivocally prove that I’m the only me that goes along with my (now public) mini-identity data (e.g., credit card numbers, social security number, address, genealogy, etc.)?” And, in terms of requirements creep, I’d also like to be able to prove it without giving away my actual identity.

Thoughts? I hate to take you this far and not have something to offer, but I feel qualified only in asking the question, not in postulating an answer. And, of course, my follow-up question is “How are we going to make that software better than the software we have now?”

Technorati Tags: data security, privacy

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

One of the commonly proposed remedies for SQL Injection is to use SQL stored procedures. Use of stored procedures can greatly reduce the likelihood that you’ll code an SQL injection, but it’s not the stored procedure-ness that’s saving you. Stored procedures let you use Static-SQL instead of forcing you to always use Dynamic-SQL. In Static-SQL the metadata for the query is known at compile-time whereas in Dynamic-SQL the program constructs the query at runtime. Dynamic-SQL is injectable; Static-SQL is not.

For most programs, Static-SQL is sufficient. Only a small subset of features such as user driven filtering interfaces need Dynamic-SQL’s flexibility. Unfortunately, the common database access protocols, ODBC and JDBC, are based on Dynamic-SQL and there’s no provision in the interface for static queries. It’s into this void that SQL stored procedures stepped in.

But SQL stored procedures aren’t limited to Static-SQL. It’s possible to use Dynamic-SQL through the PREPARE, EXECUTE and EXECUTE IMMEDIATE statements (these are the ANSI SQL-92 statement names, your RDBMS have different names). In fact, ODBC and JDBC are just wrappers that ship the SQL text from your program to the database server and make calls to the RDBMS through the runtime support for these Dynamic-SQL statements (actually). So, stored procedures that execute Dynamic-SQL statements are equally vulnerable to SQL injection. It doesn’t matter if it’s Java code concatenating strings and passing them to JDBC or if the strings are concatenated in PL/SQL. Both are equally vulnerable.

By now you’re probably wondering why I’m splitting this hair. I’m splitting it because I want to ensure that we protect ourselves from the programmer we’ve not yet met. It’s the programmer that goes and dutifully reads our coding guideline that says “Use SQL stored procedures to prevent SQL Injection” and now has to extend our application with the feature that introduces Dynamic-SQL. But, because we haven’t properly articulated the guidance, s/he creates an SQL injection vulnerability.

Implementing your queries using Static-SQL will go a long way to protect your application from SQL Injection. It’s also possible to simulate Static-SQL using ODBC/JDBC type interfaces with the religious use of SQL parameter markers. This leaves the use of Dynamic-SQL only for truly dynamic queries like the dynamic user-defined filter I mentioned above. There’s a pattern for securely implementing such a filter that’s floating around in my head. I need to write that down, but you’ll have to wait until next month. Sorry.

Technorati Tags: sql, defects, flaws

Cigital is in the business of making software secure, often by telling our clients precisely how and why their software is not secure. There are an almost infinite number of ways to be vulnerable so it should be no surprise that we rarely find the perfect system. I’m tempted to say never, but I’d have to check around on that. We have a saying in the office that the only truly secure system is one that is buried underground with no wires in or out and no users.

Some of our clients, though, are shocked and more than a little annoyed when our assessment is critical. A top level manager may express gratitude when we confirm his gut feeling, but the middle manager with direct responsibility for the system is often embarrassed and defensive, and the guys in the trenches are downright pissed. That’s too bad. We aren’t top level managers. We are trench warriors ourselves. We truly appreciate how very difficult it is to write excellent code—code that does what it is supposed to do, code that works fast, code that works reliably in a production environment, code that is maintainable and code that is secure.

I once lead a development team that produced some code that managed some highly visible and regulated financial transactions. The code had to be 100% free of errors as there were many critics with deep pockets, political connections, and dozens of lawyers who wanted it to fail. The client wisely hired an independent (end excellent) team to perform extensive IV&V at the test level and the code level. The team showed up in my office where I gave them all the documentation, all of the test results and test code, and unfettered access to my pre-production staging area. I figured they were just code shmoes like me, just doing their job, so I tried to be nice. Their attitude though was that of an IRS auditor on the trail of a bootlegger. One day I walked in and gave them a couple of boxes of Girl Scout cookies from my troop (Thin Mints, I believe). They turned down the cookies and told me that it was completely inappropriate of me to offer them anything of that sort. I lost it. I screamed “They’re not bribes, they’re goddamned cookies. Eat the ——- cookies!” They were so shocked they all instantly grabbed one and ate it very quickly. It was hilarious, and we eventually had a laugh over it.

At Cigital we don’t want to be like those fellows. We love smart coders—they are our kind of guys. Let the guys in sales play golf with the bosses. We would rather drink beer (or Mountain Dew) with the folks on the midnight pizza shift. At root though, we do review other peoples’ work, and sometimes the auditor mentality takes over. One of the best guys at Cigital recently took on an audit gig. He told his manager that he wanted to keep the report secret until the end of the project, so he could produce a bug-rich audit report. I suppose the idea was to show how smart he is and we are. His sage manager told him to cut it out and share the findings as they emerged. The result was that we produced a long bug list, but noted in the final report that almost everything had already been addressed. That’s a good outcome for our client and a good one for us—we got another gig.

Writing good code is real hard, and the smart guys who do it are the heroes of our business. We love you guys, but we sometimes do have tell your that your baby is ugly and we’ll go beyond that to describe every deformity, wart and blemish in lurid detail. Understand, though, that we, like you, want that ugly baby to grown up into a runway model.

Technorati Tags: governance, regulation, software security

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

Recently, someone at Cigital asked me to characterize the difference between our approach to software security and Microsoft’s. Before I get to comparing things I want to note that we’re big fans of Microsoft when it comes to software security. Under the leadership of Michael Howard and Steve Lipner, Microsoft has made great progress in software security over the last few years. There are many lessons that we can all learn from what they’re doing.

That said, Microsoft’s approach to software security does differ from ours in a few fundamental ways that are worth discussing.

The biggest difference to highlight is that their approach has a static threat model that is great for operating system vendors. People in other sectors such as finance or hospitality will not have the same kind of threats that Microsoft does. In this case, what I mean by threat is an actor or agent who causes risk. That is, your possible attacker(s). Building a threat model that is tailored for a customer is a key aspect of our approach at Cigital. Microsoft has already done this for their business, but chances are you are not an operating system vendor.

At the heart of Cigital’s approach to software security are a number of best practices that we call the touchpoints. You can read about the touchpoints in my book Software Security. The top two touchpoints are “Architectural Risk Analysis” which helps uncover and mitigate flaws at the design and architecture level, and “Code Review with a Static Analysis Tool” which helps ferret out bugs in code at the implementation level.

Our approach to Architectural Risk Analysis is much better suited to finding new risks not yet ever seen before than Microsoft’s list-based approach. Undiscovered new risks are the kinds of things that lead to 0days and help you to wind up on the front page of the Wall Street Journal. Our three-phase analysis goes way past Microsoft’s STRIDE model with regard to dependencies and ambiguities. Our approach to risk is much more sophisticated and grounded in business as well. The reasons for this probably have to do with having to demonstrate to our customers the importance of the things we’re finding. By contrast, Microsoft doesn’t need to be convinced to fix security problems, Bill Gates already said that they have to.

When it comes to code review, Microsoft and Cigital approaches are similar, but Microsoft leverages proprietary unreleased tools that are not available outside of Microsoft. (Many of you will have heard of Prefix…Prefast, now available with some Microsoft compilers, is not the same thing.) The Cigital approach leverages customizable commercial tools and a best of breed approach. We often use Fortify’s supremely good static analysis tool, but we have been known to wield Coverity’s tool and Klokwork’s tool as well, depending on the situation. In both cases, however, the use of a static analysis tool to find bugs is absolutely critical.

Our approach to security testing is much more white box than Microsoft’s is, and involves using the risks uncovered during Architectural Risk Analysis to drive inside-out test planning. Microsoft’s approach is grammar driven and focused on APIs. The fact that James Whittaker now works for Microsoft is likely to help to evolve Microsoft’s approach to security testing, but James has a tendency to start with API fault injection as well (see his great book How to Break Software Security).

As far as I know, Microsoft does next to nothing at the requirements level. At Cigital, we have a decent approach to security requirements that covers both functional security mechanisms and abuse cases.

There are many other differences between our approaches, but those are the highlights. The most interesting thing is just how closely aligned the two approaches are.

Technorati Tags: software security, microsoft, stride, sdl

I was a young Air Force lieutenant when Ken Thompson released his 1984 piece, Reflections on Trusting Trust. Assigned to a data center in the Pentagon, I was working on the B2 evaluation of Honeywell Multics with the fine folks at the National Computer Security Center and contributing some words to the growing Rainbow Series books. We were in ongoing debates over the meaning of phrases such as “top-level specification” and “on behalf of” in the Orange Book (a mail thread that went on for several years) and trying to perpetuate the wave of talking about “trusted computers” instead of “secure computers.”

We talked a lot about “how much trust do I get for how much analysis and testing” and “how much trust do I need for certain scenarios, like allowing a computer to automatically downgrade data from Top Secret to Secret.” These kinds of concepts ended up in capability maturity models, testing models, and risk models.

I took Ken’s words to heart and quickly made up my mind that we could really only move the trust bar up slightly (like from 10% to 20%), even with enormous expense. It was immediately obvious that getting up to, say, 75% would require so much calendar time that no one would wait for the result (and I think later experience with Orange Book evaluations, Common Criteria evaluations, and related programs have borne this out). Between hardware, software, firmware—and the completely unpredictable human factors—we really had no idea how even the most reviewed code would operate in relatively controlled environments (e.g., in a government facility where everyone was cleared), much less how it would operate in a hostile environment (hostile mobile code was not really a problem yet) where people might actively be up to nefarious deeds.

Why should you care about my reminiscing? Well, because I think a flavor of trust is still a major problem today and it’s costing everyone a bunch of money that could be put into real long-term solutions.

As I talk with my operations friends these days, I’m seeing a subtle shift in their thinking. They’re thinking more and more about appliances (web application firewalls, IDS and stuff like that), but not for direct security value. They seem to be thinking that since the software they install, whether purchased or built internally, will certainly have security problems, they have to install more bells and whistles so that operations can protect itself. This is beyond healthy paranoia; it’s an unhealthy distrust of people who should be active partners, even if it’s been earned by years of spectacular failures.

Then I started wondering why so many development organizations throw out requirements documents from product managers and just start over. Is it only because the requirements are so bad, or is it also because the developers just don’t trust the managers to know what they’re talking about?

And why do so many managers try to tell development organization how to create applications, instead of simply what the creation must accomplish? Do they simply not trust the developers to be aware of business objectives, or do they just not understand the creative processes involved?

And so on.

What an enormous amount of wasted cycles that could be used to greater organizational good.

We may never get to the point where we can implicitly trust software. But, can’t we at get to the point where we can trust each other?

Technorati Tags: software security, software quality