Making Security a Part of Product Development with Naomi Buckwalter

Secure Talk - Naomi Buckwalter

Justin Beals: Hello everyone. And welcome to Secure Talk. Glad to have you this week. I have the pleasure of an amazing guest today, Naomi Buckwalter. Naomi is an accomplished information security leader, nonprofit director, keynote speaker, and LinkedIn learning instructor. She has extensive experience in directing information security programs and has most notably served as director of product security at Contrast Security.

Buckwalter's expertise encompasses compliance, risk management, and security operations. She is also the founder and executive director of the Cybersecurity Gatebreakers Foundation. Its aim is to revolutionize cybersecurity hiring practices. She has a background in computer science and is recognized for her contributions as the cybersecurity thought leader and advocate for diversity in tech.

Naomi, thank you for joining us today. 

Naomi Buckwalter: Hey, very cool. Justin, so great to be here. Thanks for having me. 

Justin Beals: It's a real pleasure. So I certainly would like to learn a little bit about how you got interested in computer science and certainly cybersecurity. We love a great origin story here at Secure Talk. So, could you tell us your story a little bit?

Naomi Buckwalter: Well, like origin story, do people get origin stories if they're good or if they're evil or both? Like you get to both. Yeah, it doesn't matter. You 

Justin Beals: Like you get to both. Just have to track a great story. 

Naomi Buckwalter: Great, great story. I feel like, I feel like the good guys, their origin stories always have something depressing and sad. Like Batman had the murder of his parents, and it 

Justin Beals: does create a dynamic, you know, we have these tropes for stories, like the person crawls out of the hole. The person falls in the hole then crawls out of the hole. So you could if there's a good trope. 

Naomi Buckwalter: Oh yeah. Like the hero's journey. Right. I certainly hope I'm not one of the bad people. Like Joker falls into, I don't know how he starts, but I feel like he was just bullied. Possibly. Although I have my fair share. Well, Justin, happy to introduce myself. I am Naomi Buchwalter. I'm the senior director of product security at Contrast, and we do runtime application security. So check us out if you guys are in the market, but we block and protect your running applications. And it's pretty awesome, got to say. 

Anyway, how did I get started? How did I get started? Well, I've always been interested in tech like you, Justin, I'm sure all your listeners also. We've always just been interested in, and I don't think at any point growing up. I was ever told that, hey, this is not for you, a female. How dare you?

You must play with the, oh my  God, Justin, with my dolls. I it was not the best at the doll thing. And I would just like cut their hair and draw on their faces and rip their heads off. I guess I was a little psychopath. Maybe I am a little bad person. But I'll say I was always interested in tech and always just had my hands on something, taking apart VCRs and putting them back together again as a very young child, getting my first computer at 11 or 12, first getting on the internet in high school.

I remember just getting blown away, Justin. Do you remember the first time you were on the internet? How did you feel? How did you feel? 

Justin Beals: It was amazing. I think there were a couple different dial-up situations that I had, and the first one, like, you still had to put the handset in the little cups, and it didn't actually have a screen, It was paper. But the fact that I was talking to another computer somewhere blew my mind. I was like, Oh, wow. 

Naomi Buckwalter: Amazing. Oh, my gosh. All right. So you're a little older than  me, but I know it's okay to apologize. So you're O. G. That's what the kids call it.  I am in my 40s, so I'll just leave it at that. But I remember the first time being on the Internet I was blown away because I thought, computers at the time were very fact-based, you know, like 1 plus 1 equals 1, always equals 1, unless you're JavaScript, ha ha ha. The idea is that when you log in now, you can, you can get someone's opinion. And that is what I remember my first taste of the Internet.

I don't know what I was doing. I was in the high school library, and I was like, Oh, the internet, that's cool. And then I look something up and it's someone's blog. Personal opinions on something, and I was just blown away. I was like, say what? You know, so I remember that, but I've always been interested in tech.

I, my undergrad is in computer engineering. I did a math minor at Stevens Institute of Technology. And from there I got a job as a software engineer at Vanguard. I was working there for about 12 years. I did a whole bunch of different things, but my journey into security happened there. Somebody took a chance on me.

I took a course in basic application security and for developers. And I was blown away at first. It was like the same angels singing heavens opening up thing, just like how I did that moment on the internet. I had that moment where I was like, Oh my God. Cause I was learning something basic like SQL injection at the time.

