UMLintr: A UML Profile for Specifying Intrusions - CiteSeerX

UMLintr: A UML Profile for Specifying Intrusions Mohammed Hussein and Mohammad Zulkernine School of Computing Queens University, Kingston Ontario, Canada, K7L3N6 {hussein, mzulker}@cs.quuensu.ca

Abstract Specifications of non-functional requirements (NFR) such as security, safety, usability are as important as specification of functional requirements (FR). Non conformance to some NFR may render the whole software useless. There are many difficulties associated with the representation of NFR and the complexity of their subsequent validation. The main objective of this work is towards incorporating an important aspect of NFR, i.e., security from the very beginning of a software development process. In this paper, a framework is presented for specifying intrusion scenarios in the Unified Modeling Language (UML). We describe a UML profile called UMLintr (UML for intrusion specifications) that allows developers to specify intrusions using UML notations extended to suit the context of intrusion scenarios. The framework utilizes the expressiveness of UML and eliminates the need of using attack languages that are proposed only to describe attack scenarios. Since developers do not need to learn a separate language to describe attacks, the task of specifying intrusion scenarios becomes much easier. This approach also helps to avoid conflicting (e.g., security vs. usability), ambiguous, and redundant requirements. Examples are provided to show the usage of the proposed UML profile.

1. Introduction Specifying non-functional requirements (NFR) has its own set of challenges which make it more difficult than specifying functional requirements (FR). For example, NFR are usually abstract, they are not formally specified such as, “the system must be secure”. Moreover, NFR conflict with each other, e.g., performance vs. safety. Also, it is difficult to verify whether a system conforms to its NFR or not.

Compared to FR, there are very few tools and methodologies to support NFR specifications [1]. The Unified Modeling Language (UML) is a language for “specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems” [2]. Object Constraint Language (OCL) is used to add constraints to UML elements. A UML profile is a collection of UML notations extended to specialize UML for a particular domain. Although UML provides developers with various diagrams and features to specify FR, it does not provide that much of help for specifying NFR. An intrusion scenario is an abstract description of the steps that an intruder follows to gain an illegitimate access to some protected resources. The detailed description of such scenarios using a specification or attack language [3] is called an intrusion signature. Systems that try to detect and report intrusions are called Intrusion Detection Systems (IDS) [4]. The main motivation for this work is to help developers to use UML for both modeling the software and specifying its security requirements, i.e., mainly for specifying intrusion scenarios. There are several problems with the introduction of another language for security specifications that may waste time and effort. Duplicate and conflicting (e.g., security vs. usability) requirements are examples of such problems resulted from using two different languages. Moreover, attack languages for specifying security requirements are not easy to be communicated and explained to customers. Another motivation is to allow the incorporation of security requirements at the early stages of the software development. Zulkernine et al. [5, 6, 7] argue for the importance of unifying software engineering and security engineering processes. In [5], they suggest a waterfall based process model for their work and describe how security requirements are handled in each step of this process. Delaying the incorporation of security requirements to the end of the software development may make it impossible to satisfy these

Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) 0-7695-2546-6/06 $20.00 © 2006

IEEE

requirements. In some cases, failing to meet security requirements may render the whole system useless. In this paper, we present a UML profile for intrusion scenarios called UMLintr (UML for intrusion specifications) that specializes UML notations for the context of intrusion specification. In addition, this work describes a framework for specifying intrusion scenarios. This framework allows developers to specify intrusion scenarios and generate signatures using UML. The usage of the UML profile as well as the framework is demonstrated using two well known attack examples from a benchmark intrusion dataset. This paper also provides a detailed survey on the related security specifications. Paper organization. The current state of the art of specifying security requirements using UML is outlined in the following section. Section 3 explains the proposed framework in details. Our UML profile, UMLintr, is described in Section 4. Two example intrusion scenarios are presented in Section 5. At the end, the main ideas of this paper and the future work are summarized in Section 6.

