Security Requirements: - Introduce What Are - Define What Are

Fundamentals of
Secure System Modelling

Springer, 2017
Chapter 4:
Security Requirements
Raimundas Matulevičius
University of Tartu, Estonia, rma@ut.ee
Goal
•  Introduce what are security criteria
•  Define what are security requirements
–  How they can be classified, specified and represented
2
Security Risk Management
Domain Model
Outline
•  Security criteria
•  Security requirements
–  Definition
–  Classification
–  Specification
–  Representation
•  Related (to Security) Requirements
–  Safety
–  Privacy by minimisation
4
Outline

–  Definition
–  Safety
Security Criterion
•  Property or constraint on business assets that characterises
their security needs
•  Act as indicators to assess the significance of a risk
v  Confidentiality – a property of being made not available or
disclosed to unauthorized individuals, entities or processes
v  Integrity – a property of safeguarding the accuracy and

completeness of assets
Ø  Accuracy could be threatened by (unauthorised or
undesirable) update or tampering
Ø  Completeness could be threatened using altering or deletion
v  Availability – a property of being accessible and usable

upon demand by an authorised entity 6
Security objective
•  Defined using security criteria on business assets
–  Confidentiality of the technical plans
–  Integrity of the structure calculation process
–  Availability of ticket booking service
Outline

–  Definition
–  Safety
8
What are requirements?
[Jackson 2001; Easterbrook, 2004]
What are requirements?

[Jackson 2001; Easterbrook, 2004]
•  Domain Properties:
–  things in the application domain that are true whether or not we ever build
the proposed system
•  Requirements:
–  things in the application domain that we wish to be made true by delivering
the proposed system
• Many of which will involve phenomena the machine has no access to
•  A Specification:
–  is a description of the behaviours that the program must have in order to
meet the requirements
10
• Can only be written in terms of shared phenomena!
Security requirement
•  Security requirement is a condition over the

phenomenon of the environment that we wish to make
true by installing the system in order to mitigate risks
11
•  A requirement defining what level of security is expected
from the system with respect to some type of threat or
malicious attack
•  what you require?
–  Different from the security objective (criterion)
•  not why it is needed?
–  Different from the choice of security controls (design)
•  not how to achieve it?
12
•  A requirement defining what level of security is expected
from the system with respect to some type of threat or
malicious attack
•  what you require?
–  Different from the security objective (criterion)
•  not why it is needed?
–  Different from the choice of security controls (design)
•  not how to achieve it?
•  Related concepts:
–  Security: malicious / Intended harm
–  Safety: accidental harm
–  Dependability: more general concept covering both safety, security and
several other concepts
•  Availability, reliability, robustness, survivability…
–  Privacy: sometimes considered as a subcategory of security, but sometimes
also in conflict 13
Objectives of
Security requirements
•  Ensure that users and applications
–  are identified and that their identities are properly
verified
–  can only access data and services for which they

have been properly authorised
•  Detect attempted intrusions by unauthorised persons

and applications
•  Enable security personnel to audit the status and usage

of the security mechanisms
14
[Firesmith, 2003]
Objectives of
•  Ensure that
–  unauthorized malicious programs do not infect the application
or component
–  communications and data are not intentionally corrupted
–  parties to interactions with the application or component cannot
later repudiate those interactions
–  confidential communications and data are kept private
–  applications survive attack
–  system (people and application) are protected against
destruction, damage, theft, or surreptitious replacement
–  system maintenance does not unintentionally disrupt the
security mechanisms
15
[Firesmith, 2003]
Outline
–  Definition

–  Safety
16
Taxonomy of
[Firesmith, 2003]
Identification requirements
Authentication requirements System maintenance security

requirements
Authorisation requirements Physical protection

requirements
Immunity requirements Survivability requirements
Integrity requirements Security auditing requirements
Intrusion detection Nonrepudiation requirements

