Building Cybersecurity Teams with Matthew Marji

TLDR;

• Communication, both written and oral, are key skills for security engineers and organizations should evaluate for this during the hiring process.
• For startups while hiring, assessing the business risk has a huge impact because it helps you decide whether to hire a contractor or a pen tester or a CISO and also whether you should hire someone internally or work with an external agency.
• Alignment is key for business success. So similarly, Security alignment is key for success of security programs.

Transcript

Host: Hi everyone, this is Purushottam, and thanks for tuning into ScaletoZero podcast.

Today's episode is with Matthew Marji. Matthew has a decade of experience in security engineering, starting as a developer, a security IC, and for the last couple of years, he has been established himself as a leader. He's currently leading security at Narvar, the leader in post -purchase experiences. Prior to that, he has worked at the likes of Symantec, Auth0, and Okta.

Matt is not just passionate about security, but he also enjoys taking on home DIY projects. And a fun fact about him is he's from Toronto, Canada, but despite what you may think, he doesn't drink maple syrup for breakfast. So that's a good fun fact to have.

So, Matt, welcome to the show. For our audience, do you want to briefly share about your journey?

Matthew: Yeah, I'd love to. My journey started as I studied in university computer programming. Before that, I had a wonderful high school teacher who's now passed away, but she was extremely passionate about coding. And it was the first time that I got a feel for it and just realized like, wow, there is so much that you can do by writing code.

So yeah, so that drove my interest to study computer engineering at the University of Toronto. So I started as a developer. And one way or another, I wasn't the greatest developer. It actually turned out that a vulnerability in some of the code that I wrote was my introduction into moving over to the security side of things and looking to work closer with engineers on securing their code and building kind of secure by design products.

So started in software, realized that it might not be the best thing, but I definitely knew what to look for in terms of ways that things can go wrong. So that part of my mind is what I like to stretch a lot.

Host: So that's a very unique sort of transition, right? That you are a programmer and you transition to security so that you can prevent things for maybe one of the things that happened by you, right? So you were just trying to make sure that. That doesn't happen to others. Okay. Makes a lot of sense. So we ask this question to all of our guests and we get unique answers. So I'm curious, like,

What does a day in your life look like?

Matthew: Really good question. Not to be corny, but I do start my day in and around 5 The first thing I do is I go to the gym most of the days during the week. That's a great way for me to, I think one, if anything, get out of the house as an opportunity as I work from home and I'm sitting the majority of the day. So it kind of gets me going. I start to kind of process and think about how the day's looking. I will typically have breakfast with my wife, take our dog for a walk. That's his bed behind me. He typically joins meetings when he feels like it's appropriate. And then, yeah, so then I spend the day at work.

It's interesting that the role that I'm currently in, I could spend the entire day in meetings with customers, reviewing security questions that they have. I could spend all day with our engineering teams, empowering them, doing code reviews, etc. Or, you know, it could be strategic, we could be doing planning and kind of forward looking tasks across the business.

So every day is a little bit different at work, which is the exciting part about it. But yeah, then typically at night I do my best to kind of keep it low-key. I will again, we'll walk the dog, we'll have dinner. And I am a fan for good or for bad of the Toronto Maple Leafs, our NHL hockey team. So if their game is on, then you'll definitely find us watching it.

Host: Lovely. And I see that you have a quite a mix of things, right? Like your workday and your personality as well. So yeah. Lovely to hear that.

So yeah, thank you for coming to today's podcast. And today we are going to talk about building cybersecurity teams and the importance of continuous learning as a security leader. So let's dive in.

So hiring is a big challenge, right? In general and in cybersecurity, it's even more of a challenge. So hiring cybersecurity professionals with the right blend of qualities and skills is crucial. Especially nowadays we see cyber threat landscape is evolving rapidly. So,

What are some key qualities and skills organizations should look for when they are recruiting for cybersecurity professionals?

And if you can separate both technical and non -technical qualities that will help.

Matthew: Yeah, I would love to. It's a really good question. I'm going to do my best because there are so many areas to focus in on. I think from a… Maybe non -technical, I'll start with first.

I think from a non -technical point of view, considering not just only the threat landscape, but also to kind of like the work landscape. We have distributed organizations where we're not all meeting in person anymore. Those days are pretty gone for a lot of companies. And so I'd say first and foremost, both oral and written communication is really important.

Can I convert my understanding of a technical vulnerability that's been found that has to do with a particular injection that causes some data exfiltration. How do I synthesize that really well? How do I reproduce it in a fashion that makes it easy to consume? Those are the types of things that I think about and I attempt to put together technical challenges, et cetera, that test those abilities. So really looking for strong oral and written communication. Are we able to take technical concepts and break them down easily for others to consume.

And then on the technical side, I think first and foremost, what's really important to me at least is, and especially thinking about startups and the first few hires is someone who is hands -on. And by hands -on, I typically mean has the ability to be the side-by-side with a developer and be able to take a look at code and have a back-and-forth conversation and and discuss ways that this might be able to go wrong.

So almost like a mini threat model, but like essentially doing some level, if you're able to do a level of peer programming where you're able to sit and understand and ask really good questions about how we're doing things and why, that's really important to me.

So yeah, the ability to kind of read and write code, I'd say is probably first and foremost on my mind from a technical point of view.

We might probably get into it further, but in terms of current technical skill, security is continuing to evolve. So if you take a look at OWASP top 10 from 2017 to the latest 2021, you'll see a shift in what the threats are in priority. So those things will continue to change. So I'm not necessarily looking for someone who is technical and specific areas as I know that generally speaking, the threat landscape will continue to evolve and we're going to have to continue to learn.

Host: Yeah. And one of the things that you highlighted I feel is very similar in engineering also is the communication. Like understanding the, let's say, technical requirements and then sort of communicating that with, let's say, your team. so that the way they can understand and they can work on it. So that's a very important skill. And I see that you are also saying that it applies to security as well. Understanding it, working with the engineering team, or working with leadership, communicating in the right language has a huge impact.

Matthew: Yeah, and you brought up a really good point there, which is the communication and maybe the level of technicality that you'll use with an engineering team is going to be different than with leadership. So a part of the skill there is tailoring, you know, our language to, you know, exactly to different groups.

Host: Yeah. Yeah. Yeah. So a follow up question to that is, let's say you, you're trying to hire or you have hired, what, what strategies would you recommend so that you can attract the right talent? Or let's say you have hired now, how do you retain the cybersecurity talent.

Matthew: Okay, so really great. I'll speak first on hiring and then transition into members on the team.. So in terms of hiring, I kind of think back to what I liked and what I didn't like of the days of kind of software interviews, software development interviews. What I really liked is exploring what you'll do in the role, some examples or current areas that the team is looking to improve or work on.

So I like to share those things to really give the candidate a great idea of what they will be working on from the beginning. In terms of assessing kind of skill set, I really like to do a collaborative type of challenge where we will both jump into something together that is actually a spin-off of a real-life challenge that the organization has had.

So, you know, we, one example that I like to use is there is a particular refactoring of code that we're doing. And it's, it involves us reviewing how we are manipulating JWTs. And so we go over the code together. We look for, we look for vulnerabilities and generated, and we generate one or more vulnerability tickets that we would technically pass on to an engineering team to review and mitigate or remediate rather.

So what I like to do there is it assesses both kind of technical as well as communication, both in real-time communication and the written piece as well. So yeah, I love the collaboration piece of it. I love that we can be a little bit technical and that I aim for it to be collaborative such that it doesn't feel like I'm quietly just sitting there assessing what you're doing right and what you're doing wrong.

Host: A few things that I liked about the way you sort of the way you are recommending the evaluation process.

One is the transparency. Like you're sharing what exactly it looks like on a day to day basis maybe. What would they work on? And what type of real challenges they might face rather than giving like in case of engineering interviews, sometimes we give hypothetical challenges, right?

But I like your recommendation where you are saying what to work with them on a real challenge so that they also get a feel like candidate also gets a feel what type of challenges I might get when I join and you are also able to evaluate given a particular challenge, how is the candidate approaching it? So that helps you with that.

Matthew: Yeah, that's so true. And I kind of equate transparency to trust. And so my attempt is to build that trust early and that, you know, to the second part of your question, it transitions in and starts to build trust early so that once we actually, you know, begin working in the security org together, you know, some of that has already been established, those clear lines of communication, the openness of what we're working on.

Host: Yeah, I like that. So now if we take the same setup to a startup, let's say a startup trying to hire there, they're starting their cybersecurity program or journey, and are ready to hire their first security, like first security hire, they're ready to hire them.

Now, in general, startups have several constraints, right? Like budget, employee expectations, and employer expectations, there are so many things. Considering these constraints,

What security programs should organizations prioritize when they are hiring?

Should they even look at by security programs?

How would you approach it?

Matthew: That's a really good question. I think every organization is different and I've seen a number of different approaches. From my experience thus far, the best way to identify the next step is to typically spend time registering your business security risks.

So taking the time to assess risks across your business will allow you to establish, hey, is the next step maybe something that's very simple and contractual, like maybe a third-party security team. Is it a technical hire? Is it maybe like a CISO or an InfoSec hire? Because a lot of these concerns are related to compliance and privacy and frameworks.

So it's all really going to depend, I'd say, on what the business risk is in them. I say that not necessarily as a cop-out, but then again, because I haven't seen a one-size-fits-all all approach to how to do this for Narvar in particular, the organization started with compliance and privacy first and then moved on to building out security engineering second and that aligned with the needs of the business.

Host: I was hoping there will be like one answer, but I totally get it. No, I totally understand as you highlighted Narvar's case that your first focus was to have compliance. So you focus on that when you are hiring, then privacy, then other areas as well. Makes a lot of sense.

And when you are hiring, are you looking at a specific set of skills and experience based on different stages of your company or different priorities, or the skills and experience is very similar?

Matthew: Really great question. I think this skills evolve. So again, kind of, I'm going to dive into the realm of, you know, my awareness at Narvar.

What's been beautiful to see is as technology continues to evolve, so are the kind of needs for where we need to cover security. One example is three to five years ago, not as many people were doing infrastructure as code. So Helm charts and Terraform and these things were still kind of new. Like if you were If you were on the bleeding edge, you were doing it, but otherwise you were in the UI, you were deploying things to VMs, you were doing some Docker containers, like nothing too crazy. But now it's really exploded. And so that's an entire new world.

So looking for security engineers that have started to dive into those spaces or, you know, have the experience in Kubernetes is a huge asset because as the business takes that technical turn and decides to kind of, you know, spend time, doing those things, we want security to also be aligned with that, right?

You know, similar to going back to what I said, I do want a security engineer to be able to sit with a developer and review the infrastructure code, right? To go over what we're building and how it looks in the cloud. So yes, I would say definitely in terms of the technical skills and typically what I'm looking for, it's always going to be, you know, there's a role in in what we are currently working on, the technologies that we're using, the cloud environments that we're in, those will play a part in what we look for in candidates.

Host: Yeah, I like how you framed it, right? Like depending on, and with examples again, right? Depending on how the technology trend is moving, you should also think about hiring for some of those skill sets. So yeah, spot on on that.

So one of the things that I want to understand from you is, let's say you hire security engineers. One of the challenges that they face is incorporating the security practices into the mindset of other teams, right? Like engineering teams. Because they have to work with engineering teams more often than not. So it comes down to the culture of the company, right? So,

How can organizations ensure that security is baked into their teams from the beginning rather than being an afterthought?

Matthew: I feel like I'm going to disappoint a second time in saying that. As much as I wish that organizations put security at the front, we have to be realistic, I think. Organizations, especially startups, depending on your business and what you do might not be the first thought, right? You want to be cashflow positive, you want to bring on customers, you want to ensure that you're building products, right? So you have to, it's just a reality, right? Like as a business, you have to think about priorities.

And so whether security is first and foremost, or whether security is, you know, a little bit further down the list, I think what's important when establishing a security, you know, department or group in the organization is essentially discussing the relevance of security as it pertains to that group. So almost like providing evidence of how important security is for a particular product or for that particular leader.

So one example that I really love to give is in being technical and hands-on, what I have done in the past is I have spent the time to review a particular product and I'll find the vulnerability and an exploit for it and kind of share hands -on the importance of trying to be ahead of these things and integrating that early on, right, in the development of our products and, you know, working to be secure by design.

So I like to do almost like a show and tell or, you know, lead by example. And I think typically what that does is it, you know when we're showing something and it kind of gives us some shock value, we remember it. Right. And we tend to value those things more.

And so I have typically found that as long as, you know, from a security point of view, you have the patience and realize that this isn't the culture may not be something that is, you know, built overnight. You, you, you take the steps to lead by example. And I think that that's the best way to start to integrate it into the culture is you lead by example, you get more people interested, you kind of bring them into that world. You hopefully empower them begin to give them the tools and the resources that they need to do the same things.

And you find that it kind of continues to spread from there.

