Misuse and Abuse cases
Engineering Secure Software
What is a requirement?
How do you define it?If done well, what are they useful for?
© 2011-2012 Andrew Meneely
Key Requirement Properties
What the system should…DoNot doWho interacts with the system (actors)Highly domain-specificDescribe how the surrounding environment has changed as a result of the system
Security is Not a Set of Features
Secureis an emergent property of software“Being dry” in a tent in the rainBeing 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
Vulnerabilities are in areas oftoo muchfunctionality
Copyright © Andrew Meneely
What the System Should Be
Non-security faults (bugs)
Use Case Review
Use cases include:ActorPreconditionsMain flow describes the primary scenarioAlternative scenarios describe how the system reacts to alternative cases
Misuse & Abuse Cases
A scenario within a use case in which an actor compromises the systemFlow of events, but with malicious usageDefine the harm done to the systemKeys:Domain, domain, domain.Don’t focus on coding and design vulnerabilities hereMalicious actors are creativeQuestion the assumptions of the systemFocus on what the actorcando overwilldo(prioritize later)
Misuse vs. Abuse
Misuse is unintentionalAbuse is intentionalMisuse cases are still security-related (crime of opportunity)Abuse cases imply the actor is actively seeking vulnerabilities
e.g. Maintain Drug Interactions
Actor: Hospital AdministratorPrecondition: Admin is authenticated.Main Flow:Admin selects two different drug codes from the National Drug Codes selection menuAdmin enters a minimum dosage for both drugsAdmin enters text notes about the potential consequences of the interactionAdmin is shown a table of patient records where the interaction rule would applyAdmin saves the interaction rule
e.g. Misusing Maintain Drug Interactions
Misuse caseMain flow steps 1-3Admin is shown a set of patient records that have not been authorized for hospital administrator viewingHarm done: Patient privacy has been violated
e.g. Abusing Maintain Drug Interactions
Abuse caseActor: attacker who has spoofed an administrator’s identityRepeat Main Flow steps 10,000 timesProviding many rules for all different drug interactionsAuto-generate vague, technical text notes for each interaction ruleStop when the preview step takes over a minute to completeHarm done:Patients are overwhelmed by alerts, so alerts become ignoredAvailability of the system is compromised
Isn’t this infinite?
YesBut even one good abuse case goes farEasier to think beyond one scenarioStarts a discussionGets stakeholders and developers into a balanced mindset early onMotivates good design decisions
Generalized forms of misuse and abuse casesUse-cases trace to security requirementsDocument these in the main flowAlso called “anti-requirements”E.g. from Maintain Drug InteractionsHospital administrators are only allowed to view a patient’s record with explicit, opt-in indication from the patientAll actors are limited to 10 server requests per minute
Think of the best engineer on your teamFire them and humiliate them publiclyNow challenge them to break your systemWhat would they go after?What knowledge could they leverage the most?
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 plug-in?
See course website for “Abuse & Misuse Cases”Systems are:An auction websiteA charity micro-lending website (e.g. Kiva.org)A social networking website for model rocket hobbyistsAsmartphoneapp for trading recipes with people in your neighborhoodA reservation system for virtual images to be run on serverfarmsA moderated and curated question-and-answer site (e.g.StackOverflow)A crowd-sourced servicethat curatesautomated language translation