In this webinar, we explore the process of zero-day vulnerability management from initial threat analysis to automated detection and remediation. We will demonstrate how easy it is to detect attack vectors and to quickly assess the reliability and security of those interfaces using general purpose fuzzing solutions. We will also show you how you can complement these solutions with known vulnerability data and do patch verification easily and cost-effectively. Finally, we will discuss how you can tailor your defenses to block zero day attacks, which is a key aspect of vulnerability management.

1. Zero Day Vulnerability Management Fuzzing 101 Ari Takanen, CTO of Codenomicon July 6th, 2010

5. Zero Day Vulnerability Management Moving from Reactive to Proactive

6. Security View: Window of Vulnerability SW - under vulnerability analysis SW - after product release SW - after the vulnerability process TIME BUG APPEARS RELEASE BUG FOUND VULN FOUND VULN REPORT VULN FIX AVAIL. PATCH RELEASE ADVISORY RELEASE PATCH INSTALL Zero Exposure Limited Exposure Public Exposure

8. Security Vulnerability = Just A Bug

9. Codenomicon Labs Test Results http://www.codenomicon.com/labs/results

13. Practice Targets: Known Vulnerable Software

15. Threat Analysis using Network Analyzers Identify and prioritize!

18. Network Analyzer % sudo vmnet-sniffer -w demo.pcap vmnet8

20. Fuzzing for Zero Days What you need to know to prepare for zero day discovery

21. Fuzz Test Effectiveness against WiFi

25. Anomaly Coverage Selection

26. FTP Fuzzing

27. Results

29. Traffic Capture Fuzzing

31. Zero Day Remediation Using IDS/IPS Block only what needs to be blocked!

34. Load Snort default

35. Attack WinSip – Snort Does Not Detect

36. Alert Raised by Codenomicon Ruleset

37. Patch Verification for Known Issues Do you trust the vendor patches?

39. Patch Verification with Vulnerability Feeds

43. PROACTIVE SECURITY AND ROBUSTNESS SOLUTIONS THANK YOU – QUESTIONS? “ Thrill to the excitement of the chase! Stalk bugs with care, methodology, and reason. Build traps for them. .... Testers! Break that software (as you must) and drive it to the ultimate - but don’t enjoy the programmer’s pain.” [from Boris Beizer]