IBM Application Security Insider

Cucumber Season in WebAppSec Land?

For those of you who are not aware of what the Cucumber Season is, I have included a short paragraph to get you up to speed on the subject:

"Cucumber season". The term, from Norwegian, refers to the period from sometime in early June, when Parliament and the public schools recess, until mid-August when the schools start up again and people return from their summer holidays. The name of this season comes from the observation that during this period, newspapers have little to write about - since nothing much happens - and so are forced to report on non-news, such as outsized and/or weirdly shaped vegetables such as cucumbers. By extension, the term refers to newspaper articles as well - a padded-out news item of dubious importance and inflated headline is referred to as a cucumber.

Well, I'm no Norwegian, but I can sure smell hype when I read blog posts and articles such as the one recently published over at SearchSecurity.com titled "Google, Yahoo, Microsoft vulnerable to authentication token flaw".

Being the curious guy that I am, I just had to check out this oh-so-frightening blog post, only to discover that:

Researchers at the United States Computer Emergency Readiness Team (US-CERT) have discovered a flaw in the way some Web sites handle authentication tokens. The agency issued an advisory Friday warning that some sites are transmitting authentication data, such as cookies without encrypting the entire session, even when the authentication material is initially set over an encrypted HTTP session.

Wait, wait, wait!!! let's read this again, slowly...

The agency issued an advisory Friday warning that some sites are transmitting authentication data, such as cookies without encrypting the entire session, even when the authentication material is initially set over an encrypted HTTP session.

¡Ay, Caramba! transmitting authentication data without encrypting the entire session, even when the authentication material is initially set over an encrypted HTTP session??? You don't say...

What year is this? where's my Delorean? what happened to the Flux Capacitor? is this 2007? it feels as if we're back to 1996. Next thing you know, US-CERT will publish a vulnerability about PHF.

Ok, I've had my fun, now let's get to the moral of this post - 

1. You know that it's Cucumber Season in WebAppSec land when a trivial issue such as this is published with the title "[HUGE COMPANY NAME HERE] Vulnerable to [LAME VULNERABILITY NAME HERE]"
2. I don't know what's more sad - the fact that CERT actually researched and posted this advisory, or that companies such as the ones mentioned above, still have such trivial issues in their web applications
3. It's Cucumber Season in WebAppSec land, and I didn't have anything better to talk about.

One small thing before I sign off -

if you haven't seen or heard about the WASSEC project - check it out.

A Wild Safari

An ancient African proverb goes like this:

Every morning in Africa, a gazelle wakes up.
It knows it must run faster than the fastest lion or it will be killed.
Every morning a lion wakes up.
It knows it must outrun the slowest gazelle or it will starve to death.
It doesn’t matter whether you are a lion or a gazelle.
When the sun comes up, you better start running.

Jeremiah Grossman recently commented on a curious topic which I have long thought about – if the statistics are so grim (75% of attacks are against the application, and almost 90% of applications are vulnerable), why then do we not see more incidents in the real world?

We are gazelles and yet I have never have been bitten?  What if 75% of lion attacks were on gazelles and 90% of gazelles could not run faster than lions – then what?  Would the gazelle population be reduced by 90%.  No.

I would argue that being attacked by the lion is only one consideration.  The reality is not so simple.

The Number of the Lions
It is an unavoidable truth that there are lions.  Further, I’m sure the gazelle would like to know when it wakes up how many lions happen to be crouching in the tall grass nearby.  However, the gazelle has little to no warning of an imminent attack.  The smart gazelle assumes that at all times, there is one lion stalking them.  Reality?  The gazelles continue to exist as there are far more of them and their population grows quickly.

I don't have any real good statistics on how many malicious attackers are attempting harm in the web application space, but I have to believe that the number of applications and organizations far outnumber those who would attack us.

The Number of Gazelles
True or false? The gazelle must run faster than the fastest lion.  False.  The gazelle only must outrun as many gazelles as there are lions.  If there are 20 lions and 40 gazelles, he merely needs to come in as one of the top 20 of his peers.  In this manner, his peers might also be his enemy.  If he is on the low end of the speed spectrum, it may be that he ends up as the soft target.

We all agree that there is no such thing as "secure".  Sometimes it may be enough to merely not be the one who is the least secure.  Is that a defense?  No.  But sometimes we accept rather than mitigate  risk, and we are not bitten.

Attractiveness
As a target, some gazelles might appear more attractive?  Distinguishing oneself from the herd can be a dangerous game and one that should not be lightly entered.  Collection of highly attractive data (financial information, military secrets, and valuable assets) often makes one gazelle appear plumper than its peers.  While this distinction is often unavoidable, it seems to be a certainty that the lions consider some targets as more attractive.

Do you have a choice in how attractive you are?  Sometimes yes.  Sometimes no.  It may be that the business dictates your attractiveness.  Certainly a Microsoft is more attractive than Mom and Pop's Bait and Tackle.  However, we would do well to remember one of the key tenets of the IAPP fair information practices: limiting collection.  Sometimes we could make ourselves a more attractive target by retaining more information than needed

--

I do not want to leave you with the impression that you can hide within the herd.  Playing the "wait and see" game can be dangerous.  However at the same time, I believe it spreads fear, uncertainty and doubt when we only talk about the lion.  There are gazelles that die of old age, despite the fact that they can not outrun the lions.

Can I Buy a Vowel?

As the vowels of the English alphabet (A, E, I, O, U) are integral to the English language - both written and oral; so too are certain actions for addressing security in software - both web-based and traditional.

