Security In Small And Big Organizations - The Hyphen Between Security And Dev With Amanda Honea-Frias

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

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

Welcome back to The Secure Developer. On today’s episode, Guy Podjarny, President and Founder of Snyk is joined by Amanda Honea-Frias. Amanda has a great personal journey on how she got into security. Starting off a unique career with roles ranging from construction, DevOps, network engineering, technical support, pen testing, all the way to building and evolving application security businesses. She has been on the team at several enterprise companies such as Belkin, Amazon Web Services, Duo security, and most recently, the Cisco Security & Trust organization. We really hope you enjoyed the conversation and please don't forget to leave us a review on iTunes, if you enjoyed today's episode.

[INTERVIEW]

[00:01:38] Guy Podjarny: Hello, everyone. Thanks for tuning back in. Today, we have a great guest to talk to us about being that hyphen between security and dev, which is a whole topic on its own and also, I guess, sort of a great personal journey about getting into security. I'm excited to welcome Amanda Honea-Frias, who is a technical leader and a security architect at Cisco coming in through the acquisition of Duo into it. Amanda, thanks for coming on to the show

[00:02:07] Amanda Honea-Frias: I'm really happy to be here. Thanks for inviting me.

[00:02:09] Guy Podjarny: Before we dig in, and unravel some of these statements and others that I have mentioned, tell us a little bit about what you do and how you got to this place. What was your journey?

[00:02:18] Amanda Honea-Frias: At heart, I am a technologist. I've always wanted to, well, play with technology. I never actually wanted to work in the technology space. In fact, before I started my career in technology, specifically, I was working as a construction worker. I was an apprentice fourth generation. I was very proud, very happy, very ripped too, by the way, not so much anymore. But I got injured —

The only thing I knew how to do was to repair computers, fix computers, whether it's networking or whatever and this is during the mid to late portion of the dot com era. And what I did was go into – let me step back a minute. I actually was not informal — I did not have any formal education. I received my GED here in the US because I was homeschooled. And the thing that I learned how to do was hack, because we had stuff like The Anarchist Cookbook, I did not make bombs, however, I did learn how to make the beige boxes where I could steal my dad's landline so that I could host a BBS and all that other stuff without him knowing. But nothing nefarious.

Those skills were my fallback. So, I went into a computer shop and said, “Hey.” It was Microtome Computers at the time. In this little shop in Salinas, California, downtown. And I said, “Hey, I don't have any formal experience. But I will fix whatever you want me to, give me two weeks, but you're going to hire me in a week, and I will completely volunteer.” They hired me in three days. And from there, I started gaining more experience, ended up getting hired. And I was very lucky because I found people that just saw something in me, that lifted me up. They were very good sponsors, and hired me in the Silicon Valley as a network engineer. I'm actually a network administrator and then I graduated to network engineer.

Since then, I've held roles in various, well, pretty much every spectrum from network engineering to software development, quality assurance. I've led and directed support entity — specifically for Reno equipment, it was back in the day for PBXs. And it led me all the way to, I

think that was about 10-year block-ish, and then I hit Rapid7, and I fell in love with the security space. I was like, “This — is something amazing.” And this was of course, you know, when the vendors were starting to get really hot, and being able to provide services for people that really needed to start understanding how to secure their systems and networks. And from there, it was a whirlwind and I ended up going into leadership. Well, I've had various interesting managers, but I've been very lucky with having so many good ones. And I saw so many people suffer from not having really good leadership or management, that I wanted to be a part of the change.

About a little over 10 years ago I started going down that track when I took the role to level up. When I was at Belkin, specifically, we had just acquired Linksys, we had a hot new IoT brand Wemo. And I was like, “I'm going to do it, let's just figure it out.” So, from there, I haven't looked back. And then recently, fast forward a few years ago, I joined Duo, left AWS, and I fell in love with the company. I moved from Seattle to Austin, sight unseen, just because the company culture. From there, we got acquired by Cisco. I was a little leery of it at that time, because I knew it was a big, big company. But man, I'm drinking the Kool Aid, and I actually moved from Duo, I was leading the application security portfolio specifically for Duo most recently as the head of product security. And then I moved over into security leadership specifically for architecting different services within our Cisco secure development lifecycle.

[00:05:54] Guy Podjarny: Well, that's quite a journey. I'm curious on the transition from fixing computers at a shop to the network, sort of sys-admin, to kind of, I guess, getting your first job at the high- tech company, or you said, moving to Silicon Valley. What sparked that difference? Is it just you found a job application online, and you kind of direct applied to it? Is it something else? It feels, to me maybe for my familiarity with the journeys, that's the one that's one of the most unusual steps there, not to mention the construction to computers, which has its own respect.

[00:06:26] Amanda Honea-Frias: So, I grew up in an underprivileged area. It's a little farm town. My family were pretty much evangelicals. So, they did not believe in higher education at the time. I did not know how to get into college. I didn't know who to talk to or anything like that. So, all I knew how to be was scrappy, figure out what the next opportunity was, and it took me a good deal of time, probably like half of my career to figure out really where I wanted to spend my time. And overall, it was that wacky and crazy journey, and just looking for an opportunity, any opportunity, and I had to give up a lot. I gave up my family. Everything I knew, to move away and to better myself,

and it's not an easy journey, right? To get out of something that like, it's not easy. People say, “Oh, when you don't have the necessities or the ability to up level yourself, just move.” It's not that easy. I’m proof of that. But it's possible. That really was it. It was the necessity to be more than I was, and I didn't know what that more could be.

[00:07:32] Guy Podjarny: I think that it's not easy, but you're also an example of doing so and you know, doing so very successfully. So, definitely much to be learned from that shifting. I could probably talk about it the whole time, sort of the personal journeys is really interesting, maybe let's sort of explore a bit the professional paths here. Maybe, we'll start with the company and we'll kind of we'll go more into kind of the personal evolution here. I'm intrigued by this Duo in Cisco to a broader role that Cisco that you recently took on. Security is oftentimes different in different sized organizations or other security practices and how do you apply it. Maybe we can start with the first one, the sort of Duo to Duo at Cisco.

You're at Duo, you're doing security, what had to change and how to be successful in securing Duo versus securing Duo in the context of Cisco?

[00:08:21] Amanda Honea-Frias: Sure. Anytime you are part of an acquisition, and you're merging your things into a large organization, it takes time. There's multiple phases and things of that nature, and it has to be done with care, because you don't want to break the products, you don't want to break the people, you really want to have that package that you purchased from Cisco's perspective intact and bring in cultural additions. I mean, they very much so enabled us that way from the get go.

To be perfectly candid, as soon as they acquired us, they started switching, how they did some core things in acquisitions. And also, we were able to help pivot in very critical areas, or different cloud offerings and portfolios that Cisco has publicly been pursuing. You know what I mean? And from there, we had a lot of scrappy ways. When you're in a startup, whether you're going IPO or looking to get acquired, or whatever the case may be, we were actually looking to go IPO. We were going full force. And then there was this opportunity that Doug took and pivoted, and we all went along with him, because Doug is great, if you've ever had a chance to talk to him or meet him. If not, you should — delightful person.

In any case, as far as like the security port posture and things of that nature, we were very mature already, because security came first at the core of Duo security. We lead with empathy and everything, even the hard sciences. With data science, actually implementing any of our controls within security and security features, et cetera. Not to mention the foundation of the actual products themselves. With that said, no program and no company is perfect. That's just how it goes.

We had a lot of learning to do specifically for scaling our business and programs, because Cisco has that scale, but they also have a lot more different types of security groups to work with. So, that diversification had already been underway with Cisco for quite some time, we just were able to add our voices to that a little bit and they welcomed us to do so. It was not like one of those acquisitions where it's like, “Okay, thou shalt plug into every single thing we have, we will monitor everything, your security team is now reporting to us, blah, blah, blah. We know better.”

Not like that at all. We both came from a very specific, let's learn together and let's build that bridge. I know, it's a marketing Cisco thing, but the reality is, is that that's what we do internally.

[00:10:53] Guy Podjarny: Did it affect the independence of teams? I know, that Duo, having spoken to Mike before, and various other folks there, Duo was quite empowering, I think for the dev teams. A lot of control over there. Sometimes you go into a larger organization, sometimes developers are not equally empowered, there might be more powers to be or more corporate requirements that are a bit less immovable, or even just sheer dependencies across dev teams as well within the org. How much did that play a role at all here? And did that change how you need to, I guess, help them build something secure?

[00:11:28] Amanda Honea-Frias: No, it actually has not changed. Duo and its culture has stayed intact, and I would say, it's an addition. It's Duo plus Cisco, or Cisco plus Duo. Either way you swap it. It's a win-win situation, in my view, because the developers develop Duo products. We find integration passing points, and we brought zero trust strategy, specifically to Cisco that is powering forward. I think that there's a really good story here to say, you do not have to be the giant. What is that Jonah and the Whale, right? You don't have to be the whale and Jonah being swallowed, at all. I don't think that that has to be an option. I think Cisco did a really good job at allowing us not to basically screw up the products.

[00:12:14] Guy Podjarny: That transition sounds like it went smoothly and you kind of continued to the sort of empowered approach and run that. Now, you're taking another step. You're going into into the broader Cisco organization that maybe hasn't really had the Duo roots that you came along with. First of all, maybe you can tell us a little bit about the new gig, and how do you expect. I know you're reasonably new to the role. So, maybe it's not how you're doing it, but rather, how you plan to, but how do you think you'll approach it differently, if at all, given the sort of the broader audience from different backgrounds?

[00:12:45] Amanda Honea-Frias: Yeah, it is definitely different, because the whole spectrum is the team that I've gone into specifically is, it's around servicing and making sure that we have controls that meet the customer needs. So, our customers, our developers, for example. And we want to make sure that they have that paved path to get to our paved road, to say, “Hey, if you have any potential mitigations, we will help you figure that out. We have tons of resources and things like that built over time.” But part of me coming over as well is assisting with a deeper understanding of some of the cloud security models and shifting how we're thinking about different things. This gets a little like, I can't give too much information, but what I can say is, I am being tapped to assist in architecting very specific and pragmatic work streams, to enable our business to move faster in an industry where the security keeps changing, whether it's on prem or in cloud, and how do we actually make sure that we're bringing those modern processes and procedures, and marrying those with how we're designing things.

It's really letting me use a lot of the tools in my backpack from designing and my experience and working with designers specifically, working with engineers, PMs all across the gamut, and going in, and while we're architecting, whatever those support services was to be, how can we ensure that the security controls are right, that we're also tying back into any potential compliance needs to build trust and make a success overall and rule the world?

[00:14:23] Guy Podjarny: Yeah, well, that's always a good destination on there. Let's get to concrete here a little bit. So, like, what are some examples, for instance of practices, you've sort of seen, maybe work in the past or whether at Duo or previously and you think you'll try to apply here or generally, you find them to be maybe not obvious to people, but quite impactful?

[00:14:44] Amanda Honea-Frias: When I usually go in, and this is just a pattern that I have. So, spoiler for anybody that's going to work with me or has. Generally, I build empathy, understand where they are, how they are working, whether it's a developer, PM, or somebody on my team that I'm working with, et cetera. Understand the history of the things that they know about the things we're working on, especially in a large organization. For example, I'm paired up with a nice chap, in my team, my boss, I love him. He put me with a very senior individual, specifically, he's been around for a while, knows so much about maybe the dead bodies that are buried and stuff like that night.

[00:15:18] Guy Podjarny: In the security org or in the development?

[00:15:20] Amanda Honea-Frias: In the security org, because he's also been a developer and everything else there too. So, I get to build empathy. For me, specifically, I am getting to build empathy, not just with him, and understanding how all these decisions were made, and everything else. And together, how we can evolve them over time as well to meet the pace of business. But then, it's building empathy for the company. One of the things that I've experienced within Cisco, that I think is beautiful, is everything that's been worked on is associated with a person. When I'm talking to these people about the history, that in itself builds an emotion, for the people that are actually working on the things, and that's something that you can't just make up. It is not something – I mean, that's just a testament of the culture.

For me, that helps me to anchor on understanding the company, the projects, the people in such a different way, and empathy is one of the biggest things in my portfolio.

[00:16:17] Guy Podjarny: What do you mean, when you say everything that you work on is associated with a person? Is that sort of your view or is that an actual practice of mapping?

[00:16:25] Amanda Honea-Frias: It's not a practice of mapping, but it's something that I've noticed. When I talk to people that have been around for a while, they're like, “Oh, so and so, I believe it was so and so that worked on this in 1995.” Which was a project that probably nobody remembers, but they do. The fact that we have these tethers, this gets into so many like diversities and different types of issues, where we want to move, move, move forward, but we never learned from mistakes of the past, because guess what we all know, Cisco has made some, every single company has

made some, but they learned from it. And this is how they try not to make sure that they're making the sins of the past. And that's something I have not seen in a company that I've worked for before. I think that's amazing. Does that clear it up a little bit?

[00:17:09] Guy Podjarny: It does, yep. It's a part of the fabric of this specific one. So, if you back, your MO is, for starters, you're trying to build empathy, and you do it through much of these conversations and understanding of other people's point of view. And in this case, there's a lot of that type of human trail that you see with everything that's been built.

[00:17:30] Amanda Honea-Frias: Exactly, yes. And to cap it off, you have to bring your A game. You have to know what you're talking about, you have to be technical, and you have to be able to understand and learn and also be able to share, because you can't just make it all fluff. You actually have to bring brass tacks, this is what we're trying to pragmatically achieve and bring goals and things of that nature.

There's always got to be a structure to all the feely things. I have high EQ. I think you could probably tell, and I have to kind of not weight myself down, but balance myself to also bring in that technical side. So, sometimes my EQ can shut off a little bit, and I go very logical. So, I have to watch that. So, there's also pros and cons to that, too.

[00:18:13] Guy Podjarny: Okay, so you understand the lay of the land and how people operate, and you build that empathy. What's kind of step two? And you know, maybe again, maybe in this role, you're just coming into it, but if you look for instance, at past projects at Duo, what are some key solutions or conclusions that this led that you think are ones you kind of you remember, and you might apply, again, anywhere from a practice, I don't know, what I'm really kind of asking for right here is from some core practices or approaches that changed.

[00:18:44] Amanda Honea-Frias: I would say, for me, I'm having to learn a new way to organize myself differently, because it's a different pace than Cisco. Other than, you know, in a core cloud company, your move very fast, and you just keep going, going, going. I'm sure you're aware of this. And I got used to that pace. So, when I'm over here, there's so many things to do. I need to prioritize that, appropriately. And I look at my prioritization rubric differently. I had to adjust that. I'm still adjusting it because I'm still trying to find my butt. I don't know where it is yet. But I'm

saying things apparently, people think I sound smart, “Ha ha ha!” Fooled you. But I'm still trying to figure that out in this role, because that's what I do. I need to adapt. That's I think the key portion there is adaptation to the surroundings and the new topics that you're going to be covering, because what I'm going to be covering is going to be so much more than just cloud security itself, or things surrounding it. And that's what I'm looking forward to and expanding my journey.

[00:19:42] Guy Podjarny: For sure. But then, that adaptation, that's actually like a great negative view around just the different time horizons and maybe relates to sort of my comment before about the number of parties involved. Part of it is the number of people but also a lot of it, just the different pace of moving the beast forward. Maybe talking a little bit about making that happen. When we spoke before, you used kind of that quote at the beginning, you said that you see yourself as being the hyphen between security and Dev, and we talked a little bit about relationship between developers and security practitioners. What's your view there? You've already talked about how empathy is important. So, I assume that's a core element to it. When you kind of get down to concrete interaction, what do you think works well? How do you interact between the Duo security organization, its developers, and maybe even applying it to the next situation here?

[00:20:32] Amanda Honea-Frias: So, to be clear with empathy, empathy is only a value if you leverage the outcomes and value from it, meaning I build empathy, let's say with you, Guy. I am building empathy with you. So hey, I could be on your podcast. Just kidding. In reality, we want to take that empathy and put it to work. It's a means of influence, not manipulation. Let's be clear. How do we work together and understand one another? It's not just me building empathy with you, per se. But it's also allowing you to build empathy with me. And even if you don't know how to do so, trying to help you in a nonchalant way of doing that. So, that we can come with an outcome that will benefit both of our agendas, because business is full of agendas, full stop, we have to get work done, we have to deliver results. That is how we make money, that is how we survive and get our paychecks. It's just a whole ecosystem.

When you're building that empathy, you take it and you build plans. You actually make that into something that is more of a learning discovery thing that you might need to do to figure out how you guys find out more information or whatever the project is. I think just the short answer is

having an outcome for what you plan to do with that empathy. And then also building it into your plan specifically for the outcomes of that, to build out your program or something that you're going to be coding or whatever the case may be with whatever layer that I would be talking to at that point in time. Does that make sense?

[00:22:05] Guy Podjarny: Yeah, it does. But then, I'm still kind of pressed for details, if you will. So, in practice, we're talking about empathy, you have those departments, you're driving it, maybe we go one role back, and think about Duo leading application security. Tell us a bit about what that org looks like, and how does the interaction occur between the app security team and the development teams?

[00:22:31] Amanda Honea-Frias: Specifically, talking to the developers. I'll give you the example that I've lived and then my opinion after the fact that's more global. So, specifically, Duo security is set to, they’re still performing this way, they are set to talk to developers at each and every single phase of the software development lifecycle. Developers have a channel directly to them, they have the ability to just – well, when we were in the buildings, pre COVID, it was, “Hey, AppSec, I have an issue.” You go and walk up, right? Now, you can do this with a startup or a company that has a few hundred developers like Duo and it's not thousands. So, this is when scale problem comes in.

But having that direct connection, having lunch and learns, having office hours, and really talking to them and where they work, how are these security mechanisms, whether it's automation, its security reviews, et cetera. What do you need to do your job to not have to think about security? They still need to think about secure development, but for the controls that we implement, they should not have to. Customer support comes in here, because modern security teams have support functions, or the ones that are able to work in that area, because not all security engineers are extroverts. Not all can play extroverts. So, that's something we need to honor.

But for those that can, building those relationships, heck, going out for coffee, treating them like actual peers, instead of segmenting security away from development. Because guess what, security engineers are not experts of the product, the developers are, and we need to get away

from that elitist attitude, saying that, “Well, I am the security expert. I know all. You do as I say.” That is not ever going to work. So, specifically at Duo, that is counterculture, that latter.

Basically, keeping the channels open, sending surveys is one. Any way that you can get feedback, or talk directly to developers on what they want, instead of what we want. So, I would say that that is a really good foundation and something that made me very happy that we were able to implement.

[00:24:43] Guy Podjarny: If I go back maybe to the beginning, in channeling those, you come into a surrounding that requires probably more compliance. What you described right now is Duo as a group. Is it really the same that has occurred in the context of Cisco? How do you balance the requirements of compliance with this, I guess I'm trying to find a different word than empowerment, but it comes back to that sort of empowerment in the surrounding?

[00:25:14] Amanda Honea-Frias: Compliance and security serve two separate functions. Compliance builds trust with the customers. They also make sure that we are following and we have the appropriate artifactory, specifically for meeting ISO 27,000, PCI, etcetera, security. Good security will always lead to being compliant, because if you are looking and threat modeling the things in a pragmatic way to benefit your customers, make sure that you're not allowing X fill up their data, make sure that you know, everything's encrypted at rest, and in transit, et cetera, you're going to be able to hit a control. Sure, there might be very wonky things that you have to set up a DMZ for, whatever, but that's not going to be the hard work, right? Building secure code will always lead back to customer trust. Instead of leading with compliance and trust, we're doing it backwards. And this is this is like my little soapbox. Always build for secure controls that makes sense for your product that are risk based, instead of just meeting a control, because if you just made a control, guess what, that is not full coverage.

[00:26:25] Guy Podjarny: Yeah, being compliant doesn't mean you are secure. So, in this process, and then, I imagine when you do that exercise, there's a translation exercise. So, you work with the development teams, you help coach them to build an actual secure product. Somewhere down the line, if there's an exercise in demonstrating your compliance, is the security team the one that is responsible in connecting those dots and translating maybe the concrete on the ground,

the security controls that had to be there, how do they satisfy the compliance requirements? Is that another team?

[00:26:59] Amanda Honea-Frias: Product security shouldn't get into that. There are individuals that are product security savvy, that are in the trust and compliance groups. But generally, and I haven't seen any large organizations where they combined both of them, in general, they usually have like a different GM and all that other stuff. The same is here as well. Duo has always separated the two but work together. I mean, there's a difference. There is complete separation in ivory towers, or there's separation with bridges, and we're trying to do the latter here at Cisco.

[00:27:27] Guy Podjarny: We've been kind of going down this journey a little bit about sort of the small and big, talking about the empowerment, definitely a lot of emphasis on empathy. And there's been a lot of conversation here about getting people to come along for the journey, although a lot of your focus has been on you understanding them. So, you guide them accordingly. When you kind of talked about whatever the whirlwind that pulled you up once you got into Rapid7, you talked more about leadership, and then necessarily management. I think in our previous conversation as well, you talked about seeing yourself a bit more as a leader than a manager. How do you see the distinction between those, especially here in this in this context of mobilizing the organization to be secure?

[00:28:05] Amanda Honea-Frias: Sure. So, when you talk about leadership versus management, to me, it's two different focal points. One is managing of the things, maybe the programs and projects and things of that nature, the other is leading people. Leading people is interesting, because you can't just say, “Hey, I want to do X, Y, and Z. And even if you don't agree with it, just do it.” You got to have people that are passionate about and have a mission, whether it's small or big, it doesn't matter. Whatever team you have, you want to have an outcome that is impactful. What is the best way to do that? You put your heads together.

I remember growing up and watching the Disney Channel and watching this, I don't remember what it was, but there were little ants that were trying to get a grape. There was one trying to jump and jump in it couldn't get it. And then finally, there was another one that comes up, jumps on his shoulders and grabs it and they share it. That to me instilled something really amazing that two heads are better than one, right? And that's the same thing for leadership, because

whether I'm a manager, a technical leader, or something else, even just an IC that is doing heads down work, no matter what, I always fall into that leadership category to how do we all get together to make sure that our impact is better, and multiply it.

Now, when you're managing, it's how do I get these resources to work to get this deliverable? Which one's going to multiply better? And that's just my experience in how I've applied myself. Now, there probably is a guaranteed alternate ideation on this, which is just as valid, but just from my experience, that's what I've seen in the difference between managing and leadership.

[00:29:56] Guy Podjarny: And how much do you think you need to be a manager of people to lead or like, does it help, does it hinder for you to also be the boss of those folks, to also be able to produce a bit of more of an edict of this is what you're going to do?

[00:30:12] Amanda Honea-Frias: Again, adaptation. You have to adapt to the situation. Some people are not as freewheeling and they do need more very strict guidelines. They need to be handheld a little bit. And that's okay, you should be able to facilitate as a leader and a manager. But for the most part, it's teaching somebody how to fish. How do you build more leaders? I don't want to think for them. For example, I'm not ever the smartest person in the room and I hope I'm not ever, because I'm never going to be learning anything. So, anytime I hired somebody, I absolutely want somebody that's smarter, better, and hopefully will be my boss one day. And I think dropping the ego is how you really achieve some of that, and maybe that's because I came from very humble or my origin origin story is very humble, and I've tried to keep that humility and that kindness, and empathy.

But with all that said, you still need to be able to run your business, because the hard facts are what you push up. But how you protect the people that you're working with and working for and who are working for you, that is how you show up as a leader, because you're going between both hats. I think it's an interchangeable thing, but leading with leadership for me is even when I have hard decisions to make, I take all of the information in front of me and make a decision as fast as I need to. But I don't do it alone and I think that's it, not doing it alone. And the management part is where it is you, it is your butt on the line, you are having to do it alone, and you're making these decisions. For me, that's the clear-cut line.

[00:31:50] Guy Podjarny: I have a bit of a closing question, but before we go there, maybe I'll tap into the analytical part of your brain and there's the EQ, which is measurement. So, everything we talked about up until now is very, I relate to it, but it's kind of fluffy. It's directional. It's empathy. It's emotional. As you alluded to many times, there's a business outcome at the end of it. How do you know if you're doing it well? How do you measure success in leading such a program?

[00:32:16] Amanda Honea-Frias: You check in with your stakeholders. You ask. So, I'm a big fan of surveys. I'm a big fan of meeting with people one on one and say, “Hey, give me the candid information.” Or even in a group, I love retrospectives. As fluffy as I am, in many ways, I believe in very hard- hitting facts, candor, direct, yet respectful honesty, because we cannot become better, until we all can communicate and talk.

All of the fluffiness leads to direct hard outcomes, because it's motivating people on their behaviors, and not just driving people to do exact deliveries that may seem meaningless at times, right? If we look around at the different companies that are successful, people are passionate about what they're doing. What happens when you're a drone, just sitting there doing one thing, the same thing over and over again? Okay, I'm building the website, I'm going to do X, Y, and Z. Okay, I have this thing. It's Check, check, check. But what about when you are really passionate about the thing that you're driving? Being like, “Wow, this is going to get me recognition”, or whatever the motivating factor is. “Oh, wow. I'm going to make my team look really good.” It doesn't matter what it is.

But when you put something that is meaningful, in front of anyone that's working on the project, they're going to want to do more. I want to do more. When I see my team doing well, “Man, they're working so hard. I got to work harder.” And it's to make sure that nothing buckles them. And I think it just creates a sense of meaning. To be honest, right now, I'm looking for a lot of sense of meaning from being so isolated. As we're going forward into the new normal, whatever that will be. We need to figure out how we connect people even more, because without connecting people, what are we building?

[00:34:03] Guy Podjarny: I find this interesting. So, even in the analytics piece, you're sort of taking more of almost sort of social sciences approach to measuring this, you're talking about surveying people, and I guess taking the sort of service mentality or support mentality of things. Do you

feel you're getting the support, you are indeed doing things that are meaningful in terms of making your software more secure? Is that the right way to do it or did I misunderstand?

[00:34:26] Amanda Honea-Frias: Yeah, I don't know if it's the right way to do. That's how I've been successful, I think. But success is also hard to achieve as well. And if you look at the harder data, okay, so how much more I've been able to deliver versus last year, etcetera, etcetera, you can figure out like how many lines of code we write and stuff we're building, all that other measurement stuff. But at the end of the day, what does it mean to me with how many lines of code but change it, maybe up at a level, how many features that were impactful? So, in those surveys, it's not just the fluffy stuff. It’s did you find this Tool X impactful into your workflow?

When we get data back on that, and you see a trend where it's like, this is crap, or this is amazing, or this is okay, then we can actually have some places to hone in who generally, I prefer anonymous surveys, because people will speak up a little bit more, but at least you can actually hone in on your surveys, figure out where in the areas or get even user groups together from your customers, like our developers, to say, “Hey, this doesn't really look right.”

Everything we do should have a community around it, in my weird, wonky brain. Only because I fundamentally feel that everything revolves around communities and building things. With developers, we don't have one just working on it sustaining and maintaining it, we have multiple. With security teams, we have individuals that are helping or supporting, at least in my experience. The development teams, that's a part of that community, right? And then the designers, whatever that project is, that pod is a community. How do you sustain it? How do you make sure that they're churning and excited and thinking about the things that they could build, and then when you think about that, you build in the measurements of how you can be successful? Because it all leads back, no matter what you're doing, always think of measurements, while you're building something. You may not have everything ready, but at least you're going to have a semblance.

I will tell you what, when you build a tool, or an offering, or whatever, without thinking about measuring, how hard is it going to be to put measurements in after the fact? And finding out the data streams, are they going to have the right classifications? Is it a text only data set where you're going to have to figure out how to actually try and measure that? There are so many

random things that can happen without bringing in that. So, empathy, and I'm almost thinking that there's probably a subcategory of technical empathy somewhere. I don't know. Maybe when we get into AI.

