There is a reason why the adoption rate of these tools is very LOW (by security professionals, developers, software architects, etc..), and even more importantly, there is a a reason why even when they are used, very few people actually get decent (& actionable) results from it. Of course that the sales & marketing departments paint a different story, but most of the current sales result in shelf-ware (and if you have doubts on this statement, I just have one word for you: Frameworks)
In addition to:
- lack of support for Frameworks like Struts, Spring, Enterprise Library, ASP.NET MCV, (heck, most don’t even ‘properly support’ J2EE’s or ASP.NET’s request execution flow),
- the customizations made to those Frameworks, and
- custom or ‘client / vendor specific’ Frameworks
... the reason why those tools don’t work in the real world, is because they (currently) don’t ‘understand’ how the target application works.
For example, when they DO provide a finding, that finding will only cover a very small part of the entire code flow that creates that vulnerability (for example the URL with the exploit or the internal Source-Sink trace).
This is why the market perceives these tools as NOT working, and why the security professionals (who should be its MOST active users and promoters) look down on them and ignore them.
Remember that my objective on my security engagements is to ‘Automate Security Knowledge and Workflows’.
This way less experience users will be are able to replicate my actions and fix, mitigate or accept (the risk of) the security issues on their applications.
Application security will never scale if we required everybody to be security experts!!
Back to O2...
This is why the market perceives these tools as NOT working, and why the security professionals (who should be its MOST active users and promoters) look down on them and ignore them.
Remember that my objective on my security engagements is to ‘Automate Security Knowledge and Workflows’.
This way less experience users will be are able to replicate my actions and fix, mitigate or accept (the risk of) the security issues on their applications.
Application security will never scale if we required everybody to be security experts!!
Back to O2...
Historically O2 was built on top of the Ounce’s Labs (now called AppScan Source Edition) product when I was hired (in my 2007) as an independent consultant, and was tasked of using their tool on ‘service-driven’ engagements and provide feedback to the product team.
After getting my head around on how the Ounce Engine, I was in love with its data-flow analysis and wide coverage (since I was used to doing it by hand), but was very disappointed by its lack of support for Frameworks and for ‘building custom analysis’ on top of those findings (which remember, only represent a small part of the ‘real’ traces & exploit flow).
So having a programming background, I did what every security consultant does today.
I wrote scripts ...
And more scripts & command line tools...
And more scripts & some GUIs ...
Who eventually become so complex and feature rich, that I decided that I needed to build a host for those scripts, tools and GUIs.
And that is when O2 was born :)
In fact, originally this tool was called F1 (as in the ‘F1 racing car’ vs ‘the normal cars that run on the road’), and was renamed O2 (for Ounce Open) when the Ounce Labs guys made the decision to allow me to Open Source it (which happened Nov 08 (last year) at the OWASP conference in NYC)
In the beginning, O2’s capabilities were almost 100% dependent on the Ounce’s engine (since originally O2 (i.e. F1) was designed to automate and increase it capabilities). So at this stage, one could not use O2 without a valid (i.e. paid for) Ounce Engine.
Eventually, as O2’s capabilities matured and (aided by the fact that I was doing other Security Engagements outside of Ounce where I was using & developing O2), the number of features that did NOT require Ounce’s commercial license started to grow. Eventually taking O2 to a level that enormous value can be obtained by ALL users and making O2 worthy of being an OWASP project (and being called ‘A Platform’).
Today (Nov 09), O2 has reached a maturity level where I (Dinis) can finally perform security engagements with a type of visibility and automation that I could only dream off a couple years ago.
There are a small number of people (me and the few brave O2 users) that get a LOT of value from O2, the challenge now is to make this scale, and dramatically simplify O2’s workflows so that it can be easily used by new users.
After getting my head around on how the Ounce Engine, I was in love with its data-flow analysis and wide coverage (since I was used to doing it by hand), but was very disappointed by its lack of support for Frameworks and for ‘building custom analysis’ on top of those findings (which remember, only represent a small part of the ‘real’ traces & exploit flow).
So having a programming background, I did what every security consultant does today.
I wrote scripts ...
And more scripts & command line tools...
And more scripts & some GUIs ...
Who eventually become so complex and feature rich, that I decided that I needed to build a host for those scripts, tools and GUIs.
And that is when O2 was born :)
In fact, originally this tool was called F1 (as in the ‘F1 racing car’ vs ‘the normal cars that run on the road’), and was renamed O2 (for Ounce Open) when the Ounce Labs guys made the decision to allow me to Open Source it (which happened Nov 08 (last year) at the OWASP conference in NYC)
In the beginning, O2’s capabilities were almost 100% dependent on the Ounce’s engine (since originally O2 (i.e. F1) was designed to automate and increase it capabilities). So at this stage, one could not use O2 without a valid (i.e. paid for) Ounce Engine.
Eventually, as O2’s capabilities matured and (aided by the fact that I was doing other Security Engagements outside of Ounce where I was using & developing O2), the number of features that did NOT require Ounce’s commercial license started to grow. Eventually taking O2 to a level that enormous value can be obtained by ALL users and making O2 worthy of being an OWASP project (and being called ‘A Platform’).
Today (Nov 09), O2 has reached a maturity level where I (Dinis) can finally perform security engagements with a type of visibility and automation that I could only dream off a couple years ago.
There are a small number of people (me and the few brave O2 users) that get a LOT of value from O2, the challenge now is to make this scale, and dramatically simplify O2’s workflows so that it can be easily used by new users.
