Describing Early Security Requirements using Use Case Maps Jameleddine Hassine King Fahd University of Petroleum and Minerals, Dhahran, Saudi Arabia 1 Abdelwahab Hamou-Lhadj Concordia University, Montreal, Canada F O R U M th International Conference on System Design Languages Smart Cities, October 12-14, Berlin, Germany

Outline  Motivation  What is Security?  Architectural Security Tactics  Modeling Security in Use Case Maps  UCM Attack Detection Modeling  UCM Attack Resistance, Reaction, and Recovery Modeling  UCM Security-Enabled Metamodel  Discussion  Conclusion & Future Work 2

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)). 3

 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. 4 What is Security?

Architectural Security Tactics 5 [Bass et al. 2012]

Architectural Availability Tactics 6 [Bass et al. 2012]

Modelling 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. 7

UCM Attack Detection Modeling  SecCategory has the value DetectAttacks.  SecTactic has one of the following four values: 1.DetectIntrusion, 2.DetectServiceDenial, 3.VerifyMessageIntegrity, 4.DetectMessageDelay. 8

UCM 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. 9

UCM Attack Resistance, Reaction, and Recovery Modeling- Generic Example 10

11 UCM Security-Enabled Metamodel

12 UCM Security-Enabled Metamodel Hassine J.: Describing and assessing availability requirements in the early stages of system development. Software and System Modeling 14(4): (2015) DOI /s

UCM 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. 13

Discussion  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. 14

Conclusions 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. 15