Move Fast and Fix Things
Download as PPTX, PDF0 likes999 views
This document discusses making security easier and more practical. It argues that security needs to move beyond just being possible to actually being practical. It highlights several challenges, including that human factors are important but often overlooked. It proposes some solutions like making encryption and secure protocols the default instead of optional, and using cloud infrastructure to improve isolation and make compromises more survivable. The overall message is that the security community needs to come together to actually fix issues and make real improvements instead of just discussing theoretical possibilities.
Move Fast and Fix Things
- 1. From Possible to Practical: The Path for Defense Dan Kaminsky Chief Scientist White Ops
- 2. Or: MOVE FAST AND FIX THINGS
- 3. We can fix this Internet. You can help. Yes, you.
- 5. “Look! Linux and Windows, launched instantly from the cloud! And…”
- 6. “No wait go back” “Huh? But hypervisor…root…safe…”
- 7. WHEEEEEEEEEEEEEEEEEE They just wanted a safe Internet experience. For once.
- 8. We could lose this Internet. Or we could save it.
- 9. Some think security is impossible.
- 10. Apparently anything is possible.
- 11. When it comes to security, though…
- 13. “It’s possible to survive this infection…”
- 15. It doesn’t matter why it’s hard. Just matters that it is. Human factors matter.
- 16. “Doctors are gentlemen, and gentlemen’s hands are clean” From the great debates regarding the Germ Theory of Medicine You really don’t want to know about the history of Anesthesia.
- 17. Germ Theory: How does it spread, what keeps it sterile? == Well Defined Interfaces Known Good State PRACTICAL PRACTICAL PRACTICAL
- 18. They measured. They monitored. They learned. They rebooted. Those white coats? Symbolic.
- 19. Infosec did not invent “Snake Oil” We used to take actual snakes, and press them into actual oil.
- 20. ACTUAL CHINESE SNAKE OIL WORKS Snakes are expensive… Nobody could tell the difference… Didn’t yet have the analytical chem… AWKWARD HYPERMETAPHORICAL HISTORY IS AWKWARD
- 21. “Modeling How Students Learn to Program” If you don’t learn it in week 2, you’re going to fail in week 7. {piech, sahami, koller, coopers}@cs.stanford.edu, paulob@stanford.edu
- 22. BUGS AREN’T RANDOM (Well, of course, but really.)
- 23. Humans have intentions. Machines have instructions. Humans are right. Bugs are in the comm layer.
- 24. Programming languages. Not programming equations. It’s not math. It’s cognitive science.
- 25. JavaScript and Assembly are both Turing Complete. In that sense, they’re isomorphic. Go ahead. Call them equal.
- 26. I see bad APIs. They’re everywhere. They don’t know they’re bad.
- 27. Application Programming Interfaces that spend their budget on barely working, leave nothing left for working securely.
- 28. Security is not separate from IT. IT looks to Security. They need our help!
- 29. We cross layers. We see victims. We witness systems failing. It’s always systems.
- 30. “Whatever, most hacking is really just phishing anyway”
- 31. Phishing is a technology failure. Microsoft Windows Technical Support isn’t walking into the office.
- 32. Phishing happens because victims can’t authenticate the caller but need to trust them anyway. Phones don’t just ring once, and INBOX is not ZERO.
- 33. Bad APIs are bad. Bad APIs are bad not just if they break machines, but when they break people. I mean, the machine’s next.
- 34. Human factors aren’t an extra point. They are the point. Nobody intended that buffer to overflow.
- 35. We aren’t measuring enough. Barely see crashes, rarely seeing frustration.
- 36. It’s not just security. Other fields are easier to measure. We have to fight harder.
- 37. Hacker Latency is a problem. We can’t keep taking years to find things.
- 38. “NIH for Cyber” == Volunteer Firefighting is cool, but we don’t have the guy who fights cancer Nerds, stable funding, a mandate to measure and repair this Internet
- 39. Find What’s Hard. Don’t Judge. Fix.
- 40. Developer Ergonomics: Full Chrome dev environment, boots in seconds. (dochro)
- 41. Easier to inspect and fix Chrome? More inspection and fixing of Chrome. Human factors. (I mean, I needed it)
- 42. Lots of insecure TCP listeners. Far fewer secure TLS listeners. Why? Crypto? SSH replaced Telnet…
- 43. No permission required for TCP. No permission required for SSH. Had to get a certificate from a bizdude. Couldn’t automate.
- 44. Can now.
- 45. So let’s. JFE: Jump to Full Encrytion # ./jfe -D There, all services, all ports, valid cert, if a client wants working encryption it’s there, system-wide
- 46. I mean, you could do all this configuration…
- 47. People normally just deploy this. •
- 48. Be shameless. Anything can block you, you might need to fix anything. Be rigorous. You have to be right. LISTEN.
- 49. It’s hard to trace DDoS. Takes time, takes manhours. How do you deal with spoofs? Who do you even call?
- 50. Nothing in our architecture is set in stone. (This is equal parts reassuring and terrifying.)
- 51. OverflowD: Stochastic Traffic Factoring Utility Sends small bits of Netflow, to nodes suffering Network Flows.
- 52. Alice attacks Bob. Alice is not directly connected to Bob. There are many intervening routers and networks. They’re all monitored for load.
- 53. Status Quo: Netflow goes to the same network, or maybe to Feds. Never to attackers or victims. But they’re the interested parties!
- 54. Idea: ~1/1M packets causes a tracer to attacker and victim net. “Heh, I saw this, here’s an abuse contact.” See what happens.
- 55. What if every DDoS came with the keys to stop the DDoS?
- 56. You have to think of the time these floods take people to resolve, and the scalability of that resolution. Find the hard problems.
- 57. Recognize the real world.
- 58. “Why did everyone punt their DNS to DYN instead of running their own infrastructure?”
- 59. Did you miss the last ten years of software development moving everything to the cloud? Don’t answer that You just did
- 60. We’re not securing 2005 anymore. Clouds are not JBOS (Just A Bunch Of Servers), where you hack one, you hack them all. For almost all values you
- 61. All or Nothing is not how risk management works It is how a lot of systems are modeled, and thus designed
- 62. “After your password database is compromised, make sure the attacker has to do as much work as possible…”
- 63. AFTER???????
- 64. If we can’t trust the cloud, we should dramatically improve isolation. If we can trust the cloud, we should dramatically adopt its isolation. It’s way better than ours.
- 65. Cloud’s are not JBOS. They’re services with authenticated semantics. Isolation becomes someone else’s problem Amazon is better at running servers than you are, for all values you in this room
- 66. Ratelocking: Rate Limiting w/ Serverless Cloud Assets. $20 in the cash register, not all corporate earnings. 3 logins every 10 seconds. Not 500M
- 67. Let the cloud make your server getting compromised, a survivable event.
- 68. The APIs make it hard, so it hasn’t been getting done. Let’s make it easy.
- 69. Not rhetorical! I can’t write it all. I dare you to write it better. You actually can help.
- 70. Yes, you! Write code! Test code! Document code (PLEASE)! Break code! Managers – jailbreak code!
- 71. The value prop of Open Source: It is easier to find a solution on GitHub, than from the team down the hall. Or your own team last year. None of us have unique problems.
- 72. We have to fix this. We can fix this. Whatever you can do, you can make a difference here. Let’s #MakeSecurityEasy. dan@doxpara.com or @dakami I’m running hackathons, and gauging interest.