I haven’t blogged or released much research in the last two years. If you care about that, which I doubt you do, then I’m sorry.
I’ve been putting all of my energy into Contrast, a completely new way of finding vulnerabilities in applications.
Contrast uses instrumentation to add “sensors” to your running JVM, including in the JRE, server and your custom code at runtime. A rules engine then detects when vulnerable combinations of those sensors occur. When they do, the “trace” of events is transmitted back to the Contrast site for you to see.
Using this sensor-driven approach, Contrast has all the high-level capabilities present in existing security software:
- Data flow (source-to-sink stuff like SQL injection, Cross-Site Scripting, etc.)
- Control flow (lack of authentication, access control, etc.)
- Configuration checks (lack of HttpOnly, verb tampering vulnerabilities, etc.)
- Runtime checks (use of MD4 or DES, detected at runtime)
Our rules are specified by a simple domain-specific language that allows you to mix and match the above check types into a single rule.
I’m super proud of the work we’ve done. We’re planning on being perhaps naively open about how Contrast works and our rules. We hope to foster a community that works together to make sure everyone is getting the best security coverage. We’re not kidding when we say Contrast installs in a few minutes (add one line to your server startup script), and doesn’t require any security skill (just browse around your app). Vulnerabilities start popping up, and dashboards and trending reports start to churn.
The NewRelic and AppDynamics companies have been extremely successful using a similar model for measuring performance. I’m not talking about financial success, either. I’m talking about their ability to deliver developers actionable data to meet their goals. Contrast aims to be dead simple, unparalleled in accuracy, and continuously available.
Everything else, to me, is on the wrong side of history.