CSCE 548 Secure Software Development Test 1 Review

Final Project Format Title Author Abstract What you did in this paper 1. Introduction 2. Related work 3. Background information 4. Current research/development 5. Conclusions and Future Work 6. Group members’ contributions References CSCE Farkas2

Final Project Format 1. Introduction – Problem description, its importance – Representative example – Brief description of related works – What is missing? – Your work addressing the research/development gap – Organization of the report CSCE Farkas3

Final Project Format 4. Current Work 4.1 Definition of concepts (if applicable) 4.2 Problem definition 4.3 Solution 4.4 Proof-sketch of solution (if applicable) correctness/efficiency/contribution to the area CSCE Farkas4

5 Reading McGraw: Software Security: Chapters 1 – 9, 12

Non-Textbook Reading 1. Lodderstedt et. al, SecureUML: A UML-Based Modeling Language for Model-Driven Security, softech/papers/2002/0_secuml_uml2002.pdfhttp://kisogawa.inf.ethz.ch/WebBIB/publications- softech/papers/2002/0_secuml_uml2002.pdf 2. B. Littlewood, P. Popov, L. Strigini, "Modelling software design diversity - a review", ACM Computing Surveys, Vol. 33, No. 2, June 2001, pp , I. Alexander, Misuse Cases: Use Cases with Hostile Intent, IEEE Software, vol. 20, no. 1, pp , Jan./Feb B. Schneier on Security, P. Meunier, Classes of Vulnerabilities and Attacks, Wiley Handbook of Science and Technology for Homeland Security, CSCE Farkas6

7 Software Security NOT security software! Engineering software so that it continues to function correctly under malicious attack – Functional requirements – Non-functional requirements (e.g., security)

CSCE Farkas8 Why Software? Increased complexity of software product Increased connectivity Increased extensibility Increased risk of security violations!

CSCE Farkas9 Security Problems Defects: implementation and design vulnerabilities Bug: implementation-level vulnerabilities (Low- level or mid-level) – Static analysis tool Flaw: subtle, not so easy to detect problems – Manual analysis – Automated tools (for some but not design level) Risk: probability x impact

CSCE Farkas10 Application vs. Software Security Usually refers to security after the software is built – Adding more code does not make a faulty software correct – Sandboxing – Network-centric approach Application security testing: badness-ometer Deep Trouble Who Knows

CSCE Farkas11 Three Pillars of Software Security Risk Management Software Security Touchpoints Knowledge

CSCE Farkas12 Risk Management

CSCE Farkas13 Risk Assessment RISK Threats VulnerabilitiesConsequences

CSCE Farkas14 Risk Management Framework (Business Context) Understand Business Context Identify Business and Technical Risks Synthesize and Rank Risks Define Risk Mitigation Strategy Carry Out Fixes and Validate Measurement and Reporting

CSCE Farkas15 Risk Acceptance Certification How well the system meet the security requirements (technical) Accreditation Management’s approval of automated system (administrative)

CSCE Farkas16 Software Security Touchpoints

CSCE Farkas17 Application of Touchpoints Requirement and Use cases Architecture and Design Test Plans Code Tests and Test Results Feedback from the Field 5. Abuse cases 6. Security Requirements 2. Risk Analysis External Review 4. Risk-Based Security Tests 1. Code Review (Tools) 2. Risk Analysis 3. Penetration Testing 7. Security Operations

CSCE Farkas18 When to Apply Security? Economical consideration: early is better Effectiveness of touchpoints: – Economics – Which software artifacts are available – Which tools are available – Cultural changes Bad: reactive strategy  need: secure development

Additional Materials Security requirement analysis  SecureUML by Lodderstedt et. Al Abuse cases  Misuse Cases: Use Cases with Hostile Intent by Alexander Software Reliability  Modeling software design diversity by Littlewood et. al CSCE Farkas19

CSCE Farkas20 Best Practices Earlier the better Change “operational” view to secure software Best practices: expounded by experts and adopted by practitioners

CSCE Farkas21 Who Should Care? Developers Architects Other builders Operations people Do not start with security people. Start with software people.

CSCE Farkas22 SANS: Secure Programming Skills Assessment Aims to improve secure programming skills and knowledge Allow employers to rate their programmers Allow buyers of software and systems vendors to measure skills of developers Allow programmers to identify their gaps in secure programming knowledge Allow employers to evaluate job candidates and potential consultants Provide incentive for universities to include secure coding in their curricula

CSCE Farkas23 Goal of Taxonomy List of common coding mistakes Support for software developers to avoid making mistakes Useful in automated tools – Real time – Compile time Teaching aid NOT an attack taxonomy

CSCE Farkas24 7 Plus 1 Kingdoms 1. Input validation and representation 2. API abuse 3. Security features 4. Time and state 5. Error handling 6. Code quality 7. Encapsulation 8. Environment

NEXT CLASS NEXT CLASS OVERVIEW OF THE 19 DEADLY SINS, VULNERABILITY TAXONOMY, SANS TOP 25 VULNERABILITIES CSCE Farkas25