describing early security requirements using use case maps jameleddine hassine king fahd university...

Describing Early Security Requirements using Use Case

Maps

Jameleddine Hassine

King Fahd University of Petroleum and Minerals, Dhahran, Saudi Arabia

jhassine@kfupm.edu.sa 1

Abdelwahab Hamou-Lhadj

Concordia University, Montreal, Canada

abdelw@ece.concordia.ca

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.