Software Security

1. Software Security

2. Essential Facts • Software Security != Security Features • Cryptography will not make you secure. • Application firewalls will not make you secure. • 50/50 Architecture/Implementation Problems • An Emergent Property of Software • Like Usability or Reliability • Not a Feature

3. SECURITY BUGS 50% Buffer overflow Cross-site scripting Race condition SQL injection Unsafe system calls Untrusted input ARCHITECTURAL FLAWS 50% Cryptography misuse Fragility Insecure auditing Lack of compartmentalization More privilege than necessary Replay attacks Security Problems

4. Security as Risk Management • Helps communicate security need to customer. • Cost of security vs. amount of potential losses. • No system is 100% secure. • Some risks aren’t cost effective to mitigate. • Humans make mistakes. • New types of vulnerabilities are discovered.

5. Risk Management • What assets are you trying to protect? • What are the risks to those assets? • Which risks do we need to mitigate? • What security measures would mitigate those risks? • Which of those measures is most effective, when considering cost, side effects, etc.?

6. Software Security Practices

7. Software Security Practices • Code reviews • Architectural risk analysis • Penetration testing • Security testing • Abuse cases • Security operations

8. Code Reviews • Fix implementation bugs, not design flaws. • Benefits of code reviews • Find defects sooner in the lifecycle. • Find defects with less effort than testing. • Find different defects than testing. • Educate developers about security flaws.

9. Static Analysis Tools • Automated assistance for code reviews • Speed: review code faster than humans can • Accuracy: 100s of secure coding rules • False Positives • Tool reports bugs in code that aren’t there. • Complex control or data flow can confuse tools. • False Negatives • Tool fails to discover bugs that are there. • Code complexity or lack of rules to check.

10. Static Analysis Tools • Older simple search tools • Flawfinder • ITS4 • RATS • Parsing Tools • Fortify Source Code Analyzer • Klocwork K7 Suite • Secure Software Code Assure

11. Architectural Risk Analysis Fix design flaws, not implementation bugs. Risk analysis steps • Develop an architecture model. • Identify threats and possible vulnerabilities. • Develop attack scenarios. • Rank risks based on probability and impact. • Develop mitigation strategy. • Report findings

12. Architecture Model • Background materials • Use scenarios (use cases, user stories) • External dependencies (web server, db, libs, OS) • Security assumptions (external auth security, &c) • User security notes • Determine system boundaries / trust levels • Boundaries between components. • Trust level of each component. • Sensitivity of data flows between components.

13. Level 0 Data Flow Diagram

14. Level 1 Data Flow Diagram

15. Risk Analysis • Attack Analysis • Historical attacks and vulnerabilities. • Attack patterns • Command Delimiters • Multiple Parsers and Double Escapes • Attack trees • Ambiguity Analysis • Compare understandings of architects. • External Weakness Analysis

16. Penetration Testing • Test software in deployed environment. • Allocate time at end of development to test. • Often time-boxed: test for n days. • Schedule slips often reduce testing time. • Fixing flaws is expensive late in lifecycle. • Penetration testing tools • Test common vulnerability types against inputs. • Fuzzing: send random data to inputs. • Don’t understand application structure or purpose.

17. Penetration Testing Tools • Penetration Testing Tools • WebScarab • Paros Proxy • Burp Suite • Vulnerability Scanners • Nikto • Nessus

18. Security Testing Injection flaws, buffer overflows, XSS, etc. Functional testing will find missing functionality. Intendended Functionality Actual Functionality

19. Security Testing • Two types of testing • Functional: verify security mechanisms. • Adversarial: verify resistance to attacks generated during risk analysis. • Different from traditional penetration testing • White box. • Use risk analysis to build tests. • Measure security against risk model.

20. Abuse Cases • Anti-requirements • Think explicitly about what software should not do. • A use case from an adversary’s point of view. • Obtain Another User’s CC Data. • Alter Item Price. • Deny Service to Application. • Developing abuse cases • Informed brainstorming: attack patterns, risks.

21. Security Operations • User security notes • Software should be secure by default. • Enabling certain features/configs may have risks. • User needs to be informed of security risks. • Incident response • What happens when a vulnerability is reported? • How do you communicate with users? • How do you send updates to users?

22. References • Greg Hoglund and Gary McGraw, Exploiting Software: How to Break Code, Addison-Wesley, 2004. • Gary McGraw, “XP and Software Security?!”, XP Universe, 2003. • Gary McGraw, Software Security, Addison-Wesley, 2006. • Michael Howard and Steve Lipner, The Security Development Lifecycle, Microsoft Press, 2006. • OWASP, The OWASP Top 10 Project, http://www.owasp.org/index.php/OWASP_Top_Ten_Project, 2006. • OWASP, The OWASP Guide to Building Secure Web Applications, http://www.owasp.org/index.php/OWASP_Guide_Project, 2006. • Paul Saitta, Brenda Larcom, and Michael Eddington, “Trike v.1 Methodology Document [draft],” http://dymaxion.org/trike/, 2005. • Joel Scambray, Mike Shema, and Caleb Sima, Hacking Web Applications Exposed, 2nd edition, Addison-Wesley, 2006. • Frank Swiderski and Window Snyder, Threat Modeling, Microsoft Press, 2004. • John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. • VISA, Payment Card Industry Data Security Standard (PCI-DSS), http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf