Welcome to Conversations with CISOs, Security Leaders, and Technology Executives, where we sit down with the leaders shaping cybersecurity and enterprise technology. Today I'm joined by Nigel Sampson to discuss building a security program when you're the first security leader. Nigel, thank you for taking time to join me today to get us started, could you introduce yourself and tell us a little bit about your background and your current role?

Thanks a lot, Sullivan. ~ A little bit about my background. ~ So ~ I've been in cybersecurity for last sixteen years. Can add another ten years doing security assessments, running my own business, more of a tech company more than security and handling risk management assessments. ~ I'm a CISSP in the last sixteen years I've worked across multiple verticals, including oil and gas, healthcare, banking, ~ global publishing, and more recently in higher education for the main community college system, which is where I'm currently ~ employed as the CISO responsible for ~ securing seven different colleges across the state of Maine.

So when you walk into an organization as its first security leader, where do you start? What are you trying to understand in those first few weeks before deciding what needs to change?

So I start by listening and not really changing anything. ~ The first few weeks I'm gonna try and understand three things. ~ What keeps the leadership awake at night, ~ what are the organization's most critical functions, and what are the largest risks to those functions? So I'll spend time with the executives, IT leadership, ~ maybe internal stakeholders, managers, application owners, compliance stakeholders, and sometimes the end users as well to kind of get a feel of what the security culture is like. ~ I'm looking for existing pain points. So, you know, historical incidents, audit findings perhaps, maybe some of the technical debt that has built up over recent years, and kind of the cultural ~ attitudes towards security? Do they see it as like the department of no? Sometimes there there isn't even a security department before I've started. So people sometimes don't know what to expect. But ~ before I make any major recommendations, I just want to understand how work actually gets done across the organization.

So on the being the like the really first, absolutely first security person, have you ever found that you have to like teach leadership what a security function is supposed to do and what they should expect from you?

Yes, because many organizations sometimes don't know how to hire security people. They don't know what is the going to be the right fit for the organization, even though they've gone through a screening process for a number of individuals and a lot of people talk the talk, walk the walk. But when they actually get hired, it's like, okay, so what are the strengths of that security person? What have they done? What can they do for the organization? And how are they going to mature the program? So ~ a lot of the time it's it's understanding the organization, building the relationships with the executives and the departments. ~ So you kinda build that rapport with those people.

So after you identify kind of you talk to those executives, you have identified those key risk areas, what is the area of security that you build out first? The people, the processes, or the technology?

Well, it's usually going to be the process first. You know, technology amplifies whatever exists underneath it, right? So the you know, it's going to identify the issues and the risk items. So the the first priorities are gonna be ~ just look at the processes, you know, do they have a good incident response plan, vulnerability management processes? Do they have a a solid program in patch management? Do they have asset inventory? Do they actually know what they're trying to protect? Right? ~ Risk management and governance is another area where yeah, I'd have to look at to see are they actually do they actually have ~ the correct policies and processes, procedures in place? ~ And basic security awareness. Do they even have a program? Do they have somebody, even if it's just a vendor, sending out bulletins to the employees? So I kind of look at those as ~ foundational to see if they exist. And then just start focusing on building the right team and then selecting the tools that gives me the risk visibility.

So when it comes to building out that right team, how do you approach hiring and the team structure when you're building that security function from scratch?

So if it really literally is from scratch where I think three of my previous employers hired me as the first security executive. ~ And depending on the size of the company, larger companies I'm looking for managers, director level, employees because I need somebody that maybe is going to take care of the security operations function and maybe somebody that's going to take care of the security engineering function. So ~ they are different because the engineering side they're gonna be looking at maybe current solutions or the solutions that I'm gonna end up procuring they're gonna have to implement and manage. And on the security up side they're more the consumer of the information and the data that those solutions and tools are going to be providing. So they're going to have to act quickly to identify incidents and events using those solutions. So ~ if it's a big enough team where I'm gonna have to kind of start at the top, that's where I'm gonna start with operations and engineering at those levels. If it's more of a smaller company, then I'm gonna be looking for individuals that can wear multiple hats. It could be somebody that's both a security analyst but has implemented solutions where or they can at least do the tuning of like a SIEM for example. So they might get to be the security analyst but they're also going to have to tune the SIEM as well. ~ So it really depends on the size of the organization.

