Talking the language of business: Translating security into dollars with Terry O’Daniel at Amplitude

[00:00:00] Terry O'Daniel: I think at the end of the day, risk quantification. Is not very sexy. I understand. But, we tie ourselves in knots in security, you know, doing this sort of interpretive dance for the board of red, yellow, green, and here's what it means. And bib boo and businesses don't run on interpretive dance. They run on dollars. And until we can come to the table like grownups with the rest of the grownups running our function and saying, here's the risk in dollars, here's the investment in dollars, here's the risk mitigation we're gonna realize in dollars. that's the key, right? We have to be able to talk the language of business to be successful as, and be taken seriously as business partners.

[00:00:37] Tim Chase: Welcome to Code to Cloud. I'm your host, Tim Chase, global Field, CISO at Lacework. Today on the show I'm speaking with Amplitude's, acting Head of Security. Terry O' Daniel Amplitude is a product analytics platform that helps businesses track visitors with the help of collaborative and analytics. Terry joined the company in October of 2022 as head of G R C and prior to Amplitude, he led G R C within infrastructure engineering at Instacart. Terry, I. Welcome to the show.

[00:01:07] Terry O'Daniel: Hey, thanks so much, Tim. Thanks for having me here. 

[00:01:09] Fade out theme song

[00:01:09] Terry O'Daniel: Now let's get right into it. we're gonna start with a hot take.when you talk about DevSecOps, you have referred to it as the Failed Promise of DevSecOps. so, what do you mean by the failed promise of DevSecOps?

[00:01:22] Terry O'Daniel: Thank you for asking. Such a, fun pointed question upfront, Tim. my challenge here is that, you know, I, I come from an ops, background myself. I've been an operational engineer and worked in production, engineering teams, et cetera, for a long time, I think one of the biggest challenges we have in. The general move towards shifting left, which is theoretically what DevSecOps should be about, is I see a lot of nodding heads, aligning on the shared goal, and that's good. What I don't see a lot is actually turning the mechanics of integrated testing at every step of the SDLC and shared goals. I think those are two of the elements of DevSecOps that, perhaps because teams at companies in the, the, in the growing markets, early public companies, even startups, maybe that's something that, that isn't seen. They haven't seen the value unlocked there. but I think that's one of the big challenges is if we say DevSecOps inherently means. Catching problems earlier, correcting them faster, and not having security show up at the 11th hour and saying, hold on, don't release that. There's some issues. I think we haven't necessarily done the work, and the work involves getting those shared goals, getting that alignment from the top, from engineering leadership all the way down. getting the space on roadmaps to actually prioritize building out these patterns that we want to implement. And then, and then doing the tough work of saying, There's a tax. There's a tax that's required in actually moving left. Shifting left involves having smaller pieces and smaller interruptions more frequently. In, in the worst case, rather than having a single showstopping event at the end. And that's where I say in most of the companies I've worked at, over the past seven years or so, I haven't seen DevSecOps materialize into that model that actually gave a measurable outcome for the distance. So that's where I start when I say something that's perhaps a little spicy, like. The overall industry, 10 of DevSecOps hasn't been realized across most of the smaller SaaS companies that really have the opportunity to make an invest in and see the outcome.

[00:03:31] Tim Chase: At a high level, like why do you think that is? Like, I, I agree with you. I talk to a lot of customers and a lot of prospects and it's kind of the same way. You know, I still hear we're in the process of. moving to DevOps. Not everybody is there. I mean, the larger organizations, definitely they're a forever transformation, I feel like. But the ones that are the most successful probably are the smaller ones that maybe are more cloud native and they start that way. But, you know, if, if they started out one way in Waterfall or Agile or whatever they happen to be, and then they're moving to DevOps, right? Like, why is it really hard to make that transition? Do you think it's like one particular thing, or is it a combination of everything you just said?

[00:04:12] Terry O'Daniel: Well, I, I think, let's start with the place of alignment, right? We agreed that the industry sees the value in this. We agreed that the industry understands that shifting left is the ideal. I don't think anyone standing up and saying, hold on, shift left is the wrong pattern. So that's the good piece, right? we've fostered that agreement. And over the past decade or so, I do think the culture with insecurity has changed. Maybe one factor that has also worked in our favor is, you know, I think 10 or 15 years ago, if you said the modern CISO should be aligned with engineering, the modern CISO should be an engineer by training. the vast bulk of the modern CISO's work is technical work. We, we don't have to have that argument. I think the industry has sort of moved in that direction for us and maybe that buys us a lot of credibility in the movement towards DevSecOps. So why hasn't it worked then to, I would answer that question by saying a lot of it comes down to shared goals, right? It the best of times it is very difficult to get dev teams to put goals around security on their, their roadmap. Right? It is seen well, I think we still treat security as a. Necessary evil attacks that has to be paid and devs are somewhat rewarded for you know, staying under the radar when it comes to security, as opposed to what we really need is we really need them to be shifting left with us. We need them to drive us to shift left. So I would say on one hand, every time security does pull the emergency brake and say, hold on, there's a problem. It happens. It happens, but. That's a huge learning opportunity. Right. And I dunno that we do enough RCA looking in the mirror and saying, all right, that was really ugly to catch that at the 11th hour. What can we do to catch it at the 10th hour next time? And, and just build a roadmap for the, the process over time. So I think that's some of it. I also think there's a, well there's a natural tension right in, in software engineering between speed and quality. I think some of it comes down to folks background, their experiences, what they've seen successful at, various companies. at Amplitude we have a very clear direction. From the top, the top all the way down. We understand that one of the best predictors of software quality and the improvement of software overall for a SaaS company like us. Is the speed of releases. If we can release fast, that's, that's the core of Agile, right? If we can release fast, we can get customer feedback fast and we can build that feedback loop. And I think the challenge is at a certain point that emphasis on speed appears to be in conflict with the desire for quality, which is what I would call a software engineering function driving towards. one, one of the reasons I'm at Amplitude is I really love the. Alignment in vision and practice in our engineering function. By that I mean we're not saying we're going to accomplish one thing and then really in practice doing another. We are very upfront about the, that we, on the speed to quality spectrum, we align on the side of speed, and that's a cultural value and we're gonna go all in on it. It. So my job as the head of security is to constantly be there to pull us a little bit towards the quality piece and to build the patterns so that the. Customers of those quality improvements are the engineers themselves. If I'm only building quality into the product to satisfy myself, it's not gonna go very far. I have to put on the hat of the customer and say, for our largest customers, how can I ensure that they are meeting the security requirements that will enable them to continue to use Amplitude, to start to use amplitude, et cetera. So that's, this is a very amplitude answer, but I'd say that that's one way I'm solving the problem is aligning really tightly with my engineering counterparts and focusing a little less on what I want them to do and a little more on why I'm asking them to do it.

[00:08:07] Tim Chase: I think one of the reasons sometimes that. we're not so good at, the quality when you do DevOps and, and such like that as we forget that part of DevOps has continuous improvement at the end, right? that's why they have this infinite loop, but it's not just, you know, you write the code, deploy it, write the code, deploy it, right? There's this little thing on the end that says, Hey, come back, see what you did wrong, and fix it so you don't do it again. And I think we forget that. That part sometimes, and I, I talk a lot about that when I talk about DevSecOps. I mean, do you agree or you have a different opinion?

[00:08:36] Terry O'Daniel: I do. I do. And I think that's honestly one of the areas, you know, having worked in, in prge infrastructure and now security for a long time, I would say that's one area that infra and platform especially does a really good job, right? you just have to, you have to build that muscle of, constant post-mortems, constant RCA is constant cycle of improvement because otherwise you, you don't know, you don't know where you should invest. but. Devs will tell you, dev XB is a very clear way to hear from your internal customers. This is broken, those scans take too long, whatever. So yeah, I think that's part of it. And I would, I would even go a step further and I'd say, sometimes where we lack the most in security in, in the way we approach security engineering is around transparency. And empathy, it pains us sometimes insecurity, to see the risks, to see the vulnerabilities, to, to see the potential for exploit. And we, you know, it keeps us up at night, but we don't always do the best job of empathizing with our dev counterparts and the speed. How much they are under a vertical product oriented, business oriented timeline. And they don't have the same flexibility that we do to change some of those timelines, right? Sure. We can show up and say, Hey, there's a zero day, stop everything and do this. We only have so many times we can use that excuse. And I think a lot of the times where we could be investing better is to have that transparency and the empathy and understanding. From our engineering counterparts. When was the last time you had a security team? Go ask Dev. Hey, what are the biggest risks of the company? Or do we sort of, precede that and do we come to the table with that already filled out and we tell devs, here are the biggest risks of the company, therefore we need you to do X, Y, z. I think we missed an opportunity by doing that.

[00:10:21] Tim Chase: Yeah. I'm a big fan of, of us being like advisors and auditors rather than, you know, doers and, pushers. Right? I think when you get to a really good kind of DevSecOps flow, that's what it ends up being is it's more collaborative, because we're allowing them to do more of the work it integrates with their workflow. We're there to set the guardrails, and to help them and advise them when they, maybe they don't know how to fix something, but ultimately, you know, that's what we're there for. we talked about goals a few times. and I want to really kind of double down on that a little bit cuz I think that's very important. Sometimes when we start talking about goals, and we, we get into DevSecOps, we think of goals along the lines of. Vulnerability reduction or, you know, fewer, security defects. Right. Those kind of goals. but ultimately, like, that's not what we just talked about. That's not what I heard you say. What I heard was more along the lines of goals to the business. Like that's where the DevOps teams are focused. That's if, so if security can, go along with, their focus and figure out how to meet their timeframes or work with them like that seems to be where you're talking about goals, not like security goals.

[00:11:29] Terry O'Daniel: I think so because I think security goals are around risk, right? Security goals have to be about the, the measurement and management of risk over time, but, Amplitude is not in the business of measuring and managing risk over time. Amplitude has a product that it is trying to build and sell to customers, and I think it is easy insecurity to lose sight of that, and it's easy to lose a sense of driving towards business objectives. you know, we, we talked a little bit earlier about how I, I spent some time in the, in the trenches of, governance risk and compliance. the one thing I, I really learned from that, was how much we have the opportunity to. Align with business objectives and the more you align with business objectives, the less you're ice skating, uphill chasing after people trying to say, Hey, we need to move in this direction. If there's a, a strong center of gravity, amplitude wants to move in this direction because it meets our product roadmap, and unlock these kind of expanded deals with these kind of customers. That is a much easier conversation to have about how to align rather than chasing after folks saying, Hey, get those secrets outta code. Hey, close those phones within sla. It's just a different conversation and I think it, it's, it sets security at a, at a more strategic level to have those conversations. And if you can't have those conversations, you haven't unlocked the value yet. You haven't proven that you can be a strategic partner, that you empathize with the relentless, product, you know, ship it, delivery cycle and things like that. So I would say it's not, while it is perhaps a spicy take, I would also say it, it behooves us to look in the mirror about why we're here.

[00:13:05] Tim Chase: Spicy. Take number two, man. we're, uh, just tearing it up here. 

[00:13:09] Tim Chase: the other thing that I think Amplitude is, doing that you mentioned, is the leadership, this is an area that I don't think people understand enough is that, you can't just have, an engineering leader. Say we're going DevOps, and then they're off to the races, right? Like, that's not the way that it works. And I think, I think you know that, right? the way that I look at it is, Agile is the methodology that you work within to do the testing or the development, right? But overall, the framework is the DevOps. So you can use Agile inside of DevOps, but Devs DevOps is a transformation that requires leadership change from the very top, right? I mean, agree.

[00:13:47] Terry O'Daniel: I do. you know, I was, I remember I was at, at Yahoo in, uh, 20 15, 20 16 when sort of DevOps was becoming a thing. And it was fascinating to see the reaction. I, I worked in production engineering, which is, you know, kind of the ops of, of DevOps and it was fascinating to see the reactions internally and as we hired in new people, right. There's a way that you can, I think if you summarize the value proposition of DevOps, if you do it well, it's almost hard to say no. It, it, it's like one of those things like, we should put out the fire. It is hard to get anyone to disagree with that. The fire's burning, we gotta do something about it. So I, it takes me back to, no, it's been 15 years. What happened? I wonder sometimes if, you are right, right. Is it around? The leadership conundrum because have we created this artificial, contentious relationship between engineering and security? I, I'll, I'll be transparent in sharing that. You know, when I, when I joined the Amplitude, I think there was a little bit of a pattern that had developed, or, or an anti-pattern where, devs realized if they flew under the radar and they just kind of shipped quickly and, didn't draw the, the watchful eye of security, then, you know, even if they had a problem, they could just, fail forward and they could patch it next cycle. how painful do we make it for devs to get involved with quality improvements? Do we make it easy? Do we make it something that they can, Start and stop in, in five or 15 minute chunks, or do we make it a big, big overblown project that makes it painful and then makes it feel like they aren't actually working on the job they were hired to do. I I think we've erred a little on the side of the first one. Right, and I don't know if you've actually built the, the patterns that tell Dev, here's the value that you're gonna unlock. and sometimes it's as simple as that. Sometimes it's appealing to common interest. would you rather, invest 20 hours to build a better intake mechanism here? Or would you rather spend 200 hours over the next quarter or two responding to these individually? I think together, if we decide on a pattern, we could build that funnel and we could reduce the amount, we could build risk patterns natively into those systems. I mean, I had to stop myself. I almost started talking about change management, right? one of the interesting pieces about change management that I don't think I've ever been in an organization where engineering doesn't say, well, not every change has to be reviewed. Right? I mean, not

