Case Study: 10 Steps to Agile Development without Compromising Enterprise Security

Schedule Speakers

Wednesday, November 20 • 12:00 pm - 12:50 pm

Case Study: 10 Steps to Agile Development without Compromising Enterprise Security

In an Agile, fast­paced environment with frequent and multiple product releases, security code reviews & testing is usually considered to be a delaying factor that conflicts with success.
Is it possible to keep up with the high­end demands of continuous integration and deployment without abandoning security best practices?

When we started this journey, we were seeking for a way to reduce the friction, risk and cost driven from identifying vulnerabilities in Production. After a long way and with many lessons learned, we have successfully added an in­depth security coverage to more than 20 SCRUMS (up to 1 MLOC), and are happy to share our insights, tips and experience.

LivePerson is a provider of SaaS based technology for real­time interaction between customers and online businesses. Over 1.5 billion web­visitors are monitored by the platform on a monthly basis. The R&D includes hundreds of developers who have adopted Agile and Scrum­based methods, closely tied with our Secure Software Development Lifecycle.

Our Secure Software Development Lifecycle:
In order to achieve best results and reduce friction, we have linked the SSDLC to the standard SCRUM process, and added a security coverage for each phase, as briefly outlined below:

Post Release Planning – Security High Level Design.
As soon as a Release is planned, a High Level Security Design is performed by the Security team together with the Group Leaders/Software Architects. This phase outlines the agreed security standards. We define the Logical Security flows and ensure that security best practices are enforced and complaint/regulations aspects.

Sprint Planning – On Demand Security Q&A
While the Sprint is being planned, some questions arise and require a response from a security specialist, for example: which validator should we use? What is the best encoder for this output? How shall we implement encryption?

Coding – ESAPI and SCA on build at CI.
The release version control system submits each build to a Static Code Analysis, where among other things, the correct usage of LivePerson ESAPI implementation is enforced.

Code Freeze – Manual CR
During “Code Freeze”, the Security Team partners with the developers to do Code Review in the submitted commits, to detect and prevent errors which might be missed by the Static Code Analysis process.
QA – Regression Test – Automated Security Test
Using a specific plugin to do automating testing we send the different inputs to automatic Security Testing, using BURP as our platform.

Release – External Pentest
Before every major release, an external, independent security pentest is executed by a 3rd party vendor to help detect any potential problems that might had been missed by the process.

Tools to help
Continuous integration Plugins

We created some plugins to get information from our Continuous Integration environment, to get alerts and real time intelligence of the compliance status of the projects.

Static Code analysis.
We created a plugin on our CI process to add the our Static Code Analysis as a Maven Step. In case there is a Medium or High Vulnerability in this process, the build fails. Further, before the release step and Puppet creation, a final scan is run where no findings should exist.

Vulnerability Scanning plugin.
URL’s with all the Parameters are generated, so an automated Vulnerability scanning could be conducted.

Esapi Package.
We created an ESAPI package available in our local MAVEN repository, making the implementation of the accepted Validators, CSRF guard, Standard Encoders, logging and Encryption methods straightforward, ensuring that all the projects use our Framework.

Key success Factors.

1) Be part of the process
2) Enforce the policy by using a security package API (we use ESAPI) in each product
3) Integrate SCA to put controls in the native process of coding,
4) Use automation to collaborate with the security dynamic test
5) Allow customers to run a pen­test and work as a community to succeed.
6) Engage Tech Leaders as security Champions by showing them the value of security
7) Train developers on a regular basis.
8) Create a security knowledge base and discussions around security – for developers.
9) Break the build if the SCA or automated Pen­Test finds any Medium or High vulnerabilities. 10) Start with a pilot group of enthusiastic individuals, replicate with the experiences learnt.

Conclusions.
Using this process, we have successfully added an in­depth security coverage to 22 SCRUMS, which are responsible for medium to large sized projects (up to 1 MLOC), thus reducing the general risk. The amount of vulnerabilities we had found on production for our releases is lower

than with our previous process, thus reducing the cost of Security Development and patching. We managed to actively encourage developers to connect and work with us as a unified team rather than conflicting teams. If you work with the security team from early stages, the probability of having a failed build due to security issue is significantly lower.

References.
OWASP ESAPI https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API Writing Secure Code, Second Edition, Michael Howard and David LeBlanc, Microsoft Press The Burp Suite http://portswigger.net/burp/
OWASP Developer Guide http://ignum.dl.sourceforge.net/project/owasp/Guide/2.0.1/OWASPGuide2.0.1.pdf 

Speaker:
Yair Rovek

A technical information security specialist with more than 25 years of experience and strong knowledge in Network and Web Applications.

Head of SSDLC program at Liveperson's R&D center in Israel, responsible for the implementation and lifecycle of the Secure Development methodologies within all development units including R&D and QA. In addition responsible for usage and use of new security technologies for further improvement in the organisation. Prior to that, he has served at the Israeli Air Force for more than 20 years, handling network and application security.

See more of: Presentations
www.appsecusa.org
<< Previous Presentation | Next Presentation >>