Leif Dreizler -- Tactical tips to shift engineering right

0:00Chris RomeoLeif Dreizler is the manager of the product security team at Segment. Leif got his start in the security industry at Redspin doing security consulting work and was later an early employee at Bugcrowd. He helps organize the Bay Area OWASP chapter, the LocoMocoSec conference, and the AppSec California conference. Leif caught our attention when he published an article called Shifting Engineering Right: What Security Engineers Can Learn from DevSecOps. In this interview, we focus in on the tactical tips and takeaways from the article, or how you as a security person can shift engineering right. We hope you enjoy this conversation with Leif Dreizler. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length, We believe in hands-on experiments, builder and breaker style, that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey. I'm also joined today by Robert Hurlbut. Hey Robert.

1:45Robert HurlbutHey Chris. Yeah, Robert Hurlbut, Threat Modeling Architect. Good to be here.

1:49Chris RomeoWe're going to talk about an article that I know a number of people, a number of our listeners, a number of people across the industry have seen, and that article is called Shifting Engineering Right: What Security Engineers Can Learn from DevSecOps. The good news is we happen to have the author of this article, Leif Dreizler, who's with us today. Now, Leif, we always jump right into the security origin story, not even giving you a second to catch your breath. Our audience is sitting on the edge of their seats going, how did Leif Dreizler get started in this crazy world we call application security?

2:23Leif DreizlerWell, first off, thanks for having me as a guest on the show. I really appreciate the kind words about the article. you have me on here today. And so with that, yeah, I don't know if there's really like a specific story that got me kicked off in security, but one of my earlier memories of being interested in security was in high school. And when I was in high school, one of the most popular phones was the Motorola Razr and some of the other variations of that. And I got really into learning about this phone and I was on a couple different forums. One of them was Howard Forums, another one was Hack the Razr. And I learned that through manipulating some of the settings and calling into some of the automated Verizon systems, you were actually able to activate the internet feature on your phone, even though it wasn't part of your plan. And this was actually pretty easy to do. And I did this for all of my friends at the time. And so we were using this really terrible mobile browser because You know, you were using a non-smartphone screen to browse the web, but there were, there were some, some websites that like actually had formatted for 200 pixels horizontally to look at their sites. And that was pretty cool. And people thought it was cool. They could go on the internet and check the weather or sports scores or whatever. But I definitely took it a little bit further than I did on my friend's phones where I actually installed the stock Motorola firmware, which was a lot more performant and a lot nicer to look at than the kind of awful Verizon firmware that they tried to make all of their phones, regardless of the manufacturer, look the same, whether you had an LG or Motorola. And so I was using— I still remember the carrier, Vivo, which apparently is a very popular carrier in Brazil. And so I was using their firmware for a couple of years, and that just really got me interested in hacking stuff and Then I went to college, I studied computer science. From there, I got into security consulting, mostly focused on application security. And then after that, I actually joined Bugcrowd and was their first sales engineer. So I got some experience on the go-to-market side. And then after leaving Bugcrowd, I was an early member of the Segment security team and have been doing a mixture of application and product security. at Segment for the last 3 and a half years, and about 4 or 5 months ago, I actually became the manager of the product security team, so helping build out that functionality here at Segment. And at Segment, we loosely define application security as the tooling, training, and internal consulting to help developers write secure code autonomously. And then product security, we actually define as helping to design and build the security features of our product. And so it's much more like a traditional software engineering team. I know that the industry does not agree on what product security means, but for the context of this episode, I'm gonna pretend that everyone uses our definition.

5:31Chris RomeoIt's funny, I was watching a debate yesterday on the OWASP Slack about the definition of application security, and the one you just shared was better than what was being floated around. So curious, did you come— would you say you came to security the development side or from the system admin side, or what would, what would be kind of your— what would be your lineage?

5:53Leif DreizlerYeah, I mean, I kind of just got thrown into security consulting while I was still in college. And so, I mean, I was doing computer science, so I guess technically that is from the software development side, but I had never been a full-time software developer. You know, I had built tooling and stuff for my job, and I had obviously done projects and stuff for school, but I had never actually built something where if it broke, you know, it would really matter where you'd have customers that were upset or anything like that. So yeah, I guess I just kind of started in security. Like that was my first full-time job was as a security consultant doing web pen testing.

