Rugged Software Engineering 2015-10-22

Rugged Software Engineering, presented at LASCON, Austin, Texas on 2015-10-22

1. Rugged Software Engineering LASCON 2015 Austin Texas 2015-10-22 Nick Galbreath @NGalbreath Founder / CTO Signal Sciences
5. Software Engineering
6. Technology concerned with the design, building and use of software
7. Software Engineering is not computer science
8. Software Engineering is not coding
9. Software Engineering is all of us
10. In London, my plea was to get Developers interested in Security. First version was at GotoCon London
11. In Austin, my plea is to get Security folks interested in Development
12. How are we doing?
13. Software Liability is Inevitable Jeff Moss, Black Hat USA 2015 http://techcrunch.com/2015/08/06/should-software-companies-be-legally-liable-for-security-breaches/ https://threatpost.com/software-liability-is-inevitable/114136/
14. I think we’re going to do a really crappy job with software liability for a long time, and the people who will suffer will be the innovators and the startups, not the established companies Jennifer Granick, Black Hat USA 2015 Keynote
 2015-08-04 around minute 46:00 https://www.youtube.com/watch?v=Tjvw5fz_GuA
15. 2015-09-10 The market for cyber insurance began to take off about five years ago, Beshar said. Today, globally, about $2 billion worth of premiums have been sold. Most of that coverage is in the United States, but the market is growing substantially, he said. http://wapo.st/1gcDU9i
16. … the bill wants automakers to establish real-time monitoring to “immediately detect, report, and stop” hacking attempts in their cars.
17. (USA) Government ranks last in fixing software security holes 
 Three-quarters of all government Web and mobile applications fail their initial security reviews CSO Online / Veracode Jun 23, 2015 … and then only fixing 27% a year later http://www.csoonline.com/article/2939234/application-security/government-ranks- last-in-fixing-software-security-holes.html
18. Financial Times 2015-09-15
 http://on.ft.com/1PQnM9H
19. Sadly Not Public https://twitter.com/dotMudge/status/642758829697056768
20. https://twitter.com/taviso/status/639992212164513792 Note: Patched and pushed in a day. Excellent
21. 1 https://fireeyeapp/script/ NEI_ModuleDispatch.php? module=NEI_AdvancedConfig&function=HapiGetFile Contents&name=../../../../../../../../../../.. /etc/passwd&extension=&category=operating %20system %20logs&mode=download&time=...&mytoken=... 2 3 ... 4 5 root:aaaaa:16209:0:99999:7::: 6 bin:*:15628:0:99999:7::: 7 daemon:*:15628:0:99999:7::: Here's your 0-day! — http://pastebin.com/ExXFZhDM Are you kidding me. https://twitter.com/h3rm4ns3c/status/638940105529499648
22. https://www.ernw.de/download/ ERNW_44CON_PlayingWithFire_signed.pdf

24. CVE-2015-5949
25. Slower Bloated
 More Expensive
 Less Secure
26. What Went Wrong?
27. Security is Invisible
 for Most of the Organization Invisible Things Aren't Valued
28. 100-10-1 Ratio Waterfall Model You can not hire out of this
29. You can not
 hire out of this
30. SDLC? http://www.microsoft.com/en-us/SDL/Discover/sdlagile.aspx deploy incident response Send the devs to 
 Security Camp once a year disconnected from dev
31. https://twitter.com/TheColonial/status/642199904547307520
32. failing at easy stuff.
33. I am the cavalry https://www.iamthecavalry.org
34. We are the cavalry
35. Rugged
36. What Emotion Are
 They Playing On
37. Maybe Unfair Comparison • Dynamic • Risk-Based • Continuous • Cross-Team • Hopefully appealing • Static • List-Based • Discrete • Single Team • Tainted Word
38. @kellan 2015-08-31 https://medium.com/@kellan/five-years-building- a-culture-and-handing-it-off-54a38c3ab8de Software development should be thought of as a cycle of continual learning and improvement rather a progression from start to finish, or a search for correctness.
39. Software Engineering
 is a
 Team Sport
40. building 
 things 
 together
41. But also, you have an adversary.
42. Cleaning up PreDeploy Deploy PostDeploy
43. Style 
 Matters
45. https://www.bsdcan.org/2012/schedule/attachments/ 218_crowdsec.pdf
46. The Buried Lead: 
 4x Faster Bug Fixes
