Mike Rothman mentioned fuzzing today which prompted me to post a thought of my own. Fuzzing is not a security posture.

Fuzzing pretty much means throwing all sorts of “things” at an application either in input fields or network ports, and so on. This is something any dummy can run. But fuzzing results are an order of magnitude more difficult to determine if an issue is really a vulnerability. This isn’t the same as looking at an open port reported by Nessus or a missing patch reported by MBSA. Not only that, but fuzzing is not as fast as even an nmap scan on a network. The setup and execution are longer.

Once you get the results, oftimes you will need some memory management skills to determine if a bug will actually pop the stack properly, and then craft an exploit to prove the issue. Otherwise you might just have found some lame bug that closes the application (DoS), or less. If we raised the alarm on every issue a fuzzing found, we wouldn’t be having “Month of X Bugs,” but rather multiple “Years of X Bugs.” Check out the comments on some of those posts to see the contention some people make on whether a fuzzed result is truly exploitable or not.

Fuzzing is not terribly difficult. Interpreting the results takes an expert, unlike other scanning methods. Fuzzing won’t be a part of most IT shops or even developer circles for a long time until they start learning what happens in the OS/memory and not just doing their interpreted coding to do task A and move item B. Even QA will be hard-pressed to be given training and time to perform real fuzzing in all but the most critical and rich organizations.