Uml-Based Modeling and Analysis of Security Threat

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/220344852
Uml-Based Modeling and Analysis of Security Threats.
Article in International Journal of Software Engineering and Knowledge Engineering · September 2010

DOI: 10.1142/S0218194010004980 · Source: DBLP
CITATIONS READS
21 2,798
3 authors, including:
Jun Kong Dianxiang Xu

North Dakota State University University of Missouri - Kansas City
65 PUBLICATIONS 670 CITATIONS 140 PUBLICATIONS 2,039 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Engineering ethics and morality View project
The future of programmable security controls View project
All content following this page was uploaded by Jun Kong on 18 March 2015.
The user has requested enhancement of the downloaded file.

January 18, 2011 11:16 WSPC/117-IJSEKE - SPI-J111 0218-1940
S0218194010004980
International Journal of Software Engineering

and Knowledge Engineering
Vol. 20, No. 6 (2010) 875–897
c World Scientific Publishing Company
DOI: 10.1142/S0218194010004980
UML-BASED MODELING AND ANALYSIS

OF SECURITY THREATS
JUN KONG
Department of Computer Science
North Dakota State University
jun.kong@ndsu.edu
DIANXIANG XU
National Center for the Protection
of the Financial Infrastructure
Dakota State University
dianxiang.xu@dsu.edu
XIAOQIN ZENG
Department of Computer Science
Hohai University, China
xzeng@hhu.edu.cn
Received 12 January 2009

Revised 10 September 2009
Accepted 26 October 2009
Poor design has been a major source of software security problems. Rigorous and
designer-friendly methodologies for modeling and analyzing secure software are highly
desirable. A formal method for software development, however, often suffers from a gap
between the rigidity of the method and the informal nature of system requirements. To
narrow this gap, this paper presents a UML-based framework for modeling and analyz-
ing security threats (i.e. potential security attacks) rigorously and visually. We model
the intended functions of a software application with UML statechart diagrams and
the security threats with sequence diagrams, respectively. Statechart diagrams are auto-
matically converted into a graph transformation system, which has a well-established
theoretical foundation. Method invocations in a sequence diagram of a security threat
are interpreted as a sequence of paired graph transformations. Therefore, the analysis
of a security threat is conducted through simulating the state transitions from an initial
state to a final state triggered by method invocations. In our approach, designers directly
work with UML diagrams to visually model system behaviors and security threats while
threats can still be rigorously analyzed based on graph transformation.
Keywords: Graph transformation; visual modeling and analysis; security threats.
875
S0218194010004980
876 J. Kong, D. Xu & X. Zeng
1. Introduction
Many techniques (i.e. cryptography and firewall) have been proposed to protect
computer systems at the network and operating system levels. However, they are
inadequate for application-level security because they lack the knowledge of appli-
cation semantics [35]. Poor software design has been a major source of security
problems. For example, around 50 percent of the security flaws uncovered during
Microsoft’s “security push” in 2002 were closely related to design-level problems [9].
Rigorous and designer-friendly methodologies for modeling and analyzing secure
software are highly desirable.
Formal methods can offer a solid foundation for achieving a high degree of
trustworthiness through formalization and verification of security properties [34].
Application of formal methods, however, requires considerable expertise and often
incurs a steep learning curve. This significantly reduces users’ interest in adopting
formal methods for real-world software development processes. In general, a visual
language can encourage users’ involvement and facilitate the communication of
design decisions, but often lacks precise semantics. This paper presents a UML-based
framework for modeling and analyzing secure software. This framework is featured
by using UML [28] as the modeling language while supporting rigorous analysis
of security threats. This narrows the gap between visual modeling and rigorous
analysis.
UML is a widely applied standard language for visually modeling object-oriented
systems. Our approach uses UML statechart diagrams to model intended func-
tions and UML sequence diagrams to specify security threats. Security threats are
misuses and anomalies that violate security policies or goals (e.g. confidentiality,
integrity, and availability) [35]. Due to the informal nature of UML notations, how-
ever, it is difficult to automate the analysis of security threats. In order to support
rigorous analysis, our approach automatically translates a UML statechart diagram
to a graph transformation system [19], which provides a solid foundation to simu-
late the execution of state transitions. Graph transformation offers a computational
paradigm of mathematical precision and visual specification [33]. It defines computa-
tion in a multi-dimensional fashion based on a set of rewriting rules, i.e. productions.
Each production consists of two parts: a left graph and a right graph, the difference
of which visually indicates the changes caused by a computation. With a graphical
representation of the state of a software artifact in the execution, the behavioral
semantics can be inherently specified through a sequence of productions, i.e. tran-
sitions from one graph (representing the current state) to another (representing a
new state). In our approach, we exploit graph transformation as the underlying
theoretical foundation for rigorous verification of security threats. More specifically,
a sequence diagram of security threat includes a sequence of actions. Each action
in a security threat triggers a state transition, which is executed through graph
transformation. If the system finally stays at some regular state after the attack
of a security threat, it indicates that the system is vulnerable to the threat since
S0218194010004980
UML-Based Modeling and Analysis of Security Threats 877
the system takes the special combination of sequenced actions in a security threat
as normal actions. After we verify and identify vulnerable security threats against
intended functions, we need to mitigate identified vulnerabilities. Threat mitigation
is to prevent a specific sequence of actions from being triggered in state transitions.
In summary, this paper presents a rigorous and designer-friendly approach to
modeling and verifying security threats. In this approach, designers directly work
with UML diagrams to model intended functions and security threats. The intu-
itive nature of UML diagrams facilitates the distribution and communication of
software models. This encourages end-users to get involved in the design process.
Since end-users are more familiar with application domains, they may anticipate
those security threats that are not recognized by software developers. Underlying
UML diagrams, our approach applies graph transformation to verify security threats
against intended functions. Therefore, our approach supports rigorous verification
of security threats while it releases designers/users from learning a formal language.
The work reported in this paper is extended from a short conference paper [18]. This
paper, however, gives a more complete specification of our approach and presents a
more comprehensive case study.
The rest of this paper is organized as follows. Section 2 overviews the UML-based
modeling and analysis of security threats. Section 3 illustrates the modeling of
intended functions and security threats through UML diagrams. Section 4 demon-
strates the analysis of security threats based on graph transformation. Section 5
presents a case study. Section 6 discusses related work and Sec. 7 concludes the
paper.
2. UML-Based Modeling and Analysis of Security Threats

