MisuseCases:earlierandsmarterinformationsecurity ...media.techtarget.com/searchSecurityUK/downloads/RHUL_Ruck_fina… · RoyalHollowaySeries MisuseCases:earlierandsmarterinformationsecurity

Royal Holloway Series Misuse Cases: earlier and smarter information security

HOME

THEINFORMATIONSYSTEMSLIFECYCLE

CASE STUDY

USE ANDMISUSE CASES

MISUSE CASETECHNIQUES

CONCLUSIONSAND FURTHERWORK

1

Misuse Cases:earlier and smarterinformation securityBy defining the scenarios in which computer systemscould be misused, security professionals can test morethoroughly and close down risk more quickly.By John Neil Ruck and Geraint Price

ISUSE CASES PROVIDE informationsecurity professionals with a wayto identify how their informationsystem might be used inappro-

priately, either deliberately (an attack) or acci-dentally (a mistake). This article illustrates threetechniques based on misuse cases by applyingthem to a case study (an IT Contractor Manage-ment System).

� Technique 1: to identify and prioritise poten-tial misuses (described by misuse cases);

� Technique 2: to derive the security require-ments needed to counter the misuse cases;

� Technique 3: a novel approach to develop testscenarios to verify that security requirementshave been met.

1. INTRODUCTIONIn the information security profession we are los-ing the battle. Schneier [Schneier, 2004] arguesthat today’s computers and networks are lesssecure than they were earlier and they will beeven less secure in the future. To stand a chance

of reversing our fortunes the information securityprofession needs to focus on securing informa-tion systems faster and smarter. Software engi-neers recognised over 15 years ago [Davis, 1993]that it is much cheaper to identify and fix require-ment-related errors as early on in the softwarelifecycle as possible. There is much the informa-tion security profession can learn from softwareengineers, and indeed vice versa!Whilst software engineers use techniques

based on “use cases” to describe the functionalityan information system must provide; informationsecurity professionals can use techniques basedon “misuse cases” to describe functionality aninformation system must not provide.In this article we apply the three techniques

to a hypothetical case study (an IT ContractorManagement System, described in Section 4)to perform the following, security-enhancingactivities:

� Derive the functionality an informationsystem must not allow; referred to as its misusesand described in the form of misuse cases(Technique 1);


HOME


CASE STUDY

USE ANDMISUSE CASES



2

M

� Derive the security requirements that willcounter the misuse cases we are most concernedabout (Technique 2);

� Derive test scenarios in order to verify that wehave implemented the security requirements cor-rectly and that the misuses are no longer possible(Technique 3).

Techniques 1 and 2 are based on techniquestaken from the existing literature, with somemodifications and extensions that we propose tomake them as applicable to the ‘real world’ aspossible. Technique 3 is a novel approach basedon combining two existing techniques that isunique to our Technical Report [Ruck, 2008].The remained of this article is organised as fol-

lows:

� Section 2 introduces the concept of an infor-mation systems lifecycle; to help us understandhow to incorporate security at the earliest oppor-tunity;

� Section 3 provides a brief description of thecase study we will use to demonstrate our tech-niques;

� Section 4 gives an overview of misuse casesand use cases;

� Section 5 applies the three techniques based

on misuse cases in detail;� Section 6 concludes and provides recommen-

dations for future work.

2. THE INFORMATION SYSTEMS LIFECYCLEInformation systems do not just happen; softwareengineers manage their development using a sys-tem development process. There are a range ofthese available; the one we chose is the Unified

Process (UP) because many other developmentlifecycles are derived from it and the UP has nointellectual property constraints. The UP is shownin FIGURE 1 on page 4; and described in detail in[Jacobson, Booch, & Rumbaugh, 1999].The phases of the system lifecycle are shown in

the columns of FIGURE 1; the system starts in the‘inception’ phase. The rows of FIGURE 1 describe


HOME


CASE STUDY

USE ANDMISUSE CASES



