JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2003 Vol. 2, No. 3, May-June 2003 Cite this column as follows: Donald Firesmith: “Security Use Cases”, in Journal of Object Technology, vol. 2, no. 3, May-June 2003, pp. 53-64. http://www.jot.fm/issues/issue_2003_05/ column6 Security Use Cases Donald G. Firesmith, Software Engineering Institute, U.S.A. Abstract Although use cases are a popular modeling approach for engineering functional requirements, they are often misused when it comes to engineering security requirements because requirements engineers unnecessarily specify security architectural mechanisms instead of security requirements. After discussing the relationships between misuse cases, security use cases, and security mechanisms, this column provides examples and guidelines for properly specifying essential (i.e., requirements-level) security use cases. 1 INTRODUCTION Over the past decade, use cases have become one of the most popular modeling approaches for analyzing and specifying functional requirements. However, use case modeling has not been as successfully applied to engineering quality requirements, such as operational availability, performance, portability, reliability, reuse, security, and usability. When it comes to engineering security requirements, use cases are typically misused to unnecessarily specify security architectural mechanisms (e.g., the use of user identifiers and passwords) rather than actual security requirements (e.g., mandating some level of identification and authentication). Thus, typical example use cases for an automatic teller machine might include initial interactions for inserting an ATM card to identify the customer and entering a PIN number for authentication (i.e., verifying the identity of the customer). Whereas this is the current standard security mechanism for implementing identification and authentication requirements for ATM machines, it unnecessarily prevents the use of other, perhaps improved means of access control such as biometrics (e.g., face recognition, fingerprint analysis, or retinal scan). Security requirements should be based on an analysis of the assets and services to be protected and the security threats from which these assets and services should be protected. Thus, as illustrated in Figure 1, there are clear relationships between assets and services, which are vulnerable to security threats, which necessitate security requirements, which require security mechanisms that counter these security threats and thereby protect the assets and services.SECURITY USE CASES 54 JOURNAL OF OBJECT TECHNOLOGY VOL. 2, NO. 3 Assets andServicesSecurityThreatsSecurityRequirementsSecurityMechanismsarevulnerabletonecessitate requirecounterprotect Fig. 1: Security Threats, Requirements, and Mechanisms Historically, the emphasis of security engineering has been on the development and use of numerous security mechanisms to protect vulnerable assets and services by countering known security threats. The analysis and documentation of security threats and security requirements has received considerably less attention. Misuse Cases for the Analysis of Security Threats A relatively recent approach to addressing security threat analysis has been the development of misuse cases. As illustrated in Figure 2, misuse cases (a.k.a., abuse cases) are a specialized kind of use cases that are used to analyze and specify security threats [Sindre and Opdahl 2001] [Alexander2003]. Unlike normal use cases that document interactions between an application and its users, misuse cases concentrate on interactions between the application and its misusers (e.g., cracker or disgruntled employee) who seek to violate its security. Because the success criteria for a misuse case is a successful attack against an application, misuse cases are highly effective ways of analyzing security threats but are inappropriate for the analysis and specification of security requirements. Instead, security use cases should be used to specify requirements that the application shall successfully protect itself from its relevant security threats. Assets andServicesSecurityThreatsSecurityRequirementsSecurityMechanismsMisuseCasesSecurityUse CasesSecurity Teamarevulnerabletonecessitate requirecounterprotectanalyzeandspecifydevelopsdevelopsanalyzeandspecifydriveFig. 2: Misuse Cases vs. Security Use CasesINTRODUCTION VOL. 2, NO. 3 JOURNAL OF OBJECT TECHNOLOGY 55 The following table summarizes the primary differences between misuse cases and security use cases. Misuse Cases Security Use Cases Usage Analyze and specify security threats. Analyze and specify security requirements Success Criteria Misuser Succeeds Application Succeeds Produced By Security Team Security Team Used By Security Team Requirements Team External Actors Misuser, User User Driven By Asset Vulnerability Analysis Threat Analysis Misuse Cases To further illustrate the differences between normal use cases, security use cases, and associated misuse cases, consider Figure 3. The traditional use cases for an automated teller machine might include Deposit Funds, Withdraw Funds, Transfer Funds, and Query Balance, all of which are specializations of a general Manage Accounts use case. To securely manage one’s accounts, one can specify security use cases to control access (identification, authentication, and authorization), ensure privacy (of data and communications), ensure integrity (of data and communications), and ensure nonrepudiation of transactions. The resulting four security use cases specify requirements that protect the ATM and its users from three security threats involving attacks by either crackers or thiefs. CustomerManageAccountsDepositFundsWithdrawFundsTransferFundsQueryBalanceControl Access(Security)Ensure Privacy(Security)Ensure Integrity(Security)EnsureNonrepudiation(Security)Spoof User(Misuse)Invade Privacy(Misuse)Perpetrate Fraud(Misuse)CrackerThiefMisuseCaseMisuserSecurityUse Case Fig. 3: Example Security Use Cases and Misuse CasesSECURITY USE CASES 56 JOURNAL OF OBJECT TECHNOLOGY VOL. 2, NO. 3 2 EXAMPLE SECURITY USE CASES As documented in [Firesmith 2003], there are numerous kinds of security requirements. Although each kind of security requirement typically has its own security use case, given the limited space available in this column, I have selected access control (identification and