Effective Software Requirements: Understanding Functional and Non-functional Aspects

Software Security Requirements CSCE 413/713 - Software Security Spring 2020 Philip Ritchey Department of Computer Science and Engineering CSCE 413/713 - Software Security 1

CSCE 413/713 - Software Security 2

If you remember nothing else Requirements specify WHAT, Functional: what the system does Expressed as use cases or shall given duets Non-functional: what the system is is Expressed as <metric> <number/range> <units> specifications Requirements should be (at a minimum): Testable Testable Unambiguous Unambiguous Complete Complete Correct Correct Consistent Consistent Security Requirements specify what the system must do and be with regard to security goals Identified by abuse cases Security Requirements should be Everything requirements are and Measurable Measurable (security is not Boolean) WHAT, not how. does CSCE 413/713 - Software Security 3

Requirements in Software Engineering 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology 1. A condition or capability needed by a user to solve a problem or achieve an objective. 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. 3. A documented representation of a condition or capability as in (1) or (2). Sommerville & Sawyer A specification of what should be implemented. Descriptions of how the system should behave, or of a system property or attribute. May be a constraint on the development process of a system. CSCE 413/713 - Software Security 4

Functional & Non-functional Requirements Functional: describe behaviors under specific conditions Often expressed as shall given duets The program shall append timestamped data to a log file given the data, log file, and a valid authentication token. Non-functional: describe other characteristics Constraints (design, implementation) External interface requirements (hw, sw, user, communication) Performance (response time, throughput, latency, degraded modes) Quality attributes (usability, robustness, integrity, availability, maintainability, etc.) Often expressed as <metric> <number/range> <units> specifications The program has a response time of less than 5 seconds for any query. CSCE 413/713 - Software Security 5

How to write good software requirements http://lmgtfy.com/?q=how+to+write+good+software+requirements skill, practice, and patience Express requirements as User Stories and/or Use Cases User story: centered on the result and the benefit of the feature Use case: describe how the system behaves Invent a standard format and use it for all requirements Requirements should be Correct, Unambiguous, Complete, Verifiable, Consistent, Traceable, Maintainable CSCE 413/713 - Software Security 6

User Stories 1-3 sentences in natural language Written by/with customer Format Feature name As a [stakeholder] So that [I can achieve some goal] I want to [do some task] Idea: user story can be formulated as an acceptance test before code written. test before code is CSCE 413/713 - Software Security 7

SMART Stories S Specific unambiguous, given/when/then M Measurable verifiable (testable) A Achievable small enough to be completed in 1 iteration R Relevant business value, 5 Whys T Timeboxed finish by T or abandon story (story may be too big) CSCE 413/713 - Software Security 8

Use Cases Written descriptions of how users will perform tasks using the system Outlines / explains system behavior from user perspective also help to identify what could go wrong Represented as a sequence of simple steps begins with user's goal ends when that goal is fulfilled What use cases include Who is using the system What the user wants to do (goal) The steps the user takes How the system should respond What uses cases do NOT include Implementation-specific language Details about user interfaces CSCE 413/713 - Software Security 9

Elements of a Use Case Title Title goal the use case is trying to satisfy Stakeholders Stakeholders those with interests in the behavior of the system Primary Actor Primary Actor stakeholder who initiates an interaction with the system to achieve the goal Preconditions Preconditions what must be true or happen before the use case runs. Trigger Trigger the event that causes the use case to be initiated. Postconditions Postconditions what must be true or happen after the use case runs. Main Success Scenario Main Success Scenario use case in which nothing goes wrong. Exceptions Exceptions use cases in which some things go wrong. CSCE 413/713 - Software Security 10

Security Requirements Security requirements specify what the system must do and be with regard to security goals Security Goals (policy) Confidentiality Integrity Availability Mechanism enforce policy Authentication Authorization Audit A security requirement is not a magic wand that you can wave at an application and say Thou shalt not be compromised by hackers . Every security requirement should address a specific security need. Specific security requirements will arise from the specific application requirements. https://www.synopsys.com/blogs/software-security/software-security-requirement/ CSCE 413/713 - Software Security 11

Gold Standard Authentication connects actor with identity Identity: who is it? How does the system know it is who it says it is? Factors: What it knows, what it has, what it is Multi-factor: 2 or more Authorization connects identity with action What is the principal allowed to do? To whom? When? Etc. E.g. access control: mandatory, discretionary, role-based Audit - record information about system/user activities Determine the circumstances of misuse or breach, or establish that one did not occur Log files must be protected CSCE 413/713 - Software Security 12

User Stories and Use Cases Requirements Agile / XP would claim that a user story / use case IS a requirement IEEE Standard 830 would say they are not [ good ] requirements IEEE recommends The system shall Use Cases and User Stories are behavioral requirements Scenarios that use the functional requirements Functional requirements are supported by non-functional requirements Express functional (what) as The system shall <do requirement> Express non-functional (quality) as The system shall <be requirement> CSCE 413/713 - Software Security 13

Abuse Cases Security Requirements Abuse Case: same as a use case, except Primary Actor is attacker Main Success Scenario is violation of security 5 steps for using abuse cases to identify security requirements 1. Identify critical assets in the system 2. Define security goals for each asset 3. Identify threats to each of these security goals, e.g. by identifying the attackers that may want to cause harm to the system 4. Identify and analyze risks for the threats 5. Define security requirements for the risks. CSCE 413/713 - Software Security 14

Threats: STRIDE Ask: What could go wrong? Remember this mnemonic for categories of threats: S S is for S Spoofing - Integrity T T is for T Tampering - Integrity R R is for R Repudiation - Integrity I I is for I Information disclosure - Confidentiality D D is for D Denial of service - Availability E E is for E Elevation of privilege Confidentiality, Integrity, Availability Attack patterns: Like GoF design patterns, but for attacks e.g. Make the Client Invisible Talk directly with the server, masquerading as the client. Explore the input space. CSCE 413/713 - Software Security 15

Specifying [Security] Requirements Basic Syntax Goals Use one subject, one verb and one object per statement. If multiple objects are necessary, enumerate. Employ active verbs. Limit the use of clauses. Avoid orphan phrases. Check the grammar. Basic Semantic Goals Define the terms. Avoid overloaded words. Select accurate adjectives. Check for internal consistency. Include references to details where needed. Avoid duplication among requirements. CSCE 413/713 - Software Security 16

Thanks and Gig em! WHOOP! CSCE 413/713 - Software Security 17