3

The information securityprofession needs to focuson securing informationsystems faster and smarter.

the workflows that are being followedthroughout the lifecycle. The shapes showthe amount of effort expended on eachworkflow in relation to the phase in thesystem lifecycle. The thicker the shape themore of the workflow is done at that pointin the lifecycle.The misuse case techniques we apply

relate primarily to the two numbered areasin FIGURE 1:

1) ‘Requirements’—we show howmis-use cases can be identified and used tocapture and prioritise security require-ments for information systems (Tech-niques 1 & 2);

2) ‘Testing’—we show how test scenar-ios can be developed (Technique 3) to beused to verify that security requirements havebeen satisfied throughout the system lifecycle(‘traceability of requirements’).

3. CASE STUDYThe case study we use in both this article and theTechnical Report [Ruck, 2008] is an IT Contrac-tor Management System. It is a hypothetical

information system that is used to demonstratehow the three techniques can be applied. Thissection summarises the case study for the read-er’s convenience.The IT Contractor Management System is an

information system that is owned and managedby a hypothetical organisation whose business isproviding IT contractors to large multinationalcompanies and managing the relationship. The


HOME


CASE STUDY

USE ANDMISUSE CASES



4

FIGURE 1

THE UNIFIED PROCESS(ELECTRONIC COPY FROM [KIVISTÖ, 2000])

1»

2»

organisation deals with administrative tasks suchas organising jobs for and making payments tothe IT contractors; it employs Human Resources(HR) administrators to do such tasks.The information system provides the following

functions to its users:

� IT contractors can ‘Change (their own)Payment Details’

� IT contractors can ‘Submit Invoices’� HR administrators can ‘Pay Invoices’� IT contractors and HR administrators can‘Arrange a Job’

The information system is connectedto the Internet and provides a web-based interface to IT contractors.

4. MISUSE CASES—BADUSE CASESUse cases are used to describe the func-tionality that an information systemprovides to actors (anyone or anythingthat interacts with the system). Theyare commonly used in software engi-neering during the requirements andanalysis workflows of the unifiedprocess. Use cases can be either dia-grammatic or textual, for more informa-tion see Bittner et al [Bittner & Spence,2003].The diagrammatic use case in FIGURE 2

shows two actors from the case study(the HR administrator and the IT con-tractor). Significantly, the HR adminis-


HOME


CASE STUDY

USE ANDMISUSE CASES



5

FIGURE 2

USE CASE DIAGRAM FOR THEIT CONTRACTORMANAGEMENT SYSTEM

trator can pay invoices and theIT contractor can only submitinvoices, not pay them. A possi-ble motivation for an escalationof privileges attack?Use cases are things that we

want to happen; now we intro-duce the concept of a misuser,an actor who will misuse oursystem. These misuses arecommunicated using misusecases. Misusers could be illegit-imate users of the system orlegitimate users of the system(‘insiders’); shown in FIGURE 3 inblack and grey respectively.

FIGURE 3 shows how we cancommunicate misuse cases forthe IT Contractor Management informationsystem in a visually powerful way (in grey andblack). There are two misuse cases shown:‘Escalate Privileges’ and ‘View Payment’; the for-mer misuse is conducted by an internal misuser(a rogue IT contractor). Essentially the informa-tion security professionals can take a use casediagram from the software engineers and injecta healthy dose of paranoia by thinking: “Howcan the information system be misused by the

bad guys?”Security professionals forget the malicious

insider at their peril. In FIGURE 3we have consid-ered what a malicious IT contractor may do withthe IT Contractor Management information sys-tem. Escalating their privileges to become a HRadministrator would be quite an attractive misusebecause they could then pay people of theirchoosing; in Section 5.2 we consider this misusein more detail.


HOME


CASE STUDY

USE ANDMISUSE CASES



6

FIGURE 3

A SIMPLEMISUSE CASE DIAGRAM