2. Related UML Based Security Specifications The UML profile for modeling quality of service and fault tolerance [8] supports the specifications of quality of service (QoS) characteristics. In this profile, security is considered as one of the QoS characteristics. It provides a way to model some aspects of security. Access-control specifies the control policy while the safety of an element qualifies the security level provided by that element. The UML profile for security assessment developed as part of the CORAS project [9, 10] is a profile for documenting security assessments of a system. It is used to describe the target of the evaluation, to facilitate communication between stakeholders, and to document security assessments. It provides a way to identify attacks and threats which makes it the closest approach to our work. The main difference is that they extend use-cases for documenting attack scenarios, while we allow developers to specify intrusion scenarios using classes and state-machines and to use those specifications for generating intrusion signatures. Jurjen [11, 12] introduces UMLsec which is a UML profile for security. UMLsec uses stereotypes and tagged values to add security information to UML diagrams. UMLsec tries to utilize UML diagrams for security specifications. UMLsec also uses OCL to support the interpretation of these tagged values. Secrecy, integrity, and authenticity are examples of such tags. UMLsec can be used to search for vulnerabilities in the UML diagrams. It can also be

used to check whether the security requirements are met or not. Furthermore, developers do not need to have a good knowledge about security to use this extension. While UMLsec focuses on specifying and validating security properties and mechanisms like encryption, our profile focuses on specifying intrusions to be used as intrusion signatures. SecureUML is a UML-like language [13, 14] based on Role Based Access Control (RBAC). RBAC views a system as a set of users, roles, and resources. Each user has certain privileges to access certain resources. Also each user utilizes each resource according to some roles. SecureUML is a generic security policy language. To combine it with a modeling language like UML one has to define a dialect. A dialect shows the elements of a modeling language with the actions assigned to them as protected resources in SecureUML. While SecureUML focuses on modeling access control, our profile focuses on modeling intrusions. Cysneiros and Leitte [15] present an approach to deal with NFR and reflect them in the conceptual model. The authors view the development as “two independent evolutionary cycles that may be dealt with separately”. One cycle focuses on FR and the other focuses on NFR. Both cycles are connected through convergence points. Their first step is to record the FR and NFR in the Language Extended Lexicon (LEL). LEL is used to find how an NFR is related to another one and how it is related to the FR. The second step is to build a graph for each NFR and solve interdependencies among them using the LEL. After that, for each class in the system they identify the applicable graphs and extend that class accordingly. This step is repeated to make sure that all NFR are satisfied. The authors of [16, 17] describe a way of using use-cases to model un-authorized access to system resources. Misuse-case [16] and abuse-case [17] show the ways that actors may harm the system. They suggest that developers take each use-case and try to see how different kinds of actors might attack or misuse the system. In [16], a textual template for eliciting misuse-cases is described, while [17] focuses on presenting guidelines for creating abuse-cases based on the motivations, tools, and the techniques used. The work presented in [16] and [17] discuss the usage of use-cases only, whereas we utilize use-cases, classes, and state-machines. Oikinomopolous et al. [18] provide more detailed comparison and analysis of current work on specifying security requirements in UML. They also suggest a method for incorporating security requirements in the Rational Unified Process (RUP). Another approach of using security patterns can be found in [19]. It suggests modifying design patterns in

Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) 0-7695-2546-6/06 $20.00 © 2006

IEEE

order to be used for specifying security properties. The security pattern template is based on the design pattern template with more fields and with modification to some current fields. The added and modified fields hold more security relevant information. The authors also describe some security patterns designed from the security pattern template. For instance, Single Access Point defines one interface for communication with the external world in order to ease the job of monitoring and controlling of the system. Another example is Authorization which manages the access control of the resources.

3. Intrusion Specification Framework Overview

4. UML Profile, UMLintr

