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 Problems

• 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

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 arent cost effective to mitigate.
• Humans make mistakes.
• New types of vulnerabilities are discovered.

5
Risk Management

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

6
Software Security Practices
7
Software Security Practices

1. Code reviews
2. Architectural risk analysis
3. Penetration testing
4. Security testing
5. Abuse cases
6. 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 arent 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.
• Dont 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 adversarys point of view.
• Obtain Another Users 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

1. Greg Hoglund and Gary McGraw, Exploiting
   Software How to Break Code, Addison-Wesley,
   2004.
2. Gary McGraw, XP and Software Security?!, XP
   Universe, 2003.
3. Gary McGraw, Software Security, Addison-Wesley,
   2006.
4. Michael Howard and Steve Lipner, The Security
   Development Lifecycle, Microsoft Press, 2006.
5. OWASP, The OWASP Top 10 Project,
   http//www.owasp.org/index.php/OWASP_Top_Ten_Proje
   ct, 2006.
6. OWASP, The OWASP Guide to Building Secure Web
   Applications, http//www.owasp.org/index.php/OWASP
   _Guide_Project, 2006.
7. Paul Saitta, Brenda Larcom, and Michael
   Eddington, Trike v.1 Methodology Document
   draft, http//dymaxion.org/trike/, 2005.
8. Joel Scambray, Mike Shema, and Caleb Sima,
   Hacking Web Applications Exposed, 2nd edition,
   Addison-Wesley, 2006.
9. Frank Swiderski and Window Snyder, Threat
   Modeling, Microsoft Press, 2004.
10. John Viega and Gary McGraw, Building Secure
    Software, Addison-Wesley, 2002.
11. VISA, Payment Card Industry Data Security
    Standard (PCI-DSS), http//usa.visa.com/download/b
    usiness/accepting_visa/ops_risk_management/cisp_PC
    I_Data_Security_Standard.pdf