Four Years On: Reflections From Our First-Ever Guest With Kyle Randolph

ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community, a platform for developers, operators, and security people to share their views and practices on DevSecOps, dev and sec collaboration, cloud security and more. Check out devseccon.com to join the community and find other great resources.

This podcast is sponsored by Snyk. Snyk is a dev-first security company, helping companies fix vulnerabilities in their open source components and containers, without slowing down development. To learn more, visit snyk.io, S-N-Y-K.io.

On today’s episode, Guy Podjarny, President and Co-founder of Snyk talks to Kyle Randolph, Chief Security Officer and VP of Security, Privacy, Compliance, and Assurance at Episerver. Kyle has 18 years of experience scaling security teams and security services. He built a security team from scratch at Citrix, hardening everything from terminal service kernel drivers to COM clients. Kyle sandboxed everyone's favorite malware delivery agent at Adobe and built authentication services at massive scale at Twitter. Most recently, Kyle has been focusing on growing security and privacy at Optimizely which serves JavaScript on many of our favorite websites. Episerver recently acquired Optimizely where Kyle's scope has expanded to CISO and leading the trust org for the combined organization.

[INTERVIEW]

[00:01:47] Guy Podjarny: Hello everyone. Welcome back to The Secure Developer. Today, we have a very special episode. We actually have with us on the show Kyle Randolph, who today is the Chief Information Security Officer at Optimizely. But maybe even more of a badge of honor is that he was the first guest to be on The Secure Developer podcast way back roughly four years ago. So very much a great opening episode and it was for me a pleasure to actually go back and re-listen to it with all the great advice in it. But, Kyle, thanks a lot for coming on the show. Great to have you on the show again.

[00:02:20] Kyle Randolph: Yeah. I’m happy to be back.

[00:02:22] Guy Podjarny: Kyle, we're going to take a little bit. We're going to use the opportunity of having kind of you in that sort of first episode and having kind of grown to be the CISO at Optimizely and dig a little bit into the deltas. So maybe what we're going to do is we're going to run through some of the observations, some of the insights that you had back then, and then just talk a little bit about how things have changed, how your perspectives have changed, maybe sometimes your practices and the likes. Sounds good?

[00:02:49] Kyle Randolph: Yup.

[00:02:49] Guy Podjarny: Okay. So let's start from org. Let’s start from people and people structure. So in our first conversation back then, you described how you joined the company as probably one of the first people if not the first person with the security title. Security was being done but not necessarily in a dedicated capacity. When you talked about it, you talked about security as a whole, what's being done. There was InfoSec activities later on. By the time we spoke, there was InfoSec activities, but you were doing AppSec. InfoSec and AppSec were separate, where AppSec was in engineering and InfoSec I assume wasn't. You were partnering with InfoSec at the time. Can you tell us a little bit about how that changed? I mean, is that still reality today? How has that maybe evolved over time?

[00:03:35] Kyle Randolph: Yes. So, we have adopted a similar model between both the abstract side partnering with engineering, as well as the IT security side partnering with IT where we have a lean security team and we have security engineers that we call partners. So, like for each engineering team, we have a security partner assigned. Then for the IT team, we have a security partner assigned. These teams own their own security and also their privacy and compliance, but the security partner is the governance layer and the advisor to them to help them figure out, okay, out of all these things we could and should be doing for security, how do we figure out what to focus our resources on and what to do first and how to do it the right way to meet the security expectations, as well as the other business objectives that engineering or IT have for the business?

[00:04:31] Guy Podjarny: Interesting. Is the organization now combined? Is it one group and then has that partnership model?

[00:04:39] Kyle Randolph: Yeah. We have one group. We call it security, privacy, compliance and insurance, and this core group is the governance layer for all security for the company, both on the engineering side, the infrastructure side, as well as the product infrastructure side and the IT infrastructure side.

