Friday, 13 November 2009

Part I - IBM Application Security related tools & "AppScan 2011"

To start this series of O2 (i.e. the OWASP O2 Platform) related posts, I would like to provide an example (using existing IBM products) of what an ‘Application Security Assessment’ should look like. 

This type of workflows and capabilities are what I mean by ‘solving the problem’ of 'Application / Software security'. 

In this world, effective People, Process and Technology (when fully integrated) can really allow the delivery of ‘Application Security Assessments’ that are: measurable, quantified, methodical, repeatable, documented, effective, productive and understood (maybe then we could even be able to talk about an ‘‘scientific or engineering process’). 

Using IBM products that exist today (and there are other alternatives Proprietary or Open Source tools) , lets look at how they could work one day when fully integrated 

VAPORWARE ALERT: This is a pure fictional scenario in Nov 2009, most of the workflows described below are either impossible or very hard to implement using today’s versions of these products (at least not without using O2 :) ) 

“... on rainy day in 2011.... 

John (who is the business owner of financial application XYZ) decides that it is time for him to make sure that is product is secure. His market as finally matured (from a security point of view) and his clients are now making purchasing decisions based on how secure the products are. 

This means that John doesn’t want to be ‘Compliant’ he wants to be ‘Secure’ 

So the first thing he does is he allocates enough budget to the problem, finds an internal resource who will be responsible for the initiative (i.e. fired if it is not done correctly) and makes it very clear to all parties involved in application XYZ’s team that SECURITY is now an important factor and they have to do it properly. 

Steve (who was appointed by John to implement this program) after much research decides to hire a 3rd party security consultancy company (called AppSEC) to help him with the process of security the current application. 

After much planning Steve and AppSEC agreed on the following plan of action:
  1. AppSEC will perform a compete application security review of application XYZ’ and deliver
    1. Security findings
    2. Technology to replicate the discovery and exploitation of those security findings
    3. Fixes for those security findings
    4. Developer Training materials (based on the security findings)
  2. AppSEC will have complete access to all application XYZ’s team members and is expected to securely handle all data exchanges between both parties (from emails, to application documentation, to source code, to findings, to remediation information, etc...)

  3. On completion, AppSEC is expected to leave behind a technological solution which is fully automated and can be triggered via a big ‘red button’ (so that new revisions/versions of the applications do NOT require a similar effort and expense) and used by NON-Security people (from developers, to managers, to testers,etc...)
AppSEC is an IBM shop, so they will be using a number of products during this engagement. 