5. APPLYING THEMISUSE CASE TECHNIQUESIn this section we illustrate three complementarytechniques based on misuse cases. They aremost effective when applied in numerical order aseach technique builds on the information fromthe previous ones.

5.1 TECHNIQUE 1: MISUSE CASES TO IDENTIFYTOP-LEVEL MISUSES OF A SYSTEMExpanding on the ideas in FIGURE 3, we can reallygive our software engineering friends somethingto think about by applying some ‘bad guy thinking’to the use case diagram from FIGURE 2 and super-imposing our misuse cases to create FIGURE 4.


HOME


CASE STUDY

USE ANDMISUSE CASES



7

FIGURE 4

AMISUSE CASEDIAGRAM FORTHE IT CONTRACTORMANAGEMENTINFORMATIONSYSTEM

In FIGURE 4we have identified how our informa-tion system could be misused by internal andexternal actors (we have rightly or wronglyassumed our HR Administrators would not mis-use the information system). Notice how the mis-use cases relate to the use cases of the system,illustrating the point that every individual usecase affords an opportunity for a misuse. Forexample by enabling jobs to be arranged onlinewe have given malicious external misusers theopportunity to ‘Change Job Dates’ and IT con-tractors the ability to ‘Repudiate Jobs’ (by claim-ing that “It could have been a hacker!”).

FIGURE 4 is not a ‘complete’ diagram because itdoes not show all of the possible misuse cases forour informationsystem; this is for twoprincipal reasons:

� Space constraintsmean we have notrecorded all possiblemisuses, just the oneswe judged to be mostimportant;

� An unstructuredapplication of the tech-nique means that we

may not have identified all possible misuses ofour system.

Verifiable completeness of misuse analysis iscommonly understood to be unachievable becauseit is not a ‘formal analysis method’—refer to theTechnical Report [Ruck, 2008] for a more in depthdiscussion. We propose two modifications toTechnique 1 that make the analysis more rigorous.

5.1.1 SUGGESTED MODIFICATION 1: TABULATIONTo address the issue of space constraints wepropose the use of a table; an example of this isshown in the table below.Prioritising the misuse cases (in a similar man-


HOME


CASE STUDY

USE ANDMISUSE CASES



8

EXAMPLEMISUSES TOTHE IT CONTRACTORMANAGEMENT SYSTEM

DESCRIPTION LIKELI-PRIORITY OFMISUSE MISUSER IMPACT HOOD

1 Escalate Privileges Internal User VH M

2 View Invoice Internal User M H(of another user)

3 View Payment External Misuser H M

4 ...

ner to risks) enables us to know which misuseswe are most concerned about; and therefore aremore important to mitigate.

5.1.2 SUGGESTED MODIFICATION 2:APPLICATION OF THE STRIDE CLASSIFICATIONTo address the issue of an unstructured applica-tion of the misuse case techniques we proposethat each individual use case in turn is consideredagainst the STRIDE classification system (Spoof-ing, Tampering, Repudiation, Information Disclo-sure, Denial of Service and Escalation of Privi-lege), by asking the question “Which of theSTRIDE misuses are we concerned about for thisindividual use case?”.We maintain that all of the misuse cases identi-

fied in FIGURE 4 could be derived from a STRIDEclassification; for example: the ‘View Invoice’ mis-use case could be derived from the ‘InformationDisclosure’ STRIDE classification.For more information on STRIDE refer to

Microsoft’s Threat Modelling process [Swiderski& Snyder, 2004].

5.2 TECHNIQUE 2: SECURITY USE CASESApplication of Technique 1 and our suggestedenhancements to the IT Contractor ManagementSystem will result in a prioritised list of top-level

misuse cases that is as complete as possible. Atthis stage however we will not know sufficientdetail of how these misuses can be conducted. Toget more detail it is necessary to develop textualdescriptions; security use cases provide an idealvehicle for this.Security use cases were initially proposed by