[00:37:01] Guy Podjarny: I find the conversation fascinating because it is a different approach. I think if I allow myself to classify it a little bit, or different lens, at measuring the effectiveness, it's almost, like what you're measuring is how well are you supporting people in building something that is secure, as opposed to how well you're measuring security. So, I've kind of encountered so far, three primary means of measuring security. One is measuring the application of a security control, how often is a security control present? Two is measuring the output of a security control, measuring comorbidities, measuring remediation times, metrics that are more the output of the tool. Each of these things has pros and cons. And the third is measuring the efficacy of it.

So, actually, kind of trying to compare it to red team outputs or exploits and the likes. And I think you bringing here a different, it's probably additional, it's not sort of a replacement to the other three, but sort of an additional lens, which is more, if I'm understanding it correctly, more meant to almost like measuring the level of service. Not just service, but like to support and capability on the premise that if you do that, the developer is building the application. They will build measurement of those functionalities, including security mindful functionalities that they built inside.

Take more of a survey approach, take more of an appreciation, sense of accomplishment approach and such. In your questions, your biasing in favor of saying, how well am I supporting you in building secure software? Am I echoing it back correctly?

[00:38:29] Amanda Honea-Frias: I think so. For me, if I could say, I'm going to try and say in one sentence, I feel like when we have products we're developing, when we look at the hard data of we have had a number of deliverables, we have had a number of features added from customer requests, how do we know they are effective appropriately to those customers in that customer base? How does it make them feel? How does it make them connect to the work that they're doing, whether it’s, I don't have to think about it, or I have to think a whole bunch and work around your mistakes, potentially, or this workflow does not work for me?

I think there's a sliver right there, in between, that we need to focus on more and more. A lot of companies are doing so, but that is the impact we want to measure. How is it affecting your life positively? Because if I'm using a tool, like the COVID tools that they have lit up for us to sign up for the vaccines are horrendous, right? Because they've been scrappy. So, when I'm using that, I have been in technology for a long time, I had to figure out and reverse engineer how that actually worked just to be able to try and figure out how to make sure I had the right error messages to know that I was doing something right, for example. That is not a good experience.

However, when I'm looking at, I don't know you use Zoom today, but I'm going to say WebEx because that's you know – when I'm looking at WebEx and I click connect to join, and it magically happens, that means I had a good experience, barring any network issues and stuff like that we're all happy with Zoom and then WebEx and everything else. But the reality is, what is meaningful and will always be meaningful for our customers, and it's always worked for me, it's always working back from the customers and how we serve them, because that's what we're doing. We are providing services. If we can measure that appropriately, and we are making them happy, that's when it matters.

[00:40:29] Guy Podjarny: Yeah.[00:40:29] Amanda Honea-Frias: And then the money will follow.

[00:40:31] Guy Podjarny: There's definitely a lot of wisdom in that. So, before we parted ways, you know, this is like, we can kind of probably geek out on both the empathy piece here and the measurement piece for a while now. One last kind of parting question, as I like to ask everybody on the show this year, if you think about your role, and imagine someone doing that role in five years’ time, what would be the most different about their reality than yours?

[00:40:57] Amanda Honea-Frias: Everything's completely secure. Just kidding. I would say in the current role that I just stepped into, it would be well documented, streamlined, and allow for innovation to work, where we can actually become more research oriented to find the zero days instead of having to, and basically having all of the teams know exactly what they need to do without ambiguity. So, that means that the architect in my role would say, I can architect for the harder things right on security controls and things of that nature, because we do it now. But I would like

at my level, instead of having you to the principle's everybody else, because I am not there yet, trying to figure all this stuff out, but actually allow lower levels, to be able to do that research to figure it out, that we have harder problems to solve, instead of trying to make sure that we're not doing the same stupid mistakes.

[00:41:52] Guy Podjarny: Yeah, that's a good reality to aspire to. So, here's to hoping. Amanda, this has been great. Thanks for coming on to the show.

[00:41:58] Amanda Honea-Frias: Thank you for having me. It's been a lot of fun.[00:42:00] Guy Podjarny: And thanks, everybody, for tuning in and I hope you'll join us for the next one. [END OF INTERVIEW]

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

Bye for now. [END]