Kayla and Taylor talk about security roadmaps.
Hosts:
Kayla Williams
On ITSPmagazine | https://www.itspmagazine.com/itspmagazine-podcast-radio-hosts/kayla-williams
Taylor Parsons
On ITSPmagazine | https://itspmagazine.com/itspmagazine-podcast-radio-hosts/taylor-parsons
________________________________
This Episode’s Sponsors
Are you interested in sponsoring an ITSPmagazine Channel?
👉 https://www.itspmagazine.com/sponsor-the-itspmagazine-podcast-network
________________________________
Episode Description
What is a security roadmap? Why is it important? Who should be apart of creating the roadmap? All of the roadmap items and a very interesting perspective from both Kayla and Taylor.
________________________________
Resources
________________________________
For more podcast stories from The Locked Down Podcast With Kayla Williams and Taylor Parsons: https://itspmagazine.com/locked-down-podcast
Watch the webcast version on-demand on YouTube:
https://www.youtube.com/playlist?list=PLnYu0psdcllSNOVxx-zkXPYN6dxzuG8GG
How to Create a Solid Cybersecurtiy Roadmap | Locked Down Podcast With Kayla Williams and Taylor Parsons
[00:00:00]
Kayla: Welcome to the latest episode of Lockdown with Kayla and Taylor. With cybersecurity encompassing so many facets of business, it can be overwhelming and stressful. With our help, you'll be able to make sense of it all, and this week we are discussing how to create a solid cybersecurity roadmap as a first time security lead.
Or perhaps, you've been a security lead for a while and you're moving into a new industry and a new role where you need some assistance. So that's,
Taylor: that's huge. First time security leaders. That's scary. Yeah.
Where do you begin? We talk about being leaders and oftentimes we talk about the soft skills required or the management skills required of doing one on ones and doing peer reviews or. Or downward reviews and upward reviews. But, whenever you become a cyber security leader or a security leader within an organization, like you're stepping into so many facets that affect the business obviously you've stepped into quite a few roles [00:01:00] and different parts of security and ownership of teams, where do you really begin?
How do you begin to identify like the needs of your team compared to the needs of the business?
Kayla: Yeah, that's a great question. And we're actually going to cover. Stakeholder management in a future episode, which that is a huge part of building a cybersecurity roadmap. So I'm going to put that piece to the side for right now.
But I would say firstly, is you need to understand your organization's objectives and that's where the stakeholder management comes in. You need to go in and you need to meet with people. But review websites, look at the, the goals and objectives, look at the OKRs KPIs. Talk to your stakeholders and understand you know what their overall goal is and how they are using that to align to the objectives from the board.
What's what is the overall mission? Identify how Cybersecurity fits into all of these components of your company, whether it's [00:02:00] sales, customer success, marketing, product security the overall sentiment that I see is that security is a cost center. They don't, they have their own priorities, their own goals.
They're not trying to address my specific needs. So if you can go in and understand what each team is doing and what the risks are, then you're better aligned to the overall organization. And you're going to have much more success getting buy in for the things you need to do if you talk to people and understand how you can help them versus force things on them.
And then with that, I think as you're having those discussions and you're doing your own homework and you're reading websites and white papers and things assessing the current state, what do you see is missing? What do you see as lacking? Look at existing policies, procedures, practices build a SWOT, understand the strengths and weaknesses, your opportunities.
This again. I know I'm super biased, but this is where [00:03:00] GRC skill set comes in handy. Being able to assess the risk of the things that aren't there. The unknown unknowns is a skill set. So I think that's super important as well. And that helps you to identify your key assets. Those key risks and understanding what's the most critical to the company where are the keys to the kingdom and are they protected?
I think that's huge. You have to know that
Taylor: they're hidden usually under the mat at the front door. So you talked about understanding objectives and assessing current state. I identifying key assets and risks going into the unknown and establishing the known. As like a new security leader, are you coming in with a predetermined notion that you know how things should be going because you've either been an operator, you've been in the industry for a while, or are you allowing like your assessment of the current state?
And the known [00:04:00] objectives and other things to establish where you're going to start your roadmap.
Kayla: I think it'll be a little bit of both because as a practitioner and as a strategic thinker, you're always going. Ah, but, this has happened before. This risk has come to fruition. That's always going to sit in the back of your mind.
It's never going to turn off, but you have to be open minded in the sense that what worked at one company in one industry may not work for you. Somewhere else, for example, moving from financial services, a very highly regulated and disciplined industry into SAS, the way you did business at a financial services company will never translate one for one into what you'll do to address the same type of risk in a SAS company.
So you have to be willing to have discussions to under you have to, yeah, you have to be able to say it and admit it, right? I can't have that approach because. It's not the [00:05:00] same. But I think that also goes with like the next step in building your roadmap is understanding the legal and compliance landscape, understanding your contractual obligations, which are also part of the legal landscape.
What have you already committed to customers and partners, but where
Taylor: are you saying sales sold something?
Kayla: What? That never happens.
Understanding that landscape and what is permissible and not in the type of industry and company that you're in is very important as you build your assessment in your road map.
Taylor: Yeah, and I think that, I'm obviously, I've both been in security for a very long time, different parts of security to write like I've done in point. I've done attack surface management. I've done threat intelligence, external attack, surface management sim, and Uiba. And, then, I've still within the security realm.
But more focused on defense tech as of recently. And in the way that, I operated [00:06:00] as, a support engineer or technical account manager, focused on endpoint security compared to the way that I operate within, the defense tech realm. I, I had preconceived notions of this is how I prioritize or, this is how I escalate things that I see of importance.
While they're the foundations appear to be the same, there are, nuances in how you execute.
Kayla: Yeah, absolutely. And that's the nuances of execution is really where the stakeholder management skills come in, because there's going to be a lot of compromise and back and forth and hearts and mind campaign that goes into having a successful roadmap.
When I say successful, bought into and supported. Across the company. I haven't, that consensus is going to be important.
Taylor: Yeah. And so we've talked about, GRC, of course I w I would actually like to know if we've had a single episode where some portion of GRC hasn't come up yet. [00:07:00] I think we should research that.
Kayla: Yeah, I think we should too. I don't think so, but
Taylor: That's the
Kayla: point. GRC is everywhere.
Taylor: So we've assessed this the current state. We've talked about identifying key assets. We've talked about compliance requirements and regulatory compliance sales sold something right.
And we have contractual obligations. How do we Then prioritize. We know the objectives.
Kayla: Yeah, that's it. That's it right there is knowing your objectives, setting those goals and objectives. So when I've done this in the past, I have set OKRs. I prefer to go in that route. That's objectives and key results if you're not familiar with OKRs.
So for example, one, I think one very common OKR is going to be the objective of evolved security culture. I think every single. See, so I've ever spoken to has had that like remit right within your first 30, 60, 90 days work on [00:08:00] this. So that's the objective. So the key result could be execute comprehensive security awareness training, achieving 75 percent of completion or 100 percent of completion by a certain date.
And then what's your criteria for completion? Who are your dependencies? Have you met that goal by that date? Begin a CISO publication with a, from an awareness perspective, like a blog, internal blog for awareness by the end of whatever quarter, establish your criteria for completion.
Dependencies, blah, blah, blah, right? So go through and look at your objectives. Other ones I've seen are, develop and coordinate a security risk management framework ensure timely reviews of customer due diligence, same thing with vendor due diligence and making sure your stakeholders there are aligned securing your business applications, securing your corporate assets, et cetera.
provide excellent customer service, right? So these are the objectives that you need to start looking at as a CISO or a security leader in any function that you deliver a service [00:09:00] for. And really, hold yourself to them, get buy in from the rest of your team, make sure that the objectives align to everything that's there.
And then you'll look at those and say, okay, what's the company's a mission statement here. How do I align to the company's already existing road map? Maybe it's a vendor due diligence because there's been a vendor related incident in the past, or maybe it's customer delight and focusing on the customer aspect and then prioritize things under there.
Now when it comes to tools and prioritization, This is, I think, a big question, right? It's I don't have this budget, right? Like the Gartners and the Palo Altos and the Wakefields and the Foresters are all saying, I need to have a SIEM and XDR. I need to have all these really expensive tools like ticketing systems, software management hardware management for asset inventories.
I need to have vulnerability management. I can't afford this. How do I prioritize it? Take a deep breath and go back through your assessments and see [00:10:00] what have you experienced is lacking. Completely missing or lacking. And then what is your budget? What's your pool? Everyone, if you're a security professional and you're a leader, you should know what this pool is.
And then sit there and say, okay, what's going to give me the biggest bang for my buck? Is it a system, a platform system that is massive that, you can have HR in there and change management, IT management, security, GRC, procurement. If you don't have buy in from stakeholders, do not go in that direction because then you're going to be disappointed when nobody else buys in and you're left with a million dollar tool that is only quarter utilized.
But look at what you have. Have you had incidents in the past That have had very bad repercussions for your brand, where you would have benefited from having a seam or a vulnerability management tool and process in place. What's going to make the company start to trust the [00:11:00] security function.
What's going to help build trust with your customers or your prospects, partners, the industry. And then have those discussions say, Hey, here's my draft roadmap. This is where I think it will get the biggest bang for a buck. We'll be able to really enhance our security posture and the security maturity of the organization and build those things that build the OKRs or KPIs and how you're going to be able to demonstrate that to those stakeholders, whether it's a steering committee or the board or just the executive team, you owe that to them to be able to show the value add because security is not a cost center.
And that's just how we start to deliver value.
Taylor: I think that's huge. Often people, oftentimes though, we start to talk about the cost of things, and we only discuss the. Procurement cost.
Kayla: Yeah,
Taylor: we there because sometimes we can say, Hey there's an open source tool [00:12:00] for this, right? We need to end point metrics.
There's OS query, OS queries, free open source tool. There's open source seams. There's no open source data collection tools. What we. Often don't account for when we're starting to talk about roadmaps and deliverables is what is the actual internal cost of delivery? Is there,
Kayla: is there
Taylor: infrastructure that needs to be provided?
Is there a other team resources that need to be provided? And that does go back to the buy in and the understanding and aligning to, roadmaps and objectives. But every time we, every time we talk about this, it's about changing the security culture.
Kayla: Absolutely. That's one of the first OKRs that I establish is.
working on evolving the culture even if you've been in business for years, if you're not, if the organization has not historically paid attention to security or have a CISO or security leader, whatever the title may be, they like, Oh yeah, [00:13:00] we sit behind a VPN. We're fine. We have MFA. We're fine. No, that culture has to change.
That is not going to cut it today. And you're absolutely right. That stakeholder management, the security awareness, the security culture, it all fits in and your roadmap should be reflective of the things you need and all encompassing. My, my three year strategy is people process and technology. And I go through and I'm a bit overboard.
I was a project manager, so I have a lot of stuff in there, but I don't have a PMP, just a master's. I'm going to put that out there with a disclaimer.
Taylor: Sorry.
Kayla: No, because a PMP is really hard and those people deserve a lot of credit for it. So I just want to put that out there. I do not have one, but what I do have is a particular set of skills that I've honed over time.
Like in my roadmap, I have ABC, I prioritize what I need, and then that will change. The document is a living document that will change over time. Because if there's an [00:14:00] incident, everybody's objectives change. If you get a new customer that has a more stringent requirements that then are going to impact shared infrastructure somewhere, excuse me, somewhere your objectives and your goals are going to change in order.
So you have to be able to pivot again, favorite word and that's really where having a roadmap that you can easily say, okay, I was planning on doing this in Q1, something's happened. I have to push this out. I have to move something else up. in people and maybe I have to hire people or maybe I have to hire people and bring in new technology and then train the people on the new technology from a process perspective.
Now I'm hitting all three areas and having that level of transparency is really important to make sure that you're still aligned. To the goals and objectives of the organization.
Taylor: So with your roadmap, it, and I find that I don't like roadmaps like generally. Just because at times, like the way that [00:15:00] roadmaps are presented, it gives you a stringency of this is how I'm going to execute, and this is the only way I'm going to execute.
And it almost sets a precedence of. Nothing else is important outside of this delivery with confined to this roadmap, right? Know that that's an inaccurate, unfair evaluation of
Kayla: I think a roadmap should not talk about execution of how full stop your roadmap should say what needs to get done, not how it's going to get done.
So if you have a roadmap. that says I need, a ticketing system. It should never say what that ticketing system is because you should be getting together with all of your stakeholders as part of your project kickoff and saying the objective of this project is to identify a, ticketing solution that's going to work across the organization within the implementation timelines that we agree.
And then you should, as a group, [00:16:00] work together to identify a ticketing system that meets all needs. Because maybe it's just an IT ticketing system or a security team ticketing system, but then HR all of a sudden wants tickets, legal wants tickets, they can track their work. You need to make sure that the criteria that meets their needs is met as well.
So I don't think a security team, unless it's their own tool, Should force any tool on any stakeholders at all. It should be a group decision. Consensus should be made because that's how you burn bridges. You can't force things on teams. Cause what if it doesn't work the way that those teams work and now you're forcing a change that is not necessary.
Taylor: Yeah, no, that's fair. And I, I've come across that not just specific to security, but like implementation of an LMS system where, you start talking Internal training or one boarding of an employee within a certain department. And then all of a sudden it's Oh if we're going to onboard employees, they're like, [00:17:00] maybe we should publish our security awareness training there and it's Oh, okay.
And then it's Oh this doesn't work here, but this works here. And then HR is Oh if you guys are going to do training and employee onboarding here, Maybe we should do like general onboarding here. And you're like, wow, like that's scope
Kayla: creep, that's scope creep. And that's where you need to bring all of your stakeholders together and have, I know you're laughing.
Cause I know there's a, there's an example that's in your head right now where this has happened somewhere, I've seen it happen lots of times where, we tried to roll out an IAM tool, had every single stakeholder on board, had a kickoff call, we had a charter, we had. Why do we need to do this slides?
We did all of our homework and then the, one of the key stakeholders decided to change all of their cost center structure and put that from the finance team into the HRIS system, which is then broke every single thing that was built into it. Build an I am tool. And then, oh, it's the tools fault. That's not you made it an [00:18:00] unapproved change.
You didn't come back to the project team and talk about this. You didn't involve the right stakeholders. So that I think is a discussion for that stock of a stakeholder management conversation. But you're absolutely right. There, you need to make sure that you have consensus, but consensus and buy in does not mean that the resources are going to be available when you need them to be, which is why I always, I have a little table next to every part of my roadmap.
It has Q1, Q2, Q3, Q4, Q1, Q2, for three years going out highlighted. And then in my description of each of those projects initiatives, if you will, I say who I need, who's agreed to have the resources available, do things change? Absolutely. Priorities are going to shift in the other functions pivot, but that's when everybody needs to get back together and say, okay, we need to have a governance over this process.
This is what this is. When are these resources going to be available? Or do we bring in a third party to do it for us? Like the PS hours and things like that, professional services, or is [00:19:00] this no longer a priority? So if that's no longer a priority, these are all the things that are going to be impacted by this change.
Hey, CEO. Hey, steering committee. Hey board. Are you okay with this change? If not, we need to do something about it. If you are cool, put it in writing. I want an email. And done moves to the next.
Taylor: So I know that we're short on time here. I guess I just really, I have one last question for you. Whenever we talk about, building roadmaps, having security roadmaps Modifying, gaining buy in, all of, like all of the things, right?
Is the security roadmap intended to be viewed by all employees? Should they be aware?
Kayla: I think they should be aware of high level. Yes. Of where it's going. Do they need to know funding resources and budget information and approvals information? Absolutely not. That should be. Really [00:20:00] locked down just the security team.
And if you have if you're sitting inside an engineering team, like just the engineering leaders who can see that or a product team, when I worked for the CTO, the product team had, they could go and look at my roadmap whenever they wanted to think, I don't know, but it was there.
But my teams, it existed. And then what we would do is my teams, when we got to get together quarterly. And review all the initiatives tied back to those objectives, complete and incomplete at the end of the quarter. If they were incomplete, why? Was it a dependency issue with, vendor, internal system limitation?
Work on a remediation for that. Approve, get approval amongst us for when we were going to have a new due date and track it from that perspective. And celebrate the wins. Get a list of all of your completions and say, Woohoo, we did this thing. We finished. And that it, especially in our field can feel so good having a completion for something.
So I think [00:21:00] it's really important that you communicate within your teams. You're all collaboratively held accountable all, sorry, working collaboratively, held accountable. And then, Celebrating those deliverables and milestones and completions when appropriate.
Taylor: Yeah, no, I 100 percent agree.
I I am a firm believer in violent transparency. So not even just not even just the wins, but sometimes the lessons learned.
Kayla: Yes, absolutely.
Taylor: It can impact such a microcosm of, it can have such a microcosmic effect on an individual contributor and the way that they are approaching things and potentially impacting that roadmap that they weren't aware of.
So I am all for violent transparency. I agree that there are things that, yes, funding resourcing plans engagement with outside consultants, especially like if you're doing some shadow it stuff you're doing some pen testing or, you're doing static code analysis. There are things that obviously [00:22:00] don't need to be violently transparent, but when we have those wins or we have those adjustments or those lessons learned, I'm all for
Kayla: it.
Yep. I agree with you. I completely agree. And I think The lessons learned, if you see that you have, and this will be my final word, I swear I'll stop, but if you see that there's a particular function or individual who is consistently blocking what you're trying to do and you have the evidence, have a conversation with their line manager or your peer, someone that you're comfortable with and say, how do we fix this?
How do we work collaboratively and move past Is this person overtaxed? Are they not skilled? Are they, are they unaware? Is there a misalignment? And then, deal with it that way as well.
Taylor: A hundred percent. Kayla, I really appreciate your time. I know that we got a lot of episodes lined up with some really awesome awesome guests.
So I can't wait. This has been a great episode and I think it's really eye opening. So I appreciate your time today and we will talk soon.
Kayla: Yes. [00:23:00] Thank you. Have a good day, everybody.