Product Security Insights With Rinki Sethi

[00:00:22] 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, Founder of Snyk, talks to Rinki Sethi, Vice President and Chief Information Security Officer at Twitter. Rinki is responsible for leading efforts to protect Twitter’s information and technology assets and advise the company's continued product innovations in the security space. Prior to Twitter, Rinki was most recently the VP and CISO at Rubrik. She has been at the forefront of developing cutting-edge online security infrastructure at several Fortune 500 companies such as IBM, Palo Alto Networks, Intuit, eBay, Walmart, and PG&E. We hope you enjoy the conversation, and don't forget to leave us a review on iTunes if you enjoyed today's episode.

[INTERVIEW]

[00:01:47] Guy Podjarny: Rinki, excited to have you on. Thanks for coming on to the show.

[00:01:49] Rinki Sethi: It's an honor to be here.

[00:01:51] Guy Podjarny: Rinki, before we dig in, can you tell us a little bit about what is it that you do today, but also a bit about the journey that got you into security and into the role you're in today?

[00:01:59] Rinki Sethi: Today, I'm the Chief Information Security Officer for Twitter. So I run all of information security at Twitter. I've been here for, gosh, just about six and a half months now and joined at a really interesting time at Twitter when Twitter had gone through its breach. But it was right before the election and a really interesting time to join as the Head of Security here at Twitter, which I can dive into more later.

When I was in high school, before I knew what cyber security was, before I knew what hacking even was, I remember that AOL Instant Messenger, for those of you that used it –

[00:02:39] Guy Podjarny: You’re dating yourself there.

[00:02:40] Rinki Sethi: Yeah. I’m dating myself, but that was the thing. That was the new thing in how you communicated with your friends. I was a late adopter of it, compared to my friends. I started chatting and I thought it was the coolest thing ever, until I overheard my dad telling my mom about something I had typed to a friend and I was thinking, “How the hell did he know about that?” So I started digging around in my machine and realized now what we call a keylogger is something he was aware of and was a parental spy tool that he had installed on my computer and was recording all my chats and reading them and just wanted to make sure probably that I wasn't talking to boys or something like that.

I found out about it. I told my sister about it too, and so we started messing with him. I deleted it first but then I'd have to go and check again, so I wrote a little program that would alert me every time he installed it, and we would actually mess with him. We'd start writing stuff that wasn't real and then hear him talking about it later. I think my mind was always a little twisted in that direction towards kind of like that security hacker type thing, although I left that alone. I went and pursued my computer science engineering degree at UC Davis. When I graduated, it was a real bad time in the economy, and I was willing to take any job at that point. I wanted to just have a job when I graduated.

Fortunately enough, I was recruited by PG&E, and that was my first role in becoming a cybersecurity analyst. Back then, they called it an information protection analyst. So I started my career there. I’ve been in cybersecurity for about two decades now. I worked at Walmart.com, at Intuit, at Palo Alto Networks, at eBay, at IBM for a really short stint, Rubrik, and now here at Twitter. So I’ve been around the block in terms of industries and types of companies and cultures as it relates to cybersecurity.

[00:04:31] Guy Podjarny: Yeah, absolutely. I love the motivation to get into the world of security through sort of teenage insubordinate or through sort of maybe – As a parent, I think about the appeal. I've resisted the appeal so far, but it is tempting. I know how to do it. I know how to sort of track the kids’ activities. I've preserved their privacy today. I hope I keep that up.

Let's dig a little bit into those companies. I think one of the super interesting lenses that you have on the world is just the different perspectives you have on product security, right? You've worked at companies big and large. You've sort of touched security as a whole and product security specifically for a journey. You've sort of seen the industry itself evolve and you've even kind of been over to the dark side of it, sort of being a vendor for a while or rather being a security team at a security provider at Palo Alto. How do you think? If we think about product security and how you approach security, what are your key takeaways about how is it different? As you as you think about these different profiles of company, how would you bucket them?

[00:05:34] Rinki Sethi: It's so different from company to company, industry to industry. Then depending on what the company itself is going through at the time, they might be going through a transformation. So when I joined Walmart.com, product security was easy. It was a really small development team. Walmart.com was a wholly owned subsidiary by Walmart, and so it was easy to influence. It was easy to train developers. It was easy to push security into the product, and product was different back then, right? It was a website and it was an e-commerce site, and e-commerce was a new thing back then, a different type of culture at Walmart.com.