[00:16:14] Tim Chase: Just the ones that don't affect, you know,

[00:16:16] Terry O'Daniel: right, right, right. And I say, okay, cool. Awesome. No, no, you're right there. There are minor changes and they shouldn't have to be approved at all. Can you show me the canonical source of truth and the engine that enforces that behavior? It doesn't exist, then yes, every change has to be approved because we haven't done the work. We haven't, and I mean, us included, security included. We haven't sat down the table, shoulder to shoulder and locked the door and said, you know what? If we come up with a rubric that actually aligns on these, We have the same goals. We want the company to be safe and secure. We want our customers to be delighted and happy and not, have a, a blank screen or something like that. if we're all sitting on the same side of the table and we keep that objective in sight, then it just comes down to a list and priorities and, and a regular practice of grooming that backlog. And those are engineering patterns. We know how to do those.

[00:17:05] Tim Chase: Yep. that's spot on. I, I like it. And that's actually a good segue into kind of where I wanted to go next. So your background, is kind of in engineering, right? That's historically where you, where you come from. and so I'd love to know. Kind of how you got from engineering into security. How did that go? I, I always like to know how. Other people got there so that other people can learn how to do this cybersecurity journey. So engineering to, to security. 

[00:17:30] Tim Chase:

[00:17:30] Terry O'Daniel: I had the good fortune to be in San Francisco, just as the.com boom was happening. and I, I had the technical background and I started working for a lot of small startups. And, you know, startups at that point weren't, you know, you gotta pay your AWS bill and, and you can just get started. this was like, you know, we, we gotta wire this warehouse before we can actually have people working here. We got build our data center, et cetera. I think coming from a very operational place where I wouldn't have thought to call myself a security person in the first half of my career, or at least the first third because it sure felt like engineering ops, it, even things like that. But I always considered that security was an essential component of those. I would never have considered delivering something and saying, that's someone else's job to secure this thing. It, it's all part of the mix. Right. So for me, the fascinating piece for me is I was moving on that path and I, was doing a lot of security auditing. I was doing audits for the, the state of California on their data centers and networking and things like that. Cause I, I have a background as a network engineer, And, a VP of engineering I'd worked for in the past said, Hey, you should, you should come check out this, this compliance work that's starting. , there's this new security standard called, Sarbanes Oxley, and we need to help, uh, companies get compliant with it. Now, that was a big lie. Sarbanes Oxley has nothing to do with security, but what I found is gave me an opportunity to talk to the half of the business that I really didn't understand, which was. The business, the non-technical half of the business. And I had the opportunity to help, some very large financial organizations get compliant in the first couple of years of SOCS and it taught me a lot about how even at the largest, you know, financial services, uh, banks, et cetera, the understanding of risk and how it applies to technology was sorely lacking. the understanding of risk got to a certain point and the understanding of technology got to a certain point, and I found that there was really this gap in the middle. So I, I worked in Yahoo at production engineering and a senior director who kind of mentored me a little bit, had a background in quality engineering. He was getting hammered by these various requests from our security team at Yahoo, and he was feeling overwhelmed. And I said, well, I don't know any of this stuff, but I have a background in security, so, so let me take a look. And I realized quickly that it was the same problem, right? engineering had goals and we had metrics by which those, those goals would be evaluated and we had certain numbers we had to hit. And nowhere in there was anything about risks. Anything about compliance, anything about securing the company. And so I took that on and I took that. I said, you know what? Let me just, let me just own all these intakes from those other teams and, and manage them. And I very quickly found out they care about the same things that we do. They care about access to privileged resources. They care about privilege escalation. They care about, I mean, we, we at the time, you know, Docker was just sort of spawning, so we cared about securing those containers and making sure that people could do lateral movement, although we didn't call it lateral movement at the time. And I think that was really the genesis for my starting to, think less of myself as purely an engineer, specifically an ops engineer or infra engineer, and, I started to think of myself as doing security work and then as I went to, Salesforce as they grew, I was at Salesforce doing a period of immense growth where they were just doubling their user base every year. I had to create the second line of defense in a sustainable way. We couldn't be everywhere. We had to build patterns, and we had to be able to hand them to a growing organization in a way that those patterns could be almost holo, grammatic, and they would grow as those orgs grow. Through. the first actual security job I had reporting into a security team was just a couple of years ago it was reporting into security at Netflix and I learned so much. that gave words to the feelings I'd always had, about how I like to approach security. and I really enjoyed the, thoughtful leadership and, and the great, security engineers I met at Netflix because they all understood the truth. Devs don't report to us. They have their own leaders and they have their own goals, but what we can do, we don't control. Engineering, but we can give them the context. We can help 'em understand the context for making better risk aware decisions. And honestly, that's been, my hope ever since. And, and now I have the opportunity. I, I led security for a year and a half at, uh, Instacart. And now I have the opportunity to lead security here at Amplitude. And I think if I do nothing else other than foster that conversation and help. The company make risk aware decisions and document that we did, so I feel good about the journey.

