02/15/2021 – Developing & Validating security policies

All right, we are live. Welcome, everybody. Cyber Call, week 37. Joined as always with, uh, my Phantom co-host, Wes Spencer, who it says he's accepting and connecting, so hopefully he will be here shortly. Gary Pika, president. Wow, that was a rough one there. Cigar last night. Ryan. Weeks. And then, uh, let's see, Wes is texting me, new machine, working on connecting. Okay. Just so everyone knows where Wes is. He, and then Brian Blakely, uh, the, uh, founder of cosent, uh, cybersecurity.

Brian, welcome Brian. How are you? I'm doing great. Hope everybody's doing wonderful today too on this Monday. Yeah. Yeah. Rest is so secure. You can't connect Exactly That. How secure He's I'm, I'm, I'm secure. I'm, I'm dialed in through a payphone. Speaking of which, Gary, why don't you just, you know, you're telling us something off air that I think everybody should know about. I, I didn't know this. Or can you share a little about what people might want to hit YouTube up for? Yeah. Yeah.

So if you didn't watch 60 Minutes, uh, last night, go out and search the piece they did on 60 Minutes about the SolarWinds breach. So, um, it was good because it was done like in a mainstream way, and they explained it in that way, but it gives everybody an idea of what now the messaging is, you know, outside of our industry and to the public, uh, on it. So, uh, I, I won't spend any time on it, but I would recommend that everybody, uh, goes and checks it out. Yeah. Interesting.

Um, thanks for sharing that, Gary. Um, few announcements real quick. Um, as always, for the last few weeks, we've been talking about, uh, in the call to action, the little green box underneath, uh, the Cyber Resilience workshop that we're doing on the 23rd and 24th of this month. Yeah. It's shaping up to be awesome. Yeah. Abso yeah, we've got hundreds registered.

Um, and, uh, you know, we just found out that, um, in the technical sessions, if you have a team that's look looking to learn how to do, you know, understand vulnerability management, understand vulnerability, exploitation, and then, you know, things that have to do with the top 10, it's called the OAS Top 10, which I know you gentlemen know about.

Um, there's gonna be, um, the ability to win, um, two one hour sessions with Jason Slagel, um, so as an MSP sitting with him, uh, being mentored by him. So those are gonna be sponsored by Cyber Phish. And then, um, I think that is it. Do we have Wes still accepting and connecting? So we will kind of kick things off here. Alright. So the way this kind of came about was actually during last week's cyber call, um, we were talking, you know, we've been doing frameworks.

Then we had ci uh, CIS on Phyllis Lee and security Controls. And then we started talking about policy and we threw out a question, you know, would, uh, a cyber call dedicated to policy security policy be of interest? And, you know, uh, I, I know I was expecting a very low response rate. Um, do you know what it was, Gary? I think it was in the nineties. Yeah. 97% of people said, give us a cyber call dedicated, um, to, uh, security policy. And Ryan, you were kind of shocked by that, weren't you?

Yeah. We can't hear you, Brian. Oh, yeah, no, sorry. I said absolutely. Yeah. It's not usually the most fun area of cybersecurity, but certainly one of the more important ones. So, Yeah, I was Just shocked. Usually people wanna talk about technology or hackers, or usually never policy. Yeah, yeah, yeah. Absolutely. I Think it's positive. Maybe, maybe all this is, you know, the, the constant conversation's moving in the right direction. Yeah.

And I, um, put up a first poll for you guys to take a look at. And so let's kick things right into gear here. Um, starting off. Brian Blakely welcome. Um, and, uh, really appreciate you showing up.

You're the first person I thought about for this, uh, session because, you know, you've owned, uh, just a few MSPs and this, it was funny, Wes and I did a promo with you and, uh, I think it's six, and we were trying to get you to do a seven, so you could be like Tom Brady, uh, and then, um, but not Happening. Um, but then, you know, you founded Cosan. Um, and May, can you tell us a little bit about yourself, your background? Sure.

And then I'll shortly turn it over to, to Gary to kick things off here. Sure thing. First of all, thanks Andrew. And Wow, look at the, look at the people here, right on the cyber call. You and Wes is somewhere out there in the cyber world trying to get in. But, but Gary and Ryan, and, oh, there's Wes, uh, Audi, welcome to the party. Yeah. I joined the, uh, world of Windows this week, and, uh, I forgot, uh, when in doubt reboot, uh, I'm not used to that in the world of Mac, so here I am. Wow.

Right on. Well, good timing. I was just thinking, Andrew, uh, and, uh, just saying, wow, what an esteemed group of people, and I'm, I'm really not worthy and, and humbled to, to be here and play a smart small part. Um, InfoSec policies Yes. And policies on a Monday. And, uh, how exciting, what, what could be better, right. Better and passion. Uh, probably not a big enough word for me when it comes to InfoSec program development.

I'm an InfoSec strategy and leadership nerd, really with a background in IT engineering architecture, particularly like you said, Andrew, in the MSP space over the years. But I've written and executed, uh, many InfoSec programs, uh, over the last several years. And really the strength, uh, that I helped bring, I, me and my team, is getting that first time InfoSec program stood up and moving forward in a, a positive direction.

So I'm really looking forward to learning something today from all of you, and at the same time, sharing some of the wisdom, some of the bumps, bruises, scrapes, breaks in some cases, uh, on the topic of InfoSec policy. So, again, thanks for, for having me part of the discussion today. Yeah, absolutely.

So my final thought before kicking it over here to Gary is, you know, I get to talk to you regularly, Brian, and one of the things that kind of had me scratching my head is, you, right now, you foc you do work with MSPs, you do focus mainly in the mid market. And, um, I was like, oh, surely the security programs you're working on are around regulation and, you know, compliance based organizations, and you're like, you, you said to me something very contrary.

