Creating system and security requirements
Defining clear system and security requirements makes sure a capability delivers its mission securely in line with its risk appetite.
System and security requirements should also be created based on your initial risk assessment.
Security controls are how you achieve the security requirements. Detailing functional and non-functional requirements (NFRs) will help you achieve this.
Functional requirements describe what the system should do, focusing on specific actions or behaviours. For example: ‘The system shall verify the strength of user-chosen passwords and prevent the use of weak passwords.’
NFRs describe how the system performs its functions. For example, ‘Passwords shall be protected from unauthorised access, both during storage and transmission.’
It is important to remember that security requirements cannot be considered separately from key user requirements (KURs), user requirements and system requirements.
Often, security requirements will flow directly from KURs as changing a capability will change the risks.
System and security requirements should also be created based on your initial risk assessment.
Security controls are how you achieve the security requirements. Detailing functional and non-functional requirements (NFRs) will help you achieve this.
Functional requirements describe what the system should do, focusing on specific actions or behaviours. For example: ‘The system shall verify the strength of user-chosen passwords and prevent the use of weak passwords.’
NFRs describe how the system performs its functions. For example, ‘Passwords shall be protected from unauthorised access, both during storage and transmission.’
It is important to remember that security requirements cannot be considered separately from key user requirements (KURs), user requirements and system requirements.
Often, security requirements will flow directly from KURs as changing a capability will change the risks.
Benefits
The benefits of creating security and systems requirements are:
- bridges the gap between the identified risks and the controls which should be implemented
- clearer and more concise requirements, making them easier to understand, implement, and track
- avoids requirement creep when defined and agreed early on
- flexibility in choosing appropriate security controls (different options might be able to achieve the same outcome)
- testing and verification can be based on system and security requirements
- cheaper and more effective systems when security requirements are identified early
Outcomes
Your outcomes will include:
- statements of what the system is intended to achieve and how this supports mission functions
- measurable and testable system requirements, for example, functional, non-functional, data requirements)
- security requirements that can be managed and tracked
- statements of security engineering required to deliver the mission securely and proportionately, informing control identification
- make sure all stakeholders understand and work to the same strategic outcomes
Responsibility
Who is responsible:
- delivery team lead
- project management office (PMO)
- capability sponsor
- delivery team security lead
When to carry out security working groups
You should create your requirements:
- at concept and assessment stages
- tracked and managed through-life
- in response to testing and validation