6:30Chris RomeoLet's jump into the article then. And I wanted to start by understanding the motivation behind the title of this. So Shifting Engineering Right: What Security Engineers Can Learn from DevSecOps. Why this title? What does it signify? What were you trying to get what were we trying to get into our brains when we read this title?

6:48Leif DreizlerSure. So I think that for a good blog or conference presentation title, you need that appropriate mix of clickbait and substance. Because if you have a title that's too boring, you know, you could have a really good article, but people are going to see it on Twitter or Hacker News or whatever, and they'll just be like, whatever, that doesn't sound interesting. But then if you make it too clickbaity, people are like, that, that just seems like some marketing nonsense. Like, I'm not going to read that either. And so I think naturally, you know, when somebody comes up with something, somebody else is going to riff and come up with a way to tweak it and make it the opposite. And so, you know, you've heard of shifting left. I was like, this is kind of like shifting right. This is the opposite. And I thought that people would see that and be interested enough to read more. And then the second half of the title is like the more vanilla title that actually, you know, tells you what the article's about. And so really what this article is about is I think there's been a lot of focus on, as part of shifting left, on getting engineers to learn things about security. And I think that's great. I think that that is really the way that we move forward as an industry is having engineers that are knowledgeable about security and are making good decisions on their own. We're way past the days where engineering could even dream of reviewing everything on its way out the door. Furthermore, there's no way that security people could be experts on all of the different technologies that a business is using. And it would be so slow. You wouldn't be, you wouldn't be competitive. But at the same time, I think part of DevSecOps should also be about security engineers learning about engineering. This shouldn't just be a one-way transfer of knowledge. And so if we're talking about, you know, how do we shift security left? So it's earlier in the process. I think part of it should also be, how do we do the opposite? How do we shift software engineering into security engineering.

8:37Chris RomeoThat's certainly what caught my attention when I started— when I saw this article for the first time. First, the title was great because it stopped and made me think for a second, wait, shifting engineering right? What do they mean by that? And so that caught my attention, not from a clickbait perspective, but really because I was just like, wow, that's like a twist on what we think we see with shifting security left, but there's some meaning behind this. I'm somebody who studies security culture and thinks about how do we get developers more excited about security and more into these things, but I've also, in the last year, been thinking a lot about how do we do exactly what you're talking about here? How do we walk a mile in their shoes instead of always saying, well, we're the security team, we have all the answers? I've got a quote that I pulled out that I thought was another good kind of early thing to discuss, and so I'm quoting you directly from the article. This article will focus on how to create a meaningful partnership between security and software engineers. And it got me thinking about like, first of all, why do we need to create a meaningful partnership and what's the value proposition or the return on investment for both sides by having this relationship?

9:44Robert HurlbutSure.

9:46Leif DreizlerSo I think that once a project gets to any meaningful sort of size in the context of your organization, it's naturally going to span more than one team. Sure, there are opportunities where, you know, one team can really make a really big impact, but the big projects that you truly think of as changing your business or changing the way that your customers interact with even just a portion of your business typically require multiple teams to agree on something and build something together and deliver it to your customers. And so I think that That's the value of having that partnership between security and engineering is if security is bought into what engineering is doing and understands how engineers actually build stuff, when you as a security person are reviewing something or providing feedback, you're gonna be much more likely to be able to provide feedback that actually makes sense. I think we've all heard stories of some security person coming in and saying like, Hey, you need to do X, Y, and Z, and they don't realize how much work that is. They don't realize that the effort to do this thing versus the benefit that it's providing is actually like not a good trade-off for the organization. And so I think the more that you know about other parts of the business, the better you are able to serve your customers because you understand what is important like throughout the org, not just your own organization. And then Going the other direction, I think if you have software engineers that understand and are bought into security being part of good software, they're gonna think about it the same way they think about other things they already care about, like reliability, ability to scale, things like that. If security can be seen in that same lens of like, hey, this is just a part of building good software, it's gonna be something that is more top of mind for for software engineers, and at the end of the day, they're the people that are building and maintaining a lot of this stuff. And so if they have a good impression, they wanna work with the security team, you're gonna end up with a more secure product, which hopefully is your goal as a security person, is to help your organization cultivate that type of thing.

