Becoming a Security-Conscious Company (CHCon 2019) with notes

Transcript

1. THE FOLLOWING TALK HAS BEEN WRITTEN FOR PEOPLE WHO WANT TO SEE SECURITY CULTURE TAKE ROOT AT THEIR COMPANY BY SOMEONE WHO’S LEARNING, EVERY DAY.
2. Hi. @aupajo Hi, I’m Pete. And this is my first ever security conference, and my first ever conference talk. Please bear with me while I get the hang of it. That’s my handle on all the things. Twitter, the InfoSecNZ Slack, GitHub, etc.
3. Who am I? @aupajo I’m an engineer at a software company with ~50 developers in three countries. We build web applications and services for a variety of clients. We build complex systems and do long-term engagements. And we’ve always had what I would characterise as a healthy respect for security. One of the reasons we focus on solutions built on Heroku in particular, is the peace of mind of not having to worry about managing servers and the runtime. Many of us come from an ops background. We now how hard that can be to do well. Heroku lets us focus on application development, and doing that as best we can.
4. Disclaimer. Before I begin, I have disclaimer.
5. I know nothing. But more than I did 6 months ago. Always good to set expectations. I am not a security professional. I am a software developer. I’ve been writing software professionally for about 13 years. Talk is for software developers who are interested in how to improve security culture at their software company. In short, this talk is for me me six or so months ago. What I share today is what I wish I’d known when I started: some of the lessons I’ve learned, the wins I’ve found and the problems I’ve struggled with. For those of you who are security professionals, I hope you glean some insight into the challenges software companies face.
6. How to become a security- conscious software company. Or one way , at least. Warning: this is more about strategy than tactics. Some topics are better suited in a write-up on the internet. I think this one is better suited to a talk. You don’t need me for tactics (or if you do, come up to me after and let’s chat after).
7. Spoilers. I’m going to cheat, and show you the conclusion last. And I’m going to try to leave you with something you can remember and take away.
8. Buy. Measure. Bake and share. Works for Security & Cupcakes Here it is. It’s only five words. Eat that, Michael Pollan. Buy, bake, measure and share. Their purpose is to be memorable, so I hope you remember them. I call it the cupcake formula for security strategy. If it doesn’t work for security, It will at least work for cupcakes.
9. Our story begins Central America… * Probably . retelLings may vary . * Let me explain how I got there.
10. I went away on a long, long break from work. I traveled for about 10 months. This is the route I took. As I traveled to remote places, I kept up with the world by reading the news.
11. It was a bad year for technology. Traveling gave me some time to think and reflect. Especially about technology, the choices we make, and the brief window of time in which we get to make them. I kept wondering: how do I want to contribute to this world? And I must confess, I was on the fence about wanting to do technology at all. I mulled it over, for months. What happened here, I thought? Those developers at Facebook, at British Airways, at Equifax, etc. – are they inherently evil? Is Mark Zuckerberg an actual robot? Are they just blind to the responsibility placed on their shoulders?
12. No, I think these companies filled very much with people just like you or I. And doesn’t that make you wonder? How they got to this point? What should they have done differently?
13. When I got back I started in writing… And so, when I got back, I started writing a lot of my thoughts down…
14. …and thinking… We have this saying internally, “writing is thinking”. To write clearly means having to think clearly. I’m a big believer in this, and I often write to explain something to myself.
15. …and sharing… I shared some thoughts on security on our internal wiki. I shared them with my boss. We talked, I revised my thinking, and I kept aiming towards a goal…
16. Making a compelling case to focus. It’s not about whether a business cares or not. If you ask most businesses whether they care about security, I’m sure they will say yes. It’s not about caring, it’s about focus. It’s difficult to get a business to focus and align departments, teams, budgets, etc. In practice, it’s hard to focus around more than a handful of things, so if your thing going to be one of them, you need to be precise on why it should be focused on at the expense of other things. For us, it came down to a story about the increasing likelihood and severity risks based on our clients, and a coming market shift based on heightened public awareness and legislative efforts.
17. Reasons to focus on security It’s a long-term competitive advantage. It’s practical risk mitigation. It’s the right thing to do, which speaks to your values as a company. ✓ ✓ ✓ This is the very short version of where we came to. These reasons may not fit your company, your circumstances, or appeal to your leadership, and do not speak to the the qualification that went into them, but feel free to steal them as a starting point.
18. My boss brought a message to the company, and the message was: we must take security seriously. That was very helpful, a call to improve. It gave me a clear mandate that was visible company-wide, a sense of responsibility and support.
19. Buy. Measure. Bake and share. Get buy-in And so here’s the first word: “Buy”. “Buy” means “get buy-in” from the business. It’s the single-biggest factor if you want to do this.
20. Leadership Risks and opportunities Management Measurement, direction and practices Implementation Skills, tools, and support Now, it’s good to convince your CEO, but you need to go further. Ultimately, you have to get buy-in from everyone, because security is everyone’s responsibility. And you have to think about the different levels. Here’s what I would do: Open a doc, write out three headings and each of the issues as subheadings. Keep writing until it makes sense to you. You know your company best. Then show it to a colleague. Get their opinion. Revise. Get more buy-in, encourage collaboration address more perspectives, until its bulletproof and the business can clearly see the why and ideally the how. That’s how you start to get buy in.
21. You have buy-in. Now what? I confess I went round in circles a bit here. I did the easy wins. Switching on mandatory 2FA. Writing security training. I also read a lot and tried to absorb as much as I could. In retrospect, it was a bit directionless, but I suspect you’ll probably do this too, and I think it’s a normal part of grappling with a complex subject. But if I were to do it again, this is the question I’d ask…
22. What are you trying to do? Maybe you’re trying to “become security-conscious”. What does that mean? What’s a good way to break that down? Here’s how I like to respond to that question…
23. Well, how would you measure it? This is like a good definition of done. How do you know you know - clearly and unambiguously – that achieved what you set out to do?
24. OKRs Appeals to engineering sensibilities. It works. Bonus: You only need to read the first three (-ish) chapters to get the gist. Good contender for the best 1½ hour you can spend for your company. One approach I recommend is OKRs. It’s like thinking with portals – it takes a bit of getting used to, but one day a switch goes off and suddenly you’re doing improbable things with time and space. As a software developer, I think at some point in your career you glean that while you’re ostensibly at work to write software, on some deeper level you’re there to add this abstract thing called “value”. “Value” might mean seeing a way to avoid a doing ticket in the first place. It is literally the opposite of writing software, yet it’s the bigger win for the company. Learning OKRs are a good candidate for increasing your value.
25. Objective Become a security-conscious company by June 2020. How do we measure this? Time-bound, specific OKRs involving defining objectives and key results. For me, this is the objective. I got a rough sense for the scale and what we needed to do, and then set a date. But it demands a definition: what is a security-conscious company?
26. security-conscious adj. Embracing security culture through awareness, capabilities, and practice. Here’s what I came to. Notice the highlighted words. They were important in defining the key results.
27. Key Results 1. On 100% of our projects where we play a significant security role, a developer has passed a test for critical application security knowledge
 2. 100% of all employees (excluding those in their first month) have passed a test for basic workplace security
 3. 100% our client solutions pass the “critical” section of our internal security solution scoring matrix Now, I don’t have a lot of time to go into much detail.