Okay. ~ And if you only have the resources to make like one good security hire, what's like that one role? That's a must.

~ It's going to be probably a seasoned security ops analyst. Somebody that can hit the ground running, they're gonna start looking for, you know, events, they're gonna start correlating events, they're going to start identifying problems and issues and start working with potentially IT teams or application teams that work on remediation of issues. ~ Somebody that's gonna be able to maybe even formulate an incident response plan if one doesn't exist. So that's probably gonna be the key hire initially, which may be in any organization.

So speaking of those relationships with IT, how do you establish ownership and start working with IT infrastructure and engineering when the business doesn't have a formal security function yet?

So it's working with the executives, work building those relationships, ~ it's building a rapport, understanding what they see as the issues. ~ and normally it's ~ I've done some groundwork before I have a meeting with the executive board or an executive committee ~ to where I can formulate a strategy and get their buy-in and sometimes they'll suggest things that I hadn't thought of ~ that's happened before. But normally ~ when I'm presenting strategies and initiatives, they really sometimes they don't understand a complete risk landscape. And once I've done the risk assessment, provided the results and gotten their buy-in, normally it's ~ a quick approval and I get a lot of positive feedback from the executives. So I normally start at the top and kind of build that rapport first.

Okay. Do you have any have you found any particular strategies or methods effective for building that rapport with the executives?

Yes, it's really having a dotted line to either the audit committee or the CEO so that I can present quarterly updates to them, normally just in a dashboard or something that gives them metrics or some kind of maturity model. And having that regular communication and cadence keeps them aware of the risks that they're actually accepting. Most boards in companies don't understand risk. ~ They don't have they don't have visibility into those risk environments. They don't have somebody that can explain risk in say layman's terms. ~ And sometimes organizations haven't even conducted a risk assessment. So they really need somebody to explain what the risks are, how they can be remediated, what the costs are gonna be, how long it's gonna take. Those are all questions that any board should be asking a CISO or whoever's leading the security program. And the leadership of the security department should be forthcoming with those answers fairly quickly. ~ Because they should understand walking in what their risk landscape looks like and how they're going to remediate it, how they're going to mature the security program, how long it's going to take, costs, how many people they're going to need, are there process gaps, all those things. You kind of find that out in the first ninety days, six months of just having those conversations. Doing some initial investigations, researching the solutions and controls that they have. Sometimes it's easier when you have a compliance program in place because the compliance program requires that you do certain things to identify control gaps and ~ process issues. So you can glean a lot of good information from those reports and to see how the company is doing. PCI, for example, ~ is very clear cut and you normally have to have third parties involved to do ~ the assessments. So ~ but that only covers a certain area of the environment. So ~ things like ISO certification can be ~ very prescriptive and in the solutions that you have to put in place because that's it's a very rigid framework. ~ Whereas maybe a SOC one or SOC two ~ they have a certain number of controls that you have to meet, but what goes in the report can sometimes be negotiated. So

Ha ha.

it's not always ~ let's say, comprehensive. ~ So you know, NIST CSF is what a lot of ~ companies use, covers a lot of the domains in security, covers a lot of ~ key areas. ~ So I normally build programs to kind of that compliance structure.

So moving on to building out the technology stack when you're the first security leader, how do you approach that ~ and determine what the organization actually needs versus what's better fit to ~ address through people or processes?

So I look at which risk does that solution reduce, right? and is it currently a people problem or is it a tech problem? Right? So you kinda have ascertain that before you start spending the company's money on these solutions. And I look at can it be operationalized effectively? Meaning is it intuitive to navigate? Is it easy to implement? Is it easy to maintain? Is there a cost to that maintenance? ~ And effectively does it really do what it's supposed to do? ~ I get a lot of solicitations from vendors. I've probably deployed about 55 different security solutions over last 16 years and I've used probably five or six different VARS. And I've known sales reps in different companies. I've gone from one company to some that have gone through five or six different security companies. ~ And my you know, my when I if I get a new rep from a new company, ~ they ask me what I look for in a solution and you know, when I'm building a tech stack, it's always going to be ease of implementation, ease of navigation. Can I get to the information I need very quickly? Can my team use it intuitively? And do they get the information that they need quickly? And what's the reporting like? So I bought CrowdStrike ten years ago when they didn't even have their registration for virus detection, ~ and their reporting sucks, but their EDR was the best. And to this day, they're still the best, but their reporting still sucks. So, you know, I've the best reporting module that I've come across was Zscaler. ~ They have canned reports built for CISOs in security leadership to where I can just click a box and it gives me a PowerPoint presentation of the last ninety days of that product with all the metrics built in. So ~ you know it saves a ton of time, it's built into the product. I don't have to start hunting for metrics and pulling together a PowerPoint. Although I could do it in AI nowadays, it takes you like five minutes,