12:03Chris RomeoYeah, it sounds, sounds like a really, like a security culture-focused kind of endgame is what you're describing, getting to this point where there's a lot of collaboration, but it's meaningful collaboration where there's respect from both sides of the table. And I think that's going to be a really powerful thing. Robert, I think you're going to lead us into this list of tactical tips. And I'll just stop for a second and remind people, we're just going to scratch the surface on this. Go read the article as well because there's a lot more depth and good stuff in there for you to take away. But Robert, why don't you take us through these tactical tips?

12:37Robert HurlbutSure, sure. So Leif, you have at the end of the article these tactical tips and takeaways. So just start off with lay a foundation. So what do you mean by that?

12:49Leif DreizlerYeah. So kind of the overarching point of the tactical tips and takeaways section at the end of the article is to try to provide people with some things that they could look back on, you know, a month down the road or, you know, a few weeks down the road or a few months down the road. And try to apply things from the article, like directly to their organization. Obviously, like your organization is going to be different. Some parts of it are going to be better, some parts may be worse. Luckily at Segment, we do have the benefit of having our company and engineering leadership very bought into security. I think that that is in part just a function of what our business does. Like, we're a B2B business, we sell to large enterprises, we sell to very security-conscious customers. And so that naturally makes security something that you need to invest in more heavily because otherwise, you know, your big customers are going to be like, we don't really trust you, so we're just not going to give you millions of dollars. But anyway, when you're laying a foundation as just like an individual contributor or maybe somebody who's not an executive, or even if you are an executive, honestly, try to just meet people and make friends within your company and learn about what people are working on. There isn't really a super easy way to measure the impact that this has, but anytime you hear about a project that somebody is working on that you think you can, you know, help shape in a more secure way is going to benefit your organization. And, you know, as much as the world has moved to, you know, like async communication and, you know, hopefully your organization is publishing more documents and trying to keep people informed. There's still a lot of things that are just going to happen in a meeting or in a Slack channel, or, you know, you wouldn't know about if you just didn't talk to this person. And so anytime that you have to give like an engineering training or to do a design review or a threat model or anything like that, use this as an opportunity to build a relationship with somebody because they might tell you something that is going to be interesting, or maybe they're working on something that, that you've done before. And that you can help them. Your company is paying both of you to do great things. And you can do that more effectively when you're working with other people. So if you have something like, we have an app called Donut that just like randomly pairs you up with people. That's a great way to meet people. Like I had a really great Donut conversation on Monday, and that led to me talking to somebody else that that person knew, and we were able to bidirectionally share some knowledge.

15:27Robert HurlbutVery cool. All right. Next one is use your knowledge to influence stakeholders. So tell us a little bit about that.

15:36Leif DreizlerSure. So once you know some people and, you know, maybe you're keeping an eye on your company's roadmap and kind of reviewing what other teams have said they're working on, look for opportunities to improve security along the way. It's a lot easier, you know, as most of the listeners know, to get security right from the start. But, you know, maybe there was something that was built before you were there. Maybe there was something that was built, you know, by an acquisition, or, you know, maybe there was just something that didn't go through whatever the normal process is, or maybe things have changed and you want to make some improvements. It's a lot easier to get a team to make changes to a system that they already have plans to change. And so if you hear that somebody in your company is interested in redoing— maybe it's parts of your authentication system. Okay, that's a great opportunity for your team to look at what the authentication system is doing right now. Maybe there's some things that don't really make sense or, you know, aren't a best practice. Try to incorporate these improvements to that team's work while they are already in the process of planning and making changes and, you know, pulling out parts and putting in new pieces. And then also, if there's anything that's like specifically a security feature that, you know, maybe a customer has asked for or You know, maybe it's something that's on their roadmap. You probably inherently as a security person have a decent feel for how product security features work or don't work. I know that when I'm logging into a new app and signing up for the first time or looking at 2FA or, you know, whatever, like I just kind of keep a mental note of what is a good experience and what is not a good experience. You know, I think that one recently that comes to mind is I was added to the beta for GitHub for their trusted devices, and they have a nice flow where you can add in your fingerprint from your MacBook. And now whenever I am asked to log into GitHub, you know, I don't have to put in my password, I don't have to put in my 2FA code, I just put my, my fingerprint on my computer and I'm logged in through my trusted device. Like, that's a very easy way to get up and running in an app. And it's like, if we were to add that to our app, you know, I would go look at their implementation. I know Okta also has this. I'd go take a look at their implementation. What are the things I like and don't like? And so, you know, having some of this feedback that you can give to a product manager is great. Like, product managers love listing what other apps do this well or don't do this well. And so—

