Security And Compliance With Duncan Godfrey

"Duncan Godfrey: I was always obsessed with networks and the Internet. Day one of my career, I was in the most top-secret environments possible. A lot of small companies have a lot of very terrible security problems, and when they actually needed someone to come in and help them fix those security problems, they can't make use of the tools that bigger enterprises have, because they just have to fix all of the basics. Trust is this foundational pillar for everything that we do, and really, compliance is how we build that trust."

[INTRODUCTION]

[0:00:34] Guy Podjarny: Hi, I'm Guy Podjarny, CEO and Co-Founder of Snyk. You're listening to The Secure Developer, a podcast about security for developers, covering security tools and practices you can and should adopt into your development workflow.

It is a part of The Secure Developer community, check out thesecuredeveloper.com for great talks and content about developer security, and to ask questions, and share your knowledge. The Secure Developer is brought to you by Heavybit, a program dedicated to helping startups take their developer products to market. For more information, visit heavybit.com.

[INTERVIEW]

[0:01:07] Guy Podjarny: Hello, everyone. Welcome back to The Secure Developer. Thanks for tuning back in today. Today, we have a great guest, Duncan Godfrey from Auth0. Thanks for coming on the show, Duncan.

[0:01:16] Duncan Godfrey: Hi, Guy. No, thank you for having me.

[0:01:18] Guy Podjarny: Duncan, we talked about a whole bunch of things to review. But I think, maybe before we would dig into the actual topics, maybe kind of walk us through a little bit about what you do, And maybe the journey of how you got there.

[0:01:30] Duncan Godfrey: Sure. I wasn't into security as a kid, as probably a lot of people who come into your show did. I was always obsessed with networks and the Internet, and that's very much what I wanted to do. I did do computer science, and I've been into software, but I got my dream job working for a telecoms company. That was my first job in the UK. Then, day one, I arrived, and I'd actually been tapped to work in the government department of telecoms, which I think everyone knows that now is a standard part of business in the world that we live in. Day one of my career, I was in the most top-secret environments possible. I'm working my way through and I was introduced to the security community that way.

[0:02:13] Guy Podjarny: It wasn't a security role. It was just a security surrounding.

[0:02:19] Duncan Godfrey: Security surrounded but a security role, so building secure networks for kind of government clients, and doing security reviews, and secure systems for data storage, and things like that. It was eye opening, and it really framed the way that I view systems from then on. Because you have to meet certain standards, you have to design them in a certain way, and you have to meet all these really interesting and specific requirements. Actually, that is really what pulled me into the world of security, and thinking about security, and thinking about risk. It was a great way to start out. But as you say, I've done quite a few things since then, on my journey.

[0:02:54] Guy Podjarny: Yes. You started with a dose of paranoia a little bit.

[0:02:58] Duncan Godfrey: Definite paranoia, yes. That's certainly what happens in those environments. The worst-case scenario is, you're always catering for it. That was an interesting way. I did that for a couple of years, and then I pushed back about being in that world a little bit. I had a really fun adventure, living in Mozambique for a while, and actually working for a telecoms company there. It was at the beginning of, when fibre was landing in Southern Africa, down the coast.

Actually, we helped build out some of the networks there. They only had satellite communication, a lot of countries along the East Coast. Suddenly, the fibre bonanza arrived, and there was tons of bandwidth. That was a lot of fun. Then, I came back to the UK after a couple of years, and I worked for various established enterprise company, which was the complete opposite of that. I actually worked for the post office in the United Kingdom. But that in itself has a lot of interesting security challenges because they have a lot of retail outlets. They have a lot of very old systems that are running off the tills. It's actually, in terms of endpoints, one of the biggest number of endpoints in the UK.

[0:04:06] Guy Podjarny: Yes, you have to be close to customers. We have a lot of those different points.

[0:04:08] Duncan Godfrey: Yes. The customers are interesting and demanding, so that's fun. But, I think, really, what kind of put me on the tech adventure that we've been on for the last couple of years was actually moving up into Amazon. I joined the security team there, and that was really working at scale, working hours in scale, which is just something that I'd never seen before, and I may never see again. Because it's probably the biggest network, biggest systems in the world.

