Requirements James Walden Northern Kentucky University

Requirements

James Walden

Northern Kentucky University

CSC 666: Secure Software Engineering

Topics

1. Requirements

2. Misuse cases

3. SQUARE

4. AMS Case Study


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.


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


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


Software Security Practices

1. Code Reviews

2. Risk Analysis

3. Penetration Testing

SecurityOperations

Requirements Design Coding Testing Maintenance

RiskAnalysis

AbuseCases

Code Reviews +Static Analysis

PenetrationTesting

SecurityTesting

4. Security Testing

5. Abuse Cases

6. Security Operations


Misuse Cases

Anti-requirementsThink 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 casesInformed brainstorming: attack patterns, risks.


Use Case Example

UC 1: Login to Web StorePrimary Actor: CustomerStakeholders 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.


Misuse Case Example

MUC 1: Sniff PasswordPrimary Actor: AttackerStakeholders 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.


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.


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.


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.


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.


Step 11 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


Agree on Definitions

Initial set of terms

• Build off of a list of standard terms

• Provide a list of suggested definitions to choose from

□ Other: ___________________________________

_________________________________________

[JONES 02]

□ Restricting access to information via a hierarchy of classes of access.

[ISO 04]□ Ensuring that information is available to only those with authorized access.

[SANS 03a]

□ The property that information is not made available or disclosed to unauthorized individuals, entities, or processes (i.e., to any unauthorized system entity).

confidentiality

Example Term with Suggested Definitions


Step 21 2 3 4 5 6 7 8 9


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


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)


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…


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


Step 31 2 3 4 5 6 7 8 9


Develop Artifacts

• Collect or create artifacts that will facilitate generation of security requirements.

• Jointly verify their accuracy and completeness.


Develop Artifacts

Types of artifacts to collect:• System architecture

diagrams• Misuse cases• Attack trees• Templates


Step 41 2 3 4 5 6 7 8 9


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


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]


Comparison of Techniques

SSM QFD CORE IBIS JAD FODA CDA ARMAdaptability 3 1 3 2 2 3 2 1 2CASE Tool 1 2 1 1 3 2 1 1 1Client Acceptance 2 2 2 2 3 2 1 3 3Complexity 2 2 1 2 3 2 1 1 2Graphical Output 2 2 1 1 2 1 2 2 3

2 2 1 1 2 1 2 2 3

Learning Curve 3 1 2 1 3 2 1 1 1Maturity 2 3 3 3 2 3 2 2 1Scalability 1 3 3 3 2 3 2 1 2

Misuse Cases

Implementation Duration

Comparison of elicitation techniques

3 = very good, 2 = fair, 1 = poor


Step 51 2 3 4 5 6 7 8 9


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


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.


Step 61 2 3 4 5 6 7 8 9


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


Step 71 2 3 4 5 6 7 8 9


Categorize Requirements

• Classify requirements into essential, non-essential, system, software, or architectural constraints.

• Sample table:

System level Software level

Architectural constraint

Reqt. 1

Reqt. 2


Categorization Example

Example method– ARM (Accelerated Requirements Method)

Group D : Authentication

1. Strong authentication

Group C : Data Integrity

1. Partitioned data store( public read only and private read/write)

2. Indelibility

Group B : Access Control

1. Role-based access/views

2. Need for an access control system

Group A : Confidentiality

1. Information must be kept private from outside world

2. Selectively secure communication with outside entities

.

.

.


Step 81 2 3 4 5 6 7 8 9


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.


Prioritization Example

Prioritization example

i, j shows how much higher (or lower) the value/cost for requirement i is than that of requirement j1 - Requirements i and j are of equal cost.

3 - Requirement i has slightly higher cost than j.

5 - Requirement i has strongly higher cost than j.

7 - Requirement i has very strongly higher cost than j.

9 - Requirement 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.

Pairwise Comparison Matrix


Priority Visualization

Cost/Value Diagram of Requirements


Step 91 2 3 4 5 6 7 8 9


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


Step 9: Requirements Inspection

　　　　　　　　　

　　　　　　　　　

　　　　　　　　　

STATUSREVIEWEROWNERSEVERITYDESCRIPTIONDEFECT TYPEORIGINDATESNo

Peer review log format

Assigns each team member inspection responsibility

Ranks problems according to severity


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.


AMS Case Study

Asset Management System Provides data to make decisions about

emergency situations.


AMS Use Case Example


AMS Goals and Requirements


R01: Security Controls


Risk Assessment


References

1. CLASP, OWASP CLASP Project, http://www.owasp.org/index.php/Category:OWASP_CLASP_Project, 2008.

2. Noopur Davis et. al., Processes for Producing Secure Software. IEEE Security & Privacy, May 2004.

3. 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.

4. Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, 2006.

5. Gary McGraw, Software Security, Addison-Wesley, 2006.6. 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.

Documents

Requirements James Walden Northern Kentucky University