Adopting New Security Tools at Scale

00:00:00

Speaker 1: Thank you everyone for joining the Trace3 and Bright Security webinar. We’re going to talk about, today abou,t basically how to select a tool, how to make sure you operationalize it, how to make sure you scale it out in a good way. But first, I was hoping each of my partners in crime could tell me a bit about themselves. Amanda, could you introduce yourself and tell everyone just a little bit?

00:00:25

Speaker 2: All right, so my elevator pitch is I like to start off with with my background in IT operations. That was a really cool experience and kind of understanding what the traditional infosec and IT backgrounds that kind of develop your, your foundations for understanding engineering and security and all these other fun stuff. And then I for a couple of years was an engineer that was really great experience to learn a lot of these DevOps practices and really learning how developers think so that I can understand how to help them secure it and then I went back into a more security focused role. And in these last couple of years that has been really focusing on Devsecops and all things about software development lifecycles and educating everyone about what this really means because everyone needs to do their part in securing the applications. So that’s how I got to where I am today.

00:01:19

Speaker 1: That’s awesome. Gina, do you want to share a little bit about yourself first?

00:01:23

Speaker 3: Well, first, Amanda’s energy for like really securing, like, the pipeline and the entire process end to end. That lifecycle of application security just like, warms my heart. I love working with Amanda on different projects with clients because I know that that client is going to be really get a full aspect of not just like the tools but the processes and kind of how to make it successful because of her experience. And so, Amanda, you’re engaging personality with that. Really just I love I love it. So thank you for those on the panel. My name is Gina Yacone. I am Trace3’s Mountain Advisory or Regional CISO. So what does that mean? It means a lot of different things. So I do help with kind of go to market and things like that. I’m also our security officer for our region. Prior to this, I was working and helping organizations secure their organization through a series of different events, and I kind of met those organizations where they are in terms of their cybersecurity journey. So they needed a risk assessment. Great. But if they needed kind of that full suite of products in terms of risk assessments, tabletop exercises, policies and procedures, awareness training, I helped them with that. So I got to work in all different types of verticals. And what is relevant to you guys is I’ve helped two organizations with kind of transforming their AppSec kind of journey and kind of building in security into their pipeline. So and thinking about that, I’m pretty proud because I do think that it is hard to secure our applications and to really get a great kind of cybersecurity culture with that. So but prior to that, I built a SOC with an organization and our SIM and Threat intelligence platform got purchased by Sophos. And prior to that I was in Legal for 14 years. So I’ve got I’m old y’all. So I got a lot of different things going on.

00:03:33

Speaker 1: No I, I love it. I feel like your skill set and Amanda’s skill set really complement each other. And I’m going to come in and a lot of my stuff’s going to sound just like Amanda. So I’m Tonya Janca, and I’m the host of this fireside chat today, and I’m from Bright, and so I was a software developer for around 17 years. And then I met a hacker and it was just all downhill. He’s like, Look at this. You could do this, you could do that. Let’s smash all the things. And then before I knew it, I was learning how to be a penetration tester. And then I discovered AppSec, and that’s where I belong. It turns out, because you can still hang out with software developers a lot, but you also get to smash stuff sometimes. And so I felt like that was a good

00:04:16

Speaker 1: Compromise.

00:04:18

Speaker 1: For me personally and I work at Bright Security, and part of why we’re doing this is because we met like the people from Bright met the people from Trace3, and I was like, we need to partner with these awesome humans. So and so I was wondering if.

00:04:34

Speaker 1: So.

00:04:36

Speaker 1: The idea of this, this webinar is like adopting new security tools at scale. So if you only have four developers, it’s pretty easy to be like, Hey guys, let’s try this. And rolling it out is like clicking two buttons. But if you have 100 developers or 1000 developers or thousands and thousands, and especially if they’re all doing different software development lifecycles, etc., this could be a problem. And so I guess like first, first thing and I could put it to either one of you, but like

00:05:06

Speaker 1: When we’re.

00:05:07

Speaker 1: Going to buy a new tool, how does that even start? Like, Gina, maybe this is for you. Like, like when does a company decide to buy a new tool and why?

00:05:15

Speaker 1: And how

00:05:16

Speaker 1: Do you advise on that.

00:05:18

Speaker 3: Shiny new thing? Shiny new thing? Well, we hope you know that our organizations are thoughtfully thinking about new solutions, but a lot of times it might not be a tool or a certain product set that they have in mind. It’s more of like the business requirements that they know that there is something in their organization that’s creating a pain for their people and that they want to build appropriate processes and find the right tool to help streamline that process, allow their developers to work as they do best. Right? So we want, of course, always employees to shine and to grow and to really be confident in their day to day. And I think that there’s a lot of times like a misconception that security stunts that because of the usability aspect, you know, that we put something in there then things don’t go as smoothly as we hopefully anticipated. And I don’t necessarily think that that’s the case. Sometimes, of course, there might be some pop ups and things to kind of alert you to some risks. But really, if a tool and processes are done properly, then it should be seamless, seamless, and it should really empower our developers. So when we think about organizations, we really want to think about what are your business requirements or what are your pain points so we can build those kind of use cases out and really think about the uglier, the better in a way. Like really, what is your end goal? What does success look like for you? And make sure that we’re doing it in a very thoughtful process. So I think making sure when you’re putting in any tool, understanding success and your business use cases is fundamental.

00:07:14

Speaker 1: Can I ask more questions about… Amanda, I have questions for you, but I just I’m like, Hmm, I don’t get to pick your

