Tuesday, 8 January 2013

My focus, O2 as the Open Platform, why IBM needs open standards and O2+AppScan research project

Here is an email (with minor edits) that I wrote recently to an (retired) IBMer and Bill Cheswick an Network Security guru (where I tried to answer the questions: "What are you trying to do? What is O2? and how can O2 help IBM?")

Hi Bill

My focus is on Web Application Security, namely on how to create secure applications.

My key objectives are to:
  • enable developers to write secure code
  • enable buyers/users to make informed and risk-based 'application security' decisions
  • scale application security knowlege
In order to make this happen, I wrote an Open Platform (called the OWASP O2 Platform) which allows the creation of custom 'analysis engines'. These engines are created from security expert's knowledge/workflows and the output/capabilities of Application Security Tools (like the ones from IBM AppScan, HP Fortify, Veracode, CheckMarx, etc...). I am also the lead architect and developer of the TeamMentor product (from Security Innovation) which is aimed at providing hyperlinked Security Knowledge to developers (e.g. prescriptive guidance for developers mapped to corporate policies)
To give you three examples in areas that you have done considerable research (passwords, visualization and firewalls), the O2 Platrform can be used to:
  • create a targeted analysis that checks (and verifies) an application's implementation of password-based authentication (for example to make sure the pitfalls you mention in http://web.cheswick.com/ches/talks/rethink.pdf don't exist)
  • visualize taint-flow or call-flow code paths in order to find (in)secure patterns
  • feed an WAF (Web Application Firewall) a map of an application's attack surface and its data validation rules/expectations
Basically what I'm trying to do is to improve the visibility into how an application actually works (vs how it behaves), so that we can understand its true security risk, and allow the users/buyer to make informed decisions. One of the key concepts that I have is to 'stop creating PDFs with security knowledge' and 'using UnitTests to talk with developers' .

Unfortunately, just like you mention in your presentation, we have to do much better job than what we're doing today.

Most companies/vendors/users/buyers don't really care about their application's security, and usually when they do (i.e. are attacked or there is an 'XYZ compliance requirement') most efforts tend to be targeted to the affected applications, with the focus being on damage control and 'compliance'.

And even the companies that want to develop secure applications struggle. 

These companies tend to create strong internal Application Security Teams with activities like the ones described in Building Security In Maturity Model. They unfortunately fail to scale, because the current Application Security Tools don't really work in the way they are sold and are designed to work 'out of the box'. These Application Security Tools tools tend to have limited customisation capabilities, which is a massive problem in the real-world since every major application is unique, with tremendous amounts of 're-invent the wheel' scenarios and lack of common controls (i.e. application building blocks). 

Add to the mix the fact that there are very few (if any) coding standards. Most development teams have weak CI (Continuous Integration) processes. The application's original developers are not there. There is little (if any) up-to-date documentation about how the application actually works; and the insurance industry is still trying to figure out how to measure/quantify risk, which is a pre-requesite to create application security insurance policies. Note how this article Cyber insurance offers IT peace of mind -- or maybe not doesn't really enter the realm of Application Security Risk.

The reality is that we will not fix application security, unless we also fix software development.

Since most companies barely understand how their applications work, including the network-based/anti-virus solutions currently deployed to protect them; the application/software problem is getting bigger and bigger by the day. 

But does this mean that 'the sky will fall'  today, tomorrow or next-month'? NO. 

Most companies and application are 'safe' today because there are not enough motivated and knowledgeable attackers to exploit them. The key question is: 'will this change in the next 2 to 5 years?' I think it will, and there is a big opportunity for the ones focused on solving the problem (vs patching it).

And this takes me to IBM, which is a company that will need to solve this problem. Think about how important application security is for IBM's Smart Planet and large software development services.

Ironically IBM already has a lot of the pieces in place. 

Look at their Rational AppScan, Testing, misc security and Jazz (Collaboration) products. The problem is that these IBM products are not integrated.

Most (if not all) customers of these IBM tools want the suite of tools to be integrated AND work with the dozens/hundreds of other products those customers already use internally. Most of these IBM products are not integrated because they were not created in-house, they were acquisitions. The current reality is one made of multiple GigaBytes of installs and databases which take days or weeks to set-up, and have different rules/reporting standards. So far, IBM has been making enough money with these tools/acquisitions (look at the IBM share price) to feel no urgent need to commit significant time, energy and resources in making these tools talk with each other.

IBM and others need to realise that it's just about impossible to integrate and consolidate these tools, and its development teams, without an open standard and platform (like the O2 Platform). Part of the reason that the Application Security and software industry is so immature (from an engineering point of view) is that companies who try to create such standards (like IBM, HP, Intel, Microsoft, Fortune 100, Anti-Virus, Network Security tools,  etc...) have done it under proprietary formats, in the hope to create/control the 'industry standard'. 

But for IBM, this 'proprietary standards' strategy is a false economy. IBM needs the Application Security space to mature, and ultimately the amount of money they could earn with Application Security Products sales, is dwarfed by the missed opportunities created by insecure applications or the costs of dealing with application security breaches.

Open standards are so important (e.g. code analysis, security rules, remediation practices, etc... ) because most applications exists in 'virtual realities' ' created by the Development Frameworks used. Each Framework version will need to be understood, codified and mapped to rules/guidance (for example a Spring Framework application behaves very differently from an application developed on top of SharePoint, Struts, Asp.NET MVC, SAP, Ruby-on-Rales, PHP, NodeJS, SalesForce, Android, IoS, etc...).

IBM already spends a lot in Application Security Research, which tends fall into that 'proprietary standards' pit. Most IBM Research Labs great ideas never ship in a usable/effective state and achieve their true potential. 

I have written a lot about these topics on my blog. Here are a couple posts you might find interesting:
The good news is that the industry is finally changing and is starting to talk/look at these ideas (like 'map/visualise how apps work', 'customise/integrate tools' and 'deliver security knowledge to developers using UnitTests', etc...) . For example here are a couple posts from Ian at IBM's community/blog DeveloperWorks website, which show the type of integration that is possible to create with the O2 Platform and the IBM AppScan Source product
So what are the next steps?

Well, a great place to start would be a research grant from IBM, to work with a couple IBM clients to create a PoC (Proof-of-Concept) of using the O2 Platform and AppScan products to create a consolidated/correlated view of an application's security, with a focus on fixing the identified security vulnerabilities (using consolidated remediation guidance from TeamMentor and the multiple AppScan databases). 

The deliverable would be an 'Open Interface' created on top of IBM's AppScan tools, customised for a particular application, and seamless integrated into the application's  development and build environment. 

This PoC would then be given to the multiple AppScan product teams so that they could productize the best parts, which would improve each product, help more customers and make the next generation of these PoCs simpler, faster and more effective.

What do you think?

Best Regards

Dinis Cruz


Posted by at
Labels: , , ,