Sindre et al. [Sindre, Firesmith, & Opdhal, 2003].They are a powerful tool that can be used to com-municate both the details of the misuses andwhat the system needs do to counter the misus-es. Firesmith [Firesmith, 2003] elaborated on theoriginal technique and we adopt his approach andmake some slight modifications; see the Techni-cal Report [Ruck, 2008] for more detail.Creating a security use case is time consuming

so it makes sense to focus on the misuse casesthat have been identified as high priority (byapplication of Technique 1). To that end we haveused a security use case for authorisation todevelop the ‘Escalation of Privilege’ misusecase.The blue arrow shown in FIGURE 5 on pages 10

and 11 traces the actions performed by the mis-user; in order left to right, top to bottom. In doingthis we can identify and record what the systemcan do to counter (prevent, detect or respond to)


HOME


CASE STUDY

USE ANDMISUSE CASES



9(Continued on page 12)


HOME


CASE STUDY

USE ANDMISUSE CASES



10

FIGURE 5

SECURITYUSE CASE FORAUTHORISATION (TOMITIGATE THE PRIVILEGE ESCALATIONMISUSE)

� SECURITY USE CASE: Authorisation

� SECURITY USE CASE PATH: Attempted escalation of privileges

� SECURITY THREAT: The user becomes a misuser and bypasses authorisation controls to obtain theprivileges of the administrator

� MISUSER PROFILE: Users are IT contractors therefore it reasonable to assume a high degree of tech-nical competence (capability). Due to recent disputes over payments it is judged to be moderatelylikely that users would be motivated to conduct the misuse (likelihood).

� TRIGGER: Always true. This can happen at any time

� PRECONDITIONS: 1) Misuser is authorised by the system as a user; 2) Misuse is able to upload dataof their choosing to the system

� PREVENTION REQUIREMENTS: 1) The systemmust only permit on site administration of the system;2) The systemmust not allow users to upload information of their choosing to the system

� POST CONDITIONS: 1) The system should have prevented the user escalating their privileges; 2) Thesystemmust have detected and responded to the user attempting to escalate their privileges

� MITIGATION GUARANTEE: Verified by testing at each stage in the system development lifecycle

� TECHNOLOGY AND DATA VARIATIONS: If zero-day attacks are used it is highly unlikely it will bepossible to prevent the attack (hence the importance of detection and response)

(CONTNUEDON PAGE 11)


HOME


CASE STUDY

USE ANDMISUSE CASES



11

FIGURE 5

IT CONTRACTORINTERACTIONS

The userauthenticates tothe system andis authorisedas a user

HR ADMINISTRATORINTERACTIONS

Administrators in-vestigate the event,if it is unexpectedconsider shuttingdown the system

MISUSERINTERACTIONS

User (nowmisuser) uploadsa maliciousprogram to thesystem

Misuser attemptsto execute mali-cious program andgain administratorauthorisation

Misuser attemptsto interceptnotification

Misuser attemptsto cover theirtracks by deletingsystem logs

SYSTEMINTERACTIONS

The system couldalert other admin-istrators that anescalation of privi-lege has occurred

The systemmustrequire notifica-tion of receipt forany alerts

SYSTEM ACTIONS

1) The system mustlog user transactions2) The system mustscan all uploaded datafor malicious content

The system mustlog that an escalationof privilege hasoccurred

The system logmust be append only(no entries can bedeleted)

SECURITYUSE CASE FORAUTHORISATION (CONTINUED FROMPAGE 10)

SYSTEM REQUIREMENTS

what the misuser is doing and record them in thegrey shaded area of the table in FIGURE 5. Thesecountermeasures are the system’s securityrequirements.The power of this technique is that it provides

a means of binding the security requirements (inthe grey area in FIGURE 5) with a top-level misusecase from Technique 1 (privilege escalation) byencapsulating them in a security use case. Fromthe table on page 8, we know that the ‘PrivilegeEscalation’ misuse case is the one we considerhighest priority and therefore the system securityrequirements that counter privilege escalation(contained in the security use case for authorisa-tion) should also be the highest priority. If moneyand time became an issue later on in the systemlifecycle we would look to ‘de-scope’ the require-ments relating to our lower priority misuses casesinstead.