A language with a simple and well-understood syntax, possibly with a graphical
representation, facilitates the communication of designs among different develop-
ers. UML [28] has been widely used in modeling software artifacts. It provides a
variety of diagrams for specifying software artifacts from various points of view. For
example, a class diagram models the static structure of a class whereas a statechart
diagram describes the behavior of the objects of a class. While the intuitive nature of
UML notations greatly facilitates distribution and communication of software arti-
facts among different developers, the lack of a precise semantics makes it difficult to
automate verification. A developer has to rely on personal experiences to discover
errors and inconsistencies. These processes are tedious and error-prone. This section
presents a framework for UML-based modeling and analysis of security threats. In
our approach, designers use UML notations to model intended functions and secu-
rity threats, which can be rigorously analyzed through graph transformation. More
specifically, intended functions are modeled in terms of statechart diagrams whereas
security threats are specified as sequence diagrams. Security threats indicate poten-
tial attacks. Unmitigated security threats are vulnerabilities that can be exploited
by attackers. The execution of sequential actions in a security threat can violate
S0218194010004980
Model Intended Model Security

Functions Threats
UML Statechart UML Sequence

Diagrams Diagrams
Formalize
Hierarchical States Analyze
as a Graph Grammar Security Threats
A Graph Secured
Mitigate Statechart
Grammar Security Threats Diagrams
Fig. 1. UML-based modeling and analysis of security threats.
security policies. In order to rigorously verify a security threat against intended

functions, a statechart diagram is given a precise behavioral semantics based on
graph transformation [19]. Based on the semantics, the process of threat analysis is
essentially implemented as state transitions, simulated through graph transforma-
tion. If the system finally stays at some normal state after an attack, it indicates
that the current design is vulnerable to that security threat. We have to mitigate
the security threat by applying security features to protect the system. After the
security features are applied, the design is secured from the anticipated security
threats.
Figure 1 gives an overview of the UML-based modeling and analysis of secu-
rity threats. First, designers model intended functions through UML statechart
diagrams. Accordingly, security threats are modeled through sequence diagrams.
In order to rigorously verify a security threat against intended functions, hierar-
chical relations among states in a statechart diagram are automatically formalized
as a graph grammar [19]. Based on the graph grammar, a graph transformation
system [6, 15, 39] works as a UML virtual machine to execute state transitions,
triggered by sequenced actions in a security threat. The beauty of our approach is
that designers only work with UML diagrams while the underlying graph transfor-
mation system provides a precise semantics to verify security threats. Our approach
proceeds in four steps:
(1) Modeling intended functions according to functional requirements

We elicit requirements of intended functions in terms of use cases [35]. Then,
we model the static structure of a system through UML class diagrams, and
intended functions with UML statechart diagrams. In a UML statechart dia-
gram, actions or events refer to method invocations defined in a class. In order
to verify intended functions, we convert a statechart diagram to a graph trans-
formation system [19].
S0218194010004980
(2) Identifying and modeling security threats according to functions and

security goals
To model security threats, designers interview with end users and domain
experts to collect information of potential attacks. Furthermore, designers can
use security requirements analysis and threat categories, which include mis-
use case based requirements analysis [1, 30] and the STRIDE threat cate-
gories [11, 32], to identify security threats. After potential attacks are identified,
each attack is essentially conducted as a set of sequenced method invocations,
which constitute a security threat and are specified as a sequence diagram.
(3) Verifying security threats
In order to verify identified security threats against functions, hierarchical rela-
tions among states in a statechart diagram of intended functions are automat-
ically formalized as a graph grammar. Then, given an initial state, a graph
transformation system executes state transitions, triggered by method invoca-
tions defined in a security threat, based on the automatically generated graph
grammar.
(4) Modeling threat mitigations
After analyzing security threats against intended functions, if the defined sys-
tem is vulnerable to a security threat, designers must mitigate the identified
security threat. Threat mitigations aim to prevent corresponding state transi-
tions from occurring in a statechart diagram.
The above process is performed iteratively. In the following sections, we use an

online shopping application, which is adapted from Xu and Nygard’s work [35], as
a running example to illustrate our approach. With an online shopping system, a
user can browse products, check price and check inventory online. After the user
chooses a product, he/she can add the selected product to a shopping cart. Finally,
the user fills in a check-out form online and submits the order to a server. In order to
attract users, many online shopping systems provide discount to users. In general,
an online shopping application includes:
(1) An account manager, which keeps track of a customer’s activities in a shopping

session;
(2) A shopping manager, which records products sold to a user and allows a user
to add coupons;
(3) A payment gateway, which validates a user’s payment; and
(4) A database, which records information of products and users.
In the past years, a number of shopping cart systems failed because of security
vulnerabilities (e.g. customers purchased products at a reduced price and customers
ended up paying for others’ purchases). Those vulnerabilities were primarily due to
improper design.
S0218194010004980
3. Modeling Intended Functions and Security Threats

In our approach, a class diagram together with its associated statechart diagrams
constitutes a design model. Each action, which triggers a state transition, refers
to a method invocation. Furthermore, we classify states into three categories: nor-
mal final state (NFS), abnormal final state (AFS), and intermediate state (IS). An
NFS/AFS specifies a state, which a system can stay after several operations. Espe-
cially, an NFS state indicates that the system terminates with a normal condition
while an AFS state indicates an erroneous condition.
Definition 1 (Design Model). A design model is a 2-tuple , ð, where

describes the static structure of a system in terms of UML class diagrams and
ð models intended functions through UML statechart diagrams. In a class diagram,
each method in a class can trigger a state transition and may be exploited by a
malicious user to perform an attack.
Taking an online shopping application as a running example, Fig. 2 presents the
class diagram, which models the static structure. Class Account models a customer
who has some personal information, such as name and address. The methods defined
in class Account allow users to log in the online shopping system, create a new
account, browse available products and log out. Class ShoppingCart represents a
shopping cart, which allows users to display products in a shopping cart, calculate
the total price, submit an order, apply and verify a coupon. Class PayCenter is
designed to process a user’s order, such as verifying a user’s payment or printing a
receipt. Class Products stores some basic information of a product, such as product
Account ShoppingCart PayCenter

name;
Order; Receipt;
address;
Own 1 PlaceOrder();
phoneNumber; 1 Pay GetOrder();
email; calTotalPrice(); ValidatePay();
Login(); showItems(); PrintReceipt();
Create(); AddCoupon();
Browse(); ContinueShopping();
Logout(); VerifyCoupon();
1
Select Store
0..*
ItemToPurchase
Quantity;
Products
UnitPrice;
ProductName; CheckInventory();
Description; CheckPrice();
Quantity; AddItem();
UnitPrice; RemoveItem();
Fig. 2. The static structure of an online shopping system.

S0218194010004980
AddItem
RemoveItem
AddItem
shopping
Purchase CheckPrice Price
calTotalPrice
AddItem CheckPrice ListPrice
orderSubmitted
CheckInventory Browsing PlaceOrder
Inventory CheckInventory showItems
ItemToPurchase statechart diagram ContinueShopping addCoupon

discount
GetOrder Coupon
processing
waitingOrder
Order VerifyCoupon
ValidatePay [InValid]
[Valid]
[pay=valid] [pay=invalid]
Valid Invalid
Confirmed Error addCoupon
PrintReceipt
ShoppingCart statechart diagram
PayCenter statechart diagram
Fig. 3. Statechart diagrams.
name, description and quantity. Class ItemToPurchase records the products in a

shopping cart, such as adding/removing a product to/from the shopping cart.
Figure 3(a) shows the UML statechart diagrama for class ItemToPurchase. An
ItemToPurchase object first goes to state Purchase, which can transit to states
Inventory and Price, respectively by methods CheckInventory and CheckPrice.
Figure 3(b) presents the UML statechart diagram for class PayCenter. A Pay-
Center object first waits for an order in the state waitingOrder. After the order is
received, the PayCenter object enters the state ProcessingOrder. A valid order with
a valid payment transits the object to final state Confirmed through method invo-
cation ValidatePay. Otherwise, the object enters state Error. Figure 3(c) illustrates
the UML statechart diagram for class ShoppingCart. A ShoppingCart object is in
the composite state shopping in the beginning. The shopping state includes two
direct substates: Browsing and ListPrice. Browsing is the default substate of the
composite state shopping. The method invocations calTotalPrice and showItems can
trigger the state transition between Browsing and ListPrice. The method invocation
addCoupon can trigger the state of a ShoppingCart object from shopping to dis-
count. The composite state discount includes three direct substates: Coupon, Valid
and Invalid. The default substate is Coupon. The method VerifyCoupon verifies the
validity of a coupon. A valid coupon triggers a state transition from Coupon to Valid.
Otherwise, the state goes to Invalid. The method ContinueShopping allows a user
to continue shopping, and triggers the state transition from discount to shopping.
a We only present the UML statechart diagrams for classes ItemToPurchase, PayCenter and Shop-
pingCart which are relevant to the following discussions about security threats.
S0218194010004980
After a user completes shopping, he/she can place the order by calling method
PlaceOrder, which triggers a state transition from shopping to orderSubmitted.
Figures 2 and 3 constitute a design model for an online shopping application.
Given a design model, a security threat is a potential misuse or anomaly that vio-
lates some security goals. More specifically, given a design model, a security threat
refers to a number of sequenced method invocations that can violate security goals
or policies. However, an arbitrary set of method invocations does not necessarily
make up a security threat. Multiple threats can constitute a more complex threat.
Normally, a method invocation in a security threat is an action legitimately sup-
ported in a design model. However, certain combinations of legitimate individual
actions may become vulnerabilities. Sequence diagrams provide a natural means to
model those sequenced method invocations that constitute a security threat.
Definition 2 (Security Threat). Given a design model , ð, a security threat is a

sequence diagram. The sequence diagram records a sequence of method invocations,
which can be used by malicious users to undermine security goals. A security threat
is meaningful only if it is associated with a class diagram since each action in a
security threat essentially refers to a method defined in a class.
Without a good design, an online shopping system could be vulnerable to dif-
ferent kinds of threats, such as “a customer purchases products at a reduced price”,
“a customer pays for another customer’s purchase”, “a customer cancels another
customer’s order” and so on [35]. This section discusses a security threat, called
coupon fraud. In order to attract customers, an online shopping system in general
gives customers a reduced price by using coupons. The application of a coupon
needs to observe some restrictions. For example, a coupon can be applied only if
the total price exceeds a certain threshold or a coupon can only be applied to some
specific products. A coupon fraud means that a coupon is applied without com-
plying with its restrictions. Corresponding to the design model of Figs. 2 and 3,
Fig. 4 models the threat of a coupon fraud, which applies a coupon to unqualified
products but still gets a reduced price. A malicious user first logins his account,
browses products, and checks inventory as usual. In order to carry out a coupon
fraud attack, this user adds a product, which qualifies for a coupon, through the
method AddItem, and then correspondingly adds a coupon to the shopping cart
through method AddCoupon. The coupon is validated through the method Verify-
Coupon, and a discount is applied to the shopping cart. Later, this user intentionally
removes the qualified product through the method RemoveItem while the discount
is still in the shopping cart. At this point, the user has successfully performed a
coupon-fraud attack.
The verification of a security threat against a design model is conducted as a
sequence of state transitions. Given a design model, we apply sequenced actions in a
security threat to trigger state transitions from an initial state. If the system finally
stays in a normal state after the verification of a security threat, it indicates that
the system takes a security threat as normal actions and thus is vulnerable to such
S0218194010004980
Account ItemToPurchase ShoppingCart PayCenter
Login
Browse
CheckInventory
AddItem
AddCoupon
VerifyCoupon
Continue
Shopping
RemoveItem
calTotalPrice
PlaceOrder
GetOrder
ValidatePay
Fig. 4. The threat of a coupon fraud.
a threat. It is time-consuming and error-prone to manually verify a security threat

against intended functions. The next section discusses a rigorous and automatic
approach to analyzing security threats.
4. Analysis of Security Threats

This section presents an approach to automatically analyzing security threats
against a design model. First, we discuss the graph grammar — a theoretical foun-
dation for the analysis of security threats; then, we present how to formalize hierar-
chical relations among states as a graph grammar; and finally we use a coupon-fraud
example to illustrate the analysis of security threats through graph transformation.
4.1. Graph grammar

Visual languages [4] directly model structures and concepts in a visual fashion [7].
Graph grammars with their well-established theoretical background can be used as
natural and powerful syntax-definition formalism [27] to specify visual languages,
and the parsing algorithm based on a graph grammar may be used to check the
syntactical correctness and to interpret the language semantics.
Various grammar formalisms [5, 17, 24, 29, 38] have been proposed for different
purposes. In general, nodes are used to represent objects and edges to model rela-
tions between objects in an abstract syntax. A graph grammar consists of a set of
productions, each of which has two graphs, called left graph and right graph. For
example, Fig. 5 presents a production, where the left graph includes a non-terminal
node XN modeling a state configuration while the right graph presents a two-level
S0218194010004980
Left graph Right graph

XT
XN :=
YT ZT
Fig. 5. A production.
tree. This production formalizes the hierarchical structure of a state configuration

starting with state X as the root down to two single states Y and Z.
Applying a production to a graph (i.e. a host graph) is referred to as a graph
transformation, which can be classified as an L-application (in a forward direction)
or R-application (in a reverse direction). A redex is a sub-graph in the host graph
which is isomorphic to the right graph in an R-application or to the left graph in
an L-application. A production’s L-application to a host graph is to find in the host
graph a redex of the left graph and replace the redex with the right graph while
the R-application is a reverse replacement (i.e. from the right graph to the left).
The language, defined as all possible graphs that only have terminal objects, can
be derived using L-applications (i.e. a generating process) from an initial graph.
On the other hand, R-applications (i.e. a parsing process) are used to verify the
membership of a graph.
In the case of linear textual languages, it is clear how to replace a non-terminal in
a sentence by a corresponding sequence of (non-)terminals. However, with a visual
language that has two-dimensional relationships among the language elements, a
more complicated mechanism is needed to establish relationships between the sub-
stitute of a redex and its adjacent elements.
There are three approaches to embedding a graph into a host graph [24]:
• Implicit embedding: formalisms such as picture layout grammars [8] and con-
straint multiset grammars [22] do not distinguish between a node and an edge.
Relationships are implicitly defined as constraints over their attribute values.
Attribute assignments within productions have the implicit side effect that cre-
ates new relationships to unknown context elements. Users are, therefore, not
always aware of the consequences of attribute assignments, and a parser requires
considerable time to extract implicitly defined knowledge about the relationships
from attributes and constraints.
• Embedding rules: some graph grammars, such as the NLC graph grammar [26],
have separate embedding rules which allow the redirection of arbitrary sets of
relationships from a redex to its substitute. This approach is easy to implement.
However, the embedding rules are often difficult to understand and all known
parsing algorithms for productions with embedding rules are either inefficient or
imposing very strict restrictions on the left and right graphs of the productions.
S0218194010004980
Furthermore, embedding rules are only able to redirect or re-label existing rela-
tionships. They cannot be used to establish new relations between previously
unconnected nodes.
• Context elements: context elements can be used to establish the relationships
between a newly created graph and the host graph. This approach is the easiest
to understand, but an unrestricted use of context elements may complicate the
productions. Furthermore, it is difficult to rewrite elements that may participate
in a statically unknown number of relationships.
Without limiting to a specific grammar formalism, this paper uses the Spatial
Graph Grammar (SGG) [17] as the underlying grammar formalism to illustrate
our approach. The SGG formalism uses labeled graphs to support the linking of
newly created graphs into a parsed graph (traditionally called embedding). The
node structure enhanced with additional visual notations (e.g. vertices) in the SGG
simplifies the transformation specification and also increases the expressiveness. The
SGG combines the approaches of the embedding rule and the context elements to
solve the embedding problem. By introducing context information, simple embed-
ding rules can be sufficiently expressive to handle complicated visual programs.
The time complexity of the SGG parser is critical to the overall system perfor-
mance. The SGG parser uses efficient string matching technique to search for an
appropriate substructure which matches the right graph of a production based on
spatial relations. Under the confluence condition, the SGG parser has a polyno-
mial time complexity [17]. Informally, the confluence requires that different orders
of production applications achieve the same result, and therefore the parsing only
tries one parsing path.
4.2. Formalizing hierarchical states as a graph grammar

The hierarchical structure of states empowers statechart diagrams in system mod-
eling while it also challenges the recognition of source states due to state explosion:
a small number of states can cause large combinations. The state explosion can
be effectively addressed by a graph grammar in which a small set of productions
can specify a large number of different well-formed state configurations. Instead
of manually designing the graph grammar, an automation mechanism is used to
formalize hierarchical states as a graph grammar. In the derived graph grammar, a
non-terminal node indicates a state configuration, and a terminal node represents
a single or composite state. Each production specifies the hierarchical relationships
between a composite state and its direct sub-states while a graph grammar inte-
grates those local hierarchical relationships together and is able to derive all state
configurations complying with the given statechart diagram.
More specially, each state S in a statechart diagram generates a terminal node
ST and a non-terminal node SN . From the semantic point of view, the terminal
node ST represents the state itself, and the non-terminal node SN indicates a state
configuration starting from S down to substates contained by S. For example, in the
S0218194010004980
BusyN
Busy
BusyT Scan
Fig. 6. A state configuration.
(a) A concurrent composite (b) A sequential

state composite state
sT sT
sN := sN :=
x1N …… xiN x1N
……
(c) A simple state sT
sN := sT sN :=
xiN
Fig. 7. Production generation.
state configuration as shown in Fig. 6, the non-terminal node Busy N denotes the
state configuration starting from state Busy and the terminal node Busy T means
state Busy itself.
Productions are automatically generated according to the following rules:
• As visualized in Fig. 7(a), a concurrent composite state s with i direct substates
(x1 , . . . , xi ) generates a production such that the left graph includes only one
non-terminal node sN and the right graph is a two-level tree having node sT as
the root with i child nodes from x1N to xiN .
• Figure 7(b) depicts that a sequential composite state s with i direct substates
(x1 , . . . , xi ) generates i productions. In each production, the left graph has only
one non-terminal node sN , and the right graph is a two-level tree having node sT
as the root with one child node xmN (1 ≤ m ≤ i).
• Figure 7(c) shows a simple state s that generates a production such that the
left/right graph is made up of one node sN/sT .
4.3. Analyzing security threats

Based on the generated graph grammar, state transitions are executed through
paired graph transformations. More specifically, the recognition of a source state
can be performed by iterative R-applications in a bottom-up fashion until the cor-
responding non-terminal node of the source state is recognized or an initial graph
(denoted as λ) is reached. On the other hand, generating a target state is realized
S0218194010004980
Active state Method

State Diagram
configuration invocation
Derive Validate &

Recognize
Graph grammar
Source state
Generate
Target state Transit New state configuration
Fig. 8. Execute state transition based on graph transformation.
through iterative L-applications in a top-down fashion. However, different state

entries and pseudostates complicate the process of target-state generation, which
requires a sophisticated control mechanism to control the sequence of production
applications. Such a control mechanism is defined as a mapping between a state
entry and a production. For example, a default entry is mapped to such a production
that the left graph is the non-terminal node of the parent state and the right graph
is a two-level tree, where the leaf is the non-terminal node of the default sub-state.
Figure 8 describes the execution of state transitions based on a graph grammar. A
detailed description about the behavioral semantics of statechart diagrams based
on graph transformation can be found at [19].
Definition 3 (State Transition). Given a design model , ð, GT = P, C is a

graph transformation system, where P designates the graph grammar automatically
derived from ð, and C specifies a mapping among productions and method invo-
cations. Triggered by a method m defined in , a state transition is implemented
as paired graph transformations PGT = reg, genm , where reg = (pi , . . . , pj ) is a
parsing process (i.e. R-applications), which applies a sequence of productions from
pi to pj to identify the source state(s) while gen = (pm , . . . , pn ) is a generating
process (i.e. L-applications) to generate the target state(s).
Definition 3 defines state transitions in terms of graph transformation. For exam-
ple, the hierarchical states in Fig. 9(a) are precisely formalized as a graph grammar
in Fig. 9(b). Based on the graph grammar, state transition is executed through a
combination of parsing and generating processes. If an object stays in state J as
shown in Fig. 9(c), the state transition triggered by event e3 is realized through
a sequence of graph transformations. First, Production 7 is applied in the form of
R-application to recognize the source state; then, Productions 1, 3 and 5 are used
in the form of L-application to generate the target states as shown in Fig. 9(d).
S0218194010004980
(a) A Statechart (c) Current