This framework provides software developers an opportunity to use UML for both modeling the system behavior and specifying security requirements related to intrusion detection. The goal is to use UML to specify intrusion scenarios and generate intrusion signatures accordingly. Figure 1 shows the phases of the framework. First of all, developers identify intrusion scenarios that can affect their system. Next, they specify these intrusions using the UML profile presented in this paper. Then, the specifications are transformed into signatures. Finally, the signatures can be used by intrusion detection systems (IDSs). To identify intrusions scenarios, developers should determine what services their system will provide. Then for each service, developers should study the components, operating system, and network protocols in which this service is going to be built on. Intrusions which affect these components, operating system, or protocols are definitely going to affect that service provided by the system. Identifying intrusion scenarios based on the security requirements of a given system is out of the scope of this paper. Developers draw usecases representing the identified intrusion scenarios. Then, they design classes and state-machines. After Intrusion list Identifying Intrusion Scenarios

Intrusion specs

Specifying Intrusion Scenarios

Intrusion signatures

Generating Intrusion Signatures

that, the developers implement these classes and statemachines. Finally, the code is compiled and the signatures are ready to be used by an IDS. Figure 2 shows a typical life cycle for developing software systems. Each step of our framework (see Figure 1) is applied in the corresponding stage of the development life cycle. In the requirements specification stage, developers identify intrusions in which their system is expected to be vulnerable to and use the framework to draw use-cases. As developers design and implement their system, they also draw class and state-machine diagrams for the intrusions. The framework should also be used to specify new intrusions discovered after the deployment.

IDS

Figure 1: The framework overview

UML is a language used to model the software in a high level of abstraction. A UML profile is a collection of UML notations extended to specialize UML for a particular domain. In order for developers to specify intrusion scenarios in regular UML, they need to add many notes and constraints to the use-case and class diagrams. Moreover, functions written in the class diagrams are full of low level code for dealing with events, audit logs, packets, etc. Definitely, dealing with such things is a very complicated and difficult task. Furthermore, extending current UML diagrams to suit the context of intrusion detection makes the intrusion scenarios much easier to be specified, communicated, and explained. Therefore, a new UML profile is needed to ease the process of specifying intrusion scenarios. The ability to extend UML to suit a particular domain is one of its great features. The extension can be achieved by either using tagged values, stereotypes, and constraints or by extending the UML metamodeling language. The first approach includes the addition of new elements to UML based on the current UML elements. An example profile for this type of extension is UMLsec. On the other hand, the second approach gives the ability to create, delete, or modify the current UML syntax and semantics. Rational Rose Real Time [20] is a profile based on the second extension mechanism. In UMLintr (UML for intrusion specifications), we also use the first approach of extension.

4.1. Computer attacks taxonomy architecture

requirements Requirements Specifications

Design

code

Implementation

Figure 2: Life cycle of a software system

The Information Systems Technology group (IST) of MIT “has collected and distributed the first standard corpora for evaluation of computer network intrusion detection systems” [21]. In 1998, their tests used more than 300 instances of 38 attack types. Six research

Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) 0-7695-2546-6/06 $20.00 © 2006

IEEE

Table 1: UMLintr stereotypes Stereotype

Base class Package Package Package Package Actor Actor Use-case Use-case Use-case Use-case Use-case



Class



Class Class Connector Connector Connector Connector Connector

Tagged values

Description Denial of service attacks Remote to user attacks User to root attacks Probe attacks Attacker actor Victim actor Methods of exploitation

initial-privilege, gainedprivilege, skill, action security severity, method, listeners

Attacker class Victim class Intrusion class Actions performed by attacker

Table 2: UMLintr tagged values Tagged value initial-privilege gained-privilege skill action security severity method listeners

Description Represents the initial access level of the attacker (e.g., remote network, local network, local user, root, or physical access) Represents the gained access level of the attacker (e.g., remote network, local network, local user, root, or physical access) The skill of the attacker (e.g., novice, intermediate, or experienced) The action of the attacker (e.g., probe, deny, intercept, alter, or use) The security level of the victim (e.g., low, medium, or high) The severity level of the attack (e.g., low, medium, or high) The exploitation method of the attack (e.g., abuse feature, masquerading, implementation bug, misconfiguration, or social engineering) Events needed to detect attacks (e.g., Windows audit, Unix log, Solaris BSM, or network packets)