5.3 TECHNIQUE 3 : ADAPTING SECURITY USECASES TO GENERATE TEST SCENARIOSApplication of Technique 2 has enabled us toidentify and communicate the security require-ments that we really care about. The questionnow becomes “how can we verify the securityrequirements have been implemented successfully

throughout the system lifecycle?”Technique 3 is a novel approach that combines

activity diagrams (for more information see Bit-tner et al [Bittner & Spence, 2003]) and securityuse cases (Technique 2) to describe test scenar-ios for an information system. Individual systemsecurity requirements can be verified by conduct-ing the test cases (TCs) that make up the testscenario. FIGURE 6 on page 12 shows the test sce-nario for the privilege escalation misuse for the ITContractor Management System; the test casesare shown in the red boxes.If a test case fails then we will know that the

corresponding security requirement has not beensatisfied and remedial action will be needed (ifit is deemed to be of sufficiently high priority).By placing the test scenario shown in FIGURE 6

in the hands of the system testers, it becomesincredibly powerful because it gives them a sim-ple way of verifying:

� Individual security requirements have beenrealised by the implementation;

� Misuses of the system are prevented, detect-ed or responded to by the information system.

Conducting the test scenarios throughout the


HOME


CASE STUDY

USE ANDMISUSE CASES



12(Continued on page 14)

(Continued from page 9)

FIGURE 6


HOME


CASE STUDY

USE ANDMISUSE CASES



13

ACTIVITY DIAGRAM SHOWING THE TEST SCENARIO AND TEST CASES (TCS) FOR THE‘PRIVILEGE ESCALATION’ MISUSE FOR THE IT CONTRACTORMANAGEMENT SYSTEM

system development lifecycle, as directed by theUP (shown in FIGURE 1), will achieve ‘traceabilityof the requirements’ throughout the phases of theinformation system.

6. CONCLUSIONS AND FURTHERWORK6.1 SUMMARYWe have taken the ‘best of breed’ misuse casetechniques and applied them to an IT ContractorManagement System.We have proposed ourown modifications and extensions to the existingtechniques (Techniques 1 & 2) and come up witha novel approach that combines two existingtechniques (Technique 3). By applying the tech-niques to the case study we have identified:

� The potential misuses of our informationsystem and the ones we care about most(Technique 1);

� The system security requirements that areneeded to mitigate the misuses we care aboutmost (Technique 2);

� The test scenarios that we can use to verifythat the security requirements that we care abouthave been met throughout the lifecycle of theinformation system (Technique 3).

As we have shown the three techniques canbe extremely powerful especially when usedsequentially within the context of a system devel-opment process.

6.2 USING MISUSE CASE TECHNIQUESIN THE REAL WORLDIn Section 5.1.2 we proposed using the STRIDEclassification to make the set of misuse cases weidentify for our information system as completeas possible, but how can we be sure that we haveidentified everything?If a complete set of pre-defined misuse cases

existed, then information security professionalscould do a ‘sanity check’ by comparing the com-plete list with their set of misuse cases for theinformation system. In 2003 Sindre et al [Sindre,Firesmith, & Opdhal, 2003] claimed that workwas underway to develop a library of re-usablemisuse cases. Unfortunately if such librariesalready exist they are not readily available in thepublic domain.Having a complete set of misuse cases as a

starting point would not guarantee that we wouldderive a complete set of security requirements(using Technique 2) because we could still over-look important countermeasures. To allay this


HOME


CASE STUDY

USE ANDMISUSE CASES



14

(Continued from page 12)

we suggest that a formal check is done by com-paring:

� The security requirements identified whenapplying Technique 2 and;