[00:22:11] Tim Chase: you have an interesting kind of side. You've done the GRC stuff, you've done the engineering stuff. You kind of understand both. What are the questions that I like to ask, and this, this is another hot take, but like, do you think it's, more effective for a CISO to come from a GRC background or an engineering background?

[00:22:28] Terry O'Daniel: You know, if you asked me that a few years ago, I probably would've been, It maybe out of self-interest more than anything else. because I had just rolled off, several GRC engagements and I'd seen how much that perspective and discipline was missing in security organizations. But I'll be frank, I think the speed of technology is, is not slowing down and I think There's only so much I can lean on my GRC background that will take me to the solution. I guess I look at it this way, if I wasn't an engineer and if I didn't have, you know, 25 plus years of engineering hands-on background, I don't know that that GRC overlay by itself would be enough. I think it has to be the combination. So I, if, if, you know, if you were a CTO hiring, a CISO for your org, I think if you're a SaaS company, I think your CISO has to be technical. I think at the core, your CISO is not only protecting your people and your work systems and your sdlc, they also are inherently predicting and predicting the risk. Of your product and that B2B relationship. So I think it, I think traditional industries still can get a, a huge degree of value out of hiring a CISO who comes from a strong risk and governance background. But if you're an engineering first company that's building neat stuff, if your CISO doesn't have the finger on the pulse of that, I think they're inherently a little hampered from their ability to help the company shift left.

[00:23:57] Tim Chase: No, I agree, especially, and like I said, you know, there are exceptions to everything, but you know, especially like when you're coming up with kind of your overall security plan and understanding how everything should fit together, things are so technological these days, you know, how, how can you understand kind of the overlap of to making sure that you're covered in all the different security areas? If you don't have that understanding, you know, risk will only get you so far. GRC is super important because, all the privacy stuff coming up in countries and states and things like that. But, that's my opinion. Somebody else could come on and, and have, a another one, like I said, it was, there's no, there's no right or wrong to it.

[00:24:33] Terry O'Daniel: And I would say, take that a step further, right? I'm not here to, to pick a fight between compliance and security. I think there's a lot of, you know, sort of bad blood between compliance and security. Again, I think that's a case where both sides could, use a little time looking in the mirror. I don't know that grc, has done the best job of, you know, understanding security enough. I mean, Come on. if you're gonna ask me questions about how I'm hardening Kubernetes, then, you know, spend an hour looking at YouTube videos of how to harden Kubernetes so we can speak the same language. So I think that's fair. But then on the flip side, G R C does a great job of taking big, big unmanageable projects and just throwing their arms around the whole thing and saying, we're gonna slice and dice this and get it done. And still it's done. And that, and sometimes I think insecurity, you know, we get distracted, shiny object, Ooh, terraform or, you know, something, and, and we don't have that same focus. So I think both are, are really essential in any. Especially for SaaS, especially for certain industries, right? B2b, FinTech, health tech, things like that. You have to understand the why and the the business goals, which are risk and compliance and governance. But if you don't understand the underlying technology, then you're just playing a game of telephone.

