Security has always been an afterthought for agile teams. One of the common premise agile teams neglect Security is because it is not an explicit part of the common agile framework. Security requirements are mostly discussed and identified during the discovery or high-level planning phase and tested at the end, leaving a vacuum during the process. This blog provides few ideas for Product Manager to help to adapt DevSecOps
Capturing Security features
Accentuating security needs in an Epic or a User Story has never been practiced as they are considered implicit requirements unless it, they are very specific needs like Single-Sign-On integration. Engineering teams cannot silently take care of security without product owners explicitly motivating and requiring security features. Security may remain invisible and intangible.
Explicit security requirements
Product Owner should articulate clearly “Why” security is of high importance in protecting Data, Systems, and People. Capturing the security requirements is a little challenging as we are not used to it. Some of the techniques that would help us start are as follows
Security Personas and Anti-Personas
Defining personas who try to break the system will help the team to understand the mindset. For example, defining personas like Hacker, Malware developer, organized criminal gang will help to understand the motive and incentive that would trigger to break the system
Attacker or Evil User Stories
Next logical progression would be to think like an attacker and create some high-level stories that would help the engineering team to address the security requirements. Example “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.” Source
SAFECode Security Stories
SAFECode, the Software Assurance Forum for Excellence in Code, is an industry group made up of vendors like Adobe, Oracle, and Microsoft which provides guidance on software security and assurance. SAFECode provides Security Stories covering CWE/SANS Top 25 Most Dangerous Development Error List and OWASP Top 10 list. Product Owner can take advantage this list.
Threat Modeling is an interesting modeling technique that the product owner can take the help of security professionals and engineering team to identify the trust boundaries and system vulnerabilities and create stories for the team
Using Definition of Done or Acceptance Criteria
Another way to list security verification criteria is by using Acceptance Criteria as part of User Stories. Good start for the web application is by using the OWASP Application Security Verification Standard (ASVS) checklist.
Hari G, serves as CIO for TaUB Solutions and Heads Agile and DevOps Practice. He has 18+ for IT experience and works on spreading the best practices of Agile and DevOps. He can reach him and say hi @tweetofhari and firstname.lastname@example.org