Then going to eBay was very complicated when you thought about the eBay platform back then. Developers were given a lot of access. There was this culture that made it such a cool, innovative company at the time that let developers do what they want. I remember thinking like it was very, very difficult to bring security in. It was a larger company too. How do you scale security and how do you train developers? That's when I introduced at eBay the idea of security champions and really training and developing core competency into the development teams because it was the only way to secure product and really scale product security.

Then I went over to Intuit, and that was actually – Intuit, I actually led product security, and it was a really interesting time because now Intuit was broken up into business units. So TurboTax was a business unit. Mint was a business unit. They had a small business group, and so they had all these business units. Each one had their completely different development practices. Each one – One was in desktop package software, where you bought TurboTax from Costco. The other was starting to like just completely in cloud. So you saw all these variations, and product security was nuanced.

[00:07:23] Guy Podjarny: But the product security organization was centralized like these different – The development teams were separate, but product security was one central entity supporting all these different groups.

[00:07:32] Rinki Sethi: Yeah, that's exactly right. It’s such an interesting model. Again, it was in a position where you can't scale that, right? How are you going to have a central team when everything's different? Maybe you can hire one person for the big business units but what beyond that? The other interesting thing was that really threw a monkey wrench into the product security and how we thought about it, was walking away from desktop packaged software and moving to cloud but not just private cloud. They were moving TurboTax like data. They were the first company to move data, like the very, very private sensitive data into public cloud, AWS. So they were going through a massive transformation. You're re-architecting your applications. You're having to rethink product security as a company.

Again, that security champions models started coming back again, very different from company to company. Then you talked about me being on the security vendor side at Palo Alto Networks and at Rubrik and thinking about how we did product security there. It was, again, a little bit simpler. But then you're also thinking about this is critical infrastructure for many companies where you play as a security vendor. The scrutiny and amount of importance of security was at a whole different level, and you have to role model what security is for the rest of the world at a company like that, and so very different from company to company.

Then, of course, Palo Alto Networks had a hardware business, and so your product is not just software. Different nuances, different challenges along the way, different ways of organizing, different cultures, different success stories and how you organize, so really interesting.

[00:09:08] Guy Podjarny: Yeah, it's fascinating. There's like a world of questions that come out of this. But for starters, when you referred to security champions, and you're describing things very much in the relation or maybe the proximity of the security organization to the development organization, is that a correct way to read what you're saying? Like you're talking about how when Walmart did was – It was easy because it was small enough and close enough. While maybe in Intuit it was hard because you were distant, and it was very diverse. Is that sort of the fundamental you think, and you addressed many of those with sort of security champions? Is the conceptual, like security champions, is the implementation, but what you're trying to do is achieve proximity between the security practice and the development practice? Is that a decent representation of it?

[00:09:52] Rinki Sethi: I liked the way you articulated that. I think the proximity is such an important thing, and that's what you're trying to get. It's the closer the two are, the more effective security is going to be for the company. I think proximity is one way of talking about it.

The other way is, like in Twitter, we talk about embedded security, the same type of thing. Or, again, champions I think takes different forms depending on what company or what team you're talking to. But it can also be that you're actually building security into engineering. So I think it could be an actual full integration and I think you're getting as close to that as you can in building that champions program so that you can scale.

[00:10:30] Guy Podjarny: For security champions, what do you feel are the core tenants? When you say security champions program, what does that mean to you?

[00:10:37] Rinki Sethi: Yeah. I've failed at this actually more than once to know kind of what works and what doesn't work. What doesn't work is that you say, “I'm going to go identify security champions.” You tell them they're responsible for security. They're not trained. You don't have a long term strategy for how they stay trained. There's no accountability as to what you're expecting from them. Or that they're the sole representation for that business or for that development team, and it might even create a bottleneck in ways that you don't want it to. So those are things that don't work.

