Everything will be broken

Looking at security principles from the perspective of imminent failure: how to make resilient security in the age of things falling apart?

This is a talk presented at SecurityBSides 2016 Kyiv

Transcript

1. Everything will be broken
2. # whoami 1997 #sprintnet #x25ru #phrack 2015 founder @ cossacklabs.com 2012 partner, director in dev business 2002 engineer
3. 1. Everything will be broken?
4. story: investments and dedication alone don’t guarantee good results american retail chain
5. story: data leak in very compartmented and echelonized network top Ukrainian bank
6. 0 25 50 75 100 80s 90s 00s 10s Effort Effect Effort grows, but effect diminishes
7. 80s: don’t let them in! firewalls authentication
8. 90s: control entrance firewalls authentication audit trail
9. 90s-00s firewalls authentication audit trail monitoring
10. 00s-10s firewalls authentication audit trail monitoring traffic inspection DLP encrypt data at rest encrypt data in motion
11. we love fancy tools so much, don’t we?
12. 20s: more fancy tooling!
13. WE LET THEM* IN, ANYWAY *
14. open/public infrastructures bring your own devices * *
15. blind package installation rabbit hole of dependencies * *
16. bad trust sources ‘smart’ thin clients * *
17. WE LET THEM* GET ANYTHING THEY* WANT *
18. cryptography is expensive! (writing in ruby is not ;) ) * *
19. compartmentation is inconvenient … and hard to maintain * *
20. keys together with data they protect * *
21. 1FA trust to intermediary tokens * *
22. Reactive security Wrong focus Reasons? Magical thinking
23. 0 25 50 75 100 80s 90s 00s 10s Effort Progress World changes faster than we invent new techniques
24. Intermission Airport business lounge firewalls and dnstunnel.de
25. So, what shall we do? 2.
26. most important risk management ideas haven’t changed in last 3 decades at all.
27. most important risk management ideas haven’t changed in last 1500 years.
29. Compartmentalization Echelonize defences Principle of least authority Log everything Environment is hostile Keep it simple Identify weak spots Safe defaults & positive model Kerckhoffs's principle
31. but these are just models!
32. “Just models” help produce desired effects predictably in technologically challenging tasks.
33. … tasks like creating secure infrastructures.
34. Before doing anything new, step back and think.
35. compliance standards as useful thought exercise intermission
36. 3. Putting models to practice
37. threat model: Enemy is already inside.
38. What can we do? proactive design limit proliferation compartment sources of trust
39. step 1: proactive tools first
40. proactive: HIDS reactive: antivirus example: binary monitoring
41. example: firewalls & access proactive: positive security + defence in depth reactive: typical mod_security ruleset
42. step 2: fall in love with boring tools
43. exciting crypto: SSL BEAST, POODLE, Heartbleed, DROWN, LogJam, FREAK
44. ideal boring crypto @djb: boring crypto is one that simply works, solidly resists attacks, never needs any upgrades.
45. good firewalls are boring; prepared DB statements and strong type system are boring;
46. step 3: trust and data protection
47. crypto is easy key management is hard
48. data owner as sole source trust EWBB way:
49. owner trust example Link encryption Link encryption End-to-end encryption
50. good end-to-end - 
 decrypt only on client.
51. >1 data actors: Hello PKC
52. B (decryptor): 
 receive (data, key_envelope) secret = asymm_decrypt (key_envelope, B_privkey, A_pubkey) plaintext = symm_decrypt(data, secret) grant access to encrypted data = send keys in envelopes! A (data owner): 
 data = symm_encrypt(data, secretkey) key_envelope = asymm_encrypt (secretkey, B_pubkey, A_privkey) send(data, secretkey)
53. owner-centric trust ideas we develop at cossack labs: combining asymmetric and symmetric crypto
54. unified trust scheme for data in motion and data at rest
55. worst case scenario: leak _some_ data
56. step 4: 
 limiting proliferation
57. firewalls: no ‘subnet’-‘subnet’ wildcard trust inside private networks strong comparmentalization
58. strong comparmentalization storage: no one-factor master keys to anything match roles/owners to access keys
59. trusted network traffic does not exist anymore
60. trusted network traffic perfect forward secrecy inside the trusted perimeter
61. repeated strong auth repeated authentication with different factors
62. repeated strong auth OTP enforced by crypto
63. auth and request ZKP auth and key derivation techniques
64. intermission on unexciting 90s software atm network done right
65. performance penalties
66. crypto seems expensive 0 100 200 300 400 read write plaintext AES reading & writing string from file in C, 1000 cycles 0 100 200 300 400 read write C PHP read/write string in C vs PHP
67. script languages OK? => crypto OK too
68. repeated authentication is frustrating?
69. give something back to users
70. last tip: how to succeed at (almost) anything
71. Thank you
72. https://medium.com/@9gunpi/ everything-will-be-broken- e21f6391aebc
73. Talk back twitter/medium: @9gunpi www.cossacklabs.com