18:12Robert HurlbutYeah.

18:13Leif Dreizleryou have a lot of knowledge that a lot of other people probably don't really think about, and so you should really bring that to the table when security features are being discussed.

18:22Robert HurlbutMakes sense. I like the part here about customer security questionnaires, you know, getting some feedback from customers and then relaying that to stakeholders as well from a security perspective. I really like that.

18:35Chris RomeoLeif, when you think stakeholders now, I'm curious, what's your definition? Are we just talking about people on the engineering team, product managers? Where do we Do executives fit into this? Like, what is a stakeholder?

18:48Leif DreizlerYeah, I think it can really be anybody that cares about your product, your project, or what you have to say about a project. I don't think that there's a specific role or, you know, person that, that is or is not a stakeholder. I would also consider a customer stakeholder too. So if they're, you know, if they've sent you a security questionnaire, that's like, do you support SCIM? It's like, okay, maybe that's something that we should look at building if if this is something that customers are starting to ask about. And so, yeah, I think stakeholder can really just be anybody who cares about what you're building.

19:17Robert HurlbutNext one is interesting. Fixing your first bug, start small. So tell us about that, fixing bugs.

19:25Leif DreizlerYeah, so as we touched on super briefly in the beginning, I had never been a software developer before I joined Segment's security organization. I certainly knew the basics of software development and you know, could build some things to solve problems, but I had never actually contributed to something that was customer-facing. And so one of my main goals when I joined Segment was I wanted to be significantly better at writing code. And the way that I got started doing this was I just looked at stuff that was in our bug bounty backlog that was, you know, maybe like a P3 or a P4 issue. Something that, you know, was worth fixing but not really top of mind for anybody. And I used this as a way to learn about our application. And generally, the engineers were more than happy to help review my pull requests, tell me what was good, what was not so good, you know, hey, did you consider this other part of the app where this thing is used? And I think that this is a really good opportunity for somebody that you know, isn't a super confident software developer and wants to get better is, you know, start by fixing some small stuff where you can look at other parts of the application and figure out, you know, what you should be doing and really take the time to understand like the full impact of your change, learn how the testing gets done, learn how CI works. Like there's that kind of just base level developer knowledge that you'll have to learn anytime you join a new company of just like How do I get something out the door in a safe manner? And fixing some bugs that probably won't get fixed otherwise is a good way to do that, and it'll build some goodwill with some engineering managers too.

21:15Chris RomeoSo I got a question about this because I'm curious to get your perspective. When I think about this, you know, I've worked in really large companies with gigantic engineering functions, and now I'm a part of my own startup. I wonder, is this— do you think other companies support this, or is this something that works because of Segment's culture in some way?

21:42Leif DreizlerI don't know that I have a diverse enough set of experiences to really answer that, but I think that at Segment, generally, there is a very open culture to people switching teams temporarily or permanently. there's a number of very important repositories that do have kind of a shared ownership between multiple teams that are contributing. And so I had never really thought about that before I wrote this. At Segment, it just seemed so natural. Like, I just joined and nobody said I couldn't do this and I did it and then people seemed okay with it. And so I just kept doing it. And then, you know, over time I just got better and learned how to, you know, do more things and definitely learned a ton from the software engineering org at Segment. And, but, you know, I think that maybe in a more siloed organization that would, would be difficult, but I think if your company isn't letting you do something, I think you really only have 2 options. You either convince them to let you do it or you go do something somewhere else, unfortunately. And I think that ideally you would be able to, you know, work with another team. Maybe it's something that you have to start out a little bit more formal. Another thing that I talk about in the article in depth is our embed process. And so maybe it's something where it's like, okay, you can't just jump to fixing a few small bugs. Maybe you have to go through some channels and do a temporary reassignment to another team or something like that. Like, I think you need to Be realistic with what is possible at your organization, but I would hope that most orgs would be encouraging to somebody who wants to learn more about a team that they're supposed to be partnering with.

