Security Requirements for the Development Team

In my last post, “Security Training for the Development Team,” I shared the experience of building a security training program for the development team. 

Today, I will cover another essential step of securing engineering: security requirements. After reading this blog, I hope you will have a better understanding and be able to improve your security processes by implementing the additional requirements you’ll find here from the beginning of the product engineering phase. 

Understanding a system’s security and privacy requirements is critical to building a secure system. Therefore, security requirements must be updated regularly to reflect current requirements and the constant threat of landscape changes. Security requirements should also be defined along with the functional requirements, as this will help the design team to create a better system that can both cover these requirements and build a new security culture and mindset. 

Below, we will discuss an agile development environment and how security requirements can be captured and tracked in different ways.

1. Security Epics And User Stories 

A team can track security requirements similar to the functional and feature requirements in the form of epics and user stories. 

Epics and user stories can document and track business-related security requirements like security requirements for policy/compliance, legal, contractual and regulatory requirements, or system functionalities, design levels like multi-factor authentication, logging, and tracing. These can be prioritized alongside other epics and user stories. 

Security epics and user stories ensure security requirements are considered from the beginning, making the team fully aware of these requirements. The team can also tag these epics and user stories by tracking them separately across a security board. 

2. Security Tasks

In addition to epics and user stories, a team can also track security requirements as part of the security tasks. Security tasks are more suitable for granular or implementation levels, for example, when a task is used to implement data encryption while capturing and storing PII data. 

Security tasks ensure that security is not missed while implementing business features and functionalities. 

3. Security Debt

Security tasks can also be captured and tracked through a function called security debt. Debt is those tasks that cannot be properly implemented because of the prioritization part of this list. 

But as with technical debt, a team should be cautious when tracking security debt, as this can grow rapidly and become a significant risk if it is not taken care of within a reasonable time. 

4. Operational Security Tasks 

The team can also capture and track operational-related security tasks as part of their operational security tasks. 

These tasks are typically not related to security requirements, meaning they are operational. Examples could include updating the development environment regularly, updating open-source libraries regularly (at least before each major release), resolving issues reported by SAST, etc.

5. Specialized Security Tasks

The engineering team can implement all of the above without any significant help from the security team. 

But there are a few tasks that require a deep understanding of security. These can be captured and tracked through specialized security tasks such as the performance of threat modeling, PEN testing, environment hardening, etc.