[0:04:33] Guy Podjarny: This is post-AWS era already, right? AWS is already kind of alive and well.

[0:04:38] Duncan Godfrey: Actually, it was a fun time to join, because it was during the transition. Actually, during my time there, a lot of what was amazon.com moved over to AWS. I was working on the .com side, but actually, we ran a lot of the network security. That's always, you kind of see a theme of what I'm talking about: network security, security monitoring, that's what I've been interested in. That's what I did for them. During that period, we were transitioning some things over to AWS, that Amazon itself were transitioning a lot of its own services over to pure AWS, which was interesting.

Actually, we, as a team, were actually using AWS services internally and dogfooding them for the first time, and we were customers too. We were actually helping to design secure ways to use those services and advise our internal customers. It was a fun time to be there and it was great to see security and systems of that scale. Then, I resisted a little bit working for a little bit of a big enterprise, I think a couple of years was there, I'd been on that adventure. Then, I founded my own thing with a friend of mine, which looking back was a very fun year. Unfortunately, the company didn't work out, but it led me to where I am now. I'm grateful for that part of it. But I was really trying to take learnings of what I had done as a security professional for bigger companies and try and do that for smaller companies. That's what we were trying to do with this little company called, Cadency, so working in the Netherlands,

[0:06:00] Guy Podjarny: This was more of a consulting kind of an advisory type role or as a product capacity?

[0:06:06] Duncan Godfrey: It was building out security monitoring. What you would classically call a CM, or just kind of data like of logs, but doing that at a much smaller scale. My grand idea was to do that for lots of lots of little companies, and that would turn into a big business. But, the funny thing about that was actually, it made me realise that a lot of small companies have a lot of very terrible security problems. What they actually need is someone to come in and help them fix those security problems. They can't make use of the tools that bigger enterprises have, because they just have to fix all of the basics. I found myself getting caught up in that.

Actually, it's funny you say, consulting because I actually ended up doing a lot of consulting gigs to try and fix the security of these companies, so they could use the system that I was trying to build. I never quite saw I was getting there. I actually see some interesting companies now, coming up, I think the way it's working out that we might be headed in that direction. I might have just been a little bit ahead of it. But it's definitely a space in terms of logging and enabling companies to have access to those tools that the bigger companies have was my main aim. Then. I ended up with Auth0, which kind of started up where I am now.

[0:07:13] Guy Podjarny: Oh, very cool. Okay. Well, let's that's quite a journey. You've seen some things, even Mozambique and some secret government chambers, and the biggest sort of Amazon surrounding, even the startup surrounding. Definitely have this sort of rich perspective coming into Auth0. Let's dig into the Auth0 work. Walk us through a little bit into roles and responsibilities maybe that you took on as the company grew, I guess. You joined when they were, you said about 70 people?

[0:07:40] Duncan Godfrey: Yes. I think I was the 70th. I wish I'd run the number down, but it was around about 60 or 70. We're of multiples of that now, so it's been a really fun journey. I kind of split it into two halves. I'm now a security leader, I'm leading a security team. But when you joined a startup, my first year there, I was a principal engineer, and I was building out security systems, helping developers deliver secure software. Primarily, I was focused on –we're a very heavy AWS shop. I was just trying to make sure that our cloud infrastructure was secure, and that we could scale, and keep up with the rapid growth just in terms of people, and in terms of services that we were deploying, and things like that.

Then, as the team, and the company grew, that's kind of the great opportunity of working out there. As I've grown with it, the team never stopped growing, which is fun. Now, I'm the Director of Security and Compliance, so it's a kind of combined role. The second half is, primarily focused on leading, and building, and structuring that team, and hiring, and making sure we have the right people in the right places, and we're doing the right things to build that trust with our customers that we need to build for them to use our services.

[0:08:51] Guy Podjarny: Cool. Before we dig into the sort of the org and this group you're doing. When you were joining, just going back a little bit because I find it very interesting to talk about when do you do the first security hires or subsequent when you joined that employees 70-ish with security in your title. Were you the first security hire? Are there other previous people that had that mental?

