Using Abuse Case Models for Security Requirements Analysis

John McDermott and Chris Fox

Department of Computer Science
James Madison University
Harrisonburg, Virginia 222807
E-mail: {mcdermot, fox}@cs.jmu.edu

Abstract Security specialists use mathematical security models

[6, 8] to understand security problems and find
The relationships between the work products of a solutions for them. Use of these models is essential to
security engineering process can be hard to the creation of trustworthy information security
understand, even for persons with a strong technical products. But these models are complex and subtle.
background but little knowledge of security They are not easily understood by persons who are not
security specialists. They must be interpreted for the
engineering. Market forces are driving software
system to which they are applied. Security specialists
practitioners who are not security specialists to
develop software that requires security features. When can construct these interpretations, but the construction
these practitioners develop software solutions without can be time consuming.
appropriate security-specific processes and models,
they sometimes fail to produce effective solutions. On the other hand, market forces are driving software
practitioners who are not security specialists to develop
software that requires security features. When these
We have adapted a proven object-oriented modeling
technique, use cases, to capture and analyze security practitioners develop software solutions without
requirements in a simple way. We call the adaptation appropriate security-specific processes and models [2],
an abuse case model. Its relationship to other security they sometimes fail to produce effective solutions [7].
engineering work products is relatively simple, from a
user perspective. While we do not have a solution to this problem, we
have adapted a proven object-oriented modeling
technique, use cases, to capture and analyze security
1. Introduction requirements in a simple way. We call the adaptation
an abuse case model. As we employ it, an abuse case
A valid security engineering process, as typified by the model is considerably easier to understand than a
Common Criteria [1], is a complex activity involving mathematical security model. Its relationship to other
many special work products: security objectives, security engineering work products is relatively simple,
security requirements, security policies, functional from a user perspective
specifications, and security policy models. These work
products are essential in a process that aims to create 2. Use Cases
trustworthy information security products. But the
work products and relationships between them can be
hard to understand, even for persons with a strong Use cases are abstract episodes of interaction between
technical background, but little knowledge of security a system and its environment. A use case characterizes
engineering. a way of using a system, or a dialog that a system and
its environment may share as they interact.
We define a use case as a specification of a type of The Customer chooses a balance inquiry on either
complete interaction between a system and one or checking or savings. The system displays the current
more actors (discussed below). A use case must be balance and re-displays the transaction menu. This
complete in the sense that it forms an entire and continues until the Customer chooses to terminate the
coherent transaction. For example, making a cash interaction. The system releases the bank card. The
withdrawal at an ATM machine, placing a call on the Customer removes the card and the system returns to
telephone, or deleting a file from a file system, are its ready state. If the bank card is not removed within
examples of complete interactions with various sorts of 40 seconds, the system retrieves the bank card.
systems that would qualify as use cases.
Notice that the use case describes the possible courses
An abstraction of an external agent that interacts with of events that may occur in various scenarios.
the system is called an actor. Actors represent entities
outside a system that interact with it in some way. Use case models are documented using two notations:
Actors may be human or non-human. Actors may use case diagrams and use case descriptions. Use case
interact with a system by exchanging data with it, diagrams are part of the Universal Modeling Language
invoking one of the system’s operations, or having one (UML), an industry standard collection of notations for
of the actor’s operations invoked by the system. Actors analysis and design [5].
are abstractions of actual individual users or systems
typifying the roles played in system interactions. Some
A use case diagram is a schematic representation of
examples of actors are Dispatcher, Clerk, Printer,
actors and a system’s use cases. Each actor is
Communications Channel, and Inventory System.
represented by a stick figure; the actor’s name appears
near the figure. Use cases are represented by ovals with
A scenario is a description of a specific interaction the name of the use case either below or within the
between particular individuals. A use case abstracts oval. Finally, an association line connects the actors
scenarios that are instances of the same kind of with the use cases in which they participate. These
interaction between a system and its actors. The symbols are shown below, in Figure 1.
following description is a scenario:

Mary Smith places her bank card into an active ATM

