DevSecOps for Product Manager

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

Reference

• User personas for privacy and security
• A methodology of developing Attacker Personas

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.

SAFECode:Practical Security Stories and Security Tasks for Agile Development Environments

Threat Modeling

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

GOTO 2017 • Adaptive Threat Modelling • Aaron Bedra

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.

OWASP Application Security Verification Standard v3.0

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 hari@wordpress-129153-2119642.cloudwaysapps.com