describing early security requirements using use case maps jameleddine hassine king fahd university...
TRANSCRIPT
Describing Early Security Requirements using Use Case
Maps
Jameleddine Hassine
King Fahd University of Petroleum and Minerals, Dhahran, Saudi Arabia
Abdelwahab Hamou-Lhadj
Concordia University, Montreal, Canada
F O R U M 2015
17th International Conference on System Design Languages
Smart Cities, October 12-14, Berlin, Germany
2Outline
Motivation What is Security? Architectural Security Tactics Modeling Security in Use Case Maps
UCM Attack Detection ModelingUCM Attack Resistance, Reaction, and Recovery Modeling
UCM Security-Enabled Metamodel Discussion Conclusion & Future Work
3 Motivation
Non-functional requirements (NFR), such as availability and security, are often critical for the success of a software product.
Address NFRs at the earliest stages of system development life cycle.
Security concerns are often postponed to the very end of the design process causing serious design challenges that usually translate into software vulnerabilities.
Describe high-level security requirements using the Use Case Maps language (part of the ITU-T standard User Requirements Notation (URN)).
4
The term 'security' is used in the sense of minimizing the vulnerabilities (i.e., any weakness that could be exploited to violate a system or its data) of assets (i.e., anything of value) and resources. [ITU-T rec. E.800]
Security [ITU-T rec. X.1051] can be characterized in terms of (CIA triad):
Confidentiality: set of rules that limits access to information.
Integrity: the assurance that the information is trustworthy and accurate.
Availability: A guarantee of reliable access to the information by authorized people.
Other characteristics, such as authentication (e.g., checking the identity of a client), authorization (e.g., checking whether a client might invoke a certain operation), and non-repudiation (which refers to the accountability of the communicating parties), are used to support security.
What is Security?
5Architectural Security Tactics
[Bass et al. 2012]
6
Architectural Availability Tactics
[Bass et al. 2012]
7Modelling Security in Use Case Maps
1. Bind the type of the deployed security tactic with UCM responsibilities using metadata attributes:
SecCategory: Species the security category, if any, that the responsibility is implementing. This attribute may take one of the following four values: DetectAttacks, ResistAttacks, ReactAttacks, and RecoverAttacks.
SecTactic: Denotes the deployed security tactic (i.e., one of the seventeen defined tactics).
2. Model, at the scenario path level, how different security categories can be deployed.
8UCM Attack Detection Modeling
SecCategory has the value DetectAttacks.
SecTactic has one of the following four values:
1. DetectIntrusion,
2. DetectServiceDenial,
3. VerifyMessageIntegrity,
4. DetectMessageDelay.
9UCM Attack Resistance, Reaction, and Recovery Modeling
1. Modeled using metadata attributes: SecCategory and SecTactic
2. Modeled using of cascading failure scenario paths:
A failure scenario path starts with a failure start point ( ) and has a guarding condition that can be modified as part of a
responsibility expression.
3. The definition of a hierarchical structure of UCM maps (using UCM stubs) on the failure scenario paths.
10
UCM Attack Resistance, Reaction, and Recovery Modeling- Generic Example
11
UC
M S
ecu
rity
-Enab
led
Meta
mod
el
12
UC
M S
ecu
rity
-En
ab
led
Meta
mod
el
Hassine J.: Describing and assessing availability requirements in the early stages of system development. Software and System Modeling 14(4): 1455-1479 (2015) DOI 10.1007/s10270-013-0382-0
13UCM Security-Enabled Metamodel
Reuse of the existing set of availability metaclasses to model availability requirements such as component redundancy and fault recovery.
A responsibility may implement one and only one security tactic (as described using the 0..1 relationship multiplicity in the metamodel). If there is a need to realize more than one security
tactic, a responsibility shall be refined into multiple responsibilities.
14Discussion
Security requirements as assets and services that have to be protected against possible attacks.
Guard functional behavior against potential threats.
Attach security requirements, as metadata attributes, to vulnerable responsibilities.
Defense/recovery mechanisms are implemented using failure scenario paths.
We don’t model how an attack will break the system
If such information is available, the vulnerabilities would have been fixed at the functional level.
We specify the types of measures (using the security tactics) that the system should implement.
Simpler and faster than approaches based on threat modeling.
15Conclusions and future work
Proposed a new approach to model security requirements at the very early stages of system development.
Extended the Use Case Maps language to cover security tactics.
Conduct qualitative and quantitative analysis of UCM-based security requirements.