Home > Articles > Security > Software Security

Software [In]security: Software Patents and Fault Injection

  • Print
  • + Share This
Can you patent the obvious? Apparently when it comes to software security, maybe you can. Gary McGraw explains how another party may get a patent on a technique he had a hand in inventing.
From the author of

The notion of software patents is extremely controversial. The basic idea is simple and mirrors "regular" patents. An inventor invents something and files a number of claims about the invention. The Patent Office reviews the filing and determines whether to grant a patent for the invention. Holding a patent guarantees the inventor some rights to enjoy the fruits of the invention for a fixed period of time. Not so bad if you invent the next great inside-the-peel Tomato twaddler, but a bit harder to understand in the software space.

Can you patent the obvious? Apparently when it comes to software security, maybe you can.

Software Testing 101

When you test software, there are two basic things that are always required. Thing one is the ability to generate some input to the program so that when it runs (assuming it is not entirely self contained) you can provide it with input. Thing two is some way to observe what happens inside the program when it takes the input you have given it. We call thing two "observability."

Given thing one (input) and thing two (observability) we can go about testing some running code.

We can get as fancy as we want with thing one, maybe creating a grammar to drive particular kinds of input, maybe creating a test harness to build such input automatically, or maybe taking the standard operational profile of inputs observed over time and sampling mathematically from that set.

Of course without putting thing two into place, we could test all day and never even know we're doing anything. Thing two can be as simple as watching a program's output or as complicated as instrumenting the program under test in such a way that we create and monitor particular observable conditions.

As I said, there are about as many ways to tweak the thing one and thing two ideas to do some testing as you can dream up. Should dreams be patented?

The History of Software Fault Injection

Jeff Voas, long ago co-founder of Cigital (which was at the time called Reliable Software Technologies), is one of the inventors of software fault injection. (Jeff is now a computer scientist at NIST.) His thesis work was about testing and software assessment. His basic insight was that computing cycles were getting so cheap that there was no reason not to automate testing as much as possible and aim the gazillions of extra cycles at the problem. When I started working at RST (now Cigital), I was hired as a fresh out Ph.D. to work on a DARPA grant applying Voas's notion of software fault injection to security. This was in 1995.

We built a system called FIST (fault injection security tool), and published a number of papers about the system, including one titled "An Automated Approach for Identifying Potential Vulnerabilities in Software". At the time we were doing tons of work on software fault injection, including studies of web-based software. One of the first papers on web testing that we published came out in 1996. It was titled "Untangling the Woven Web: Testing Web-based Software". Interestingly, my co-author on that work went on to become the main contributor to the findbugs project (a static analysis engine for Java) .

Jeff convinced me to co-author a book with him on software fault injection, predictably titled Software Fault Injection. We published the book with Wiley in 1997. Here is a brief overview of the book taken from the back cover:

Of course, being a kind of dynamic testing, software fault injection makes plenty of use of thing one (input generation) and thing two (observabillity) from above. Carefully crafting input and controlling for observability is more than half the battle in fault injection.

Can You Patent the Obvious?

On to patent land. Apparently the security testing firm Cenzic believes that they deserve a patent for software fault injection. In February 2007 (a decade after our book was published) Cenzic was awarded patent number 7185232 for "fault injection methods and apparatus." The basic claims in the patent involve injecting some faulty input into a web program (thing one) and watching for error responses (thing two). Very nice. Or maybe not. A grass roots effort to collect prior art and dispute the patent is being spearheaded on the net by Enrique A. Sanchez Montellano.

As an inventor of security technology, I am not completely opposed to the idea of software patents. In fact, we hold eight patents in various aspects of software security at Cigital (some of which are likely to be infringed upon). We like the idea of licensing our ideas and our prototypes to others. In fact, that's exactly what happened with Fortify which was recently acquired by HP. We licensed our code scanning ideas and prototypes to Kleiner-Perkins who went on to found Fortify, build a real commercial product, and sell the heck out of it. So the notion of protecting our ideas with patents is not foreign to us.

At the same time, we are not a fan of silly patents. There are plenty of those. I think my favorite analogy regarding silly software patents is Tim Berners Lee's analogy to patenting plot twists in literature.

Though we are not sure how the Cenzic case will play out, we are pretty sure that we invented software fault injection for security.

  • + Share This
  • 🔖 Save To Your Account