[00:04:55] Guy Podjarny: That’s cool. I think I like the model. It sounds similar to people partners, the sort of HR/people partners, right, or sort of finance partners. Is that the right way to think about it? It's a central organization that is a service provider to these other parts of the org?

[00:05:09] Kyle Randolph: Yeah. They're the service providers and the subject matter expertise and the governance layer. Then, we want to as much as possible, like we would rather hire more site reliability engineers for example, and they spend some of their time doing security than we would wanting to step up on a lot of infrastructure security engineers. It’s far more flexible for the business to where you can allocate those folks on security one day and something else another day. Also, for the security team, you're not constrained with how do you grow the security team and then how do you manage a larger org? Instead, you can just get as much leverage as possible out of a smaller number of security subject matter experts.

[00:05:48] Guy Podjarny: Yeah. I mean, I can definitely say that the scale model, and indeed it's been proven in the world of HR partnerships and others. Do you find from our relationship with engineering, was it a big difference to technically not have the team report into engineering and move out or not?

[00:06:06] Kyle Randolph: So, one of the challenges you have is just the further away you get from engineering, the more challenging alignment can be like just across teams within engineering. Okay, that's a little bit harder than the same team and then alignment across different departments. That can get a bit harder. We’re kind of in between where we've reported to the SVP of the security org who’s reported to the SVP of engineering and then more recently to the CTO. This was good because you still had the ear of the head of engineering. You were in the room for like the CTO staff, so the other heads of engineering – You’re there. You're hearing about what's going on. You can talk about what you've observed across the org and have impact there. So, it's a layer deep than if you were totally isolated but not being embedded in like a particular team. You don't get like pigeonholed too much in one part. You may not have the same visibility like you were lower down in the engineering organization.

So, I think it's a sweet spot like still being in the product development organization. But like at the CTO level, that is supposed to like appoint you a CIO or CFO or something but also better than just like being a security team reporting to an engineering manager or a director that may have more limited visibility.

[00:07:18] Guy Podjarny: Yeah. No, interesting. I agree. It's a good model. In fact, it’s actually how we structure it at Snyk in the moment as well with sort of the security organization reporting into engineering but at the top of the command chain there. So it means the IT security team is in engineering, and they partner with a team which is outside of engineering.

[00:07:40] Kyle Randolph: Yeah, yeah. So the IT org is separate, and so like you have the other sync meeting there similarly, but like the it team has their own IT security engineers and folks who do – They’re like part-time IT security engineers, but we have an alignment across the teams on like what are the security priorities for them and what they work on and a weekly sync there to stay tuned. So that's like a little more removed there but being a SaaS business where your SaaS product is what you're selling. Like you want to optimize for having the best security there, and it's not saying we don't have good IT security, but I would like to have the least amount of inefficiency in the product side. So, it makes more sense to be engineering and then IT outside.

[00:08:26] Guy Podjarny: Yeah. I think that makes a lot of sense and it's interesting. So, I guess if I paint this a little bit of the timeline just as I’m going to try and do given the sort of the two points in time that we have, fundamentally the two aspects of the org remained. But it's just the part that became the center was the product security side, the application security side. So, the IT side embedded into it, and I fully relate to the fact that while both IT and security, both securing the enterprise and securing the product are important in a SaaS company, probably bigger risks arise from securing the product. You’ve actually even mentioned that at the time, talking about how Optimizely as it grew became more of a target where if it gets compromised, many websites could get compromised. I think that aligns well with that view.

So how do you split the responsibility if we focus on that sort of product security side? You talk a lot about this autonomy years of responsibility for security within the, say, infrastructure of the SRE team. How do you think about the security KPIs or the tracking, the division of security responsibility between your team or the security engineers and the people they partner with on the engineering side?