(b) A Graph Grammar
Diagram state
Z
<P1-P2> <P5> DN := DT J
D
λ := ZN JN
(d) New states
<P6> EN := ET
e1 e2 <P3-P4> ZT ZT Z
ZN :=
E J DN EN <P7> JN := JT D
e3
Fig. 9. State transition based on graph transformation.
Based on Definition 3, the analysis of a security threat against intended functions

is essentially a sequence of state transitions. More specifically, a security threat,
represented as a sequence diagram, is made up of a sequence of method invocations.
Those method invocations trigger state transitions of a system. If the system finally
stays in a normal state (i.e. an NFS state) after verifying a security threat, it means
the system is vulnerable to such a threat.
Definition 4 (Threat Verification). Given a design model , ð and a secu-
rity threat ST, the threat-driven verification is executed as a sequence of paired
graph transformations: S1 →PGT1 S2 , S2 →PGT2 S... 3 SN −1 →
PGTN −1
SN , or simply
PGT
S1 → SN , where Si is a state in ð and S1 is the initial state of a system. PGTi is
a paired graph transformation as defined in Definition 3. A design is secured from
the security threat ST only if SN ∈ AFS after a threat-driven verification. Figure 10
summarizes threat analysis through graph transformation.
___________________________
Analysis (State, Threat, initState)
1: Formalize the hierarchical states in a state chart diagram State as

a graph grammar GG;
2: Put the sequenced method invocations in a security threat
Threat into queue actions;
3: currentState initState;
4: While (set actions is not empty) do
5: Retrieve and delete the first action act in the queue;
6: parsing(GG, act, currentState);
7: Generating(GG, act, newState);
8: currentStates newStates;
9: End while
10: if (currentState∈AFS) then
11: the design model is secured from Threat
12: End if
Fig. 10. Analyzing a security threat.

S0218194010004980
P1 PurchaseN := PurchaseT P8 CouponN := CouponT P15 shoppingT

P9 InvalidN := InvalidT shoppingN :=
P2 PriceN := PriceT BrowsingN
P3 InventoryN := InventoryT P10 BrowsingN := BrowsingT
P11 ListPriceN := ListPriceT
P16 discountT
(a) The graph grammar for
P12 shoppingT discountN :=
ItemToPurchase statechart diagram ValidN
shoppingN :=
ListPriceN
P4 waitingOrderN := waitingOrderT P17 discountT
P13 discountT
P5 processingOrderN := processingOrderT discountN :=
discountN := InvalidN
P6 ConfirmedN := ConfirmedT CouponN
P14 P18
P7 ErrorN := ErrorT orderSubmittedN := orderSubmittedT ValidN := ValidT
(b) The graph grammar for
PayCenter statechart diagram (c) The graph grammar for ShoppingCart statechart diagram
Fig. 11. Graph grammars automatically derived from UML statechart diagrams.
:ShoppingCart :ItemToPurchase
Purchase
shopping
:PayCenter
Browsing waitingOrder
Fig. 12. Initial states.
Based on Definitions 3 and 4, we illustrate the verification of a coupon fraud

(defined in Fig. 4) against a design model (defined in Figs. 2 and 3). In order to
automatically verify the coupon fraud, the state diagrams in Fig. 3 are automatically
formalized as a graph grammar as shown in Fig. 11. A graph grammar provides a
concise and precise specification to model hierarchical relationships among states
in a state diagram. In an automatically derived graph grammar, the left graph is a
non-terminal node representing a state configuration while the right graph specifies
the hierarchical relationships among a composite state and its direct sub-states,
such as Productions 12 and 13.
Based on the derived graph grammar in Fig. 11 and initial states in Fig. 12,
threat verification is performed as a sequence of paired graph transformations
triggered by method invocations in a security threat. In the above design model
(Figs. 2 and 3), we classify (1) state Confirmed as a normal final state, (2) state
Error as an abnormal final state and (3) the rest as intermediate states. Figure 13
presents the sequence of paired graph transformations to verify the coupon-fraud
S0218194010004980
:ShoppingCart :ShoppingCart :ShoppingCart :ShoppingCart

<(P10 ,P15),
shopping ( P13,P8)> discount <(P8),(P18)> discount <(P18,P16),(P15,P10)> shopping
AddCoupon VerifyCoupon ContinueShopping
Browsing Coupon Valid Browsing
RemoveItem <(P1),(P1)>
:PayCenter :PayCenter :ShoppingCart <(P11,P12), :ShoppingCart
<(P5),(P6)> <(P4),(P5)> <(P10),(P11)> :ItemToPurchase
processing (P14)>
Confirmed ValidatePay GetOrder orderSubmitted PlaceOrder shopping calTotalPrice
Order Purchase
ListPrice
Fig. 13. Threat verification through paired graph transformations — Coupon Fraud.
threat.b The method AddCoupon triggers the state transition of a ShoppingCart

object from shopping.Browsing to discount.Coupon. Especially, productions P10
and P15 are used to recognize the source state (i.e. shopping.Browsing) through
R-applications while productions P13 and P8 are used to generate the target state
(i.e. discount.Coupon) through L-applications. Then, the next method invocation
VerifyCoupon further triggers the state transition through a paired graph trans-
formation of P8 and P18 . Finally, the system state stays at Confirmed, which is
a normal final state. Therefore, according to Definition 4, the current design is
vulnerable to the coupon-fraud threat.
Definition 5 (Threat Mitigation). Given a design model , ð, and a security
threat ST, S1 →PGT SN represents a threat verification. Threat mitigation revises
the static structure and the state model ð in a design model so that the system
state cannot be transited from S1 to SN after a sequence of method invocations
defined in ST.
Malicious users use predefined methods to attack the system in a certain order.
In our approach, such an attack is modeled as a sequence diagram. Those method
invocations trigger the system state from an initial state (i.e. S1 ) to a normal final
state (i.e. SN ). In order to mitigate this security threat, we need to prevent corre-
sponding state transitions from being triggered in a statechart diagram.
Given an online shopping application, Fig. 14 gives a refined design, which
is secured from the coupon-fraud threat. Instead of verifying the coupon every
time when it is applied to the shopping cart, the ShoppingCart object only verifies
coupons once after the order is submitted through the method PlaceOrder. There-
fore, the removal of a qualified product from the shopping cart will invalidate its
corresponding coupon in the final order, which leads to an OrderCancelled state as
presented in Fig. 14. The refined statechart diagram is free from the above coupon
fraud.
b Dueto limited space, Fig. 12 only presents the paired graph transformations starting from the
method invocation AddCoupon.
S0218194010004980
shopping
PlaceOrder
calTotalPrice /VerifyCoupon
VerifyingCoupon
Browsing ListPrice
showItems
VerifyCoupon
ContinueShopping addCoupon [Valid] [InValid]
Coupon orderSubmitted orderCancelled
addCoupon
Fig. 14. A refined ShoppingCart state diagram.
5. A Case Study
Our case study was an online shopping application. We employed the STRIDE cate-
gories [11, 32] to identify threats. Each STRIDE category consists of different types
of threats. We elicited 12 types of threats to such security goals as confidentiality,
integrity, and availability and identified more than 50 specific threats across four
high-level functional use cases, including “placing an order,” “customer manage-
ment,” “order management,” and “handling and shipping.” As the online shopping
application is complex, the list of identified threats was by no means exhaustive.
Nevertheless, it provided a fairly good basis for demonstrating our approach.
In a shopping cart application, it is desirable to support client-side input, i.e.
clients can edit the quantity of a selected product. However, without a proper design,
the client-side input opens a security vulnerability to malicious users. They can edit
hidden form fields (such as price, weight, quantity, and identification) within the
HTML source code to perform an attack. For example, a malicious customer could
change the price of an item in a Web page and then submit the order request. Given a
design model (defined in Figs. 2, 3(a), 3(b) and 14), such an attack, buying a product
at a reduced price, is modeled as a sequence diagram in Fig. 15. A malicious user
Account ItemToPurchase ShoppingCart PayCenter