Like, yes, we have those, but it's not really what's the main thing that's driving it right, right now, which, and the reason I wanted to touch on this briefly is because I think it's bullish for the MSP business, 'cause not all customers of the MSPs are regulated. So can you kind of tell us what's going on? Why all of a sudden are non-regulated companies se seeking out you and what you did? Yeah, So, so it's not entirely direct compliance.

It's indirect or cascading compliance demands down to our customers, like you said, that have largely been an unregulated business, right? They don't deal with cardholder data. They may or may not have protected health information. They all have sensitive information, but, but these folks like to sell stuff, right? You know, our customers like to sell stuff to their customers. And when they can't, that creates friction for them if they can't sell.

And what they're, what they're realizing now is, is they have to have a program in place. They have to be able to instill trust and confidence in their customers who are asking, right? They're sending the, the 300 line questionnaires, the SIG questionnaires, and they're throwing 'em under Archer and all Corel and all these, all these platforms to answer a bunch of questions. And, and sometimes they're asking them in a way that makes them feel uncomfortable.

And I think that's what you're starting to see is friction created at the RFP process. They can't continue to sell to the customers they, they have been selling into until they get these things in place. So sometimes they sign stuff and they have contingencies to, to become compliant or have some sort of risk management program and policies and procedures in place to demonstrate and evidence that they're doing these things.

That's what's creating, when I first started coasting, I thought a couple years ago, I thought, man, everybody wants to be more secure, right? Even talk to people that had just been ransomware and, and business email compromised, that still wasn't enough to get them moving forward on some of the things we're gonna talk about today. And what it, what is forcing them now is to, to have these things in place.

And like I said, we'll talk about a lot of this stuff today, but I think that's driving where you're finally seeing people move forward on a lot of these formal information security programs and policies and procedures, getting them in place. And MSPs, you're in the cross airs, right? Compliance isn't coming, it's here. And so what you're seeing now is this stuff rolls downhill. And so the big reason we want to talk today is what are some of the things you need to start doing today?

And starting to think about how do you need to think about policies? I'm really hoping to share some different perspective on policies than you think. It's not the words on a page, right? There's a lot to talk about around policies and the why. Uh, and then also how, how to get started and what we wanna do. So genuinely passionate and excited. And if I start talking fast and really cool and exciting things around policies, uh, bear with me.

'cause, uh, I'm gonna connect it to some nuggets along the way that I think are actionable, uh, and, and usable today, right after this meeting. Great. So with that, Gary, you know, we're talking, it sounds like we're talking the ability to win business and, and stay in the game. So perfect segue over to your House Yeah. Or, or lose business, right? Um, last week we said that, um, every MSP is, or will be asked questions that they're gonna need the answer to.

And, uh, some of those relate back to technology, but many of them are gonna relate back to policy, uh, standards, framework, those kind of things. So, Brian, uh, real quick, uh, on the promo, you said you've written over a thousand policies. Is that true? Really true? And how is that possible? Wow, great question. What are you like 85 years old? No, no, no, no, no. Great question. You know, and in this world, you get exposure, right?

It's not where I'm warming a seat, uh, somewhere and just dealing with a monolithic sort of organization, it's, and, and, and I will back up a second. It does sound like hyperbole, right?

But when you do the math and you look at, at the, at, at policy development and information security program development over a span of just the last few years, with an understanding that each, each entity we work with, each has a policy library that could span 25 to 75 policies somewhere in there with an average of three control objectives per policy on, on average. So those numbers start to, to add up, add up quickly.

So it's definitely in the, the thousands of, of different, different policies. We'll talk about how they're unique and how some of 'em are the same or similar. Yeah. So I think where MSP struggle is like where to start. So are there areas that are most impactful? Like if you say, Hey, you know, Phyllis says, uh, hey, if you do these first, you'll hit, you know, in, in, uh, in CIS it'll cover, you know, 80% of, of, uh, of tax service. Is it that way with policy?

Is there a place where people should start, where, where getting 20 or 30% of the way there, um, will get them, you know, return on their effort? Yeah, and great question. And in my opinion, my opinion, uh, the answer may not be what, what you think, Gary, from my perspective, you start with risk tolerance. Okay? Starting with risk tolerance and a, and, and why, why would I want start with risk tolerance?

If you think about a policy, a policy defines the behavior that you want, a policy is simply the rules of the road, right? Nothing more, nothing less. And by the way, compliance is just another risk. People keep treating and talking about compliance and all this stuff as it's some separate beast, and it's just another risk. It's simply a business decision, how much to comply, how little to comply. And maybe some of us have seen where folks have made a decision not to comply at all, right?

It's a business decision. So risk tolerance period, for me, sets the tone, uh, for the policy development. So what you Kinda like paying taxes, you decide what your risk tolerance is, Right? Exactly. And, and once the risk that risk tolerance is understood, then define with leadership and, and management what the intent is across some of those. You mentioned some of the CIS, but what are the most critical InfoSec elements? So stakeholders of leadership needs someone to guide, thought and ask.

Ask the right questions, ask better questions. So what are the, the critical InfoSec elements? Well, for all you policy versions out there, uh, Gary, you mentioned a, a framework, but lean into a framework. And I would strongly encourage, especially for first time, first timers, uh, the nist, CSF is your friend, uh, for help, simply go around that circle. And I know you're all really smart, but I wanted to find what an InfoSec framework is really quickly.

It's basically a skeleton for your InfoSec program for that InfoSec organism. It it's the skeleton of that. And so my suggestion, Gary, keep your policy simple and broad so they stand the test of time. Stop the madness. If you hear, you'll hear it from me a couple times maybe, but stop the madness of being overly eloquent with your policies that span dozens of pages. The best policies are the ones that are understood, implemented, and evidenced. That's a mature policy.

Ask any auditor they wanna see lifecycle evidence too, Gary. So let's start with those most important things that, that you can easily evidence. And I, I'm gonna cover some of that in a little bit, but get some credit as an MSP, get some credit for some of the things you're already providing for your customers. Resell that value and a policy is a great way to do that. And when I say lifecycle evidence, let me pause there for a second.

