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>