Abuse & Misuse Cases

Overview

The purpose of this activity is to get you acquainted with writing abuse and misuse cases in tandem with writing use cases.

Setup

This activity is for groups of 4-6 people. Your instructor will assign each team a different system. For this exercise, your team is in charge of coming up with the system’s functionality, as well as specifying the requirements. Please assign the following roles:

• Scribe - the person who is writing the use case document
• Customer - the person who determines the functionality of the system

Activity

1. Give your system a title. Start up a document on GoogleDocs (make sure it has edit sharing permissions with the instructor and CA).
   Name it as follows: [semesterID]-331.[section]-[Title].
   Use the title “Requirements Specification for X” where X is the title of your system.
   e.g. 2195-331.01-Requirements Specification for Boeing 737Max

   Create a cover page with the title of the document, and the names of each member of your team.

   Also, place the following headers in the document to be filled out:

   • Overview
     • Description
     • Good Actors
     • Bad Actors
     • Security Goals
   • Use Case 1
     • Primary Actor
     • Preconditions
     • Main Flow of Events
     • Misuse Case
       • Flow of events Harm done
     • Abuse Case
       • Flow of events Harm done
   • Use Case 2
     • Primary Actor
     • Preconditions
     • Main Flow of Events
     • Misuse Case
       • Flow of events Harm done
     • Abuse Case
       • Flow of events Harm done
   • Security Requirements

2. Conduct a requirements elicitation session with the customer. The customer is in charge of brainstorming the functionality, but must be reasonable as the instructor can override any customer decision. The scribe takes informal notes from this meeting (no requirements just yet).

3. Fill in the Overview section based on your requirements elicitation session. What is the system, in general? What are the general security goals of the system? Who are the actors (both regular and malicious)?

4. Begin to brainstorm some good use cases. Write the titles of 3-5 use cases. Don’t write the scenarios just yet.

5. Elaborate on one use case. Write the main flow, about 4-10 steps. Be specific about what information is being exchanged. You may add alternative flows if you see the need, but they are not required for this exercise.

6. Now write both a misuse case and abuse case for that use case. A few notes:

   • Be sure to include both flow of events and harm done.
   • Make sure the flow affects your main flow, not your preconditions. You may violate a precondition in the process, but this section is for demonstrating how you can abuse/misuse the main flow.
   • Update the header to label each one as either Abuse or Misuse.

7. Sketch another use case (no need to be super-detailed on the use case if time is short). Write a detailed abuse AND misuse case for that. Thus, your requirements document should have a good mix of misuse and abuse cases.

8. Now that you have defined multiple different abuse and misuse cases, generalize those into security requirements that are not specific to any particular use-case, but are specific to your system. Document it this way:

   • Add a list to the end of your requirements document that defines these security requirements. Each security requirement should have a self-documenting identifier, e.g. “Sec1”
   • Add security requirement references to the step in the primary flows (and alternative flows if you added any).

9. Be ready to discuss your abuse and misuse cases with the rest of the class.

Submission & Grading

Share your document with your instructor so they can give feedback and mark your participation.

Meneely’s section. If you are in-person, be sure to take the attendance quiz. If you are online, share your document with the instructor (axmvse) and grader (sp9586).