requirements
Privacy requirements
17
Identity requirements
Extent
Authentication to which a system identify its
requirements System maintenance security
requirements
externals before interacting with them
requirements
Id.1: The ERIS shall identify Football
Immunity requirements Federation EmployeesSurvivability
before allowing them to
requirements
use its functions
Integrity requirements Id.2: The ERIS shallSecurity
identifyauditing
Team requirements
Representatives before allowing them to use its
Intrusion detection functions Nonrepudiation requirements
requirements Id.3: The Football Federation shall identify
Football Federation Employees before allowing
Privacy
them requirements
to enter
18
Authentication requirements
Extentrequirements
Identification to which a system shall verify the
identity of its externals before interacting with
Authentication requirements them System maintenance security
requirements
Authorisation requirements Authe1: The ERIS shallPhysical

verify protection
the identity of
requirements
Football Federation Employees before
Immunity requirements allowing them to useSurvivability
its functionsrequirements
Authe2: The ERIS shall verify the identity of
Integrity requirements Team Representatives before
Security allowing
auditing them
requirements
to use its functions.
Intrusion detection Authe3: The Football Federationrequirements
Nonrepudiation shall verify
requirements
the identity of Football Federation Employees
before
Privacy permitting them to enter.
requirements
19
Authorisation requirements
Specifies the access and usage privileges
of authenticated users
requirements

requirements
Autho1: The ERIS shall allow each Football
Immunity requirements
Federation Employee to obtain access to his
Survivability requirements
personal account information.
Autho2: The ERIS shall not allow Team
Representative to change the Game reports.
Intrusion detection Autho3: The ERIS Nonrepudiation
shall not allowrequirements
other
requirements external systems to change data
20
Authentication requirements Systemshall

Extent to which a system maintenance
protectsecurity
itself
requirements
from infection by unauthorised undesirable
Authorisation requirements programs Physical protection
requirements
Imm1: The ERIS shall protect itself
Survivability from
requirements
infection by scanning the entered data
Integrity requirements Security
Imm2: The ERIS shall auditing
notify the requirements
Administrator if malware is detected during a
requirements scan
21
Integrity requirements
Extent to which a system shall ensure that its

data and communications requirements
are not
intentionally corrupted via unauthorised
Authorisation requirements
creation, modification, orPhysical
deletionprotection
requirements

Inte1: The ERIS shall prevent unauthorised
corruption of emails sent to Team
Integrity requirements Representatives Security auditing requirements
Inte2: The ERIS shall prevent unauthorised
requirements corruption of data collected from Team
Representatives
22
Intrusion detection requirements
Extent to which a system shall detect and
Authentication requirements System maintenance
record attempted access security
or modification
requirements
by unauthorised individuals
requirements
Intr1: The ERIS shall detect attempted
Immunity requirements requirements
Survivability requirements.
accesses that fail identification
Intr2: The ERIS shall detect attempted
accesses that fail authentication
requirements.
requirements Intr3: The ERIS shall detect attempted
accesses that fail authorisation requirements.
23
Extent to which a Identification

system shall keep its
requirements
sensitive data and communications
private from unauthorised individuals andSystem maintenance security
Authentication requirements
programs requirements

Pr1: The ERIS shall not storerequirements
personal
information about the Football Federation
Immunity requirements Employee Survivability requirements
Pr2: The ERIS shall not allow unauthorised
individuals access to communications
Pr3: The ERIS shall not allow unauthorised
requirements programs access to communications
24
Nonrepudiation requirements
Extent to which
Authentication a system shall prevent a
requirements
party to one of its interactions from denying
having participated
Authorisation in all or part of the
requirements Physical protection
interaction requirements

NonR1: The ERIS shall store tamper-proof
records of the
Integrity following information about
requirements Security auditing requirements
each game: game information, umpires,
gameIntrusion
report,detection
and confirmation. Nonrepudiation requirements
requirements
25
Security auditing requirements
Extent to which a system shall enable
security personnel
Authentication to audit the status and
use of its security mechanisms requirements

Aud1: The ERIS shall collect the status of its requirements
security
Immunitymechanisms
requirementsevery Friday at 18:00 h. Survivability requirements
Aud2: The ERIS shall organize the status of
its security mechanisms every Saturday at
18:00 h.
Aud3: The ERIS
Intrusion shall summarise the status
detection Nonrepudiation requirements
requirements
of its security mechanisms every Sunday at
12:00 h.
26
Survivability requirements

