I was just reading Dre’s post, R.I.P. CISSP, over at the tssci security blog, in which he predicts the upcoming OWASP People Certification Project will be the next big thing. This paragraph is quoted from James McGovern’s blog (James is the project leader):

As an Enterprise Architect, I understand the importance of the ability for a security professional to articulate risk to IT and business executives, yet I am also equally passionate that security professionals should also have the capability to sit down at a keyboard and actually do something as opposed to just talking about [it].

I agree wholeheartedly with this sentiment, and I believe the project goals are noble. So I went to read the latest OPCP draft proposal to see how they planned to tackle this admittedly difficult problem. What did I find? It’s just another test, with questions in a dozen or so broad categories. Far more specialized that CISSP, with topics that are more relevant to application security, but ultimately, still just a test.

The comment I once made about security educators/trainers is relevant here. Whatever questions end up on the OPCP test, these educators could probably answer most of them correctly without even studying. They lecture day in and day out about these topics. They have heard obscure questions and are prepared to answer them. And yet, many of them do not have any practical field experience.

A client chastised me once for making a statement that penetration testing is a mixture of art and science. He wanted to believe that it was completely scientific and could be distilled down to a checklist type approach. I explained that while much of it can be done methodically, there is a certain amount of skill and intuition that only comes from practical experience. You learn to recognize that “gut feel” when something is amiss. He became rather incensed and, in effect, told me I was full of it. This customer went on to institute a rigid, mechanical internal process for web app pen testing that was highly inefficient and, ultimately, still relied mostly on a couple bright people on the team who were in tune with both the art and the science.

Certifications only test the science.

RSnake blogged on this first but I can’t help but comment on it. Essentially, Cenzic managed to get a patent issued on the technique of fault injection, and now they’re getting litigious. The abstract from the patent reads as follows:

A method of testing a target in a network by fault injection, includes: defining a transaction baseline; modifying at least one of an order and a structure of the transaction baseline to obtain a modified transaction with malformed grammar; and transmitting the modified transaction to a target. The method may further include, receiving a feedback from the target to determine fault occurrence. An apparatus for testing a target in a network by fault injection, includes: a driver configured to generate patterns, where a pattern can generate a plurality of packets for transmission to the target, the pattern being represented by an expression with a literal string and a wild character class; and a network interface coupled to the driver and configured to transmit and receive network traffic.

Late last month, they filed suit for patent infringement against SPI Dynamics, who makes WebInspect, one of the leading web application scanners on the market. Conveniently, they waited until after SPI was acquired by HP, which clearly has much deeper pockets than the previously privately-held SPI.

Why do patents keep getting issued for techniques and methods that have been common practice for years? If you were doing application security consulting in the late 90s or early 2000s chances are you were using fault injection. Back at @stake, I know of two tools that we released in the 2000-01 timeframe specifically around fault injection — one was Dave Aitel’s sharefuzz tool (still available from Immunity) and another was Frank Swiderski’s feszer. And those were just the tools that were publicly released. Other security consultancies at the time were certainly using similar techniques. There’s no way the Cenzic patent has any merit, there’s too much prior art out there.

Remember the Watchfire patent on web application scanning?

A method for detecting security vulnerabilities in a web application includes analyzing the client requests and server responses resulting therefrom in order to discover pre-defined elements of the application’s interface with external clients and the attributes of these elements. The client requests are then mutated based on a pre-defined set of mutation rules to thereby generate exploits unique to the application. The web application is attacked using the exploits and the results of the attack are evaluated for anomalous application activity.

Yes, plenty of people were doing that before the patent was issued in 2001. There weren’t a lot of automated web application scanners at the time, but methodology-wise, that’s how people did manual penetration testing. Now that Watchfire (actually IBM) holds a patent on it, all of the other vendors, Cenzic and SPI/HP included, have to pay significant royalties to stay in business. What this also does is discourages new and better tools from entering the market. Creativity is stifled for fear of IBM knocking on the door and demanding their cut.

There will be a lot of eyes on the Cenzic vs. SPI case as it clearly has far-reaching implications for the security industry. Chances are it’ll get settled out of court and a licensing agreement reached, since it’d be a drop in the bucket for HP. Hopefully HP chooses to fight it, though, because they can win this one.

Veracode president and CEO, Matt Moynahan, was featured yesterday in a podcast interview with IT security expert Dan Sullivan on automated vulnerability analysis as a service.

In the podcast, Matt answers questions on automated application vulnerability analysis – offered as an outsourced service. And he discusses why companies are looking for solutions that use multiple testing techniques, including Web application scanning and static binary analysis, to provide more comprehensive security reviews.

Here’s the description from the site:

Automated vulnerability assessment can complement manual efforts to find and correct vulnerabilities in application code. In this podcast, Matt Moynahan, CEO of Veracode, discusses key issues in vulnerability testing, including:

• What is the process of automated application vulnerability analysis? What are the pros and cons?
• What types of application vulnerabilities can be detected with automated analysis as a service?
• When analyzing application vulnerabilities, is static analysis sufficient to detect vulnerabilities or are behavior-based techniques required as well?
• Many developers are familiar with cross-site scripting and injection attacks, are there others you commonly see when you conduct security reviews?

Listen to it or download it here.