August 1, 2006

Software Security

August 1, 2006

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

August 1, 2006

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

August 1, 2006

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.

August 1, 2006

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

August 1, 2006

Software Security Practices

August 1, 2006

Software Security Practices

1. Code reviews

2. Architectural risk analysis

3. Penetration testing

4. Security testing

5. Abuse cases

6. Security operations

August 1, 2006

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.

August 1, 2006

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.

August 1, 2006

Static Analysis Tools

• Older simple search tools– Flawfinder– ITS4– RATS

• Parsing Tools– Fortify Source Code Analyzer– Klocwork K7 Suite– Secure Software Code Assure

August 1, 2006

Architectural Risk Analysis

Fix design flaws, not implementation bugs.

Risk analysis steps1. Develop an architecture model.

2. Identify threats and possible vulnerabilities.

3. Develop attack scenarios.

4. Rank risks based on probability and impact.

5. Develop mitigation strategy.

6. Report findings

August 1, 2006

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.

August 1, 2006

Level 0 Data Flow Diagram

Anonymous

Administrator

Database

Logs

UserWeb

Server

HTTP/HTTPS over public internet, form

logins

Apache 2.0.54 on

OpenBSD 3.7 with

mod_lisp and

CMUCL

FirewallLocal

Filesystem

Machine

Boundary

ODBC over SSL on

switched 100bT,

user/pass login

Flat text file

on OpenBSD

3.7

PostgreSQL 8.0.3

on OpenBSD 3.7

August 1, 2006

Level 1 Data Flow Diagram

Anonymous

Administrator

Content viewer

User Database Logs

Account Creation

Login

Admin

Content Creation

SSL

Only

SSL

Only

Module with log &

account creation privs

Module with

password hash

accessMachine

Boundary

Firewall

Module with DB

write access

Module with log &

DB admin privs

August 1, 2006

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

August 1, 2006

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.

August 1, 2006

Penetration Testing Tools

• Penetration Testing Tools– WebScarab– Paros Proxy– Burp Suite

• Vulnerability Scanners– Nikto– Nessus

August 1, 2006

Security Testing

IntendendedFunctionality

ActualFunctionality

Functional testing will find missing functionality.

Injection flaws, buffer overflows, XSS, etc.

August 1, 2006

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.

August 1, 2006

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.

August 1, 2006

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?

August 1, 2006

References1. 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_Project, 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/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf