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.
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.
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.
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).
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.
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?
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.
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.
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.
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.
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…
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.
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?
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.
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.
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.
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.
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.
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?
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.
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.
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.
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!
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.
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.
“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.
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.
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.