23:36Chris RomeoYeah, I think it's a great idea. I think the principle is solid of saying, hey, anybody should be able to go pick up a bug and fix it. But I also think there are some big organizations, and I'm thinking financial organizations are not going to be as open to that. to just letting anybody get into their code. But it's a cultural thing. And to your point, maybe it's a formal job rotation that gets you the ability to operate at that level and be able to get in there and actually make code modifications because you've job rotated into a development role for 3 months or something. So I think it may just look different at different industries, different size companies, but the principle is sound. being able to fix a bug and push that code into production, having it go through pipelines and things like that'll change your whole impact. When you start telling developers in the future what they need to do, you'll be like, ah, I've been through this. Now I see why this is a challenge, why what I'm saying to them is a challenge.

24:39Leif DreizlerYeah, I think you need to just pitch it in that way of like, hey, I'm doing this, one, because I'm interested in it, and two, because I'm trying to be a better partner for your organization.

24:50Robert HurlbutYeah.

24:51Leif DreizlerAnd my hope is that an engineering manager would be receptive to that. Luckily, when I joined Segment, there was already like a very collaborative engineering and security culture, and that's something that has just continued to grow as like the 2 parts of the business have grown. Like, they've really grown up and matured together in a lot of ways. And so we, we have never had any problems pitching this kind of thing to engineering managers, but I hope that even if you're a trailblazer, it your organization that, you know, you've built some relationships, you know, go back to the LEIA Foundation, you know, some friendly engineering managers that would be willing to take a chance on this kind of thing. And I think that there is a very real benefit to them because you can say, you know, next time we're doing a design review or a threat model, like, I'm going to have a way better understanding of what's realistic and what the actual level of effort of this thing is that we're recommending.

25:42Chris RomeoYeah, and I'm about to offer some advice that I'm realizing I don't know that I should give this to the working population, but one of the mantras that I've always had my professional career against is sometimes it's better to ask for forgiveness than permission. And yes, it's gotten me in trouble at times, but it's also opened a lot of doors for me to fun things in my career.

26:02Leif DreizlerImplementer beware, I guess.

26:05Chris RomeoYes, please. Yeah, I should— standard legal disclaimer applies here.

26:09Robert HurlbutYeah, right. So speaking of software and fixing bugs and so forth, next one is actually also about leveling up your software engineering skills. So yeah, tell us about that and how, how someone could do that.

26:25Leif DreizlerSure. So, you know, maybe you're already a decent software developer or, you know, maybe you've gone through the Leif Dreizler School of Software Engineering and you've fixed some bugs and had other software engineers teach you what you should be doing, but make sure that you're also focusing on the stuff that is not code related. Coding is just one part of being a good software developer. You also need to figure out, you know, is this a well-written pull request summary? Is this really clear to whoever I'm tagging in to review this? Is the code commented well? Is the documentation updated? Engineers love reviewing things that are easy for them, and if you have done a good job documenting and testing your code and you've written a nice PR description, they're way more willing to help you because you've made their job a lot easier. And then also, these PR summaries do serve as like a, you know, a historic record. You know, maybe somebody in a year from now is looking through the git blame and they're like, why'd Leaf do this? This doesn't make any sense. And then hopefully they'll click on the PR summary and they'll see like, oh, this, you know, covers this weird edge case and here's the corresponding test. And they're like, oh yeah, that actually makes a lot of sense. Like, I didn't think about that. And so you should just think of your code not in the context of like, does this work? But more in the context of, is this going to be something that somebody else can understand? Like code is meant for a human to read. The compiler and the machines, they don't care what it looks like. Your goal should be writing something that somebody else that's a human can read. And so on top of that, What are some other things from this section? Oh yeah, definitely get good at measuring the success of what you've built. I think probably earlier in a program, there's going to be some things that are just like very obvious where you're like, okay, we need to build this and you don't really need to sell it. It's like, oh, we don't have 2FA, we need 2FA. But this is a great time to get in the habit of collecting metrics and learning the ways that product develop— or yeah, product managers think of their features. And so building that muscle is going to make it easier for you to get things built in the future. And so it's like, you know, what percentage had this thing before we started? Okay, maybe that's 0%. And then what percentage of our customers are using this, you know, 3 months afterwards? It's like, maybe it's 4%. Like, do we need to advertise this more within our platform? Is that similar to what our peers are seeing and we're actually like doing fine? Did you notify anybody that had requested this feature? You know, maybe you have a big customer that was like, hey, we want this. And maybe that was 6 months ago, but reaching back out to them and letting them know, it's like, hey, we actually built this thing that you did. And then if appropriate, like, does the sales and customer success team and you know, are they aware of this thing? Is this something that is actually going to make a difference when they're talking to certain customers? So yeah, all that stuff takes extra time, but it's going to make you much more successful if you like, you know, kind of close the loop on a lot of that stuff and make sure people actually know about what you've built. And that will allow you to start tackling bigger projects, you know, moving past fixing bugs and actually like developing brand new features of increasing size and complexity.

