Webcasts
April 14-15, 2010 - Fuzzing 101 Webinar:
Fuzzing in the SDLC
Abstract
Codenomicon participated in the Blackhat webcast together with other new members of the SDL Pro Network. Codenomicon will provide a more extensive presentation for our customers and contacts. In this presentation, we will look at security and robustness testing in the various phases of the SDLC. Fuzzing is typically used in the Verification/Testing phase of the SDLC. This presentation explains how fuzzing can be used in the earlier stages of the software development process, for example, in unit testing. In addition, we will look at agile testing practices. In agile software development processes, fuzzing is performed in testing and verification related tasks in the agile development cycle.
Registration
The webcast will last approximately one hour + QA. Number of participants is limited to 100 registrants.
Register for a session now by clicking a date below:
- US West Coast: 9 AM
- US East Coast: 11 AM
- United Kingdom: 5 PM
- France/Germany: 10 AM
- India: 1:30 PM
- China: 4 PM
- Japan: 6 PM
Please contact info@codenomicon.com if neither of these times works for you or if the session you wanted to join is full, and we will schedule a new session for later time.
Speakers
Ari Takanen
Ari Takanen, founder and CTO of Codenomicon, has been active in the field of software security testing research since 1998. He has focused on information security issues in next-generation networks and security critical environments. In his work at Codenomicon and OUSPG (Oulu University Secure Programming Group), Mr. Takanen's primary goal has been ensuring that new technologies gain wide public acceptance by providing means of measuring and solidifying the quality of networked software. Mr. Takanen is one of the members of the original PROTOS research project, which studied information security and reliability errors in e.g. WAP, SNMP, LDAP, VoIP implementations.Mr. Takanen Takanen is a distinctive member of the global security testing community, a noted author and a regular speaker at various testing and security conferences, universities and international corporations. He is an author of two books on VoIP security and security testing.
Long Description of this Fuzzing 101 session
Truly proactive security measures are needed in the software development lifecycle (SDLC) to guarantee the robustness of your systems against zero-day attacks. We will focus on one approach to integrating and building security into your products, namely Fuzzing. This presentation serves as an introduction to both product security and fuzzing.
The only way to protect your systems against unknown security threats and potential attacks is to make security testing a part of the software development life-cycle. Unfortunately, legacy security testing practices such as security scanners and vulnerability scanners are reactive, and therefore they can only discover known security issues in widely used software products. Fuzzing as a proactive security testing technique provides a solution to find zero-day vulnerabilities in software. Fuzzing is typically employed in the test and verification step of the SDLC.
When revising your implementation strategy to include fuzzing into your SDLC, it is important to consider how broad the coverage of different testing techniques is and how easy it is to integrate testing into your specific software development process. The two leading approaches to fuzzing are template-based fuzzing and model-based fuzzing. Template-based fuzzers take a sample of network traffic or application logic such as XML dialogue, and mutate it to test for unexpected inputs. Model-based fuzzers, in turn, are built from interface specifications, and therefore, they are systematic in their approach to testing the input coverage of critical software.
In this presentation, we will look at security and robustness testing in the various phases of the SDLC. Fuzzing is typically used in the Verification/Testing phase of the SDLC. There are five general testing activities where fuzzing should be used: Unit, System, Integration, Acceptance and Regression test. The maturity of the product, build process, release cycles and quality/security tools in use dictate the various levels of testing done within each of these activities.This presentation explains how fuzzing can be used in the earlier stages of the software development process. In addition, we will look at agile testing practices. In agile software development processes, fuzzing is performed in testing and verification related tasks in the agile development cycle.
With regard to negative black box testing, in particular Codenomicon Defensics, it has been our experience that most Defensics customers implement our tools initially in the System and Integration test phase to realize maximum efficiency and test coverage across product groups, and resulting in easy to measure ROI for moving towards earlier bug discovery. In optimal cases Defensics should be run as early as possible in the software development, by programmers themselves during Unit test. This is especially critical for testing the stability of underlying operating system services and protocol stacks.
In security analysis, fuzzing has been mainly used by security people in the later stages of the software development cycle to find security or robustness issues in software, when the product is already complete. Passing Codenomicon Defensics tests should be the final acceptance gate (by running the tests as Acceptance Test) or review (by reviewing adequate level of test reports) before any product is released. Any flaws that are undetected at the Acceptance test will eventually be found by customers, therefore damaging the vendor brand. The usage of fuzzers in regression testing after the software is complete is critical, to prevent the flaws from being re-implmented into code.
In this presentation, we will use examples from the Security Development Lifecycle (SDL). SDL is the industry-leading software security assurance process created, and used, by Microsoft. It encompasses the entire software development lifecycle and explains how security can be built into the software.