groups participated in those tests. Another experiment was held in 1999 where 18 IDSs were evaluated using more than 200 instances of 58 attack types. Stereotypes and tags of UMLintr are chosen based on the computer attack taxonomy suggested in [30]. This taxonomy has been used successfully to describe the attacks in the 1998 and 1999 evaluations. The taxonomy defines privilege levels, transitions between these privileges, and actions. Intrusions are divided into four categories: denial of service, remote to user, user to super-user, and probe. Privileges that an attacker can have are remote network, local network, local user, super user, and physical access. Attackers can perform the attack by exploiting implementation bug, abuse of feature, masquerading, system misconfiguration, and social engineering. The actions performed by attackers, are also categorized to deny, alter, use, probe, and intercept. The following

subsection describes the usage of this taxonomy in our UML profile.

4.2. UML Notations for UMLintr UML diagrams used in this framework are usecase, class, and state-machine. Each one shows the attack in a different level of abstraction. Use-cases show attacks in a higher level of abstraction which can be easily explained to customers. Class diagrams present the structure of the attacks. State-machines show the potential steps that attacks go through. 4.2.1. Stereotypes and tagged values. Stereotypes and tagged values specialize UML to suit some particular domain. In our case, the domain is intrusion scenarios. They relieve developers from attaching many notes and constraints to UML notations. Stereotypes used in usecases have their own icons/notations. Stereotypes and tagged values in classes are used as directives to the

Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) 0-7695-2546-6/06 $20.00 © 2006

IEEE

UML tool. It can also be used for the IDS. Table 1 and 2 show the stereotypes and tagged values introduced in UMLintr. The first four stereotypes in Table 1 represent four categories of attacks suggested in [30]. The next seven are the actors and use-cases which represent attackers, victims, and methods of exploitation in use-case diagrams. The following three stereotypes represent the entities that are used in class diagrams. The rest of the stereotypes are connectors used to specify the effects of the attacks over the victims in use-case diagrams. The following subsections discuss the stereotypes and tagged values in more details. 4.2.2. Use-cases. Use-cases are very helpful in many ways. They can be easily understood by customers and help developers to brainstorm about all possible intrusions. Also in such diagrams, users who are expected to harm the system can be categorized according to their experience, goals, and targeted resources. Furthermore, use-cases are the basis of the classes and state-machines diagrams. Each use-case consists of an actor and a actor connected through an intrusion. The stereotypes: , , , , and show the effect of the intrusion on the victim. means to read files, packets, or events in a system or a network. means manipulating data or log entries at the victim. denotes the actions of using resources at the victim. includes actions of gathering information about users on a system or about machines on a network. Finally, is for stopping or degrading a service at the victim. The stereotypes: , , , , and describe the exploitation methods. represents exploitation methods where the attacker convinces the user to give the username and/or password. are the class of methods where the attacker get access to a service by supplying legitimate username and password. represents the attacker exploiting a misconfiguration in the security policy. represents the attacker exploiting a bug in the service implementation. Finally, represents the attacker using a service in a way to harm the system. 4.2.3. Packages. Stereotyped packages of UMLintr are: , , , and . These packages represent the four types of attacks: denial of service, remote to user, user to root or super user, and probe/ surveillance attacks. Denial of service is the set of attacks where the attacker aims to stop or degrade a

