Requirements
James Walden
Northern Kentucky University
Topics
1.
2.
3.
4.
Requirements
Misuse cases
SQUARE
AMS Case Study
CSC 666: Secure Software Engineering
Requirements
Functional: describe what software must be
capable of doing.
Non-functional: describe qualities of software,
such as availability, reliability, &c.
 Security is a non-functional requirement.
 Some security requirements can be re-cast as
functional requirements.
 The app must not accept overly long input data.
 The app must validate all input to ensure it does not
exceed the specified size for that type of input.
CSC 666: Secure Software Engineering
Sources of Security Requirements
 Customers’ expressed security concerns.
 Security implications of functional
requirements.
 Protect against SQL injection if app uses DB.
 Protect against XSS if there is web output.
 Regulatory compliance
 Federal Information Security Management Act
 Sarbanes-Oxley
 Health Insurance Portability & Accountability Act
CSC 666: Secure Software Engineering
Methodologies
REVEAL: Requirements Engineering
VErification and VAlidation from Praxis
SQUARE: Security QUAlity Requirements
Engineering from CMU/SEI
TRIAD: Trustworth Refinement through
Intrusion-Aware Design from CMU/SEI
AEGIS: Appropriate and Effective Guidance
in Information Security
Abuse Cases, a/k/a Misuse Cases
CSC 666: Secure Software Engineering
Software Security Practices
4. Security Testing
5. Abuse Cases
6. Security
Operations
1. Code Reviews
2. Risk Analysis
3. Penetration
Testing
Abuse
Cases
Requirements
Risk
Analysis
Design
Code Reviews +
Static Analysis
Coding
Security
Testing
Testing
CSC 666: Secure Software Engineering
Penetration
Testing
Security
Operations
Maintenance
Misuse Cases
Anti-requirements
Think about what software should not do.
A use case from an adversary’s point of view.
• Obtain Another User’s CC Data.
• Alter Item Price.
• Deny Service to Application.
Developing misuse cases
Informed brainstorming: attack patterns, risks.
CSC 666: Secure Software Engineering
Use Case Example
UC 1: Login to Web Store
Primary Actor: Customer
Stakeholders and Interests:
 Customer: Wants to purchase products.
Preconditions: Customer has web access.
Postconditions: Customer has access to their
account, with the ability to pay for and ship
products.
Summary: Customer gains access to system
using an assigned username and password.
CSC 666: Secure Software Engineering
Misuse Case Example
MUC 1: Sniff Password
Primary Actor: Attacker
Stakeholders and Interests:
 Attacker: Wants to obtain user credentials.
Preconditions: Attacker has access to a machine
on network path between user and system.
Postconditions: Attacker has obtained one or
more valid usernames and passwords.
Summary: Attacker obtains and later misuses
passwords to gain unauthorized access to
system.
CSC 666: Secure Software Engineering
Misuse Case Example
Basic Flow:
1. Attacker installs network sniffer.
2. Sniffer saves all packets which contain
strings matching “Logon,” “Username,” or
“Password.”
3. Attacker reads sniffer logs.
4. Attacker finds valid username/password in
log.
5. Attacker uses sniffed password to access
system.
CSC 666: Secure Software Engineering
Misuse Case Example
Alternate Flows:
1a. Attacker not on path between user and
system:
1. Attacker uses ARP poisoning or similar attack to
redirect user packets through his system.
1b. Customer uses wireless connection.
1. Attacker drives to customer location.
2. Attacker uses wireless sniffer to intercept
passwords.
4a. Attacker finds no passwords in log
1. Continue sniffing until a password is found.
CSC 666: Secure Software Engineering
SQUARE
 System Quality Requirements Engineering
 Security-focused requirements methodology.
 Developed at CMU/SEI by Nancy Mead.
 Could we reverse engineer BadStore’s
