How does Agile overcome common software security challenges?
Paradoxically, security is a negative goal. To secure something, you must understand how insecure it is. Start by trying to break it or by figuring out how other people might break it. The same is true of software. For example, a simple user input field on a mobile or web app may require the user to enter their name or phone number. The coding is simple in this case. However, illicit input to these fields in the form of non-alphanumeric characters (such as symbols and certain sequences of characters) can render a poorly-written app useless—making it crash. This can reveal information allowing an attacker to further penetrate the app or website.
Utilizing an Agile SDLC can optimize your practices to overcome common software security challenges. Here are three elements to include in your current Agile process to ensure your life cycle is building security in.
Consider the potential negative consequences
To secure the app, security teams need to think of the potential negative consequences that could arise from entering illicit or invalid data into a user-input field, and what that input could be. There are many negative consequences to incorrect data entered into a user-input field. This can include the software crashing, or far worse, the attacker gaining privileges allowing them to take over the software.
The good news is that there are many measures against such attack scenarios to prevent the negative consequences. There is negativity involved when considering the potential attacks and the work required to design and build countermeasures. The extra planning lengthens the overall development and testing time of the app. This, in turn, is even more negativity to think about!
We can’t ignore software security and the negative potential associated with it. Go against the grain. Embrace the negativity.
Emphasize user experience
Designing and building software using the Agile methodology places great emphasis on the user experience. The principle of user stories allows development teams to see how the app is used, what it does, and above all, get a feel for the user experience. Knowing the user experience helps to determine the code that goes into the app to make that user experience a reality.
It is also important to consider the user’s security experience as well. A well-designed user interface and user experience are pivotal. But, also consider the non-functional aspects working behind the scenes to ensure security.
Introduce security user stories
Security isn’t easy. It’s not meant to be. However, there is an opportunity to build security into software during the design and build phases of the Agile life cycle. Facilitate this process by introducing security user stories.
Security user stories explore how to build the security requirements into software developed in Agile that also consider the user experience from the security perspective. Security user stories, just like regular user stories, are applied and used according to context, priority, and value (also known as story points) for each, particularly in a security scenario.
Typically, a software development team focuses on features and functions brought about by requirements or user stories, but with less or no regard for security. In the Agile development environment, these features and functions are demonstrated to stakeholders, sponsors, and business owners at the end of a sprint. The security of the app however, unless specifically demanded, is not demonstrated to anyone, including the security stakeholders. All members of an Agile team can take on additional security roles by working with security user stories.
The security user story is a specific vulnerability that will match one or more functional user stories according to its purpose. As an example, if a website that uses a database is being built, then a security user story that specifies input sanitization to remove SQL injection threats would be appropriate.
How would scrum teams work with the security user story? Scrum leaders, product owners, and the development team can all work with security through such tasks as follows: the product owner can groom the (security) user story backlog through aligning them with functional user stories. Additionally, working with the development team to ensure they have prioritized and valued the security user stories properly. The scrum leader can work with the product owner and team to do many things. But, one very important function is to reject requests form stakeholders for new functionality to be put in a sprint, unless of course there is room for the accompanying security user stories.
-Stephen M. Dye, Secure Agile Development: 25 Security User Stories for Agile Development
Creating security user stories from scratch can create extra work for development teams and product owners. With the obvious need for security, the effort involved in creating security user stories can be reduced by using pre-written security user stories and applying only those which are relevant to the particular application. Pre-written security user stories also allow developers to quickly understand what security measures they have to add to the code for each functional user story they develop.
Summing it up
While security presents a negative goal, being defensive in an agile way promotes a stronger security stance within your organization. Overcome common software security challenges by building security into the development process. Using pre-written security user stories reduces the time and effort involved in building security into a product developed using Agile.
