Agile principles have been adopted by most business as best practice in attempts to produce cost effective software quickly.  With the tremendous amount of cybercrime in the world today producing secure applications is absolutely critical to your business.  Bringing security to the Agile principles then is a must in developing secure software.  In this article we will discuss pentesting when you are Agile.

Agile is a set of principles which help teams remain agile throughout production by micro focusing on all aspects of the applications development lifecycle.  In order to be able to construct a secure application using the agile principles, security must be considered & incorporated in conjunction with the principles.  The easiest way in accomplishing a more secure application while being agile is to make security a high priority early on.  By doing so your agile principles reflect security, which ensures security measures are considered through each phase of your application.  One great suggestion from  OWASP is to create stories based around risk and security.

“create an evil user stories in your backlog.

Example #1. As a hacker, I can send bad data in URLs, so I can access data and functions for which I’m not authorized.

Example #2. As a hacker, I can send bad data in the content of requests, so I can access data and functions for which I’m not authorized.

Example #3. As a hacker, I can send bad data in HTTP headers, so I can access data and functions for which I’m not authorized.

Example #4. As a hacker, I can read and even modify all data that is input and output by your application.”

These types of user stories are used by Agile team members to plan and develop the application, which helps ensure security is considered throughout development. Remember at the core of the Agile principles is flexibility.  This flexibility is what allows for rapid movement along your project.  If an input field has been added during a phase of your application, have the flexibility to perform some added security testing.  Have your developers take proactive measure and perform simple fuzz testing to help validate proper data handling in the input field.  By having the developers perform some simple security testing, and holding them accountable for secure design the project will benefit by having more security early on which equates to less time being spent fixing issues later in the development lifecycle.

Congratulations you have made it to the end of a sprint, performed code review, and now your application has moved to the validation phase of your secure development lifecycle!  It is now time to perform a penetration test.  During the penetration test, a wide variety of tools and techniques are harnessed by experts to dynamically measure the applications potential weaknesses.  These weaknesses, if left unfixed, could be exploited by real world attackers to compromise your applications.  Depending on the severity of a potential weakness found in an application the vulnerability could provide a foothold in your network for an attack.  Potentially this vector could allow for an attacker to pivot through your network, compromising more data than what is contained in the application itself, which is near worst case scenario.  Due to these terrible outcomes, it is absolutely critical you perform penetration testing in your applications development lifecycle today.

The results from the penetration test should then be reviewed by the developers whom now are being assisted by the penetration tester to fully understand the issues, and work to resolve the findings.  After appropriate changes have been made to fix the findings from the first pentest, a second test should be conducted to verify risks are not present prior to the deployment of the application.

Your security can be as Agile as your software development if you highlight security as a point of interest at the beginning of your projects.  Embrace a secure development lifecycle, as well as the flexibility to change in both development, and security.  Ensure application risk is minimal by reducing attack surface area, remember each feature you add creates additional risk. Test, test, and retest your application until it meets all needs. If you have said “Hey this thing needs to be secure” then security is a point which your teams must address prior to satisfying a sprint.