[00:09:35] Kyle Randolph: The line is kind of drawn on like the requirements and the prioritization side. So like the security partner is like, “Hey, here's my security requirements. Say from like the standard or maybe from best practices or from your threat model, from your risk treatment plan or other sources and then – So here's the things I want to achieve and here's my preferences on like technology selection.” But the SRE org, they're also a stakeholder and like, “Well, I may have a different way of like achieving the security goal. That's fine.” So there's alignment on the how, and then the development and operations and ownership of that security control afterwards is owned by the SRE team, and they're permitted to make like their own security decisions as long as they're still meeting the security requirements.

We have meetings to make sure we're still aligned but we want to give more autonomy to the team since they own the stuff to like truly own it, as long as they're aware of the requirements that we have.

As far as KPIs go, the sort of like interesting ones for us are on the risk mitigation side, so like what are the top risks that we have for the company that apply to this particular team. A lot of the top risks of the company do end up with the start reliability engineering team since that's the product infrastructure.

And then also for these controls that the SRE team is building. For example, they have a Kubernetes cluster, and we really want to invest baking security into this Kubernetes cluster and the other foundational parts in that like a secure defaults for the containers using Terraform. We have Terraform like examples that we know are good with our network security standards. So we can measure like how much is that being adopted. Is it out there? It’s just out there but people are working around it or is like – How many of the like projects implied by other engineering teams are actually building on top of this and getting this advantage of security already baked in?

[00:11:28] Guy Podjarny: So that's actually like a great segue. It sounds like a very healthy division between the two groups and it sounds like the KPIs focus more on kind of the adoption of a security control versus necessarily managing or like rotating on trying to measure the risk reduction that it offers. It’s more about the application of the security control if that's not misrepresenting.

So maybe indeed kind of let's veer a little bit into that sort of tooling side of the fence. So I've got your on record, right? So, in the previous episode, you had this sort of phrase that I really liked which was a guiding principle. It was for your work. A guiding principle was if "I'm doing something myself, I’m probably doing it wrong", I loved that sentiment. I think it sort of still holds well to the modern kind of a security approach that scales through the dev. You described how from a tools perspective you would do these lunch and learns. You'd showcase some cool security tools and you’d sort of keep your fingers crossed that one of the engineers would pick them up and run with them and think that they're cool.

You've already alluded to this a little bit right now, talking about sort of measuring how well a tool is being embraced. I guess how is that perspective changed when you think today about security tooling and putting them in? What guides you? What's your sort of methodology there?

[00:12:40] Kyle Randolph: Yeah. A couple of things that have changed. The one thing is like before I do the lunch and learns to like show off tools and like generate interest from engineers. As Optimizely's evolved, like we've brought in much more diverse experience and more experienced engineers, and a lot of them again on the SRE side especially but also in the application development side. Folks have had experience at different companies and how they did security and often at much larger scale than Optimizely or with a very different risk model.

Now, it's a really fun thing to do is to talk to folks and talk about like our security challenges and then hear, “Well, okay. That sounds like something I solved at another company, and here's how we did it.” They have really interesting proposals there which sometimes come out better than like anything that was even on our radar from the security team. Now, yeah, just socializing the problems and seeing what all is out there, and you get more diverse perspectives. I think that's a much stronger place to be and also like going back to that ownership that the teams have when they feel empowered to have that flexibility that they get to decide on the how they want to solve things, as opposed to a security team saying like, “You need to use this tool or you need to solve it this way.” They feel empowered to like leverage that experience and other ways of doing things that they've seen elsewhere in the industry. That’s what's changed on the tool side.

Now, as far as like tools, what's changed for us, one of the things that's kind of like we're in this transition phase. This is the direction we're just starting to go in is we have these partners that align with the engineering teams, the site reliability engineering team and so are seen between the two often is defining a security standard for a particular security control, so like machine to machine authentication or encryption in transit.

So historically, what we've done is like, “Okay, let's get a doc. Let's throw all the requirements. And if we have an air table with all the security and compliance requirements, let's put all that down in the appendix and then let's figure out what do we want to do. Or like maybe we're referencing a CIS benchmark or some other security standard, and let's figure out what makes sense in this org and what doesn't.”