requirements
Extent to which
Authorisation a system shall survive the
requirements Physical protection
intentional loss or destruction of its requirements
component
•  Sur1: The ERIS shall not have a single

point of failure.
requirements
27
Physical protection requirements
Extent to which a system shall protect itself
Authentication System maintenance security
from physicalrequirements
assault requirements

Phy1: The Football Federation shall protect requirements
its hardware components from physical
damage Survivability requirements
Phy2: The Football Federation shall protect
its hardware components from theft
Phy3: The Football Federation shall protect
its hardware components from surreptitious
requirements
replacement
28
System maintenance security requirements
Extent to which a system shall prevent
authorised modifications from accidentally
defeating its security mechanisms requirements

Main1: The ERIS shall not violate its security requirements
requirements as a result of updating data.
Main2: The ERIS shall not violate its security
requirements as a result of updating
hardware
Main3: The ERIS shall not violate its security
requirements as a result of the updating of a
requirements
software component
29
Taxonomy of
[Firesmith, 2003]

requirements

requirements

requirements
30
Taxonomy of
[Firesmith, 2003]

requirements

requirements

requirements
31
Outline
–  Definition

What are
–  Safety
criteria for writing good requirements?
32
Do not write like this
•  Ambiguity – or
–  The ERIS system shall also be able to generate visible or
audible caution or warning signal for the attention of security or
business analyst
•  Multiple requirements – and, or, with, also

–  The warning indicator shall light up when an ERIS intrusion is
detected and the current Football Federation Employees
workspace or Game report data shall be saved
[Alexander and Stevens, 2002] 33

•  Let-out clauses
if, when, except, unless, although, always
–  The fire alarm shall always be sounded when the smoke in
Football Federation building is detected, unless the alarm is being
tested when the antivirus is deployed
•  Long rumpling sentences
–  Provided that the designated Game report input signals from the
specified mobile devices are received in the correct order by the
way which the ERIS is able to differentiate the designators, the
security solution should comply with the required framework to
indicate the desired security states

•  Speculation
usually, generally, often normally, typically
–  Umpires and Team Representatives normally require early
indication of intrusion into ERIS
•  Vague, undefinable terms

user-friendly, versatile, approximately, as possible,
efficient, improved, high-performance, modern
–  Security-related messages should be versatile and user-friendly
–  The OK status indicator shall be illuminated as soon as possible
after ERIS security self-check is completed

•  Wishful thinking
100% reliable/ safe/ secure. Handle all unexpected
failures. Please all users. Run on all platforms. Never
fail. Upgrade to all future situations.
–  The gearbox shall be 100% secure in normal operation

–  The network shall handle all unexpected errors without crashing

•  System design:
no names of components, materials, software objects/
procedures, database fields
–  The antenna shall be capable of receiving FM signals, using a
copper core with nylon armoring and a waterproof hardened rubber
shield
•  Mix of requirements and design:

no references to system, design, testing, or installation
–  The user shall be able to view the current selected channel number
which shall be displayed in 14pt Swiss type on an LCD panel tested
to standard 657-89 and mounted with shockproof rubber washers
Avoid system design elements

Identification requirements Authorisation requirements
should not be specified in terms of should not be specified in terms of
–  Who you say you are: –  Authorization lists or databases
•  Name, user identifier, or national –  Person vs. role-based vs. group-
identifier
based authorization
–  What you have:
–  Commercial intrusion prevention
•  Digital possessions such as a digital
certificate systems
•  Physical possessions such as an –  Hardware electronic keys
employee ID card, a hardware key,
or a smart card enabled with a public
–  Physical access controls (e.g.,
key infrastructure (PKI). locks, security guards)
–  Who you are:
•  Physiological traits (e.g., finger print, Integrity requirements
hand print, face, etc)
should not be specified in terms of
•  Behavioral characteristics (e.g., voice
pattern, signature style) –  Cryptography
–  Hash Codes
38
Good requirements
•  Use simple direct sentences
–  Security analyst should be able to view ERIS status.
•  Use a limited vocabulary