machine. The system prompts her for her PIN
Use
number, and she types 2384. The machine displays a Association Case
transaction menu. Mary chooses a balance inquiry on
her checking account. The system reports that she has Actor
$1329.67 in her account, and again displays the
transaction menu. This time Mary chooses to end the Figure 1. Use Case Diagram Symbols
interaction, and the system releases her card. Mary
removes it and the system returns to its ready state.
Each use case should have an accompanying use case
description that explains how the actors and the system
A use case abstracts scenarios such as this to provide a interact. There is no standard notation or format for use
general specification for similar interactions. The case descriptions. Virtually any notation able to
following illustrates an ATM balance inquiry describe interactions between two or more entities may
transaction use case: be used. Typically, use case descriptions are written in
natural language. The simplest or most abstract use
A balance inquiry begins when a Customer inserts case description may be only a few sentences. More
his or her bank card into an active ATM machine in detailed use case descriptions are refined by adding
its ready state. The system prompts for the details about the interaction and references to
Customer’s PIN. The Customer types the PIN. If the requirements for requirements traceability.
PIN is incorrect, the system displays an error
message and asks the Customer to try again. The A special case of abstraction involves varying levels of
Customer gets three tries. After the third failure, the detail about the interaction protocols between actors
system keeps the card, displays a message telling the and the system. For example, an ATM balance inquiry
Customer to see a teller, and after twenty seconds, use case description may simply state that the user
returns to its active state. If the Customer enters a identifies herself to the system, specifies a balance
valid PIN, the system presents a transaction menu.
inquiry transaction on one of her accounts, is informed The use case diagram for the lab is show below as
of the balance in response, and then the user terminates Figure 2. There are three actors and eight use cases.
the interaction. This description abstracts protocol
details. A use case description with more protocol
Develop Exploit
detail might go into the specifics of ATM cards, PIN
numbers, the ATM display and menus, and the button
presses the user makes to accomplish the transaction. Demonstrate Exploit

Student Develop Defense

Use cases that abstract the details of interaction
protocols are called essential use cases; those that
include protocol details are called real or Demonstrate Defense
implementation use cases [3].
Set Up Lab
3. A Use Case Model For An Internet-
Based Information Security Lab Tear Down Lab
Administrator
Here is a complete use case model that will show how Develop Exercise
actors, use cases, associations, diagrams, and use case
descriptions fit together. This model is a simplified Develop Exercise Scoring
version of the one we are using to design and set up an
Internet-based information security lab in our own
department.
Instructor
An Internet-based information security lab, or lab, is a
collection of systems and software used for teaching Figure 2. Use Case Diagram for an Internet-
information security. Laboratory exercises give Based Information Security Laboratory
students practical experience with security
vulnerabilities, security testing, and defenses. The 3.2 Use Case Descriptions
students are not physically in the laboratory, but access
it through the Internet. The lab comprises four kinds of Here is a use case description from the model depicted
entities: servers, sources, targets, and exercises. The in Figure 2. The first use case describes the interaction
first three are specially configured host systems in the that takes place when a Student develops a security
lab. Servers provide presence for the students in the exploit as part of an assigned exercise. The second use
lab; servers do not participate in the exercises. Sources case describes how a lab Administrator configures the
and targets participate in the exercises, with at least hosts and networks of the lab for a particular exercise.
one source and target for each exercise. The exercises Lab setup occurs for each exercise, because the
are either exploits or defenses, from the student’s point exercise security configuration is quite frequently
of view. Each exercise has two parts: documentation different from one that would be recommended for an
and implementation. The documentation is provided by operational system. Our descriptions are abstract and
the instructor and usually consists of files and code informal, as we would use for requirements elicitation.
samples that explain the exercise. Students are allowed The actual lab will include several kinds of networks
to access the documentation for an exercise and are (Fast Ethernet, ATM, IPv4, IPv6) and hosts (Windows
expected to construct and demonstrate an NT and Linux), and it is difficult to be specific in a
implementation. The instructor also provides a model small amount of space.
solution which is not given to the students until the
exercise is completed. Before each exercise, the lab is Develop Exploit
configured by an administrator. After the exercise is
complete, the administrator restores the lab to an
appropriate configuration. A Student first logs in to the lab server using a either
a secure browser or command shell, from a remote
location. The lab server authenticates the Student
3.1 Use Case Diagram
using a public key authentication algorithm and
opens a session for the Student in her private
workspace. The Student reads the description of the
 exercise, due dates, assigned hosts, list of references, key to divulge the contents of a message or make an