00:07:20

Speaker 2: Go for it.

00:07:20

Speaker 1: Brain Just every day. So. So when you gather those requirements for so, like, we’re going to get a tool and sometimes people will be like, we’re going to get tool blah because they’ve heard of it or whatnot. How do you handle that when… Because I remember years ago, a director saying to me like, Oh, we’re going to do an option analysis between these three products. I’m like, okay. He’s like, I need you to write it. It needs to be about this long. And by the way, the answer is SharePoint, and I was like..

00:07:47

Speaker 3: Of course.

00:07:49

Speaker 1: And he just kept saying, The answer is going to be SharePoint. Tanya or and then eventually they just took me off the project because I kept actually analyzing the requirements and he did not like that. So how do you handle stuff like that?

00:08:00

Speaker 3: So a great question, and it does happen a lot where people either they’ve worked at another company in the past and they’re used to a certain tool and they’re so I don’t want to say narrowly focused, but they really are laser focused on getting that because we’re creatures of habits, right? This is it’s a people business in a way. And so we like what we’re comfortable with. That’s how we would succeed. So people a lot of times go for those tools. There are a couple of things that we do or that I do that when I’m talking to clients from a cybersecurity due diligence perspective, you really do need to look at 2 to 3 tools. So if you’re getting audited that the auditors can see that you actually have evaluated those certain tools. So there’s that kind of compliance, you know, component and really kind of seeing is this the most secure for our organization that we can plug it in? So that is a real thing. So when we we kind of come up against that a lot, but I think I’m going to send this kind of over to Amanda in a way, because she’s really great at getting buy in from the developers. So for me, you know, it’s, hey, listen, you know, compliance, you know, leadership stuff, business stuff, right? You need to look at these couple of tools and I will help them score it. But that’s scoring. And that really buy in really comes from the developers and Amanda is exceptional with that. So I’m going to kind of pass that off to her, if you don’t mind.

00:09:33

Speaker 2: Well, Gina Yeah, so you you talked about understanding what the pain points are, building up those requirements. You have to collect those pain points from someone and it usually should start with your developers who you’re asking to use these security tools in the first place. So for example, if your tool is taking too long in the pipeline, developers are going to probably complain about that or they may skip using that tool entirely and start breaking compliance requirements because the tool wasn’t working in their favor. They have other business requirements that they have to adhere to, get new features out, get new functions out, get these capabilities out to their customers. Well, if you treat your developers like they’re your customers right, they need to be happy to find what works best for them in their workflows. And that’s how you build out your requirements. And so when you take that scorecard to your developers and ask them, Hey, developer, does this meet your use case? Are you pleased with the satisfaction of the results that you’re getting from the security tool? Is it helping you do your job? What you need to do at this point in time of your build cycle? And that’s how you have those conversations. And when you collect that feedback, it’s easier to take that feedback from developers, translate it to your business use cases, and then carry that voice to your leadership to say, Hey, leadership, this is the tool that we need to go with. We heard that you wanted to tool A, but developers really, really like tool B, So let’s go with tool B, and what we often recommend is doing pilot programs, right? You don’t need to necessarily commit right away. You have some time to experiment with 2 to 3 tools. You have time to build that pilot programs. If it doesn’t work out, you always just pick a different tool at a later point. But you’ve at least created the foundation to make it interchangeable regardless of your solution, because you’ve built your trust in your people and you have your processes and the tool doesn’t matter as long as it meets your needs of your people.

00:11:22

Speaker 1: So I feel so, so. Trace3. Could you tell us what Trace3 does? Because then I’m going to ask another question because then everyone will understand why I’m asking the question.

00:11:32

Speaker 2: Okay, great. So Trace3 does a lot. So we are Gina, can you fill that question? You could probably answer it more elegantly than I can. 

00:11:42

Speaker 3: Ya, no, of course. I would say Trace3 has been traditionally considered a VAR or a value added reseller. So a company that resells different technology. So if your company needed a Cisco or Affordanet or Palo Alto, we can help you with that. With that said, kind of the tip of the spear has evolved over time. And so we really are looking at our customers as being their partners. And so thinking about that technology, how can we augment with people? And and processes. So thinking about the full lifecycle, we don’t want to just put in a technology solution if it’s going to fail or be shelf life. So really kind of getting in there, helping them with their business requirements, helping them to make sure it’s successful because that’s how we become a trusted partner. So some of the things that we do, we have a security practice that Amanda and I are part of. We have a cloud practice, we have an innovative practice, which I’m very proud of, and that’s when we get to a lot of times show, hey, here’s the traditional solution and here is this up and comer. You guys should look at a couple of these solutions. So our innovation practice is always just kind of baking out new technology and really thinking about that and bringing it to us to get our attention. So we have we can do staff og we can kind of do anything. So thinking about that processes, people and the technology we’re trying to hopefully be helpful to our clients in that way.

00:13:17

Speaker 2: And to add on to that really quickly, I do want to shout out to my devsecops practice. I love the team that I’m on and our focus is twofold. We do advisory services, but then we also have engineering services because we have engineers on our team. We are an engineering first devsecops practice where we understand what it means to communicate with developers. We’ve we’ve put that hat on, we’ve built code, we’ve built applications so we understand the lifecycle. And so taking what Gina had mentioned about, you know, building that trust in our clients so that we can really understand what they’re going through because the number one thing that works the best is having empathy. When you’re trying to select a new tool, implement a new tool, iterate on the tool or the people and processes that you have to build out this program and achieving your security goals in your organization.

