Addressing Security Threat Analysis by Misuse Cases

Transcription

1 Addressing Security Threat Analysis by Misuse Cases 1 Munina Yusufu, 2 Weimin Pan, 3 Gulina Yusufu *1 School of Computer Science and Technology, Xinjiang Normal University, myusuf2005@gmail.com 2 School of Computer Science and Technology, Xinjiang Normal University, panweiminss@163.com 3 School of Education Science, Xinjiang Normal University, gln531@sohu.com Abstract Use cases are focused in the analysis of functional requirements, but not necessarily with nonfunctional requirements like all of those that are related with operational availability, performance, reliability, reuse and security. This paper discusses the approach to address security threat analysis by the development of misuse cases. We discuss the differences between misuse cases and security use cases, and present a template that is similar to a use case template discussed in [7], but focus it into a misuse case interpretation, and also add some extra properties. 1. Introduction Keywords: Misuse cases, System Security, Nonfunctional Requirements Use cases [12,13,14] are a scenario-based technique for requirements elicitation [9,15,16]. They are a modeling technique for analyze and specify functional requirements in an early stage [9,10,11]. They provide scenarios about how the system works when the user is interacting, and help to describe the requirements in a graphical way. A use case defines a goal-oriented set of interactions between external actors and the system and has several advantages, such as, reusability, easy to understand, and can be integrated with other analysis tools. A use case can serve as the basis for the estimating, scheduling, and validating effort. However, use cases are focused in the analysis of functional requirements, but not necessarily with non functional requirements like all of those that are related with operational availability, performance, reliability, reuse and security [2,8,23,24,25]. It is easy to make some assumptions that can be very important within the project [6], and if we ignore them, some problems can be generated during the next stages, deriving a premature implementation of the design. Sindre and Ophal [8] define security as the prevention of, or protection against, access to information by unauthorized recipients, and intentional but unauthorized destruction or alteration of that information, for example, the protection of the information against a misuse of the system. On security terms, it is important to consider what are the weakest points in the system. There can be some security holes that because a lack of design are not considered, and it can be a possible vulnerable point for a security attack. There are some methods to deal with the security of the system, for example, the i-framework [4], a goal oriented method that works with three elements: actors, intentional elements and links. Some methods create security requirements [8], while others just deal with the necessities of the primary requirements. But, they can be very inconsistent, they are not analyzing exactly in what cases can be applied, they are focused just in the point of view of the user, and sometimes for an overview of a program in general is very hard to discover in what specific parts they are effective. Also, to deal with the security problems, there are some cryptographic approaches that can help but, if they are not based in a very well designed system, they are not enough to build a secure application. They must work together with a well designed application, which can cover all the situations where they can apply [5]. Lately the application of use cases has been investigated in connection with security and safety requirements, in the form of misuse cases [1,3,5-8,18], or abuse cases [17, 19]. In this paper, we discuss the approach to address security threat analysis by the development of This work is funded by a National Natural Science Foundation of China under Grant No , a Scientific Research Program of the Higher Education Institution of Xinjiang under Grant No. XJEDU2011I40, a Natural Science Foundation of Xinjiang Uyghur Autonomous Region under Grant No A056, and a Computer Application Technology Key Disciplines Bidding Project of Xinjiang Normal University under Grant No. 12XSXZ0602. International Journal of Digital Content Technology and its Applications(JDCTA) Volume7,Number7,April 2013 doi: /jdcta.vol7.issue

