Should Fuzz Testing be part of your SecDevOps pipeline?
The FBI recently reported that hackers successfully infiltrated a Mortgage Company’s computer systems to steal sensitive customer information using fuzzing. Fuzzing is a technique used to overwhelm and crash computer systems by flooding them with invalid, unexpected, or random inputs. Most organizations rely on static code scans, dynamic binary scans and vulnerability or penetration scans to detect security related issues, these are increasingly inadequate and unable to detect non-obvious flaws that can be exploited by hackers intent on breaking into enterprise systems.
Adopting a defensive and offensive mitigation strategy
As organizations seek to get better at protecting their systems it is essential to look at both defensive and proactive measures to detect non-obvious security defects. Protecting and monitoring the perimeter and looking for constant crashes is critical. Protections can be added by creating security rules at the boundary using firewall rules. A more proactive and offering mitigation strategy is to add fuzz testing as part of the CI/CD pipeline. Fuzzing or fuzz testing should be part of the test suite especially for large organizations with sensitive information.
Fuzz Testing as part of the CI/CD pipeline
The goal of fuzzing is to induce the application to behave in abnormal ways in response to the random input presented. This abnormal behavior could be due to memory leaks, threads hanging, buffer overflows, and other non-obvious malfunctions which can then be exploited. For example, a well known case study of fuzzing is related to a web system being penetrated by exploited a weakness in the anti-virus software that was made to crash through fuzzing which then allowed the uploading of infected files.
Given the need to accelerate the delivery of software, it is critical to integrate the fuzz testing as part of the overall development process. Key steps involved in fuzz testing are:
– Identify a target component using reconnaissance
– Design the inputs to be presented to the target
– Generate the fuzzed data by creating an attack script
– Execute the script
– Monitor the system for malfunctions
– Review logs and behavior for vulnerabilities
Initially some of these steps may have to be performed manually, but once the scripts are ready, then the actual execution could be scheduled using common CI/CD tools like Jenkins and generate reports that can be reviewed by the security team.