Friday, April 17, 2009

Software Security grew to nearly 500M in 2008

Separate from an economy in recession I’m excited to be a part of market with a healthy, if not impressive, growth clip. Gary McGraw (Cigital) published his Software Security annual revenue numbers for 2008. By combining software security tools, Software-as-a-Service providers, and professional services it comes really close to a half billion dollars. This means a lot to us vendors, their investors, and would be acquires -- for average enterprise, feel free to ignore. Instead focus on the particular solutions you need rather than basing vendor selection on prevailing winds. To do otherwise is similar to buying a house locally based upon national real estate averages.

2008 showed scanning tool (black and white box) sales as continuing to climb, but the heavily fragmented pen-testing side are those who are pulling in the lions share of the cash. This is to be expected if I was right about the general market migration mirroring that of network security. Time will tell. However, there was some analysis where I had to take issue with some of Gary’s conclusions, to which I’m hopeful he’ll set me straight.

"In 2007, the white box code review companies’ combined revenue eclipsed the black box Web app testing tool vendors’ combined revenue. As Figure 2 above shows, this trend continues in 2008. I think this is a very healthy development, demonstrating that the market is becoming ever more interested in solving software security issues and not simply diagnosing them."

Not so fast! Is that really fair to assume? By the same logic could we also conclude that McDonalds offers better meat than Morton’s (a popular steakhouse) because of the volume sold. Or, is that equally unfair? Here's another bit that doesn't feel right and deserves context...

"I am aware of 35 large-scale software security initiatives currently underway."

Certainly there are more than 35 deployed Web Application Firewalls in the world (or even in the U.S), but we wouldn’t automatically conclude that organizations are happier to band-aid the software (in)-security problem than fix it at the source.

When it’s all said and done, I like numbers. Publish what we have, good or bad, analyze them and improve overtime.

Website threats and their capabilities