2 misuse cases. We discuss the differences between misuse cases and security use cases, and present a template that focus into a misuse case interpretation, and also add some extra properties. The paper is organized as follow. We first introduce the concept of misuse case and present the investigation on the related work in section 2. In section 3 and 4, we discuss three ways that represent misuse cases diagrams, and a methodology that helps to put all the pieces together and to discover new components in the system s analysis. In section 5, we present a template that is similar to a use case template [7], but we focus it more into a misuse case interpretation, and also add some extra properties. According to the template, we give an example about an automated teller machine in section 6, and then have a conclusion in section Concept of misuse case and related work Use cases describe some functions that the system should do; when they are related with security issues, they model mechanisms to protect the system. For example, in an instant teller machine, one security requirement is the verification of the card holder and his PIN number. It specifies that each time a user introduces his card he must introduce a PIN to validate that is the cardholder. However, these requirements are vulnerable to security threats. An undesired user can try to guess the PIN number, and access illegally to the system. One approach to address security threat analysis is the development of misuse cases [2,22]. A set of use cases are taken from a positive point of view of the user ; misuse cases threat security requirements within a negative scenario [1]. All security requirements exist because people that create methods to attack the systems; employing use and misuse cases can improve security by helping to mitigate threats. Sindre and Opdahl [8] introduce the concept of Misuse cases to analyze the system in a hostile way. Formally, a misuse case is a special kind of use case, describing behavior that the system/entity owner does not want to occur. According to Laurie Williams [20], a misuse case is a tool for helping to think about your software the same way attackers do, and the goal of misuse case is to decide and document a priori how the software should react to illegitimate use. A misuse case is the opposite of a use case; it represents all the things that can attack a system, but, preserving all the properties of use cases. Misuse cases analyze the interaction between applications and the misusers whom seeks to break the security in the system (misactors). In the uses cases, an actor plays the role of the users that interact with the system; in the misuse cases, a misactor plays the function of the users and situations that can break the system. For example, in a car security system, a possible actor is the owner of the car; possible misactors are thieves and the weather. Misuse cases help to analyze threats, but, are not very helpful for the specification of security requirements. Donald Firesmith [2] proposes to include use and misuse cases in the analysis of the system, but remarking the differences between them (Table 1). Table 1. Differences between misuse cases and security use cases Misuse Cases Security Use Cases Usage Success Criteria Produced by Used by External Actors Driven by Analyze and specify Security threats Misuser Succeeds Security Team Security Team Misuser, User Asset Vulnerability Analysis Analyze and specify Security requirements Application Succeeds Security Team Requirements Team User Misuse Cases 3. Misuse case diagrams There are three ways to represent misuse cases diagrams as shown in Figure 1. The first way (a) is representing it in terms of normal use cases. It has the advantage that it is in the same terms; both, because both cases are represented at the same time it can be confusing. The second approach (b) is to separate totally the use cases and misuse cases, it easy to see how works each part, but, it is hard to identify the relations among them. It is necessary to see the whole case or requirement. 1041

3 For a better understanding of the diagram, Sindre and Ophal [8] propose to draw in black color all the issues related with the misuse cases (c). Representing them in this way permits to the designer to identify in a fast way how a misuse case and a misactor are related with the rest of the system. In this way the diagram is simple and legible. It is easy to distinguish what part of the diagram corresponds to the use and misuse cases and also, all their relations can be included. Traditionally, a use case represents functional requirements, and misuse cases represent nonfunctional requirements. Another way of looking at the role of misuse cases is to observe that the typical response to a threat is for the designers to create a subsystem whose function is to mitigate that threat. 4. Methodology Figure 1. Different representations of a misuse case diagram Once the main components in a system had been analyzed, Sindre and Ophadl suggest following a methodology that helps to put all the pieces together and to discover new components in the system s analysis [8]. 1. Concentrate in normal actors. The design must be focused mainly on the principal actors, regardless of security issues; a clear concept of the system in general will help to get a better security analysis. 2. Introduce the major mis-actors. Potential misactors are persons, but, there can be more possibilities around the system. In an online system two possible misactors can be a hacker and a competitor. 3. Investigate potential relations between misuse cases and cases. Analyze how possible attacks can affect to the system. For example, how a flood system in a car security system can affect the functionality in general. 4. Introduce new cases. Considering security issues can derive new cases, and at the same time, new mis-uses. 5. Continue with a more detailed requirements documentation. If there are more details about the requirements, or if, if there are new, we can have a wider view about what new options can be considered regarding to the security issues. 1042

4 5. Templates for use cases The template suggested is similar to a use case template [7], but we need to focus it into a misuse case interpretation, and also add some extra properties. Following the ecommerce system given in Figure 2, a template for the access control could be defined as follows as in Table 2: Basic Path. The principal ways that misuse can take to pursue its goal. Table 2. The template that focus on a misuse case interpretation Case Name: The name of the case. Summary: A brief description of the case. Extension/alternative paths/exceptional paths. Ways that the misuse can take, but, that are not very common. Because sometimes are not very visible, they can be the key point for an attack. Preconditions. Preconditions can be of three types: Triggers: Entry criteria, what initiates the use case. Assumptions: Conditions that must be true, but is not guaranteed by the system. Postconditions: They can be of three types: Worst case threat: Prevention guarantee: Describes the Describe the outcome if the misuse succeeds. guaranteed outcome whatever prevention path is followed. Author: Person analyzed case. who the Date: Date of the case analysis. Preconditions: Conditions that are ensured by the system. Detection guarantee: Describes the guaranteed outcome whatever detection path is followed. Related business rules. Particular points depending of the system and the business. Iteration. Covering the necessity of a superficial analysis and after, more detailed descriptions. Begin in an upper level; analyze each step in a more detailed way. Primary Actor or misuse profile. Scope. The scope of modeling, for example, an entire business, an information system, and so on. Level. The level of abstraction. It can be a summary, user goal, or subfunction. Stakeholders and risks. List of the various stakeholders and what their motivations are. Depending of the abstraction level, risks can be just described, or try to quantify in costs. Technology and data variations. Mention variations without giving the path for each case. 6. Eliciting exceptions and test cases A program failure leads to exceptions. The system under design should respond to undesirable events, and through it, prevent possibly failures. Through misuse case analysis is possible to discover exceptions, and handle them in a proper way. The candidate exception scenarios must be generated and requirements to prevent system failures from a proven list of exception classes must be elicited [1]. Any possible scenario can lead to a test case and misuse cases can help to explore and analyze conditions and exceptions. Products of use / misuse case analysis that can contribute to effective test planning include. Specific failure modes. Useful for real time, embedded and safety - related systems. Security threats. Useful for distributed commercial and government systems. Exception handling scenarios. Always useful. A test engineer could view misuse cases as existing purely to ensure better system testing. A quality engineer could equally well argue that their purpose is to improve the quality of delivered systems [1]. 7. Example Misuse case diagrams are represented within use case diagrams. Figure 2 shows an example about an automated teller machine [2]. The three main requirements are deposit funds, withdraw funds and query balance. There are security cases to control access, ensure privacy, integrity and to ensure nonrepudiation of transactions. These user cases are specified to protect the actors (users) from three 1043

