Framework for Engineering Complex

Security Requirements Patterns

Ral MAZO
Panthon Sorbonne University & Eafit University
raulmazo@gmail.com

Christophe FELTUS
Luxembourg Institute of Science and Technology
christophe.feltus@list.lu

Agenda
1.
2.
3.
4.
5.

Motivation
Security requirements engineering
Challenges and issues
Proposal
References

Security requirements engineering

(SRE)
So
SRE!

But SRE is really necessary?

The dark side of software security

Source:
http://www.lemondeinformatique.fr

Security requirements engineering (SRE) for

better security handling : the light side!
What?

How?

Private key

Security requirements engineering (SRE) for

better security handling : the light side!
Helps to introduce security requirements analysis in
the early phases of the system development process.
Allows us to:
envisage threats, their consequences and countermeasures
before a system is in place rather than when the destruction
of a possibly disastrous attack occurs.
analyse security requirements within the organizational
environment in which the system will operate.

Some challenges and how SRE intends to

tackle them
Analysts and requirements engineers have to
face two major challenges: the reuse of the,
often tacit, knowledge about security and the
engineering of this reusable knowledge.
In SRE, the first challenge is usually faced by
means of security patterns and the second one
by means of systems of security patterns.
8

The issues
Zuccato et al. report that (1) SRE is in practice
frequently performed by security non-experts,
(2) security expertise is scarce, and (3)
security requirements and their dependencies
are often not directly known by requirements
engineers.

Proposal
To cope with this issue, this paper proposes a
framework for engineering reusable security
requirements patterns in the context of the current
requirements engineering practices for complex
systems.
In particular, the proposed framework consists in a
set of methods and models that gathers simple
and complex patterns according to their
complexity level and the security deployment level
of the project.
10

Overview of the COPERATE (complex

security requirements patterns) framework

This framework aims to organize the elements that should be taken into account to build
and manage complex security patterns in function of:
(vertical axis) the complexity level of the security criteria that should be considered and
(horizontal axis) the security deployment life cycle of the information system

11

Example: a data access appl. in a cloud-based environment

In traditional information systems, access to information requires
the deployment of two isolated and independent security
requirements patterns:
1. a pattern for the management of the access rights (Re1: user
authentication) and
2. a pattern for the encryption of the data (Re2: data
confidentiality)

Traditional Access rights security

requirements
1. Access request
(Name in clear/
Crypted PW)

Access rights
mgt tool

4. Name and PW in clear

5. Access granted or denied

6. Give access

Eg.: Employee
2. Crypted PW

3. PW in clear

Access rights
policy

Encryption
Engine

Re1

User authentication

Re2

PW encryption

Security Pattern :
Traditional Access
rights management

Example: a data access appl. in a cloud-based environment

In a cloud computing-based environment, the access rights
and the data encryption should not be separately handled by
these two patterns. Instead, they should be composed into a
new unique complex security requirements pattern that takes
into account the complex relations between the two simple
patterns taken separately.

Example: a data access appl. in a cloud-based environment

In a cloud environment it will be necessary to consider encryption
requirements and traditional access control mechanisms as a
unique new complex requirement Re3, where Re3 is not equivalent
to Re1 + Re2 but Re3=Re1Re2 with Re1Re2 being > (Re1 + Re2).
Indeed, in cloud computing user authentication may, for instance,
not be performed in clear but by means of encryption tools.

Cloud Access rights security

requirements
Access rights
mgt tool

1. Access request
(Crypted Name/
Crypted PW)

7. Access granted or denied

8. Give access

Eg.:
Anonymous
User

6. Name and PW in clear

2. Crypted name
3 Name in clear

5. PW in clear

Access rights
policy

4. Crypted PW

Encryption
Engine 1

Re1

User authentication

Re2

PW encryption

Re3

User privacy

Encryption
Engine 2

System of security
patterns : Cloud
specific Access
rights management

Example: a data access appl. in a cloud-based environment

