1 Software Safety Specifying safety requirements Safety vs. - PDF document

User requirements CSE 403 Business Requirements Lecture 14 User User Use Cases Requirements Study Safety and Security Requirements Functional Requirements Requirements Documentation Non-functional Requirements Non-functionality Non-functional requirements requirements � Requirements beyond user interaction � Wiegers with the system � Performance requirements � Kulak and Guiney � Safety requirements � Security requirements � Availability, cost of ownership, maintainability, data integrity, extensibility, � Software quality attributes installability, reuse, operability, performance, portability, quality, robustness, scalability Software Safety Safety critical systems � Safety critical applications � Very high cost of failure � Software component of a large system � Where bugs can kill � e.g. nuclear reactor � Famous cases � Characteristics of software lead to � Therac-25 radiation therapy machine failures � US Air traffic control which failed in UK � Safety requirements � Reflected map on Greenwich Median � Low probability of failure (risk analysis) � US Aviation software failed in Israel � Understood failure modes � Encountered negative altitudes over Dead Sea 1

Software Safety Specifying safety requirements � Safety vs. Reliability � Component reliability � Fail to safe state Safety Reliability � Formal guarantees or validation � System hazard analysis � Positive measures � High risk tasks � Decouple safety critical components � Safety critical operator errors � Safety kernel � Design of Human-Machine Interface � Redundancy UI for Safety Security requirements � System failures generally complex with � Applications are run in a hostile world humans involved � Application compromise vs. system compromise � Hard to clarify degree of user error � Example requirements � Very complicated design space � Only authenticated users can change data � Design for very boring environment � Application can change security permissions or � Design for crisis operation execute programs � Malicious user cannot crash system with bad data � Take into account human cognitive � Threat analysis abilities Approaches to security Threat modeling requirements � The STRIDE Threat Model � Security audit / validation � Spoofing identity � Implementation limitations � Tampering with data � No use of ‘gets’ � Repudiation � No use of unsafe calls on user input � Allow users to deny having performed actions � Restricted operation modes � Information disclosure � Safe defaults � Denial of service � Elevation of privilege 2

Security requirements for Threat analysis for Classroom multiplayer games Presenter � Cheating ruins game play (and consequently market) � Threats � Players introducing counterfeit weapons � Sending packet of death across network � Using profiling tools to detect areas of activity in dungeons Classroom Presenter Useful references � Writing Secure Code, Michael Howard and David LeBlanc (2 nd Edition) � Good book, but strongly oriented towards Windows � Safeware: System Safety and Computers, Nancy Leveson � Defines the field of software safety 3