and scoring rules from a text file provided by the lab unauthorized change to stored data. If we extend the
server at her request. The Student studies the interaction to include the posting of the key on a public
references that are outside the lab. The Student web site then we have an abuse case.
requests references that are stored in the lab, from the
lab server. The lab server returns the references that A further distinction we make is that an abuse case
are permitted by the current security policy of the lab should describe the abuse of privilege used to complete
server. The Student then logs on to the target host, the abuse case. Clearly, any abuse can be accomplished
via the lab server. The Student requests pertinent by gaining total control of the target machine through
configuration information from the target host. The modification of the system software or firmware. In
target host returns the configuration information many cases it is not necessary to abuse this much
permitted by its local security policy and the security privilege in the real system, so we need to include
policy of the lab server. The Student studies the abuse of privilege that is less than maximal. To guard
configuration of the target host. The Student may against simple abuses, an abuse case should describe
request an editor from the lab server. The lab server interactions involving the minimal abuse of privilege
will provide one if the Student is authorized necessary to accomplish the harm intended by the
according to the security policy. The Student then abusing actor. However, in the real system, an attacker
uses the editor to write a plan for the exploit, copies may employ more than minimal effort. For this reason,
of configuration files, and programs needed to we describe the range of privileges that might be used
demonstrate the exploit. Alternatively, the Student to accomplish the abuse, up to the maximum we intend
may use editors and software tools on her local to deal with.
system outside the lab and then request to upload
them onto the lab server via the secure shell. If this is
Finally, we also include a short description of the
permitted by the current security policy, then the lab
specific harm that will occur as a result of the abuse.
server accepts the files and stores them in the
This description should be in terms from the user’s
Student’s workspace. When the Student is satisfied
domain.
that her exploit is ready she requests that the lab
server install the necessary files on the source
machine. If this is permitted by the security policy We can describe abuse cases using the same strategy as
then lab server installs the necessary files on the for use cases: use case diagrams and use case
source machine. The Student then tests her solution descriptions. We do not use any special symbols for
against the target and modifies the configuration abuse cases in diagrams, that is, an abuse case diagram
files, procedures, and programs until the exploit is drawn with the same symbols as a use case diagram.
succeeds or the Student gives up. The Student then This allows us to create abuse case specifications in
saves her solution files on the server and logs out. standard notation such as UML and to use design tools
such as Rational Rose [4]. We distinguish the two by
keeping them separate and labeling the diagrams.
4. Abuse Cases Abuse cases are not shown on a use case diagram and
use cases are not shown on an abuse case diagram.
We define an abuse case as a specification of a type of Abuse cases can also range in levels of abstraction and
complete interaction between a system and one or we use both essential abuse cases and real abuse cases.
more actors, where the results of the interaction are
harmful to the system, one of the actors, or one of the The actors in an abuse case model are the same kinds
stakeholders in the system. We cannot define of external agents that participate in use cases.
completeness just in terms of coherent transactions However, they should not be the same actors. If a
between actors and the system. Instead, we must define human that is represented by an actor from a use case
abuse in terms of interactions that result in actual harm. might also act maliciously in the corresponding role,
A complete abuse case defines an interaction between then a new actor should be defined in the abuse case.
an actor and the system that results in harm to a For example, in our Internet-based information security
resource associated with one of the actors, one of the laboratory, a malicious student might attempt to copy
stakeholders, or the system itself. For example, it may another student’s solution. If we were to model this as
be possible to define an interaction that reveals a an abuse case, we would define a new actor Malicious
session key to an actor that should not see the session Student for the abuse case, rather than have the Student
key. However, we would not call this interaction an actor associated with the abuse case. If outsiders or
abuse case, because no actor has used the compromised unauthorized users are a threat, then new actors will
have to be added to represent them. We do this to In our limited experience, we have used a tree, or
emphasize that a different role is active during abuse, sometimes a DAG structure to describe abuse cases in
even if the abusing actor also fulfills other roles. Some this way. We use a structure that could be a sub-tree of
customers and users can be very sensitive about an attack tree, as used in penetration testing. The root
discussions of possible insider threats. of the sub-tree is the system we are modeling and the
leaves are the resources or components of the system
Actors in use cases are defined only briefly. In an that are the targets of the abuse case. The interior nodes
abuse case, we give a more detailed description of the represent subsystems, applications, and individual
actor. Actor descriptions are very useful in abuse case classes within the applications. Each path from the root
modeling. Three characteristics of each actor are to a leaf shows which subsystems, applications, and
critical to understanding an abuse case: the actor’s classes might be misused in order to affect the leaf
resources, skills, and objectives. The third node in the desired way. Multiple paths through the
characteristic may seem redundant if our abuse cases tree indicate alternative means of accomplishing the
are at the same level of abstraction as essential use abuse. In our experience, the interior nodes of the tree
cases. However, the objectives of an actor are not are entities that may be regarded as subjects, while the
really captured in the abstract abuse cases. Instead, we leaf nodes are objects.
describe the actor’s objectives as long-term goals that
the actor potentially seeks over more than one abuse To summarize,
case. For example, the abuse case model of our
information security laboratory includes two actors Use Case Abuse Case
Script Kiddie and Nazgul [9]. The Script Kiddie’s
objective’s include demonstration of skills by breaking • A complete • A family of
in to a large number of systems while the Nazgul’s transaction complete
objectives include industrial espionage, terrorism, and between one or transactions
war. The resources available to an actor include other more actors and a between one or
persons and organizations that might assist the actor, in system. more actors and a
addition to the tools and systems the actor may be system, that results
using. Finally, resources include the amount of time an in harm.
actor has to devote to the abuse case.
• UML-based use • UML-based use
case diagrams. case diagrams.
The description of an abuse case can also slightly differ
from the approach taken with use case descriptions. • Typically • Typically
We can describe abuse cases in exactly the same way described using described using
that we describe use cases. However, we sometimes natural language. natural language.
take a different approach. A use case description A tree/DAG
centers around a single abstract transaction or sequence diagram may also
of events, because a use case describes a desired be used.
interaction. On the other hand, because we are not sure
where flaws will occur, an abuse case describes a • Potentially one
family of undesirable interactions. The final family member for
"implementation" of an abuse case will be through the each kind of
exploitation of requirements oversights, design flaws, privilege abuse and
and implementation flaws. Since we want to use the for each
abuse case model to reduce the number of component that
requirements oversights and design flaws, we may might be exploited.
choose describe many abstract "transactions" that
• Includes a
might take place to accomplish the same abuse. Each
description of the
feature or component of the target system that might be
range of security
exploited in an abuse case will be considered in the
privileges that may
abuse case description. So each security relevant
be abused.
feature or component in the target system adds an
abstract transaction to the family. • Includes a
description of the
harm that results
 from an abuse them. Some abuse cases may need to be refined or