I think when I think about security champions and successful models, it's either where out of engineering or development teams you actually identify several folks that are responsible for security. You build a scorecard that they are responsible for that development team that actually shows here are the things that we're doing to ensure that we're securing our product in the right way or our feature in the right way. There's some kind of go back into the central security organization, and we're also providing them with the latest and greatest in training. If the security team is responsible for building tooling and things like that, those security champions are helping you go and drive adoption. So I think security champions have to be kind of within the engineering organizations they can't be sitting outside of it, and they're really driving security, and you're holding them. There's some kind of accountability model and pull back to the security team.

[00:12:04] Guy Podjarny: The security champions in this model have official time allocated to this from their management. How do you kind of tee them up for success around being that representative for security within their daily jobs?

[00:12:16] Rinki Sethi: They have to be tied back to goals. There has to be a percent of job time dedicated to it. If it's just extracurricular work, it's never going to work. That was actually one of the failures I had at Intuit is we didn't have the buy in from the top. I was working the program grounds up, and it just wasn't the right way to do it. As soon as we went to the top and said, “Okay. GM of this business or engineering head of this business, we want you to help us make this a part of the goals for the security champions.” As soon as that flip happened, you saw a different accountability model, a different engagement back with the security organization to help craft what the model would even look like. So I think you have to have this as carved out as part of an individual's goals.

[00:12:55] Guy Podjarny: Yeah. No, it makes a lot of sense. You talk about pull back to the security organization, how do you see the delineation between those? What's the responsibility of the security team versus what's the responsibility of these security champions?

[00:13:08] Rinki Sethi: Yeah. That’s an interesting question. Security is so nuanced, right? It's like there's not one size for all. When you talk about finance teams and other teams, it's pretty much similar structures, you have an accounting team, and you have a controller team, and you know what to expect. Security is nuanced company to company, but I think the ideal model is security builds the standards. Security should be building and owning the services. I think that team drives adoption. I think in many cases where security doesn't have the capabilities to build services, then you might be asking engineering teams to do that or be building a central team within engineering to build the right services for security.

I think it's ensuring that there's like a real back and forth feedback channel between the two teams where if a tool is not working, there's feedback back, so you can improve that service or tool from a security perspective, so that the teams are driving adoption and are truly reducing security risk. I also think where it works well is where security's plugged into like development and understands their customer’s engineering in this case, and that they're really feeling the pain of their customer as well. I think that what we talked about what you said, the proximity is so important.

[00:14:16] Guy Podjarny: Yeah. I mean, it's hard. It's hard to sort of define those, but I like the general guidelines that you're describing. You talked about how it's a failing if you don't train them or you don't kind of equip them to do it. What are some suggestions of how can you help beyond kind of ensuring their management is aligned from a security team perspective? What type of training or enablement do you need to give these security champions to make them successful?

[00:14:41] Rinki Sethi: If you're launching a security champions program, again, this was another failure I had. It was really short-term thinking in terms of what training content I was going to have available and what I thought they needed. I was wrong on both fronts. I didn't test it out properly with the engineering team. I think having a pilot group that you actually test out initially to say that, “Okay, I'm launching this security champions program.” Engineering teams are not shy of giving feedback, and so they will help you shape the program in the right way.

As soon as I engaged with engineering teams, and this was iteration number two after failing the first time, what happened the first time was developed content for what I thought was six months of content for training, and it had different modules, whether it was ensuring you had the right unit tests or whether it was training them on security standards or even more specific training to different languages and so forth. When I developed that, the engineers were able to consume it in less than two months, and they were like hungry for what's next and how do I apply this. So what I realized is you need to have almost 12 to 18 months of training content. It needs to be very applicable to their role, but there has to be a combination of, here's practices, standards that you're training them on that your company is actually – It’s not just generic, like off the shelf training. It was very specific to the company, what they should be doing.

But then there is some more future-looking things as well. Developers were craving things like SAMs trainings and certifications, and they almost saw that as an incentive to continue because they were starting to get security under their belt, in addition to their core engineering role. That was another thing. I think the incentive structure we tried to gamify. The champions program, that actually was – It didn't work, and we realized that the incentives were in them starting to get like some kind of badge of honor of, “I'm a security person.” That badge of honor was not a gamified approach. They actually wanted certifications and wanted security training.

