2. Misuse Cases – Security Requirements
From a Different Viewpoint
by
Greg Sternberg, CISSP, MSc
2

3. Bio
» Worked with computers for decades a long time
• Actually used punch cards a couple of times (and spilled once)
» Done just about everything with them
• Built them, programmed them, broke them, cursed them, …
» Work at Sungard Availability Services as a Security Architect
» Board member for ISSA, Denver, member of ISC(2), ISACA
» Speaker (obviously), author
» Certs: CISSP, CISM, TOGAF, MSc
» Affiliate Faculty at Regis College
3

4. Generic Requirements
4
» “Product ‘X’ must be secure
and protect the customer’s
data and the company’s IP.”

5. 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.”
5

6. Negative Requirements
» “Files containing the customer’s personal information shall
not be sent via FTP.”
• So email was used instead
» “All passwords shall be >8 characters, have at least 1
numeric digit, have at least one upper case character and 1
special character.”
• PASSWORD1!
» “Unauthorized users shall not be allowed to log onto the
system.”
• So a shared account (admin / Company01) was used
6

7. Misuse (What If?) Scenarios
» Not a new concept
• “Humans have analyzed negative scenarios
ever since they first sat around Ice Age
campfires debating the dangers of catching a
woolly rhinoceros. ‘What if it turns and
charges us before it falls into the pit?’”
» We do it all the time:
• Traffic
• Events
• Games
• Insurance
» Misuse vs. Abuse vs. Evil User Stories
7

8. Where To Start?
» Not a RIGHT way but plenty of right
ways
• User Story
• Use case
• UML diagram
• Requirements
» Not customer or user focused
» Don’t need to think like a hacker
» Won’t secure your system
8

9. A Web Service
» CRUD Order
» Ship Order
» Log in
» Log out
» CRUD User
9
General User
Admin User
Login
Ship Order
CRUD user
CRUD Order
Logout
<<extend>>

10. Web Service + Misuse
» Unauthorized
Address Change
» Falsify
Credentials
» Intercept
Communications
» Prevent
Legitimate
Access
10
General User
Admin User
Login
Ship Order
CRUD user
CRUD Order
Logout
Falisify Credentials
Malicious User
Intercept Communications
Unauthorized Address Change
Prevent Legitimate Access

11. Web Service + Misuse + Remediation
» 2-Factor
Authentication
» Lock Accounts
» Validate Entries
» Secure Transport
» Throttling
» Whitelisting
11
General User
Admin User
Login
Ship Order
CRUD user
CRUD Order
Logout
Falisify Credentials
Malicious User
Lock Account
Intercept Communications
Unauthorized Address Change
<<extend>>
2-Factor Authentication
<<extend>>
Secure Transport
<<extend>>
Validate Entries
<<extend>>
Prevent Legitimate Access
Throttling
Whitelisting
<<extend>>
<<extend>>

12. Prevent Legitimate Access
Name Prevent Legitimate Access
Goal(s) Disrupt the system so it can no longer take legitimate login requests. Distract the
administrators and security personal from the true goal of the hacker (i.e. system
penetration)
Actor(s) Hacker
Assumption(s) None
Precondition(s) There are externally facing access point(s) – i.e. URLs, APIs
Event Flow 1. A fake or spoofed login request is generated
2. Many login requests are sent to the system using the external access point
3. The number of these login requests exceeds the capacity of the system to handle
Alternate Flow(s) None
Post Condition(s)  Legitimate users are unable to access the system
 Applications (may) have abnormally stopped
 Network response times are unacceptable
 Application response times are unacceptable
 Administrators and security are distracted and not monitoring the system closely

13. Whitelisting
» As this application is only useable by internal
users, users who are connected to the
corporate VPN or customers who have
contracted to use it the firewall shall be
configured to only allow the CIDR of
X.X.X.X/20 or a customer provided CIDR.

14. Another Approach
» Attacker Scenario
• Who – Hostile, accidental, threats, auditors
• What – Assets, access, info
• Means - Threats
• Motive – Why do are they doing it?
• Opportunity - Vulnerabilities
14

15. When You Don’t Have A Single
Software Process
» Created a set of Agile OWASP Top 10 Misuse Stories
• They have some place to start
• They have a contact in security
• There’s a consistency (in security at least) across projects
• Focus more on elements that are unique to a project vs. the
basics
• Ties into ‘Software Security Assurance for the OWASP Top 10’
developer training
» “Why you Shouldn’t Use the OWASP Top 10 as a List of
Software Security Requirements.”
15

