Using Ruby In Security Critical Applications

A description of principles for designing and implementing security controls in security critical systems, with a special focus on rubyists. Also lists some research objectives for improving ruby security. The presentation is breadth over depth and has lots of links to related information. From RubyConf 2015 in San Antonio, TX

Transcript

1. Using Ruby In Security Critical Applications Tom Macklin RubyConf 2015
2. DISCLAIMER This talk represents MY personal opinions based on MY personal AND professional experience, and is in NO WAY representative of the NRL, US Navy, or US Government!
4. Naval Research Lab? “NRL”
6. NOT
   ! Military-specific Academicia Buzzword bingo
7. meta Security Critical? Explore a use case Next Steps
8. Uncle Bob: 2012 “The Reasonable Expectations of Your CTO”
9. http://threatgeek.com
10. what to pick?
11. don’t.
12. A security-critical system should have the right security controls, in the right places, with the right assurances
13. Architecture
14. Assurance Layering Framework Application Security Framework OS App DBM IPC MAC
15. Keep it NEAT
16. Non-bypassible
17. Evaluatable
18. Always Invoked
19. Tamper Evident http://www.drdobbs.com/security/anatomy-of-a-stack-smashing-attack-and-h/240001832
20. Assurances Controls Checklist Nonbypassable Evaluatable Always Invoked Tamper Evident OS System Application
21. Use Case: OS Controls Mandatory Access Controls (MAC) OS MAC
22. + Separate databases with OS access policies Logic servers mediating write operations MAC data separation! = Admin DB n1 n1 n2 DB DB DB DB DB n1 n3 n1 n2 n3 Database(s) n2 Network Application Server mlsqlite Reference Monitor Write requests Logic svr Logic svr Logic svr Logic svr
23. Read Only permissions Simple router to the writers Enforced by OS OS integrity checking*** => => => => Check! Nonbypassable Evaluatable Always Invoked Tamper Evident *** TMI for this talk...
24. Takeaways Abstract OS “hooks” with FFI Stub OS controls for development Don’t give your app system privileges
25. Next Steps • Better OS Unit test/double “tools” a la http://mock-server.com • Rust integration when type safety is needed e.g., http://brson.github.io/2013/03/10/ embedding-rust-in-ruby
26. Use Case: Services
    Security Framework Security Framework DBM IPC
27. https://xkcd.com/1253/
28. + least privilege process separation DSL-based pre and post content filters process & storage self protection =
29. (oversimplified)
    example policy item: No semicolons allowed to be stored App must permit content to contain semicolons
30. WARNING:
    example ignores i18n! https://lingohub.com/blog/2013/08/internationalization- for-ruby-i18n-gem/ ! https://www.cvedetails.com/cve/CVE-2013-4491/
31. application pre/post processing
32. storage processing
33. Separate process storage Small, simple, separate Monkeypatched into class ‘;’ present at storage => app is broken => => => => Check! Nonbypassable Evaluatable Always Invoked Tamper Evident
34. • ANTLR and Parselet http://antlr.org http://kschiess.github.io/parslet/ • checksec.sh - compile time protections http://trapkit.de/tools/checksec.html • PoC || GTFO - fun security publication https://www.alchemistowl.org/ pocorgtfo/ Other Cool Techs
35. Takeaways DSLs are great for content filtering Make simple checks at enforcement point Also, “TOCTOU” considerations... Learn how successful attacks work http://lmgtfy.com/?q=matt+honan+wired+hack
36. Next Steps • I/O sanitization “monad” hamster gem, $SAFE, ??? “Refactoring Ruby with Monads” talk • “spec2filter” Convert “standard” formats to rule sets spec2filter rfc822.txt > smtp_filter.yaml
37. Use Case: Application
    XML Processing*** *** oversimplification Framework Application App
38. ... But how do we build a high assurance, secure XML processor?
39. we don’t.
40. + use OS to isolate validation “layers” assured and contained content validation = software fault isolation, binary diversity REXML- Well Formedness Nokogiri- Validation DSL- Content
41. OS separated “pipeline” a good flog score... override ‘as_xml()’ SECCOMP monitoring => => => => Check! Nonbypassable Evaluatable Always Invoked Tamper Evident ~
42. Other Cool Techs http://grsecurity.net https://en.wikipedia.org/wiki/Seccomp http://buildroot.uclibc.org
43. Takeaways SECCOMP as a OS “firewall” Separate, isolate, then integrate Use flog and rcov gems on your apps
44. Next Steps (better) SECCOMP integration “Robusta” style for cruby FFI-SFI http://www.cse.lehigh.edu/~gtan/paper/ robusta.pdf mruby in buildroot toolchain
45. http://blog.coreyhaines.com zak!
46. Security (Penetration) Testing
47. • Giving info increases coverage, saves $ • Build relations with your pen testers Especially rules of engagement... Buying Penetration Testing: and...
48. • Test at the correct layer FOR EACH CONTROL! Otherwise you’re testing the outside layers much more We don’t do unit testing like that!?!
49. Thanks! Kim Cameron’s 7 Laws of Identity (2005) http://identityblog.com/stories/2005/05/13/ TheLawsOfIdendtity.pdf #nonsequeter:
50. Backup Slides
51. the security “delta” Using your “features” against you!
52. safety vs security?
    • positive vs. negative principles • simplicity and modularity are hardest • nature versus human creativity