Host: So yeah, like the message that I'm getting from this is awareness, like make sure that the other teams are aware of what's going on, enable them so that how they can let's say, maybe learn more about the vulnerability or show them what the vulnerability is, what the impact is, and how can that be remedied as well. So instead of just creating a ticket and saying, hey, go fix it, work with them, collaborate with them so that they see the value of, not just the particular task or a vulnerability, but the overall process, which helps you in the longer run.

Matthew: Yeah, I think, I think that that's exactly it. Like every, in my opinion, the majority of vulnerabilities should be seen as an opportunity not to point out a mistake, but a learning opportunity to improve for the future. And so, That is the time where as a security professional, you can spend time enlightening, you know, a developer or a group or a team as to what went wrong here, because we're not thinking about the happy case. We're thinking about, you know, where this can go wrong.

And that's exactly, I'm kind of pointing back to, to my introduction into security. That was, you know, I'm essentially just kind of copying over what I learned from someone at a past organization was they took the time out to explain to me what went wrong and why.

Host: Exactly. So this sort of answers how it's a security team should interact with engineering teams. Now there is another stakeholder, right? When it comes to security, let's say leadership, and often leaders leadership make decisions around what's the strategy of the organization and stuff like that. So in the broader decision making process, cybersecurity should also have a seat at the table, right?

So what have you seen if that doesn't happen?

Matthew: Really good question. Again, I think I have seen that if security is considered a separate function that essentially acts as just a team that exists to provide tooling and a second pair of eyes and isn't tied in with the business, it becomes kind of second tier. Security isn't integrated in with the roadmap of the company.

And so security may not be flagged when we are working through iterations of a new product or a feature or the design phases for these things. So I think what's really important and what I'm really grateful for at Narvar is not only does security have their own roadmap for what we're working on and what we want to accomplish, but we are tied in to all of the elements of what we're delivering to customers year over year so that you know, from an early stage, security has a say on how we're going to, you know, how we think about, you know, managing data, how we think about the management of these new secrets or, you know, this new infrastructure that we have to put in place, you know, to support the product. So making sure that security has a seat at the table as it pertains to the product roadmap, I'd say is extremely critical.

And then, you know, Secondarily, ensuring that security still has their own roadmap for the year that aligns with the business and has OKRs is also very important to continue to see growth in the security org.

Host: So the key word that I heard from you is the alignment, right? The way you have your business capabilities alignment. Similarly, security alignment has to be there from the top down so that your teams have clarity that, hey, security is equally important as are let's say capabilities as well. Of course, earlier you said that depending on the stage of the company, sometimes they have different priorities, but more often than not, they should have equally important, equal importance rather.

Matthew: Agreed, yes.

Host: One of the things you earlier mentioned was around collaboration, right? Like maybe learn-to-learn sessions and stuff like that. Any other recommendations that you have to foster collaboration between security and engineering?

Matthew: Yes. Yes. So one of the things that I kind of call the give and take is I think really what I want to do is foster like trustful relationships both ways first. And the reason why, and we, you know, I don't know if we've alluded to this yet, but security sometimes gets a bad rap.

And that security is a, you know, a bit of a blocker and gets in the way and it's a lot of red tape. So really what I like to try and do is foster a relationship where if there is an opportunity for the security org to provide guidance or assistance, to review something early, to provide a suggestion. We want to foster that. We also want to learn about the product.

As a security engineer, I want all of the members on my team to understand the product just as well as an engineer on that team. So that we can not only provide the security recommendations, but we know how to help if need be. And so we almost play an extension of the team. So each person Each security engineer could be seen as in part a security champion, so to speak. As well as somebody that the team can go to if they have a security concern or a question. So once we start to kind of give and provide guidance and value to the team, we find that they also start to reach back to us early on and say, you know what, I should reach out to so and so because we're working on this thing. I really want his opinion on it. I want to make sure that I didn't miss anything.

So once you start to foster that, you kind of build that trust relationship. And I think from their teams start to feel less and less that there is a block or a gap between engineering and security. Host: Yeah. And so few episodes before this, we recorded with someone called Dustin Lehr from Fivetran. He's a big advocate of security champion programs. And I heard you mentioned that as well, right? And it often bridges the gap between security and engineering and eases out the collaboration.

Because there is friction, right? Whether we agree or not, there is friction between security and engineering, very similar to developers and QA. So having that security champion goes a long way.

Matthew: Yeah, I agree. I think that as much as I am an advocate for security champions, I think that there are levels of maturity and so to get to security champions most likely means that you have a pretty strong and well -rounded security like engineering or product security team and they have the ability to, they've had the ability over a period of time to work with a number of the engineering teams and then they've also empowered them and given the engineering teams the tools and things to succeed at which point then you can have security champions.

It doesn't, again, one of those things like it doesn't happen overnight. There are probably stages to it, but once you get to that stage, it is, yeah, it definitely helps in bridging the gap.

Host: Yeah. So I think the theme that I see is there is no, there is no common answer to all these challenges, right? It all depends on the stage your company at or the primary focus at that point, right? For the company. Yeah.

So one of the things that you earlier mentioned was around like awareness, right? Or enabling the teams so that they understand the importance of security.

What have you seen work when it comes to bringing awareness, like doing the trainings to the developers so that they just don't think of it as a one -time checkbox exercise, but rather learn from it and like regularly follow that?

Matthew: That's a tough one. I don't think I have a perfect answer. I have tried, so I will say I've definitely tried a number of things that have worked and a number of things that definitely have not worked. So to just kind of shed some light on past experience, I have done a number of internal talks and trainings on how to threat model and how to do a security review or how to think about code reviews with security in mind.

These things are kind of like a blip. It's like a great spike and kind of garners interest and then kind of falls off. And so, as one offs, like if it's cybersecurity week or something like that, sure, I think it's great. I think it's great for awareness. Also, something that had… Some other things that also haven't gone so well.

Security trainings could be great, but I think it strongly depends on the format of the training. If it's a set of slides or long-form video and I have to do a little quiz at the end, those are a big no for me.

I would honestly equate them to a waste of time. I think there are some amazing platforms. One of them that I've used in the past is Secure Code Warrior at Auth0, fantastic interactive platform that really makes you feel like you're a hacker and you're looking to either attack or defend. And it really kind of puts you in a real life scenario. So I really enjoyed that kind of made me feel like I felt like the early days of, you know, when I was, you know, trying like a hack the box or one of those kind of like hacking, you know, CTFs that really kind of puts you in the driver's seat and really feels like, wow, like I can see hands on the benefits of thinking about security and how and I'm kind of learning about how to think about security.

So I find that super beneficial. Hands -on training is fantastic. So to round out, I think what I'm trying to get at is I think some things that are consistent throughout and not blips or non -non-interactive are going to be the best ways to engage. And so with the way that I'm driving the security engineering team at Narvar, the goal is constant collaboration between security and the engineers. So there's always essentially a transfer of information both ways.

And additionally on that, any of the trainings that we do, we take feedback from the teams and here at least the teams are very technical, so they want to be hands on. And so making sure from leadership down, make sure that there is time dedicated to security and that there are interactive methods of learning security I found to be very important.

But yeah, all of these things, these are investments of time and resources. And that, from a leadership point of view, starts as a conversation at the top to get that time. This is time that we are going to take away from building the product or take away from technical debt that we are going to invest in security, education, and awareness.

So start at the top and then you start to tinker with what works and what doesn't from there. Host: Right. And like funny that you mentioned it, right? Like early on, even I have seen videos at my previous companies that, hey, you have five five-minute video and there is a quiz at the end and you have unlimited retries as well. So to answer the question that doesn't help, right?

I like the platform that you mentioned, Secure Code Warrior or Hack the Box. So when we publish the episode, we'll make sure to tag so that our audience can also find it.

And the keywords are interactive and engagement, right? Rather than just looking at the content and just giving an exam at the end.

Matthew: Yeah, it reminded me, this is a bit of a tangent, but it reminded me right away as you summarized it.

I was thinking about driving recently, like this morning in the car, I was thinking how I did the driving test. And at that point in time, I probably knew all of the rules of the road. But today, but today on my way home, for whatever reason, the traffic light was out. And so we had essentially like a four-way stop. And the question in my mind was like, how does this work again? Like I haven't, I haven't touched this. I haven't like, I haven't had to study this or it hasn't been on my mind for so long that like, kind of have to cycle through like, I don't know if I remember how to do it. And like, we figured it out, like everyone kind of figured it out.

But the whole point was like, yeah, like when you're not consistently or constantly kind of like checked in with something, you kind of forget, you know, it kind of goes off to a part of your mind because you're not using it. You're not thinking with that brain. You don't need to. But the whole point of this is what security is. You want it, especially for developers, you want it to be on the forefront of their minds. You want them to be not only aware of it, but be invested in how to look at it, how to think about it.

Host: Yeah, that's a very good parallel that you drew to real life. So my last question on this section is, the threat landscape, the cybersecurity landscape is evolving rapidly, right?

Now, when it comes to these learning needs, technical learning needs, what would you recommend to security leaders so that they pay attention to that?

Matthew: Yeah. So I think there are two things that come to mind right away.

The first one is whether it's you as a leader or the team that you're building, build a technical team. As much as I understand that compliance frameworks and privacy are important, having the ability to be technical and really understand how something works.

I might be biased because I'm an engineer and I've been technical, you know, all my life, but I really find that once you truly understand how something works, like, it's undeniable. And so I think it's really important to either build the technical team or have the technical ability to dig in, to really know what we're talking about. And you can, again, translate your technical knowledge into the right knowledge for leaders, et cetera. So I say that first and foremost.

But then the second one that I would say is keep up with like, you know, kind of polar opposite to that, keep up with the news and what's relevant and the attacks that are going on in the space and those types of things. I think it's really important.

As we mentioned, you know, landscape is changing. You know, currently you can't go a day without reading something about, you know, AI and machine learning as an example. And so, you know, start to read up on what type of threats are we talking about here? How does this thing, how does this even work? You know, what do we expect to see in the future as it pertains to potential threats in this world.

So yeah, try and keep on top of the cybersecurity kind of news, I'd say.

Host: Okay. So trying to understand what's going on in the world, like latest threats or latest attacks, what caused it, understanding the root cause and stuff like that, so that you are aware and at the same time, maybe you can apply some of those practices in your organization as well.

So if I change the audience of this question, instead of the organization,

What advice would you give security professionals who are trying to build a cybersecurity career?

Would your advice be the same or what advice would you have for them?

Matthew: Really good question. I think for security professionals, first and foremost, security is… becoming very broad and in a good way, there are a lot of different areas of security where you can become a professional in.

So really think about areas that you enjoy, areas that you maybe don't enjoy. I think about, you know, members or professionals that really care about, you know, kind of red team activity. So pen testing, trying to break things. you know, becoming very, you know, becoming very technical with looking for vulnerabilities. That could be one area.

You know, another area is maybe in product security. You want to be a bit more of a generalist. You want to have a strong understanding of application code and infrastructure. That could be another, maybe you want to be a leader in the information security space. So a lot more tied in with, you know, you know, compliance and privacy frameworks and that landscape that's its world.

So really thinking about where you want to excel. I'd say is a really good first step. I've been start to dive into the content there. I think, you know, as much as certifications are important, I think certifications aren't the be-all end-all. There are all types of resources available. Again, could be a bias, but I feel very much dive into that world.

If it means, you know, if it means taking a course or if it means, you know, working on a project or if it means writing up, you know, a medium article on something. I think that that just kind of stretches your brain and allows you to continue to dive in and prove that you're continuing to learn in that space.

So I'd say first and foremost, kind of pick your niche and continue to dive in. I think security generalists have their place, particularly maybe in certain startups, but I think as the threat landscape continues to expand, we are going to continue to look for professionals in certain areas.

Host: So find your niche, get like have hands on, get your hands dirty and keep upscaling you, yourself rather.

Matthew: So that you continue to grow there. One thing that I didn't mention, but I realized like as we kind of now left the era of COVID is get involved in communities.

So if there's a community that you, you know, it could be a Bsides, it could be, you know, something else along those lines. There are all types of communities that are around. They're most likely going to be both virtual and in-person.

I think it's a great way to connect with would-like minds to both learn and to share. So I think that that's great. The exchange of knowledge in these areas is really important and another way for us to all grow. I do it as well.

Host: Yeah, I think. Last one is equally important, where you meet with like-minded people to learn and also share so that others can learn from your experiences or your mistakes. Yeah.

So yeah, that's a great way to end the security questions. Thanks, Matt, for the engaging conversation.

Thank you. Let's go to the rating security practices.

Rating Security Practices

So in this section, I'll share a security practice and you should rate it from one to five, five being the best. And you can add context while you're providing a particular rating.

So let me start with the first one. Development regularly tests an incident response plan to help quickly detect, respond to, and recover from security incidents.

