Embedding Security in the Agile Product Development

Editor's note: Throughout Cybersecurity Awareness Month in October, the ISACA Now blog will publish new posts on hot security topics each week. For additional ISACA cybersecurity resources, visit our Cybersecurity Awareness Month page.

Outline security requirements at the beginning of the project, review the design to check if the requirements have been incorporated and perform security testing before go-live. If this sounds familiar, it should. Many companies manage their projects using the waterfall method, where predefined “gates” have to be cleared before the initiative can move forward. The decision can be made at certain checkpoints to not proceed further, accepting the sunk costs if benefits now seem unlikely to be realized.

This approach works really well in structured environments with clear objectives and limited uncertainty, and I have seen great things delivered using this method. There are many positives from the security point of view, too: the security team gets involved as they will normally have to provide their sign-off at certain stage gates, so it’s in the project manager’s interest to engage them early to avoid delays down the line. Additionally, the security team’s output and methodology are often well-defined, so there are no surprises from both sides and it’s easier to scale.

If overall requirements are less clear, however, or you are constantly iterating to learn more about your stakeholders’ needs to progressively elaborate on the requirements, to validate and perhaps even pivot from the initial hypothesis, then more agile project management methodologies are likely preferable.

Embedding security in the agile development is less established and there is more than one way of doing it. When discussing security in start-ups and other companies that adopt agile approaches, I see a lot of focus on automating security tests and educating developers on secure software development. Although these initiatives have their merits, it’s not the whole story. Security specialists need to have the bigger picture in mind and work with product teams to not only prevent vulnerabilities in code, but influence the overall product strategy, striving toward security and privacy by design. 

Adding security features and reviewing and refining existing requirements to make the product more secure is a step in the right direction. To do this effectively, developing relationships with the development and product teams is paramount. The product owner especially should be your best friend, as you often have to persuade him or her to include your security requirements and user stories in sprints. Remember, as a security specialist, you are only one of the stakeholders that product owners have to manage and there might be a lot of competing requirements. Besides, there is a limited amount of functionality the development team can deliver each sprint, so articulating the value and importance of your suggestions becomes an essential skill.

Few people notice security until it’s missing, at which point it’s usually too late. We see this time and time again when organizations of various sizes are grappling with data breaches and security incidents. It’s your job as a security specialist to articulate the importance of prioritizing security improvements early in the project to mitigate the potential rework and negative impact in the future.

Security recommendations are often communicated in a form of user stories. For example, ”Customer personal data should be stored securely” or “As a registered user, I would like to access my sensitive information (that is stored securely) through a secure communication channel so that I can perform authorized actions.” Although every organization’s way of working is different, try to be as specific as possible, mentioning specific technologies and protocols, if required.

When writing security user stories, you should try to elaborate as much as possible on the problem you are trying to solve, what value it will provide, if solved, and the acceptance criteria. The acceptance criteria will often include detailed security requirements (for example from OWASP ASVS, if you are working on a mobile or web application).

If you are following Scrum or a similar methodology, it’s important that the security team is involved in sprint planning to contribute to the estimates and help the product owner with prioritization. Other team meetings, like backlog refinement and daily stand-ups, are also worthwhile to attend to be able to clarify your requirements (including value, risk, due dates and dependencies) and help remove security-related impediments.

A culture of collaboration between teams is essential for the agile approach to be effective. Treating security as not something to work around but as a value-adding product feature is the mindset product and engineering teams should adopt. However, it’s up to security specialists to recognize the wider context in which they operate and accept the fact that security is just one of the requirements the team needs to consider. If the business can’t generate revenue because crucial features that customers demand are missing, it’s little consolation that security vulnerabilities have been addressed. After all, it’s great to have a secure product, but less so when nobody is using it.