This is good but the developers like working in the developer environment and so why don't I go to work in the GitHub doc and work on this document? Let’s work closer to the code. So, like going in the direction of policies code or configuring the tools, we can have our standards just go straight to code to find them there and have pull requests on the policies that we set. So, the network security standard, for example, rather than like having a document that says like, “Thou shalt do this for network security,” like let's just have our Terraform components for the network rules, and we can put pull requests in there as needed and discuss there. So, the standard in the code are one, instead of having this document separate from the code and those – It’s just a lot more likelihood of the two not being aligned or like it may get de-prioritized after you finish the document and not get it to code. So just cutting out that intermediate step is great.

[00:15:40] Guy Podjarny: And this is your team that joins in and opens that pull request that's the security engineering? Or is this again something built by the engineering team themselves and the SREs?

[00:15:48] Kyle Randolph: It’s kind of a variety. It may be the SRE writing it and the security engineer providing feedback. Other times, it may be the security engineer like, “Hey, here's what I’m looking for. What do you think?” The SRE folks or engineers take it to the next level. I'd say more often than not it's the engineers drafting. Once they understand like the requirements, they're the ones drafting it, and then the security engineer is reviewing it.

[00:16:10] Guy Podjarny: I love the kind of drop the middleman a little bit there with removing the code that describes it or the sort of the text that describes it and going straight to code and sort of the natural growth in it alongside the developer affinity. I think there's a lot to love about it. I guess what's helping you implement this, you mentioned Terraform. Are there other kind of core tech that you're using to make this happen?

[00:16:32] Kyle Randolph: Yeah. Terraform is helping as far as like the security scanning, so like we’re just starting to like get into more automation of schemes like software composition analysis, instead of like asking people, “Hey, go use this tool to do that more automated governance. Okay, let's go look at GitHub. Let’s look at our org and let's just –” Rather than asking folks what should or shouldn't be in there, let's tag all the – We’re using GitHub topics. Let’s tag all the repos that are prod. Then make sure that all those are in the tool, and they align with our GitHub security standard. We have a tool that can either report or even set through the API like the requirements we have there like a branch protection rule.

Then going back again how things get out of deep and have them on paper or maybe you have a spreadsheet with a list of all the prod repos. That's always going to be stale, so we also look at like just what are the active repos. I can sort them and then, “Okay, show me the most active repos that don't have like a prod tag on them.” Then, okay, those are the ones we need to bring on to our tool. That’s on the GitHub side.

Same thing on the cloud service provider, so like we go in AWS and then just getting tagged in there. Okay, like what are the prod things we want to look at and bring to the surface? Things that aren't tagged properly but we should be focused on that can tell us if we have them on our tools or not.

[00:17:51] Guy Podjarny: Got it. It sounds like this would be the – I’m trying to kind of understand the organizational piece. Would this be the security engineering team pulling together the data you can extract out of GitHub, the data you get out of the cloud, and then kind of combining those into a security tool, so it's the security team that builds those internal tools?

[00:18:09] Kyle Randolph: Yeah, yeah. So, we're building the internal tools, as far as like preferably like in my opinion the security team should try and get out of the business of building security tools because then you got a security engineering team with a maintenance liability. If you're like a <> company, you can have a big warrant to do that. But for everybody else, like I would say the build versus buy analysis, you would definitely want to go more towards buy. Sometimes, what helps though is by the security team building their own tooling just to solve an immediate need. That helps develop the business case in ways that you may not have been able to or may not have had time to. It’s too abstract like, “Hey, why do we need this? Why do we need budget for this?” You need this. But once you've run a script, “Hey, here's how it's going but like here's the cost of maintaining this tool and here's its limitations.” That's a much stronger case. We need to put some dollars behind us and get a more grown-up solution in place.