In this case, both requirements must be integrated to form what we
call a Complex Security Requirements Pattern (Re3), representing
Re1Re2. That is, Re3 = Re1+Re2+Re3
Where Re3 represents the integration of the security requirements
Re1 and Re2 to simultaneously achieve user authentication and
data encryption (which guarantees the confidentially and privacy of
the users while they log on the information system).

Traditional vs. Cloud Access rights

security requirements
Traditional:
Access rights requirements Re3 = Re1 and Re2
Re1 and Re2 fulfilled successively (Re1 + Re2)

Cloud:

authentication

Re1

Re2

encryption

Access rights requirements Re3 = Re1 and Re2 and Re3

Considering that user privacy is achieved by the encryption of user ID
used by the user for authentication
We have Re3 = encryption (Re2) of authentication ID (Re1) that may be
written Re1Re2
authentication

and Re3=Re1+Re2+Re3

Re1

Re3
privacy

Re2

encryption

To pave the way to future research

in the area of reusable security
patterns, there are some research
questions that still need to be
answered.

How may Security Requirements

Patterns be extended to consider
Complex Security Requirements?
Formalizing and
extending the security
requirements pattern
semantics

Sampling some important

complex security
requirements patterns
(Beckers, 2015)

(Schumacher, 2003)

How may Systems of Security Patterns

be designed on the bases of risk
management approaches?
Definition of a
methodological
framework embracing
models, templates and
guidelines required by the
security professionals.

How may Requirements Engineering help

identifying the right SSP to fulfil Complex
Security Requirements Patterns?

Allow discovering to what

extend Requirements
Engineering techniques
help
identifying/detecting/buildi
ng Systems of Security
Patterns.

What are the next challenges to be

addressed to automate the design and
implementation of SSP considering
Complex Security Requirements Patterns?
Allow understanding the
new research challenges
for identifying, designing
and implementing the
new concrete security
requirements

References

K. Beckers. "Pattern and Security Requirements Engineering-Based Establishment of Security Standards",

ISBN: 978-3-319-16663-6, Springer, 2015.
X. Franch, C. Quer, S. Renault, C. Guerlain, and C. Palomares. "Constructing and Using Software
Requirements Patterns", Managing Requirements Knowledge, edited by Walid Maalej and Anil Kumar
Thurimella, pp. 95116. Berlin, Heidelberg: Springer Verlag, 2013.
P. Nguyen, J. Klein, and Y. Le Traon. Model-Driven Security with Modularity and Reusability for Secure
Systems Development, STAF-DS, 2014.
P. Nguyen, J. Klein, and Y. Le Traon. "Model-Driven Security with A System of Aspect-Oriented Security
Design Patterns" Proceedings of the 2nd Workshop on View-Based, Aspect-Oriented and Orthographic
Software Modelling, ACM, 2014.
S. Renault, O. Mndez-Bonilla, X. Franch, and C. Quer. "PABRE: pattern-based requirements elicitation",
International Conference on Research Challenges in Information Science (RCIS), pp. 81-92, 2009.
A. Souag, C. Salinesi, R. Mazo, I. Comyn-Wattiau. "A Security Ontology for Security Requirements
Elicitation", International Symposium on Engineering Secure Software and Systems (ESSoS), Lecture Notes
in Computer Science Series, Milan-Italy, 2015.
Schumacher, M. "Security engineering with patterns: origins, theoretical models, and new applications".
Vol. 2754. Springer, 2003.
A. Zuccato, N. Daniels, C. Jampathom. "Service Security Requirement Profiles for Telecom: How Software
Engineers May Tackle Security". In the Sixth International Conference on Availability, Reliability and
Security (ARES), 2011.

Thanks and see you!

Security requirements engineering (SRE) for

better security handling (Some SRE methods)
Security Requirements
Approaches

Object Oriented
Approaches

UML Profils

Agent and Goal oriented

Approaches

Risk Analysis Based

Approches

Extended KAOS (anti-models)

RiskRep

UMLSec

Extended I*

ISSRM

SecureUML

Secure Tropos

CORAS

Use Case
EBIOS

Industrial
approaches

MisuseCase
MEHARI

AbuseCase

Security UseCase

(Fabian et al. 2009): A comparison of security

requirements engineering methods

26