service by abusing its usage. Remote to user are those attacks where the attacker with remote access to a system gains a user privilege. On the other hand, user to root are those attacks where the attacker with user access to a system gains a root privilege. Probe is to gather information about machines on the network to find its vulnerabilities. 4.2.4. Classes. After capturing attack scenarios in the use-case diagrams, the next step is to represent these attacks as classes. Three stereotyped classes are introduced: , , and . They represent the entities of the attacker, victim, and intrusion respectively. Each stereotype has its own tagged values that presents security related information. has four tags: initial-privilege, gainedprivilege, action, and skill. has one tag: security. has three tags: severity, method, and listeners. initialprivilege is the privilege that the attacker started with. gained-privilege is the privilege that the attacker ended with. action is the operation that the attacker performs after gaining access to the service. skill is used to classify attackers based on their skills and tools. security represents how secure the victim is. severity is the level of damage that the attack has on the victim. method represents the strategy that the attacker used to launch the attack. listeners are the events in which the signatures writer needs to detect the attack. 4.2.5. State-machines. Each state machine represents the states in which its corresponding attack can go through. The final state of each diagram marks a successful penetration. The input data for each machine is defined in the class diagram by the listeners tag. This is similar to the way attack languages like STATL [22] define their attack scenarios. The advantage here is that these diagrams are already present in the current UML. As a result, developers do not need to learn attack languages. While developers are creating the state machine they may need to define attributes and operations in the class diagrams. The state-machines in regular UML are suitable for specifying intrusion scenarios. Developers create new states representing different stages of an attack. The transition from one state to another is based on the trigger (event) specified by developers such as arrival of a network packet or a system call. The transition can have instructions to be executed after triggering the transition. Developers may choose to add a guard (condition) to the transition which must be evaluated to true before its corresponding transition can take place.

Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) 0-7695-2546-6/06 $20.00 © 2006

IEEE

5. Example Intrusion Scenarios



This section provides two examples of attacks specified using UMLintr. The first one is the Smurf attack while the second one is called the Xterm attack. These two attacks are chosen from the benchmarking intrusion data set reported in [21].





Figure 3: Use-case diagram for Smurf denialOfService1999

5.1. Smurf attack Smurf attack is based on the Internet Control Message Protocol (ICMP). It can be described as follows: “The attacker sends ICMP “echo request” packets to the broadcast address (xxx.xxx.xxx.255) of many subnets with the source address spoofed to be that of the intended victim” [23]. As a result, machines listening on these subnets send echo reply to the victim. Since the number of machines listening on each subnet may reach 255, the number of replies sent to the victim is huge. Obviously, this attack will lead to a denial of service at the victim. 5.1.1. Use-case diagram. An attacker uses Smurf attack which abuses a feature in the TCP protocol to deny this service at the victim’s machine. Figure 3 shows the use-case for the Smurf attack. The arrow from the to the indicates the effects of this intrusion on the victim. 5.1.2. Class diagram. The class diagram describes the structure of the Smurf attack. A novice attacker with remote network access to the victim’s machine attacks the TCP protocol to deny this service. Since this attack is of type , i.e., denial of service, the gainedprivilege tag is equal to the initial-privilege tag. The class diagram also shows that the signature writer of this attack needs a way to capture the ICMP packets sent and received. Figure 4 and 5 show the package containing the Smurf attack and its class diagram respectively. IPAddr, numOfReplies, and maxMemory are the data members of the classes, while getIPAddress, isReplyValid, and getMemorySize are the member functions. IPAddr stores the attacker’s IP address, Nov_attacker {initial-privilege = remote network} {gained-privilege = remote network} {skill = novice} {action = deny} IPAddr IP_Address getIPAddress IP_Address

TCP protocol

Smurf

Figure 4: Package containing Smurf ICMP-reply / numOfReplies < max ICMP-reply/ idle

check ICMP-reply / numOfReplies >= max

Figure 6: State-machine for Smurf numOfreplies represents the number of malicious ICMP replies, and maxMemory stores the maximum memory allowed. 5.1.3. State-machine diagram. Figure 6 presents the state machine for the Smurf attack. In the beginning, the state machine is at the idle state. Upon receiving an ICMP-reply message, the machine goes to the check state, and based on whether a request has been sent, numOfReplies is incremented. numOfReplies shown in the class represents the number of replies received for requests that have never been sent from the victim's machine. Two transitions in the check state are triggered by an ICMP-reply, but each one has a different guard condition. The one which goes back to the check state has its guard condition evaluated as true if numOfReplies is less than the threshold, i.e., max. The other guard condition evaluates to true if numOfReplies exceeds max. The final state, the black circle inside a white one, of the Smurf machine indicates that a successful Smurf attack has occurred. Smurf {severity = medium} {method = abuse feature} {listeners = ICMP} numOfReplies int isReplyValid bool

TCP_Protocol {security = low} maxMemory int getMemorySize int

Figure 5: Class diagram for Smurf

Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) 0-7695-2546-6/06 $20.00 © 2006

IEEE

5.2. Xterm attack



Xterm

“Problems exist in both the Xterm program and the Xaw library that allow user supplied data to cause buffer overflows in both the Xterm program and any program that uses the Xaw library” [23]. 5.2.1. Use-case diagram. The attacker exploits a bug in the Xaw library to cause a buffer overflow which leads to a user to gain root privileges. Figure 8 shows the use-case for the Xterm attack. 5.2.2. Class diagram. Figure 8 and 9 show the package containing the Xterm attack and its class diagram respectively. An experienced attacker with local user access to the victim’s machine exploits the Xterm program to gain root privileges and alter user accounts. userId and maxMemory are the data members of the classes, while isRoot and getMemorySize are the member functions. userId stores the user name, while isRoot determines whether this user became a root or not. 5.2.3. State-machine diagram. Figure 10 presents a state-machine for the Xterm attack. The state machine moves directly to the check state with any command executed by the user. Then, it waits for user commands that exploit known vulnerability of the Xaw library to move to the final state. If a normal user executes a malicious command and becomes a root, then isRoot is evaluated to true and hence the state-machine moves to the final state, the black circle inside a white one.

6. Conclusions and Future Work In this paper, we describe a UML profile called UMLintr (UML for intrusion specifications), which is part of our proposed framework for specifying intrusion scenarios. The UML profile is described in detail by using it to specify attack signatures for two types of attacks: denial of service attack and buffer overflow attack. We also present the state of the art of using UML for specifying security in general and intrusion scenarios in particular. Using UML for modeling NFR is an open research area which needs more research attention. Generating Nov_attacker {initial-privilege = local user} {gained-privilege = root} {skill = expert} {action = alter} userId String isRoot bool



Xaw_Library



Figure 7: Use-case diagram for Xterm remoteAttacks1999

Figure 8: Package containing Xterm command / !isRoot command / idle

check command / isRoot

Figure 10: State-machine for Xterm the attack signatures using the same framework employed to build the software system itself is more convenient for developers than using a separate framework. In addition to that, UML diagrams are much easier to be communicated to customers than attack languages code. However, using regular UML for describing intrusions makes the specification more complex. Moreover, it slows down the process of the specification. One of the limitations of this work is that we still have not investigated how to specify distributed attacks using our UML profile. Whenever we find an intrusion that cannot be specified using UMLintr, we have to change our profile accordingly. A potential immediate future work is to extend the framework for the specification of other security properties.

Acknowledgement This work has been funded by the Natural Sciences and Engineering Research Council of Canada (NSERC).

Xterm {severity = high} {method = implementation bug} {listeners = Unix log}

Xaw_Library {security = medium} maxMemory int getMemorySize int

Figure 9: Class diagram for Xterm

Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) 0-7695-2546-6/06 $20.00 © 2006

IEEE