And I was just thinking, Oh my God like I didn't even know this was possible. I love this stuff. And I fell in love with it. That very second. And I knew I needed to do security and I was maybe in like my early twenties. I was such a little naive baby. And I remember Googling like internal Googling, like, who is the security person here at Vanguard?

Because I need to get on their team no matter what, and I found out their names. Name is Tony Kaneki. And I realized it's like, Oh my gosh, he's only in like a few buildings over. So I remember either I am in him. Cause we didn't use. It's regular slack. We had something internal. Forget what it's called. Oh, what's it called?

Same time. Oh my God. Same time. Instant messaging. Yes, it was. Okay. Same time, Tim. That's how old I am. And I said, Hey Tony, my name's Naomi. You don't know who I am, but you need me on your team. You clearly need, he's like, who the heck are you? Go away. I remember, I remember just pinging him literally every other week and like, when do you need me on your team?

You need me on your team. Blah, blah, blah. And then finally, he's like, okay, we have an opening. It's for a senior position, senior application security analyst or whatever the title was at the time. And I said, great. I'm going to apply. He goes, no, you don't know what you're doing. I'm like, true. Very true.

None of that is false, but I can learn. I can learn the heck out of it. He goes, okay, we'll give you a shot. I sit in the interview. Somehow, I pass it. I remember being asked a question, some basic fundamental questions, but this is before all the frameworks and stuff like that that came out. Right. And so I remember the question was like, what, what is the problem?

I remember, I remember this from the course, you know, so the, the reason that it's stuck because I was so interested in this stuff and it just kind of stuck to me, like glue through osmosis, I kind of just picked this up through the months of me banging on his door, I was also learning some of these things, just, you know, By accident, by interest, just on my own.

And so by the time I was in the interview, they say, you know what, this person actually might have some potential here. And he took a chance on me, gave me a job and I was hired as an application security analyst on the application security team. And it was interesting cause I still love development. I was a full stack developer at the time I was doing, Oh God, what was it?Angular, 

SQLs and backend. So it was, it was fun. Good stuff. Good stuff. But I knew I wanted more. So by the time I joined Tony, Tony's team started me doing really basic pen testing, really basic application security, really, really basic stuff, really leading basic architecture reviews, leading basic code reviews.

And he gave me a chance, gave me some training, sent me off to some SANS training. I got my CSSP. A couple of years later,  and by the time I left Vanguard, I had a lot of different, I had ideas and experience in different areas of the business and different areas of information security. From there, I did a little bit more security engineering, and I took a first job as a security leader.

Did not do great at that first job, I'd like to say, Justin, was actually I got let go because I had no idea the importance of security. It wasn't as important as I thought it was. Like it was hilarious. I didn't understand the purpose of security, which is actually security as a service for the business.

 I can get more into that later, but then from there took more security leadership roles. I am currently the senior director of product security at Contrast. And I love it. I will say I've taken those executive leadership CISO level roles where, you know, I had those one-on-ones with CEOs and also board members.

So I've, I've operated at that level. Just not without the, just without the title, unfortunately, all the work, but none of the 

Justin Beals: Glory.

Naomi Buckwalter: but whatever. It was all good. I learned a lot, but I will say, Justin, at the level I am now, I'm happy to just focus on a single domain. In this case, product security / application security.

And you're working closer with developers, and it's back to what I know, which is what I love. The application security is the best domain and information security. I will argue that day in and day out is my first love. And now is the thing that I, do.

Justin Beals: That's excellent. There's something that you said that resonates with me throughout my career is that somebody took a chance on me to at times where I didn't seem like the kind of person that you would take a chance on.

And I think that is probably inspired some of your work with Gatebreakers. We want to talk a little bit about the mission at Gatebreakers and what you guys are working on. 

Naomi Buckwalter: Yeah, so Gatebreakers, and thank you for this question, Cybersecurity Gatebreakers Foundation, our mission is to break down those gates in cybersecurity hiring by convincing, winning the hearts and minds of security leaders, CISOs, hiring managers, and security professionals to really take a chance on people, just like someone took a chance on you and took a chance on me. 

The idea is, this can be done. These things in security are not, not that difficult. In fact, we make it too difficult, and therefore we see some of those breaches that we currently have because we  don't really focus on the things that matter.

