1. Watching Software Run Brian ChessNov 18, 2009

2. Success is foreseeing failure. – Henry Petroski

3. Static Analysis

4. Misconceptions Prevail High priority int main(int argc, char** argv) { char buffer[10]; strcpy(buffer, argv[1]); } Low priority int main(int argc, char** argv) { char buffer[10]; strcpy(buffer, “test”); }

5. Trace potentially tainted data through the program Report locations where an attacker could take advantage of a vulnerable function or construct Many other approaches, no one right answer Taint propagation = getInputFroNetwork(); copyBuffer(, ); exec( ); buff newBuff (command injection)

6. A never-ending battle against bad code Format String attacks: known for 10+ years printf(input); SQL Injection attacks: known for ? years statement.execute(input);

7. The Stereotypes Static analysis – Good: thorough – Bad: too many results Testing – Good: concrete results – Bad: misses too many things

8. Security in the Development Lifecycle

9. A Lesson from Cryptography Security is hard to measure – Enemy has unknown capabilities – Small mistakes can have big consequences So how many of those static analysis results do we have to fix? 9

10. Risk Management vs. Compliance Risk Management Probabilistic framework for allocating resources Compliance Fulfill somebody else's requirements 10

11. Compliance wins Why isn't everyone a risk manager? Risks not widely understood People manage their own risk, not risk to the public

12. Compliance wins What to comply with?

13. Building Security In Maturity Model Real data from real initiatives McGraw, Chess, & Migues http://bsi-mm.com Breaking new ground

14. The nine Two more unnamed financial services firms

15. Four domains Twelve practices An “archeology grid” A Software Security Framework

16. Ten things everybody does Activities that ALL do – evangelist role – policy – awareness training – history in training – security features – SSG does ARA – code review tools – black box tools – external pen testing – good network security

17. Terminator

18. Success is foreseeing failure. – Henry Petroski

19. Reactive Revisited A good idea: build security in Problem: software will still be vulnerable Solution: must compensate at runtime

20. 20 Risk in a new endeavor Time Risk Market Risk Security Risk

21. Reactive Technology Today Protecting hosts and networks – Firewalls – Anti-virus – Intrusion detection Protecting software – Patching – Web Application Firewall – Language Level: Java Security Model

22. Patching Reaction time matters DON’T BREAK STUFF Microsoft has patched on Patch Tuesday for 30 months straight Patch flood means no one is ever fully patched

23. Web Application Firewalls (WAF) Sits on network, watches web requests Context problem – What will the program do with this input? Good for collecting attacks Scaling problem – Does go easily into the cloud

24. Java Security Model General access control mechanism – Domains / domain change – Privileges / privilege enforcement Built to – Protect good Java from bad Java – Protect a good computer from bad Java Nobody uses it

25. Return of the Reference Monitor Inline reference monitors (IRM) Aspect-oriented programming Watch interfaces between major components – Report important events – Enforce policy

26. Interface monitor architecture Monitor Event Event Handlers Action Program Point Target Program VM SyslogLog VM sees extensions as a profiler or a debugger

27. Federation Fortify 360 Server VM Controller VM

28. Static Analysis vs. Interface Monitors Static Analysis Part of construction Must anticipate all problems Locality important Performance not important Interface Monitors Part of deployment Must anticipate all symptoms Locality not important Performance critically important

29. DEMO

30. Better protection: SQL Injection Target Program Source of mal input Database WAF protects here We'll protect here

31. Patching a privilege escalation vulnerability Target Program Source of mal input Unauthorized request User Role We'll make the connection

32. Watching Software Run Brian ChessNov 18, 2009