47. Oddly relevant to software
48. Sound Familiar? • 16. Be clear…. Even to a writer who is being intentionally obscure or wild of tongue we can say, "Be obscure clearly! Be wild of tongue in a way we can understand!" • 19. Do not take shortcuts at the cost of clarity. Many shortcuts are self-defeating; they waste the reader's time instead of conserving it. • 20. Avoid foreign languages. (write in the standard language, reuse existing dependencies) • 21. Prefer the standard to the offbeat. Young writers will be drawn at every turn toward eccentricities in language.
49. OpenSSL Heartbleed Absolutely convinced this was due to the un-friendly un-styled code base
50. http://www.openbsd.org/papers/bsdcan14-libressl/
 May 18, 2014 LibreSSL - The First 30 Days KNF - Kernel Normal Form C-style
51. BoringSSL So BoringSSL headers and sources look like this rather than this. The comments in BoringSSL headers can be extracted by a tool to produce documentation of a sort. (Although it could do with a make-over.) (Clang's formatting tool and its Vim integration are very helpful! It's been the biggest improvement in my code-editing experience in many years.) First thing mentioned? Style cleanup https://www.imperialviolet.org/2015/10/17/boringssl.html
52. if (something) do_critical(); The Canonical Example, With C and PHP
53. > log_debug(…);
54. if (something) log_debug(…); do_critical();
55. if (something) log_debug(…); do_critical();
56. if (something) do_critical();
57. <-if (something) do_critical(); >+if (something) { >+ log_debug("…"); >+ do_critical(); >+}
59. Lots of asterisks here. Low Data Quality, Cause != Correlation
 Type of Crime or Severity not well measured. Read on!: http://cebcp.org/evidence-based-policing/what- works-in-policing/research-evidence-review/broken-windows- policing/
60. Only applies to accidents that scale linearly in severity … major failures have much more complex causes
61. Results • Faster code reviews • More code reviews • Smaller diffs • Less merge conflicts • Faster bug detection • Faster on boarding • Side effect: simpler code. • Easier to read for everyone, including security reviews.
62. Get Into Your 
 Build Pipeline. Block on Violations
63. Now Layer On The Good Stuff
64. Static Analysis • You are insane if you don't have automated static analysis running. • The closer it can run to the developer the better (i.e. can they run it locally or in editor?)
65. Security Testing? Yes be mean to your code! Don't Forget the Home Field Advantage. 
 You know your site better than anyone else. 
 Optimize your security testing for it.
66. Not just for the
 "software development team" Ops: Puppet / Chef / Dockerfiles, etc QA: testing patterns, cucumber Everyone: configuration and glue Today
67. "Alien" slot machine,
 Las Vegas 2015-08 Continuous
 Deployment
 
 Formerly known as 
 Release Engineering
68. Punch Tavern, London
69. Smaller 
 Chunks,
 More
 Often
70. Continuous meaning fluid not "all the time"
71. > function foobar() {… >… > } If this is the entire commit and deploy,
 we know it's not used. It's complete "safe" to be deployed.
72. // doco.. > function foobar() {… >… > } > function test_foobar() { > … > } Missing doco, missing test.
73. if ($usenewstuff) { foobar(); } else { old_code(); } $usenewstuff = false; When it's time to use, use a flag.
74. http://www.paulhammond.org/2010/06/trunk/ alwaysshiptrunk.pdf
75. How often you deploy is your decision
76. But when you do,
 it should be
 without ceremony
77. Average time to fix a vulnerability is 150 days after being reported…. you think that is due to technical reasons?
78. Don't Forget the Server!
79. Continuous Deployment applies to your OS as well as your application The CIOs surveyed named the top 3 common information system vulnerabilities as being related to application security (55%), security awareness (51%), and, perhaps most surprisingly, out- of-date security patches (50%).
 
 http://www.information-age.com/industry/software/123459579/ why-your-business-cant-afford-not-patch 2015-06-02
80. Security folks have been reluctant to continuous deployment for the applications. Love it for the OS* And application patches* Operations typically doesn't like deployment ever, OS or Application.* Developers love continuous deployment, but don't care about security or operations*. * Your experience may differ
81. Runtime
 Security Monitoring
82. runtime monitoring • machine level monitoring • application level monitoring • code-level monitoring • but security monitoring?
83. Key Questions • What are the attacks (they are happening) • Where are they attacking • Are they being successful And making this visible
84. Closing the feedback loop to developers
85. Cosmic Background Noise of Attacks
86. Cloud-based scanner
87. Attack Tooling
88. Using SQLMap, on this URL, focused on 'guests'
90. Security is Empowered
91. Developers are interested in security
92. • Software written by and for a team. • Write code meant to be read
 Write code meant to be read in a diff • Filtered out the dumb stuff before deploy • Deploy small chunks, regularly • Make Security Visible • Watch What Happens