16. A1 Injection
» Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted
data is sent to an interpreter as part of a command or query. The
attacker’s hostile data can trick the interpreter into executing unintended
commands or accessing data without proper authorization.
• As a [Specially Crafted Statement] I want to [take advantage of a lack of input
validation] so that [I can retrieve information I'm not entitled to]
• As a [Executable User Data] I want to [take advantage of a lack of data
validation] so that [I can retrieve information I'm not entitled to]
• As a [Editable Config File] I want to [take advantage of unvalidated
configuration data] so that [I can have the program behave in a manner
beneficial to me]
16

17. As a [Specially Crafted Statement] I want to [take advantage of a lack of input
validation] so that [I can retrieve information I'm not entitled to]
» For example, if we use this Java:
» user_name = request.getParameter (“UserName”);
» query= “SELECT * FROM Users WHERE UserName=“ + user_name;
» statement = connection.createStatement (query);
» and the user types in 'Aeinstein' the SQL statement would look like:
» SELECT * FROM Users WHERE UserName= 'Aeinstein';
» which would return just the record for 'Aeinstein'. However, if I were to type in
something a bit different:
» SELECT * FROM Users WHERE UserName='Aeinstein' or 1=1
» the database would end up translating the SQL statement to:
» SELECT * FROM Users WHERE TRUE
» Instead do the following:
» PreparedStatement ps = connection prepareStatement (query);
» ps.setString (1, username);
» result = ps.executeQuery ();

18. More Information
» 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_case
s_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.
» Bird, Jim, Adding Appsec to Agile: Security Stories, Evil User Stories and Abuse(r)
Stories, https://dzone.com/articles/adding-appsec-agile-security
18

19. More Information
» 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
» OWASP, Agile Software Development: Don't Forget EVIL User Stories,
https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forg
et_EVIL_User_Stories
» SAFECode – http://www.safecode.org/
» 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=976CD9803D704C0F2B
561C39C68519B1?doi=10.1.1.62.4125&rep=rep1&type=pdf
19

20. Questions?
20
» If you liked the presentation:
• gwstern@comcast.net
• @gsternbe
• https://www.linkedin.com/in/g
regsternberg
» Otherwise:
• gwstern@spam.net
• @_dev_null_

21. Supporting Slides
21

22. Requirement vs. Use Case vs. User Story
» Requirements
• Nonfunctional – describe how the system works
• Functional – describes what the system does
• What the system is supposed to do at a level which can be tested and verified
» Use Cases
• A (usually) detailed description of a set of interactions between a system and one or more
actors
• About the behavior to meet the needs
• Describe a complete interaction
» User Stories/Scenarios
• A short description of something the ‘customer’ wants to do focused on the result from doing
that thing
• About needs
• Easy to read
22

23. A2 – Broken Authentication and
Session Management
» Application functions related to authentication and session management are often
not implemented correctly, allowing attackers to compromise passwords, keys, or
session tokens, or to exploit other implementation flaws to assume other users’
identities.
• As a [Forever User Session] I want to [be able to reuse session information] so that [I can reuse
another user's session]
• As a [Unencrypted A/A Token] I want to [log in as someone I'm not] so that [I can have
unfettered access to the system]
• As a [Simple Password] I want to [be easily broken] so that [I can pretend to be another user]
• As a [Man In The Middle] I want to [pretend to be someone else] so that [I can trick the
system (or user) into treating me as someone I’m not]
• As a [Malicious User] I want to [find sessions that have not been closed] so that [I can pretend
to be that user]
23

24. A3 – Cross-Site Scripting / XSS
» XSS flaws occur whenever an application takes untrusted data and
sends it to a web browser without proper validation or escaping.
XSS allows attackers to execute scripts in the victim’s browser which
can hijack user sessions, deface web sites, or redirect the user to
malicious sites
• As a [Code In User Data] I want to [be executed] so that [I can have the
program behave in an undesired manner]
• As an [Malicious Client] I want to [send dangerous information to the
server] so that [I can have the server behave how I want]
• As an [Malicious Server] I want to [send dangerous information to the
client] so that [I can have the client behave how I want]
24

25. A4 – Insecure Direct Object References
» A direct object reference occurs when a developer exposes a reference to
an internal implementation object, such as a file, directory, or database
key. Without an access control check or other protection, attackers can
manipulate these references to access unauthorized data.
• As a [Everyone Has Access To Everything] I want to [access information] so that
[I can make copies of it for my personal use]
• As an [Editor of URL Strings] I want to [try different URLs] so that [I can map
out the directory hierarchy of the system]
• As an [Editor of URL Strings] I want to [try different URL parameters] so that [I
can alter the behavior of the system]
• As a [Malicious Keyboard] I want to [change url] so that [I can get access to a
different directory]
25

26. A5 – Security Misconfiguration
» Good security requires having a secure configuration defined and
deployed for the application, frameworks, application server, web
server, database server, and platform. Secure settings should be
defined, implemented, and maintained, as defaults are often
insecure. Additionally, software should be kept up to date.
• As a [User of the Internet] I want to [find default information and try
it] so that [I can gain access to systems]
• As a [Lazy Malicious Person] I want to [try to access systems using
existing backdoors] so that [I can steal data and control the system]
• As a [Unsecured File] I want to [be modified] so that [a malicious
attacker can change the system’s behavior]
26

27. A6 – Sensitive Data Exposure
» Many web applications do not properly protect sensitive data, such
as credit cards, tax IDs, and authentication credentials. Attackers
may steal or modify such weakly protected data to conduct credit
card fraud, identity theft, or other crimes. Sensitive data deserves
extra protection such as encryption at rest or in transit, as well as
special precautions when exchanged with the browser.
• As a [Reader of Caches] I want to [scan system and application caches]
so that [I can glean sensitive data or passwords]
• As a [Modifier of URLs] I want to [modify parameters] so that [I can
have the system give me things for free]
• As a [XML guru] I want to [modify XML parameters] so that [I can have
the system behave in a fashion beneficial to me]
27

28. A7 – Missing Function Level Access
Control
» Most web applications verify function level access rights before making
that functionality visible in the UI. However, applications need to perform
the same access control checks on the server when each function is
accessed. If requests are not verified, attackers will be able to forge
requests in order to access functionality without proper authorization.
• As a [Malicious Program] I want to [try different parameters] so that [I can
make the program behave in a fashion it is not supposed to]
• As a [Malicious Client] I want to [bypass client controls] so that [I can affect
the system]
• As a [Creator of RESTful calls] I want to [pretend to be a legitimate invocation]
so that [I can invoke methods I’m not otherwise allowed to invoke]
28

29. A8 – Cross-Site Request Forgery / CSRF
» A CSRF attack forces a logged-on victim’s browser to send a forged HTTP
request, including the victim’s session cookie and any other automatically
included authentication information, to a vulnerable web application. This
allows the attacker to force the victim’s browser to generate requests the
vulnerable application thinks are legitimate requests from the victim.
• As a [Malicious User] I want to [find sessions that have not been closed] so
that [I can pretend to be that user]
• As an [Unvalidated Action] I want to [trick the browser to sending an HTTP
request] so that [I can have it execute on behalf of the user, without their
knowing]
• As a [HTTP request With Side Effects] I want to [create a malicious side effect]
so that [I can have the user execute it for me using their credentials]
29

30. A9 – Using Known Vulnerable
Components
» Components, such as libraries, frameworks, and other software
modules, almost always run with full privileges. If a vulnerable
component is exploited, such an attack can facilitate serious data
loss or server takeover. Applications using components with known
vulnerabilities may undermine application defenses and enable a
range of possible attacks and impacts.
• As a [User of the Internet] I want to [try out known weaknesses] so
that [I can discover an unpatched vulnerability]
• As an [Unpatched System] I want to [present known weaknesses] so
that [I can make it easy to be compromised]
• As a [Third Party Library] I want to [run everything in the library with
elevated privileges] so that [I can bypass security controls]
30

31. A10 – Unvalidated Redirects and
Forwards
» Web applications frequently redirect and forward
users to other pages and websites, and use
untrusted data to determine the destination
pages. Without proper validation, attackers can
redirect victims to phishing or malware sites, or
use forwards to access unauthorized pages.
• As a [Malicious Keyboard] I want [modify the url] so
that [cause a user to visit a place of my choosing,
rather than theirs]
31

32. 32