References [1] Rosa, N., Cunha, P., and Justo, G., “ProcessNFL: A Language for Describing Non-Functional Properties”, Proceedings of the 35th Hawaii International Conference on System Sciences, Hawaii, 2002. [2] OMG, OMG Unified Modeling Language Specification, Technical report, Object Management Group, March 2003. [3] Vigna, G., Eckmann, S.T., and Kemmerer, R.A., “Attack Languages”, Proceedings of the IEEE Information Survivability Workshop, Boston, MA, October 2000. [4] Axelsson S., Intrusion Detection Systems: A Survey and Taxonomy, Technical report 99-15, Department of Computer Engineering, Chalmers University of Technology, Goteborg, Sweden, March 2000. [5] Zulkernine, M. and Ahamed, S., “Software Security Engineering: Towards Unifying Software Engineering with Security Engineering”, Chapter in M. Warkentin and R. Vaughn (editors), Enterprise Information Systems Assurance and System Security: Managerial and Technical Issues, (to appear) Idea Group Publishing, 2005. [6] Raihan, M. and Zulkernine, M., “Detecting Intrusions Specified in a Software Specification Language”, Proceedings of the 29th Annual International Computer Software and Applications Conference (COMPSAC '05), IEEE CS Press, Edinburgh, Scotland, July 2005. [7] Zhang, Q. and Zulkernine, Specification for Automatic Proceedings of the Workshop Automated Processing of Security 233, Linz, Austria, September 2004.

M., “Applying AsmL Intrusion Detection”, on Specification and Requirements, pp. 221-

[8] OMG, UML Profile for Modeling Quality of Service and Fault Tolerance Characteristics and Mechanisms, Technical report, Object Management Group, September 2004. [9] Lund, M., Braber, F., Stolen, K., and Vraalsen, F., A UML Profile for the Identification and Analysis of Security Risks during Structured Brainstorming, Technical report, SINTEF ICT, May 2004. [10] Lund, M., Hogganvik, I., Seehusen, F., and Stolen, K., UML Profile for Security Assessment, Technical report, SINTEF ICT, November 2003.

[13] Baser, D., Doser, J., and Lodderstedt, T., “Model Driven Security for Process-Oriented Systems”, Proceedings of the 8th ACM Symposium on Access Control Models and Technologies, Como, Italy, 2003. [14] Lodderstedt, T., Basin, D., and Doser, J., “Secure UML: A UML-based Modeling Language for Model-Driven Security”, Proceedings of the 5th International UML Conference, Lecture Notes in Computer Scinece, Springer, Dresden, Germany, 2002. [15] Cysneiros, L.M. and Leitte, J.C., “Using UML to Reflect Non-Functional Requirements”, Proceedings of the CASCON 2001, Toronto, Canada, 2001. [16] Sindre, G. and Opdahl, A.L., “Capturing Security Requirements Through Misuse Cases”, Norway Conference on Computing, Norway, 2001. [17] Dermott, J. and Fox, C., “Using Abuse Case Models for Security Requirements Analysis”, 15th Annual Computer Security Applications Conference, Phoenix, Arizona, 1999. [18] Cheng, B., Konrad, S., Cample, L., and Wassermann, R., Using Security Patterns to Model and Analyze Security Requirements, Technical Report MSU-CSE-03-18, Software Engineering and Network Systems Laboratory, Michigan State University, 2003. [19] Oikinomopolous S. and Giritzails S., “Integration of Security Engineering into the Rational Unified Process”, Proceedings of the Workshop on Specification and Automated Processing of Security Requirements, Austria, 2004. [20] Selic B. and Rumbaugh J. “Using UML for Modeling Complex Real-Time Systems”, white paper, Rational (ObjecTime), March 1998. [21] MIT Lincoln Laboratory, DARPA Intrusion Detection Evaluation. (http://www.ll.mit.edu/IST/ ideval/), 1999. [22] Eckmann, S., Vigna, G., and Kemmerer, R., STATL. Technical report, University of California Santa Barbara, CA, 2000. [23] Kendall, K., A Database of Computer Attacks for the Evaluation of Intrusion Detection Systems, Master’s Thesis, MIT, June 1999.

[11] Jurjens, J., “Towards Development of Secure Systems using UML”, In H. Hubmann, editor, Fundamental Approaches to Software Engineering (FASE/ETAPS, International conference), Lecture Notes in Computer Scinece, Springer, Genova, Italy, 2001. [12] Jurjens, J., Secure System Development with UML, Springer-Verlag, 2005.

Proceedings of the 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems (ECBS’06) 0-7695-2546-6/06 $20.00 © 2006

IEEE