How to Secure Agile Software Development

Whether you’re recovering from a recent attack, or trying to pro-actively improve your security, all organisations can benefit from improved agile development practices.

Whether you’re recovering from a recent attack, or trying to pro-actively improve your security, all organisations can benefit from improved agile development practices. To help you secure your next software development project, we’ve outlined the basic principles of effective application security in an agile environment.

Start with Pre-Development Security Planning

Most modern software development practices prioritise rapid development, effective code and developer flexibility above all else. This is never more evident than in the Agile methodology – with security in particular taking a backseat during the development process.In order to secure your Agile developments, it’s essential to begin by defining a basic security plan. Despite seeming counter to Agile’s flexible ethos, doing so will free-up time and resources during the development process, and empower developers to respond to emerging security issues quickly and effectively.

  • Outline the basic security framework the development process needs to follow and comply with – usually an organisation’s security policy, and any relevant privacy and compliance policies.
  • Choose the security tools and resources that the development team will be using.
  • Ensure that all developers have a suitable level of security training, and outline any suitable resources developers should consult during development.
  • Use Application Threat Modelling to identify major security threats, determine their risk and potential impact, and prioritise initial security actions.
  • Define potential misuse and abuse cases, for example users being able to alter the number of products in their shopping basket.

Get into the Habit of Iterative Testing

Agile development is defined by ongoing, iterative development. Unfortunately, without defined handoffs between development stages, it can be extremely difficult to keep track of changes to the software, and model their implications for application security.As a result, security testing has to be done continuously, with software subject to multiple rounds of tiered security testing. Whilst the exact frequency of each conducted test will vary with available time and resources, and the scale of each individual change, each test needs to be conducted at some point during development.Ongoing Threat Modelling (High Frequency). After an initial threat modelling session, it’s important to continually re-evaluate the relationship between software changes, and new and existing security threats. In order to manage this on a continual basis, it’s a good idea to adopt a relatively informal process after the initial modelling session, and update your threat analysis on a weekly to bi-weekly timescale.Static Software Testing (High Frequency). Static security testing offers a simple, effective and resource-friendly way of obtaining feedback from changes to software code. Thanks to its extremely low implementation costs, static testing can be conducted after all development iterations, allowing developers to uncover bugs, vulnerabilities and errors as quickly as possible.Misuse and Abuse Case Testing (Moderate Frequency). Misuse and Abuse cases should be analysed on an individual basis, and testing prioritised according to the business risk posed by each. In the event of development changes that may impact these risks, it’s wise to retest.Penetration Testing (Low Frequency). Pen testing is a time and resource intensive process, and doesn’t need to be conducted in response to every software iteration. Instead, penetration testing should be viewed as an audit of both your software’s functionality and your previous security tests. Conduct an initial baseline penetration test when the software has a working level of functionality, and re-conduct after major software overhauls.External Testing (Low Frequency). Developer testing is a crucial tool for securing agile developments, but it isn’t without its own flaws. Developers are understandably bad at testing their own code, often seeking to prove its functionality, and stopping short of truly adversarial and exploratory testing. External testers will be able to analyse your software as thoroughly as possible, simulating the malicious intent of a hacker. Whilst the costs of external testing are high, the benefits may be even higher; making it a worthwhile expense towards the end-stages of development.

Let Experienced Developers Address High-Risk Issues

The ‘whole team’ ethos of agile development offers myriad benefits to creativity, responsiveness and peer review. However, security problems have the potential to incur serious costs and damages to an organisation. The most security-sensitive parts of the system – like encryption and session management – need to be developed and analysed by experienced developers with a proven understanding of security practices.Despite being overseen by a specialist, secure agile development still relies on the entire development team being proactive, vigilant to security issues and eager to learn from security mistakes. Serious problems should be reviewed by the entire team, in order to understand why the security issue emerged, and how it can be prevented from emerging in future software development projects.

Take Small Steps Towards Security

Many organisations choose to incorporate ‘security sprints’ into their development process – short periods of intense security review and analysis. This allows the development team to commit their full time and attention to security testing, and achieve a thorough analysis in an extremely resource-friendly way. An even simpler solution is to start with the easiest and cheapest security tests at your disposal; allowing the development team to commit resources and gain security experience in a gradual and effective way.Both approaches encourage developers to start thinking about software security, and incorporating its principles into their development. These small steps are the building blocks for a secure culture – an atmosphere which encourages developers to live and breathe application security, and helps them to incorporate it naturally into everything they develop.

Get Switched on

Subscribe to our newsletter to keep ahead in the industry, and be the first to access new reports and white papers.