[00:16:36] Guy Podjarny:  I think that makes a lot of sense. In a recent roundtable I was on, we got to an interesting perspective around the delineation between developer security training and the training of these security champions. Not just from an investment but from motivations. It felt like the – It sounds very similar to what you're talking about, which is for a lot of the statements about what developers want, maybe they conflate the two together. But in practice, there's the developers that just want to get back to their day job. So for them, you might want minimalist sort of security, and you might need gamification to lure them in.

But then the security champions, they're security curious. They're hungry for more. So for them, you actually want to give them high engagement, high depth. But they’re still engineers. They're still developers, so you have to keep that in mind. I think it's a similar perspective to what you're describing, right?

[00:17:24] Rinki Sethi: That's exactly right. Yeah, it’s exactly right. I think I was more gearing towards like what the champions are looking for. But I think in broader engineering teams, I get into debates about the carrot and the stick approach. I think whether you call it the carrot or the stick, I think recognizing developers that are doing the right thing, whether you gamify that or not. But then you have to hold those that are not accountable as well, so there needs to be a combined approach. Whether you want to call that carrot or stick or you want to call it accountability and recognition, I think that's a really important concept more broadly.

[00:17:54] Guy Podjarny:  Yeah. It’s amazing how important naming is. Indeed, accountability and recognition are both good terms, while a stick, it sounds like – Well, actually even a carrot sometimes sounds bad, maybe sort of like a little condescending. But then recognition and accountability are actually really, really good words. So I definitely am going to adopt to those.

Before we talked about the journey, we actually stopped just shy of Twitter. So when you're at Twitter, and I recognize you're only there for about six months, what are you looking to apply then from this sort of champions or what – Is there already a champions program running?

[00:18:28] Rinki Sethi: Yeah. We actually have a pretty large champions program at Twitter already when I joined. I think they're really good at training and ensuring that if there's something, a new standard, like ensuring people are aware of it. It’s the largest champions program I've seen so far that I've worked with. But I think there's one thing that's still missing that we have a little bit kind of a bridge to build is that proximity to engineering and really like not just training but how are we integrating security into everything they do because right now we're making it - it’s really hard for engineers and developers to do security. There's a lot of manual processes. If they want to introduce a new product or a new feature, that go through 10 security reviews; one for privacy, one for security, and then so many other ones.

So I think the more you we can automate, the closer we get to them to understand like, “Wow, this is not going to help us innovate quickly.” So there's a lot more work we need to do. Whether it's champions or building, I think for us and even from a central security perspective, we're starting to think about automation. We're starting to think about whether it’s the right tooling and services.

I mean, one of the products we're looking at is Snyk because of that. It’s how can we get closer to the engineers so that they – It's not like I don't want to say that they don't need to worry about security, but that security's enabling them to move faster, rather than slowing them down. So I think there's still more work we need to do on that front.

[00:19:52] Guy Podjarny: Well, there's always things to improve on it. Let me actually dig a little bit on this front and talk about skills and teams. So you've sort of been in the industry for a while. How have you seen the skills required in a product security team change if they have at all? I mean, if you harken back, whatever, 5, 10 years of sort of what you've sort of seen there back or even like at Intuit versus maybe what do you see today and what you're driving in Twitter. What would you look for in someone joining or someone you're hiring into your product security organization?

[00:20:28] Rinki Sethi: Yeah. One of the transformations I had to lead at Intuit with the team, and it was like this -- Security's kind of moving towards you're an intake. Somebody tells you, “Okay, here's like the checklist or the security product that we're going to release.” You do a review, and you go back and tell them, “Here are the things you need to do to be able to move forward.” That model is so gone, and it doesn't work, and it makes security teams not respected. If there's product security folks that are listening to this podcast, Twitter is hiring. Ping me. But the product security space, there's so little talent in this space, and we need more.

I think the interesting thing is that it's people that can learn really quickly, that have knowledge in different areas of engineering, that can wear I think – this is the biggest one - it's people that can really sit in the shoes of the customer so that we can enable development teams. I think that's got to be the lens that we wear. These three things that I mentioned, plus having really strong engineering background, I think is so important. I think it's like an interesting mix of things to find in an individual. But I'm seeing that if you don't have those mix of things, you become very irrelevant quickly.