28. Key result #3 100% our client solutions pass the “critical” section of our internal security solution scoring matrix Measurable Measurable. NeEd to define this What counts as a “solution” anyway? NeEd to determine what’s “critical” But here’s one key result example. Let’s unpack this. It raises a set of questions that will need to be answered in order for it to be measured and, ultimately, completed.
29. Components with known vulnerabilities audited in CI Security role explicitly described in contract Passes ASVS Level 1 Etc… Client A Yes Yes Yes No Client B No No Yes No Client C Yes Yes Yes Yes Client D Yes No Yes No Passing 75% 50% 100% 25% 63% 9/16 = Here’s what that matrix could look like. It gives you awareness. It gives you something objective to aim for. You could make the subjects applications, clients, or components in service-oriented architecture. It gives you a clear measurement: add up all the green boxes, divide by the number of total boxes. That’s your percentage. It gives you a way to focus. One sprint, you can focus on your lowest-scoring app. Another, you can focus on a particular security check across all apps.
30. Buy. Measure. Bake and share. Give yourself specific goals (OKRs are nice) So this is “Measure”. Give yourself measurable goals.
31. You’ve got measurable goals. Now what?
32. “Just do NIST.” (INSERT AUTHORITY OF CHOICE) Or OWASP, or ISO 27000, etc. Now, there’s some good advice here…
33. Don’t reinvent the wheel. There’s lots of good guidance out there. Some of it, like this wheel, I love. It’s a great starting point. But you quickly become inundated with information. There’s a lot of advice out there. The quality and applicability vary. It can quickly get exhausting.
34. Top 10 OWASP Top 10s 1. Top 10 Most Critical Web Application Security Risks 2. API Security Top 10 3. Serverless Top 10 4. Cloud-Native Application Security Top 10 5. Top 10 IoT Vulnerabilities Don’t get lost in the weeds. Here’s my top 10 list of OWASP top 10s. By the way, these top 10 lists are great until you’re susceptible to number 11. But you can imagine how lost in the details you can become. The thing to remember is these guides tools like any other, they’re not answers. They get you some of the way there, but not all of the way. They were designed in a general-purpose way without being aware of your company’s culture, circumstances, or constraints. It’s up to you to figure out how to apply them.
35. “Just buy DUO.” (INSERT PRODUCT OF CHOICE) Software tools are great, and definitely part of the solution. But hopefully you can start to see the problem by now. Let’s say you implement these. Have they negatively affected your culture? Have they impacted your security posture? By how much?
36. “Just hire somebody.” Hiring can be good, and leveraging experience is essential, but again, there’s a problem underpinning all these ideas: they treat security like it’s something you can bolt on.
37. “Bake in” don't “bolt on”. Your company culture is unique. It is inseparable from what makes it tick. And security is everyone’s responsibility. Blindly adopting a framework, tool, or hiring an outsider without thinking through what you want to achieve and how it fits into what makes your business tick is unlikely to lead to strong outcomes. So you have to do the thinking first.
38. Culture is like yoghurt. “I give you something to start with, but you’re going to do the growing.”
39. A strong engineering culture Developers lift each other up Continuous improvement Gaps between teams are bridged Experimentation encouraged Wins and losses shared It also helps if you have a strong engineering culture to begin with.
40. Early on, I started a security channel in our Slack. I made posts, both practical and interesting, and I cross-linked between other channels. Eventually, of their own volition, many people in the company started to join. And contribute. And discuss. This helped us improve, helped create a space within which to focus and talk about security in particular. And has it worked? We have approximately 50 developers. You can see there are 39 members in the channel now.
41. We also started hosting our local ISIG. This made it easier for our own developers to attend. I got to meet many of you from Christchurch. I found good advice, practical tips, and we invited a couple of of people come and give their talks during lunchtime. It was invaluable. It was also a lot of fun. So I highly recommend supporting your local ISIG!
42. Leverage experience. One piece of advice: leverage experience. When you’re new, you suffer from a lack of experience. So you should always try to compensate – to find someone with years’ more experience who has learned the lessons and can help you shortcut all the mistakes. Through ISIG, I found my way to hiring Kim Carter (binarymist) to help us tactically and strategically, and having the people at Lateral Security (sponsors of this event) help us plan out what we needed. It’s supporting local business, and it’s helping each other out.
43. Buy. Measure. Bake and share. Bake it into your culture So “bake” means bake it into your culture.
44. Buy. Measure. Bake and share. So what’s last one then?
45. Security alone is hard.
46. We have a common goal to keep the public trusting the software we build. We want to uphold their expectations. It benefits all of us to have the public trust that we’re doing what we can to protect the data they trust us with.
47. We’re better off working together to solve this problem. Security perhaps more than any other.
48. Default to open. Internally and externally. We must default to “open” – in our communities, in our learning and teaching, and in the way we interact with each other. We have to bridge out, internally and externally.
49. Internally, I’ve tried to stay open by publishing my thoughts…
50. …and asking for feedback. I asked people to score my OKRs. Today I’m sharing this approach with you, because I hope it’ll save you time.
51. Help each other succeed. Meet-ups Slack Conferences Open source Blog posts
52. Buy. Measure. Bake and share. Be open, lift each other up “Share”. Be open. Inside and out. Lift each other up.
53. This, to me, gets to the heart of my concern about technology. How do we stop becoming the well-meaning developers in these companies who let bad things happen on our watch? By learning how to talk to our leadership, to our management, to our engineers, making change through measurable goals, altering our culture and sharing that. Spreading that culture. It’s sometimes useful to remember that companies are legal fictions. Theoretically there’s this entity – “a company” – which supposedly services other companies, pays employees, etc. What happens is reality is a bunch of people decide to turn up and work together. How that shakes out is partly down to circumstance and leadership, but mostly due to the attitude and culture of the people working together. You have a lot more power here than you might think.
54. Take my notes…
 Ask me questions… Continue the conversation… @aupajo InfoSecNZ Slack / Twitter So, living up to that, I have an offer. Take my notes. Ask me questions. Continue the conversation. Let’s help each other out.
55. Buy. Measure. Bake and share. One last time.
56. Thank you. 28:00