00:14:10

Speaker 1: Okay, so this is awesome. And there’s a question in the chat from Pierre, but I want to ask my question first, then Pierre’s question But it’s a very good question Pierre. So, so I work at Bright and we make a Dynamic Application Security Testing tool. And so we talk to potential customers all the time and they have a list of requirements and your company provides services and products and tries to help them pick the absolute best one for them. Can either of you give me some of the types of requirements or questions that you ask? Because basically lots of people are like my boss said, we’re buying blah. But like, you know, I’ve only ever heard of two of them. There’s like 50 on the market. I don’t know how to decide, like, could you, could you go for just like some of the questions you may get or that you might ask so that you can tell.

00:14:55

Speaker 1: What they need?

00:14:58

Speaker 3: Yeah. I mean, do you want me to take it or do you want to do it?

00:15:00

Speaker 2: Yeah, I can take  this one. So there are a number of questions that that any organization can ask or we can ask because it depends on the maturity of the organization. So some some organizations might say, hey, we, we need a dynamic scanner that will integrate into pipelines. Okay, great. That’s a really solid requirement to start with. And that’s going to whittle away like 80% of your competition right there. So let’s pay attention to the 20% because, you know, integrating into a CI/CD pipeline. So for those on the call, that’s continuous integration, continuous deployment.. delivery… delivery or deployment depending

00:15:33

Speaker 2: Upon how you do it.

00:15:34

Speaker 2: Yeah, it depends on the organization. It’s still a maturing field, but yeah, it’s pretty important to have that because some security tools are just like you install it, you know, locally to your, your, your, your laptop and then you run it. But that’s not really agile. You can’t really scan fast and build fast and deploy your code quickly. If you have to install the application, run it and it takes a couple of hours to run. So that’s another one, scan speed, right? So if your scanner is taking too long, developers don’t want it. Their attention span is, you know, half a day for a feature request and then they want to move on to the next thing. If a security tool is taking too long, they’re going to feel really frustrated. And like I mentioned earlier, either not use it or complain about it. So we talked about where it integrates into the software development lifecycle. We talked about scan speeds, scan accuracy. That’s another big one. Developers do not want to spend their time wasting reviewing false positives because, then again, they will not trust that security tool. They won’t trust the security team because it was slowing them down, giving them false information and slowing them down from focusing on what really matters. So scan accuracy is another good indicator. Language support, it needs to scan the language of their development choice and if it doesn’t support it, you need to kind of get creative. Whether you use a commercial product and opensource and tandem together because there is no one size fits all security tool on this planet. So if you think there is that salesperson is not truthful. I agree. I agree. I think I think those are some of the major ones, you know, language dependencies and then making sure it covers the any compliance requirements that your organization has. If you have HIPAA or PCI or other other regulations that you need to be cognizant of when you’re scanning, that should be part of your requirements as well. And there’s.. Gina, can you think of any other ones?

00:17:36

Speaker 3: To add to that, we also like to ask like, what are those pie in the sky requirements? Like, you may not get that. It may not exist yet, but like, you know, we might get some unicorn stuff to just see. Like as we’re looking at technologies, maybe it’s something we need to just ask like, Hey, is this on your roadmap? Or We don’t think that this exists yet in their tool, but have you thought about it? So a lot of times we do kind of ask our clients like, is there any complete like wish list items that you would have? And then of course, from my perspective, like when you’re thinking about working with like CFOs or chief financial officers or what could that budgets like, how it’s license, what that kind of looks like. And to Amanda’s point before, how these tools are successful, a lot of times you don’t just deploy it to everybody, you deploy it to a team and maybe what does that POC look like? So we can kind of look at that tool or that product for this team to see how then we can replicate it for success more at scale. So there are some things where, you know, how can it how does it look like? So there’s requirements. It can be over 100 requirements, can be ten requirements, depends on the client. So.

00:18:51

Speaker 1: Oh my gosh, that’s awesome. I quite often get asked about stuff like this. They’re just like, So, you know, we need a DAST. I’m like, cool, what CI/CD pipeline are you using or are you even doing that? Like, you know, are you a 24 hour operation? Because like, if everyone works in North America in the same time zone, it’s like we could just scan things overnight nice and slow and not bother anyone. But if you’re a 24 seven thing, then that means the people that are awake while you’re asleep are pretty ticked at you. Yeah, there’s a lot of stuff there. I want to get to Pierre’s question in the chat, and I want to tell the audience, if you want to ask questions, you can. So how is data treated in evaluating tools so that your app also does not create data privacy issues against the latest regulation? So if you have to follow GDPR, California’s privacy laws, and Canada actually has quite a few privacy laws as well, or one big one basically. But anyway, we also care to either of you want to do that or do you want me to do that one.

00:19:52

Speaker 3: Doesn’t matter.

00:19:53

Speaker 2: Tanya, why don’t you take it? Yeah.

00:19:57

Speaker 1: Okay. So generally, like the main thing with this would be is the product you’re testing a SaaS product software as a service or is it installed on prem? So if you get to just install, like Amanda was saying earlier, if it installs on your actual machine on your laptop and doesn’t phone a friend back at the servers of the vendor, I mean, you’re going to be following GDPR and all the other things because it’s not sending data out. But when you use a SaaS product and Bright is a SaaS product, then you need more information for them. Like are they taking a copy of your source code? We don’t do that. Are like, are they saving your vulnerabilities on their servers or your servers? Do they have access to read those things? And so most companies that make a software as a service type, wait I’m going to correct myself. Most security companies that make a SaaS product, they can tell you that inside and out if you ask them about it, they have lawyers, they have terms of service, they have privacy, etc. But if you’re using a different type of SaaS product, you should definitely read the fine print. I mean, you always should if you’re subject to regulation. But I’ve sometimes I’ve read the fine print because, you know We Hack Purple, The company I founded a few years ago, it it had a whole bunch of SaaS products for all of its various services. And some of them I was like.

00:21:13

Speaker 1: What.

00:21:14

Speaker 1: You’re going to do what with my customer data? And so that can be a big requirement when we’re looking at products have. So I’m not asking either of you to name names, but have have you seen that before where you’re like considering a tool and then you’re you’re looking at the privacy thing. You’re like, no way, man.

00:21:32

Speaker 3: I absolutely all the time. I was talking to a client the other day and they didn’t they didn’t know if even multi factor was a thing that was allowed on the application. And there was just things that I was like, we should look, we should dive deeper into that. But you know, thinking about data, that could be absolutely somewhat hard when you’re doing kind of like a POC. A lot of times we hope organizations have de-identified data or have really thought through their data types when they’re looking at different tool sets so that you can appropriately, let’s say, look at the data and see if it would flag any type of privacy requirements or compliance. So I know that when we’re doing gathering requirements, one of the first things you want to say is, you know, do you have any legal compliance requirements? So just think about all those different privacy things and also contractual. Like a lot of times we don’t think about organizations kind of asking other organizations to have very confined aspects of their data. So thinking about that, you know, you really have to look from a legal and contractual obligations so that when you’re doing a POC that you’re kind of getting it right. So but yeah, I think it is I would say it’s a little bit difficult sometimes because it really kind of depends on the organization and what type of if they have that de-identified or if they’re using production data. Let’s hope not. But you just never know. You just never know.

00:23:12

Speaker 1: I have seen it more often than not.

00:23:14

Speaker 3: I know. Me too. I don’t want to say that, but absolutely. I wish we really do need to take five steps back in a lot of organizations to really kind of bake that out a lot better than we do and evolve it. It needs to be kind of that living, breathing code that it’s really thought about and looked, Are we complying with what we need to even for our de-duplications and that test data? So.

00:23:42

Speaker 1: Agree. We have a follow up question from Sarah. So as you mentioned, there’s no one perfect tool that will serve every single team on the planet because life would be way easier then. But how do we deal with different contexts that could be subject to different regulations and demands? And my first thought is, well, you have to add all the demands together and you got to meet all of them. But is there is there more than that? Like, is there a way to meet demands in different regions for different teams, or how do we handle this?

00:24:15

Speaker 2: Yeah, so this is a great question and I think this is kind of alluding to, like either whether procuring a tool for an organization at scale or rolling out a tool at scale that has different regulations. You definitely want to do this in a phased approach and working with the different sets of regulations that you need to adhere to, to making sure you’re not clouding your configurations with inappropriate controls that you didn’t mean to implement in the first place. So taking it as a phased approach and really testing out to see whether or not you hit all of the compliance requirements that you need to in order to be considered in regulation with the standards you’re trying to follow and then also trying to, making sure that your internal processes are aligned to how you want to set it up in your security tools. Right? So if your internal processes aren’t keeping things separated or segregated, then you may want to look to add more internal security controls that will help you segregate that data. And then that way you don’t need to really worry about segregating that data when it’s entered into your security platform because you’ll have everything separated. You could put attribute or role based access controls in place to making sure that only authorized users see what they need to see. You can set up notifications so that only you know the right people need to know at the right time that something’s happened and put other proactive security controls in place to meet the regulations that you’re trying to adhere to.

00:25:47

Speaker 3: Yeah, And something that Amanda and team kind of do is is also looking at different teams like so for example, there might be different types of code or with different languages and really kind of thinking about they may have all different types of applications that they’re working on. Right. An organization may not just have one app, they may have five, they may have 25, they may have 100. Right? So kind of looking at different teams and seeing if requirements are different. So maybe an application or maybe a company is doing some type of fitness application where there may be HIPAA data or something like that or a financial app, right. Could be the same company, but doing different things. You know, Amanda and team are really going to look to see how those different things can also feed into the tool and and how to appropriately work it so it can be replicated at scale.

00:26:43

Speaker 3: So I just wanted to mention that.

00:26:47

Speaker 1: No, it’s really good. I remember so my mom used to work at the Canadian Revenue Agency, and I used to work there too. And so it’s like the IRS, but for Canada and I would read, so, same when I worked at a bunch of companies like Microsoft, etc. They would really, really, really focus with employee training. You do not look at customer data. You do not look up your neighbor. You do not like you like just taught us like a lot about respecting the people’s privacy, who we serve. And so almost every year CRA will walk a few employees out that are fired because they looked up their ex wife, they looked up their neighbor or their whatever, and like, we’re doing inappropriate stuff. And I know that it sounds really, or I don’t know how you feel about this, but I feel like really strongly about respecting your customers and like doing what you promised. And so I’m like, Good on you. Good on you, to train them, reemphasize it all the time, do all the things. And then if someone still does a completely like, blatantly malicious thing, like, yeah, you’re out of here, buddy. Not that I would celebrate people getting fired, but it’s like I’m celebrating like an organization, they don’t just send an email saying, we respect your privacy after they’ve breached your data accidentally or spilled your data, but like, they actually mean it with their actions every day. And I

00:28:08

Speaker 1: Feel like.

00:28:09

Speaker 3: I actually have such a good thing for everybody in the audience and and everything. I think that this is so important. Like it drives me nuts when I go to a website and a company’s like, you know, puts their customers or security or privacy first. And then I go into that company and they’re like, We only have a 1% budget for security, right? Like we,when companies are holding to their mission and holding accountability, like you said, and abiding by their policies. Right. I think that’s really important. So I a lot of times will go back to their mission statement, you know, and be like, you know, really excited to to talk to you guys looked at your website and, man, you are building the most secure applications for your clients. And man, I’m really happy that you take security very seriously. And they’re like, We don’t have a budget. You know, it’s it gives you pause, right? It gives you pause. So just kind of just a light bulb trying to take that. Sorry about that.

00:29:10

Speaker 1: No, no. Like, it really matters. So, for instance, like bright Security, like, I was like, can I share our secure system development lifecycle because there’s like nine security steps and then, like, it’s really cool, like, am I allowed? So they they’re saying that I’m allowed to share it. So I’m going to write a blog post soon. But I’m like, I feel like it’s really important to demonstrate that we follow the advice that we give every single day. Like, like we’re telling you, because that’s what we do and because it works. And so, yeah, I really I like seeing it when companies.

00:29:43

Speaker 1: Just.

00:29:44

Speaker 1: Microsoft called it eating your own dog food. But I, I prefer drinking your own champagne. Thank you very much.

00:29:50

Speaker 2: Drinking your own champagne sounds a lot nicer and I can definitely get behind that. So we’ll do like hashtag drink from your own champagne because it’s true. It’s true. And that’s part of the other secret to scaling out the tool, Right? You really need to understand how the tool works, how it’s going to be set up and how it’s going to impact the end users who ultimately have to use the tools.

00:30:18

Speaker 1: In the chat we have from Sarah drinking your own Beaujolais. I’m there for it. I’m there for it. We have another awesome question from Christopher. I wanted to… I know, when you’re the host, you get to ask your questions first. So we met before the webinar and that’s why we’re all talking so comfortably. So if you’re watching, you’re like, did they just meet? No, I’ve been hassling them for months. So we talked about creating a roadmap for a company. So Trace3 comes in and they’re, you know, our security is here. We really need it to be here. You know, we’re just getting into DevOps. We’re just you know what I mean? Like, what is the first couple steps that or even just the very first step that you might take to try to help them create a roadmap for their security program?

00:31:07

Speaker 2: Yeah. So there’s there’s a three phased approach that we we kind of think about here you have your crawl, your walk, your run. If you’re you’re super optimal, you’re like sprinting. But but we’re really working with people who are who need help with crawling to build the foundations, figuring out where they’re at today so that we can help them figure out where they want to go tomorrow. And that’s that’s sort of where we get to the the walk and run. That’s tomorrow. But today we’re understanding what what’s happening. What do you have in place today? What’s working, what’s not working, and then collecting that user feedback. Because again, if you treat Devsecops almost like it’s a product in your organization, right, you want your developers to be happy. And I say this all the time. A happy developer is a happy security team because then then they’re doing the right things, right. We put security controls in place to to put safeguards on our company crown jewels. But then there’s been some sort of like disconnect or miscommunication on on the expectations and how you actually get that done. So when Trace3 comes in, we kind of figure out what the security team is trying to do, what the development teams are trying to do. And if organizations have a DevOps team, we bring them into because they’re going to help accelerate the program with using Agile and DevOps methodologies to help speed things up. So we kind of help figure out what everyone is trying to do and create that cohesive plan that everyone can agree on, because that’s been the biggest challenge is how do we get everyone on the same page from a, you know, people on the front lines to leadership levels and getting them on, on, on, on a plan that they can agree on and work towards and iteratively build out that plan. So phase one in the in the crawl stage is getting those requirements, figuring out where everyone’s at. The walk phase is where building out a pilot program. We’re going to set up the tools, we’re going to create processes and let it run. But we’re not going to say the whole organization needs to follow it. We’re just kind of seeing what works, testing the waters and if we’re, you know, testing a new tool or we’re or if we’re evaluating new tools or implementing new tools, we want to do a pilot program. Right? And you can do that with the assistance of like Trace3 and Bright being partnered together to kind of help educate people on what they need to do with any solutions. Then also setting up a security champion program that’s really helpful to to scale out your security initiatives, because as everyone knows, it’s no secret that there’s like a shortage of security resources on the planet. But to scale and to really be successful, security is everyone’s responsibility, right? Protecting our data, protecting our privacy should be everyone’s utmost concerns, in my opinion. And so when you get to the walk phase, you’re setting up your tools, you’re setting your processes, you’re testing things out, you’re collecting feedback, and then in your run phase, you’re iterating you’re really advancing your security policies, your controls and your risk posture because you’ve you’ve built the trust with the foundation you’ve created with your developers and really driving your needle to maturing your security organization. So that’s sort of what goes on the roadmap at a super, super high level. But again, no one size fits all. Where everyone is today is going to be different for every single organization. And so the maturity is always going to be different. The roadmap is always going to look different. However, the framework is going to remain the same because that’s really what you need to do to get started. You need to think about your people, your processes, and then your technologies. And specifically in that order, right? You have the best tool on the planet. But if you have bad processes written by people who don’t understand what the pain points are, you’re not going to have a good tool or an effective process for the people who need to follow it. So to tie in all of those three things together, you really need to understand what are you people need, what are your processes need to be built and what tools can you bring in to support those processes and to really enable and empower your people to do what they need to do.

00:35:06

Speaker 3: I really want to quote like have quotes now that says, like “Amanda says” right at the end. So many good things.

00:35:12

Speaker 2: Good thing this will be recorded. 

00:35:16

Speaker 3: Right, I can transcribe it. One of the amazing things that I think that I don’t want to kind of slide over is that continuous feedback loop that Amanda and team are getting. Like they really want to make it successful. We really don’t want to, we want, I mean, developers first, but it’s also just people first. Getting that continuous feedback and improving their processes are vital to buy in. And then once you have that buy in, that really helps you kind of be able to do better things down the line, include better processes and or get additional tools for the product or for your application. So it’s really important. I just wanted to make sure that we it’s like developer first people first type of thing that we really are subscribing to here. And so…

00:36:08

Speaker 1: No, I love it. And Amanda, I was on a panel a few months ago with this amazing woman named Nicole Becker, and they were asking us like, how do you start your very first conversation when you go? And she says, Oh, I show up to the meeting. I’m like, Hi, I’m from security. I come in peace.

00:36:29

Speaker 1: And just..

00:36:30

Speaker 1: And then everyone laughs. She’s like, There are so many developers that have been mistreated so many times. And so, Amanda when you were talking I’m like, oh my gosh, those two need to meet.

00:36:39

Speaker 1: Like.

00:36:40

Speaker 1: I feel like you have this this way about you that like you’re it feels like you definitely understand their job and their concerns and what they need and actually care about it and like, adjust the things you do to make sure it works better for them. And like both of you, what you’re saying, for anyone that’s like listening and not watching, I was like nodding my head vigorously for like two straight minutes.

00:37:04

Speaker 2: Thank you, Tanya. To kind of like add more to that. As we mentioned, everything that we we bring as trace3 to an organization, it is going to be dependent on the organization. And while we do recommend, hey, from Trace3’s perspective, this is what we think could work for you. But at the end of the day, there really isn’t no right or wrong way, but just a better way, right? Because obviously something wasn’t working before. And that’s why we’re having these conversations, because there are pain points and we need to iterate, use feedback and do better. Right? And to Gina’s point, when we continuously engage our clients, we’re always asking what’s worked well, what hasn’t worked well? Because we’re really kind of taking DevOps and Agile methodologies, right? As a developer, I’ve learned that, you know, at the end of a sprint cycle and a sprint is just a duration of days that a development team may build some code for those who are not engineers on the call. But at the end of a sprint they’ll do what’s called a retrospective session and they ask like, Hey team, what went well and what didn’t go well and what can we do better next time? And when you bring that mindset to the conversation, it really makes it easier because you’re you’re building that trust. You’re listening to their pain points and you’re trying to do something about it. And that’s where I think Trace3 really shines, because we really we want to take the time to understand what’s wrong and how do we get to the root cause and what can we do to help make things better. 

00:38:26

Speaker 1: Yes. So there’s a question in the chat that’s like kind of a question from quite a few minutes ago from Christopher. Any experience with automated evidence collection platforms? And I actually do have some experience with this, but not since 2007 and 2008. So I use things like Ringtail to gather just tons of evidence and change it and organize it and stuff. But like, that’s a zillion years out of date. I’m wondering if either of you happen to have like I don’t have any recent experience with evidence collection, but I thought I’d throw it out there just in case.

00:38:59

Speaker 2: No, I don’t have any relevant experience myself. But it is an area that I think needs more attention to as organizations are realizing, Oh, I need a better way to collect evidence, I need a better way to not only self audit but externally audit myself and be prepared for these types of things. So, no, not yet, but I hope to get more in the future. Gina, do you have any?

00:39:23

Speaker 3: I do not, but I’m thinking I’m going to take that down and send it to our innovation department and of course, our application security lead, Jimmy, to like to to maybe investigate further, to get some brilliant minds on that. And, Amanda, do you want to think about those security requirements so that we can score it in vet them and bring it back to Christopher?

00:39:45

Speaker 2: Yes. Sounds like a plan. Perfect. That’s our action items for next, for next steps. 

00:39:52

Speaker 1: Okay. So there’s one more topic I was hoping we could talk about before we theoretically run out of time. And it’s security champions. So when we planned this call, we’re talking a lot about how we have a lot of trouble scaling. And in January of this year, GitHub released this article saying there’s now 500 software developers for every one security professional. Yeah. And, you know, like, that number sounds outrageous, but I trust GitHub. Like, if anyone knows, they do.

00:40:19

Speaker 1: Right?

00:40:20

Speaker 2: And so so we talked about like just all the different ways that you could scale, like your program, your people, your tools, like anything you can do. And we kept coming back to security champions. And I was wondering if maybe one of you could tell everyone what security champions are and then maybe we could talk about that a little bit.

00:40:39

Speaker 2: Do you mind if I take this Gina? Okay. Great. Because I think security champions is the smartest thing any organization can do, regardless of where they are at in their DevSecOps or application or cloud security journey. The reason I say this is because security champions will help the security team scale out their security initiatives through champions who are typically developers on engineering teams in your organization. So they’re kind of like your your liaisons or your your advocates to spread your security awareness and initiatives on your behalf without you necessarily needing to be there. And remember, I said earlier, communication between security and developers is really important. Well, isn’t it super easy to have your like, your, your… how did I describe this before? You have a way in into your engineering teams through through the lens of your security champion. And your champion can be either the team lead or someone who’s really passionate about security and help drive security awareness and training and help influence these behaviors that you want developers to pick up. For example, your champion can help educate them on how to find and fix vulnerabilities much earlier in the development lifecycle so that they don’t have to react to an issue that was detected later and is more painful and costly to fix at that point in time. So there’s a lot of value in having a security champion, whether it’s training, showing them how to use new tools, educating them on difficult security concepts like authorization and access controls and really helping your they’re like an extension of your security team on your development teams without needing to spread your security resources so thinly. So I think that was it in a nutshell. But there’s more that we could talk about for champions.

00:42:35

Speaker 1: I have a question for Gina. Definitely. So Gina, you’re sort of at the top of the food chain, if you think about it, for security, like being a CISO, that’s the top. How do you get buy in from the business to do a security Champions program?

00:42:49

Speaker 3: Yeah. So when I get very smart people on the line with me, you know, surround myself with smarter people like Amanda, I think a lot of organizations, one see our passion and really start understanding. It’s kind of how I think about like cybersecurity awareness training, right? When you do a cybersecurity awareness training for an organization, you really have to make that cybersecurity awareness training about the user and then hopefully you have that trickling effect. Well, it’s kind of like the why, right? Why the user, why the organization, why now? And I think if you kind of think like everybody, everybody’s like a sixth grader, right? Or a third grader, why, why, why you have to keep on reinforcing that why message and so trying to get buy in and saying, you know, hey, listen, these are the reasons why maybe it’s regulatory, Maybe either stuff on the news, maybe there was a current breach, whatever that is, you know, whatever that why now is. And then and like why your organization? Well, you know, your application is your profit generating source that has to be protected. Right. And if a security breach was going to take place, you know how much and you try to figure out how much it would cost them if a security breach would occur, how would it cost their reputation, that application? Maybe they would never be able to use that application again. And then from there, it’s kind of trying to have them understand that buy in and making your, making sure that you’re showing the metrics along the way. You have to show success. And I think that that’s really important when you’re thinking about putting any type of process or tool in an organization, you have to understand what success looks like, be able to measure it, and then show the value to all levels from practitioner to leadership on why it worked or why it didn’t and why you should pivot. I also think it’s really important to not like scorch the earth with processes and tools to really especially in in when we’re thinking about development, it’s really thinking about maybe certain teams that you can work with to really work out the the pain points and potential objections that may come up. Because then if you work with them, one, they can become your security champions and and help with the process in other areas and or just be your advocates, but also what kind of the trenches that they were in. We can make sure that other teams don’t have that. So that allows for more of a smoother transition. And you can gather your metrics and measures on that one team to then define success for what other teams may look like. So there’s a lot of things that you can do. I think cybersecurity is just like relationships and you have to have communication. Communication is key. Everybody needs to overcommunicate and you need to explain what worked and what didn’t work. That’s really, really important. We’re all humans. We all have faults. There are things that maybe we thought would it would work out. But then once we got inside and the architecture didn’t work out right, and there are some things that we have to kind of work through together as a team, right? You know, we’re not in silos. You know, I need the help of people like Amanda and team, and I need great vendors like you to really kind of see how everything works together. The puzzle pieces and for me over communicating is key, So.

00:46:30

Speaker 3: For buy in.

00:46:31

Speaker 1: I agree completely with both of the things that you said. One thing that I’ve always done with security champions is teach them the tools that I’m asking them to use. Like if if they’re going to be doing like dynamic, static software composition analysis, it doesn’t matter. But if I’m going to make them the person that’s responsible, I want to train and train and train them so that they know how to use the tool very well. So they always look smart in front of their peers. But there’s a lot more that we want to train them about and do with them. And I’m mindful that we only have 8 minutes left.

00:47:03

Speaker 1: So would both of you…

00:47:06

Speaker 3: Huge point right there. I also think by having training, it helps them with their resume to it’s about them, right? Why them? What are they doing. So I think it’s not like, well, the organizations want us to create a great application. Right. Yes. But this also helps you in these avenues. It helps you with better process flow. It helps us have a secure product. This will help you with your resume, Right? You, you shift your whys a little bit. And I think that’s really important for us to also consider.

00:47:37

Speaker 3: So.

00:47:39

Speaker 1: Yeah, I totally agree. I was wondering if each of you could tell me just like one benefit or thing that you would want to do with a security champion. So maybe Amanda, like one thing that you might want from them, or that could be good because you have security champions.

00:47:57

Speaker 2: Yes. So I was so excited to be asked this question. Having a voice at the table as a developer I think carries a tremendous amount of weights. So when you say, Hey, I’m a security champion and I helped design my secure development policies that my organization needs to adhere to, that kind of feels like a really cool thing to brag about, to be honest. So for those engineers on the call, definitely hype up champions at your organization. And Trace3 can help. But having having that voice at the table is really, really valuable. And because it goes both ways, right? Security teams are asking developers like, Hey, can you learn about this tool? But then developers or the champions can say, Hey, security team, I think this tool could work, or I think this process could work. And you get that bidirectional feedback loop, which is such a healthy place to be for our security and engineering team to collaborate because not all security practitioners have an engineering mindset and not all engineers have a security mindset. So there’s a lot of learning that we could both benefit from if we kind of break down those barriers and give them a chance to voice their opinions.

00:49:08

