=Paper=
{{Paper
|id=Vol-1157/norms4
|storemode=property
|title=Modeling and Applying Security Patterns Using Contextual Goal Models
|pdfUrl=https://ceur-ws.org/Vol-1157/paper11.pdf
|volume=Vol-1157
|dblpUrl=https://dblp.org/rec/conf/istar/LiM14
}}
==Modeling and Applying Security Patterns Using Contextual Goal Models==
https://ceur-ws.org/Vol-1157/paper11.pdf
Modeling and Applying Security Patterns Using
Contextual Goal Models
Tong Li, John Mylopoulos
University of Trento, Trento, Italy
{tong.li,jm}@disi.unitn.it
Abstract. Security patterns have been proposed to help analysts with lit-
tle security knowledge to tackle repetitive security design tasks. Although
advanced research in this field has produced an impressive collection of
patterns, they are not well integrated with security requirements analy-
sis and not easy to apply. Goal-oriented modeling languages have been
proposed as an effective way to capture requirements, including security
requirements, for socio-technical systems. In this paper, we argue that
modeling and analyzing security patterns in contextual goal models can
facilitate their applications and magnify their influences in system security
design. Particularly, we present a mapping between security patterns and
contextual goal models, and provide practical guidelines for transforming
textual security patterns into the goal models. In addition, we propose a
systematic process for applying security patterns, and discuss how it can
be combined with existing security requirements analysis approaches.
1 Introduction
As the complexity of systems increases, system security design is becoming
increasingly laborious and requires specialized knowledge about security. Se-
curity patterns encapsulate reusable security knowledge, and as such assist an-
alysts in designing secure systems with proven security solutions. Much work
has been done to collect and document security patterns, resulting in several
security pattern repositories, such as [3]. Security patterns constitute a partic-
ular class of design patterns. Although design patterns have been successfully
applied in many industrial projects, security patterns have not been widely
used [3]. One of the reasons for this is the lack of integration with security re-
quirements analysis techniques, i.e. the analysis regarding to security patterns
mainly focuses on solutions rather than problems. Another reason is the lack of
a methodology for systematically applying security patterns.
Goal-oriented modeling languages have been proposed as an effective way
to capture and analyze system requirements. Many goal-oriented security re-
quirements approaches have been proposed, some of which already applied
security patterns in their analysis, such as Secure Tropos [5]. However, this
work does not consider contexts and tradeoffs between forces during the se-
lection of security patterns. We argue that integrating goal model analysis and
security pattern analysis by modeling security patterns in contextual goal mod-
els can benefit both goal-oriented security analysis and security pattern analysis.
Goal model analysis captures the rationale for applying security patterns and
facilitate selection among alternative security patterns, while applying security
patterns efficiently operationalizes security requirements into detailed security
specifications that consists of proven security solutions.
In this paper, we present a goal-oriented modeling language, which extends
our previous work [4] with context-related concepts. Based on this language,
we transform practical security patterns that are documented in text [3] into
contextual goal models. Additionally, we provide a number of guidelines, which
facilitate this transformation. Finally, we propose a systematic process to analyze
and apply security patterns.
2 Baseline
Our previous work proposed a three-layer security requirements analysis frame-
work, which aims to address security issues in business layer, software appli-
cation layer, and physical infrastructure layer respectively [4]. In each layer, we
not only analyze security requirements but also identify security mechanisms,
which can appropriately treat the critical security requirements. We believe that
the security mechanisms we apply in one layer shed light on the security re-
quirements in the next layer down, i.e. the upper-layer security requirements
indirectly influence the security requirements in the lower-layers. For example,
if an analyst designs an auditing activity to treat the security requirements re-
garding to a data asset in the business layer, the security of this activity itself
is also important. Thus, corresponding security requirements should also be
applied to the application that implement the auditing activity. Our three-layer
security analysis takes the functional requirements models of each of the three
layers as input, and iteratively analyzes security issues in each individual layer
via four steps: security requirements refinement, simplification, operationaliza-
tion, and cross-layer analysis. This framework presents a three-layer require-
ments goal modeling language, which involves concepts actor, goal, softgoal, task,
domain assumption, inference, contribution, dependency and priority. Those concepts
are imported from i* and Techne, and are used in the same way as defined in
existing work.
Within the three-layer framework, we leverage existing security patterns
to operationalize critical security goals into appropriate security mechanisms.
Table. 1 shows a part of the security pattern Authenticator [3], which is docu-
mented in text. Specifically, our approach matches identified critical security
goals with the problem described in a security pattern, and then provides a
list of successfully matched security patterns, amongst which the analyst must
select. However, this approach easily results in a number of alternative security
mechanisms for each critical security goal, and the selection among them is a
non-trivial task. In addition, after choosing a security pattern, the current ap-
proach requires analysts to manually model and analyze the security patterns
according to [3], which is time-consuming and may have different when per-
formed by different people. To tackle these problems, we improve the security
pattern analysis in the following aspects. 1) We suggest more suitable security
pattens to analysts by taking into account the context of security patterns, in
which the security problems happen and the security solutions apply. As shown
in Table. 1, if the Context does not hold, the security pattern is not applicable.
To model context in goal models, we base our approach on existing work [1]. 2)
We develop unified and reusable goal model snippets for each security pattern
with detailed solutions.
Table 1: Security pattern example — Authenticator [3]
Context:
Computer systems contain resources that include valuable information about business
plans, user medical records and so on.
Problem:
How can we prevent imposters from accessing our system? A malicious attacker could
try to impersonate a legitimate user to gain access to their resources. How do we verify
that a user intending to access the system is legitimate?
Force:
Flexibility. A variety of users require access to the system. We need to be able to handle
all this variety appropriately.
Performance. If authentication needs to be performed frequently, performance may be-
come an issue.
Solution:
Use a single point of access to receive the interactions of a subject with the system
Apply a protocol to verify the identity of the subject. The protocol used may be simple
or complex, depending on the needs of the application.
3 Modeling Security Patterns as Contextual Goal Models
A security pattern captures proven security knowledge in a structured template
with a number of sections, among which there are four essential sections context,
problem, force, and solution. Apart from these, a security pattern normally also
contains other sections, such as Example, Implementation, Structure, Dynamics,
Consequence, Known Uses, See Also. Table 1 shows an example, which contains
the four essential sections, with more information presented in [3].
Design-Time 1...* 1...* Softgoal
0...1 prioritize 0...1
Domain Context Force
Property 0...1 0...* Domain
Assumption
occurred in resolve
solve
Goal 1...* 0...1 0...1 1...*
Problem Solution Task
/Softgoal
Fig. 1: Concept mappings between contextual goal models and security patterns
As claimed in section 2, we aim to analyze the context of security patterns.
Towards this goal, we extend our previous modeling language with the follow-
ing concepts. A Domain Property is a fact about the world, while a Design-Time
Domain Property is a domain property that can be determined at design time.
For example, Computer systems on a local network connected to the Internet is a
design-time domain property, and we can verify this fact during design time ac-
cording to the designed system infrastructure. For another example, The number
of users increases significantly is a domain property, but not a design-time domain
property, as it cannot be verified until the system is running. Because the secu-
rity pattern analysis is carried out in the system design phase, we only capture
and analyze Design-Time Domain Properties, and use this concept to describe the
context of security patterns. A particular context could be an aggregation of
domain properties in any complexity, typically, via an and/or operator.
Based on the above extension, we propose a mapping between the four
essential concepts of the security pattern and the concepts of the contextual
goal model, which is presented in Fig. 1. We describe the mapping in detail as
below, where the definition of each security pattern concept is introduced first.
– Context: is the circumstance in which the security problem occurs and is
being solved, and it also determines the importance of the forces. We model
the context with an aggregation of Domain Property, via and/or operator.
– Problem: is a description of a situation where stakeholders do not have a
solution. We use one or several Goals or Softgoals to capture stakeholders’
needs concerning such a problem.
– Force: are considerations, often contradictory, which have to be taken into
account when choosing a solution to a problem. These considerations are
often related to non-functional requirements, such as performance and cost.
We model such forces as Softgoals. Moreover, some forces describe designer’s
assumptions, which guarantee the security problems can be correctly tack-
led by the security patterns, such as Network firewalls cannot filter out harmful
message. We use Domain Assumption to model such forces.
– Solution: describes detailed actions that are carried out by a security pattern.
We model them as Tasks, which the system-to-be performs to satisfy its
requirements.
Although the mappings we proposed above conceptually match concepts
in two sides, our practical experiences reveal a number of difficulties during
the transformations. One important reason for these difficulties is that security
patterns are sometimes documented in different ways. For example, some pat-
terns omit the Force section, such as the pattern Secure Adapter. To facilitate this
transformation, we provide complementary guidelines: 1) Some patterns not
only present forces in the Force section, but also in the Consequence section. 2)
Apart from the general context specified in the Context section, the problems,
forces, and solutions may involve particular contexts. For example, as shown
in Fig. 2, the authenticator pattern can contribute to the softgoal Flexibility only
under the context (C2) that a variety of users access the system. 3) Some solutions
are described in a very abstract manner, which should be further detailed by
reviewing the Implementation section.
Based on the proposed mapping and guidelines, we transform the textual
security pattern shown in Table 1 into a contextual goal model, shown in Fig. 2.
Note that we adopt the method proposed in [1] to model Context in goal models
using their semantics. For example, the goal Prevent imposters from access our
systems is activated, if and only if context C1 holds. The context C1 is described
as DP1, which is extracted from the Context section of Table 1.
C1
Performance Flexibility Prevent impostors
[g1] [g1] from access our
systems
C3 C2
Make Make
(g1)
Simplify Appropriately
Verify that a user attacker could try to
authentication handle user
intending to access the impersonate a legitimate
procedure variebility
system is legitimate user to gain access
Help Make
Context:
C1 = DP1, C2 = C1 ^ DP2, C3 = C1 ^ DP3
Authenticator
Domain Property:
Use single DP1: Computer systems that contain valuable information
point of access DP2: A variety of users access the system
to interact with Apply a DP3: Authentication needs to be performed frequently
users protocol to
authenticate legend
Softgoal Goal Task refine
Authentication
component User identity
data store Domain C
Assumption Context Contribution And-refine
Fig. 2: Transformation example
4 Analyzing Security Patterns
Once obtaining a set of security patterns modeled in contextual goal models,
we propose a systematic analysis procedure to analyze security patterns, which
can be further integrated into our three-layer framework to enhance the security
requirements operationalization analysis.
– Pattern Candidate Generation. By using our three-layer security require-
ments analysis [4], we can automatically derive a number of security pattern
candidates with regard to a critical security goal.
– Context Verification. The context of each security pattern candidate is
checked against the current system context. Our three-layer requirements
models can be used for this verification, because they cover system-related
design facts, ranging from the business layer to the physical layer. Because
contexts may not all be explicitly presented, this step will be done in an in-
teractive manner with stakeholders. If the context of a security pattern does
not hold, we should deactivate its corresponding part in the goal model
pattern as specified in [1], and further propagate the deactivation through
the refine and and-refine links. For example, if the context C1 does not hold
in Fig. 2, this pattern will not apply, as the C1 is tagged on the root goal.
– Pattern Selection. After above analysis, if there is more than one candidate,
we can apply certain selection algorithm to select the best security pattern
w.r.t its contributions to forces. For example, a NFR-based approach has
been proposed for this selection in [2].
– Pattern Application. If a security pattern is chosen to be implemented,
we insert the whole goal model pattern into the three-layer requirements
models. Because the solution has been refined to the detailed and layer-
specific tasks, such as Authentication component in Fig. 2, the analyst does
not need to further refine the leaf tasks but only needs to assign them to
corresponding actors in the three-layer requirements models.
5 Related Work
Mouratidis et al. extend Secure Tropos methodology with the use of security
patterns [5]. They model security patterns in agent-oriented goal models, which
capture both detailed security components and their interactions. However,
their approach does not consider contexts of security patterns during their
selections. Araujo and Weiss [2] propose to apply the Non-Functional Require-
ment (NFR) framework as a complementary representation for security pat-
terns, which helps to analyze the tradeoffs between forces. Although they also
do not consider the influences of context on the NFR models, this work could
be employed in our work after analyzing and adding the contextual issues to
the model. Ali et al. [1] propose a contextual goal modeling language, which ex-
plicitly models Monitorable Context in goal models and further provides related
reasoning algorithms. This work focuses on runtime requirements analysis,
while our framework analyzes requirements at design time. We follow their
method to model contexts, but redefine some of their concepts to fit our needs.
6 Conclusion
In this paper, we propose to model security patterns in terms of contextual goal
models to facilitate the selection and application of security patterns. Therefore,
we define conceptual mappings and provide guidelines to assist the modeling
of security patterns. Furthermore, we propose a systematic process to analyze
security patterns, which can enhance our previous work. Currently, we have
constructed contextual goal models for 6 security patterns in [3], serving as
starting examples. In the future, we plan to transform a significant number of
security patterns to support application of our security framework to a realistic
case study. As we briefly discussed in the Sec. 3, security pattern knowledge
does not always strictly fall within the corresponding sections. Along with
the above transformation, we also have the aim of improving existing security
pattern documentations. Finally, we plan to develop a tool to model security
patterns and semi-automate analysis, and further integrate this work into our
three-layer security analysis to better design secure systems.
Acknowledgements This work was supported in part by ERC advanced grant
267856, titled “Lucretius: Foundations for Software Evolution”.
References
1. R. Ali, F. Dalpiaz, and P. Giorgini. A goal-based framework for contextual require-
ments modeling and analysis. Requirements Engineering, 15(4):439–458, 2010.
2. I. Araujo and M. Weiss. Linking patterns and non-functional requirements. In Pro-
ceedings of the Ninth Conference on Pattern Language of Programs (PLOP 2002), September
8-12, 2002, 2002.
3. E. Fernandez-Buglioni. Security patterns in practice: designing secure architectures using
software patterns. John Wiley & Sons, 2013.
4. T. Li and J. Horkoff. Dealing with security requirements for socio-technical systems: A
holistic approach. In the 26th International Conference on Advanced Information Systems
Engineering (CAiSE’14). Accepted, 2014.
5. H. Mouratidis, M. Weiss, and P. Giorgini. Modeling secure systems using an agent-
oriented approach and security patterns. International Journal of Software Engineering
and Knowledge Engineering, 16(3):471, 2006.