Lifecycle evidence to an auditor is when you're, you've got, let's, let's pick on incident response. Everybody kinda understands that, right? So I have an incident response. Well, Don't assume every Happens. What am I gonna do To use? Yeah, go ahead. There's Something bad happens. What am I gonna do? So you have an incident response policy. So this is, this defines the lifecycle. I have an incident response policy. It is supported by procedures. Okay?

I have an information, I an incident response program. Okay? That's the strategy. I have incident response playbooks, which are supported by all that stuff that comes before it. I do tabletop exercises per policy and procedures. I have gaps. This is key. We're gonna talk about this some. It's real important to show gaps. Sometimes you, that sounds counterintuitive. Auditors love to see, Hey, when you did, did something and examined something, you noticed that it wasn't quite right.

How did you react to that? Well, you made some changes. You did an after action report. In this example with incident response. You turned around and made your policies, procedures, your plan, your playbooks, all this stuff better because of those. Okay? And that's that full life cycle.

And otters love as you're going through this to do that, not only otters, but pragmatic value of having that sort of connective tissue between all those things helps you get better at those things, helps you mature your program over a longer period of time. Yeah. And so to me, it's like almost anything. Um, you know, making sure that the policies you have have that lifecycle instead, you know, of 20 rather than having a hundred and none of them do, right? Or it's just words on a page Better.

Because listen, if you're, if you're an MSP who's at the beginning in a short timeframe, you're not going to get from one to 10. Do you know what I mean? So you have to make sure what you are doing right is effective. And I think that's what you're saying when you're gonna pick a policy, you know, start with the ones that you feel based on your risk tolerance, but make sure that you have the entire life cycle, right? Well put, well put.

And, and also to keep it simple, not to be wordy and something that people don't understand, put it in the terms of the business. Uh, so leadership can understand it, and the people that that have a role can actually affect that or impact that. And real quick, if you don't mind, maybe what would help demystify a couple things as we move forward is, let's really quick, let's, let's, let's build a policy together right now. It'll take, it'll take about 90 seconds. Okay? So let, let's do this.

Let's, let's pick asset management. That's something everybody can understand. I'm an MSP, I have assets under management. I, I, I do certain things. I have on my RMM tools, that fees in my PSA everybody can understand asset management. So let's look at that. Let's take an asset management policy real quick. What does leadership want? Always start with that. That creates business alignment to your policies. So you say, okay, I'm gonna say around asset management. A simple one sentence, okay?

Leadership wants to make sure technology assets are properly managed from procurement to disposal life cycle again, right? From procurement, from cradle to grave, from when we get it, until we throw it out. So that's our leadership intent. That's what management wants. And then you say from a policy perspective, one sentence. Okay, one sentence. You can get all fancy in your control objective standards and guidelines.

But your policy statement, something like, the company shall protect its assets by implementing and maintaining asset management best practices across the enterprise. We just did asset management. Boom. I'll say boom, boom. We just did an asset management policy with leadership intent. And now all the control objectives that we put in control objectives real quick are very important because control objectives say, what do we want a control to do?

What does success look like when this control works? This is what happens. Control objective, very important standards. What are the mandatory things, the non-negotiable things that must be done to satisfy this policy. And always, I I I look at guidelines all the time. 'cause as we're building our procedures and other things, our, our people process and technologies, the solutions as an MSP or MSSP that we sell, uh, uh, those are the, those are the, the procedures.

So you might have different control objectives, like around this policy. Like, hey, asset inventories are important. Hey, network diagrams and data flow diagrams that show where our assets are. That's probably important. Oh, and guess what? If we're gonna remove that asset for maintenance, or we're going to dispose of it 'cause it's end of life, what's our policy for that? How do we do it?

So there, we just did together an asset management policy that is easy to create procedures around probably stuff as an MSP you're already doing today. One last thing relative to that, Gary mentioned 80 20 impact, uh, as an MSP. And in my opinion, uh, from an, uh, an IFEC policy development perspective, you make the most impact by developing the policies that focus on areas of the CSF, where again, you're already helping your clients today.

And I'll say if we're leaning into NCSF, that's that right side of that circle. If you see me doing this when I say CSF, I'm a visual person and I go around in a circle. So the N-C-S-F-A lot of prevention happens on the right side of that circle. Okay? You're already doing as an M ms. DA lot of stuff.

So when you're focusing on the things to prioritize Gary, sometimes building early wins, momentum and the results that results in the value of the, of the stuff you're already providing as, as an msp. So I would stay on the right side of that circle, address any of those policy gaps. Okay. Again, based on risk tolerance. And then you could start moving to the left side of the circle, which is more resiliency based. So I had one more question for you, but Andrew, maybe for a future call.

Um, we're doing a special project this quarter for our peer groups where basically it's a cybersecurity, um, like check in their plan for this year. And, um, you know, we're having 'em look across, uh, nist, CSF and separating, you know, kind of what they're doing in each area for tools separate from policy, identifying gaps so they can actually see it, you know, across CSF. So, but, um, so maybe we can have a, that'd be a good conversation. We can have maybe one of these upcoming weeks.

Um, so the last question that I had for you, uh, Brian, was, um, and again, you've been involved in MSPs, you know, let's put aside creating, 'cause maybe they put a team together and they create policies. Great. And hopefully now they're not gonna treat it like their business plan, which is in the drawer until the end of the year. And then they take it out and say, oh, how do we do? Right?

Um, so with this, in terms of operationalizing these, uh, implementing these, all the things you have to do to actually get the results you're looking for from policies, it's gotta be part of your culture. But where does that accountability, like fall in an MSP? 'cause that's not really an area that they had accountability for. Like, pretty much everybody has a job right? In the MSP that they're doing already. It's a full-time job. Yeah.