We don't focus where the risk is. If you take a look at some of the data that comes out from the annual Verizon data breach investigations report, you'll see that the root cause of over 80 per cent of all breaches is a human error, there's human error involved in 80 plus per cent of all the breaches, which caused by the way, private citizens, governments, and businesses, millions, hundreds, millions of dollars, billions, trillions.

I don't even know. It's, it's a lot of money. It's numbers that I can't even imagine. It's just like, whatever. It's just numbers, but you know, but it affects us all personally. Like I've, I've personally been breached so many times at this point that I'm not even surprised. I'm just, I'm more disappointed than anything.

I'm like, you know, and it's just annoying. It's annoying. But beyond that, beyond the annoyance factor, there are real implications to everyday life that people don't think about. So if we're talking about something, you know, about the CrowdStrike. I mean, that, that wasn't depending on who you talk to. That wasn't really a security incident, at least from a CrowdStrike perspective, but it absolutely was a loss of availability for a lot of other people.

So yes for, for the end consumers, it was a security incident, but I will say, like, think about that, those, those things happen because of error. And maybe the CrowdStrike one wasn't attributed to human error, but. There is software quality issues, which is why I love application security, because you got to focus on that very, very important vertical.

But there's other things like asset management, configuration management, baselining, understanding, what, uh, social, social engineering, like security awareness. Those are the things that I think, and this is what Cybersecurity Gatebreakers does, is to help those hiring managers understand. That those are the important things that you should focus on.

And why not hire to get people to work on those things? Because first of all, Justin, you don't want your senior people working on that stuff because they would be massively overpaid. They would not be focusing on the things that you want them to. So hire those new people, get those people in, teach them what good information security looks like because, yes, there is a free, there are multiple frameworks for this.

: Don't just fly by night. Follow someone else's path that has been vetted and error checked and all these things over the course of the decades that we've been in this industry. Use stand on the shoulders of giants. I like to say. Use that knowledge and then apply it to your company. And so this is what Cybersecurity Gatebreakers does.

It's convincing people through anecdotes, stories, and data and evidence and talks and presentations and conferences. And, and we go all over the place, just spreading the word. 

Justin Beals: Yeah, II agree with you completely. And one of the things that I've  seen over and over again is that we have this, maybe this is, maybe this is engineering or maybe this is management in general, but a manager who is in a hiring position creates an expectation that a person will be 100 percent capable of a job at the time they get into the job.

That's almost never true. And it was never true for them either, right? Like, to your point, you learned in the work about what great work was, and I think it is an ethical responsibility. Of managers to hire people that aren't yet 100 percent good at certain jobs and identifying those jobs where you can bring a 25 percent or a 50 percent person that has a passion for it to grow into it, no matter who they are or where they come from, right?. So, certainly, I have a theater degree, Naomi. Someone took a chance on me to let me write some code someday, and I was like, oh, you know, this kid is capable of doing this a little bit. A theater degree. 

Naomi Buckwalter: A theater degree. That's so cool. And, and, and you're not, I mean, you're, you're special, but you're not unique, right, Justin?

Justin Beals:I'm not unique. Not at least. 

Naomi Buckwalter I mean, I'll tell you, I hired this wonderful lady. Her name's Jessica. She had, she was an opera singer. She majored in opera. She speaks three different languages fluently. And prior to me hiring her, she was a nanny, so she had absolutely no technology. And at the point where I had this internship open, I was like, you know, I got to really put my money where my mouth is.

I can't just say hire people without trying this on my own. And by then I had already hired a couple of juniors, but I really wanted to see, you know, If my theory was true, I wanted to see if I can pick somebody who is humble and hungry and smart enough that I think could do this work. And, and this is what I found in Jessica.

She was smart. She was incredibly smart. I mean, look at the proof. She speaks three languages and she can sing in them too. Um, she can pick things up in the take home project that I had her do. It was, here is a sans white paper that you can find online. It was, I forget what it was, it was something about vulnerability management.

It was maybe like four or five pages and they said, read this, give me a summary, tell me what you think. Might be wrong about this. Tell me some logical fallacies that might exist in this and this is pre AI,  so I know she actually did this on her own. So, you know and comparing her work with the four other five four or five other finalists I don't know why I've done this work too.

She stood out because her ability to pull out the logical fallacies of the arguments that were made in the white paper blew me away. And I said, this is a critical thinking that we need. This is somebody who knows she doesn't know anything. And I know she doesn't know anything, but I know she can learn it and yes, everything in cybersecurity can be learned because we currently do it every single day.