When I say that wearing the customer's shoes, that's when you can help the product teams figure out like what do they really need versus, “Oh, you need to insert a gate here and you need to check this box to move forward.” So I think also like really good product security folks. You're also thinking about how can security features enhance a product as well, and that's some of the thought process I think that goes through that. That as you're developing new products, as you're developing new features, enhancing it with security because you're seeing now there's a lot of products coming out in the social media space or platforms that are serving the public conversation.

There's innovating pretty quickly and coming up with new things, and there's all these new security and privacy implications, and that I think the world hasn't thought of as it relates to these new platforms. And I think that the more you have security and privacy plugged in and folks that are thinking about, “Hey, how could you drive innovation,” it makes your product better. So I think those are kind of the skills that product security expert needs to have.

[00:22:40] Guy Podjarny: Yeah, I love that. You talk about product security, an opportunity to provide value, not just reduce risk. It’s really around bringing that security expertise into the products’ features and capabilities and eventually top line in business success. I like that thinking. I see more and more kind of forward thinking security leaders embrace that approach, and think it fits the product security title quite well. Would you bias then – I know it's much more nuanced than that. But assuming to kind of roughly equal candidates, one with a stronger software engineering background but light on the security background versus one that's positive, do you do you buy software engineering? Or do you still bias for hiring security?

[00:23:19] Rinki Sethi: No. I bias towards software engineering. I think a security background is a plus if they're interested and passionate about security. A lot of the folks in product security have come from a software engineering background. I think it's the only way to be successful in that role, so I do bias towards that. I've also seen college new grads come in, again, who have a passion for security, who might not have all the experience in software engineering but can learn quickly and then really start providing that feedback. You see them looking at things with a fresh lens, so I do bias towards software engineering when it comes to product security because at the end of the day, your customer are – they’re software engineers.

[00:23:55] Guy Podjarny: Okay. Yeah, I love that. I think it's – Again, I'd kind of drawn an analogy to the DevOps world that moved from maybe more of the sys admins of IT backgrounds to maybe biasing in favor of platform building, and that’s the reason, that engineering. I think the security industry is going through something similar. How do you think about the security lever of like how tight do you tighten it or whatever the right way to think about it, based on the business context? I mean, if you think about being a security vendor, how do you balance the desire to run fast with the need to control risk or to keep things secure?

[00:24:31] Rinki Sethi: Security vendors are in an interesting position today. Especially when you think about security vendors that are in critical infrastructure or are considered critical infrastructure, the appetite for risk for certain companies are going to be more than others that you might be willing to take a hit on a security or privacy regulation, versus if your consumer company versus your security company. I think security companies don't have a choice.

I had a conversation where I was asked a question. In the moment, I had to answer. When I thought was the right time for a startup company in the security space to bring in a security person. I was like, “I think it needs to be one of the first five hires.” The reason I said that was, one, you have somebody that has a customer view very early on with you. Two, you’re building a security product. You have to think about security first and your appetite for risk. I think you might have to move a little slower because you're not willing to accept as many risks. I think that needs to be the balance.

I mean, we've heard about security breaches now and security vendors, and it's the one industry I think it becomes really hard is when critical infrastructure doesn't take security seriously. So I think I might be biased here but I feel like those that are in critical infrastructure need to – I think you lean towards more being risk averse.

[00:25:44] Guy Podjarny: Yeah. So on the flip side, if you come to a company where maybe they're not critical infrastructure, although you can argue Twitter today, it's such a part of our social fabric, you can potentially challenge that statement. But still, coming into Twitter, post-breach, what's your sense of how bridge-driven and sort of security prioritization in companies you've seen? I mean Twitter being one versus an actual internalization of the importance of security.

[00:26:13] Rinki Sethi: I mean, the last few companies I've been at, including Twitter, security and privacy is considered top risk to the company and is incredibly important and is a priority. So, I think there's no question about it, that it's hard when a company is so complex and big, that how do you ensure that security has a seat at the table? I think a lot of that has to do with the process you build and how, again, you get close with product and engineering teams to ensure you know early on that something new is coming out.

