Eliciting Security Requirements

1. Security Requirements
 - What the system should NOT be able to do
 - Should be explicitly stated so that these requirements can be tested as often as possible
 - Constraints on the functions of the system, where the constraints operationalise one or more security goals (integrity, confidentiality etc)
  e.g. Transactions involving personal health information must be logged

http://www.opensecurityarchitecture.org/cms/definitions/it_security_requirements

2. Elicitation Methods and Techniques
 - Techniques: Misuse / Abuse Cases, Attack Trees
 - Processes: SQUARE, SREP etc

3. Misuse Cases
 : Tool for helping to think about software the same way attackers do
 - Building Misuse Cases
  1) Start from a normal use case model
  2) Identify actors (attackers / misusers)
  3) Identify the Misuse cases
  4) Identify threaten relationships between use cases and misuse cases
   * Threaten: The use case is exploited or hindered by the misuse case
   * Mitigate: The use case is a countermeasure against a misuse case
  5) Identify security use cases a.k.a security requirements

http://searchsoftwarequality.techtarget.com/tip/Threat-modeling-enhanced-with-misuse-cases

4. Attack Trees
 - Used for threat modelling, security requirements elicitation
 - Root of the tree represents the attack goal
 - Building Attack Trees
  1) Identify top level attacks against the system
  2) Brainstorm for different ways these attack can be achieved

https://www.isograph.com/software/attacktree/

!! Think about the strength of Misuse Case and Attack Tree, do we need both for eliciting security requirements?

Misuse Cases	- drill down to the details of the interactions between system components in the event of attack
Attack Trees	- enable the requirements team to have a complete set of misuse cases  - provide a general picture of potential attacks on a system
As a result, mapping Attack trees to Misuse Cases provides a useful sanity check => Two independent teams work in parallel

5. SQUARE (Security QUAlity Requirements Engineering)
 : step-wise methodology for eliciting, categorising and prioritising security requirements

Steps	Objective
1. Agree on Definitions	to agree on definitions between stakeholders and the requirements engineering team
2. Identify Security Goals	to identify, resolve and prioritise security goals   - Generate security goals, not requirements nor recommendations
3. Develop Artifacts	to collect a complete set of artefacts of the system   - Desirable artefacts to collect: System architecture diagram, Use / Misuse cases, Attack Trees etc
4. Perform Risk Assessment	to identify   - Vulnerabilities and threats that face the system   - Likelihood that threats will materialise as real attacks   - Potential consequences of an attack
5. Select Elicitation Technique	to select an elicitation technique and document the rationale for the choice
6. Elicit Security Requirements	to identify initial set of security requirements
7. Categorise Requirements	to allow requirements engineers and stakeholders to classify requirements
8. Prioritise Requirements	to choose which requirements to implement   - Essential / Conditional / Optional
9. Requirements Inspection	to find defects in the requirements

http://www.cert.org/cybersecurity-engineering/products-services/square.cfm?