I realize this might shock our fair readers, but once upon a time I used to get my hands dirty with a little hands on web application development. Back in the heady early days of the mid-1990’s Internet I accidentally transitioned from a systems and network administrator to a web application developer and DBA at the University of Colorado’s Graduate School of Business. It all started when I made the mistake of making an incredibly ugly home page for the school, complete with a tiled background of my Photoslop-embossed version of the CU logo (but, thankfully, no BLINK tag). The University took note, and I slowly migrated out of keeping the network running into developing database driven web applications for a few thousand users. Eventually I ran my own department before setting off into the big bad world of private consulting. To this day I’m still proud of our online education tools that could totally kick Blackboard’s ass, but I think I developed my last application around 2001.

I’ll be the first to admit that my skills are beyond stale, and the tools and techniques now available to web application developers are simply astounding. When I first started out in Boulder, Colorado I’d say the majority of web site developers I met were more focused on graphics skills than database design and proper user authentication. Today’s web application developers need a background in everything from structured programming, to application design, to a working knowledge of multiple frameworks and programming languages.

Current web applications exist in an environment that is markedly different from the early days of businesses entering the Internet. They’ve become essential business tools interconnecting organizations in ways never anticipated when the first web browsers were designed. These changes have occurred so rapidly that, in many ways, we’ve failed to adapt our operational processes to meet current needs. This is especially apparent with web application security, where although most organizations have some security controls in place, few organizations have a comprehensive web application security program. This is a concern for two reasons. First, the lack of a complete program materially increases the chance of failure resulting in a loss-bearing security breach. Second, the lack of a coordinated program is likely to increase overall costs- not just losses from a breach, but the long term costs of maintaining an adequate security level (adequate being defined as meeting all compliance obligations and reducing losses to an acceptable level).

This series of posts will show you how to build a pragmatic web application security program that constrains costs while still providing effective security. Rather than digging into the specific details of any particular technology, we’ll show you all the basic pieces and how to put them together. We’ll start with some background on how web applications are different than traditional enterprise applications or commercial off-the-shelf products. We’ll provide basic business justifications for investments in web application security you can use to gain management support (although we’ll be covering these in more depth in future research). The bulk of this series will then focus of the particular security needs of web applications, before delving into details on the major security components and how to pull them together into a complete program.

Eventually we plan on releasing this as a white paper, and we already have one sponsor lined up (sponsors can redistribute the content and are acknowledged in the paper, but have no influence on content- it’s just an advertising spot within the larger paper). As with all of our research we rely on you, our readers, to keep us honest and accurate as we develop the research. Technically all analysts do that, but we actually admit it and prefer to engage you directly out in the open- so please comment away as we post.

Since I’ve already wasted a ton of space setting up the series, today we’ll just cover the web application security problem. Our next post will provide business justifications for investing in a web application security program, and guidance on building a structured program.

The Web Application Security Problem

Enterprise web applications evolved in such a way that they’ve created a bit of a conundrum for security. Although we’ve always been aware of them, we initially treated them as low-risk endeavors almost fully under the control of the developers creating them. But before we knew it, they transitioned from experimental programs to critical business applications. Ask any web application developer and they can tell you the story of their small internal project that became an essential business application once they made the mistake of showing it off to a business unit or the outside world.

We can break this general evolution down into some key trends creating the current security situation:

Before web applications, few businesses exposed their internal transactional systems to the outside world. Even those businesses which did expose systems to business partners on a restricted basis rarely exposed them directly to customers.
Web applications grew organically- starting from informational websites that were little more than online catalogs, through basic services, to robust online applications connected to back end systems.
In many cases, this transition was the classic “frog in a frying pan” problem. Drop a frog into a hot frying pan, and it will hop right out. Slowly increase the heat, and it will fry to death without noticing or trying to escape. Our applications developed slowly over time, with increased functionality, leading to increased reliance, often without the oversight they might have gotten had they been scoped as massive projects from the beginning.
Web application protocols were designed to be lightweight and flexible, and lacked privacy, integrity, and security checks.
Web application development tools and techniques evolve rapidly, but we still rely on massive amounts of legacy code. Both internal and external systems, once deployed, are nearly impossible to simply shut down and migrate to new systems.
Web application threats evolve as quickly as our applications, and apply to everything we’ve done in the past. We’re constantly discovering entirely new classes of vulnerabilities that we didn’t anticipate before. The web itself was never designed to securely run mission critical applications, so we are building on a platform that was never intended to support its current uses.
Few web applications are designed securely from the ground up, nor are they maintained with processes designed to keep them secure over time.
When security breaches do occur, they can be difficult to detect or measure.

Considering all these factors, web application security is typically underfunded in most organizations. And like all application development, web applications are subject to time pressures and deadlines that result in deployment tradeoffs and compromised functionality to meet business objectives. We like to define the web application security problem as:

Few web applications were designed to be secure.
They evolved to connect our most sensitive back end systems to an open, public network with no inherent security controls.
The web is not designed to be a secure platform.
Only a small percentage of security breaches are detected or noisy enough to result in measurable losses or gain management attention.
We have a large volume of old application code to fix, but are constantly writing new code.
Web applications are a complex mixture of platforms, tools and services from multiple providers, each with a different set of security challenges.
Many web applications are mission critical, but not always by design.
Due to the design of the web, even internal web applications are external applications.
Web applications are custom applications; we are the vendors, and no one else will provide security fixes.
Web application projects are funded to offer more services, easier, faster, and cheaper than before, while security tends to limit these benefits.
No single web application security tool provides effective security on its own.

To update an old analogy; we are trying to secure a fighter jet we’re building in the middle of combat with constantly changing functional requirements, parts, fuel, and laws of physics while facing an army of millions of almost-infinitely diverse anonymous attackers.

In a future post we’ll dig a little deeper into how web applications are different than our legacy enterprise applications, and how that affects security. But first we’ll provide some basic business justifications you can take to management to build a web application security program.

As always, we look forward to your comments…