[00:18:26] Guy Podjarny: Yeah. I mean, I love the flow. I think I feel this when you build a product. Oftentimes, when you go through a build versus buy of a whole product line even, you have the same notion which is if you haven't started building it, you oftentimes don't necessarily know what you need until sometime that you build it. So there's definitely a lot of logic here. I guess we're all limited by kind of how much dollars can be spent. The security industry is at the end of the day a bottomless pit in terms of how much you can spend there. It’s always a balancing act between building it out and buying.

Not that surprising there. There’s a lot forward thinking approach here that the teams run a lot of the sort of security operations. They collaborate the security engineering team. It really kind of helps equip them with tools and all of that kind of tries to be coded into the fabric of it. I especially liked your references to SRE team. It sounds like you're almost trying to build security into the infrastructure, just like you would infrastructure I guess, kind of the core operational. Is that correct? It kind of referred to the SRE team a fair bit both from an experience in the likes. Is that sort of the high level philosophy is to treat these security controls as a natural part of the infrastructure?

[00:20:14] Kyle Randolph: Yeah. I guess the ideal solution we want to get to is where we have this platform that already has all the security privacy compliance controls baked into it. So then if you're the application developer building new features and products, as much as possible you're already getting security for free and you don't have to worry about it. You're probably never going to totally get there but you can get closer and closer, and so wherever possible.

For example, we have our common controls for. It’s a matrix that maps to – You name it compliance, it maps to our security engineering best practices, to our privacy requirements. So we have about 140 common controls. Then out of those, there's about 80 that we need to do within the product development organization. So that's very expensive, like 80 frigging controls anytime you want to like build a new feature. That’s not going to apply. So as much as possible, let's push those down into the SRE layer and as low as possible as we can so that can be building a control by the SREs or it could be a technology preference like should you use a serverless or should you use a container or should you use an EC2 instance, for example. Here’s the relative security cost for each of those. There's going to be some additional security overhead, depending on what you choose.

So the more we've been able to bake into the SRE org, we brought that like 80 number down to where there's I believe about 30 controls now that the product development organization, the engineering teams outside of SRE may need to consider depending on what they're building. I still see room for a lot more improvement there. Some things are at a layer above this or the organization. We call it like the application platform, so this could be like your framework for microservices. Use this and we know you can – Like all communication is going to be over TLS 1.2. We focus on maintaining cipher suite selection there. We know you use this framework. You already got authorization built in for [inaudible 00:22:19] between your microservices and also like logging. There are so many different layers of logs using this framework, and you don't have to deal with logging.

Other things like kind of on the horizon to get that 30 number down more could be like, okay, customer data deletion , like subscribing to a common message bus for that or over to GPR, the subject access requests, like moving more and more those out so that more developers can just focus on building features.

[00:22:47] Guy Podjarny: Yeah. No, that sounds awesome. It sounds conceptually maybe even practically similar to the paved road concept, right? You documented the best practices or you documented the controls required and then you're creating this sort of application platform that has as much of them embedded into it already. Is that correct?

[00:23:06] Kyle Randolph: Yeah, yeah. It’s certainly the paved road approach and it's like you can either use this paved road approach. Or if you don't, okay, here's that subset of those 30 controls that apply to you, so we're going to have to figure out what to do there. Sometimes, in the interest of like development velocity getting things out as fast as possible, that makes sense. Maybe out of 30, it's only a small number that apply to them. So it's okay for them to not use the paper or maybe like a significant number. But we can find out other ways maybe by changing what they're building to drive that number down but without using that paper. We have flexibility there but bringing transparency to into like, “Hey, here's where we're starting from with how much work you can do and here's your options.” Developers really like having that flexibility.

[00:23:51] Guy Podjarny: Yeah. I think it's a very healthy approach to set up a brainless kind of path is to go on the sort of the paved road, and many of your concerns would just automatically go away. If you want to go off, then you need to put in the time to explore and evaluate these different controls.

