I've been reviewing code for security problems for about 15 years now. I'm privileged to have seen the code for many of the world's most critical applications. And I've also had a lot of time to think about how we can find vulnerabilities faster and more cost-effectively, because outside attacks on applications have only increased. And when hacking can be done from a couch or a coffee shop, there really is no end in sight.
Why Instrumentation Rocks
Back in the early 2000's, I thought that static analysis might be a way forward with application security. It had promise. But unfortunately, the rapid advances in software architecture and software development processes have made it very difficult to get value from these tools. In 2009 I started to think about a new way to find security issues at runtime, by using "instrumentation" to gather information from a running application.
Instrumentation simply means that you add sensors to your code that allow you to gather information at runtime. We invented a host of new methods for doing this to extract security information, correlate it, and identify vulnerabilities. We realized that with this approach, our tools could be more accurate *and* far easier to use than existing tools.
In the meantime, instrumentation has *taken off* for doing performance analysis. Companies like New Relic and AppDynamics are using instrumentation to extract incredible performance information out of running applications and giving developers incredible power. In fact, these companies are literally making it possible for *every* developer to do their own performance testing. What used to require expensive performance specialists with complex expert tools can now be done by developers themselves.
Can we revolutionize application security the same way New Relic did performance? Yes, that's our vision and Contrast is the right technology for the job.
The Importance of Super Accurate Data Flow
We all know that finding vulnerabilities requires a very strong understanding of the data flow in an application. These data flows are the pathways that attacks follow through the code. But these pathways aren't very obvious, and they certainly aren't linear.
When an application receives some data, say an HTTP parameter, from a user, that data is parsed and put into a "request" object by the application server. Every time that data is combined, shared, merged, encoded, or stored, a new copy of that data is made. I think of it like a clusterbomb crashing through an application's code infecting other data pathways. Each new piece of untrusted data can cause multiple parallel data flows to track.
But it's worse than that. None of these tracked data flows are exactly the same. Some are combined with "safe" data. Others are validated or escaped in various ways. Are these flows now safe? Or are they still dangerous? Actually, it depends. In fact, it's important to understand all the various transformations and validations that each piece of data has gone through before reporting a vulnerability. One reason why static tools report so many false alarms is that they don't track all the different things that happen to data as it flows through an application.
Contrast's Advanced Data Tagging
By comparison, using Contrast we can track every piece of data that enters the application from an untrusted source. Initially, we tag this data with appropriate tags based on the source. So data from an HTTP header might be tagged "untrusted" while data from an HTTP parameter might be tagged "cross-site" because an attacker can send it across domains. Initially, these tags apply to the entire data.
As the data flows through an application, we update the tags every time the data is modified or examined. For example, if the tracked data is appended to some untrusted data, we keep track of both the untrusted and trusted parts. If some portion of that data is escaped, we track that too.
Then, when data finally reaches a dangerous method, such as a SQL query execution or invoking a command shell, we know exactly what security properties the data has and whether *any portion* of it represents a risk.
This super-accurate data flow tracking just works for most of the common injection type vulnerabilities, such as SQL Injection, XSS, LDAP Injection, XPath Injection, Command Injection, and more. Contrast identifies these out of the box.
Tracking Custom Data
Of course, you may want to put this powerful engine to other uses. It's easy to set up your own data tracking rules:
2. Define a new "trigger" by specifying the rules for when and how "PII" data can be used. For example, you might say that com.company.logging.Log.log*(*) methods cannot receive "PII" data.
3. Sit back and enjoy PII tracking in your new dashboard! Seriously, that's all it takes to test your application for this new data flow rule. And if you want to push it out across your entire application portfolio, Contrast makes that very easy as well.
We have clients using our powerful data tracking for all kinds of crazy amazing things. Several are using it to track credit card numbers wherever they go. Others are using it for internal data types not related to security. There's really no limit to the types of security monitoring you can create.
Developing a robust application security program does not need to be a daunting task...
Perhaps, all it takes is rethinking your existing program and moving to one that leverages a continuous application security (CAS) approach. Organizations practicing CAS quickly determine how a new risk affects them, design a defense strategy, and measure their progress to 100% coverage. By implementing eight functions within an enterprise you can assemble an effective application security program.