5 security threats (misuse cases): spoof user, invade privacy and perpetrate fraud, which can be done by a cracker or a thief (misactors). It is important to remark that a user can activate or not a use case, it is represented by lines and arrows. When the case must be activated by a user or case, it is represented by an arrow. When it could be activated by a user or case, it is represented by a line. Figure 2. An example about an automated teller machine. The following steps documents the case Access Control, for further information, [2] presents the documentation of the other cases. Case Name: Access Control. Summary: Access control is the extent to which a business enterprise, application, component or center controls access by its externals. It consists of identification, authentication and authorization. Author: Donald G. Firesmith Date: June Basic Path. Attempted spoofing using valid user identity. Attempted identity and authentication theft. Attempted spoofing using social engineering. Alternative paths. The misuser can quit at any point. Preconditions. The misuser has no valid means of user identification. The misuser has no valid means or user authentication. The misuser has a valid means of user identification enabling the impersonation of a valid user that is authorized to use a protected resource. The misuser does not have an associated valid means of user authentication. The misuser has basic knowledge of the organization. Postconditions: The system shall not have allowed the misuser to steal the user s means of authentication. The system shall not have authenticated the misuser as a valid user. The system shall not have authorized the misuser to perform any transaction that requires authentication. The system shall have recorded the access control failure. The system shall have prevented the misuser from stealing the user s means of identification and authentication. The system shall have identified and authenticated the user The system shall not have authenticated the misuser. The system shall not have authorized the misuser to access the protected resource. 1044

6 The system shall have recorded the access control failure. Related business rules. All the rules to realize a deposit, user data, privileges, etc. Iteration. No iterations. Primary Actor. Cracker and thief. Scope. Instant teller machine. Level. Summary Stakeholders and risks. External damage Technology and data variations. Model of the teller machine. 8. Conclusions Use cases are very good design tool for analyzing functional requirements in an early stage; but, they are not focused in the analysis of non-functional requirements. One of the most important nonfunctional requirements that must be considered in a system is security. Use cases analyze security requirements, they are considered as functional requirements because the user has a direct interaction and the client asked for them, some of them can be access interfaces, security algorithms, etc. Security requirements analyze security issues from a positive and straight forward point of view. They just set what security processes that must have a system, like check user and password; but they do not analyze all the possible negative scenarios that can affect or break the system s security. For analyze security threats, Sindre and Ophal [8] suggest a new extension for the use cases: Misuse Cases. One of the main advantages that they offer is the system analysis from a negative point of view, trying to do exactly what the system does not want. With that, it is possible to see another panorama to protect the system, placing a misactor to play the role of a normal actor who tries to attack the system. Also, there is a tool (Scenario Plus) that already had implemented this technique. It had the possibility to draw the diagram and it creates automatically the links between misuse and use cases through searching for underlined use case names with simple fuzzy matching [3]. But, misuse cases techniques are still in a development stage; there is not enough documentation for a deep analysis, and is not clear how they can be implemented during the other stages of the software design; there is not a clear method to get all the misuse case and a big part of the analysis depends on the designer s criteria. As Sindre and Opdahl suggested: Another important goal for further work is to facilitate broader industrial adoption of misuse cases [8]. They propose, in the same paper, to embed the misuse case in a use case modeling tool and to create a database of standard misuse cases to assist software architects. System stakeholders should create their own misuse case charts for requirements that are specific to their own problem domains. Once developed, a knowledge database can reduce the amount of standard security flaws used by lambda hackers. As said, misuse cases have not been evaluated in practical applications, just in examples. However, the industry could be interested on use them because of the following reasons: Misuse cases are a close approach to use cases; they are using the same terms as in UML use cases diagrams. Standardization of the misuse case as part of the UML notation might allow it to become a mandatory part of project development. It might be useful to create a specific notation for security functionality, or countermeasures that have been added to mitigate vulnerabilities and threats. [21] Security requirements are a main part in new system, especially those oriented to ecommerce. Misuse cases are small, simple and easy to understand. 9. References [1] Ian Alexander, Misuse cases: Use cases with hostile intent, IEEE-Software, vol. 20, no. 1, pp.58-66, [2] Donald G. Firesmith, Security use cases, Journal of Object Technology, vol. 2, no. 3, pp.53-64, [3] Ian F. Alexander, Initial industrial experience of misuse cases in trade-off analysis, In Proceedings of 10th Anniversary IEEE Joint International Conference on Requirements Engineering, pp.61-70,

