The realization that software is becoming an essential component of our everyday lives was reflected yet again in this year’s Black Hat. Even more solutions are being touted to deal with the ever-growing exposure of software to malicious threats. Unfortunately, a lot of the solutions focus on dealing with the symptoms of our current predicament without addressing the fundamental truth - software is built insecurely despite our best efforts.
What is required is a change of perspective. Software is infrastructure.
This is particularly true in safety criticality systems. Think of recent advances in the automotive industry, aeronautics, and medical devices. All would not have been possible without the introduction of software as part of the innovation. This however has the unfortunate side-effect of imbuing these systems with an additional characteristic - the fusion of hardware and software make these systems essentially cyber-physical systems. The problem is that the processes which we’ve developed to deal with the challenges of modern software development have in general not yet reached the level of maturity required for systems where life and death are at stake.
What’s missing from the process is the concept of resilience. Resilience is the ability to resist catastrophic failure in the face of adverse conditions. Resilience is an essential requirement for safety-critical cyber-physical systems specially when theses systems are expected to function for decades, not merely years.
While there are a number of technologies which help address the challenge of building resilient systems, by themselves, they only address a fraction of the problem. Let’s look at the various strengths and weaknesses of these solutions:
Coverage guided fuzzing is a technique gaining popularity that is empowered by recent advances in cloud scale infrastructure. Fuzzing is the process of generating pseudo-random inputs and feeding into a program to see if it behaves in an unexpected manner. Surprisingly, this technique is very effective in discovering new defects which can have stability/security implications. Hackers have been known to use fuzzing to discover new vulnerabilities.
Google (through the OSS-Fuzz initiative) and Microsoft (through the development of their Security Risk Detection engine) have been extremely successful apply this technology to make their applications more resilient.
The cutting-edge of this technique combines both fuzzing with Symbolic Execution. While fuzzing can be thought of as brute force mutational input testing, SE can look at the execution context of program and discover interesting paths for analysis which fuzzing by itself would have difficulty making progress against.
In addition, test cases are automatically generated as part of the analysis. These test cases are important because:
They can function as regression tests for future versions of the software without additional developer effort. Instead of waiting for defects/vulnerabilities to be reported against future versions, you can test the most current version of a dependency to ensure the integrity of the program's behavior.
A discovered defect has direct/measurable impact on the running program and is extremely unlikely to result in a False Positive.
They can be reduced to a minimum set of cases which exercise the discovered execution paths. This is much faster than running a full analysis of the program and can be easily incorporated into a DevOps pipeline. This gives developers immediate visibility into regressions/defects discovered through analysis .
They can be used to provide defect reproducers so the developers can quickly identify where the code needs to be fixed. In essence, tests give the type of context an experienced auditor/pen-tester can provide.
As analysis progresses, new test cases are generated.
While no analysis can ever claim to find all possible bugs, having a collection of test cases that evolves with the program gives organizations confidence that a program which has undergone analysis will be resilient.
Interested? Come see how Mayhem can help you build more resilient software: https://forallsecure.com/early-access/
Originally published at The New Stack
Thank you for subscribing!