Security Requirements – are they different from other requirements?

As a security professional, I may have a heightened sense of awareness to the challenges that can result from not defining security requirements in a solution or product from the start. This is why I commonly describe security as everyone’s job to some extent, not just a responsibility within the security group of an organization. it is most important for an organization to prepare for and define possible security related events as a solution or product is in development and more specifically, as the requirements are being defined. It is a common mistake to assume these will be added on at a later date.

Security requirements may not be like those features requested by your customer and to formally define it, they must be actionable, measurable, and testable. But Security requirements are different from other requirements in that they are specifically based on mitigating threats such as those defined in the threat model. Security requirements should also be defined by what the corporate policy states within an organization and/or the classification of information processed by the solution or product.

As I described in one of my previous blogs - How and why to integrate security into the development of a solution or product, one important task for increased security is to create a threat model. The threat model is a task that allows a team to consider the current requirements and start predicting why and how a threat agent (who) would try to compromise the confidentiality, availability and integrity of the data and the application based on the data access control that should be enforced. Once a threat model has been completed, define the security objectives which may evolve throughout the development of the product. These security objectives can also describe what the solution will not do as a security non-goal, thus allowing the development team to finalize on the security requirements that are part of security objectives.

It should be considered an expectation that changes will take place during the product development lifecycle. The threat model and security objectives/requirements can be updated throughout the lifecycle so that as changes are approved for the current or next iteration, those changes are properly evaluated for security related risks and properly mitigated if deemed necessary. This phased approach also allows for an overall security strategy in consideration of communication flows and how each component may have different levels of access restrictions to create a security defense-in-depth strategy during the architecture and design phases.