CSCE 548 Building Secure Software

1. CSCE 548 Building Secure Software

2. Reading • This lecture: • McGraw: Chapter 1 • Recommended: • CyberInsecurity: The Cost of Monopoly, http://cryptome.org/cyberinsecurity.htm • Next lecture: • McGraw: Chapter 2

3. Why do we need software security? • Software is essential in most every aspect of our life • Current news (recommended): • Kelly Jackson Higgins, Dark Reading, SQL Injection Hack Infects 1 Million Web Pages, InformationWeek, January 5, 2012, http://www.informationweek.com/news/security/attacks/232301355 • Gregg Keizer, Adobe plugs 6 critical holes in Reader, Computerworld, January 11, 2012, http://www.computerworld.com/s/article/9223344/Adobe_plugs_6_critical_holes_in_Reader • Gregg Keizer, Microsoft patches critical Windows drive-by bug, Computerworld, January 10, 2012, http://www.computerworld.com/s/article/9223326/Microsoft_patches_critical_Windows_drive_by_bug

4. How to address software security? • Do not address at all • Ad-hoc evaluation • Add security features after the fact • Identify security vulnerabilities • Test security level • Incorporate security throughout of SDLC

5. This Course • Not a software engineering course • Understand basic security concepts and their impact • Introduce systematic security design and development along project management • Best practices

6. Security Objectives • Confidentiality: prevent/detect/deter improper disclosure of information • Integrity: prevent/detect/deter improper modification of information • Availability: prevent/detect/deter improper denial of access to services Which objective SW security addresses?

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 • How much effort to invest in security • Consequences of security breaches • Acceptable-level of security • Tracking and mitigating risk throughout the full SDLC

13. Touchpoints • System-wide activity: from design to testing and feedback • Focus on security from ground up • Touchpoints: • Code review • Architectural risk analysis • Penetration testing • Risk-based security testing • Abuse cases • Security requiremetns • Security operations

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

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

16. Start with Software Developers!

17. Next Class • Risk Management