Right. Very easy now with

but ~

Claude or Chat GPT or something.

Absolutely. And I've done it and it's amazing how I can build a deck ~ just with

Mm-hmm.

a few, you know, a few items. So when I build a tech stack, it's gonna be about, you know, ROI operationalize ~ operationalization of the product, but also the interoperability of those products and interconnectivity. ~ I found a a lot of solutions now come with open ~ APIs and they tout that they can connect to pretty much anything. ~ and I l I expect that from most security solutions. Cause you can't just they're not ~ they're not gonna be the silver bullet. And they're gonna have to interact with every other solution that you have in your tech stack. So they have to have the ability to have open APIs and connect. And so I can build, even if I build an AI, which I'm currently using, to ~ pull in the data into ~ dashboards and sometimes real-time alerting. You have to it's gonna be a requirement for any solution in this day and age. You can't just build a solution that doesn't connect or doesn't have open APIs.

So when you're looking at each of these areas, people, process, and technology as a whole, and you're working it into your first security roadmap and establishing your budget as that first security leader, how do you approach that and build that out?

So it kinda goes back to you what we spoke about earlier about is it is it a people problem, is it a tech problem, you know, do I have a team? Don't I have a team? 'Cause it's gonna be different from one organization to the other, whether you have a team or if you don't have a team. So if you don't have a team, then you're really looking at it from a risk standpoint, then you would conduct a risk assessment to identify, okay, where does the risk lie? What solutions am I going to have to get to? ~ Get me risk visibility and ~ what can I use to be proactive to ~ be preventative in nature and protect, right? So you can look at the NISCSF and the six pillars and you kind of look at the front end and you're just like, okay, I need to detect, prevent, protect, kind of those kinds of things. And what solutions are going to help me get that done first. And then you can start looking into kind of the response aspect and recovery aspect. So ~ the governance kind of goes along with it, which is why if you look at the CSF, the governance block covers all of the poly the the pillars because you have to have policies and procedures ~ documented for each one. So ~ but kind of that's where I would start and if I have no team and you look at the risk assessment, you you build the strategy first, you get the buy in from the board and then you start with those key hires and you kinda start from the top down and then you build those solutions that are gonna make ~ an immediate impact ~ but also are going to reduce the risk significantly as soon as you've implemented them, right? So there's gonna be some outliers of kind of smaller solutions, the nuanced solutions that might fix a particular risk in certain areas. But you're really looking for how you're going to cover the bisc the biggest risk items first. ~ And that's kind of where I would start.

So what are some of the biggest mistakes either you've made as a first time CISO or you've seen other first time CISOs make when they try to build out too much too quickly?

