1. CSCE 522 Building Secure Software

2. CSCE 548 - Farkas2 Reading This lecture – McGraw: Ch. 3 – G. McGraw, Software Security, http://www.cigital.com/papers/download/bsi1-swsec.pdf http://www.cigital.com/papers/download/bsi1-swsec.pdf – Ted Demopoulos, Worst Practices in Developing Secure Software, http://www.demop.com/articles/developing-secure-software.html http://www.demop.com/articles/developing-secure-software.html Next Lecture – McGraw: Ch. 4 (overview, we’ll cover code review in details later)

3. CSCE 548 - Farkas3 Three Pillars of Software Security Risk Management Software Security Touchpoints Knowledge

4. CSCE 548 - Farkas4 Risk Management How much effort to invest in security Consequences of security breaches Acceptable-level of security Tracking and mitigating risk throughout the full SDLC

5. CSCE 548 - Farkas5 Touchpoints System-wide activity: from design to testing and feedback Focus on security from ground up Touchpoints: 1. Code review 2. Architectural risk analysis 3. Penetration testing 4. Risk-based security testing 5. Abuse cases 6. Security requirements 7. Security operations 8. External Analysis Prioritize activities!

6. CSCE 548 - Farkas6 Knowledge Gathering, encapsulating, and sharing security knowledge Knowledge catalogs: principles, guidelines, rules, vulnerabilities, exploits, attack patterns, historical risks Knowledge categories: – Prescriptive knowledge – Diagnostic knowledge – Historical knowledge Applied along the SDLC Can you give examples?

7. CSCE 548 - Farkas7 Security Engineering Reduce the need for reactive technologies (e.g., intrusion detection) by safer products  Understand software Need for: – Software developers – Operations people – Administrators – Users – Executives Why do these people need Security Engineering?

8. CSCE 548 - Farkas8 Software Security Touchpoints Best Practices Both White Hat (constructive) and Black Hat (destructive) activities Throughout the SDLC How do you think about security? Which is more important? White hat or Black hat type of activities?

9. CSCE 548 - Farkas9 Application of Touchpoints Requirement and Use cases Architecture and Design Test Plans Code Tests and Test Results Feedback from the Field Abuse cases 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

10. CSCE 548 - Farkas10 Code Review (Tool) Artifact: Code Implementation bugs Static Analysis tools White Hat 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

11. CSCE 548 - Farkas11 Architectural Risk Analysis Artifact: Design and specification System must be coherent and present a uniform security front Document assumptions and identify possible attacks Both at specification-based architecture stage and class- hierarchy design stage White hat 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

12. CSCE 548 - Farkas12 Penetration Testing Artifact: system in its environment Understanding fielded software in its environment Information supplied by architectural risk analysis Who does it? Black Hat 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

13. CSCE 548 - Farkas13 Risk-Based Security Testing Artifact: unit and system Strategies: – Testing of security functionality (standard functional testing) – Risk-based security testing (attack pattern, risk analysis, abuse cases) Attacker’s mindset White Hat + Black Hat 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

14. CSCE 548 - Farkas14 Abuse Cases Artifact: requirements and use cases Describe system behavior under attack Explicit coverage of – What should be protected – From whom – For how long White Hat + Black Hat 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

15. CSCE 548 - Farkas15 Security Requirements Artifact: Requirements Security explicitly worked into the requirements level Both functional security and emergent characteristics White Hat 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

16. CSCE 548 - Farkas16 Security Operations Artifact: fielded system Monitoring system usage Combines both network centric and software specific operations White Hat 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

17. CSCE 548 - Farkas17 External Analysis Evaluate security by outside members Why? Advantages/disadvantages 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. CSCE 548 - Farkas19 Best Practices Earlier the better Change “operational” view to secure software Best practices: expounded by experts and adopted by practitioners

20. Worst Practices to Avoid From T. Demopoulos, “Worst Practices in Developing Secure Software 1. Assuming only “important’ SW needs to be secure 2. Emphasizing hitting deadlines over “good code” 3. Having IT make all risk management decisions 4. Not considering security during the entire SDLC 5. Assuming the SW won’t be attacked 6. Not doing any security testing 7. Not planning for failure 8. Counting on “security through obscurity” 9. Disallowing bad input instead of only allowing good input 10. SW that is not secure by default 11. Coding your own cryptography CSCE 548 - Farkas20

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 Next Class Code Review