Do I Need to Fuzz For the SDL?
Given diligent application of required security activities in the Design and Implementation phases, fuzzing done at the Verification phase confirms that attack surface reduction and threat modeling were complete and that resulting code was well written from a security standpoint.
Fuzzing Recommendations of the Microsoft SDL
- Fuzz each protocol on its own
- Test at all the levels, including network, protocol, file, hardware, DLL and API
- Maximize your testing – Reach coverage as close to 100% as possible
- Fuzz whatever malicious input a user can provide (file formats, program parameters, network traffic, ActiveX controls, extension protocols, drivers, APIs, etc.)
- Don’t use only random input, also feed the application what it might expect
BeSTORM performs a comprehensive software security test of products during development, in the Verification phase of the SDL and after release. Testing should be started during development so that threat modeling can be verified and security weaknesses can be revealed early. Vulnerabilities found early can be corrected with far less cost and with less impact on production deadlines. If you’re curious to learn more about beSTORM, read our DAST guide.
Many security vulnerabilities found in products and applications can be discovered automatically using beSTORM. By trying virtually all different attack combinations and with the ability to detect application anomalies and indicate a successful attack, security holes can be revealed with little oversight.
BeSTORM can perform attacks on virtually all user input vectors:
- File formats
- Network traffic
- ActiveX controls
- Extension protocols
- Drivers and APIs
Attack prioritizing algorithms allow beSTORM to start with the attacks most likely to succeed, depending on the specific protocol that is audited. This saves considerable time and highlights the most important problems first.
After starting with the most likely attacks, beSTORM will exhaustively test the full test-space. Examples include:
- One or more malformed values found inside the packet(s) – non alpha-numeric data if such is expected
- One or more malformed relationships between values found inside packets – size, description
- Oversized values
- Undersized values
- Non-expected values – if expecting a session number, use non-relevant data, e.g. reuse a previously closed session number
- Out of order sessions – the order at which packets from a session are sent is reversed or ‘randomized’
- Overlapping sessions – the follow-up packet re-initiates or utilizes different values that it should have
- Missing sessions – the session is never completed, or properly closed
Does beSTORM Need Access to Source Code?
As a true black-box testing tool beSTORM requires no access to source code and little or no training on protocols to begin testing. Its ‘Auto Learning’ feature allows it to fuzz proprietary protocols. beSTORM tests the binary application and is therefore completely indifferent to the programming language or system libraries used. beSTORM can run automatically until all test scenarios are exhausted, trying the most probable combinations first.
Complete logging provides stable and repeatable tests for security compliance checking. An incorporated monitor detects buffer overflow, format string, or memory exceptions. It will report the exact interaction that triggered the vulnerability and developers can repeat that interaction using whatever development environment they wish to see what caused the fault.
Some Noteworthy beSTORM Customers
- Lockheed Martin
Microsoft SDL Fuzzer
Fortra’s Beyond Security is a member of the SDL Pro Network, a group of security consultants, training companies, and tool providers that specialize in application security and have substantial experience and expertise with the methodology and technologies of the SDL.