–  Security analyst should be able to change
the infected ERIS component in less than 12 h; or
–  Security analyst should be able to reconfigure
the infected ERIS component in less than 12 h
Good requirements
•  Identify the type of user who wants each requirements

–  The Football Federation Employee shall be able to …
•  Focus on stating result

–  … view game reports …
•  Define verifiable criteria

–  … after 2 h after the game.

Criteria
for writing good requirements
•  What, not how (external observability)

–  Avoid premature design or implementation decisions
•  Understandability, clarity (not ambiguous)
•  Cohesiveness (one thing per requirement)
•  Testability
–  Somehow possible to test or validate whether the requirement
has been met, clear acceptance criteria
–  Often requires quantification, this is more difficult for security
than e.g. for performance
•  The response time of button press should be max 2 s.
•  The security of function F should be at least 99.9%
41
Outline
–  Definition

•  Related (to Security)
•  Text-based securityRequirements
requirements
–  Safety
•  Graphical modelling languages
–  Privacy byspecification
•  Formal minimisation
42
Security Requirements Engineering
[Mellado et al., 2010]
•  Techniques
–  Misuse cases [Sindre and Opdahl, 2005]
–  Mal-activity diagrams [Sindre, 2007]
–  SecureUML [Basin et al., 2006]
–  UMLsec [Jürjens, 2005]
–  Agile security requirements engineering [Peeters, 2005]
43

•  Frameworks
–  Specification based framework [Hussein and Zulkernine, 2007]
–  Problem domain ontology [Lee et al., 2006]
–  Framework for security requirements engineering:
representation and analysis
[Haley et al., 2008; Moffett and Nuseibeh, 2003]
–  Security-by-ontology: a knowledge-centric approach

[Tsoumas et al., 2006]
–  Building security requirements with [Viega, 2006]
44
•  Processes
–  CC-based security engineering process [Mellado et al., 2007, 2008]
–  Security requirements for software product lines: a security
domain requirements engineering process
–  Threat modeling as a basis for security requirements
[Myagmar et al., 2005]
–  Software requirements and architecture modelling for evolving
non-secure applications into secure applications
[El-Hadary and El-Kassas, 2014]
–  Requirements reuse for improving systems security
[Shin and Gomaa, 2007]
–  Holistic security requirement engineering
[Zuccato, 2004, 2007, Zuccato et al., 2008]
45

•  Methods
–  KAOS extension to security [van Lamsweerde, 2004]
–  Secure Tropos
[Asnar et al., 2011; Giorgini et al., 2005; Mouratidis et al., 2007, 2010]
•  Security constraint management
•  Trust, ownership and delegation management
•  Goal risk-driven assessment
•  A three-layer security analysis framework
–  SQUARE [Mead et al., 2005]
–  SREBP [Ahmed and Matulevičius, 2013, 2014]
46
Formal specification techniques
•  Specify system requirements in terms of formulae in
math/logic
•  Advantages:
–  Precise
–  Can (sometimes) prove that the system is correct
•  Disadvantages:
–  Very time-consuming
–  Hard to understand for stakeholders who are not specialists
•  Can only be used for smaller parts of systems, e.g.,

highly critical parts where a huge investment is feasible
47
Outline
–  Definition

–  Safety
48
Safety domain model
Safety is characterised as unintentional happening
[Firesmith, 2003] 49
Safety domain model
•  Asset is anything of value

that should be protected from
accidental harm
•  Safety goals state the
importance of achieving a target
level of safety
Safety domain model
•  Safety risk is the potential

harm to an asset due to
accidents based on the
vulnerabilities
Safety domain model
•  Safety policy is a quality policy that

mandates a system-specific quality criterion
for safety or one of its subfactors
•  Safety requirement is specified in terms of
a system-specific criterion and a minimum
mandatory level of an associated quality
metric that is necessary to meet safety
policies and to mitigate the safety risks
Outline
–  Definition
–  Safety


53
Privacy by Data Minimisation

[Pfitzmann and Hansen, 2010]
54
•  Anonymity means that subject is not

identifiable within a set of the
anonymity set, i.e., all subjects
•  Undetectability of an item of interest
means that the attacker is not able to
distinguish between whether the item
of interest exists or not
•  Unobservability of an item of
interest consists of undetectability
and anonymity 55

