Misuse & Abuse Cases Engineering Secure Software Last Revised: - - PowerPoint PPT Presentation

▶
misuse abuse cases
SMART_READER_LITE
LIVE PREVIEW

Misuse & Abuse Cases Engineering Secure Software Last Revised: - - PowerPoint PPT Presentation

Sep 11, 2023 365 likes •652 views

Misuse & Abuse Cases Engineering Secure Software Last Revised: October 9, 2020 SWEN-331: Engineering Secure Software Benjamin S Meyers 1 What is a Requirement? How do you define it? If done well, what are they useful for? Who

slide-1
SLIDE 1

SWEN-331: Engineering Secure Software Benjamin S Meyers

Misuse & Abuse Cases

Engineering Secure Software

Last Revised: October 9, 2020 1

slide-2
SLIDE 2

SWEN-331: Engineering Secure Software Benjamin S Meyers

What is a Requirement?

  • How do you define it?
  • If done well, what are they useful for?
  • Who benefits from requirements?

2

slide-3
SLIDE 3

SWEN-331: Engineering Secure Software Benjamin S Meyers

Key Properties of Requirements

  • What the system should…

○ Do ○ Not do

  • Who interacts with the system (actors)
  • Highly domain-specific
  • Describe how the surrounding environment has changed as a

result of the system

3

slide-4
SLIDE 4

SWEN-331: Engineering Secure Software Benjamin S Meyers

Security is Not a Set of Features

  • Secure is an emergent property of software

○ Emergent: result of nothing failing

e.g. Being dry in a tent in the rain

○ Being secure is the result of many, many factors, not one feature (e.g. SSL)

  • … so requirements documents should not just be a list of

features!

4

slide-5
SLIDE 5

SWEN-331: Engineering Secure Software Benjamin S Meyers 5

What the System Should Be

slide-6
SLIDE 6

SWEN-331: Engineering Secure Software Benjamin S Meyers 6

What the System Should Be What the System Is

slide-7
SLIDE 7

SWEN-331: Engineering Secure Software Benjamin S Meyers 7

What the System Should Be What the System Is

slide-8
SLIDE 8

SWEN-331: Engineering Secure Software Benjamin S Meyers 8

What the System Should Be What the System Is

Vulnerabilities Bugs Faults

Unintended Functionality

  • Vulnerabilities are
  • ften in areas of

too much functionality

  • Vulnerabilities are

features for attackers

slide-9
SLIDE 9

SWEN-331: Engineering Secure Software Benjamin S Meyers

Use Case Review

  • Use Cases include:

○ Actor(s) ○ Precondition(s) ○ Main flow describing the primary scenario ○ Alternative flows describing how the system reacts to alternative scenarios

9

slide-10
SLIDE 10

SWEN-331: Engineering Secure Software Benjamin S Meyers

Misuse & Abuse Cases

  • A scenario within a use case in which an actor compromises

the system

  • Flow of events, but with malicious usage
  • Define the harm done to the system
  • Keys:

○ Domain, domain, domain

Don’t focus on coding and design vulnerabilities here

○ Malicious actors are creative ○ Question the assumptions of the system ○ Focus on what the actor can do over what they will do

(prioritize later)

10 10

slide-11
SLIDE 11

SWEN-331: Engineering Secure Software Benjamin S Meyers

Misuse vs. Abuse

  • Misuse is unintentional; Abuse is intentional
  • Abuse cases imply the actor is actively seeking vulnerabilities
  • Misuse cases must still be security-related

○ NOT the same as alternative flows e.g. user mistakes are not usually misuse ○ “Crime” of opportunity -- system presents you with an

  • pportunity to do something unintentional

○ A good test: if you COULD do this again intentionally, would that be abuse? If yes, then it’s misuse

11 11

slide-12
SLIDE 12

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: Maintain Drug Interactions

  • Actor: Hospital Administrator
  • Precondition: Admin is authenticated.
  • Main Flow:

1. Admin selects two different drug codes from the selection menu 2. Admin enters minimum dosage for both drugs 3. Admin enters text notes about potential consequences of drug interaction 4. Admin is shown table of patient records where interaction rule would apply 5. Admin saves the interaction rule

12 12

slide-13
SLIDE 13

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example Misuse: Maintain Drug Interactions

  • Actor: Hospital Administrator
  • Precondition: Admin is authenticated.
  • Main Flow:

1. Admin selects two different drug codes from the selection menu 2. Admin enters minimum dosage for both drugs 3. Admin enters text notes about potential consequences of drug interaction 4. Admin is shown table of patient records where interaction rule would apply 5. Admin saves the interaction rule

  • Misuse Case:

1. Main flow steps 1-3 2. Admin is shown a set of patient records that have not been authorized for hospital administrator viewing

  • Harm Done: Patient privacy has been violated

13 13

slide-14
SLIDE 14

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example: Maintain Drug Interactions

  • Actor: Hospital Administrator
  • Precondition: Admin is authenticated.
  • Main Flow:

1. Admin selects two different drug codes from the selection menu 2. Admin enters minimum dosage for both drugs 3. Admin enters text notes about potential consequences of drug interaction 4. Admin is shown table of patient records where interaction rule would apply 5. Admin saves the interaction rule

14 14

slide-15
SLIDE 15

SWEN-331: Engineering Secure Software Benjamin S Meyers

Example Abuse: Maintain Drug Interactions

  • Actor: Hospital Administrator
  • Precondition: Admin is authenticated.
  • Main Flow:

1. Admin selects two different drug codes from the selection menu 2. Admin enters minimum dosage for both drugs 3. Admin enters text notes about potential consequences of drug interaction 4. Admin is shown table of patient records where interaction rule would apply 5. Admin saves the interaction rule

  • Abuse Case:

Actor: Attacker spoofing Hospital Administrator 1. Repeat main flow 10K times with different rules and vague notes 2. Stop when Main Flow Step 4 takes a long time to complete

  • Harm Done:

1. Patients are overwhelmed by alerts and ignore them 2. Availability of the system is compromised

15 15

slide-16
SLIDE 16

SWEN-331: Engineering Secure Software Benjamin S Meyers

Isn’t this Infinite?

  • Yes
  • But even one good abuse case goes a long way

○ Easier to think beyond one scenario ○ Starts a discussion ○ Gets stakeholders and developers into a balanced mindset early ○ Motivates good design decisions

16 16

slide-17
SLIDE 17

SWEN-331: Engineering Secure Software Benjamin S Meyers

Security Requirements

  • Generalized forms of misuse and abuse cases
  • Use cases trace to security requirements

○ Document these in the main flow

  • Also called “anti-requirements”
  • e.g. Maintain Drug Interactions:

○ Hospital administrators are only allowed to view a patient’s record with explicit, opt-in indication from the patient ○ All actors are limited to 10 server requests per second

17 17

slide-18
SLIDE 18

SWEN-331: Engineering Secure Software Benjamin S Meyers

Actor Inspiration

  • Think of the best engineer on your team
  • Fire them and humiliate them publicly
  • Challenge them to break your system

○ What would they go after? ○ What knowledge could they leverage the most?

18 18

slide-19
SLIDE 19

SWEN-331: Engineering Secure Software Benjamin S Meyers

Assumptions Inspiration

  • What are the other non-malicious users expecting in this

domain?

  • What are the ramifications of violating access restrictions?
  • Where could an attacker “sit in the middle”?

○ Sniff the network? ○ Load a plugin?

19 19

slide-20
SLIDE 20

SWEN-331: Engineering Secure Software Benjamin S Meyers

Abuse/Misuse Cases vs. Risk Assessment

  • Abuse & Misuse Cases

○ Involves planning ○ Potentially infinite

20 20

  • Risk Assessment

○ Involves planning ○ Potentially infinite

slide-21
SLIDE 21

SWEN-331: Engineering Secure Software Benjamin S Meyers

Abuse/Misuse Cases vs. Risk Assessment

  • Abuse & Misuse Cases

○ Involves planning ○ Potentially infinite ○ Emphasize domain

21 21

  • Risk Assessment

○ Involves planning ○ Potentially infinite ○ Emphasize all risks

slide-22
SLIDE 22

SWEN-331: Engineering Secure Software Benjamin S Meyers

Abuse/Misuse Cases vs. Risk Assessment

  • Abuse & Misuse Cases

○ Involves planning ○ Potentially infinite ○ Emphasize domain ○ Scenario-driven

22 22

  • Risk Assessment

○ Involves planning ○ Potentially infinite ○ Emphasize all risks ○ Quantitative

slide-23
SLIDE 23

SWEN-331: Engineering Secure Software Benjamin S Meyers

Abuse/Misuse Cases vs. Risk Assessment

  • Abuse & Misuse Cases

○ Involves planning ○ Potentially infinite ○ Emphasize domain ○ Scenario-driven ○ Originates from abusing functionality

23 23

  • Risk Assessment

○ Involves planning ○ Potentially infinite ○ Emphasize all risks ○ Quantitative ○ Originates from CIA assets, p(exploit)

slide-24
SLIDE 24

SWEN-331: Engineering Secure Software Benjamin S Meyers

Abuse/Misuse Cases vs. Risk Assessment

  • Abuse & Misuse Cases

○ Involves planning ○ Potentially infinite ○ Emphasize domain ○ Scenario-driven ○ Originates from abusing functionality ○ What if this happens?

24 24

  • Risk Assessment

○ Involves planning ○ Potentially infinite ○ Emphasize all risks ○ Quantitative ○ Originates from CIA assets, p(exploit) ○ What might happen?

slide-25
SLIDE 25

SWEN-331: Engineering Secure Software Benjamin S Meyers

Abuse/Misuse Cases vs. Risk Assessment

  • Abuse & Misuse Cases

○ Involves planning ○ Potentially infinite ○ Emphasize domain ○ Scenario-driven ○ Originates from abusing functionality ○ What if this happens?

25 25

  • Risk Assessment

○ Involves planning ○ Potentially infinite ○ Emphasize all risks ○ Quantitative ○ Originates from CIA assets, p(exploit) ○ What might happen? ○ Helps refine and discover new abuse cases

slide-26
SLIDE 26

SWEN-331: Engineering Secure Software Benjamin S Meyers

Misuse & Abuse Case Activity

  • Systems:

○ Team 1: An auction website ○ Team 2: A charity micro-lending website (e.g. kiva.org) ○ Team 3: A social networking website for model rocket hobbyists ○ Team 4: A smartphone app for trading recipes with your neighbors ○ Team 5: A reservation system for virtual images to be run on server farms ○ Team 6: A moderated/curated Q&A site (e.g. StackOverflow) ○ Team 7: A crowd-sourced service that curates automated language translation ○ Team 8: A mobile app for ride-sharing and taxi services

26 26

slide-27
SLIDE 27

SWEN-331: Engineering Secure Software Benjamin S Meyers

Misuse & Abuse Case Activity

1. Choose a scribe and a customer 2. Perform requirements elicitation

○ Scribe takes notes ○ Customer decides functionality

3.

Write overview: description, good/bad actors, general security goals

4. Brainstorm use cases -- write down 3-5 titles (no flows yet) 5. Pick a use case and write main flow (4-10 steps) -- be specific 6. Write a Misuse and an Abuse case for that use case -- include harm done 7. Repeat 5-6 (at least once) 8. Time permitting: write some generalized security requirements based on your misuse/abuse cases

27 27