7 [4] Lin Liu, Eric Yu, John Mylopoulos, Analyzing security requirements as relationships among strategic actors, In Proceedings of 2nd Symposium on Requirements Engineering for Information Security, [5] Paco Hope, Gary McGraw, Annie I. Antón, Misuse and abuse cases: Getting past the positive, IEEE Security and Privacy, vol. 2, no. 3, pp.90-92, [6] Joshua J. Pauli, Dianxiang Xu, Misuse case-based design and analysis of secure software architecture, In Proceedings of International Conference on Informa-tion Technology Coding and Computing, pp , [7] Guttorm Sindre, Andreas L. Opdahl, Templates for misuse case description, In 7th International Workshop on Requirements Engineering: Foundation of Software Quality, pp.4-17, [8] Guttorm Sindre, Andreas L. Opdahl, Eliciting security requirements by misuse cases, Requirements Engineering, vol. 45, pp.34-44, [9] Ian Sommerville, Software Engineering, Addison-Wesley, 6th edition, USA, [10] Munina Yusufu, Gulina Yusufu, Comparison of software specification methods using a case study, In Proceedings of International Conference on Computer Science and Software Engineering, pp , [11] Munina Yusufu, Gulina Yusufu, Comparative study of formal specifications through a case study, In Proceedings of 2nd International Conference on Information Science and Technology, pp , [12] Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and G. Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach, Boston: Addison-Wesley, USA, [13] Larry L. Constantine, Lucy A. D. Lockwood, Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design, ACM Press, USA, [14] Alistair Cockburn, Writing Effective Use Cases. Addison-Wesley, USA, [15] James E. Rumbaugh, Getting Started: Using Use Cases to Capture Requirements, Journal of Object-Oriented Programming, vol. 7, no. 5, pp. 8-23, [16] Daryl Kulak, Eamonn Guiney, Use Cases: Requirements in Context, ACM Press, USA, [17] John McDermott, Abuse-Case-Based Assurance Arguments, In Proceedings of 17th Annual Computer Security Applications Conference, pp , [18] Ian F. Alexander, Modeling the Interplay of Conflicting Goals with Use and Misuse Cases, In Proceedings of 8th International Workshop on Requirements Engineering: Foundation for Software Quality, [19] John McDermott, Chris Fox, Using Abuse Case Models for Security Requirements Analysis, In Proceedings of 15th Annual Computer Security Applications Conference, pp ,1999. [20] Laurie Williams, [21] Lillian Røstad, An extended misuse case notation: Including vulnerabilities and the insider threat, In Proceedings of 12th Working Conference on Requirements Engineering: Foundation for Software Quality, [22] Peter Karpati, Guttorm Sindre, Raimundas Matulevicius, Comparing Misuse Case and Mal- Activity Diagrams for Modelling Social Engineering Attacks, International Journal of Secure Software Engineering, Vol. 3, Iss. 2, [23] Saeed Ullah, Muzaffar Iq bal, Aamir Mehmood Khan, A Survey on Issues in Non-Functional Requirements Elicitation, In Proceedings of International Conference on Computer Networks and Information Technology, pp , [24] Li Xin, Zhang Ru, Niu Xinxin, Liu Jianyi, Analysis of the Security for Information Hiding Based on Behavior, AISS: Advances in Information Sciences and Service Sciences, Vol. 4, No. 5, pp , 2012 [25] Muhammad Qaiser Saleem, Jafreezal B. Jaafar, Mohd Fadzil Hassan, Model-based Security Engineering of SOA Systems Using Modified UML-SOA-Sec, AISS: Advances in Information Sciences and Service Sciences, Vol. 4, No. 9, pp ,