•  Unlinkability of two or more items

of interest means that the attacker
cannot sufficiently distinguish
whether they are related or not
56
•  Pseudonymity is the use of

pseudonyms as identifiers
–  Pseudonym is an identifier of a
subject other than one of his real
names
57

•  Identifiability means that the attacker

can sufficiently identify the subject within
a set of subjects
–  Identity is any subset of attribute values of
a person which sufficiently identifies this
person within any set of persons
–  Identity management deals with defining
identity attributes, developing and
choosing pseudonyms and partial
identities in the considered context
58
Summary
–  Definition
–  Safety
59

Security Requirements: - Introduce What Are - Define What Are

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Security Requirements: - Introduce What Are - Define What Are

Caricato da

Copyright:

Formati disponibili

Fundamentals of

Secure System Modelling

v Integrity – a property of safeguarding the accuracy and

v Availability – a property of being accessible and usable

What are requirements?

• Security requirement is a condition over the

– can only access data and services for which they

• Detect attempted intrusions by unauthorised persons

• Enable security personnel to audit the status and usage

Authentication requirements System maintenance security

Authorisation requirements Physical protection

Immunity requirements Survivability requirements

Integrity requirements Security auditing requirements

Intrusion detection Nonrepudiation requirements

Authorisation requirements Authe1: The ERIS shallPhysical

Authorisation requirements Physical protection

Authentication requirements Systemshall

Extent to which a system shall ensure that its

Immunity requirements Survivability requirements

Extent to which a Identification

Authorisation requirements Physical protection

Immunity requirements Survivability requirements

Security auditing requirements

Authorisation requirements Physical protection

Authentication requirements System maintenance security

• Sur1: The ERIS shall not have a single

Physical protection requirements

Authorisation requirements Physical protection

Authorisation requirements Physical protection

Authentication requirements System maintenance security

Authorisation requirements Physical protection

Immunity requirements Survivability requirements

Integrity requirements Security auditing requirements

Intrusion detection Nonrepudiation requirements

Authentication requirements System maintenance security

Authorisation requirements Physical protection

Immunity requirements Survivability requirements

Integrity requirements Security auditing requirements

Intrusion detection Nonrepudiation requirements

• Multiple requirements – and, or, with, also

[Alexander and Stevens, 2002] 33

Do not write like this

[Alexander and Stevens, 2002] 34

• Vague, undefinable terms

[Alexander and Stevens, 2002] 35

Do not write like this

– The gearbox shall be 100% secure in normal operation

[Alexander and Stevens, 2002] 36

• Mix of requirements and design:

[Alexander and Stevens, 2002] 37

Avoid system design elements

• Use a limited vocabulary

[Alexander and Stevens, 2002] 39

• Identify the type of user who wants each requirements

• Focus on stating result

• Define verifiable criteria

[Alexander and Stevens, 2002] 40

• What, not how (external observability)

Security Requirements Engineering

– Security-by-ontology: a knowledge-centric approach

– Building security requirements with [Viega, 2006]

Security Requirements Engineering

• Can only be used for smaller parts of systems, e.g.,

v  Integrity – a property of safeguarding the accuracy and

v  Availability – a property of being accessible and usable

•  Security requirement is a condition over the

–  can only access data and services for which they

•  Detect attempted intrusions by unauthorised persons

•  Enable security personnel to audit the status and usage

•  Sur1: The ERIS shall not have a single

•  Multiple requirements – and, or, with, also

•  Vague, undefinable terms

–  The gearbox shall be 100% secure in normal operation

•  Mix of requirements and design:

•  Use a limited vocabulary

•  Identify the type of user who wants each requirements

•  Focus on stating result

•  Define verifiable criteria

•  What, not how (external observability)

–  Security-by-ontology: a knowledge-centric approach

–  Building security requirements with [Viega, 2006]

•  Can only be used for smaller parts of systems, e.g.,

•  Asset is anything of value

•  Safety risk is the potential

•  Safety policy is a quality policy that

•  Anonymity means that subject is not

•  Unlinkability of two or more items

•  Pseudonymity is the use of

•  Identifiability means that the attacker