And, and so a lot of what you're asking, Gary, if I can echo back and understand, uh, kind of if you're looking at a RACI chart, uh, you know, when it comes to, to policies, how are who creates 'em? Or let's assume creation, but who maintains them? Implements them, who's responsible For that? Yeah. How are they, right? Knowing what, knowing what you know about MSPs, like, and their structure, the ones that are getting good at this, that you work with, where are they putting that?

What, where does it fall? Yeah, great question. And, and so, uh, from my experience and in the, in the Wild Gary responsibility for policy development, uh, really varies a lot from organization to organization. Nobody likes our, our answer when we say it depends. Uh, but that's the reality oftentimes.

And so that's why I, I think when you're building policies, there's a couple of things to think about before that, that helps provide clarity in those situations so you don't have fly balls to the outfield and, and confusion and people staring at each other as the ball hits the ground. So I, I, I love to start with a charter. Okay? What is a charter? Charter is a birth certificate, basically for your InfoSec program and identifies the parents and it says, who's gonna be responsible for it?

So starting with the charter and then that, that gives birth to the program. And then you can define your roles and responsibilities. InfoSec roles and responsibilities are key, I think, to the success in eliminating or mitigating confusion upfront as you roll some of these things out. So think about how that having as an MSP think about having that conversation at onboarding or re onboarding. We all know what that is.

Uh, re onboarding or onboarding, uh, a, a client and, and ask these questions upfront. 'cause your competition probably isn't saying, oh, could do you mind sharing your InfoSec, charter and InfoSec roles and responsibilities? And most cases, they're not gonna have a clue. And, and I think this is a golden opportunity to have that discussion and help, help educate the client.

Um, uh, the person, uh, talking about, about kind of who, who's responsible and the charter, it says the accountable party. The accountable party, uh, is, is oftentimes the, um, in larger organizations, the accountable party could be the board of directors, uh, but, but, or, or senior leadership. And smaller companies, it could be the owner, but they assign responsibility of the information security program to someone.

Larger companies that's a CISO or director of InfoSec or some sort of title, VP of something, uh, and smaller orgs, they tend to assign that responsibility, uh, to someone in it. And as the MSP, that's usually your point of contact is your, your POC. And so they're knocking on your door. So what do you say, right? They, they say, Hey, we need these things. What do you say? My question to you is, is do you, do you make money by writing policies as an as an MSP?

Do you make money by writing policies for your customers? Do you feel like it's something you're qualified to do? Is it in the best interest of your client for you to write policy? Is this something you want to do for your clients? If so, great. You know, let me know how I can help support you.

If you don't make money by writing policy, uh, and you, and you don't feel qualified to do it and don't wanna do it, seek help from a trusted partner, in my opinion, that, that, that the MSP and IT in general should be Gary consulted and informed looking at this from a RACI perspective, okay.

When it comes to security policies, they're for sure, as much as clients would like to hold the MSP accountable or responsible, when you look at an InfoSec, um, uh, policy, uh, uh, they're not the responsible or accountable, they should be consulted and informed. Uh, also from an audit perspective, when it drafts policy, it comes in sideways. It lacks, lacks governance oftentimes. And so it and MSP's role, I see it anyway.

And, and this is again, my InfoSec nerd leadership strategy kind of thing, is I, I see, I, I I, I, the MSP's role is, is specific in executing the procedures that support the policies. The MSP reviews the policies and weighs in on the best way to satisfy the policy process, technologies, solutions, automation, et cetera. But the accountable and responsible parties decide yes or no on your solution, and they just need educated on the risks of not moving forward, right?

We, we have a bunch of accordion of services that MSP to sell, right? A lot of cool stuff that we can help them with. And we just wanna know, hey, this, we're helping you satisfy your policy, which you said is important, okay? And if they're not willing to do that or make those investments, then, uh, then MSP documents, uh, that the policy is, is not adequately supported, right? Just, I, I know that this happens a lot with, with some of the disaster recovery, right?

Ryan on around data and, and some of that, if a client doesn't wanna do these certain things, then we, as the MSP need to kind of divorce ourselves from some of that are separate ourselves from that. They're assuming this risk, we tried to lead them down this path, they're not doing it. Same kind of approach with policies.

Uh, and that's, that's as an MSP, as I see you kinda separating yourself, you're consulted, informed, and you're helping you sit on the same side of the table, table as your client and customer, helping them achieve the things that they said was important to the goals, mission, objectives of the business, which is the intent within the policy. Very good.

So, Gary, 'cause you, I gotta believe as we hand it over to Wes, but you, you are always asking because you're thinking of an alignment to roles, responsibility, revenue. Yeah. Yeah. I have a whole, this opens up a whole can of worms that I don't want to get into now that maybe a whole future call, uh, that builds on what we've talked about. 'cause I, I wanna let, um, I wanna let a couple guys ask questions who have, um, are responsible or have also built policy.

So I'm gonna, I'm gonna step back. No, it was great. We'll do, Gary is bring one of your members on and we can lead that what you were saying about earlier, what they de what they discovered, and then kind of walk through it. So Yeah, because there's a lot of problems based on everything we just heard about actually making that happen in the average MSP. But let, let's, let's stay with this 'cause uh, we have Brian, and let's let him get into the details and this thing with people.

Yeah, yeah, absolutely. Go ahead, Wes. Hey, uh, thanks for having me back and Windows. Thank you for finally working for me today. Uh, yes, I saw the, uh, the messages in chat and yes, I am soliciting help for a managed IT provider. If you guys know of any that are any good, uh, send them my way. 'cause apparently, I don't know how to restart. Oh, Shoot. I'm currently between MSPs. Oh, man. Carrie, I was hoping you wouldn't say that. Uh, you've disappointed me.