case. abstracted to achieve uniform granularity.
In our experience, we develop the abuse case model
one step behind the use case model. We use each 4. Check completeness and minimality. Each
component of the use case model to construct the abuse case description should be checked to see if it
corresponding component of the abuse case model: describes an interaction that results in harm to a user or
stakeholder in the system. We should also check to see
if a critical abuse case may have been omitted. An
1. Identify the actors. After the actors of the use abuse case in the model may lack an abuse based on
case model have been identified, identify the actors of the minimal privilege needed to accomplish the harm.
the abuse case model. If an actor in the use case model Requirements documents and the use case model
might attempt harmful use of the system, then add a should be reviewed, along with descriptions of
corresponding malicious actor to the abuse case model. anticipated security features. Users and customers
After the insider roles are represented, then actors should be consulted to be sure that no critical abuse has
should be added for any intruders that might be a been overlooked.
problem. Distinguish outsiders primarily on the basis
of skills and resources. Requirements documents may
give some help in identifying actors for abuse cases but 5. An Abuse Case Model For An Internet-
a careful analysis of the system environment should Based Information Security Lab
also be done. It is important for the security specialist
to discuss the potential actors with users and
customers. An example will help to make things clear. The
following example shows how we would construct an
abuse case model, at the essential use case level of
2. Identify the abuse cases. For each actor, abstraction, for our Internet-based information security
determine their interactions with the system. Name lab. We present a simplified model that is based on the
each abuse case. At this point, it is helpful to draw an actual model we developed to construct a security
abuse case diagram. model and policy for our Internet-based information
security laboratory.
4. Define abuse cases. As the interface to the
system becomes more refined and the specific Figure 3 shows the abuse case diagram for the lab. Our
components are identified, the abuse case can be model has three actors and eight abuse cases. The first
described. Since we use a tree structure to describe the thing to notice is that we have two abuse cases that are
possible points of abuse, we defer the definition until distinguished primarily by the capabilities of the actor
there is enough system structure to work with. The that interacts with our lab: Browse Exercise with Warez
definitions can be refined as the description of the and Browse Exercise with Scalpel. By "warez" we
system is refined. mean packages and tools that allow a user to mount
attacks on a system from a GUI, without knowledge of
3. Check granularity. There may be too few the principles involved in carrying out the attack. By
abuse cases or there may be too many. Deciding how "scalpel" we mean a well-engineered attack designed
many are needed is largely a matter of experience and specifically to penetrate our system. This kind of
consideration of the specific target system. In our modeling can be helpful in identifying the level of
experience there are two ways we can wind up with too security needed by users or customers.
many abuse cases: 1) including possible but unlikely
cases, or 2) modeling with too much detail. The latter
problem results in several abuse cases that are
distinguished only by details that are inappropriate for
the purpose. For example, in most situations we would
not need two abuse cases involving password theft that
differed only in the kind of command shell used to
accomplish the theft. We must be cautious when
discarding an abuse case as unlikely. Some abuse
cases may be too complex and others may be too
abstract. A good abuse case model will have uniform
granularity of detail in its cases, and not too many of
 Copy Another Student’s Work Objectives

