Better Software - June 2008 - (Page COD2)

Codenomicon whitepaper: How to integrate FUZZING and security testing into SDLC 1 Introduction to fuzzing In contrast to fuzzing frameworks, another category of fuzzers consists of test suite-based fuzzers. These package a set of tests that have been pregenerated with fuzzing methods into a test suite or test tool that can be used in actual testing. Usually this type of fuzzing requires only minimal work from the end-user (tester), as the interface model as well as test case definitions have already been created beforehand. The tester needs to configure only a few basic settings to start running the tests, and does not even need to fully understand the specifications or other details of the tested protocol or file format. Another dimension for comparing fuzzers stems from whether they are model-based or not. Compared with a static, non-stateful fuzzer which may not be able to simulate any protocol deeper than an initial packet, a fully model-based fuzzer is able to test an interface more completely and thoroughly, usually proving much more effective in discovering flaws in practice. Tests executed by a fully model-based fuzzer are usually able to penetrate much deeper within the system under test, exercising the packet parsing and input handling routines extremely thoroughly, and reaching all the way into the state machine and even output generation routines. Security needs to be integrated into every step of the software development life-cycle (SDLC). Neither fuzzing nor code auditing is able to provably find all possible bugs and defects in a tested system or program. As a rule of thumb, the effectiveness of fuzzing is based on how thoroughly it covers the input space of the tested interface (input space coverage), and how good are the representative malicious and malformed inputs for testing each element or structure within the tested interface definition (quality of generated inputs). Fuzzers which use templates or network captures as the model will reach very low input space coverage. Fuzzers which populate their tests with random or semi-random data will have bad quality of inputs and can have significant number of meaningless tests. By Heikki Kortti, Codenomicon Fuzzing or fuzz testing means sending malformed or invalid inputs to a software, device or system in order to find critical flaws and vulnerabilities. During the past 10 years, fuzzing has become increasingly popular as a low-cost but highly effective way of hardening implementations against external attacks. Fuzzing enables software testers, developers and auditors to easily find defects that can be triggered by malformed inputs via external interfaces. This means that fuzzing is able to cover the most exposed and critical attack surfaces in a system relatively well, and identify many common errors and potential vulnerabilities quickly and cost-effectively. Fuzzing is especially useful in analyzing black-box systems, as it does not require any access to source code. Having access to information such as source code, design or implementation specifications, debugging or profiling hooks, logging output, or details on the state of the system under test or its operational environment will help in root cause analysis of any problems that are found, but none of this is strictly necessary. Fuzzing is often compared to code auditing and other white-box testing methods. While code auditing is another highly valuable technique in a software tester’s or developer’s toolbox, code auditing and fuzzing are really complementary to each other. Fuzzing focuses on finding some critical defects quickly, and the found errors are usually very real. With fuzzing, there are no false positives. Some fuzzers are implemented as fuzzing frameworks, which means that they provide an end-user with a platform for creating fuzz tests. Fuzzing frameworks typically require a considerable investment in time and resources to develop tests for a new interface. If the framework does not offer ready-made test data for common structures and elements, efficient testing also requires considerable expertise in designing inputs that are able to trigger faults in the tested interface. For further information on fuzzing, check out: http://www.codenomicon.com/products/buzz-on-fuzzing.shtml PREEMPTIVE SECURITY AND ROBUSTNESS TEST SOLUTIONS http://www.codenomicon.com/products/buzz-on-fuzzing.shtml

Table of Contents Feed for the Digital Edition of Better Software - June 2008

Better Software - June 2008 Contents Mark Your Calendar Contributors Technically Speaking eLightenment Code Craft Test Connection Management Chronicles Agile Model-Driven Development The Myth of Risk Management Stop the Insanity! Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.