Uh, hey, before we get started, the first poll question, kind of the data surprised me. I wanna make sure we got a good data hygiene. If you can actually go back and retract your vote, uh, insert political jokes if you may. When we say we write our own security policies, what we meant by that is do you write it from scratch? Do you literally open up like a blank word doc and start writing? Um, go back and reassess your yes or no there.

Um, versus I think maybe some people might have interpreted that as we write our own. Yeah, here goes the data. Uh, I thought maybe some people, like, do you actually put input in it versus just downloading something and, and moving forward without looking at, I think people, there's probably some confusion there. And now the data is changing. So there we go. I've been wondering this the whole time. Okay. So, uh, that helps. All right, so Brian, here's my question. I got an opener for you.

Uh, you know, you've owned six MSPs. Um, you know, I think we were talking in the planning session, you ought to go to seven, right? Just, you know, the, the greatest of all time, they tend to win seven, is that right? Gary Pico? Is that the number? That's the number, apparently. Yeah, I thought so.

You know, so, uh, you know, regardless of whether you go to seven or not, if you're sitting down right now and you were starting knowing what you knew, and you're starting an MSP from scratch, how Only one in Tampa, I'll take it. I'll take what we can get. Uh, and you were starting from scratch, Brian, what advice would you give to others when you're thinking about policy development?

Yeah, I think one of the great greatest sales tools I had in my tool be tool belt as an MSP, is there's tremendous power in eating your own cookie, so to speak, eating your own dog food, right? And with some of the stuff we just mentioned about, uh, MSPs and the cross hairs of data flow diagrams and critical vendors, mission critical vendors and such. So I, I'd start, you know, clean your own house, get some help, build your own formal informa InfoSec program.

Um, operationalize it by connecting the internal procedures to your policies and programs. Share that experience with your customers and prospects. There's tremendous power when a, a customer better understands the way you do it as an MSP and how you do things. It has just a lot of weight, okay? So as an MSP, understand that, again, compliance isn't coming. It's here. You're tasty target a one to many payoff for bad actors.

So if IMSP today, you know, cascading compliance demands, uh, on your customers alone should be enough to get yourself in gear. So all compliance requirements, again, uh, have this need for lifecycle based policies. We've, we've beat that, that horse. But again, it's more than words on a page. Uh, we talked about how it goes, like even incident response all the way to being able to evidence an artifact that the policy is in place, it's ratified. And, and here's how we do this.

Um, so looking back on my MSP's businesses, um, I sincerely, I strongly believe that, that we could have increased revenue by maybe double if we didn't engage more, uh, had a partner relationship to build some of this information security program where we could connect every single one of our solutions, uh, to a customer problem that we're solving by leveraging policy. Okay?

One thing real quick, cyber, if, if you have this in your marketing materials, I would strongly encourage you to rethink it. But, but this fear, uncertainty and doubt, and this hoodie wearing hackers with ones and zeros floating behind your, your, your, your, your background or guy Fox masks on wearing gloves and stuff is polarizing nonsense, uh, to a lot of clients and prospects, right? You spend a half hour talking about what it isn't.

And, and then, so if you can lead with that, having your own InfoSec program and talking through examples and, and how you're doing it, and the value and the features and, and the, the problems you're solving and becoming more security and readiness assessments are basically done because you have a lot of these things in place. Not fear, uncertainty and doubt, but meaningful policy connected to behavior and culture and business goals and objectives.

So as an MSPI, I wish I could have asked better questions, right? I always look back and I think, man, if I was an MSSP today, yeah, I'm a security nerd. And, and I always try to check that, am my hammer looking for a nail? Or what am I doing here?

And, and, but I, at the same time, you ask if I could go back, or if I started one, I would, I was, I would lead with certain questions that would differentiate me from this, this, uh, very, uh, saturated pack of, of MSPs out there, all kind of doing the same thing with the same tools. And how do I differentiate myself? I think policies is one way to do it. So you say, Hey, can we, can we review your InfoSec security policies? You already know the answers to some of these questions, right?

But you're trying to expose the pain. Let's get the nerve out there. So you say, can we review your InfoSec security policies? Hey, how about your cyber risk insurance policy? Can we review that? Hey, when you, when you initiated this policy, did they ask you some questions? You know, how do, how do you feel about your answers on some of those? And then what do you, I would ask my customers, what do your customers want? You know, what's creating friction for you?

Are that you getting questionnaires? How do you feel about some of the responses? Um, you know, what are you doing to prepare for fill in the blank, uh, compliance, you know, soup of the day kind of compliance coming out next week or next month or next year. Are you prepared? Um, so, and even saying, Hey, here's what your competitors are doing and here's what you're gonna need to do to even stay competitive and continue to sell or, or increase your market share in, in your industry.

So say Real quick. That's where I start. Sure. Yeah. No, 'cause and Wes, I wanna hand right back to you, but you're literally just outlining what we, you know, what's known as the challenger sale. You know, it's a commercial insight. Um, and your friend just in your neighborhood, Carl Bickmore from Snap Tech, it, oh, he's really good at that, right? And, you know, hey, well, we find I'm making it up on the fly, right?

Hey, Wes, we find 98% of small businesses that we talk to don't have a security policy, you know, well thought out security policies in place. Here's that, what that does as a result, blah, blah, blah. So, Wes thoughts and, and let you continue. Well, I mean, that, that's true.

And um, Brian, one thing I want to come back to you rabbit trailed on this for a minute, and I was hoping you would dive in more, and now I'm just gonna ask you to, so you made a comment that probably surprised people on this chat. You said that there is a tie in, there's a direct correlator to strong policy and governance and revenue. Can you, can you talk about that a little bit more?

Because I think most of us, if we're honest, we just feel like policy is this either CYA thing we do, or it's this red tape compliance thing that we just have to do and we get no benefit out of it? Can you, can you dive in a little bit more on that? Yeah. So, so policy is not where it ends, or it, it is where it begins, right? We've talked about it being the foundation.