Tamper With Scores Script Kiddies may have a variety of criminal

objectives including vandalism and theft. They also
are interested in demonstrating their technical
Tamper With Exercise prowess.
Malicious
Student
Nazgul

Root Lab Host Resources

Nazguls operate on behalf of groups that have
Vandalize Lab Host budgets set aside to accomplish some form of harm.
Script Kiddie They may have technical assistance from an
Browse Exercise with Warez organization that is tasked with supporting them.
They have hardware, software, tools, and Internet
Browse Exercise with Scalpel access provided by a business, a government, or a
quasi-government. They have significant access to
Capture Lab Host documentation of the systems they intend to abuse
and may be able to test or simulate an intended
Nazgul exploit on a copy of the target system. We assume
that Nazguls may spend up to 90 days in preparation
Figure 3. Abuse Case Diagram for an Internet- and execution of an attempt to breach the security of
Based Information Security Laboratory the system.
Skills
5.1 Actor Descriptions
Nazguls have superior technical skills. They can
design operating systems, network protocols,
Here are the actor descriptions for two of the actors in computer hardware, and cryptographic algorithms.
our abuse case model for the Internet-based They apply software engineering technology,
information security lab. These two actors represent mathematics, computer engineering, and similar
different classes of outsiders that, for whatever reason, disciplines to their exploits.
we believe might attempt to abuse our system. The
actual human who might assume the role of a Nazgul Objectives
in attacking our system may also interact with it in the Nazguls are primarily interested in accomplishing the
role of Script Kiddie, in order to probe for weaknesses. objective of the organization that supports them.
In this case, we are stating that such a person would They also seek to increase their own skills and
apply no more resources, skills or time than any other knowledge, but not to demonstrate them to anyone.
attacker in the Script Kiddie role. Organizations that support Nazguls do so to carry out
Script Kiddie espionage, warfare, terrorism or similar harmful
activities.
Resources
The Script Kiddie operates alone, although he or she 5.2 An Abuse Case Description: Browse
may exchange some information with fellow Script Server Exercise With Warez
Kiddies. The Script Kiddie has hardware, software,
and Internet access that might be available to an
individual through purchase with personal funds or Our abuse case description is intentionally very
by theft from an employer. Our model assumes that abstract, corresponding to an essential use case. We
the Script Kiddie is willing to spend about 24 hours don’t have the space to present a more detailed abuse
trying to defeat the security of a particular system. case and we also want to show what an initial abuse
case might look like. We would use this kind of abuse
Skills case description early in the requirements phase of a
project. For example, we intend to incorporate both
Script Kiddies have limited technical skills. The Windows NT and Linux based hosts in our lab and the
majority of their activities are carried out using tools abuse cases are meant to apply to either kind of host.
and techniques devised by other people. However, in the requirements analysis, it is not
significant whether the abuse occurs via Windows NT target host, a source host, or a server host. The lab
or Linux. Later, in design or testing, the specific host establishes the session with the Warez 1 tool. If
features of NT or Linux would be significant. the initial session has sufficient privilege, then the
Script Kiddie will request either a file manager, a
Notice that our description does not include the logical debugger, a programming editor, or a command shell
case where the actor (Script Kiddie) fails to gain access to browse exercise documentation and example
to the exercise materials. Since this case involves no exercise implementations stored on a lab server. If
harm, we omit it. the initial session has sufficient privileges or there is
a flaw in the system software of the host, then the lab
host permits browsing of the exercises on the server
We have included part of a tree diagram (Figure 4)
host. If the initial session does not have sufficient
depicting the various ways that the abuse case may be
privileges to browse exercises stored on a server,
accomplished. The meaning of the tree diagram is
then the Script Kiddie uses additional tools Warez 2
intentionally vague, to avoid complexity that is of little
through Warez N to request an increase in privilege.
benefit to users. We read the diagram like a decision
The lab machine, source, target, or server, may or
tree, with each path from root to leaf defining an
may not grant an increase in privilege. If the Script
abstract abuse case transaction that could occur. For
Kiddie cannot obtain an increase in privilege from
example, Figure 4 does not show all paths of the tree
the system software, then the Script Kiddie requests
corresponding to the Browse Server Exercises With
copies of the exercise materials directly, via the
Warez abuse case, but it does depict the complete path
available file manager, debugger, editor, or command
for an abuse that exploits vulnerabilities in the file
shell of the host. One or more of these applications
manager of a target host, to browse the documentation
permit (via a flaw) browsing of exercise
for an exercise.
documentation or exercise implementations stored
on a lab server.