[00:25:50] Tim Chase: Yeah. Yeah. I, I agree. I think that's a super interesting perspective on it. you know, just to kind of get back onto your career and your learning,a little bit, like if you were to look back kind of on all of your years that you've been doing engineering and then eventually security, what do you think has been the biggest learning of your career?

[00:26:08] Terry O'Daniel: I suppose this feels odd to say out loud as a, as an engineer, but it, it's really been about the human element, right? I can own up to the fact that I was pretty arrogant, when I was younger, and I thought that if we just. Focused a little more on the technology and we, we erred on the side of picking the best technical solutions and we focused on, on good implementations, then everything else sort of takes care of itself. And I have found that over the past few years,if I'm not hiring good, strong security engineers who can do that, then that's a problem. But if I am hiring good strong security engineers, then I think more and more of my job has become to be the leader they need to help unlock their value. And by that I mean it can be very frustrating to be in a security role. Especially if you're a security engineer, right? And you, you know how to build things and I'm, I'm incredibly fortunate that all of my security engineers at Amplitude come from development, They all have backgrounds as engineers and they came over to the dark side of security. So I'm incredibly fortunate because we can, we can speak sort of a shorthand in doing so, but that doesn't take away my responsibility and my responsibility is to. Enable them to succeed, to unlock the understanding of how much value they can provide to the company. And sometimes that means making introductions. Sometimes that means setting them up for success by thawing the atmosphere with other leaders. maybe because of past negative experiences. But at the end of the day, for me, I. It's about servant leadership, and it's really about helping my team succeed and helping through coaching, through setting them up for success, through making sure they're working on the right things that align to their goals and and abilities. That more than anything else has really been the, the focus, over the past few years. For me, as, as I move more and more into security leadership, I think the, the conversations with the board, the conversations with the C-suite, those, those are my responsibility and, and I take this very seriously. But if I don't have the foundation of having built a safe, high trust, high transparency environment, then. I don't know that any of the other stuff will necessarily work out. So for me, I, I guess I've become a little less arrogant. I've become a little more focused on the people, rather than the technology. I'm still an engineer at heart and I love, I love cool tech, but I. Yeah, that's not gonna help me be successful. What's gonna help me be successful is unlocking the value of a security team that knows how to talk with engineers and sit side by side and align with them and, and solve problems together and come back to the well and say, I need help in this area. And if I do that, then I think frankly, the rest should take care of itself.

[00:28:55] Tim Chase: No, that's a great way of looking at it. I've always had that perspective, you know, the more leadership roles that I've taken on is like, it's about building those relationships. it's talking to the people over on the, the Windows teams or the infrastructure or, the legal side of the house, right? Like I always felt like our job as leaders is to build those, because that's how, when you, when you need something done, like you go over there and, they're gonna listen to you, right? But if you're constantly like, You know, fighting everybody. Like it's never gonna happen, right? And so I've even told my my teams, you know, look, you got a problem with something outside of our team. come talk to me first. Let me fight the battle for you and I'll figure it out. I don't need you out there fighting this battle with somebody. Frustrating them, frustrating yourself. Like, let me use my relationships to help you to maintain, you know, security as the, as the enabler. 

[00:29:45] Terry O'Daniel: Yeah. I think, having either joined a company twice now that has, was either preparing to go public or has just gone public and is trying to figure out how to unlock the next level of security and maturity. Yeah. I, I am a huge believer in the fact that we, we have to give people the tools to, to really be successful. And, if I'm not growing leaders, then what am I doing? I, I might as well be hiring contractors. But that's not what I'm doing. I'm hiring these people and I take the responsibility very seriously that they should be, they should feel just insanely successful. And if they're not then, then that's on me and I'm not, I'm not helping them unlock their value in a way that I should be.

[00:30:20] Tim Chase: Well, kind of getting to that, just to kind of wrap up and, and finish up with, uh, one last question before we do some rapid fire stuff. like what advice do you have to somebody wanting to get into the security, industry and wanting to kinda make that breakthrough?

