1 / 32

Watching Software Run

Watching Software Run. Brian Chess Nov 18, 2009. Success is foreseeing failure. – Henry Petroski. Static Analysis. Misconceptions Prevail. High priority int main(int argc , char** argv ) { char buffer[10]; strcpy(buffer , argv[1]); } Low priority

krysta
Download Presentation

Watching Software Run

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Watching Software Run Brian Chess Nov 18, 2009

  2. Success is foreseeing failure. – Henry Petroski

  3. Static Analysis

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

  5. Taint propagation 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 = getInputFroNetwork(); copyBuffer( , ); exec( ); buff newBuff 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?

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

  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. Breaking new ground • Building Security In Maturity Model • Real data from real initiatives • McGraw, Chess, & Migues • http://bsi-mm.com

  14. The nine Two more unnamed financial services firms

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

  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. Market Risk Security Risk Risk in a new endeavor Risk Time

  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 <Rule> VM VM sees extensions as aprofiler or a debugger Target Program Monitor ProgramPoint Event <EventHandler> Event Handlers Log Syslog Action

  27. Federation Fortify 360 Server Controller VM VM 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 WAF protectshere We'll protecthere Target Program Source of mal input Database

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

  32. Watching Software Run Brian Chess Nov 18, 2009

More Related