And so what, when, when you look at revenue, um, companies, organizations now realize they have to have some of this stuff in place. So it starts with, I have to check the box. But when you can have, and what I mean by good quality, uh, policy development, as you've involved leadership, they've blurted out words, right? They've said, these are important to my business. This is our tolerance for risk. These are things we want to do. If I'm an MSP, you have solid gold there, right?

What, 'cause what you could do is you're selling certain solutions that help satisfy that policy. So the conversation comes back. I'd love using customer's words against them sometimes, is to say, okay, you don't wanna, you don't wanna, you don't wanna plug this solution in that we have. Okay, soc as a service somewhere. You don't wanna, you don't wanna monitor. Okay, that's fine. Then we need to go back to the policy. 'cause obviously that's not important and something's changed.

So let's, let's sit down and look at your policy and review your policy and make sure it better matches your risk tolerance. 'cause when we sat down and developed the policy, you said this was important. You said that this could end your business. You said that this, your reputation is at stake, and now you don't wanna spend $2 per user per month to help with that. So let's, let's either go back and revisit the policy, because obviously we, we got it wrong.

I wish It was $2 per month, Like per user, per month. If it Was $2, they probably could sell it, You know? But, but no, I, I, but, but Gary, I think sometimes they're, they're getting subscribed to death sometimes. So it is sometimes $2 per user per month. I'm Thinking about differently than you, you're really talking about how to have that conversation. I don't wanna step on Wes, I don't wanna step on you, but I can't help it now. Go For it.

I figured you might, You, you know, you don't, I wanna make a really important point here, um, about how to have that conversation with a customer, and that's great. We all gotta get better at it. But what I want to ask everybody listening is, if Brian or someone with his knowledge was to walk into one of your customers today, how long and how many questions would he have to ask to uncover pain to make one of your customers say, what do you mean? And that's where we're trying to tell people.

This is not just challenger sale offensive, I'm saying defensive. Because if you don't ask these questions, somebody else is gonna ask some of your, of your customer. And I would not want to have Brian talking to one of, uh, my customers. Right? Well, I, I don't know why he wouldn't. And I'll tell you why. Uh, because coming into it this way, uh, talking about policy and, and, and the leadership, those are conversations, uh, most, most organizations haven't had, especially SMB.

And what they need to realize is that we're coming in not to shine a light on the problem and then tell 'em what a, what a loser their MSP is and, and stuff to make us look good. We don't, we don't, for example, I'll come in there with an agenda, nor do I ever want to support or, or, or provide any of these MSP or MSSP services. We lose credibility and integrity on our, our deliverables when we do that. Right? Today, I'm saying if you were an MSP with your knowledge Oh, yeah, Yeah.

MSPs a hundred percent. Yeah. 'cause that's their goal, right? Is Yeah. Is to make the incumbent, uh, shine a light on all the things that they should have asked and not doing a hundred percent accurate. Sorry, Wes. No, you, you're good. Those, those are good things.

Uh, and, and I love, that's why I wanted to ask this correlation here, because I think there's great value in us, um, thinking about those things and thinking about how we build, uh, maturity in our, in our, what I call our GRC, right? Our governance, risk and compliance. It's, it's not just, and I love that we're having this conversation, by the way, right? I remember in 2018, the only conversations that I ended up in were tools. What goes into the stack?

And I think we've finally gotten to this point now, and Brian, you kind of alluded to this a little bit as well, is tools are great and they're important, but they have a place to, to in the role, and they're subservient to overarching GRC and how that adds into what we do. And, and that's why the whole, you know, security by scaring and hackers and ski masks does not work with our end users. It's well said. Um, in, in, in light of that, I wanna shift gears just a little bit.

So I learned a lot of this as well when, when I was at a bank, and, uh, you guys know, those of you that are on the cyber call know I talk about this a lot. Um, but you know, when, I remember when I first started at the bank, I don't know how I've said this very many times, if at all, the very first week I started was when the federal examiners were in for their 12 month cycle.

And like, seriously, they're like, oh, by the way, when you start, uh, you're gonna see some guys in suits coming in and they're gonna be grilling you the questions. And sure enough, that happened. And so very, you know, day one, here I am sitting down and, and I'm still like, don't even know names yet other than the CFO and the CEO. And in comes the examiner, he is like, Hey, I'm understand that you're kind of new here. I'm like, yep, you understand correctly.

And so he starts grilling me with questions and I'm like, you know, I've answer 'em as best as I could. But he finally just said, he goes, okay, I know you're new. He goes, how are you gonna get started here? And I said, well, I'm starting with policies. Uh, I said, I, I really don't understand exactly what we're doing and, and how this looks. Um, and, and he goes, that's a good answer. He goes, that's a very good answer. And so, um, that's how we began this story.

And you know, what I found and discovered is where while we had some strength in policies in the past, we also had some significant weaknesses. Brian and I ended up using a lot of that with open conversations with my examiners to go offensive with it. What I mean by that is when I saw gaps in material weaknesses, not just in policy, I also knew that those are things that were gonna have weaknesses operationally as well.

And so I would use those to say, we're gonna change some of our policy so that we can set and dictate some new things that we need to be doing that requires either more budget, more process, more personnel changes, whatever. And my point is, I learned a great lesson that policy is not just this thing I have to do because my regulators tell me to do it.

I can actually use it to accomplish my objectives and get what I need done to say we're gonna, we're gonna enhance our policy and mature it, but that also means residually, we're gonna have to do some additional things. Can you just talk to me more about that offensive look of policy, how we can use policy to get our agenda across or get our goals accomplished with our customers? You've talked about a little bit, but can you dive into that a little bit more? Yeah.

One thing real quick is, is, and I don't think this is what you're saying, Wes, but, uh, one, when I, I I look at, at policies, it is really a reflection of, of risk. And I think that, um, uh, as as such, I don't like to be aspirational or overly aspirational about policies. You like to lead a little bit, especially around thought and connect it back to leadership intent.

But what the important thing around policies is being able to look at a return on security investment and tools and other things. And now I think what you're saying, Wes offensively is saying, Hey, I'm able to justify a spend in a specific area because I connect it back to the policy, which connects back to the business's goals, mission objectives. And then I have alignment. I'm not accumulating technical debt.

I'm not going out and, and spending money on blinking lights and white noise because it's cool. I'm not spending money on things that are gonna spew out logs that nobody has time to look at. I'm not increasing my attack surface with these tools. I am linking it back to what we said was important. And I have helped satisfying a business problem that we have. And that is a gap in policy.

Um, and I think when you're using it offensively, uh, to get some of your agenda through and to help justify some of your security, security tools and expense to say, Hey, we're not accumulating technical debt. It solves this problem. I can connect the.to almost every single dollar I spend on people, process and technology in my InfoSec program back to back to a policy. And that's solid gold during the audit perspective too, right?

We talked about offensively now defensively, okay, I'm in there. I've got, I'm, I just did this with a, a client a couple weeks ago, right? The $45 billion years, uh, and, and transactions as a SaaS company, two day, two day audit with their bank, right? I'm leading it.

First thing I do is I spend time walking them through the InfoSec program, the policies, the procedures I have it, their it in and out to, uh, for, to, to do what I call security theater sometimes, but where they're doing demos and observations of things like log reviews and firewall rules. But as they're doing that, I'm connecting every single thing they're doing. I'm saying, oh, that's this procedure that connects to this policy and here's why we're doing it. And you know what?

That, that audit that's usually 16 hours only lasted 10 hours. And now my client, because we're doing that, we have that, we have, we have the right policies that are evidenced so I can defend them, uh, uh, went from instead of every 12 months to now 24 months 'cause of our low risk. And that happened to be a bank, you know, who looked at it. And, and these are people keep in mind that are paid, they justify their existence as an auditor to buying stuff, right?

But when they come back, no remediations, no contingencies, all that kinda stuff, that's a win. And that's a huge win to reduce friction and audit costs and some of those. So that's an real quick example of policies offensively to help get some of the agenda done, connect those expenses back. And defensively when I'm sitting in an audit with auditors and going through and saying, look at, look at what we're doing and how it's connected. All connected. Hey, Wes. Mm-Hmm.

Just wanna wonder, um, to pass the baton to Ryan Weeks, 'cause we're, uh, got about 11 minutes to the top of the hour here. Yep. That was, uh, my plan. Exactly. So, Ryan, take it away. Sorry about that. Yeah. So I'm curious, for MSPs that might not have policies today or have policies for their customers, do you view the initial policy setting as setting a path to what good looks like? Or is it documenting where I am now, right?

Because where I am now can be incredibly important if you're undergoing an audit, right? But it's also kind of important to have an idea of where you wanna go. So how do you balance those two when you're setting policy? Yeah, great question Ryan, and thanks for that. And, and I personally, like I said a moment ago, I don't like to develop overly aspirational policies. They become very difficult, if not if possible, to operationalize in evidence.

I, I feel like the road to hell is, is like we've all heard paved with good intentions. So, uh, it's really, let's work together and build real meaningful policies that reflect Ryan really reflect what is right, what is, uh, we can always identify areas of, um, uh, on a maturity roadmap where policy needs to be more stringent and improved over a longer period of time.

But the best way to be a force, I think, for, for positive change is to start with a policy that can be evidenced and supported and then roadmap those changes needed to better match that risk tolerance of the organization. That's gonna expose some gaps. But roadmap those, especially, especially when you're building a first time InfoSec program, uh, meet your client where they're at today.

Start with, like I said, the charter InfoSec roles, responsibilities, meet with the leadership team, determine risk tolerance, uh, as you develop the policies and understand, uh, what they're doing today in it and understand what IT projects have stalled or slated for later. And I can't believe MFA out there is still one I come to, you know, just 'cause of the end user friction. I, I can't believe it this day and age, but that, that's one, for example.

But, but many orgs are, are many, many organizations are, are missing strategy. And so it and compliance become the tail wagon, the, the dog and technical debt becomes a problem. And it should be all about, all about risk policies are are foundational. Okay. I'm gonna ask one more quick question. Um, it's really about the process of creating a policy.

I mean, it's usually not like go sit in a dark room with a blank sheet of paper, write a bunch of stuff on paper, and then put it up on a, you know, your intranet page and say, I created a policy here. I'm gonna go read it. This is what we're gonna do. Right? What's, what's the process that you use to create, iterate, socialize policy to, to drive kind of ownership and input and, and, and ultimately kind of arriving at the right outcome for the business?

Like how, how do you generally advise people walk through that process of creation? Yeah, it, it is interesting 'cause I always equate it when you go to your attorney and you say, Hey, I need this type of agreement. And they act like they're pulling up word from a blank sheet of paper. They've never written an NDA before. And, and, and so I, I I'm thinking, is that what you really do? Do we have like something that gets me about 60, 70% of the way there and we can tailor it from there?

So same thing applies here. Very seldom are you going, I, I can think of only on a few occasions I've had to develop more of a policy from scratch because of a specific need or compliance requirement. Uh, but with, uh, policy development, um, uh, don't do this, uh, let me start with this. Don't download policies. There's some good libraries out there like Al Ts Compliance Forge, uh, sands that have policy. Don't download those. Find and replace the name and stamp it and say, I have a policy.

'cause remember, policies have nothing to do with the words on the page. They have everything to do with the stuff after it that supports it. That's what makes the policy a policy. And let me word of caution. Auditors have all these templates. Auditors will know when you did that. Okay? They will know. And what they're going to ask is they're going to say, you know what? I'd like to see your policy history. I have the template and I see yours here. Only thing different here is the name.