Speaker 1: So that’s such a good answer. Gina, do you want add.

00:49:12

Speaker 3: Oh, I have to follow up on that, huh? Yeah. No, I definitely think the bragging is is absolutely great from both sides. Right. Leadership can brag about their team. So I think security champions, though, redefines cybersecurity culture at an organization because it isn’t. Yes, I do think that security and policy should be from like kind of the top down and op down. Like there’s so many things you can think about that. But having champions and having continuous feedback loops and celebrating successes and doing all that really changes that cybersecurity culture at an organization, that engineering versus security, those silos or IT, those silos that take place. And there’s just so many good things that come out of it. Is it easy? No, it’s not right, but it is so worthwhile to just like your relationships. So I think it’s, it’s really critical to have successful programs like this because I think it is just revolution, revolutionizing the way that organizations think about security and think of it differently. So.

00:50:24

Speaker 1: I like that. So I’m going to tell everyone a little secret about Security Champions programs. And so if you are a developer and you become a security champion and you’re very, very interested when the security team needs to hire someone, we are going to try really hard to convince you to come on to our team and like it is one of the best possible ways to recruit a junior AppSec person. It’s like they already have tons of corporate memory, so they know all of the apps. Everyone knows this person and likes them. And this is how I got into the security team. I had led one of the dev teams and I had completed like a super huge project and one of the like the head of security basically came over and he’s like, Yeah, So we’re like going to hire, you know, a junior security person. And I was like.

00:51:11

Speaker 1: Me, me, me

00:51:13

Speaker 1: Me, pick me. And he’s like, We’re wondering if maybe you don’t know. I’m like, me!

00:51:16

Speaker 2: Hey, welcome to the dark side.

00:51:20

Speaker 1: I know. I was so excited. I was joking with them because two out of the three people on the team were named Eric. I was like, You can call me Erika. And I was like, So, like, to say I was thrilled would be a huge understatement. And so this is like, like security teams, if you’re like, thinking about this, like, this is a way where you could recruit the absolute most ideal junior person because they know all the things you want. They know all your policies, they know all your apps, they know all the people. They are a peer of the software developers where you work. Like when this person comes to talk to them. It’s not like mystery person from the security team. It’s their friend that they’ve had coffee with 12 times. Right? And it’s just such a completely different conversation. And so don’t tell anyone, but that’s a secret.

00:52:10

Speaker 3: So that’s a great secret.

00:52:13

Speaker 1: So we have we have just 3 minutes left and I’m supposed to, like, wrap us up and I’m really bad at ending things. So I was wondering if each of you wanted to just say one last thing and it could be about security champions. It could be about scaling your program like anything you want, just like to kind of end off as a thought for people to think on.

00:52:31

Speaker 2: I’ll start and then I’ll have Amanda finish. But I think it’s it starts small. I think it’s don’t, don’t like I said, don’t scorch the earth. You know, Rome wasn’t built in a day type of thing, but really thinking about, you know, starting small, what your use cases is, what does success look like and work on that, do it well, and then you are able to replicate. So I think that that’s going to be my message.

00:52:56

Speaker 2: That’s perfect. Can I like plus one that because my my like like DevOps hat of this or devsecops is fail fast, learn fast and like keep keep striving to do better when you start small and if you have three decisions to make, just test them all out really quickly. What’s the harm in figuring it out right? Take the time upfront to to experiment, hypothesize and take that feedback and that learning, right? I like to think of not failures. Failures aren’t really failures. They’re learning opportunities, right? We all have to fail sometimes to learn to grow. And so take what you know now and do something about it, right. Don’t hold your cards close to you and think that like only you need to know all the answers, right? Everyone is better together. So take what you know, share it with everyone else, and then they’ll share it with more people that they know and it kind of organically grows. As Gina mentioned earlier the use of a security champion program and scaling it a security tool. When you start small, you can make it measurable, you can figure out what works and keep iterating and fine tuning. Make a couple of changes every time. Don’t change, Don’t overhaul everything, but keep it small, keep it simple and have fun. You got to have fun while you’re doing it. 

00:54:11

Speaker 3: So Important Amanda, Have fun. Yes.

00:54:13

Speaker 1: Yes.

00:54:14

Speaker 1: So there was one question. So security champions do not need to know. All of the tools of the security team needs to know. They just do the security activities in the SDLC You are right, Sarah, who asked that question. And so I want to basically from that question, say my last point is, so if you’re watching this and you’re not on the security team, but you are very curious about security, I would like to encourage you to reach out to your security team and say, hey, I’d like to learn more. Is there an opportunity like, are you planning a Security Champions program or could you maybe let me job shadow you some day? Because they’re, first of all, a zillion jobs. But second of all, we really need your help. And I’m sure basically any security team ever, it would be music to our ears. Amanda and Gina, you two are amazing. I’m definitely going to be trying to convince you to do more stuff with us.

00:55:08

Speaker 2: Sign me up. Well, this was awesome, Tanya. Thank you for having us today.

00:55:14

Speaker 1: Thank you so much for coming. And thank you to everyone who’s here. Thank you to all the awesome people who ask questions in the chat. Thank you for everyone that’s listening. Thank you to all the people who are behind me from Bright, who actually organized this, promoted this, and like did all the actual work. Us three ladies look awesome because of all of you. And with that, thank you both so much. And I’m going to say bye to everyone.

00:55:38

Speaker 1: Bye!

00:55:39

Speaker 3: Thanks so much. Appreciate your time.