[00:24:05] Kyle Randolph: Another aspect of this that we're just at the like tinkering stage with is so I guess like the controls prescription and what are we doing with like design reviews and how we figure out what controls are important, what aren't. This is not a new notion but we're just starting to dip our toe into it is moving away from like the design reviews and more into like a self-service questionnaire. So like, “Okay, you're building a new feature. Answer these questions.” Today, like we dump the questions [inaudible 00:24:32] security engineer reviews that.

The direction we want to go is more if this than that kind of logic where like, “Is your feature collecting customer data?” “Yes.” “Okay. Then we're going to create a requirement for you for account deletion or like to subscribe to this event bus for it. Okay, you're collecting PII. All right, we’re going to just go ahead and create a requirement for you for encryption at rest, unless you would check yes on using one of these stores that we already know we have an encryption at rest by default.” So that would also like help cut down on the like security overhead [inaudible 00:25:03] security engineers more not being so tied up on designer reviews. I also like not being so contingent upon having a designer review in the first place because not everything has a design dock.

[00:25:15] Guy Podjarny: Yeah. It makes a lot of sense. Definitely a recurring and valuable theme of independence to the teams to helping them kind of self-provision. So maybe indeed that it is a decent segue, it's talking a little bit about sort of interaction and celebration.

Last time, we talked about a security community. You described you had this group of people that kind of self-selected into it. You hang out in a Slack channel I think was the phrase. You have some weekly cadence. I guess how has that changed over time? Have you considered or implemented like a more formal security champions program? Is it still a community? What does that look like four years later?

[00:25:54] Kyle Randolph: As far as security champions go, we stayed at the I would say the informal and organic security champion program for quite a while where it's like, first, joining Optimizely when they were just to start their security program from scratch. There was quite a bit of effort for like inbound marketing. They get false interest in security and get folks come bring things to us and the Slacking helped out a lot. Then as we grew and the security requirements grew, we needed to get more formalization. So, we shifted the effort from that inbound marketing and getting I guess the informal security champions to focusing more on the partner side that I mentioned previously. So, we shifted a bit.

Just take Slack as an example. Instead of having one security Slack room where anybody interested talks about security, which we still do but it's more like general security topics or customer requests. Now, we have a Slack room which is like security-team [inaudible 00:26:51] engineering team. That’s where we talk simply about that team security considerations and anybody's walking in rooms, of course, but typically we have the folks from that team in there, including product manager, the engineering manager. That's great to bring more visibility to the team about these topics and not have it get lost in the sea of their general team channel chatter, and they have a place to go where they know that it's going to get attention because of the security partner paying attention to it.

We are just now like looking to take our security champion program to the next level, but we detoured more into like investing more in the security partner side. But the future is the security partner from the security team, plus the security champion from the engineering team.

[00:27:34] Guy Podjarny: Yeah, it makes sense. It think it sounds like you're tackling a lot of sort of the fundamental concept of security champions which is indeed that partnering approach, and it’s just all about the ratios and the right autonomy that the team has which, in your case, is quite high. So maybe as those teams, it's not a formal champion or security community program but rather it's quite embedded.

One of the topics that – Well, you were the first on the podcast but definitely one of the early ones for me to hear about was the celebrating success aspect, and you described a security hero t-shirt that you had that you gave to relevant developers that succeeded it. What have you sort of learned over the years in terms of celebrating success? Are there other practices or tactics or maybe just philosophies around recognizing developers or others that do well on security?

[00:28:25] Kyle Randolph: Yes. So the shirts were a big hit. I think they say like 2015 on them, and still a lot of people wear them, and I love complimenting folks who still bust them out quite regularly. But where we've gone from there is a lot more recognition that I feel like we can't overinvest in recognition. Even when we feel like we're doing too much, like we need to be doing more. So it's been much more like I guess the common places for recognition has been just watching Slack, like being in lots of Slack channels and, of course, like the partners being in their partner rooms and looking for like even small wins. A small win may be a tiny win. It's a thumbs up on a Slack message. A bit bigger win like, “Let’s call that out in the team Slack room.” A bit bigger win, let’s call that out in the engineering all hands a week. We need a bigger one like the company-wide airing of praise channel or even like, “Okay, you did something massive like a big milestone.”