Prove that you met with leadership. Prove that you had this ratified. Prove that this is socialized, prove that this is in place. How is this evidenced? And you know what? You look like a real schmo when you have a canned policy that's been fine and replaced. Auditors are onto this. So, so Ryan, real quick, uh, uh, when it comes to developing the policy, uh, you don't do this. This isn't when I do it. It's not Brian Blakely's information security program, right?

It's just not as policy is developed. It has so many areas where feedback is needed. So I ask questions, I prompt some thought and I shut up and take notes. Um, uh, I make sure to summarize policies with leadership and the policy statement first, get their buy-in. Uh, if I'm doing a SOC two type two readiness, I have formal acceptance of those. And you can show ratification. But I wanna get socialization. I wanna socialize that and get consensus.

And when I roll out policy, this is the last point here, key to policies is being transparent throughout the process. So why, why would I wanna be transparent? Well lean in here for a moment. Believe it or not, I'm not perfect. You know, nobody is, no matter how many policies they've developed, you make mistakes and you're gonna create friction. You're gonna create a problem for somebody. And you wanna make sure and have two way communication open as that policies rolled out.

Especially when procedures are input pla put in place. 'cause what do people do when they need, Hey, their job's on the line, they have deadlines. What do people, policies are all about people. What do people do when, when you've created too much friction for them? They find a way to do their job. They find a way around the policy, okay, they circumvent it to get what they need to get done. And can anybody guess, is that riskier or is it less risk when they go out and do that on?

No, they're creating more risk, which is the opposite of what you're trying to do with a policy. So let's have open communication, socialize it, get a buy-in. There's role-based, uh, people that have to, to, to, to maybe more impact or affect that, and then have transparency. So if the policy's not working, or you're creating a bazillion policy exceptions, you know, there's a problem. You need to revisit the, the policy and make the necessary adjustments.

So make it say, make it easier for your policy to be followed than it is to be broken. Think about that. Yeah. Wow. That was that man, that was awesome. You know, I, I wanna kind of wrap, start to wrap things up here. And you know, Ryan, um, I'm sorry. Uh, Brian, we did a, one of the polls was I put up, um, would we, we would like help and would pay to learn how to write security policy.

So I'm kind of putting this gauntlet up to Gary and you, how cool would it be to do a course where we're talking about how to do it, but then how to use it as a wedge. Gary, like, man, I just think that could be, uh, invaluable to everybody. So, uh, we can't hear you Gary, you're on mute. Yeah, so we're trying to do one thing, like we're doing cyber resilience this quarter. Yep.

Um, so maybe that will be a good thing, Andrew, that we can maybe, you know, work together on like to have it be for next quarter. Yeah. That, yeah. Would you come back and join us for that? Brian? Count me in. I love, I love this stuff. I, I can't get enough of it, so, uh, consider me at any and all opportunity for that. Alright, fantastic. So we had some questions. I don't know if we can get to 'em. We got about three minutes left here.

Ryan, thank you for answering the one on OI think the one was answered on O. Yep. Yes, Ryan. Um, yeah, the One I didn't answer was, uh, Daniel Moyer's question. Okay. Specifically for Brian. Okay. So Brian here, once you have a, once you have to, once you, you have the answers to the policy questions or insurance questions, how do you track or don't track to the progress, uh, to, to progress them to a better place?

Oh, so I, I love if you lean into the NIST CSF, uh, what some of the work that that we do is, is using that and plotting it out on a SPI spider diagram and is very easy to plot PO and separate out policy from practice maturity because a lot of good companies have great MSPs that are doing great practice without a lot of policy. So separate 'em out so you can get your rifle out and shoot just those spider diagrams.

Allow for leadership in your clients to great see, easily see progress as you plot along, over executing that, that roadmap. That's very cool. I think even the, uh, CIS CSAT West has kind of like that spider ish look, uh, on each control level level. I'm not sure if you've seen that, uh, Brian, but they, they do a really nice job at that. So with a few minutes left here, um, Gary closing comments, thoughts from you?

Yeah, a couple things I made notes of here were, um, you know, governance policy standards, all these things we're talking about every week. Um, we've set enough time that they're good business, they're revenue producers, but now we gotta go a step further and say, not maturing in these areas, not maturing your posture is now becoming bad business. Right. Second point I had was, um, four times today Brian said, policies have nothing to do with words on a page. Four times.

He said that if he said it four times, I think he means it. Okay. So that means that this is hard work, right? That's the signal to MSPs that this is hard work, not something we love. Um, so, uh, again, if we tie it back to how we open with 60 Minutes and SolarWinds being on it, um, the world has changed not just for us as providers, but the world has changed for our customers and we gotta get with it. Yeah. Well, well really well summed up. How about you Wes? You are on mute bud.

That Windows machine still on mute Ryan Weeks? He gave Up. Go back to a Mac. Yeah, He's probably running Vista. It's, It's OA operator error. Yeah. I mean, like my, my recommendation for most things in information security is like, if you're not doing it, just get started. Right? Like Brian said, go find something you like on Google, like the, the NIST framework. Don't find and replace your company name.

Read it, understand how it works for you, how it doesn't, and start to modify it and create something that works. And if you're a CIS shop and there's not a lot of CIS policy frameworks, well CIS maps to nist CSF, go download the policies from nist, modify them and then figure how they map back to CIS to help you achieve control objectives. Right. You have a lot of resource just, just get started. That's awesome.

And I just thought about it, Ryan, you'd be great to come back when we do this next quarter thing where we could do it around dr. You know, I mean Yeah. That, that would be a real, you know, it's something that's critical to everybody, but yeah. Something that all MSPs are doing, So yeah, I love the idea of a policy workshop where MSPs walk away with a functional policy. Yeah. Be phenomenal outcome. Yeah. Brian, thank you so much for coming on with us. That was fantastic.

And on behalf of all of us at the cyber call and all the audience out there, thank you for, um, spending your, your President's Day with us and we'll look forward to seeing everybody next week. Until then, take care everybody. Awesome.