[0:09:11] Duncan Godfrey: No, there were actually was an existing director. Auth0 were forward-looking. It was actually a good friend of mine. That is the reason I joined the company. He said, "Hey, you should come and work for me. It's fast-moving, but you'll be able to have an impact, so come and work." It was actually when he moved on, I kind of took over his role and kind of took off from there. But there was one other application security engineer who I'm proud to say is still with the company too. We're the two oldest serving security people. It's Radek. I think you know too.

[0:09:41] Guy Podjarny: Yes. Cool. I mean, it's great, and I'm happy for it, but definitely forward-looking to sort of have three security staff, if you will, when the company is at circa 70 people.

[0:09:52] Duncan Godfrey: Yes. I think it's key. I mean, we're not going to pretend that we've got everything. We are trying to catch up in some areas. But when you're bringing people in at the beginning, and you're not having to bolt it on to the end, you're just saving time, and you're saving money, and you're saving frustration, and it's definitely something I'd recommend to other founders.

[0:10:08] Guy Podjarny: Okay, cool. This is fascinating journey. Hence, kind of the dig through it. You're coming along, you come, you build the AWS infrastructure. Let's maybe fast forward to today. What is the security team in Auth0? What does it look like?

[0:10:22] Duncan Godfrey: Yes, it's something I love talking about because it's been quite a journey and it's been a lot of fun putting the pieces into place. But really, the way that we divide it out now is we have what we call our product security team, which is a kind of cross-functional application and product security team. There are builders and our breakers. There are people who are dealing with vulnerability management, they're helping developers through a secure development lifecycle. They are dealing with incoming vulnerabilities and making sure we're dealing with them as quickly and as efficiently as possible. Just really like helping engineering understand security, secure development, working with them on best practices.

Then, we have two other teams. One of them is a detection and response team. That's something that is actually feeling like a little bit of a luxury this year because really, we've done detection response as a whole team, up until we've been able to get to this size. Now, we have a dedicated team of experts who are looking for issues, responding to issues, automating security response, which is something I'm excited about

Then, we have our cloud security team. So, you can see, that was where my strong background was, and that's obviously where I've put a lot of effort. I handed that off to a strong engineer, who's kind of driven a couple of engineers now, who's driven cloud security forward. That's what would traditionally be called a SecOps team. That's what it would have been called at Amazon, for example. But really, we're trying to keep ahead of ending up in a SecOps state of mind by automating as much as possible, not having people sitting, working tickets. It's building software, building automation to keep up with our growth.

[0:12:00] Guy Podjarny: When you say cloud security, how does that differ from product security? I mean, how is the cloud bit not product and how is it, maybe?

[0:12:09] Duncan Godfrey: It's literally securing the cloud. It sounds simplistic, but actually, AWS is so complex, and we move so quickly. You really need specialists to understand building secure infrastructure. Really, the way that I've built this program out is, I put a lot of emphasis and focus on monitoring, security monitoring, gathering logs, making sure we have a good audit trail for everything that we do. The charter of that team is to ensure that we're collecting data from every possible facet, nook, and cranny of AWS, and pulling that in for analysis. That's kind of the reason they exist. Then, on top of that, it's building tools for developers to be able to deploy safely to the cloud too. Making sure that they're not having to go it alone if they want to deploy some infrastructure.

We're reasonably flexible in Auth0r around what the development teams want to do. So, you do have some DevOps teams who are running the full stack. That's actually where our team has touchpoints with those teams a lot more when they're running the infrastructure. We have a couple of straight-up development teams who just deploy services to a platform and things like that. That team is really just securing, monitoring the cloud.

[0:13:24] Guy Podjarny: Okay. Is that a fair analogy to say that this team is kind of the SRE equivalent for security? Your sort of engineering the surrounding to be available and sort of in power, I guess, the dev team, but it's still on its own. sort of a turf of expertise.