requirements using SQUARE?
Special permission to use SQUARE course materials
(copyright 2007 Carnegie Mellon University) for James
Walden’s Secure Software Engineering class is granted by the
Software Engineering Institute at Carnegie Mellon University.
Neither Carnegie Mellon nor its Software Engineering Institute
directly or indirectly endorse James Walden's work.
CSC 666: Secure Software Engineering
SQUARE Steps
1. Agree on definitions.
2. Identify security goals.
3. Develop artifacts to support security
requirements definition.
4. Assess risks.
5. Select elicitation technique(s).
6. Elicit security requirements.
7. Categorize requirements.
8. Prioritize requirements.
9. Inspect requirements.
CSC 666: Secure Software Engineering
Step 1
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Agree on Definitions
• Requirements engineers and stakeholders
agree on a set of definitions.
• Process is carried out through interviews.
• Exit criteria: documented set of definitions
• Examples: non-repudiation, DoS, intrusion, malware
CSC 666: Secure Software Engineering
Agree on Definitions
Initial set of terms
• Build off of a list of standard terms
• Provide a list of suggested definitions to choose from
Example Term with Suggested Definitions
confidentiality
□ The property that information is not made available or
disclosed to unauthorized individuals, entities, or
processes (i.e., to any unauthorized system entity).
[SANS
03a]
□ Ensuring that information is available to only those
with authorized access.
[ISO 04]
□ Restricting access to information via a hierarchy of
classes of access.
[JONES
02]
□ Other: ___________________________________
_________________________________________
CSC 666: Secure Software Engineering
Step 2
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Identify Security Goals
• Goals are required to identify the priority and
relevance of security requirements.
• Security goals must support the business goal.
• Goals are reviewed, prioritized, and documented.
• Exit criteria: one business goal, several security goals
CSC 666: Secure Software Engineering
Step 2: Identify Security Goals
A single business goal and several security goals:
• “The system allows the client to make informed
decisions based on which assets are available.”
(Business Goal)
• “The confidentiality, accuracy, and integrity of the
system’s data shall be maintained.” (Security Goal)
CSC 666: Secure Software Engineering
Goals vs. Requirements
Establish security goals, not security
requirements or security recommendations
 Goals – state what must be
- “Management shall exercise effective control over the
system’s configuration and usage.”
- “The confidentiality, accuracy, and integrity of the
Asset Management System shall be maintained.”
- “The system shall be available for use when needed.”
cont’d…
CSC 666: Secure Software Engineering
Goals vs. Requirements
Requirements – state what must be done
- “The system is required to have strong authentication
measures in place at all system gateways/entrance
points.”
(maps to Goals 1 and 2)
- “A continuity of operations plan (COOP) must be in
place to assure system availability.”
(maps to Goal 3)
Recommendations – state a general good idea
- “Invest in backup information technology hardware to
ensure business continuity.”
CSC 666: Secure Software Engineering
Step 3
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Develop Artifacts
• Collect or create artifacts that will facilitate generation
of security requirements.
• Jointly verify their accuracy and completeness.
CSC 666: Secure Software Engineering
Develop Artifacts
Types of artifacts to collect:
• System architecture
diagrams
• Misuse cases
• Attack trees
• Templates
CSC 666: Secure Software Engineering
Step 4
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Perform Risk Assessment
• Identify threats to system and its vulnerabilities.
• Calculate likelihood of their occurrence. Classify them.
This will also help in prioritizing requirements later.
• Risk expert might be required.
• Exit criteria: documentation of all threats, their
likelihood and classifications
CSC 666: Secure Software Engineering
Risk Assessment Methods
• General Accounting Office model [GAO 99]
• National Institute of Standards and Technology model
•
•
•
•
•
•
(recommended) [Stoneburner 02]
NSA’s INFOSEC Assessment Technology [NSA 04]
Shawn Butler’s Security Attribute Evaluation Method
[Butler 02]
CMU’s “V-RATE” method [Lipson 01]
Yacov Haimes’s RFRM model (recommended) [Haimes
04]
CMU’s Survivable Systems Analysis method [Mead 02]
Martin Feather’s DDP model [Cornford 04]
CSC 666: Secure Software Engineering
Comparison of Techniques
Comparison of elicitation techniques
Adaptability
CASE Tool
Client Acceptance
Complexity
Graphical Output
Implementation
Duration
Learning Curve
Maturity
Scalability
Misuse
Cases SSM
3
1
1
2
2
2
2
2
2
2
QFD
3
1
2
1
1
CORE
2
1
2
2
1
IBIS
2
3
3
3
2
JAD
3
2
2
2
1
FODA
2
1
1
1
2
CDA
1
1
3
1
2
ARM
2
1
3
2
3
2
2
1
1
2
1
2
2
3
3
2
1
1
3
3
2
3
3
1
3
3
3
2
2
2
3
3
1
2
2
1
2
1
1
1
2
3 = very good, 2 = fair, 1 = poor
CSC 666: Secure Software Engineering
Step 5
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Select Elicitation Technique
• Select appropriate technique for the number and
expertise of stakeholders, requirements engineers,
and size and scope of the project.
• Techniques: structured/unstructured interviews,
accelerated requirements method (ARM), soft
systems methodology, issue based information
systems (IBIS), Quality Function Deployment
CSC 666: Secure Software Engineering
Elicitation Techniques
•
•
•
•
•
•
•
•
•
•
Misuse Cases [Jacobson 92]
Soft Systems Methodology (SSM) [Checkland 90]
Quality Function Deployment (QFD) [QFD 05]
Controlled Requirements Expression (CORE) [SDS 86]
Issue Based Information Systems (IBIS) [Kunz 70]
Joint Application Development (JAD) [Wood 89]
Feature-Oriented Domain Analysis (FODA) [Kang 90]
Critical Discourse Analysis (CDA) [Schiffrin 94]
Accelerated Requirements Method (ARM) [Hubbard 00]
Structured/unstructured Interviews.
CSC 666: Secure Software Engineering
Step 6
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Elicit Security Requirements
(Heart of SQUARE)
• Execute the elicitation technique.
• Avoid non-verifiable, vague, ambiguous requirements.
• Concentrate on what, not how.
Avoid implementations and architectural constraints.
• Exit criteria: initial document with requirements
CSC 666: Secure Software Engineering
Step 7
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Categorize Requirements
• Classify requirements into essential, non-essential,
system, software, or architectural constraints.
• Sample table:
System level
Software level
Reqt. 1
Reqt. 2
CSC 666: Secure Software Engineering
Architectural
constraint
Categorization Example
Example method
– ARM (Accelerated Requirements Method)
Group A : Confidentiality
1. Information must be kept private
from outside world
2. Selectively secure communication
with outside entities
Group B : Access Control
1. Role-based access/views
2. Need for an access control system
Group C : Data Integrity
1. Partitioned data store( public read
only and private read/write)
2. Indelibility
Group D : Authentication
1. Strong authentication
.
.
.
CSC 666: Secure Software Engineering
Step 8
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Prioritize Requirements
• Use risk assessment and categorization results to
prioritize requirements.
• Prioritization techniques: Triage, Win-Win,
Analytical Hierarchy Process
• Requirements engineering team should produce a
cost-benefit analysis to aid stakeholders.
CSC 666: Secure Software Engineering
Prioritization Example
Prioritization example
Pairwise Comparison Matrix
i, j shows how much higher (or lower) the value/cost for requirement i
is than that of requirement j
1Requirements i and j are of equal cost.
3Requirement i has slightly higher cost than j.
5Requirement i has strongly higher cost than j.
7Requirement i has very strongly higher cost than j.
9Requirement i has absolutely higher cost than j.
2, 4, 6, 8 - These are intermediate scales between two adjacent judgments.
Reciprocals - If requirement i has lower cost than j.
CSC 666: Secure Software Engineering
Priority Visualization
Cost/Value Diagram of Requirements
CSC 666: Secure Software Engineering
Step 9
1
2
3
4
5
6
7
8
9
Def.
Goals
Artifacts
Risk
Technique
Elicit
Categorize
Prioritize
Inspect
Requirements Inspection
• Inspection aids in creating accurate and verifiable
security requirements.
• Look for ambiguities, inconsistencies, mistaken
assumptions.
• Fagan inspections / peer reviews
• Exit criteria: all requirements verified and documented
CSC 666: Secure Software Engineering
Step 9: Requirements Inspection
Peer review log format
SNo
DATE
ORIGIN
DEFECT TYPE
DESCRIPTION
SEVERITY
OWNER
REVIEWER
STATUS
Assigns each team member inspection responsibility
Ranks problems according to severity
CSC 666: Secure Software Engineering
Approach
Time to complete depends on project size.
Implemented in three distinct case studies.
SQUARE-Lite (simpler, experimental)
– Agree on definitions.
– Identify security goals.
– Elicit security requirements.
– Prioritize requirements.
CSC 666: Secure Software Engineering
AMS Case Study
Asset Management System
 Provides data to make decisions about