Justin, don't we always learn something new? 

Justin Beals: It is the joy and the work. Yeah. That's why I was attracted to it. Cause it's. Constantly a new challenge. Yeah, 

Naomi Buckwalter: Absolutely. And so how can we sit here and say, Oh, you can never learn this when we ourselves are currently learning things that is so hypocritical, right?

And so that's the kind of thing like, what if I gave her and her first project was, was we need some IT security playbooks. Our IT security is fledgling it again. This is how I view security Information. Security is like risk management for security risk for the business. That's what we do. We do risk management underneath information security there's other buckets. 

One of them being it. I love this. Like it really should be reported to information security. That's a whole nother thing. That's a whole nother thing. But under IT, there's be IT, ITsecurity. So things like managing access for IT systems and thing and just little things like that.

Not like the bigger security projects like architecture, infrastructure and stuff like that. It should be all separate. But anyway, security operations, for example, IT  security, we needed help. We needed playbooks. So I said, Jessica, could you create, as your internship project, as your learning security, can you please create us a set of usable IT security playbooks, which, by the way, don't need to be automated, just give us the 1, the list of things, give us the flowchart, blah, blah, blah, give me example, give me playbooks for when a account is compromised.

Like your email account, right? How about when a laptop is stolen or when someone clicks on a link and they don't know what to do, give me those things. And by the way, all of those things are available for free on the internet. That if you just look it up and apply it to your own company, those things are available, those resources are available.

So not only can she learn this stuff because she's smart, she's resourceful. She's not afraid to ask questions. I'm not afraid to teach her because I know these things. Pretty well now because I've made my share of mistakes. And so if I could teach her and I realized someone like Jessica, who is an opera singer, who is a nanny, who speaks  three languages, who has no background in technology at all, zero, if we can do this, anyone can.

And I realized at that point, I feel like there's just like the biggest secret that I needed to share with the world. And I, and apparently by then I'd already had like a little bit of a following on LinkedIn and I'm so cringy, but I knew that the story needs to be told and I can't be the only one who believes in this and then me as a citizen of this world with family, friends, and, and kids and neighbors and just people in the street.

I want everybody to be safe on the internet, to have a safe digital future, because I know, and the data shows, cybercrime is increasing, we are at risk for very large disruptions across humanity, across the world, from instability,, due to cyber criminals, and this is happening, and I don't want that world.

I don't, I don't want that for anyone and I have that selfish reason of like, we need this message to be spread across everyone everywhere as often as possible. 

Justin Beals: I think of it like tending our own garden, right? Versus rating it in the moment. If we tend for a good Internet, a good digital space for us to operate in with humanity.

With trust, then we'll build, I think, something that reflects our society that we want as well. And if we don't put in guardrails or it's too porous, or it's too easy to perpetrate fraud or theft, then, you know, it will reflect the worst of our cultures in a way. Yeah. Well, you have a, you have a passion for a great internet, you have a passion and have been giving people opportunities securing that Internet. It's really brilliant. I thought we also might talk a little bit about the work that happens on product security itself. So you're an application security leader. What are some of the big aspects that you think about it in your work?

Conjoined with someone trying to get product out the door like a software development team? 

Naomi Buckwalter: Yeah, yeah. So remember how I said, Justin, that information security is a service for the business? 

Justin Beals: Yeah. 

Naomi Buckwalter: Also said information security is risk management for security risk in an organization. Security risk is just one of many different types of risks.

Okay. It's the same thing for application security. My job is to manage application security risk for an application development team or a shop. And that's essentially what we do is, we manage risk, we discover the risk, we prioritize the risk, and we make sure it gets, uh, managed correctly. Either it gets mitigated and fixed or, you know, it gets punted down the road for other things.

But we help balance the priorities with the engineers of why something is important, why something is, and how to fix it. And not only that, I also manage engineers myself and we build tools, we build things to help improve how security is built into our products, everything included in to it, all the things that go into that.

Justin Beals: So you have, you have the product engineers that are part of your constituency. You have your own team. Are you managing the business expectations as well that there must be a certain amount of. Tension at times between security being perceived as a blocker for getting something out the door. We just talked about CrowdStrike.