At the core of all products used is the IBM Jazz platform (https://jazz.net)which acts like the central gateway (i.e. portal) into all tools and capabilities used during this engagement. 

The first step is to use Jazz to create a number of user accounts which will be used by the different parties (from AppSEC security consultants, to Application XYZ developers (who are outsourced) to Application XYZ managers, etc...) 

Even that first step (creating accounts for everybody) is not as simple as one might tough since at least 5 different Identify solutions were used: Jazz own user management system, Active Directory, Oracle, IBM and OpenID. The good news is that Jazz integrates will all of these, so the process is an easy and strait-forward one. 

Next AppSEC sets up Rational Project Conductor (https://jazz.net/projects/rational-project-conductor/) to manage this project and starts using Rational Requirement Composer (https://jazz.net/projects/rational-requirements-composer/) to complete the SOW (Statement of Work) with the client. The objective here is to make sure that all parties involved have a clear picture of what are the objectives and deliverables of this engagement. 

Once everything is ready to kick start the engagement, AppSec set-ups Rational Team Concert (https://jazz.net/projects/rational-team-concert/) which will be the ‘collaboration tool’ used on this engagement to synchronize all activities and provided an integrated (secure) communication platform between all parties involved. Remember that not everybody involved in this project can have access to ALL information available. There are a lot of very security sensitive information available whose access have to be securely controlled (note: there was talk about also using WebSphere Portal (http://www-01.ibm.com/software/websphere/portal/) on this engagement as an extension of the collaboration environment, but it was decided that at this stage those extra features were not critical for the success of this project) 

The next step for AppSEC is to build the test environment that will be used by its security consultants during the engagement. 

In the past this was always a massive problem since it is not trivial to replicate both Black Box and White Box environments for ‘real-world’ complex applications. Luckily Rational Build Forge (http://www.ibm.com/developerworks/rational/products/buildforge/) has a number of wizards and customizable import tools which allows the easy creation of this environment. 

Now everything is in place to start the security analysis, the AppSEC security consultants (who are broken into two teams) will use the following IBM Rational tools to gain visibility into the security profile of Application XYZ:

All these tools provide standard REST interfaces which are hooked via Jazz Foundation (via http://jazz.net/projects/jazz-foundation/) and consumable from a central console (which creates a fully integrated and seamless application security review environment). Although there were a substantial number of IBM applications used during the engagement, there is very little deployment, configuration and integration overhead due to the built in ‘IBM Cloud’ support (http://www-01.ibm.com/software/rational/announce/cloud-services/) which is configured from a central one-click to set-up a cloud-base application’ website (http://www-949.ibm.com/cloud/developer/dashboard) 

Here is the workflow between all these different tools (note that at these stage these tools are been driven by AppSEC security consultants who are tweaking them as required in order to adjust the built in functionality, capabilities and Framework support, to the ‘real-world-behavior’ created by the Application XYZ developers (for example a number of extensions where built to the MVC layer used which have a number of potential security implications (both in their ability to create vulnerabilities, but in also in their ability to remediation vulnerabiltiies))
  • AppScan Source Edition and Developer Edition are used to analyze the source-code and build an object representation of how the application works

  • These results are then feed to the AppScan Standard Edition, who now as a pretty good picture of how the application is structured and what should be possible (for example what URLs and Form fields can be submitted)

  • The results of AppScan Standand are feed back into AppScan Source Edition and Developer Edition who will now re-analyze the code in order to make sure that both set of data match (i.e. the ‘this is what I was able to do from the outside’ view provided by the BlackBox tool, matches the WhiteBox’s ‘these are the tainted data entry points that I know about’)

  • The other set of data that is provide to both tools is the AppScan Developer Edition ‘Instrumentation Logs’ which were created by instrumenting the ApplicationXYZ binaries using AOP and inserting hooks into all functions Enter & Leave. This creates a view of what were the exact code paths that were followed when page XYZ was invoked, and what was the changes made to the tainted data received from the outside (this is made possible by also logging the contents of the data objects created during the execution flow (namely the values of the function’s called parameters)

  • Another powerful technique used during this phase is the use of breakpoints at sensitive parts of the application (for example the data layer) so that the payloads created by AppScan Standard are detected and removed (since we can safely assure that if the payload reached the data layer, than we have a case of SQL Injection, and there is no need to execute it)

  • During this phase both AppSEC teams are busy analyzing the results and tweaking the technology so that by the end of the engagement a fully automated solution (covering both BlackBox and WhiteBox). The two teams have very different roles
    • Team 1 is doing the security engagement and is staffed by AppSEC security consultants (not necessary the most senior, experienced and knowledgeable security)
    • Team 2 is creating (when required) the custom tools or connectors which are then consumed by Team 1 (this is where AppSEC most experienced security consultants and developers exist, and their scope is only to provide expert security analysis and technology customization (for example in this project Application XYZ used a custom MVC View technology which had to be converted using WALA into a format that could be consumed by AppScan Source Edition)
  • Throughout the engagement, when security issues (i.e. findings) are discovered, the following workflow is executed:
    • Identify the issue on the source code (i.e code trace) and visualize it
    • Identify how the the issue can be exploited (i.e. sequence of pages (URL & parameters) required to deliver the payload)
    • Consolidation of issues into ‘security patterns’ (so that similar issues are reported & visualized together using AppScan Source Edition and AppScan Reporting Console )
    • Creation of multiple unit test that accurately replicate the issue reported using AppScan Tester Edition. Due to the complexity of the source (i.e. payload) to sink (i.e vulnerable function) path, the following unit tests are created in AppScan Tester edition
      • External test (ala BlackBox)
      • When relevant: one Internal test per application layer. For example :
        • Web Layer -> Validation Layer
        • Validation Layer- > Web Controllers Layer
        • Web Controllers Layer -> Web Services Layer
        • Web Services Layer -> Business Logic Layer
        • Business Logic Layer -> Data Access Layer (DAL)
        • Data Access Layer -> Database
      • One complete internal Unit item that covers the entire path:
        • Web Layer -> Validation Layer - > Web Controllers Layer -> Web Services Layer -> Business Logic Layer -> Data Access Layer (DAL) -> Database
      • NOTE: the unit tests created must be designed so that they fail when the application is vulnerable and pass when the vulnerability has been correctly remediated
    • Provide detailed remediation assistance and solutions on how to fix the problem:
      • If the source code is available, figure out the best location in the code (or configuration files) to mitigate / solve the issue and use Rational Software Analyzer to write ‘auto-fix’ code samples (which can be used by the developers on its IDE)
      • If the source code is not available write virtual binary patches (.NET or Java)
      • When possible, write WAF rules that prevent its exploitation.
    • Map the security implications of the issue reported to its business implications, rate it using the client’s Risk classification criteria and publish the data into AppScan Reporting Console, Rational Dashboard and Rational Insight (who will provide management reporting and Business Intelligence analysis to the multiple layers Application XYZ’s client contacts)
  • Once the assessment is completed, the AppSEC team packages all material created to into Rational Quality Manager, Rational Test Lab Manager and AppScan Enterprise (who between them will be used to automate the Exploitation of the Findings reported and the Unit tests for the developers (which allow them to replicate those issues and track its remediation)). This is the 'One-Click Button' that everybody wants (i.e. the button that can be used by non-security experts)
    • Due to the sensitive nature of the materials created and distributed, Rational Team Concert collaboration environment was used as a content distribution hub. This ensured that the client’s ‘sensitive data retention, encryption and usage’ policies were enforced
  • Over the next couple months, a number of meetings, presentations and training sessions occured between AppSEC consultants and Application XYZ staff (managed via Rational Project Conductor and Rational Requirement Composer) in order to ensure maximum knowledge transfer and capabilities enablement
In addition to the tools and technologies mentioned above, in order to solve particular technical challenges that occurred during the engagement, the following IBM products or research tools were used:
See also:


Posted by at
Labels: ,