Requirements James Walden Northern Kentucky University Topics 1

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 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: 1 a. Attacker not on path between user and system: 1. Attacker uses ARP poisoning or similar attack to redirect user packets through his system. 1 b. Customer uses wireless connection. 1. Attacker drives to customer location. 2. Attacker uses wireless sniffer to intercept passwords. 4 a. 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 Bad. Store’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 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, Do. S, 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 03 a] □ 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 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 – 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 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 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 3 = very good, 2 = fair, 1 = poor CSC 666: Secure Software Engineering

Step 5 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 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 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 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 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 1 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. CSC 666: Secure Software Engineering

Priority Visualization Cost/Value Diagram of Requirements CSC 666: Secure Software Engineering

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

R 01: 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 Mc. Graw, 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/05 tr 009. pdf, 2005. CSC 666: Secure Software Engineering