Computers, Programming, Technology, Music, Literature

Leveraging Open Source for Continuous Application Security at Agile Continuous Integration and Continuous Delivery environments

leave a comment »

 

This post is an abstract of my submission to nullcon 2015.

 

With more and more web applications enabling us to converse, communicate, conspire, collaborate, contribute, capture, compute, credit, conjure, and even keeping us content; more and more trivially insecure vulnerabilities are left to be exploited. With development teams always confronted with deliverables and ever faster imminent deadlines, they always see penetration testers as blockers because when a developed application is penetrated and vulnerabilities are identified the effort to fix them surges and it just would have been downright child’s play, had those bugs been identified early in development cycle when features of the application were being built and tested. As deployment dates near, most raised security bugs still remain raised, the critical and some lucky high risk bugs are fixed, but stakeholders accept medium and low risk bugs as technical debt, our vulnerable application meets the world wild web.

The early feedback cycles introduced by Continuous Integration systems have proven that when software development teams are faced with bugs, and build failures, they have always stepped up with early fixes. In the same way a system with Continuous Security aims at a transparent security governance of application development, making security visible at all levels – development, quality, compliance. As ‘tools in the market can’t oust human intelligence at penetration tests’ stands as an immutable fact ‘tools are used to automate and identify recurring and routine security bugs and complement manual audits’ also stands true. Sure, there are security wary development firms that use penetration testing tools, part of their development cycles. However, there hasn’t been a rapid adoption of automated tools in the rapid and agile application development processes. The primary answer could be cost, time, effort, lack of security awareness, fear of introducing more bugs trying to fix an existing bug, habit of responding to latest threats instead of proactive measures. Even some of the free and open source offerings lack support, active development community, documentation, usability, scripting support.

Bugs are something that frightens every developer and tester. Working with development teams of various sizes it is evident that the earlier the bugs are identified the easier they are to fix. While the proposed idea might look familiar or said before or may be even some of the organizations have expensive tools deployed to identify bugs every night, they are no extra steps taken to get a developer’s attention. Nothing could be more embarrassing for a developer to have broken a build and notified about the bugs. Getting a developer’s attention with build notifications and failures, getting the identified bugs fixed, keeping the source control free of the common security vulnerabilities at the cost of free and open source software with a generic platform agnostic approach is different and innovative about this paper. Also the sample source that accompanies this abstract would help many needy security analysts and developers to understand how Continuous Application Security could be done, and actually implement Continuous Application Security for their web applications.

This paper proposes a generic framework/approach with open source options to integrate vulnerability analysis as a daily chore during web application development and maintenance. The fundamental idea is to integrate a custom pipeline build script or use the boilerplate code accompanying this paper into the build system; the custom pipeline build script henceforth referred to as the CPBS. Based on the vulnerabilities found the CPBS would update the build system for success or failure. Conditional action should be taken to keep the new checked in code into the version control system or discard it or to stop a production deployment for continuous integration or continuous deployment setup respectively.  The CPBS sequence follows a work-flow of starting our security tools on a port to listen; attempts a health check on the website Url and keep polling until the website services are up; excludes urls that destroy active sessions; if a functional test suite is available, monitors and waits for the functional tests to complete; lets the security tool analyze the traffic and sense vulnerabilities based on passive scanning; starts a webdriver script to create an active session for the application; apart from the urls obtained while the functional tests were running, fires up the spiders to crawl for more resources; sets the desired scan policies and starts the scan; sends success or failure code based on the results.

Embracing automated functional tests within the Vulnerability Analysis process, handling authenticated resources and login protected websites, handling intensive client side scripts with JSON or single page web applications, handling CSRF tokens, handling iterative and incremental scans, false positive management, promoting security culture and governance in the organization, managing identified bugs in tracking systems, keeping the code in version control systems free of security bugs are some of the key areas of focus.

Advertisements

Written by gmaran23

July 16, 2015 at 1:56 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: