Key components of an MSP cybersecurity governance program

This blog is part three of the multi-part series summarizing “The Ultimate Operations Guide for MSP Cybersecurity.” In this installment, we’ll lay out good cybersecurity governance practices and establish a common starting point for MSPs wanting to build out their cybersecurity offerings. If you’re interested in reading the previous installments of this multi-part series, you can access them below:

• Part one: Summary of the ultimate operations guide for MSP cybersecurity
• Part two: Core concepts for MSPs setting up a cybersecurity practice

Let’s get into the key components of cybersecurity governance for MSPs.

What is cybersecurity governance?

Governance is the set of formal policies, processes, standards, etc., that make up a cybersecurity program and allow an organization to achieve its objectives. It’s common to see standards and policies combined into single documents, but we recommend keeping the documents separate to achieve good end-state maturity. Governance is the stage where approvals and policies come into play, and if you’re starting at ground zero, it’s important to note that setting up and implementing good governance fully typically takes months. But what components constitute good governance for cybersecurity?

Policies

The core of a cybersecurity program consists of policies. Policies are high-level descriptions of expected behaviors and goals. Because of this, they don’t change often. For MSPs, items unique to the business model would also appear in these policies. For example, a cybersecurity policy for MSPs could be: “All assets with the client label must require multiple forms of authentication for access.”

The specifics will differ for every organization, both for architectural reasons and risk tolerances. The key point of policies is that they are high-level and don’t usually get into specific technologies—they represent management’s goals for the cybersecurity program. In smaller organizations, the cybersecurity team will write these and send them to management for approval.

Standards

Standards answer “what” questions to policy goals. Continuing with the example about client labels shown above, a standard might answer questions such as:

• What methods are acceptable for implementing multi-factor authentication (MFA)? Microsoft Authenticator, Google Authenticator, SMS?
• Are standalone accounts with MFA acceptable? Or must the application be integrated with the organization’s identity provider?

Standards also represent configuration baselines. An organization might decide to configure its Windows devices based on specifications defined in the Center for Internet Cybersecurity benchmarks or the Microsoft cybersecurity baselines. Standards are the place to declare that.

For the configuration example, a higher-level policy would indicate that devices must be configured to use the organization’s configuration baselines. And the standard defines the baseline.

Procedures

Procedures get into the specifics and define the steps that an employee must take to accomplish something. In the MFA example, a procedure defines how to add new applications to single sign-on (SSO), how to configure employee devices, and at a higher level, how to approve new applications in the first place.

Procedures are dynamic and change the most frequently. And they’re also what most employees use day-to-day.

Critical policy documents

Requirements differ based on organizational structure, specific regulatory requirements, and technology choices. However, the following are policies every organization should have:

• Organizational cybersecurity policy: Sets the overarching cybersecurity objectives, including requirements to review policies
• Acceptable use policy: Documents how technology may be used (and not used)
• Disaster recovery policy: Documents how technology recovers from a critical failure
• Business continuity policy: Documents how operations continue during a critical failure
• Incident response policy: Describes how an organization handles cybersecurity issues
• Access control policy: Describes how access to assets is protected
• Change control policy: Describes the approval process and the documentation requirements for system changes—also defines the circumstances that require formal change approval
• Vendor management policy: Describes how third-party vendors are evaluated and approved before use
• Risk management policy: Describes how the organization measures and manages risk, including risk assessments
• Logging and monitoring: Describes how diagnostic data is collected, stored, and how often it’s reviewed
• Patch management: Describes how the updates are tested and installed, including firmware for network devices, out-of-band management on servers, hypervisor updates, etc.—not just workstation patches
• Vulnerability management policy: Describes how the organization detects, tracks, and remediates vulnerabilities
• Remote access policy: Describes requirements to access organizational assets from outside of the office—this is especially relevant with the rise of remote work

Of course, organizations can have more policies than those listed above, it’s just dependent on their unique needs.

Classification

Data classification is critical because of the finite resources MSPs have available. Classifying data and assigning formal responsibilities to individuals serves two purposes. It allows us to prioritize a limited budget on cybersecurity expenditures and identify what is most important. And it defines who is responsible for ensuring that safeguards are implemented.

Formally, the choice of cybersecurity controls comes from an asset’s classification, which you can identify by conducting a crown jewels analysis. An asset is protected by multifactor authentication because all assets with <X> classification level or <Y> label require that level.

Informally, classification often serves to identify special assets or ones that require controls above and beyond the baseline. Regardless of the formality level an MSP uses, the value comes from taking the time to consider the relative priorities of the data and systems.

Data owners

The person or role responsible for an asset is the data owner. The data owner is not necessarily the person implementing controls, clicking buttons in the interface, or assigning new permissions. However, data owners do approve access requests and policy exceptions. Rather than listing a specific employee as the data owner, we recommend listing a role, such as vice president of operations, to ensure that even in the case of an employee leaving or changing positions, it’s clear who owns the data.

An MSP might decide that their service manager will be the data owner for the RMM system and that the company owner will be the data owner for the PSA software. Those individuals sign off on access modifications, approve changes when needed, and verify that the proper cybersecurity controls are in place, while other individuals in the organization may perform the actual task of making those changes.

Other roles exist in formal classification, like data custodian, data steward, etc. The person who makes the changes would be called the custodian in a formal program. Don’t worry too much about naming the roles—you can save that for a future version of the cybersecurity program.

Classification levels

When defining classification levels, MSPs should think about how granular the controls might get. As a baseline, three levels of classification work as a realistic starting point for many organizations:

• Public: Information that does not require any special protection, such as public-facing marketing materials, press releases, product brochures, etc.
• Internal: Information that does not require any specific protection within the organization, including most company data, like handbooks, reports, etc.
• Restricted: Highly confidential data that needs additional protection beyond average internal data, such as the Coke secret formula—for MSPs, this might mean administrative access to an RMM system

For MSPs, it’s important to differentiate between restricted assets and internal with limited permissions. Classification is not the same as permissions. All assets are still subject to the access control policy and principles like least-privilege and role-based access control.

Labels

Labels are additional context alongside classification levels. MSPs have a unique cybersecurity concern in that they have access to data and systems that belong to other organizations. Identifying which assets those are versus assets that are internal-only allows writing policies that prioritize the protection of those assets.

It’s important to note that data classification isn’t the same as criticality. Criticality is prioritizing the relative importance of assets in the context of operational dependencies.

Cybersecurity team roles

There are many roles on a cybersecurity team. So while this is not meant to be a total employee roster, someone on your cybersecurity team does need to be responsible for each of the roles outlined below.

• Cybersecurity technician: This can be an entry-level position—for example, a tech making the first jump to a cybersecurity role or a recent graduate. Responsibilities include:
  • Checking dashboards for actionable items
  • Ensuring ticket integrations are functioning
  • Verifying alert counts match ticket counts
  • Verifying the accuracy of the security playbook and updating it as needed

• Cybersecurity engineer: This person should have at least 2-3 years of experience, ideally with a background in networking and cybersecurity, and relevant cybersecurity certifications from both the vendors you work with and at least one recognized in the industry as a standard cybersecurity certification. Responsibilities include:
  • Integrating and reviewing tools
  • Maintaining, updating, and troubleshooting tools
  • Managing, maintaining, and troubleshooting cybersecurity appliances
  • Working with vendors to escalate issues
  • Ensuring that tool agents are deployed correctly using your RMM tool
  • Performing onboarding
  • Managing exclusions, safe listing, and the tuning of settings
  • Spot-checking policies
  • Participating in report generation
  • Working with sales engineering

• Cybersecurity analyst: Higher level cybersecurity expert, who trains cybersecurity techs, serves as an escalation point for the security tech, may handle incidents, write a cybersecurity play book, and determine when it’s necessary to perform client tuning. Responsibilities include:
  • Validating that SLA and SLOs are being met
  • Reviewing random tickets to ensure techs are following the playbook
  • Threat hunting
  • Checking the SIEM integrations to ensure the sources are still logging to the SIEM
  • Reviewing client networks for unprotected systems

• SOC manager: MSPs may be able to consolidate the analyst and manager into a single role, depending on their evolution and how involved they want the SOC to be with cybersecurity alerts. Responsibilities include:
  • Delivering security services
  • Trailing the teams
  • Meeting all SLA and SLOs
  • Ensuring the onboarding and training processes are created and followed
  • Ensuring the cybersecurity playbook is created and followed
  • Managing any client/service expectations

• Technical account manager: An account manager that understands cybersecurity and can translate it to clients. Responsibilities include:
  • Reminding clients of the value your team brings
  • Continuing to build the client relationship
  • Establishing the roadmap for one, three, and five-year planning horizon
  • Cross-selling or up-selling the company’s products and services
  • Uncovering any potential problems

• vCISO: This person thinks and acts like the information cybersecurity officer for the client. Responsibilities include:
  • Identifying cybersecurity standards, policies, regulations, and legislation that apply to the organization
  • Completing a gap assessment as part of the vCISO services and driving deliverables of the executive summary
  • Managing threat detection, prevention, and incident management
  • Aligning with corporate Infosec objectives and cybersecurity budget planning
  • Developing, deploying, and testing of cybersecurity architecture and backup and disaster recovery
  • Overseeing legal and human resources services, including data discovery and classification, as well as cybersecurity vendor management
  • Managing investigations/forensics
  • Ensuring compliance and running audits
  • Overseeing identity management, risk management, governance, and technology

Certifications

Certifications are one of the important ways MSPs can demonstrate commitment to excellence within the profession. MSPs are encouraged to make certifications a part of company culture, and an excellent way to reward employees who can achieve and demonstrate their professional knowledge on the job.

Some recommended industry certifications include:

• Entry-level: CompTIASecurity+
• Intermediate level: CompTIACySA+ and CompTIACASP
• Advanced level: (ISC)2 CISSP, ISACACISM, and ISACACISA

ConnectWise also offers members of our Partner Program certifications through ConnectWise University™ and ConnectWise Certify™. Some of these certifications include:

• ConnectWise Certify™ cybersecurity fundamentals for engineers: This on-demand training covers foundational cybersecurity, including industry frameworks and standards, risk assessment best practices, and navigating the ecosystem of cybersecurity products.

• ConnectWise Certify™ advanced courses: This program teaches competencies necessary to build a credible cybersecurity practice. Join our cybersecurity experts for live, in-depth insights into implementing a strong cybersecurity posture inside your business and reliably extending that same level of protection to your clients.

Third-party management

When managing third-party vendors, some important considerations for MSPs include:

• Vendor selection: Consider the vendor’s experience, expertise, reputation, references, and financial stability
• Contract negotiations: Establish clear contractual terms and conditions, including service level agreements (SLAs), pricing, and termination clauses
• Vendor variety: Third-party risk is not limited to SaaS software providers, however those or other service providers are the most common example when considering this type of risk
• Vendor communication: Establish regular communication channels with the vendor to ensure that you address any issues in a timely and effective manner and set expectations for how often you will communicate and how to report problems
• Risk management: Identify and assess the risks associated with the vendor’s services and establish a risk management plan to mitigate those risks
• Performance management: Monitor the vendor’s performance regularly, measure their effectiveness using key performance indicators (KPIs), conduct regular reviews, and establish benchmarks for measuring success
• Cybersecurity and compliance: Ensure the vendor meets the organization’s cybersecurity and compliance requirements—consider conducting regular security audits to ensure that the vendor is meeting these requirements
• Continuity planning: Establish a continuity plan in case the vendor cannot provide services or goes out of business

Third-party lifecycle

Broadly, there’s a cycle when interfacing with third parties and multiple models. While the number and name of steps differ, all third-party lifecycles include:

• Define requirements
• Assess candidates
• Selection
• Implementation
• Operation
• Decomissioning

Third-party risk assessment

The common understanding of a third-party risk assessment is that it focuses on cybersecurity risks. For MSPs, there are differences in risk depending on whether the service is internal or part of service delivery. Some of the risk types to consider when evaluating third parties include:

• Operational risk: If this partner fails, what is the impact on my ability to continue operations?
• Privacy risk: If this partner fails, what is the risk to private data?
• Reputation risk: If this partner fails, how will it impact my reputation?
• Cybersecurity risk: If this partner fails, what is the impact on my own organization’s cybersecurity?
• Regulatory risk: If this partner fails, what is the impact on my regulatory compliance obligations?
• Revenue risk: If this partner fails, what is the impact on my ability to generate revenue?
• Financial risk: If this partner fails, what is the financial cost?

Change management

Change management procedures are critical for the fast-paced world of technology solution providers to ensure that implementing any changes to their systems or services is effective and does not disrupt or negatively impact their customers. Some high-level steps that MSPs can follow to establish change management procedures include:

• Establishing a change management policy
• Identifying the need for change
• Assessing the impact of the change
• Planning the change
• Testing the change
• Implementing the change
• Monitoring the change

Note that, for smaller organizations, it may suffice to simply meet with the key stakeholders and discuss the steps above before executing any changes.

Summary

This blog was meant to serve as high-level summary of good governance processes. For a more detailed understanding of each of these programs and how MSPs should approach cybersecurity governance, read “The Ultimate Operations Guide for MSP Cybersecurity” eBook in its entirety.