I’m often asked by companies to help document some of the essential actions they can take while attempting to build better, and therefore more secure, software.  Let’s distill this down to five essential actions an organization can implement in order to build more secure software.

Artifact Collection

It is no mistake that artifact collection must be the first vowel in this list.  As has been succinctly stated by others, metrics matter.  You can’t be serious about improving something if you are unable to measure it.  Measurement is required for establishing a baseline, for establishing goals, for calculating improvement and for determining success.

Many organizations are quick to establish artifact collection and measurement in one area of development such as requirements or bug tracking, but forget that this equally applies to more manual processes.  This might include a process artifact such as an architectural risk analysis or a people artifact as to whether a certain developer has attended training.  Regardless of the artifact type, a central repository for the collection, measurement and monitoring of artifacts is essential to building more secure software.

Enablement

The second action to consider is enablement.  Enablement pertains to individuals and should include three core areas: education, resources and tools.

Education of development teams with respect to security has long been considered an essential element to designing, building and deploying secure software.  This education can cover basic security principles, threat classifications, threat modeling, or perhaps cover even more fundamental topics such as essential practices for good software development.  Education enablement should not be a one-time thing.  Establishing a repeatable program that allows for refresher courses, growth and maturity is valuable to developing one of your most important assets in the software development process – the developer.  Valuable progress has been made using bite-sized 15-minute web based training programs (which of course can be measured as an artifact) as an education enablement method.

Why have we entered such an era of unparalleled growth in recent years in the software industry?  I believe it is because of access to resources.  We have been enabled to grow and expand at a previously unparalleled rate due to access to online resources.  Think Google.  Why not enable the developers internally through a similar internal resource library?  By establishing items in the library such as the previously mentioned web-based training, best practices guidelines or certified components, we enable the developer to focus on what they were meant to do – develop software.  We don’t want our developers re-inventing the wheel.  Why would we ask them to re-architect a method for validating an email address?  We can enable them through access to a proven certified component which is stored in a resource library.

Enablement of people and process is also fundamentally addressed through tools.  We all recognize that tools do not build secure software in themselves, nor do they fix the technical and logical issues which they are able to find.  As an example however, they may enable the individual to understand these deficiencies and make intelligent recommendations.  They enable the developer.  By granting access to tools that are able to perform these assessments, we enable the developer to be self-sufficient, reducing time and costs in the software development process.

Incremental Security

I have seen countless security initiatives fail because the ocean simply would not boil.  How many different security threats do you suppose there are?  I don’t have a number for that.  Any given security assessment tool may have hundreds to thousands to tens of thousands of different types of checks.  It simply does not work to attempt to run tools and report on all findings.  The ocean doesn’t boil and people are frustrated.

Incremental security testing is essential for a successful security initiative.  Start with one or two high priority security issues that make sense for your organization.  Secondly, I suggest you look for two commonalities between them: a common root cause and a binary pass/fail automated test that can not be contested.  The benefit of focusing on a common root cause is that the developer does not focus on what happened, but why it happened.  For example, Mitre reports that cross-site scripting (XSS) and SQL injection were the two most commonly reported vulnerabilities in 2006.  Perhaps these are the two issues that you begin with.

Ongoing Security Testing

One of the core successes of the Agile development methodology is that it is both incremental and iterative.  This means that the software is built early and often.  This allows transparency early in the process to where the largest obstacles will occur.  Should a problem arise, a decision can quickly be made as to whether the efforts should be redirected or canceled.  Security testing is no different.  It greatly benefits from ongoing, iterative analysis.  While logical vulnerabilities should be architected out of the software during the inception and elaboration phases, technical vulnerabilities have the tendency to arise due to developer or implementation error.  Remember, security is an emergent property of the software development process.  That is, the vulnerabilities tend to emerge as the application is constructed and can continue to appear in the ongoing maintenance phase.  By performing automated ongoing or iterative security testing, the software benefits from having the technical vulnerabilities discovered and corrected as early as possible.  It is no secret that correcting issues early in the software development lifecycle represents significant savings for the organization.

Unify the Policy

I purposely want to stay away from the term “Unified Process” as I do not want to refer to a specific development framework.  Instead, this last vowel is merely the recognition that a strong unified policy should exist – which may well include a core development framework.  While every large (or small) organization practically has many methodologies or variations of a methodology for developing software, it has been recognized for some time that implementing a unified and consistent process and policy results in better quality software.  While I do not want to go on about the merits of various frameworks such as Waterfall, RUP, XP, or Spiral, it is unquestionable that some level of discipline regarding the unification of the development process is valuable.  A unified policy should include very fundamental concepts such as the defined code framework and certified components that will be used.  Usage of proven, mature frameworks drastically improves the quality of software.  This policy should also define the required feedback loops from internal, external and software sources.  Going further, this policy would define the more manual techniques that are required outside of automation.  Unification of these processes, tools and results are what establishes a more complete and unified policy.

--

Regardless of the actions taken in implementing a strategic software security strategy, or the discussion about what the priority should be, it remains infinitely clear that “something” has to be done.  The statistics are against us.  Perhaps these five action vowels don’t seem to map to your organization.  I won’t argue.  It is sufficient that we open the dialog about these actions.  Me?  The five vowels are easy to remember and I’ve seen these simple steps bring success: Artifact collection, Enablement, Incremental security, Ongoing security testing and a Unifying the policy.