Web application crashes and error messages are centrally logged.
Define the scope and design of comprehensive security tests, conduct the tests, and document results within the development workflow or issue tracking system. Conduct functional testing of security features, dynamic vulnerability testing, and tests for previously reported vulnerabilities. Use additional techniques such as fuzz testing, penetration testing, and root cause analysis to strengthen security. Document all issues, remediations, and lessons learned, and use resources like source code and design records to inform ongoing test planning.
Integrate fuzz testing into the development process to identify security vulnerabilities by injecting malformed or unexpected data into application inputs. Ensure testing covers all major input parameters, simulating real-world attack scenarios to detect unexpected crashes and weaknesses. Leverage automated fuzzing tools to systematically generate malformed inputs, exposing bugs that structured testing may overlook. Prioritize recording and analyzing crashes to assess their security impact, ensuring that discovered vulnerabilities are properly triaged and remediated. Use existing fuzzing frameworks to enhance test coverage and detection accuracy while minimizing manual effort. Apply fuzz testing to closed systems, such as SIP phones or embedded applications, where traditional security testing may be limited. Maintain a continuous testing strategy, incorporating lessons learned to improve resilience against unpredictable inputs.
ID | Operation | Description | Phase | Agent |
---|---|---|---|---|
SSS-03-02-01-01-01 | Cover all main input parameters with fuzzing | Ensure that fuzz testing covers most or all of the application's main input parameters. This includes any data that the application accepts, whether from users or integrated systems. | Development | Security Engineers, QA Teams |
SSS-03-02-01-01-02 | Send random or malformed data to the application | Perform fuzz testing by sending random or malformed data inputs to the test subject in an attempt to make the application crash or behave unexpectedly. | Development | Security Engineers, QA Teams |
SSS-03-02-01-01-03 | Record and inspect crashes for security impact | Record all application crashes during fuzz testing and carefully inspect each one for potential security impacts, such as data corruption, unauthorized access, or unhandled exceptions. | Development | Security Engineers, QA Teams |
SSS-03-02-01-01-04 | Automate fuzz testing using existing tools | Leverage existing fuzzing tools and frameworks to automate the fuzz testing process. Utilize their supporting tooling to generate test cases and track issues efficiently. | Development | Security Engineers, QA Teams |
SSS-03-02-01-01-05 | Assess the quality of a closed system | Use fuzz testing to assess the robustness of closed systems (e.g., SIP phones, proprietary systems) that might otherwise be hard to evaluate through traditional testing methods. | Development | Security Engineers, Testing Teams |
SSS-03-02-01-01-06 | Triaging crashes for vulnerability analysis | After performing fuzz testing, triage any crashes to understand their root cause and determine whether they could lead to security vulnerabilities, such as buffer overflows or denial of service. | Development | Security Engineers, QA Teams |
Industry framework | Academic work | Real-world case |
---|---|---|
Information Security Manual (ISM-1911) NIST Secure Software Development Framework (PW.8.2) OWASP SAMM: Software Assurance Maturity Model( V-RT-1-B) |