SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Requirements Engineering for Security using
Problem Frames
Conclusions
Maritta Heisel
paluno - The Ruhr Institute for Software Technology,
University of Duisburg-Essen - Germany
June 18, 2014
1/ 17
Messages
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
• If you don’t know what you’re doing, it’s hard to do it
right.
• No software without an environment.
• Security is not an add-on.
2/ 17
Software engineering practice?
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
3/ 17
“You guys start coding while I go find out what the
customer wants.”
Studies of the Standish-Group (CHAOS Research),
’94/’96/’98/’00/’02/’04/’06/’08/’10
SRE PF
60%
M. Heisel
50%
Introduction
Why RE?
40%
Environment
Security
30%
Conclusions
20%
10%
0%
Successful
Challenged
Failed
1994
16%
53%
31%
1996
27%
40%
33%
1998
26%
46%
28%
2000
28%
49%
23%
2002
34%
51%
15%
2004
29%
53%
18%
2006
35%
46%
19%
2008
32%
44%
24%
2010
37%
42%
21%
Imcomplete requirements are the most important reason for
failed or challenged projects.
4/ 17
Requirements engineering is a necessity!
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
• Text may be nice, but is hard to analyze and re-use.
Conclusions
• Patterns are nice, because we don’t re-invent the wheel all
the time.
• Models are nice, because they are computer-processable.
5/ 17
Patterns: Problem Frames
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
• A pattern is a kind of template, abstracting from details,
representing the essence of an artifact.
• Problem frames are patterns for simple software
development problems, proposed by Michael Jackson.
• “A tool is needed to allow a user to create and edit a certain class of
computer-processable text or graphic objects, or similar structures, so
that they can be subsequently copied, printed, analysed or used in
other ways. The problem is to build a machine that can act as this
tool.”
Workpieces
Editing tool
ET!E1
WP!Y2
Y4
Workpieces
Party
plan
a
c
Command
effects
US!E3
b
John & Lucy
User
B
6/ 17
b
B
E3
User
effects
Correct
editing
X
Editing
tool
Command
X
Party
editor
a: PE!{PlanOperations}
PP!{PlanStates}
b: JL!{Commands}
c:PP!{PlanEffects}
[E1]
[Y2]
[E3]
[Y4]
Models
SRE PF
M. Heisel
Introduction
Why RE?
Environment
• Use modeling languages, such as UML.
• Models can be checked for semantic properties, e.g.,
coherence to other models.
Security
• Models can be processed further, e.g. code generation.
Conclusions
• Model-driven software development is a hot topic.
7/ 17
No software without an environment
SRE PF
M. Heisel
Introduction
Why RE?
Environment
• We always have to take the environment in which the
software will operate into account.
Security
Conclusions
• The software is built to enhance the environment, so it has
to interact with it in an appropriate way.
• Depending on how the environment behaves, the software
may be adequate for its purpose, or not.
• Example: Ariane 5 accident
8/ 17
Example: smart grid
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
9/ 17
Context diagram for smart grid
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
10/ 17
Security requirements engineering
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
• Taking the enviroment into account is especially important
for security.
• No software is ”absolutely secure”, it just can be secure
with respect to its environment. For example, it can
withstand a medium strong attacker, but not the NSA.
• As a consequence, domain knowledge has to be made
explicit (e.g., using models).
11/ 17
Example: Attacker modeling
(According to the Common Methodology for Information Technology Security
Evaluation (CEM))
12/ 17
standard, specialized,
bespoke, multiple
bespoke
Value RQ11.4
Specialist
expertise
Knowledge of
the TOE
Window of
opportunity
IT hardware/software or
other
equipment
Value RQ11.3
Attack time
one day, one week, two
weeks, one month, two
months, three months,
four months, five
months, six months,
more than six months
one day, one week, two
weeks, one month, two
months, three months,
four months, five
months, six months,
more than six months
laymen, proficient,
expert, multiple experts
public, restricted,
sensitive, critical
unnecessary / unlimited,
easy, moderate, difficult
Value RQ11.2
Conclusions
Preparation
time
Upper/Lower Bound
Security
Value Original Requirement
Environment
Rank
Why RE?
Possible Values
Introduction
Property (CEM)
M. Heisel
Quality: Security, Requirement RQ11, Alternatives RQ11.2, RQ11.3, RQ11.4
SRE PF
3
more
than six
months
one
month
four
months
two
months
one
month
5
more
than six
months
one
month
more
than six
months
three
months
one
month
6
multiple
experts
proficient
multiple
experts
expert
proficient
1
public
public
public
public
public
2
difficult
difficult
difficult
difficult
difficult
4
multiple
bespoke
bespoke
multiple
bespoke
multiple
bespoke
bespoke
Security is not an add-on
SRE PF
M. Heisel
Introduction
Why RE?
There is no pulldown menu that will let you select
“Security” and then sit back and watch magic things
happen. (McGraw)
Environment
Security
Conclusions
• Talking about encryption and firewalls does not help.
These are solutions, but we must first describe the
problems.
• Therefore, we must elicit and analyse security
requirements in much the same way as we do with
functional requirements.
• For this purpose, we must identify assets to be protected,
analyze the risk for the assets and only then decide on
countermeasures such as encryption or access control.
13/ 17
Problem diagram for smart grid security
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
14/ 17
Method I
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
1. Structure the environment in which the software will
operate by setting up a context diagram.
2. Elicit security requirements. These refer to assets (e.g.,
meter data), and security goals, such as confidentiality,
integrity, and availability.
3. Elicit domain knowledge. In particular, describe the
attackers the system should be protected against.
4. Set up problem diagrams, showing what domains are
affected by the requirements.
15/ 17
Method II
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
5. Check the models for semantic integrity conditions. This
can be done in a tool-supported way.
6. Analyse requirements for possible conflicts, e.g., with
performance requirements or budgetary constraints.
7. Possibly weaken some of the requirements.
Only after all these steps have been taken, appropriate security
mechanisms, such as encryption or access control, can be
chosen.
16/ 17
Conclusions
SRE PF
M. Heisel
Introduction
Why RE?
Environment
Security
Conclusions
• Without thoroughly analyzing requirements, we cannot get
things right.
• The environment plays a crucial role and hence must be
modeled. This concerns attackers, in particular.
• Security must be planned for from the beginning of system
and software developement.
• Security requirements (i.e., problems, not security
mechanisms) must be elicited and analyzed, and balanced
with other requirements.
• The problem frames approach and UML modeling can
support this process.
17/ 17