requirements james walden northern kentucky university
Post on 12-Jan-2016
219 Views
Preview:
TRANSCRIPT
Requirements
James Walden
Northern Kentucky University
CSC 666: Secure Software Engineering
Topics
1. Requirements
2. Misuse cases
3. SQUARE
4. 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
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
CSC 666: Secure Software Engineering
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.
CSC 666: Secure Software Engineering
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.
CSC 666: Secure Software Engineering
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.
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 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
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
□ 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
CSC 666: Secure Software Engineering
Step 21 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 31 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 41 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
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
CSC 666: Secure Software Engineering
Step 51 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 61 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 71 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
Architectural constraint
Reqt. 1
Reqt. 2
CSC 666: Secure Software Engineering
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
.
.
.
CSC 666: Secure Software Engineering
Step 81 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
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
CSC 666: Secure Software Engineering
Priority Visualization
Cost/Value Diagram of Requirements
CSC 666: Secure Software Engineering
Step 91 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
STATUSREVIEWEROWNERSEVERITYDESCRIPTIONDEFECT TYPEORIGINDATESNo
Peer review log format
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. 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.
top related