29:57Robert HurlbutDefinitely. I do like the part about, you know, see your features through past launch. Don't just build and leave. So I really like that. Stay with it, see what's happening, attend a postmortem. That's, that's, you know, that's what you learn, and not just software, but the whole lifecycle. So very cool.

30:20Leif DreizlerYeah, you're gonna break stuff eventually. And if you don't, then you're probably going a little bit too slow and, you know, maybe not working on ambitious enough projects. But yeah, you're gonna make mistakes and don't worry about it. Software breaks all the time. Think about all the times when companies have problems. It's like, yeah, you don't want to be too cavalier when you're like pushing changes and like you need to do effective testing, but In a lot of industries, it's not like that is that big of a deal. And like, obviously if you're like in the medical industry or something, it's like, maybe don't just YOLO some changes, but you know, if something is seldom used within your app and nobody's really going to get hurt, like it's okay to make some mistakes. Like everybody has messed something up in production after a few years as a software developer.

31:10Robert HurlbutAll right. Next you have embed with another team. So joining another team and learning from them, tell us about that.

31:18Leif DreizlerYeah, so some of my best experiences at Segment have actually come from embedding within another team. And that's not to say that, you know, I don't love the team that I work on. I really like our security team at Segment. I think we have an amazing security organization and culture. But as I mentioned earlier, one of the reasons why I joined Segment is because I wanted to get way better at writing software. And I have learned a tremendous amount from the various people that have been on the teams that I have embedded with. And so if you have the opportunity to do this and you're interested in learning more about software development as a security person, I would highly recommend either creating this opportunity for yourself or taking it if, if it is offered to you. And so this section of the takeaways and tips is really about, you know, how, how can you actually make this process successful? And so a couple of things that we've helped engineering teams build is we've helped them rebuild our authentication service. We also implemented SCIM, which is an RFC-defined set of REST endpoints that sit on top of an identity provider like Okta and allow the identity provider to manage provisioning and deprovisioning and group mapping. So the first day when you started a company, Your Okta account gets activated, you get put into this group at Segment, and you already have the permissions you need to do your job. It's a really awesome feature if you're in a— in the B2B space. Highly recommend implementing SCIM. But these were things that we were able to build in collaboration with software engineering teams. And the first feature that I actually embedded within another team, or tried to embed within another team, was 2-factor authentication. And ultimately the project was very successful, but it was more of a relay race where I did the backend and then somebody else did the, the like frontend of the project. And I went to a couple standups and like people were reviewing my PRs, but it wasn't really the same as an embed. And so if you have an opportunity to do this, I would say really try to embrace the other team's culture and practices. And so If you can have a recurring one-on-one with the manager, definitely do that. Ask if there's, you know, a Jira board or planning docs or anything that you can review before joining the team so that, you know, you are less of a burden to them. You know, anytime somebody joins a team, like, they just don't know a bunch of things that, you know, somebody needs to help them figure out. And so if you can reduce that and show up prepared, that obviously makes a very good impression. If they have some Slack channels for you to join, join those. Go to their planning meetings, go to their demo meetings, participate in standup. If they invite you to any social events, you know, try to go to those too, if it makes sense. I got invited to go-karts once by another team and then I actually won. So I don't know if they would invite me back, but definitely try to do that because at the end of the day, like, these are people at your company, like They want to work with people that they like. And so if you can show up and do a good job and build some good relationships, you're going to have more opportunities to, to work with them in the future. And then kind of the last part of this section is don't just embed as a security person and, you know, do all the security stuff for them. Like, you're there to learn about what they do and they're learn— they're there to learn from you as well. And so If you have to do a design review or a threat model or whatever for this feature, make sure that you're not the person from security who's leading this. Go through it from the perspective of a developer and bring one of the other developers or 2 of the other developers with you and think about ways that this process could be improved for the consumer. And when you go in with that lens, like, you'll think about things not from your typical view of like, okay, I'm the security person leading this design review. You're thinking about it from the process of the developer, and you should be thinking, you know, how can I make this more efficient? How can I make this something that's easier for the developers to do while still maintaining like the same level of quality? And you'll just look at it from another perspective that will help you create a better experience for the parts of your organization that you're supposed to be serving.