If any of the exercise materials could serve as

Browse Server Exercises With Warez additional warez to the Script Kiddie, then the Script
Kiddie saves or downloads them.
Harm: The users of the lab will be legally, ethically,
and morally responsible for increasing the abilities of
the Script Kiddie. The users may also be responsible
for allowing information about previously unknown
exploits to be released.

Privilege Range: The Script Kiddie might carry out

this abuse using privileges in the following range:
1. Installation of modified system utilities with
root/administrator privileges on a source or
target host
2. One-time control of a root/administrator account
on a source or target host
3. One-time control of a root/administrator session
on a source or target host
4. Installation of modified utilities with user
privileges on a source or target host
5. One-time control of a single instructor session
on a server host
6. One-time control of a single student session on a
server host
Abusive Interaction: Using the TCP/IP protocol suite
and a hypothetical attack tool called Warez 1, the
Script Kiddie requests or attempts to initiate a session
on some lab host. The initial session could be on a
 Lab The applicable abuse cases can been identified and
defined in a level of detail like our example, with the
help of the users and customers. Later, each abuse case
Target
can be refined and described more rigorously, as
needed. One must be careful not to expend too much
effort on rigorous descriptions of abuse cases early in
the project. Changes in requirements or system
File Manager
architecture may overtake some of them and they will
disappear.
Exercise
Implementation
6. Applications Of Abuse Case Modeling
Exercise
Documentation
Abuse case models can be helpful during the
requirements, design, and testing phases of a security
Debugger
engineering process.