[0:13:40] Duncan Godfrey: Yes. I think that's where we're headed more and more. Actually, I find myself hiring more actual – I don't like calling people DevOps engineers, but that's what the title is, that's what the industry has decided. Because we are running services, so we're running the security services for this monitoring, and collection, and for the tooling, and other services that development teams can plug into when they're deploying their infrastructure to get the data they need and to build the services they need.

So yes, I think that's a good way of thinking about it, kind of security SRVs. That's a little bit of a work in progress. It's a mixed-disciplinary team of security engineers, but more to the software development side. I think when people typically think of security engineers, they think of people who run firewalls, or they do the configuration on routers and things like that. But really, that's not how you can operate in a cloud environment anymore. That's not how you can operate. I'm sure, everyone's writing software. It's security software engineers building security services with some more infrastructure ops people now mixed into the team to help them scale their services too. We're also getting good quality service. So, yes, it's been interesting development.

[0:14:53] Guy Podjarny: Okay. Very cool. I think we dug a little bit into the sort of the cloud security team, or I'd love for someone to figure out a term for a security SRE. You need to do it, like make up a term and write a book about it and that will be yours. This is the cloud SRE, can the unravel a little bit what the other teams are doing as well, just for ownership turfs.

[0:15:16] Duncan Godfrey: Sure. The detection and response team, it's pretty much as straightforward as it says, as what it says on the tin. It's really dealing with the amount of data that the other team, so cloud security being one of the biggest providers of that, the security monitoring data. If you imagine, an AWS with – you switch on cloud trail, you suddenly get audit actions of everything that's happening in your environment. We have, I think, upwards of 150 AWS accounts now. That becomes a big data problem. We're collecting cloud trail from multiple accounts, and you're correlating that data, you're trying to figure out what's good, what's bad, you're trying to get a baseline of what is normal and what isn't normal.

At a basic level, that team is really working with that data to look for anomalies. That is their primary focus. What we're trying to do is avoid that team getting too large because it then becomes a little bit of a train on the business. What you'll see is like a SOC growing out, you'll have an analyst role, people will be working tickets on those events. But what we're trying to do is actually automate response to anything that can be automated. We're automating that way, so that team can stay focused on the next level up, which is doing the detection work.

Then, ultimately, that team is our insurance policy. That team is the team that deals with a security incident if it ever would have happened. There are trained incident responders who can deal with tough issues and they can problem solve, they can work under pressure if something is happening, and deal with it, so we have a good outcome. That's how I view that team as my insurance policy.

[0:16:56] Guy Podjarny: How do they differ from the ops team or how do they collaborate, I guess, with the ops team?

[0:17:03] Duncan Godfrey: Actually, they collaborate with all the ops teams because we need to gather data from all of our systems. It's a pretty similar relationship across – it's building a relationship to either have to deploy an agent to collect the data you need or working with them. If it already exists, to just send it to the place you need to go. Then, it's a two-way street, because a lot of this isn't necessarily just security information like cloud trail is actually pretty useful for troubleshooting issues. We're pouring that into a data lake for all teams to use and have access to if they want to troubleshoot things. But really, that team are also, they're kind of the centre of excellence around what the right things to be doing in secure systems are too. They're also doing a little bit of consulting work. They're working on hardening operating systems, they're working on making sure that the ops people are doing the right things in those teams, but they're just trying to get all the data they can. So we have all the visibility we can into our networks and into our systems.

[0:18:00] Guy Podjarny: Got it. Okay. But unlikely, cloud security people, they both have the sort of guidance element, but they also kind of carry a pager.

[0:18:08] Duncan Godfrey: Yes, ultimately. I mean, cloud security are on-call for – we run on like a DevOps team, so they're on-call for the services they build, so it is an ops team in that way. But yes, when you're on-call, you're focused on dealing with anything that's happening. We have an interesting environment because we have so many customers, and they can use our product in so many different ways. We're actually often offering a lot of advice to customers, and that often comes back to the security team in question. So you're on-call, you can be helping a few, funny, customer issues that have come up. But that's what your focus is, your focus is dealing with issues. Then, when you're not on-call, then yes, you're trying to automate away anything that frustrated you during your on-call period, like any ops team should be doing.