[00:30:33] Terry O'Daniel: I, I, I, I think I have two answers, I think if you want to get into security, it, it's a passion project, I think most of us are in security for the long term, not because we're, chasing, you know, a big compensation or something like that. I think it's because we just. Can't leave well enough alone, we see a risk and we just, it, it just itches us. It itches us in our soul and we have to do something about it. So I would say first and foremost, if you're getting into security because you think it's a, a hot market,strongly encourage you to do some ride-alongs to, to see the actual burden. Most of us who are in security after a few years are here because we can't. Not be. So I would say make sure that your passion is really there and if your passion's there, then I strongly encourage people to find a role that gives you breadth early on. Don't hyper specialize. Right. It, it's very easy for us to hyper specialize in security and more than, I mean, sure. Engineering teams talk about what languages do you know and are you used to front end or back end or stuff like that. But. Man, we paint ourselves in this little corner in security by saying, you know, oh, well I, I started out as a, a pen tester and then I was a red teamer, and now I'm gonna, I'm gonna stay in this avenue and I don't care. What I want is, I want you to help me secure the company. So, I think focus less on being an expert in a certain area unless you really want and you found your passion and that's all you ever wanna do. I know some folks who are amazing at the security research space or, or IR or whatever, they just don't have a desire to work on the other parts. Great. Good for you, but. One of the best things you can do early on in a security career is get a breadth of exposure and understand all the flavors and, and the ways that the business actually applies. what you read in your textbooks or, or studying for your C I S S P exam, how that actually happens in the modern enterprise.That'll give you a lot of visibility into the pieces that you want to work on because again, it's not just about the technology, it's about the combination of the technology and what are you gonna be doing every day. You wake up, you turn on your computer. What is your day like, the day of an AppSec person, and the duties of that role may be very different from the type of work you think you want to do. So get that breath, get an understanding of how security actually works in the real world, and that'll give you a better understanding and you can make the, the choices to, specialize from there.

[00:32:55] Tim Chase: that makes total sense. I try to get people to get away from like the cool factor. So like what you were saying at the very beginning, like take a ride before you. Commit. Right? Because I get people that are like, I wanna be a hacker. How do I get to be a hacker? I'm like, like, dude, just, it's not like in the movies, right? Like, you can't just, I can't teach you to be a hacker. Like, you've gotta have like six other skills to even get started down that path, right? So, start someplace else and then, and then figure it out. 

[00:33:18] Terry O'Daniel: that's, hilarious. That reminds me of my youth. I, I mean, it's funny, I, you know, I didn't go to university, uh, for computer engineering or anything like that. I actually was a arts major, but, um, I think when I was 13 or so, I had my own computer and I, I couldn't get a program to work and I just started thinking to myself, Well, there's gotta be another way to get this to work. And I mean, that's where it starts, right? You, you, I don't know if you can teach someone to be a hacker so much as you, you help people who have that fundamental mindset. You help 'em find success, and you help them apply those skills in the real world.

[00:33:51] Tim Chase: No, you're exactly right. They usually, they're already like, You know, in, into Python, and we're like, well, I could just script that I could do something, and then they kind of take it to the next step. You're, you're spot on. all right. Here's some rapid fire questions for you, as we, as we kind of wrap up. what is one tool that you can't live without?

[00:34:07] Terry O'Daniel: Vulnerability management. It pains me to say, but vulnerability management is as painful as all the tools are in this space. Ultimately, one of the cores of my job is getting a signal, too much of a signal, trying to filter out the noise, and then getting people to take action.

[00:34:23] Terry O'Daniel: I think at the end of the day, risk quantification. Is not very sexy. I understand. But, we tie ourselves in knots in security, you know, doing this sort of interpretive dance for the board of red, yellow, green, and here's what it means. And bib boo and businesses don't run on interpretive dance. They run on dollars. And until we can come to the table like grownups with the rest of the grownups running our function and saying, here's the risk in dollars, here's the investment in dollars, here's the risk mitigation we're gonna realize in dollars. that's the key, right? We have to be able to talk the language of business to be successful as, and be taken seriously as business partners.

[00:35:01] Tim Chase: I love it. 

[00:35:02] Fade in theme song

[00:35:02] Tim Chase: alright, that does it for us today. Thanks so much for tuning in. If you're enjoying the show, please consider subscribing or leaving a rating and review. and keep an eye out for the next episode of Code to Cloud. Coming soon to your podcast player of choice.