CSCE 548 Secure Software Development Test 1 Review

1. CSCE 548 Secure Software DevelopmentTest 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

3. Final Project Format • 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

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

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

6. Non-Textbook Reading • 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.pdf • 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 • 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 • B. Schneier on Security, http://schneier.com/blog/archives/2007/05/is_penetration.html • 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

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. Why Software? • Increased complexity of software product • Increased connectivity • Increased extensibility Increased risk of security violations!

9. 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. 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 Who Knows Deep Trouble

11. Three Pillars of Software Security • Risk Management • Software Security Touchpoints • Knowledge

12. Risk Management

13. Threats RISK Vulnerabilities Consequences Risk Assessment

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

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

16. Software Security Touchpoints

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

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

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

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

22. 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. 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. 7 Plus 1 Kingdoms Input validation and representation API abuse Security features Time and state Error handling Code quality Encapsulation Environment

25. Next ClassOverview of the 19 deadly sins, vulnerability taxonomy, SANS top 25 vulnerabilities