Naomi Buckwalter: Oh yeah. I mean, you said it, I mean, security is a service for the business. We do not exist without the business. So we always have to understand that the developers are the stars. They are the ones that we're trying to serve, essentially. I mean, if you put it that way, and, and the business is the same way.

The business. Has their needs, they have their, and we can influence, we can advise, we can guide, but at the end of the day, they own the risk. And it's the same way for the developers, the product managers and the leaders. We have our frequent meetings. We talk about risk. We talk about priorities. We talk about importance and we make the case.

And the advice and the guidance for fixing certain things or improving certain things, adding features and such into our software. And you know, we come to a conclusion of, yeah, we're going to add this in for this quarter or we're not. And you know, and this is the reason why. And it becomes a conversation.

So back to your question, Justin is like, you know, how do you have those conversations? That's exactly what it is. It's a peer to peer respectful conversation. If they understand where you're coming from and I understand where they're coming from, it becomes an exercise. In conversation, in communication, and my personal thought here is that the root cause of 99 percent of all problems are communication.

It's like a communication issue. Think about any issue that you might have currently in your life. 100 percent guarantee, 99 percent guarantee. The reason for that was because of poor communication. So at this point I am working very, very hard on getting my communication down, whether it's being clear and precise at not using big words as a big one, get in that trap a little bit, especially coming out of Vanguard, which you're just talking corporate speak the whole time without saying anything.

You're literally talking for like an hour and you're not saying anything, you know, it's, it's practice and the way that anyone can do this. You read books, you watch other people do this, you practice. And that's, that's a growth mindset that I think a lot of us might be lacking insecurity. And the more that I talk about this, the more I'm convinced I'm like, yeah, we need to put our ego aside sometimes and work with the business, work with the developers because they, at the end of the day, they're who we are serving.

Justin Beals: You have a word in one of the talks that I was looking through called secsplaining. Can you describe this for us, Naomi? And 

Naomi Buckwalter: that's S E C S. S 

Justin Beals: E C S, yes, absolutely. Security explaining, yeah. 

Naomi Buckwalter: Yeah, that didn't sound right, I guess. 

Justin Beals: Oh, I thought it was right. 

Naomi Buckwalter: It's hard to pronounce that one. Security explaining.

Let the record show. 

Justin Beals: Yeah, 

Naomi Buckwalter: I mean, it's I think it's a little self explanatory here. It's a little bit a play on words security explaining Especially when you put it against some of the cultural issues that we go through a little bit, but security explaining if a security person is talking to a developer, they already know their code base better than you ever will.

So if you're sitting there and be like, this is what your code base is doing. And this is why this is a problem. They don't need to hear that. In fact, they're actually turning you off. So, in the meetings, they see you, they hear you, but they don't respect you. Right? So there, there's a level of understanding, a level of self awareness.

If we are doing this secsplaining, that means we are probably losing. Our audience, we are losing the hearts and minds of  our developers. Whereas we would be wanting to win their hearts and minds. We want to give them good things. The benefit of working with security is for them to understand how to mitigate something.

And so we as security people need to work where they are and understand their jobs and understand how software is built. And if we just sit here in our little high castles, And just be like, well, the scanner said that this is a problem. Obviously you have to fix it. Like. No, no, that's not the way the developers work. They know you don't know what you're talking about because you're just running a tool. 

they want, and this is what they need from you. They want you to understand their job. They want you to understand how software is built in the year of our Lord 2024 because God knows it is way different than when I started, which is, I don't know, Justin, how long you've been in the software development business.

Justin Beals: Too long. Too long. Long time. 

Naomi Buckwalter: It is not the same. 

Justin Beals: It's not the same. Well, I think to your point about engineers as a culture, whether security engineering or software development, right? Really, a lot of our sense of power, I think, comes from being knowledgeable, you know, if you're, if you're an architect or a software architect or an engineer, you are knowledgeable about something.

And usually people are querying you like, I want to build this product or can it do this thing? Or is it possible that is it possible question happens all the time to an engineer, whether it be a security engineer or any form of engineer. And I think. We self value when we're able to answer those questions, right?

So, if someone is security splaining back to someone else in a way that is obtuse, especially to another engineer, it's an immediate turn off because you're  like, you're not seeing your own value. represented in that person's conversation. 