Login
Browse
CheckPrice
AddItem
calTotalPrice
PlaceOrder
VerifyCoupon
GetOrder ValidatePay
Fig. 15. The threat of buying products at a reduced price.

S0218194010004980
P8 CouponN := CouponT P9 ListPriceN := ListPriceT P14 shoppingT

shoppingN :=
P10 BrowsingN := BrowsingT
BrowsingN
P11 VerifyingCouponN := VerifyingCouponT
P15 shoppingT
P12 orderSubmittedN := orderSubmittedT
shoppingN :=
P13 orderCancelledN := orderCancelledT ListPriceN
Fig. 16. A graph grammar derived from Fig. 14.
:ShoppingCart
:ItemToPurchas :ItemToPurchase :ItemToPurchas shopping
<(P1),( P2)> <(P2),(P1)> <(P10),(P9)>
Purchase CheckPrice Price AddItem Purchase CalTotalPrice
ListPrice
<(P9, P15),(P11)> PlaceOrder
:PayCenter :PayCenter :ShoppingCart :ShoppingCart

<(P5),(P6)> <(P4),(P5)> <(P11),(P12)>
processing
Confirmed ValidatePay Order GetOrder orderSubmitted VerifyCoupon VerifyingCoupon
Fig. 17. Threat-driven verification — Buying a product at a reduced price.
checks the price of a selected product by calling CheckPrice. Then, he/she saves the
Web page of the selected product, changes the price and adds the product to the
shopping cart with a reduced price by calling AddItem.
Figure 16 gives the automatically derived graph grammar, which is correspond-
ing to the refined statechart diagram in Fig. 14. Similar to the verification of a
coupon fraud, grammars in Figs. 16, 11(a) and 11(b) provide a theoretical founda-
tion to verify the threat of buying a product at a reduced price. Figure 17 gives the
verification process, including a sequence of paired graph transformations. Accord-
ing to the verification result, though the statehcart diagram for the ShoppingCart
class in Fig. 14 is free from a coupon fraud, it is still vulnerable to the threat of
buying a product at a reduced price.
In order to mitigate the threat, we introduce a new method VerifyPrice to the
class ShoppingCart. This method, which is automatically called after an Shopping-
Cart object verifies coupons, is used to compare the submitted price recorded in
class Products. If the price is altered, the ShoppingCart object is transitted to state
orderCancelled, which indicates an invalid order. The corresponding refined state-
chart diagram for class ShoppingCart is presented in Fig. 18, which is secured from
both the coupon fraud and buying a product at a reduced price. The above model-
ing and verification process is performed iteratively until all identified threats are
verified.
S0218194010004980
PlaceOrder
shopping /VerifyCoupon
calTotalPrice VerifyingCoupon
Browsing ListPrice VerifyCoupon
showItems
[Valid]
[InValid]
/VerifyPrice
ContinueShopping addCoupon
VerifyingPrice orderCancelled
Coupon
VerifyPrice
[ValidPrice] [InValidPrice]
addCoupon
orderSubmitted
Fig. 18. A secure ShoppingCart state diagram.
6. Related Work
Threat modeling has gained increasing attention in the secure software engineering
community. As a structured way to secure software, the Microsoft’s threat model-
ing approach [11, 32] first determines threats to the system based on application
decomposition, ranks them by decreasing risk, and then chooses assurance tech-
niques to mitigate them. The suggested tools for specifying system functions and
security threats are data flow diagrams and attack trees, respectively. The misuse
case approach [1, 30] extends the use case approach with misuse cases and miti-
gation cases for the integrated elicitation of functional and security requirements.
Misuse cases are the inverse of use cases to model system behavior that should be
avoided. A misuse case can be defined as a complete sequence of actions which can
result in loss for the organization or some specific stakeholder. Sindre and Opdahl
have identified several relations between ordinary use cases and misuse cases, such
as includes, extends, prevents and detects. Also they have proposed a general tem-
plate for misuse case description [31]. Alexander discussed a variety of applications
of misuse cases beyond security requirements elicitation, such as eliciting general
“-ility” requirements, exceptions, and test cases [1]. Built upon the notions of misuse
and mitigation use cases, Xu et al. [37] have exploited aspect-orientation to capture
the crosscutting nature of threats and mitigations so that system requirements are
elicited in a more structured way. The structured specification facilitates under-
standing and analysis of the interplays between functional and security require-
ments. Xu and Pauli have developed a threat-driven approach to the architectural
design and analysis of secure software [36]. Based on the identification and mitiga-
tion of security threats as misuse use cases, they leverage use cases, misuse cases,
and mitigation of use cases to design architectural components and their connec-
tions for candidate architectures. This approach also allows for informal analysis of
whether or not candidate architectures are resistant to the identified security threats
and what constraints must be imposed on the choices of system implementation.
S0218194010004980
Many approaches have been proposed to extend UML to model and specify
security requirements. Rodriguez et al. [25] extend UML to model secure business
process at a high level of abstraction through UML activity diagrams. Houmb and
Kansen [10] present the Security Assessment UML, i.e. a UML profile for specifying
concrete threat scenarios. This UML profile aims at documenting the results from
risk identification and risk analysis in a security assessment, but this approach does
not discuss automatic verification of threat scenarios. Basin et al. [20, 2] proposed
a Model Driven Security methodology for developing secure systems, and demon-
strated its application to the domain of access control. Based on the SecureUML [20],
a modeling language for specifying access control policies, this approach supports to
automatically generate configured access control infrastructures. Due to the infor-
mal nature, the approaches described above do not support verification of threat
models or misuse cases while our approach supports a rigorous verification of secu-
rity threats based on graph transformation. Brucker et al. [3] present a semantics
for SecureUML by transforming a SecureUML model into a secured system model
described in UML/OCL. Kim et al. [16] use UML template diagrams to specify
reusable Role-Based Access Control (RBAC) policies, which need to be instantiated
in an application specific model. UMLsec [12, 13] extends UML to specify security
requirements within UML diagrams in a system specification. This approach sup-
ports encapsulating security engineering knowledge in the widely used design nota-
tion of UML. A tool has been developed to support UMLsec-based verification [14].
However, this work does not discuss threat modeling and analysis.
Formal methods for threat modeling and verification have also been developed.
Xu and Nygard have developed aspect-oriented Petri nets as a unified formalism
for specifying intended functions, security threats, and threat mitigations of a secu-
rity design as a whole [35]. Intended functions and security threats are modeled
by Petri nets, whereas threat mitigations are modeled by Petri net based aspects
due to the incremental and crosscutting nature of security features. The unified
formalism facilitates verifying correctness of security threats against intended func-
tions and verifying absence of security threats from integrated functions and threat
mitigations. Lotz has proposed a process-algebra based formal approach for devel-
oping secure communication systems with the aid of threat scenarios [21]. A threat
scenario describes a situation in which the system is attacked by an adversary.
The specification of a threat scenario is derived by replacing critical components
with subsystems that specify relevant attacks. Based on a compositional system
specification, the approach identifies and specifies threat scenarios, selects security
mechanisms, refines specification, and conducts security analysis. In this paper, we
investigate threat modeling and verification with UML Statecharts, UML sequence
diagrams, and graph transformations. Different from the above approaches, our
front-end language is UML, which has been widely applied to real-world software
development.
S0218194010004980
7. Conclusion
We have presented a rigorous and design-friendly framework for modeling and anal-
ysis of security threats. In our approach, designers use statechart diagrams to model
the behavior and sequence diagrams to specify security threats. In order to support
rigorous analysis of security threats against the system behavior, statechart dia-
grams are automatically converted to a graph transformation system, which can
be considered to be a UML virtual machine to interpret state transitions triggered
by sequenced method invocations in a security threat. Our approach allows for rig-
orous modeling and analysis of secure software while minimizing the requirement
of expertise in formal methods. In other words, designers directly apply the indus-
try standard of UML notations to model secured software without knowing the
details of underlying graph grammars. The popularity of UML notations increases
the applicability of our approach.
Our approach is limited by the nature of UML statechart and sequence diagrams.
Since a statechart diagram captures control-oriented state transitions, instead of
data flows, it is difficult to identify and analyze threats that are related to data flows.
Furthermore, a statechart diagram requires enumerating all states, which makes it
difficult to build the statechart for a complex system. Also, sequence diagrams
represent sequences of actions. They are hard to capture the relationships between
threats. As the future work, we will conduct more experiments on modeling and
analyzing security requirements in real-world systems to investigate above issues.
We will also formalize our approach with a rigorous proof of correctness to analyze
security threats against statechart diagrams.
Acknowledgments
The authors would like to thank associate editor Dr. Yi Deng and anonymous
reviewers for their insightful and constructive comments that have helped us to
significantly improve the presentation. This work is supported in part by ND NASA
EPSCoR grant #NNXO7AK91A.
References
1. I. Alexander, Misuse Cases: Use Cases with Hostile intent, IEEE Software (2003)
58–66.
2. D. Basin, J. Doser and T. Lodderstedt, Model driven security: From UML models
to access control infrastructures, ACM Transactions on Software Engineering and
Methodology 15(1) (2006) 39–91.
3. A. D. Brucker, J. Doser and B. Wolff, A model transformation semantics and analy-
sis methodology for SecureUML, Model Driven Engineering Languages and Systems
LNCS, Vol. 4199 (2006), pp. 306–320.
4. M. M. Burnett, Visual Language Research Bibliography, http://www.cs.orst.edu/
∼burnett/vpl.html, 2009.
S0218194010004980
5. G. Costagliola and G. Polese, Extended positional grammars, Proc. 16th IEEE