[0:18:51] Guy Podjarny: Yes. Good. One of the beauties of this new sort of DevOps mindset, and the reason you kind of own it. You get to experience the pain, and then, hopefully, you get to resolve it. Okay, cool. Can you give us a sense of the sizes a little bit? Then, before we move over as well to the product team. I think you mentioned that the cloud security is like a couple of folks.

[0:19:11] Duncan Godfrey: Yes, that's been a project for this year. We're roundabout four people, so that's a functioning rotor. We're going to grow that out to five or six people this year, so that's the main aim. So, it's a slightly longer rotation. I think that's a good size, that's a good. I think, as a rule of thumb, when I've been talking to kind of friends, and colleagues in the industry, like you kind of tie it to your headcount, the amount of incident responses you have. It's like one per hundred or one-and-a-half per hundred of the different things that we've discussed. We're kind of keeping pace there. But I don't really want that team to get too much bigger than that. As I said, I really want them to be big on automation.

The cloud security team is similar in size, and really, Auth0, we're fully in on AWS. We are an AWS partner and we are building all of our systems there. That is significant real estate to protect. That's how we've been able to get the investment in that team to kind of scale it up.

[0:20:08] Guy Podjarny: Got it. Okay. Cool. We've covered two teams. What's team number three? Actually, maybe like the most dev-ish product security team.

[0:20:16] Duncan Godfrey: Yes. Product security team is like an interesting name, is kind of one that I came down on. I think, at some companies, that's doing product development work. But for us, it's really being a part of the product development lifecycle. We have a secure development lifecycle, and that team is supporting developers through that. Then, that team is also triaging incoming vulnerabilities, assessing them, so we have a white hat program. We use Bugcrowd to run our program through that. You got interesting issues cropping up from time to time with people playing and testing with your product, so they're dealing with security researchers, they're dealing with people using that platform.

Then, we've always had a strong internal testing ethos. It's something that I've always been a big fan of. We have a couple of people in that team who are very offensive-minded, and they will go out – it's not quite a red team. So our red team is an organised – well, semi-organised function, who'll go and kind of try and break your environment in an unstructured way. But really, this team is trying to do an internal testing engagement on where they feel is the most important to kind of test, and play around with, and try, and break. I think a good way to think of that team is like breakers and builders. They're the people who are helping build things. But part of it is also trying to break the things too.

[0:21:39] Guy Podjarny: The product team is breakers and builders, kind of combined. I've heard, I guess I was new to the term of a purple team. I'm talking about sort of the blue team and the red team implying they do attacks, but they do so in collaboration with the defenders. So that everything can be loaded, and logged, and automated, and repeated. Is that an interesting kind of term for those two breakers in this team?

[0:22:03] Duncan Godfrey: Actually, that's a really good way to think about the structure of our teams in general. The first two teams are my blue teams, so the detect and respond in the cloud security, they're really all the defenders. Then, the product security has some aspects, and I think, purple team does capture that well. But I'd say, it's more of a combined purple team across all of the security teams because we're not really – we're not big enough that people are in silos and all that. I don't want people to get in silos. We do run some quite fun, like internal testing exercises, where we're trying to defend against an outbreak as they're trying to attack. Our blue teams are trying to look for that, so that is interesting. But yes, I like that way of framing it.

[0:22:45] Guy Podjarny: Okay. Cool. This team has those two people. Then, also has the people helping build secure products, as you said, sort of working with the bug bounties, and the likes. This is, I guess, what you'd call application security in more classic term.

[0:22:58] Duncan Godfrey: Yes. We're trying to have as frictionless as possible experience for developers to run through our secure development lifecycle. Because the development teams also can choose any way they want to develop software. We're just trying to plug in wherever we can, but keep it as safe as possible. [Inaudible 0:23:17] was really at the beginning, you fill out a very short form. I hope the developers [inaudible 0:23:22] too. That will steer you in the direction of how much help you're going to need from security. You'll fill it out, and say, you're going to be writing service that's going to be handling customer data, or PII. Or if you're going to expose a public endpoint, things like that. It's different paths down our secure development lifecycle.