emergency situations.
CSC 666: Secure Software Engineering
AMS Use Case Example
CSC 666: Secure Software Engineering
AMS Goals and Requirements
CSC 666: Secure Software Engineering
R01: Security Controls
CSC 666: Secure Software Engineering
Risk Assessment
CSC 666: Secure Software Engineering
References
1.
2.
3.
4.
5.
6.
CLASP, OWASP CLASP Project,
http://www.owasp.org/index.php/Category:OWASP_CLASP_Project,
2008.
Noopur Davis et. al., Processes for Producing Secure Software.
IEEE Security & Privacy, May 2004.
Karen Goertzel, Theodore Winograd, et al. for Department of
Homeland Security and Department of Defense Data and Analysis
Center for Software. Enhancing the Development Life Cycle to
Produce Secure Software: A Reference Guidebook on Software
Assurance, October 2008.
Michael Howard and Steve Lipner, The Security Development
Lifecycle, Microsoft Press, 2006.
Gary McGraw, Software Security, Addison-Wesley, 2006.
Nancy R. Mead, Eric D. Hough, Theodore R. Stehney II, Security
Quality Requirements Engineering (SQUARE) Methodology,
CMU/SEI-2005-TR-009,
http://www.sei.cmu.edu/pub/documents/05.reports/pdf/05tr009.pdf,
2005.
CSC 666: Secure Software Engineering