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

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 benefits from requirements? ● SWEN-331: Engineering Secure Software Benjamin S Meyers 2

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 SWEN-331: Engineering Secure Software Benjamin S Meyers 3

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! SWEN-331: Engineering Secure Software Benjamin S Meyers 4

What the System Should Be SWEN-331: Engineering Secure Software Benjamin S Meyers 5

What the What the System System Is Should Be SWEN-331: Engineering Secure Software Benjamin S Meyers 6

What the System Should Be What the System Is SWEN-331: Engineering Secure Software Benjamin S Meyers 7

Unintended Functionality What the System Should Be Vulnerabilities are ● often in areas of too much functionality What the System Is Vulnerabilities are ● features for attackers Vulnerabilities Bugs Faults SWEN-331: Engineering Secure Software Benjamin S Meyers 8

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 SWEN-331: Engineering Secure Software Benjamin S Meyers 9

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) SWEN-331: Engineering Secure Software Benjamin S Meyers 10 10

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 ○ opportunity to do something unintentional A good test: if you COULD do this again intentionally, would that ○ be abuse? If yes, then it’s misuse SWEN-331: Engineering Secure Software Benjamin S Meyers 11 11

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 SWEN-331: Engineering Secure Software Benjamin S Meyers 12 12

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 ● SWEN-331: Engineering Secure Software Benjamin S Meyers 13 13

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 SWEN-331: Engineering Secure Software Benjamin S Meyers 14 14

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 SWEN-331: Engineering Secure Software Benjamin S Meyers 15 15

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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 16 16

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 ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 17 17

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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 18 18

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? ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 19 19

Abuse/Misuse Cases vs. Risk Assessment Abuse & Misuse Cases Risk Assessment ● ● Involves planning Involves planning ○ ○ Potentially infinite Potentially infinite ○ ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 20 20

Abuse/Misuse Cases vs. Risk Assessment Abuse & Misuse Cases Risk Assessment ● ● Involves planning Involves planning ○ ○ Potentially infinite Potentially infinite ○ ○ Emphasize domain Emphasize all risks ○ ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 21 21

Abuse/Misuse Cases vs. Risk Assessment Abuse & Misuse Cases Risk Assessment ● ● Involves planning Involves planning ○ ○ Potentially infinite Potentially infinite ○ ○ Emphasize domain Emphasize all risks ○ ○ Scenario-driven Quantitative ○ ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 22 22

Abuse/Misuse Cases vs. Risk Assessment Abuse & Misuse Cases Risk Assessment ● ● Involves planning Involves planning ○ ○ Potentially infinite Potentially infinite ○ ○ Emphasize domain Emphasize all risks ○ ○ Scenario-driven Quantitative ○ ○ Originates from abusing Originates from CIA assets, ○ ○ functionality p(exploit) SWEN-331: Engineering Secure Software Benjamin S Meyers 23 23

Abuse/Misuse Cases vs. Risk Assessment Abuse & Misuse Cases Risk Assessment ● ● Involves planning Involves planning ○ ○ Potentially infinite Potentially infinite ○ ○ Emphasize domain Emphasize all risks ○ ○ Scenario-driven Quantitative ○ ○ Originates from abusing Originates from CIA assets, ○ ○ functionality p(exploit) What if this happens? What might happen? ○ ○ SWEN-331: Engineering Secure Software Benjamin S Meyers 24 24

Abuse/Misuse Cases vs. Risk Assessment Abuse & Misuse Cases Risk Assessment ● ● Involves planning Involves planning ○ ○ Potentially infinite Potentially infinite ○ ○ Emphasize domain Emphasize all risks ○ ○ Scenario-driven Quantitative ○ ○ Originates from abusing Originates from CIA assets, ○ ○ functionality p(exploit) What if this happens? What might happen? ○ ○ Helps refine and discover ○ new abuse cases SWEN-331: Engineering Secure Software Benjamin S Meyers 25 25