� The security functional requirements (SFRs)in the Common Criteria [Common Criteria, 2005,Part 2].

6.3 FUTURE WORKDeveloping a library of re-usable misuse caseswould be a significant contribution to the area.Schumacher et al [Schumacher, Fernandez-Buglioni, Hybertson, Buschmann, & Sommerlad,2006] propose the use of patterns (solutions tocommon problems in a given context) as a solu-tion.There is no documented study of a ‘real world’

application of misuse case techniques. Triallingour techniques and, in particular, the modifica-tions we propose would provide invaluable realworld feedback. If you are working with misusecases or interested in trialling the techniques inan operational environment please contact theauthors of this article. �

ABOUT THE AUTHORS

John Neil Ruck is a senior consultantworking for the UK government and has 7 yearsof experience in the information security profes-sion. His specialities include the evaluation ofthe security of information systems and Identifi-cation and Authentication (ID&A). He hasworked on a number of high-profile governmentprojects including leading the technical deliveryof the ePassports Country Signing CertificateAuthority (used in the digital signing of all UKePassports).He has an MSc with distinction in Informa-

tion Security from Royal Holloway and is aguest lecturer at Coventry University on thesubject of Information Security.

Dr. Geraint Price is a lecturer in infor-mation security at Royal Holloway, Universityof London, with research interests in public keyinfrastructures and denial of security attacks.Dr. Price teaches the course in Security Tech-nologies in the Secure Digital Business pathwayof the M.Sc. in Information Security at RoyalHolloway.


HOME


CASE STUDY

USE ANDMISUSE CASES



15


HOME


CASE STUDY

USE ANDMISUSE CASES



16

REFERENCES:

Bittner, K., & Spence, I. (2003). Use Case Modelling. Boston: Pearson Eduction.

Common Criteria. (2005). ISO 15408:2005 Common Criteria for Information Technology Security Evaluation version 3.1.International Organisation for Standardisation.

Davis, A. M. (1993). Software Requirements: Objects, Functions and States. Prentice-Hall.

Firesmith, D. (2003). Security Use Cases. Journal of Object Technology , 2 (3), 53-64.

Jacobson, I., Booch, G., & Rumbaugh, J. (1999). The Unified Software Development Process. Reading: AddisonWesley.

Kivistö, K. (2000, December). A Third Generation Object-Oriented Process Model: Roles and Architectures in Focus.Retrieved August 28, 2008, from University of Oulu, Finland: http://herkules.oulu.fi/isbn9514258371/html/c199.html

Ruck, J. (2008, September). Applying Misuse Cases to improve the Security of Information Systems, MSc Dissertationfor Royal Holloway, University of London: http://www.ma.rhul.ac.uk/static/techrep/2009/RHUL-MA-2009-05.pdf

Schneier, B. (2004). Secrets & Lies- Digital Security in a NetworkedWorld (with new information post-9/11 security).Indianapolis: Wiley Inc.

Schumacher, M., Fernandez-Buglioni, E., Hybertson, D., Buschmann, F., & Sommerlad, P. (2006). Security Patterns- Inte-grating Security and Systems Engineering. Chichster: JohnWiley and Sons.

Sindre, G., Firesmith, D. G., & Opdhal, A. L. (2003). A Reuse-based Approach to Determining Security Requirements.REFSQ'03 Pre-proceedings (pp. 106-114). Klagenfurt/Velden: REFSQ.

Swiderski, F., & Snyder, W. (2004). Threat Modelling. Redmond, Washington: Microsoft Press.

http://www.ma.rhul.ac.uk/static/techrep/2009/RHUL-MA-2009-05.pdf

http://herkules.oulu.fi/isbn9514258371/html/c199.html

Documents

MisuseCases:earlierandsmarterinformationsecurity ...media.techtarget.com/searchSecurityUK/downloads/RHUL_Ruck_fina… · RoyalHollowaySeries MisuseCases:earlierandsmarterinformationsecurity