35:50Robert HurlbutOkay, makes sense. And so finally, the last tip you have is reflect and share, and you start with build empathy. But, but tell us about that.

36:00Leif DreizlerYeah, so I think that one of the biggest takeaways from embedding within another team is just learning how other parts of the business work. As a security person, we're frequently brought in to try to help keep the business safe, but it really is not our sole responsibility. Ultimately, it is up to every person at the company to keep the company safe. Security is obviously there to help. You know, we're providing training, we're providing tooling, but at the end of the day, you know, there's tons of other things that, that can go wrong that, that we might not be a part of, even outside of engineering. And I think that like one of my big pet peeves is like, oh, Like, don't click on links. It's like, people have to click on links. Like, people send each other PDFs, people send each other to look at. It's like nothing would get done if your business was not allowed to open documents and click on links. And I think that that kind of mindset a lot of times, you know, comes from like a lack of empathy for like what this person's job is. It's like, you can't tell somebody in procurement not to open PDFs. like their whole job is vendors sending them PDFs. That's not practical advice. And as a security person, I think you've been— you get a huge benefit by, by being practical because people want to work with you because you show them that you understand what they're doing and you try to build a system that allows them to work safely and efficiently. And if your organization is one link click away from getting destroyed, that is not the fault of somebody working in procurement or recruiting. Uh, that is the fault of your security and IT program and potentially your executives. If you're underfunded or whatever, it's like, that's not necessarily your fault, but, um, you should not be like one PDF click away from your whole org collapsing.

38:02Chris RomeoI think that needs to go on a sticker or a t-shirt or something like one click away from total collapse.

38:10Leif DreizlerYeah. And then once you understand more about these other parts of the business, teach it to other people on your team and document it. You know, maybe this team has welcomed you into their, their team for a quarter. Try to make it so that, you know, somebody else from your, your team can learn, I don't know, maybe a third of what you did without any effort from that other team. Uh, it's not going to scale if you're like, okay, well, you know, every security person, you just have to rotate to this team and they train you and then you come back and then now you you're actually good at your job. Try to document like what you've learned, try to share with your team, like different things that you think could be applied to the way that you do work, or try to improve processes for how you interact with these other teams to make things safer and more efficient. And that will help make your whole team have a better relationship with people outside of your team.

39:05Chris RomeoSo what's the importance of empathy then? Like you mentioned that kind of a little bit at the beginning of this section, but I wanna circle back because I think this is a concept that's huge, and it's something that we've not done a very good job in security in general, and I'm including myself in that collection of our entire industry. We just haven't done a very good job about recognizing the depth of things that we're asking other groups to do. And so from your perspective, what's the importance of that? What's the benefit of really getting to that stage? Sounds like that, you're pretty close, if you're not there now, to that. How does that change your— when you come calling on development and ask for something, how is that different now?