Then, it's really working with our engineers and the security team working with the engineer and developing, to then, do some general threat modelling. So just exposing them to that concept of how you can write an application, and how typically people will attack applications, and how data is moving in ways that you might not expect, and working them through. Hopefully, upfront, we have the requirements in place and the good controls in place that we end up with good, secure software. Then, at the end, we're running some more tests.

For our core services, we're getting third parties to come in and test them too because you kind of need to have that external validation. After we've done some external testing, that we're pulling our pen testing company. We use different vendors, and they'll come in and do a final formal check. But, I mean, the way that things move right now, that is definitely the older model, is having that kind of formal check gate. Which is, it's getting harder and harder to enforce in a DevOps world where software is moving. I find us moving more to just try and insert security in the deployment pipeline as much as we can. So, it's just transparent to developers. So, plugging in different tools into the way that they deploy code, and trying to catch everything on the left side of the development cycle as early as we can.

[0:25:01] Guy Podjarny: Yes. That makes sense. I guess, when would they fill this questionnaire or this kind of a short form?

[0:25:07] Duncan Godfrey: Right at the beginning. Ideally –

[0:25:08] Guy Podjarny: At the beginning of setting up a new service or like at the beginning of what?

[0:25:13] Duncan Godfrey: The beginning of their development. Whether it be a feature or a service, so anything of significance, anything a new team is – either a new team, or a new service, or a significant change to what's happening, then you engage the security team, engaged with the security process, and then be guided.

[0:25:32] Guy Podjarny: Got it. Maybe this is kind of a good segue for us to sort of talk a little bit about indeed. We talked a lot about how do we operate, you're sort of agile, you move around, you build, you run your set of cloud security capabilities to DevOps. But this kind of shifts us a little bit more into the sort of the governance mindset as well and this world of compliance. So, let's dig into compliance a little bit. Compliance, I understand also, it's kind of a part of your mandate and title as well. Sort of keep Auth0 compliant from a security mental. What's your approach to it? How do you tackle compliance in the sort of fast-paced surroundings.

[0:26:06] Duncan Godfrey: Yes, that's really been our journey over the last year, and was my primary focus during last year. It's been really interesting. Previous companies, I think, Amazon in particular, compliance was a very scary department. They would come in, and they would audit you, and you were having a compliance audit. It was something that you were worried about happening, and it was something that you needed to make sure you had all your ducks in a row. I think, I can see that playing out all throughout my career, where the compliance department is a little bit in conflict with the rest of the business, or at least, you as an engineer, they feel like they're getting in your way, or you're checking a box.

I think the nature of Auth0's business, the way that we need customers to trust us, and trust is this foundational pillar for everything that we do. Whenever I'm talking to customers, I'm having to explain to them why they should trust the most sensitive transactions with us. And really, compliance is how we build that trust. You kind of internalise that, and then, you move forward, and you treat it as something that's enabling the business, is enabling sales, is enabling us to grow and to get the bigger customers that we want. That makes it easier.

Then, I've kind of set myself up as a main contributor to getting those compliance. I come from a very technical background, and I've worked hand in hand with who is now the director of compliance, he reports in to me. Last year, in particular, we worked hand in hand to get that done. But I think, in our environment, in a fast-moving environment, you have to – similar to what I was saying about pen test reports happening at the end, having a checkbox at the end. That just doesn't really work anymore. You need to think about how you can be compliant but in a fast-moving environment.

You need to actually be building tooling internally to track all of your assets. Because you don't have a list of firewall configurations to give to your auditor anymore, you have a huge amount of data in AWS that you need to process and that you need to present to them in a way that they can understand. You need to come up with frictionless processes in the way that we've done with our secure development lifecycle to allow developers to keep moving forward, to keep developing in a secure way. But also, fundamentally, you need to demonstrate that you have shown maturity along the way that you're doing things like change control, you're doing things like code reviews, you've got security tooling built in.