Symposium on Visual Languages (2000), pp. 103–110.
6. G. Costagliola, V. Deufemia and G. Polese, A framework for modeling and implement-
ing visual notations with applications to software engineering, ACM Transactions on
Software Engineering and Methodology (2004), pp. 431–487.
7. P. T. Cox and T. Smedley, Building environments for visual programming of robots
by demonstration, Journal of Visual Languages &Computing 11(5) (2000) 549–571.
8. E. J. Golin, Parsing visual languages with picture layout grammars, Journal of Visual
Languages and Computing 4(2) (1991) 371–394.
9. G. Hoglund and G. McGraw, Exploiting Software: How to Break Code (Addison-
Wesley, 2004).
10. S. H. Houmb and K. Hansen, Towards a UML profile for security assessment, Proc.
Workshop on Critical Systems Development with UML (2003).
11. M. Howard and D. LeBlanc, Writing Secure Code (Microsoft Press, 2003).
12. J. Jurjens, Towards development of secure systems using UMLsec, Proc. 4th Inter-
national Conference on Fundamental Approaches to Software Engineering (2001),
pp. 187–200.
13. J. Jurjens, UMLsec: Extending UML for secure systems development, Proc. 5th Inter-
national Conference on Unified Modeling Language (2002), pp. 412–425.
14. J. Jurjens, Developing high-assurance secure systems with UML: A smartcard-based
purchase protocol, Proc. 8th IEEE International Symposium on High Assurance Sys-
tems Engineering (2004), pp. 231–240.
15. G. Karsai, J. Sztipanovits, A. Ledeczi and T. Bapty, Model-integrated development
of embedded software, Proceedings of the IEEE 91(1) (2003) 145–164.
16. D. K. Kim, I. Ray, R. France and N. Li, Modeling role-based access control using
parameterized UML models, Proc. Fundamental Approaches to Software Engineering
(2004), pp. 180–193.
17. J. Kong, K. Zhang and X. Q. Zeng, Spatial graph grammar for graphic user interfaces,
ACM Transactions on Human-Computer Interaction 13(2) (2006) 268–307.
18. J. Kong and D. Xu, A UML-based framework for design and analysis of dependable
software, Proc. COMPSAC’2008 (2008), pp. 28–31.
19. J. Kong, K. Zhang, J. Dong and D. Xu, Specifying behavioral semantics of UML dia-
grams through graph transformations, Journal of Systems and Software 82(2) (2009)
292–306.
20. T. Lodderstedt, D. Basin and J. Doser, SecureUML: A UML-based modeling language
for model-driven security, Proc. of UML’02 (2002), pp. 426–441.
21. V. Lotz, Threat scenarios as a means to formally develop secure systems, Journal of
Computer Security 5 (1997), pp. 31–67.
22. K. Marriott, Constraint multiset grammars, Proc. 1994 IEEE Symposium on Visual
Languages (1994), pp. 118–125.
23. S. McClure, S. Shah and S. Shah, Web Hacking: Attacks and Defense (Addison-Wesley,
2003).
24. J. Rekers and A. Schürr, Defining and parsing visual languages with layered graph
grammars, Journal of Visual Languages and Computing 8(1) (1997) 27–55.
25. A. Rodriguez, E. Fernandez-Medina and M. Piattini, Towards a UML 2.0 extension
for the modeling of security requirements in business processes, Trust and Privacy in
Digital Business, LNCS, Vol. 4083 (2006), pp. 51–61.
26. G. Rozenberg and E. Welzl, Boundary NLC graph grammars — basic definitions,
normal forms, and complexity, Information and Control 69 (1986) 136–167.
S0218194010004980
27. G. Rozenberg (ed.), Handbook of Graph Grammars and Computing by Graph Trans-
formation: Foundations, Vol. 1 (World Scientific, 1997).
28. J. Rumbaugh, I. Jacobson and G. Booch, The Unified Modeling Language Reference
Manual, 2nd edn. (Addison-Wesley, 2005).
29. A. Schürr, A. Winter and A. Zündorf, Graph grammar engineering with PROGRES,
Proc. ESEC’95, LNCS Vol. 989 (1995), pp. 219–234.
30. G. Sindre and A. L. Opdahl, Eliciting security requirements by misuse cases, Proc.
Conf. Technology of Object-Oriented Languages and Systems (2000), pp. 120–131.
31. G. Sindre and A. L. Opdahl, Templates for misuse case description, Proc. of the
7th International Workshop on Requirements Engineering, Foundation for Software
Quality (2001).
32. F. Swiderski and W. Snyder, Threat Modeling (Microsoft Press, 2004).
33. D. Varró, A formal semantics of UML statecharts by model transition systems, Proc.
ICGT 2002, LNCS Vol. 2505 (2002), pp. 378–392.
34. J. Wing, A symbiotic relationship between formal methods and security, Proc. NSF
Workshop on Computer Security, Fault Tolerance, and Software Assurance: From
Needs to Solution (1998).
35. D. X. Xu and K. E. Nygard, Threat-driven modeling and verification of secure software
using aspect-oriented petri nets, IEEE Transactions on Software Engineering 32(4)
(2006) 265–278.
36. D. Xu and J. Pauli, Threat-driven design and analysis of secure software architectures,
Journal of Information Assurance and Security 1(3) (2006) 171–180.
37. D. Xu, V. Goel, K. Nygard and W. E. Wong, Aspect-oriented specification of threat-
driven security requirements, International Journal of Computer Applications in Tech-
nology, Special Issue on Concern Oriented Software Evolution 31(1/2) (2008) 131–140.
38. D. Q. Zhang, K. Zhang and J. Cao, A context-sensitive graph grammar formalism for
the specification of visual languages, Computer Journal 44(3) (2001) 187–200.
39. K. Zhang, D-Q. Zhang and J. Cao, Design, construction, and application of a generic
visual language generation environment, IEEE Transactions on Software Engineering
27(4) (2001) 289–307.
View publication stats