This goes back to the previous questions that we talked about, too, which is the skills for product security folks, right? If security can show value early on in terms of you’re now like making proposals that are actually going to generate business as well, security and privacy becomes such a strong strategic partner for the business, that it's going to be prioritized, and you're going to have a year. So I think there's a little bit of a balance that you have to prove yourself as an organization a little bit first, and then you will have that. It’s not just a risk decision but it's like, “Wow, this is actually bringing value.”

I think in certain areas, Twitter's like – They're chartering new territory. So I think that's where it becomes really difficult. When you're moving fast to go innovate and build new products in a space that hasn't been disrupted or it hasn't existed before, that's where it becomes really nuanced on the risk you're willing to take to go get it to market. Then maybe take some hit but then going and building it in afterwards.

[00:27:38] Guy Podjarny: Yeah, coming back to like the product security definition as well of representing business value. Do you see that as a leader attribute? Like as a leader, you need to think about it? Do you think all the people in your security organization should think about it? Should you almost like imagine the marketing message you would say around the security work you're doing like, like you might for functionality that you would do? Do you see that as a tenet we should permeate through the security org about understanding how to communicate the value to your customers and help the business?

[00:28:09] Rinki Sethi: I think it's really important, right? You're always going to have security engineers that are might not want to communicate, and they're in certain roles where they don't need to be in front of other teams, because they're working on some kind of tooling or development. I think security on the product security side, absolutely. Product security folks, they have so many ideas. They’re constantly thinking about the product. They're thinking about new features. I think the difference between the leader and the team will generally be there'll be a lot of idea generators in the team. I think the leader is the one that's going to be like, “These are the few that we should go and prioritize. These are the ones we should go focus on.” Then how do we share those wins with an organization that this actually came from this team and enhance the product and potentially brought in more revenue. Or we won over competitors because we went, and we were partnering early on.

[00:28:56] Guy Podjarny: Help the business understand the value of security. Don't just sort of think, “Hey, be there in a security team, be disgruntled, and sort of be annoyed that the business doesn’t value you.” Think about it. Help it out. Communicate. How can your security value, alongside the risk reduction, actually provide business value at the leadership as you point out around focusing on what matters most but even sort of thinking about it within the ranks, although granted not everybody's – That’s true for software engineers as well. Not everybody loves communicating and kind of marketing.

Well, I feel there's all these different questions I want to ask you. I think I'll squeeze in two more. I know you've been on the Women in Cybersecurity board. Just kind of using the stage a little bit, if you're thinking, I kind of have these two audiences, there might be sort of women listening, looking to get into security, looking to grow in security, do you have any tips for them? But also similarly, for all us guys on it, is there any tip of what we should start or stop doing to help encourage more diversity in this industry?

[00:29:56] Rinki Sethi: This is an area, Guy, you know I'm super passionate about. I just tweeted about this. My thinking around this topic evolves to I'm learning as well. But one of the things I'm realizing is I think we need to recruit more from colleges. When you look at computer science classes now, not all computer science classes – in fact, I just talked to a student that told me that she was the only girl in one of her computer science classes, and she was telling me that, “Hey, I can't even get my thoughts across because the guys won't let me talk on a project. I’ve got good ideas and things like that.”

But kind of if you look overall, the number of women and men in computer science programs, there's a lot of programs that have 50/50. But somehow, then when you go look at engineering teams, and especially cybersecurity teams, there's like a huge issue, and I think we need to – What I tweeted was we need to stop trying to get more women into our company by stealing from another company because we're not really helping with like improving the pipeline. So it's almost like we need to make commitment as an industry that we're going to go bring in X number of more talent from colleges. I think that will introduce more diversity. That will introduce more women into cybersecurity.

But also, maybe from other fields where there's expertise like marketing, maybe those are folks that can help with security culture. There's I think a lot more work that we need to do. I always say this. It's a fact that women don't take as many risks as men. If we don't feel qualified for a role, we won't apply, whereas someone who's not qualified for a role for men will apply. I think women need to take risks. Go out there. Reach out to folks and leaders. I bet you that you would get like a reply back from a security leader, looking for talent in the security space. We need more women in the field. I think we as leaders need to go and recruit more from colleges and also invest in younger – in kids.