Matthew: Ooh, that's a good one. I'm going to give this one a four and the reason why I give it a four is incident response is one of those things where it's never considered important until it's really important. And so when you have your next equivalent of a log four J and you're like, shoot, this was a lot harder to, to get to the bottom of. And we don't even have, we might not even have the confidence, you know, that we had hoped in making sure that we covered everything that that in and of itself highlights like, wow, if we did tabletop exercises, even, you know, quarterly or once a year, it would at least got us even a little bit closer to making this an easier, an easier process.

So what I like about the incident, you know, kind of response is you might be able to realize that maybe we need improvements in process, right? We, you know, teams have changed, structure has changed and you know, what we haven't really thought about that because it hasn't happened.

Or two, we realized like, Based on our current landscape, we might not have the right tools in place. So maybe there's a gap there that might be worthwhile considering like based on this tabletop exercise that we did, we don't have a tool in this space. So yeah, typically I find both it helps with both kind of finding gaps in process and in kind of visibility.

Host: Yeah, I don't know if this is accurate, but I find it somewhat parallel to like insurance, right? You don't need it until you need it. but you need to have it in a way.

Matthew: That's right. Really well said.

Host: Thank you. The next one is granting users unrestricted access to systems and applications so that we can move fast and roll out new features quickly. gosh. OK, so what's the one to five? Is five totally not acceptable and one very much is?

Host: So five is the best and one is the worst.

Matthew: So, okay, so if I understand correctly, this is a one, or actually maybe I'll give it a two. This is a two. And the reason why I gave it a two and not a one is like, there are a number of use cases that I could think of that are, you know, theoretical in which providing developers access to certain areas might be required, but, but, there, there are fantastic just in time or JIT options here.

This is, so it's not unfettered unrestricted access forever. It's. This developer needs to have access to this particular environment for this period of time under these particular instructions. That I could see as maybe, you know, a way that it's not the worst, but at least there's some mitigation in place. You definitely should not do it, but if you are considering something even close to doing it, you have to have some just-in-time access where you're, you're at least restrictive to some degree on expiry.

Host: Yeah. Yeah. Makes sense.

The third one is continuous integration is a must for DevOps practices. Security architecture review should be conducted as part of the integration itself.

Matthew: Hmm. So I'm going to give this one a three. And the reason why is I'm going to kind of fall back on really depends on the organization. Again, every organization moves a little bit differently in terms of their process.

Some organizations might rely heavily on Agile, CI, and CD plays a part in continuing to integrate and deploy changes to code. Some other organizations might have longer drawn out processes where they have releases every quarter, et cetera. So I think it all depends.

But in terms of the security architecture piece, again, I do think that maybe not on every kind of, you know, every CI run, you do a security architecture review, but there should be some period of time, you know, whether it be a trigger of a large feature change or a security, a security-specific change, there should be triggers that cause a security architecture review with the security engineering team.

So, I think that there are pieces of that that are important. I will fall back on, I think it's going to depend on every organization and we don't want security to be a bottleneck. So I think that there should be points or reasons for the security review.

Host: The theme of the episode I see is it depends. There is no silver bullet. I am joking, but I understand.

The same thing applies to engineering also, right? When it comes to architecture decisions. You cannot have one size fits all answers. It always depends. That's a very favorite answer of architects as well, that it depends.

Matthew: You're not so funny you say that. I was essentially, I spent a lot of the time early in my career at Symantec in particular, trained by an architect that had many, many years of experience. So maybe I picked it up from there. I'm not sure.

Host: I totally get that. So yeah, so before we end the episode, I have one last question, which is do you have any recommendations any blue blog or a book or a podcast anything that you want our audience to pick up?

Matthew: Ooh, that's a good one. I'm trying to think of I have to pick one. Okay, so I think what I would strongly suggest is everyone take a look at the book, The Art of Leadership. It's Small Things Done Well by Michael Lopp. Michael Lopp also has a fantastic kind of blog called Rands in Repose. Yeah. Yeah, so you're familiar. Yeah.

Host: Yeah, the book is amazing and his blogs are also amazing. So Yeah, thank you for sharing that recommendation. So when we publish the episode, we'll tag that as well so that our audience can go there and learn from there.

Yeah. So yeah, thank you so much, Matt, for joining and sharing your learnings and sharing some of the best practices around hiring and keeping the talent as well. Thank you for coming to the episode.

Matthew: It was a pleasure.

Host: And to our audience, thank you so much for watching. See you in the next episode. Thank you.