39:49Leif DreizlerYeah, I think that it, it makes the relationship way less combative because you're starting from a point that is hopefully very reasonable. And you've already spent time as a security person trying to think of like, hey, how can we accomplish this thing? And it's not like, hey, how can we stop this bad thing from happening? It's like, how can we allow these developers to do something that on the surface might seem a little bit risky, but how do we allow them to do that quickly and safely? And so I think it just completely changes the way that security people approach problems. And it's naturally gonna make you more collaborative if you understand what these other teams have to do every day and what they go through. And it's easy as an outsider to be like, oh, just you know, do this thing, just patch, you know, whatever the example is. And then, but after you have actually had to do that work, a lot of times you'll realize like, actually, it isn't as easy as just like, you know, fix this bug. It's like, oh, that seems like such a quick fix. Like, you'll realize that nothing is a quick fix. Segment has a very efficient developer organization and has overall very good developer tooling. You know, a lot of our repos, the tests run in like 3 to 4 minutes, you merge to the main branch, and then it gets deployed to production automatically. And, you know, that's something that can be out to customers within 10 minutes. But, you know, how long does it take you to figure out what those few lines are that you need to change, make sure that the tests capture it, make sure that somebody reviews the pull request, they actually come up with a better way for you to do it? You know, it ends up taking like a few hours. And maybe like 3 years ago, I would have been like, oh, this seems like so fast. Like, why hasn't somebody done this yet? And it was like, they actually have a lot of other stuff to do. And it's actually not that fast.

41:43Chris RomeoYeah, I think there's a lot, a lot for all of us to learn from this, from this kind of back and forth between the experiences that you've had.

41:54Robert HurlbutYeah.

41:55Leif DreizlerAnd I think that this applies not just to security and software engineering and the blog obviously focuses on that because that's been my experience. Like I'm a security engineer working with software developers, but I think this really applies to any part of security working with another part of the organization. It's like, maybe you're in GRC and you're on the third-party risk side. It's like, okay, how much do you actually know about the procurement process? Or maybe you're helping people answer security questionnaires. It's like, how much do you know about the go-to-market process? Like security is generally in some sort of like support-ish type role for other parts of the organization. And the more you know about those other parts of the org, the more effective you're going to be at being able to support them. And in the context of engineering, that's frequently fixing stuff or building security features or whatever. And you're going to be able to recommend much more practical approaches, and hopefully they'll eventually see you as a resource for a lot of things, even if it's outside of security. Like, our cloud security team gets called all the time to help consult on things just because they're really good at AWS. Even outside, like, it's not like they just know the security stuff. Like, you can't be a good cloud sec person if you don't know more than just the security features of AWS. Like, you actually need to understand, like, how things are built in the cloud. And I think being able to bring that same approach to a design review is like, if you have built more software and you've helped implement software, it's gonna make you— it's gonna make it easier for you to provide good feedback as part of a design review or a threat model in the future.

43:36Chris RomeoYou've definitely given us lots of additional things to think about as we look at our own programs and say, how does security and development collaborate together? And, you know, a lot of things to kind of measure against, and even some great guidance for changes you can make to try and, you know, shift engineering right. We're coming towards the end of our time here, Lief, and I'd love to get your perspective from What's your key takeaway for our audience? What's a call to action you want to leave them with? And I'm going to steal the easy one, which is go read the blog post. So that one's off the table now. So what's, what's your key takeaway for our audience?

44:19Leif DreizlerSure. I actually think it's, it's pretty similar to one of my recent points of just learn as much as you can about whatever part of your organization you interact with the most. Because the next time you ask them to go do something, the more you know about their day-to-day and how things run for them, the more likely you're going to be able to come up with something that they hear and they're like, actually, that's not that much work. And it won't be that much work because you've put a lot of work into figuring out what the right thing is. And then if you learn things from people, make sure that you recognize them. I've learned a ton from Segment's enterprise security organ— or sorry, enterprise software organization. And I definitely would not have gotten to where I'm at today without all the help and guidance that they've provided to me over the years.

45:12Robert HurlbutAwesome.

45:14Leif DreizlerLeif, thank you so much for taking the time to be with us and with our audience here to share this wisdom that you've accumulated. And we look forward to an opportunity to speak again in the future about something else.

45:25Chris Romeorelated to application security.

45:26Leif DreizlerSo thanks for the time. Awesome. Thanks again for having me. I really enjoyed the conversation.

45:32Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @Robert Hurlbut. Remember, security is a journey, not a destination.