Naomi Buckwalter: That's a good way of putting it. I hadn't considered that. Yeah, because it's a little bit about egos and I get that. I get that. I would say that it's probably, oh, oh, here's a good one. Have you ever read the book, The Five Dysfunctions of a Team? 

Justin Beals: I haven't read it, but it's now on my list. 

Naomi Buckwalter: Oh my gosh. Patrick Lencioni, hopefully I'm pronouncing his name right. But he writes these fables and tales through the lens of a business book. It's interesting. 

Anyway, so five dysfunctions. The first dysfunction is lack of trust. And so the thing here is if you are very unselfaware, like you just said, Justin, like the security person. It's not really aware of themselves and they're pushing out these thoughts. Whereas the person receiving these thoughts are like, well, you're crazy.

So that's that level of trust because you're not really being vulnerable in the moment. You're only just saying words. Not understanding how they're received. You're not being aware of yourself. And that  low level of trust, neither the two people, the talking and the listeners, the talkers or the listeners, nor the listeners, they are willing to give ground.

They're not willing to step back and be like, Oh yeah, my ego isn't in the front. I don't need to protect my ego at this point. Because, I trust these people. So that first dysfunction, which is low trust, if you can get over that. I trust you to not make me feel like an idiot because I really don't quite know how you do your job, how you build your software, but I am willing to learn.

 That is that first mental hurdle that I had to go over because as a, as a very basic, like a new person in information security, I did feel like I had to put on that armor. And just be like, I  do need to know everything, even though deep down, I was like, Oh no, I really don't. But the more I was able to just say, Hey, I'm taking off this armor now. 

I'm willing to expose myself and understand that that's okay. I can learn. I can, I can find things on the internet. I can take courses. And by the way, during my time at  Vanguard, that's when I got my master's degrees. I got one in computer science. And I got one in technology management. And so understanding those things now, I'm like, Oh, I can learn this stuff.

It's not that hard. Anyone can learn this stuff. And that's where the thoughts, the wheels were turning. I was like, Oh, okay. If I can do this, anyone can. You just have to get over this mental hurdle needing to be the smartest person in the room. Oh, and that's another, that's another book. 

That's another Christian Espinosa wrote The Smartest Person in the book, in the room, sorry, “The Smartest Person In the Room”, Christian Espinosa. He wrote a book about, uh, the reason why we are losing the war on cybercrime is because we need to be the smartest person in the room. There's a whole book about that. So a lot of these ideas are not really my own.

I'm just finally taking them in and, and, and like letting them sink in. sit uncomfortably within myself. And then finally I'm like, aha, like to me right now in this moment in my life,  this is where I am. 

Who knows? Maybe I'm wrong. Maybe in 20 years I'll be like, Oh my God, Naomi just tried the world because of her stupid LinkedIn.

Justin Beals: We'll make sure  these books are included in the show notes because it's certainly impactful. Yeah. You know, you have a phrase I read in one of your talks that I think speaks to this relationship between security engineers and, and perhaps the software development team, which is. A fight for us, not against us.

It seems in line with that idea that if we have trust, I believe security is helping us be better, right? 

Naomi Buckwalter: Yeah, yeah, trust is a huge thing and you got to trust those developers to do security, but you still have to give them the tools and the requirements, give them reasons for doing things. The engineers wants to do security. I mean, Justin, how many of your developers don't want to do security? Right? Zero. Hopefully. 

Justin Beals: Yeah. I don't think any of them don't want to do security. And, uh, they have a great leader. I, I don't get to chat with them as much as I used to at prior roles. But I think, I do think that. It's interesting. I think engineering teams, in my experience, think less about security and more about tech debt.

They do think like a conjoinment in a way, like bad security is when I'm unable to figure out why a bug has happened or some vulnerability was created that I was absolutely unaware of. And I think that's why we have a shared core belief in change management as being a critical part of the security practice, because I, I do think the CrowdStrike, uh, issue is a security incident at the end of the day, right? Like, effective change management is good security. 

Naomi Buckwalter: Agreed. Actually, that's one of the, in my belief system here, one of the fundamentals of information security is good change management.

Okay. I mean, configuration management, change management, yes. Access control, asset management, oh gosh, I can go on and on and on and on and on and I won't. 

Justin Beals: Well, one thing  that I would love to delineate a little bit, and I, this wasn't a practice when I was an engineer. So, I think this is something you've been part of developing Naomi in your work, what's the difference between a secure architecture review and a secure code review? 