Uml-Based Modeling and Analysis of Security Threat

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml-Based Modeling and Analysis of Security Threat

Uploaded by

Copyright:

Available Formats

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Uml-Based Modeling and Analysis of Security Threats.

Article in International Journal of Software Engineering and Knowledge Engineering · September 2010

Jun Kong Dianxiang Xu

SEE PROFILE SEE PROFILE

Engineering ethics and morality View project

The future of programmable security controls View project

The user has requested enhancement of the downloaded file.

International Journal of Software Engineering

UML-BASED MODELING AND ANALYSIS

Received 12 January 2009

Keywords: Graph transformation; visual modeling and analysis; security threats.

876 J. Kong, D. Xu & X. Zeng

UML-Based Modeling and Analysis of Security Threats 877

2. UML-Based Modeling and Analysis of Security Threats

878 J. Kong, D. Xu & X. Zeng

Model Intended Model Security

UML Statechart UML Sequence

Fig. 1. UML-based modeling and analysis of security threats.

security policies. In order to rigorously verify a security threat against intended

(1) Modeling intended functions according to functional requirements

UML-Based Modeling and Analysis of Security Threats 879

(2) Identifying and modeling security threats according to functions and

The above process is performed iteratively. In the following sections, we use an

(1) An account manager, which keeps track of a customer’s activities in a shopping

880 J. Kong, D. Xu & X. Zeng

3. Modeling Intended Functions and Security Threats

Definition 1 (Design Model). A design model is a 2-tuple , ð, where

Account ShoppingCart PayCenter

Fig. 2. The static structure of an online shopping system.

UML-Based Modeling and Analysis of Security Threats 881

ItemToPurchase statechart diagram ContinueShopping addCoupon

Confirmed Error addCoupon

Fig. 3. Statechart diagrams.

name, description and quantity. Class ItemToPurchase records the products in a

882 J. Kong, D. Xu & X. Zeng

Definition 2 (Security Threat). Given a design model , ð, a security threat is a

UML-Based Modeling and Analysis of Security Threats 883

Account ItemToPurchase ShoppingCart PayCenter

Fig. 4. The threat of a coupon fraud.

a threat. It is time-consuming and error-prone to manually verify a security threat

4. Analysis of Security Threats

4.1. Graph grammar

884 J. Kong, D. Xu & X. Zeng

Left graph Right graph

tree. This production formalizes the hierarchical structure of a state conﬁguration

UML-Based Modeling and Analysis of Security Threats 885

4.2. Formalizing hierarchical states as a graph grammar

886 J. Kong, D. Xu & X. Zeng

Fig. 6. A state conﬁguration.

(a) A concurrent composite (b) A sequential

Fig. 7. Production generation.

4.3. Analyzing security threats

UML-Based Modeling and Analysis of Security Threats 887

Active state Method

Derive Validate &

Target state Transit New state configuration

Fig. 8. Execute state transition based on graph transformation.

through iterative L-applications in a top-down fashion. However, diﬀerent state

Definition 3 (State Transition). Given a design model , ð, GT = P, C is a

888 J. Kong, D. Xu & X. Zeng

(a) A Statechart (c) Current

Fig. 9. State transition based on graph transformation.