Misuse Cases
Greg Sternberg, MSc, CISSP
Um, Duh?
Product should be secure and protect the customer's information
Um, Run That By Me Again...
NIST Special Publication 800-122 defines PII as "any information about an individual maintained by an agency, including (1) any information that can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or linkable to an individual, such as medical, educational, financial, and employment information."
Full name, mailing and home Address, email address, IP address, vehicle registration plate number, driver's license number, face, fingerprints, or handwriting, date of birth, birthplace, telephone number, login name, screen name, nickname, or handle, country, state, or city of residence, age, gender or race, school(s), workplace(s), grades, salary, or job position
Just Right (?)
All data passing over the Internet or over insecure network links must be encrypted, either at the network layer (i.e. IPsec as used within VPNs), the transport layer (i.e. SSL), or the application layer (i.e. PGP mail). All network links that pass through non-company owned buildings must be treated as insecure. Only traffic contained within server rooms or other well-controlled locations may be excluded from the encryption requirement. FTP must be replaced with SSH, HTTP with HTTPS, etc... on all insecure links.
Unspoken Requirements
User shall be allowed to store their credit card information so as to allow for faster purchasing at a later date
Our application data will be moved to the cloud (better availability, lower cost, more secure)
Negative Requirements(made worse)
Users shall not be allowed to access other user's data Users shall only be allowed to
read, add, change and delete only the information which they explicitly provided to the system during account creation or daily use.
Files containing a customer's personal information shall not be sent via ftp Files shall be sent via email
Abuse/Misuse/Negative Use Cases
We've been doing misuse cases since the dawn of time
Security isn't a set of features
Security don't care about a valid user (well, mostly)
Attackers may try the front door but they will use the neighbor's window and enter through the sewer system
Security is a preventive and less an enabler
We are interested in the breaking of systems and less on the using of them
e-Site Use CasesName Change SSN
Goal Allow an admin to change a user's SSN
Actor(s) Admin
Assumptions(s) •Customer has requested their SSN be updated•The request has been validated
Preconditions(s) •The admin has access to the web site
Event Flow •The admin enters their login information•The system validates the admin's information•Etc...
Alternate flow(s) N/A
Post condition(s)
The customer's SSN has been changed
Name Login
Goal Allow a user to access the system
Actor(s) Customer
Assumptions(s) None
Preconditions(s) •The customer has access to the web site
Event Flow •The customer enters their login information•The system validates the customers information•The system displays the home page
Alternate flow(s) N/A
Post condition(s)
The user is able to use the system
Pieces / parts
Who
Hostile
Accidental
Threats
Auditors
What
Assets
Compliance
Means
Threats
Motive
Why do they want it?
Opportunity
Vulnerabilities
Misuse Cases (by Role)
Management
Why? How much? Acceptable risk
Requirements
How should it react? Expectations
Architecture
Question assumptions. Assets
Development
"Why, sometimes I've believed as many as six impossible things before breakfast!"
Testing
Outside the box
External Misuse Factors
Actors
Employee / Ex-employee
User / Administrator
Hacker, Attacker and Spy
Application
Threats
Fraud
Theft
Disruption of service
Intrusion
Security goals
CIAA
e-Site Misuse CasesName Escalate Privileges
Goal Allow an unauthorized user to increase their access level
Actor(s) Hacker
Assumptions(s) None
Preconditions(s) •The hacker already has an account on the system
Event Flow <various>
Alternate flow(s) N/A
Post condition(s)
The hacker now has admin rights
Name DDoS
Goal Disrupt the system so it can no longer take legitimate login requests
Actor(s) Hacker
Assumptions(s) None
Preconditions(s) •There are externally facing URLs
Event Flow •A login request is generated•The login request is sent to the system via the URL•The number of requests per second is increased
Alternate flow(s) N/A
Post condition(s)
The user is able to use the system
e-Site Misuse Case Diagram(full)
Caveat Emptor
Requirement analysts aren't hackers
Analysis paralysis
Zero day attacks
Won't fix lack of direction
"That depends a good deal on where you want to get to," said the Cat.
"I don’t much care where--" said Alice.
"Then it doesn’t matter which way you go," said the Cat.
Questions?(And maybe even answers!)
Supporting Slides
E-commerce (e-Site) Use Case
Actor-Goal listActor(s) Goal(s)
Customer Login
Register Self
Place Order
Pay For Order
Cancel Order
Unregister Self
Administrator Monitor Site
Change SSN
Update Site
e-Site Misuse Case Diagram(w/ just Misuse Cases)
e-Site Mitigating Use Cases Name Queue Requests
Goal Allow only as many requests as the system can handle
Actor(s) Application
Assumptions(s) Rejecting or delaying requests is acceptable
Preconditions(s) •A maximum number of requests is determined
Event Flow •All requests are placed into a queue•Requests are pulled off as the application is ready for them•Excess requests are rejected before the application receives them
Alternate flow(s) N/A
Post condition(s) The system is always available
Name Encrypt Transaction
Goal Make it not cost effective to steal data
Actor(s) ApplicationAdministrator
Assumptions(s) None
Preconditions(s) •The key(s) are stored securely•The key(s) are available to the application
Event Flow •A transaction is created•The transaction is encrypted with the key
Alternate flow(s) N/A
Post condition(s)
The transaction has been encrypted
References Alexander, I. (1999). Misuse Cases Help to Elicit Non-Functional Requirements. Retrieved from
http://www.scenarioplus.org.uk/papers/misuse_cases/misuse_cases.htm
Alexander, I. Use/Misuse case analysis elicits non-functional requirements. Computing & Control Engineering Journal, Vol 14, 1, pp 40-45, February 2003. Retrieved from http://www.scenarioplus.org.uk/papers/misuse_cases_hostile_intent/misuse_cases_hostile_intent.htm
Allenby, K. & Kelly, T. Deriving Safety Requirements Using Scenarios. Proc. 5th International Symposium on Requirements Engineering RE'01, pp 228-235, 2001.
Cockburn, A. (2001). Writing effective use cases. Addison-Wesley.
McGraw, G. (Ed.). (2004). Misuse and Abuse Cases: Getting Past the Positive. IEEE Security & Privacy 2004. Retrieved from http://www.cigital.com/papers/download/bsi2-misuse.pdf
Sindre, G. & Opdahl, A. (2001). Templates for Misuse Case Description. Proc. 7th Intl Workshop on Requirements Engineering, Foundation for Software Quality (REFSQ'2001), Interlaken, Switzerland, 4-5 June 2001
Srivatanakul, T., Clark, J., & Polack, F. (2004). Writing Effective Security Abuse Cases. University of York Technical Report YCS-2004-375 http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=976CD9803D704C0F2B561C39C68519B1?doi=10.1.1.62.4125&rep=rep1&type=pdf
<more>