Naomi Buckwalter: Ah, good question. Okay, so here's a quick little lesson for anyone who is not currently doing this, but within the lifecycle of software, you should be doing security activities. So secure code reviews is a security activity or a thing that has security in it that happens at the end.

So this is after implementation, possibly prior to any tests. That you're doing. Although I think test should be included in a good secure code review. But security architecture reviews happen before the implementation. So, as you are settling on your architecture and you've decided on some, the, the data flows and the system flows and all the things and components within your infrastructure, that is when a good security architecture review happens and you are reviewing each one of those components and how are they are talking to each other and where the risk might be within the entire system as a whole and so a security architecture review reviews the architecture system and how secure it is. 

So you always go through the basics, the CIA and also non repudiation and good stuff like that, logging, monitoring, confidentiality, integrity, availability, non repudiation, we've got logging logic. So we have a bunch of buckets and we ask the questions and we go fairly technical into it too.

But always knowing that the engineers are the experts in those things. All we can do is really help them help guide their conversations and their understanding of their own systems. So we ask the questions. 

Justin Beals: Yeah, that's an important distinction. You're not answering the questions. You're not necessarily saying, This is insecure, I've looked at your code and I think you have this issue. It's more that you're helping them run through an assessment. 

Naomi Buckwalter: Oh, yeah. It's like a self awareness assessment. Yeah. 

Sometimes, sometimes it does  come down to, like, an actual guidance, like, this is the way you should do this, but in many cases, they're going to be the experts in that thing.

So, in general, it is sometimes a little more generic, but we do bring out the risk. So we, those conversations, those architecture reviews, is a conversation between the security team and the engineers and the architects, and we talk about where the possible risk is, and if there isn't something that they've already thought of, we're like, have you thought about Authentication and authorization at this part of the point, right?

Like, here's the reasons why that you need it. Here, here's some risk. And so to give them that bigger picture, have them understand deeply their own systems, that's what an architecture review does. A secure code review is a little bit different. You're actually looking for fundamental security flaws within their code base.

And that is a little more complicated. But there are a lot of tools for that. There's also manual security reviews that will take a little bit more time. There's also other security activities. It's not just those two things. There's threat modeling, there's a pen testing, there's internal validation, there's just all these other things that we do as a product security team, small but mighty, but we do it. 

Justin Beals: Yeah. And of course you're supporting a security product itself. So it becomes. Doubly important. You probably contrast. Security probably has pretty privileged access to your customers information.

Naomi Buckwalter: Well, no, actually, we do not. We are agent based, so we don't look at data. But what we do is look at the run running application. So so here's a little primer on runtime application. Yeah, we don't really care about your data. We don't store it or collect it in any meaningful way. What we are running it through is our rules engines and reporting any actual risks.

So this is the best part of this, is runtime application always, always, always, not always, that's not true. More than, more than 90 percent of the time, it's going to give you true positives on the flaws within your software. And not only that, but what we do with Protect is we protect and block actual attacks to your application that could be exploitable because we know what's exploitable or not.

And that's, that's really, really cool. It's way better than a static or, you know, dynamic scanner that doesn't really have that context, that level of knowledge of your application that we do. So we are agent based. We aren't looking at your data, we're not collecting your data. So.

Justin Beals: You know, we've had some conversations about the difference between like a web services model with true network segmentation versus agent based deployments.

I'm curious how you feel about it. Like if you were a buyer of an agent based solution, which I would consider like the, the CrowdStrike solution, you know, deploying agents essentially on end points, how do you, how do you think people that are developing agent should think about the security boundary between them and their customers?

Naomi Buckwalter: It's a great question. I love that. Well, I guess it depends, and that's always a wonderful answer. And just so you know, our agent is not running on the underlying, I keep wanting to say hypervisor, but that's the lowest level, right? Right. Where BIOS runs, wherever that's, what's that thing called? What the heck?

Justin Beals: That is good deep in the operating system. Yeah, 

Naomi Buckwalter: we don't run on that level. We run at the application level. So everything your containers on your actual application servers, that's where we exist. We run alongside as a running process. So if you're Java or Java process, we are running alongside your applications.

