An Approach for Modeling Information Systems
Security Risk Assessment
Subhas C. Misra
1
, Vinod Kumar
2
and Uma Kumar
2
1
Carleton University, 1125 Colonel By Drive, Ottawa, Ontario, Canada K1S 5B6
2
Carleton University, 1125 Colonel By Drive, Ottawa, Ontario, Canada K1S 5B6
Abstract. In this paper, we present a conceptual modeling approach, which is
new in the domain of information systems security risk assessment. The ap-
proach is helpful for performing means-end analysis, thereby uncovering the
structural origin of security risks in an information system, and how the root-
causes of such risks can be controlled from the early stages of the projects. The
approach addresses this limitation of the existing security risk assessment mod-
els by exploring the strategic dependencies between the actors of a system, and
analyzing the motivations, intents, and rationales behind the different entities
and activities constituting the system.
1 Introduction
Security is considered to be a very important issue while developing complex informa-
tion systems. Security risk assessment is a systematic process that includes identifica-
tion of the risk, determining the consequences of the risk and managing risks [1,9]. In
this paper, we present an approach which is new in the domain of modeling informa-
tion systems security risk assessment, based on the concept of analysis of the strategic
dependencies between the actors of a system [3,8].
Before presenting our approach, we first review the relevant previous work in this
area. Several risk assessment methodologies tailored towards specific domains are
available in the existing literatures [1]. For instance, SEISMED is a methodology that
provides a set of guidelines on IT security risk analysis for health care IT personnel
and ODESSA is a methodology that provides health care data security [1]. COBIT
project addresses the good management practices for security and control in IT for
world-wide endorsement by various organizations [5]. CRAMM is a risk analysis
methodology that was developed with an aim of providing a structured approach to
manage security for computer systems [2]. The most influential of the above for our
work is the CORAS methodology that bases itself on UML-based modeling [14].
In contrast to the previously proposed modeling techniques in the domain of security
risk assessment, we use the concept of modeling intentional relationships using i* [3]
between actors of a project. Similar studies have been conducted in the areas of re-
quirements engineering [6], process verification and validation [8], trust in informa-
tion systems (e.g., [8]). Our modeling technique adopts ideas of two methodologies –
C. Misra S., Kumar V. and Kumar U. (2005).
An Approach for Modeling Information Systems Security Risk Assessment.
In Proceedings of the 3rd International Workshop on Security in Information Systems, pages 253-262
DOI: 10.5220/0002561702530262
Copyright
c
SciTePress
CORAS and actor-dependency framework. In contrast to CORAS, our proposed
method described in our paper uses agent-oriented approach and allows modeling
security by modeling dependencies between actors of the system.
In this paper, we show how we can use the concepts of modeling intentional de-
pendencies between actors to explore the structural origins of risks in an information
security assessment project. Although the concept of actor-dependency is not new, the
way we use these concepts and extend them to analyze security risks is novel to our
work, and requires ingenuity of the modelers. In this paper, we have discussed a
methodology that can help one to model and explore the strategic security risks, the
actual causes and intentions of the different actions one can undertake, the risks in-
volved in undertaking those actions, and finally, model how one can control those
risks from the inception of a project.
i* framework is an agent-oriented modeling methodology that was developed for
modeling intentional dependencies among strategic actors, who can be social agents,
organizations or other active units. Actors depend on one another for achieving goals,
performing tasks and furnishing the resources. Using this approach one can model
various hard-to-formalize phenomena such as goal, belief, ability, and so on. How-
ever, i* is insufficient for risk assessment. In this paper we alter some modeling ele-
ments of i* and show how the altered framework can be used to perform risk assess-
ment. Contributions of our work are the development of a new methododology to
represent assets, vulnerabilities and security features using i* elements and the intro-
duction of different new diagrammatic elements for representing risk value and asset
value.
Our current work has been inspired by the work done in [9] to model security using
Tropos. The paper [9] introduces several new security-related concepts and shows
how the concepts can be represented diagrammatically. We adopt the security feature
concept introduced in this paper. However the paper on security modeling with Tro-
pos does not cover such concepts as assets, security risk, asset and risk value that are
central for security risk assessment.
In our work we referred to a widely recognized standard for security risk manage-
ment named the Australian/New Zealand AS/NZS standard [12]. The risk manage-
ment process described in AS/NZS consists of five stages: identify context, identifying
risks, analyze and evaluate risks, identify and document treatment. We will show how
to use our extended i* framework to accomplish the entire cycle of the risk manage-
ment process.
2 Modeling Dependencies between Strategic Actors
The concepts associated with modeling actor dependencies have their roots in Re-
quirements Engineering (RE). RE methodologies can be used to model organization
goals, processes, relationships, and actors. In order to perform very good quality risk
assessment one is required to understand the organization clearly.
In this section, we briefly discuss the actor dependency concept using i* (see, for
example, [3], [6], [8] and [13] to learn more about this area of research, and its appli-
cability to various domains). Although i* is a “brain-child” of software RE research, it
254
can be used as a powerful tool to model organizational tasks, processes, actors and
goals. In order to model, and solve this problem, two actor-dependency diagrams are
used: the Strategic Dependency Model (SD), and the Strategic Rationale Model (SR).
In the interest of brevity, only brief introductions of SD and SR are provided. Inter-
ested readers are referred to the literatures mentioned in Section 1 for learning further
details. SD diagrams are used to model dependencies between actors, while SR dia-
grams are used to model internally why each actor has those dependencies. All de-
pendencies comprise of a “depender”, a “dependee”, and a “dependum”. “Depender”
depends on a “dependee” to get “dependum”. There can be different nature of de-
pendencies in SD diagrams: goal dependency, task dependency, resource dependency,
and softgoal dependency. Fig.1 is an example of a SD model. It represents the de-
pendencies between actors of a Card Payment System.
Fig. 1. SD Diagram for a Card Payment System
Fig. 2. Example of Different Types of Actors
Actors can be modeled as a generalized relationship among agents, position and
role [7]. In general, agents represent physical manifestation of actors. Agents occupy a
position in SD diagrams. In fact, a position is a generalization of an agent. Fig.2
shows an example of different types of actors. Without much elaboration, we present
the SR diagram in Fig.3.
255
Fig. 3. SR diagram for a Card Payment System
3 Security Risk Assessment
Prior to this work there was no method of using i* framework for security risk assess-
ment. We slightly extend i* framework by altering some i* elements and describe
how risk assessment can be done using the extended framework.
Before we describe how to extend i* for risk assessment, we introduce basic con-
cepts of risk management and introduce phases of risk management process according
to AS\NZS -- widely referred standard of security management.
3.1 Security Risk Components
Asset: Asset is anything that has value and therefore it has to be protected. Examples
of assets are information/data, physical equipment, people and their knowledge, qual-
ity of service, image and reputation of company. Information assets have to be pre-
served in context of confidentiality, integrity, and availability.
Asset value: Asset values are used to describe the importance of assets to a busi-
ness. Asset value should reflect potential impact of unwanted incidents that can hap-
pen to the asset. Asset value can be discreet (in this case it is an element of some finite
set, for example {HIGH, MEDIUM, LOW}), or continuous (a number from some
predetermined segment, for example [0,1]).
Security Feature: When we deal with information security assets, the assets
should be protected in the context of privacy, availability or integrity. Privacy, avail-
ability and integrity are different security features of an asset. Harm provided to dif-
ferent security features of the same asset can lead to different consequences to a busi-
ness. Thus, we can assign different values to different security features.
256
Threat: A threat is a potential cause of a harm of an asset. A threat leads to re-
duction of asset value. In information security settings, a threat leads to the loss of
confidentiality, integrity or privacy of information. Threats may be acts of nature (i.e.,
floods, fires, earthquakes), acts of unqualified personal, hackers, and so on As we
consider an agent-oriented modeling technique, we will deal only with threats who can
be considered as actors acting in an improper way. Threat actors may act in an im-
proper way both intentionally or accidentally.
Vulnerability: Vulnerability is a weakness of the system through which a threat
can harm an asset. It is a condition that can allow a threat to harm an asset more fre-
quently or more intensively. For example, if a threat is a hacker who intends to access
a website illegally, the possible vulnerabilities may be lack of firewall, firewall is
configured incorrectly, or software security patches are not up-to date. To gain some
impact on an asset, a threat should exploit vulnerability.
Unwanted incident (Attack): In the settings of agent-oriented approach, un-
wanted incidents (or attacks) are malicious actions of actors that could harm assets.
Risk: Security risk is a potential that a threat will exploit vulnerability to make
some harm to an asset. We assume that a risk will be associated to an attack. The
potential is measured by a risk value. Risk value should be determined from a value of
all assets that are affected by the attack, and from potential frequency of the attack.
3.2 Risk Management Process
AS\NZS is a widely recognized risk management standard. The standard specifies a
risk management process. The process is interactive and its every iteration consists of
several stages. The stages are:
Identification of context, where the target system is described and assets are
identified.
Identification of risks, where threats, vulnerabilities and possible unwanted
incidents (attacks) are identified.
Analysis and evaluation of risks, where frequency of attacks and risks values
are identified, and risks are prioritized.
Identification and documentation of treatment
We will show how to extend the i* framework so that it can be applied on every
stage of the risk management process.
Identification of context: In this stage of the risk management process, the target
system under assessment is described and assets are identified. To describe the system
being assessed, we use the SD diagram of i*. We identify actors of the system and
intentional dependencies among the actors. We put the actors and their dependencies
in the SD diagram.
The next task is to identify assets. According to CORAS, an asset is everything
that has value for stakeholders of the project. As agent-oriented modeling approach
does not involve the concept of stakeholder. We may view an asset as anything that
has value for one of the actors of the system. The actor, who considers that the asset
has value for him, has a goal to preserve the asset. If an asset has value for several
257
actors of the system, then all the actors should have a goal to preserve the asset. Goals
associated with the preservation of assets are depicted by internal goal or softgoal
elements in the SR diagram. Owner of a credit card can have two assets: card pass-
word and account information. Fig.4 shows how the assets are depicted as internal
goals of Card Holder in SR diagram. The goals associated with preservation of attacks
are subgoals of a generalized goal “Preserve Assets”
The next step is to identify security features that should be protected. The secu-
rity features are depicted as internal goals and sofgotals of an actor. We use softgoal
to depict security feature when it is hard to formalize the criteria that the security
feature is protected. Security features are linked with goals associated with assets by
the mean-ends dependencies. Fig. 5 shows the security features of assets of a Card-
holder. The next step is to assign values to assets and security features. If a security
feature corresponding to an asset is identified, we assign a value only to the security
feature. The assigned value should reflect importance of an asset or security feature to
the business.
Fig. 4. Assets depicted as internal goals in the SR diagram
If we want to assign value to an asset or a security feature, we assign a value to
the corresponding goal or softgoal. We represent values on the top of i* goal and
softgoal elements. If we use discreet values, we represent values as star marks (“*”).
The example is shown in Fig.5.
Identification of risks: At this step of the risk management process, threats, vulner-
abilities and possible unwanted incidents (attacks) should be identified. So far, we
identified and put in SR and SD diagrams elements that are related to the normal op-
eration of the system. Now we need to consider potential threats and attacks and de-
termine further dependencies between actors. We depict the newly determined secu-
rity-related external dependencies in SR diagram. Fig. 6 shows security-related de-
pendencies between Card Holder and Terminal Owner.
258
Fig. 5. Security features of assets of a Cardholde
hyphen are subject to a special rule. If the first word can stand alone, the second word
should be capitalized. The font sizes are given in Table 1.
Here are some examples of headings: "Criteria to Disprove Context-Freeness of
Collage Languages", "On Correcting the Intrusion of Tracing Non-deterministic
The next task is to identify threats. As we use an agent-oriented modeling tech-
nique, threats are treated as actors acting in an improper way. As mentioned before,
since they may act in an improper way intentionally or accidentally, in both cases, the
improper action is called an attack. Virtually any actor of the system may act as an
attacker. For malicious actors we introduce a special role: “Actor as an attacker”.
Attack is depicted in SR diagram as an internal task of an attacker.
To conduct an attack, an attacker must exploit vulnerabilities. Thus exploitations
of vulnerabilities are subtasks of the task associated with the attack and they are linked
*
* * ***
V
Fig. 6. Security-related dependencies between Card Holder and Terminal Owner
* * * * * *
259
with task decomposition links. We note task elements corresponding to the exploita-
tion of vulnerabilities by letter “V” on the right of the element (Fig. 7).
Fig. 7. Representation of task elements corresponding to the exploitation vulnerabilities
If one actor depends on another actor who is an attacker, the attacker may provide a
number of attacks to make the dependency not viable. Making a dependency not vi-
able is depicted by a contribution link connecting to dependum. The links originate
from the tasks associated with the attacks. For attacks that make dependency totally
unviable, link is labeled as a break link. This can be seen in the example in Fig.8.
V
Fig. 8. Representation of attacks that make the dependency totally unviable. The link is
labeled as a break link.
V
V
*
*
Fig. 9. Depiction of risk values
! ! !
260
Fig. 10. Depiction of treatment measures in an SR Diagram
! !
!
V
V
***
Risk Analysis and Evaluation: The goal of this step of the risk management process
is to determine values of risks. In our approach, we have seen that a risk is associated
with an attack. To estimate a risk value, we need to estimate possible frequency of the
attack associated with the risk. Then we need to take into consideration values of all
the assets that can be affected by the attack.
If we use discreet risk values, we can represent risk values by the exclamation
mark (“!”) at the top of a task element associated with an attack. For example, three
exclamation marks depict that risk value is high, whereas one exclamation mark depict
that the risk value is low. Fig. 9 shows an example of how risk value is depicted. If
continuous risk values are used, the values can be depicted as numbers on the top of
the corresponding task element.
Identification and documentation of treatment: To protect their assets, in other
words, to reduce security risks, actors may want to provide countermeasures against
possible attacks. An actor who provides defensive measures plays a role “Actor as a
defender”. The countermeasures are represented as internal tasks of defending actors.
The aim of treatment measure is to fix some vulnerability, and thus to reduce the im-
pact or the frequency of the attack. To show that a treatment measure is aimed at
fixing vulnerability, we draw a negative contribution link connecting the task repre-
senting the treatment measure with the task representing exploitation of the vulnerabil-
ity. Fig.10 illustrates how treatment measures are depicted in SR diagram.
261
4 Conclusion
We have outlined a new technique for modeling information system security risk
analysis using the concept of actor-dependency, and extending its scope to the domain
of security risk management. The technique can reason about the opportunities, vul-
nerabilities, changes, and risks that are associated with information systems security,
and can incorporate prominently the issues related to security risk.
i* was not originally designed for studying security risks. We have leveraged the
concept of actor-dependency of i*, extended it to address its limitations for use in
security risk management We recommend further research to design a new language
for modeling actor-dependencies in security risk management.
References
1. Aagedal, J.O., Braber, F. D., Dimitrakos, T., Gran, B.A., Raptis, D., Stolen, K.: Model-
Based Risk Assessment to Improve Enterprise Security. In Proceedings of the Fifth Inter-
national Enterprise Distributed Object Computing Conference (EDOC 2002), September
17-20, Lausanne, Switzerland (2002)
2. Barber, B., and Davey, J.: The use of the CCTA Risk Analysis and Management Methodol-
ogy (CRAMM) in health information systems. In: Medinfo 92. Amsterdam: North Holland
(1992) 1589-1593.
3. Chung, L., Nixon, B.A., Yu, E., Mylopoulos, J. Non-Functional Requirements in Software
Engineering, Kluwer Academic Publishers (2000)
4. Common Criteria Organization: Common Criteria for Information Technology Security
Evaluation. http://www.commoncriteria.org, accessed: 2004 (2002)
5. Control Objectives for Information and Related Technology, 2002. “COBIT”.
http://www.isaca.org/ct-denld.htm (2002)
6. Donzelli, P., Bresciani, P.: An Agent-Based Requirements Engineering Framework for
Complex Socio-Technical Systems. In Proceedings of SELMAS 2003, Portland (2003)
7. Dubois, E., Yu, E. and Petit, M.: From Early to Late Formal Requirements: a Process Con-
trol Case Study. In Proc. 9th International Workshop on Software Specification and De-
sign, April 16-18, Ise-Shima, Japan (1998) 34-42.
8. Gans, G., Jarke, M., Kethers, S., Lakemeyer, G., Ellrich, L., Funken, C., Meister, M.: Re-
quirements Modeling for Organization Networks: A (Dis)Trust-Based Approach, In Proc.
5th IEEE International Symposium on Requirements Engineering, Toronto (2001)
9. Mouratidis, H., Giorgini, P., Manson, G., Philip, I.: A Natural Extension of Tropos Meth-
odology for Modeling Security. In Proceedings of the Agent Oriented Methodologies
Workshop (OOPSLA 2002), November, Seattle-USA (2002)
10. Reactive System Design Support: RSDS. http://www.kcl.ac.uk., Sandia National Laborato-
ries (2002)
11. Schechter, S.E: Computer Security & Risk: A Quantitative Approach. Ph.D. Thesis, Com-
puter Science, Harvard University (2004)
12. Standards Australia: AS/NZS 4360: Risk Management. AS/NZS 4360 (1999)
13. Sutcliffe, A.G. and Minocha, S: Linking Business Modeling to Socio-technical System
Design, In Proceedings of CaiSE’99 (1999) 73-87.
14. Vraalsen, F., Braber, F.D., Hogganvik, I., Lund, S., Stolen, K: The CORAS Tool-
Supported Methodology. SINTEF Report, Report # STF90A04015, February, Norway
(2004)
262