~ I think it's trying if ~ some new CISOs they try to cover all of the items at once. So they're trying to make an impact, try to do it quickly and try to remediate all the risks at the same time, which is gonna be impossible. And if you go to IT and say, here's my shopping list of items that I've got to get done within the next two weeks, they're basically just gonna freak out and say, no, it's not possible and you then you kind of end up with losing that rapport and that connection and then you have an uphill battle of trying to get things done in a in a you know a suitable timeline to where you can actually get those solutions in place. And it's I've dealt with some large IT departments that don't believe in how some of these security products work. I've had vendors had two or three meetings with IT teams to say this is how this works and the the IT teams don't believe it. And normally those those are folks have been with a company for twenty years, thirty years, whatever, and you know, they're used to things working a certain way, and then you tell them here's a new technology that's going to do this, and they don't believe it's going to work. Until you actually get through the procurement and you start deploying, and they they suddenly realize, wow, this is going to work, and it really does work that way. Probably a good example of that is a network access control system. When you say, okay, I can build ~ policy-based access. And you're basically stepping on the network manager's toes because you're gonna say anything that joins this network, I'm basically gonna shut that port if they don't meet these this specific ~ OS levels and or patching levels. ~ Until you show them and you test it, they don't really believe you. ~ and I deployed a solution at the MBTA where we discovered, you know, Wi-Fi ~ access points across the network that ~ once sanctioned or approved. So instead of going to those environments and just, you know, pulling them out of the drawers or taking them off a wall, you just basically put a policy in to say, I identify that as a Wi-Fi access point that hasn't been approved by IT and just disconnect it. So you centralize the management, you control your environment. so those kinds of solutions take a lot of educating and ~ you can justify the cost quite easily just based on the security controls that you can implement within things like an X. So ~ so yeah, there's a lot of education, there's a lot of ~ justification, ~ but it's a ~ it's a journey. It's not a sprint. So you've got to take things slowly.

So for that journey as you start to mature, ~ what tells you that it's time to move from that kind of building those fundamentals to scaling and optimizing your security program?

That comes from your risk assessment. So your risk assessment is going to tell you the level of maturity of where you are. It's going to identify the gaps. And from that you you can build a multi-year roadmap that will basically guide you ~ in how to get your cyber program to the level of maturity that is going to be acceptable to the board, to the executive committee. But really, you know, you're when you create the strategy and you present that to the board, you're basically presenting the mat the the the journey of maturity of that cyber program over three to five years. Right. And then you're also going to provide estimated costs because that's really what they're they're looking for. So ~ sometimes that can be surprising to them, the level or let's say the low level of maturity in some instances, based on that risk assessment. Sometimes you'll get feedback if you're doing the risk assessment and you're not hiring a company to do it, they'll question it because they'll say it's more subjective. However, you know you kind of remind them you're hiring somebody that's got decades of experience and certifications to s to provide, you know, the level of expertise to present this risk assessment. And sometimes you still have to get a third party a Deloitte or an Ernst Young to come in and do it. But they're just going to use auditors that that take the same controls and just match it to a framework that they use. I know because I did audits. I did sixty audits for community banks as well as the security assessments and the pen test for them. So ~ and that's the most heavily regulated industry. So I understand executives when they come from when they have questions, but it's that's where you start. The risk assessment, you get the roadmap, and then you execute. And the key to all of that is the execution, is getting it done, getting the solutions deployed, getting the team employed, and getting the processes documented. And that gives you a well-rounded cyber program. It won't be a hundred percent because it changes, environments change. So maybe you get to 80% of CMMC or some kind of ~ maybe C. CIS NIS CSF, you get to maybe a level four or you get to like eighty percent of NIST CSF. ~ that'll get you to a pretty good matured cyber program.

All right, excellent. So as we wrap up, looking back at the programs that you've built and scaled, what do you wish you had known the f for the first time you were responsible for building a security function?

Maybe the I may of maybe have gotten a bigger budget to start with, perhaps, I don't know.

Ha ha ha.

I think when I go into a program I'd be mindful of the budget and I don't want to kinda go in with a big number, buy a bunch of tools and then realize I don't have the team to execute. So now I'm sitting on solutions. There has been times when that's out of my hands. I was a contractor when I've had to put in three security solutions and the goal I was given the mandate to say, Okay, you need to procure these solutions and follow this heavily regulated process so I went through that so I have the solutions but then we started running into technical problems and the actual network could not handle the security solution so the security solution had to wait until the network was upgraded. Well you know if you're in a a very large organization that could take years and it actually did which means that solution was already procured and sat on the shelf for years losing value, not doing what it's supposed to do. ~ And so if I in hindsight looked back, I probably would have said, I'm just gonna do one solution each year so you're not wasting money just by buying them all at the same time. But that's what I was told to do, and that's what I did, and unfortunately, technical issues prevented us from executing. So that that's probably what I would kind of look at first.

All right, well sounds good. Thank you very much, Nigel, for joining us today. ~ if you enjoyed this conversation, be sure to like, subscribe, and leave a comment with thoughts or suggestions for future guests and topics.

Thanks, Sullivan.