We just built some pretty major controls in one of our main AWS accounts. That’s like a company-level thing. Hey, let's talk about that in the company all hands and why it matters to the business and why it matters for Optimizely also its customers. So, it's all these different layers and but it's just like a constant filtering, especially for me. As things bubble up more, like me going and recognizing things large and small and getting them more visibility too. Folks may feel like they work on security, and it's not going to get recognized, and do you need to recognize like every ticket they close like to all of engineering? No, but sometimes, harvesting those gems that may be done under the hood or may not be very sexy but then bringing them to one of these larger forums. It’s a really big deal like letting folks know that what they're doing is contributing to the business and giving them more visibility across the org and even to their manager and their manager’s manager. That helps out a lot too. The shirt was cool but this is much more dynamic and real-time feedback which much more closely tied to what they did specifically, as opposed to like a more generic value honor which the t-shirt is.

[00:30:30] Guy Podjarny: Got it. Okay, interesting. It ingrains it. I think if I slightly summarize a lot of what I'm hearing in terms of the evolution is I think when you entered Optimizely, you had to start getting people thinking about security more to find your allies, figure out who cares about security as well, build that out. As you grew, instead of taking over security and saying, “Hey, I'll do all of those. You don't need to worry about it,” what you've done over the course of the five or six or how many years you're there is ingrain security inside and make yourself and the team be the advocates of it. Be the ones that are sort of driving and ensuring adoption. I think that's great. I think it's the path that we all aim to achieve in terms of embedding security inside while still playing an active role. It’s not that you're saying, “Hey, this just happened. You have a lot of specific systems, specific software you're building, specific motions to do it, which I think is a great evolution.

As always, I actually have a whole pile of other things to ask but I think we're going to need to end around now. But before I let you go, I’m going to ask you and it'll be interesting to compare this to your answer last time because I asked you the same in the first one is if you had to give one bit of advice to a team looking to level up their security foo, a development team, a security team, a company, what would that bit of advice be?

[00:31:51] Kyle Randolph: Yeah. My bit of advice over the years has been one of the main things has been like get the decisions out of it or like stop making humans make the decisions. So wherever we can like build security in without relying on an engineer to make that decision, that's great. So, yeah, investing more in tooling, making security into components, I think that's like gold because you keep on benefiting from it without needing more humans and needing more humans make the right decision in the moment and have all the standards in their head.

As far as investments and that, like the tooling and getting as much as you can, like going back to that build versus buy analysis like bias, even if you think you're biased to buy, like how can you like double that bias? Anything outside of your core competency, like buy and get as much security for free as you can.

[00:32:43] Guy Podjarny: That’s excellent. It’s interesting. Last time, when we did the episode, you focused your advice more on philosophy. You said that security teams should get all your security issues out in the open, discussing them. A lot of teams say, “Oh, yeah. We’ve known about this and we heard about the security bug over there,” but you don't actually see them in the bug tracking system. So I think at the time you were trying to shift the direction, and it sounds like your answer right now is very much a scaling answer. It’s like you felt the pain and the benefit of automating more, of building more, of not making it a burden. I think both bits of advice are very, very good and depends I guess on which stage you are and what you're trying to achieve.

[00:33:20] Kyle Randolph: Yeah.

[00:33:21] Guy Podjarny: Kyle, this has been a pleasure, again. Thanks a lot for coming on and for sharing kind of all of that learning. Congrats on the acquisition of Optimizely and for your taking over sort of the CISO role and broader security responsibilities. Very much well deserved as the great advice here demonstrates. So thanks for coming on.

[00:33:39] Kyle Randolph: Thanks a lot, Guy. It’s been a pleasure.

[00:33:41] Guy Podjarny: And thanks, everybody, for tuning in, and I hope you join us for the next one.

[END OF INTERVIEW]