And we are looking at the ins and outs of everything your process is doing. So that's what we do. But to answer your question, this is how application security people or security people can think about. The questions you should be asking is these, you mentioned trust boundaries. That's exactly it. It's like, do you want to trust the inputs coming from your agent?. Remember, all your agents are, are phoning back home. They're sending back things. So one very basic question you can ask is, you know, should there ever be any untrusted input? And if so, what's the worst thing that can happen? This is where a threat model can come in where you're asking what's the worst thing that can happen if your, our agent goes rogue and is now reporting something, blah, blah, blah, back to us, what, what's the worst thing that can happen?

Can it, yeah. Exfiltrate. Can it ruin the integrity of someone else's data? Can it somehow grant access to other people's data? Like, is there a way to do that? In our case, our agents are write only. It doesn't actually read anything. So it's writing and pushing things. And we have our own, you know, input validation checks.

We do authorization, authentication. We do these things. These are those very basic questions that come out in a threat model. In an architecture review, and if you ever have any questions on, like, how to actually do a good architecture review, there's so many good frameworks start at a loss. By the way, is that open web application security project, which was co founded by our co founder Jeff Williams and Arshan, I can't ever say his name. Achi or something. But those two folks, they help start Oasp. They're also the co-founders of, co contrast. And, and, and Oasp has great references Yeah. And resources that anyone can use. Yeah. 

Justin Beals: Oh yeah. For a long time now, in my career, I've used oasp recommendations for securitization, especially as servers.

You know, that was our checklist. Working with a systems administrator, now a DevOps person. The role name has changed and some of the tools have changed, but similar outcome. So, one other question I wanted to ask that I think you would have some expertise in is, especially where we're talking about application security, we've seen an uptick in requirements regarding, like, a software bill of materials in our security practices. Is this an increasing vulnerability that we're seeing, where the packages and the, and the different libraries that we're using in our application development are, continue to be exploited? 

Naomi Buckwalter: Well, you mean the S bombs themselves are a vulnerability, or?

Justin Beals: Or, actually, that the reason we're having to gather S bombs is that we're seeing vulnerabilities exploited in the packages that make up our software. I mean, I don't think a lot of people that don't code know, but, you know, 90 percent of the software that you put on a server, you didn't write, it was a package that you added to your, your code, right?

Naomi Buckwalter: Oh, yeah, absolutely. Actually, I used to know the actual data on this. We did it, I did a talk and it did it break down. Actually, you estimate it pretty quickly, pretty accurately. I think it's a little less than 90%. I think there's still like 15 percent is still custom code, but you're right, like essentially 85% of all software is third party dependencies, free open source tools. 

Justin Beals: Yeah, that's better than my guesstimate. 

Naomi Buckwalter: It depends on the language and framework, obviously. But like some of the bigger enterprise software, uh, written in like those enterprise frameworks and languages like Java and NET, those are absolutely based off of a Core library and then borrowed libraries like think about anything.

I don't have to write this if I could just steal it now I forget what your actual question is but with the S bomb see the no, this is interesting There's a lot of history behind this but s bombs have always been a great idea I love the transparency and even the White House has issued an executive order, I think, a couple of years ago, uh, what is it? 14028 executive order. 

The idea is to, to show, share like software companies can share with their consumers that they care about security. That's essentially what it is. It's like an accountability tool. Like it's not, it's not meant to be exploitable at any point. It's like, Hey, we're, we're giving you the list of software dependencies that we have,  and then maybe their version numbers, and then maybe on top of that, maybe the open CVS or that, like maybe, right? Like, so I could see some companies be like, no, I would never, but if you don't know the exploitable routes. If you can't actually point to the library and here's another one. There's, there's different as sponsors, like runtime, that's fun.

Like here's the software that's actually running within your software. Like here's all the things. And then like everything else, like static and things that are just built, but not running,  that's, another thing. So, uh, it depends on what the companies want to do, but we are very proud to publish our response, our runtime software bill of materials on our public site. You can actually take a look at it. And that's something our team actually does. My team created  a tool. We did our security composition analysis, SCA. We run our own internal SCA tool and we generate as bombs of all our major products and all our agents, and we publish it on our marketing site.Crazy.

Justin Beals: Well, it's has been a real treat to get to chat with you today, Naomi. Thanks for all your hard work in both security and kind of creating a working space that is welcoming to those young and career people that want to get involved. It certainly makes me feel like we're building a better tomorrow together.

Naomi, thank you for joining us on SecureTalk today. 

Naomi Buckwalter: Thank you for having me.