1. CSCE 548 Secure Software Development Test 1 Review

2. 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 548 - Farkas2

3. 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 548 - Farkas3

4. 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 548 - Farkas4

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

6. Non-Textbook Reading 1. Lodderstedt et. al, SecureUML: A UML-Based Modeling Language for Model-Driven Security, http://kisogawa.inf.ethz.ch/WebBIB/publications- 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. 177-208, http://portal.acm.org/citation.cfm?doid=384192.384195 http://portal.acm.org/citation.cfm?doid=384192.384195 3. I. Alexander, Misuse Cases: Use Cases with Hostile Intent, IEEE Software, vol. 20, no. 1, pp. 58-66, Jan./Feb. 2003. http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2003.1159030 http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2003.1159030 4. B. Schneier on Security, http://schneier.com/blog/archives/2007/05/is_penetration.html http://schneier.com/blog/archives/2007/05/is_penetration.html 5. P. Meunier, Classes of Vulnerabilities and Attacks, Wiley Handbook of Science and Technology for Homeland Security, http://homes.cerias.purdue.edu/~pmeunier/aboutme/classes_vulnerabilities.pdf http://homes.cerias.purdue.edu/~pmeunier/aboutme/classes_vulnerabilities.pdf CSCE 548 - Farkas6

7. 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)

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

9. CSCE 548 - 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

10. CSCE 548 - 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

11. CSCE 548 - Farkas11 Three Pillars of Software Security Risk Management Software Security Touchpoints Knowledge

12. CSCE 548 - Farkas12 Risk Management

13. CSCE 548 - Farkas13 Risk Assessment RISK Threats VulnerabilitiesConsequences

14. CSCE 548 - 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

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

16. CSCE 548 - Farkas16 Software Security Touchpoints

17. CSCE 548 - 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

18. CSCE 548 - 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

19. 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 548 - Farkas19

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

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

22. CSCE 548 - 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

23. CSCE 548 - 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

24. CSCE 548 - 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

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