Because I see my daughter who's also just turned 13 a couple days ago. This is when they're defining themselves. They don't define themselves when they're in ninth grade or in high school. They start defining themselves when they're at this age, and they're not introduced to technology in the right ways or programming, nor cybersecurity or privacy. I think it's really important at this age that they get introduced to it, so then we have more girls entering colleges. I think anything people can do to teach more women, teach more girls, bring more women into the industry to increase the pipeline is going to be super critical.

[00:32:14] Guy Podjarny: Yeah. That really resonates with me. I think it's really great. We have to actually grow the community. It's not just about sort of steal all the sort of the diverse candidates and sort of women into your company. It’s about help fix the community. I think I rarely do sort of team plugs over here, but I'm just really proud of this, with the leader of our SE Team at Snyk was we kind of woke up one morning and realized we have all men in our sales engineering team. We talked about it. We set out to hire. It was really hard to find sort of qualified and experienced women in it, and he started this sort of internship program to bring women that are – They might have come from backgrounds. They weren't obviously qualified to it, an associate program, and that's been super successful. The team is far more diverse right now I don't know the exact statistics.

Then we doubled down on it and we did a whole program around mothers returning from maternity leave, kind of a return to work, people that – Not maternity leave but rather that might have been out of the career ladder for a bunch of years, coming into it. It’s an amazing, amazing kind of women join the company through it. So I'm sort of super proud of it. It’s just from – I had nothing to do with it. It's all kind of the team initiated inside of it, but just was so great to see it.

[00:33:26] Rinki Sethi: I would love to hear more about that. I mean, you need to share that in terms of that internship program and what made it successful because I think there's an analogy on the cybersecurity side on you might take some hits in the short term because they're not going to be productive right off the ground. But here's the long-term benefits of it, and here's how you got them up to speed. I would be super interested in hearing kind of that story. That's really cool.

[00:33:50] Guy Podjarny: Thanks. I agree with you. We absolutely should be publishing these details. Rinki, this has been amazing. This is like a whole kind of treasure chest of great advice. One last question I'd like to ask every guest coming on board. So if you take out your crystal ball and you think someone doing your job five years from now, what do you think would be most different about their reality?

[00:34:13] Rinki Sethi: I think one of the big shifts that I'm seeing and I see it with Snyk, I see it with LevelOps, I’ve seen it with now more companies that are coming out, there's this desire to make engineering lives easier and more engineering companies selling security to engineers, right? I think that model is going to go places. I've seen the success with Snyk. I've seen the success with other companies that do that. I think we're going to see the shift where engineering teams are going to start owning security more and more. So I think that's one thing that I see happening more in five years, especially when you're talking about large scale security engineering organizations.

On the dream side of it, I would say I'm waiting for the day where we work ourselves out of cybersecurity functions. This is what drives me and this is why I have passion around this is where security is part of the DNA of companies, period. Right? That's where I'd love to see things go, and I don't think that's the five-year crystal ball. I think that's a future crystal ball, but I hope that every security person out there is doing that for that reason that it's embedded within a company well understood in the DNA of a company.

[00:35:20] Guy Podjarny: That is definitely in kind of the right direction towards which we need to drive. Rinki, if somebody wants to join your team on Twitter or apply for a job or find you online, where should they reach out to you?

[00:35:32] Rinki Sethi: Ping me on Twitter. I'm @rinkisethi. DM me. My DMs are not restricted, so you can DM me or follow me, ping me, anyway. Or on LinkedIn.

[00:35:41] Guy Podjarny: Perfect. Yeah, I definitely encourage folks to do it. Rinki, thanks a lot for coming on. As I said, great, great, great insights.

[00:35:47] Rinki Sethi: Thanks, Guy.

[00:35:48] Guy Podjarny: Thanks, everybody, for tuning in, and I hope you join us for the next one.

[END OF INTERVIEW]

[00:35:56] ANNOUNCER: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit the securedeveloper.com. If you'd like to be a guest on the show or get involved in the community, find us on Twitter at @devseccon. Don't forget to leave us a review on iTunes if you enjoyed today's episode.

Bye for now.

[END]