It's coming up with flexible, interesting ways to get the job done to be compliant, but not have that as a burden on the business. I think that's sort of been my approach to security Auth0 since I've come here. The model of information security that we had at Amazon was, you had a very centralised security department, which had a lot of power and a lot of sway to block you, to slow you down, to report you. But when I entered Auth0, that was not the power I had or the role that I had. It's not what I wanted to do. I kind of got on in what is now called SecDevOps. I worked within the development teams, I was building infrastructure, building services for them. That's the same way that I want compliance to be. I don't want them to feel like we're doing this to them. I want it to feel like it's important, and that it makes sense. and that it's enabling the business.

[0:29:28] Guy Podjarny: Yes. How do auditors feel about that? I like it and I believe in what you're saying, in terms of the way to operate the company. When you're coming to an auditor with a digest from your data lake, instead of your firewall rules, how was the reception to that been on the auditor side?

[0:29:46] Duncan Godfrey: I mean, it's a conversation. It was definitely more interesting in the initial conversations as we're trying to explain how we do things. But, it's really about having your evidence and having the confidence to explain why you're doing what you're doing. But I think, the industry is changing. We're not the only people who are cloud-native, we're not the only people doing DevOps. So, they've seen companies like this before. I think, five years ago, you might have been laughed out of the audit room. I hope that we're making it easier for other companies to go down this path too because I think it's the way to do it.

[0:30:23] Guy Podjarny: Yes. It's definitely a much-needed transition. We had one of the early episodes of in this podcast was with Sean Gordon from New Relic. Who, I think to an extent, maybe we owe a bit of debt for being one of those early educators in this world of cloud, for the compliance side of the fence. Okay, cool. We're doing those, and you're investing in compliance, and you're building all those components. I like what you said before about the trust element, and fundamentally, I guess, using that to help foster trust once you build those security controls, and you got those compliance certificates. Maybe get a vote of confidence from the customers for it.

We definitely feel like since we got this, it's been a while now, but I think when we got the first SOC 2 compliance, it just kind of streamlines so many conversations. It's absolutely worth the effort. We're getting lots of great set of insights, and I think, super useful as people look at how do they build their org teams, or their security orgs, and facilitate them? Before I kind of let you go here, I'd like to ask every guest that comes on the show, just as a parting question. If you have one tip, or one piece of advice, or one pet peeve maybe that you want to kind of get off your chest, that you want to share with the team looking to level up their security stance, what would that be?

[0:31:40] Duncan Godfrey: I'm worried sometimes as an industry, we keep making some of the same mistakes again. I really want to dig into that as like a concept. We're moving some of our infrastructure to Kubernetes, for example. That's a whole new paradigm of how we operate infrastructure. I can just see us making the exact same mistakes again when we're exposing that infrastructure to the internet. They're doing a really good job of catching up with role-based access control now, but that wasn't built in from the beginning. It's really hard as like a security team to audit that, and really understand what the infrastructure is. What we're building on top of it, I absolutely love. I love containers, I love immutable infrastructure, I'm loving where we're headed that way. I'm just worried, again, that we're not thinking about the basics.

That would be like my pet peeve to any security team is, before you get on to the more advanced stuff, really just doing the basics of locking down your access, vulnerability management, making sure you have good IT. I'm sure – I've heard it before on your podcasts, people have said that, but also, it's just vital. So, really, just getting that solid foundation to build on, that's my current pet peeve. When I see an expose [inaudible 0:32:49] management infrastructure on the Internet, I'm like – it feels like mid-2000s again.

[0:32:55] Guy Podjarny: Yes. Cool. That is a great tip. Make sure the basics are there before you get to get fancy, and into the shiny, new toy area. Well, Duncan, this has been a pleasure. Thanks a lot for coming on the show. Thanks, everybody, for tuning in. I hope you join us for the next one.

[OUTRO]

[0:33:13] Announcer: That's all we have time for today. If you'd like to come on as a guest on this show, or get involved in this community, find us at thesecuredeveloper.com, or on Twitter, @thesecuredev. Visit heavybit.com to find additional episodes, full transcriptions, and other great podcast. See you next time.