Vulnerabilities don’t exploit themselves. Someone or something (“threat”) uses an attack vector ( to exploit a vulnerability in an asset, bypassing a control, and causes a technical or business impact. A diagram found in OWASP Catalyst (pg. 28) illustrates the concept exceptionally well. This is important to keep in mind because not every threat exercises the same technical capability or end-goal. Some threats are sentient, others are autonomous, and their methods are different as is their target selection. While I’ve seen many published threat models, I’ve not seen any specifically focused on the nuances of website security (maybe I missed it?). Website security is much different from other forms of software or business models and deserves special attention in the ways it's handled.

After studying Verizon’s 2009 Data Breach Investigations Report, you learn a few things about what or who we’re up against. Most threats are external, use SQL Injection en-masse, and linked to organized crime. This means they don’t typically have access to the source code or binaries of the custom Web applications they exploit (not that they need it). This threat profile is different from someone analyzing a piece of operation system software to uncover a 0-day who may test locally 24x7 without raising alarms. Also different from scanning a network for an unpatched issues open to a ready made exploit. Verizon goes further to organize the apparent threats into three types based upon how they chose their targets:

Random opportunistic: Victim randomly selected
Directed opportunistic: Victim selected, but only because they were known to have a particular exploitable weakness
Fully targeted: Victim was chosen and then attack planned

To make these a bit more website security specific I took the liberty of crafting some quick descriptions and associated activities a threat might perform as part of their attack vectors as a way of getting things started.

Random opportunistic: Attacks are completely automated, noisy, unauthenticated, exploit well-known unpatched issues and some customized Web application vulnerabilities. Targets are chosen indiscriminately through wide scans and tend to impact the most vulnerable. Typical motivation is to infect Web pages with malware or subtle defacement.

Example: With Mass SQL Injection automated worms insert malicious JavaScript IFRAMEs (pointing to malware servers) into back-end databases and used the capability to exploit unpatched Web browsers.

Directed opportunistic: Attacker with professional or open source scanning tools. May register accounts, authenticate, and customize exploits for custom Web application flaws found easily by automation. Targets are those with valuable data that can be monetized, a tarnishable brand, and penetrable within a few days of effort.

Example: XSS vulnerabilities used to create very convincing Phishing scams that appear on the real-website as opposed to a fake. JavaScript malware steals victims session cookies and passwords.

Fully targeted: Highly motivated attacker with professional, open source, and purpose built scanning tools. May register accounts, authenticate, customize exploits for custom Web application vulnerabilities, and capitalize on business logic flaws. Victims may be defrauded, extorted, and targeted from anywhere to a year or more.

Example: ‘The Analyzer’, allegedly hacked into a multiple financial institutions using SQL Injection to steal credit and debit card numbers that were then used by thieves in several countries to withdraw more than $1 million from ATMs.

By aligning a threats capabilities against a particular security control it becomes much easier to predict and/or justify that controls effectiveness. The same is true for vulnerability assessment results, which SHOULD give some type of assurance or measure of the risk posed by a particular threat. Just randomly choosing a set of vulnerabilities to scan for doesn't exactly give you that.

Thursday, April 02, 2009

Disagree with the Concept or Implementation?

Web Application Firewalls, Professional Certifications, Website Trust Logos, and Compliance Regulations are contentious topics that spark spirited debates by those for and against their existence. For years I’ve studied thoughtful arguments voiced by many people about why they disagree with these things (solutions?) often with logic that is hard to discount. What’s interesting is the vast majority of the time it’s only the current implementation by particular security vendors that are opposed. We all know many vendors abuse customers with over promising marketing, under delivering products, selling/doing/saying anything for a buck, etc. This reality will never go away, we can only expose the behavior, and this is also very different from saying that the concept behind the solutions shouldn’t exist at all or be offered by someone capable of doing better.

For example, three years ago like basically everyone in the webappsec at the time, I was a staunch WAF opponent. The WAF concept made no sense to me because why would anyone go through the pain of implementing such a device when they could simply fix the code and be done forever? That is until one day while compiling Sentinel vulnerability statistics and the volumes being identified revealed a problem so massive, pent up by over a decade of egregiously insecure Web code, that it obviously could not be solved with available fix-the-code resources (time/cost/skill) anytime soon. IT Security personnel also shared their pain of having no authority over development groups, no juice with the business to fix vulnerabilities over adding new features, and limited options to protect websites in which they were responsible for. Malicious exploitation seemed to be the only thing that genuinely stimulated action.

IT Security clearly needed an operational solution. The only answer to the aforementioned problem was the promise of a WAF. Whether not they functioned as advertised became immaterial, the bottom-line was we needed WAFs to work! Seriously, it's insane to think its possible to mitigate millions of vulnerabilities across millions of websites, even if you could find them (the vulns or the sites). Seeing the writing on the wall I invested myself in WAF technology changing my conceptual opinion to implementation and set out to see what WhiteHat could contribute. That eventually led to the (VA+WAF) solution where vulnerabilities found through our assessment process could be imported as customized rules into a WAF. This provides a viable option to mitigate now, and remediate the source of the problem in the time and manner that made business sense ... to them.

As always I’m curious to know what other think and how they characterize their opinions according the following solutions. If you disagree with them, is it on the basis of Concept or Implementation (and why)?

Web Application Firewalls - ?
Professional Certifications - ?
Website Trust Logos - ?
Compliance Regulations - ?

Wednesday, April 01, 2009

New cert program for Application Security Specialists

So confirms The Institute for Certified Application Security Specialists.

Love them or hate them, certifications are a part of the information security industry. As waves of new comers flood into the emerging application security field, overwhelming hiring managers, it's imperative that true "specialists" distinguish themselves from the general InfoSec practitioner. Obtaining a respected certification is one way for a professional to do exactly that while simultaneously increasing their credibility. Still the challenge for many is a lack of time to study, attend classes, take exams, and the high costs involved -- not to mention healthy skepticism of the value provided by such programs. What we do know is the more exclusive and specialized a certification is, the more value it may hold. So that's when I heard about the The Institute for Certified Application Security Specialists (ASS) offering a program, I had to investigate.

After visiting their site and reading the literature, I must say I was thoroughly impressed. I was previously aware of the CSSLP program, but their process was a little too involved. Conversely the Institute created a streamlined program to meet the requirements of both organizations and individuals in today's fast evolving application security landscape. The ASS certification takes into account previous work experience, industry standards and best-practices, includes a sound Code of Ethics, and even a well thought out Oath of Office. That way certification holders can rest assured they'd be in good company. Should an applicant qualify for an official certification they can obtained one without examination in minutes with a 3-step process (see right-side column) at a cost anyone can easily afford. After successful completion a person may proudly proclaim they are a Certified ASS!

I'm confident this offering will become very popular after experiencing the process personally. Lastly, one must be aware though that according to the terms certifications are only valid up until the release of Web 3.0 where additional standards may apply.