Exercise
In a requirements phase, abuse case models can be
Implementation used to increase both user and customer understanding
of the security features of a proposed product. They
can be made simple and abstract enough to be
Exercise
Documentation
understood by users from a wide range of application
domains. They can be used to show customers what
will be prevented and what will not, in terms of their
Editor
application domain. For this same reason, abuse case
models are also useful for security requirements
elicitation. Users can decide, in terms of their own
Exercise
application domain, which threats apply and which
Implementation
threats should be countered by product security
features. Many fine security models have been
Exercise developed that model various kinds of protection, in
Documentation
mathematically sound ways. Use of these models is
essential for any product that aims at complete
Command security. However, these models are subtle and very
Shell abstract. It can be difficult for users or customers to
apply them in their own domain. Practitioners who use
Exercise and translate these security models may expend a great
Implementation deal of time transforming a policy to the user’s domain,
only to find that the policy is not what the users
Exercise intended. Abuse cases may help security practitioners
Documentation and users save time in arriving at a good understanding
of security requirements.
Source
During the design and testing phases of a security
engineering process, we can apply abuse cases through
Lab Server a refutation process. As we analyze and design the
system, we refute each use case to the appropriate level
of assurance. This is one reason for describing the
actors in greater detail in an abuse case. Our refutation
Figure 4. Tree Diagram for Abuse Case: Browse may depend on the skills, resources, or objectives of
Server Exercise With Warez the actor. For example, we may argue that 40-bit
cryptographic keys are sufficient to refute an abuse
case involving a Script Kiddie actor, because of their
specified resource limitations, but not against a Nazgul. during requirements analysis and may be easier to
In other instances, our refutation may be based on the understand when trade-offs must be made between
properties of a design feature. The strength of the security and functionality.
refutation can be used to characterize the assurance we
have. A refutation arrived at during an informal code Abuse case models are not a substitute for
walk through is not as strong as a refutation based on mathematical security models. We intentionally make
formal methods. Abuse cases can be ranked or abuse case models ambiguous and incomplete and do
weighted according to the assurance that should be not worry about their soundness. Abuse case models do
applied to them. The assurance budget for a project can not replace any other part of a sound security
then be allocated by abuse case, according to the engineering process. The same qualities that make
ranking. them powerful in security requirements analysis render
them unfit as tools for high assurance. On the other
During testing, we can design our security function hand, we have found them to be very useful as a
tests to refute abuse cases. For example, we can apply complementary tool, when used during the
the abuse case directly as a family of test cases. We requirements, design, and testing phases of a project.
form a test team that has the same skills and resources
as the actors associated with the abuse case and let References
them exercise our system features. We can also
combine testing with other refutation arguments. We
may argue that neither an editor nor a debugger can 1. COMMON CRITERIA IMPLEMENTATION
browse exercises, if the current session lacks the BOARD, Common Criteria for Information
necessary security permissions. We can then use Technology Security Evaluation, version 2.0. May
testing to show that all exercises are configured with 1998, Common Criteria Project Sponsoring
the security attributes needed to prevent browsing and Organisations.
that all passwords are sufficiently strong. We can also
rank abuse cases in order to allocate testing resources. 2. CUSUMANO, M. and SELBY, R. How Microsoft
builds software. CACM, 40, 6, June 1997, pp. 53-
Abuse cases can also be used to make design trade- 61.
offs. Since both use cases and abuse cases are readily
understood by users and customers, they can be used to 3. LARMAN, C. Applying UML and Patterns: An
explain security-related design trade-offs. Customers Introduction to Object-Oriented Analysis and
will be better informed when choosing between Design, Prentice-Hall, 1998.
modified functionality in a use case and the residual
risk in an unrefuted abuse case.

7. Conclusions

By borrowing the concepts and notation of a proven

modeling technique, we can model significant forms of
abuse that we wish to prevent. An abuse case model is
easily understood not only by users and customers, but
also by the many developers who understand either
use case models or UML. This is a significant benefit
since many developers who work on the security
features of software do not understand mathematical
security models. Abuse cases are also more easily
understood by other project engineering personnel who
are not familiar with mathematical security models.

Abuse cases are much simpler than mathematical

security models but they can be an effective tool for
capturing security requirements. They are particularly
useful in communicating with users and customers
4. RATIONAL CORPORATION, Rational Rose,
http://www.rational.com.

5. RUMBAUGH, J., JACOBSON I., and BOOCH,

G. The Unified Modeling Language Reference
Manual. Addison Wesley, 1999.

6. SANDHU, R. and MUNAWER, Q. The RRA97

model for role-base administration of role
hierarchies, Proceedings of the 14th Annual
Computer Security Applications Conference,
December 1998, Phoenix, Arizona, pp. 39-49.

7. SCHNEIER, B. and MUDGE. Cryptanalysis of

Microsoft’s Point-to-Point Tunneling Protocol
(PPTP), Proceedings of the 5th ACM Conference
on Computer and Communications Security.
November 1998, San Francisco, California, pp.
132-141.

8. THOMSEN, D., O’BRIEN, D. and BOGLE, J.

Role based access control framework for network
enterprises, Proceedings of the 14th Annual
Computer Security Applications Conference.
December 1998, Phoenix, Arizona, pp. 50-58.

9. TOLKIEN, J. Lord of the Rings. Houghton

Mifflin, 1974.