Core concepts for MSPs setting up a cybersecurity practice

Posted:

08/14/2023

| By:

Sajal Sahay

This blog is part two of the multi-part series summarizing “The Ultimate Operations Guide For MSP Cybersecurity” eBook, in which we outline core cybersecurity concepts that can be used to establish a common starting point for MSPs wanting to build out a cybersecurity practice.

For additional context and an overall summary of the eBook, you can read the first blog in the series “A Summary of The Ultimate Operations Guide for MSP Cybersecurity.” Otherwise, let’s dive into these cybersecurity core concepts.

The CIA triad

Cybersecurity ensures three states of an organization, environment, or asset—including whole businesses, single locations, and even singular assets such as a laptop, file, website, etc. The three “states” that fall under cybersecurity—confidentiality, integrity, and availability—are typically called pillars and make up the CIA triad.

Confidentiality

Confidentiality means that only subjects authorized to view an object can actually view it. For clarity, objects are protected by controls. Think files, computers, cloud management panels, data, encryption keys, mailboxes, user accounts, etc. Subjects access objects. Often, this means a person, but not always. A person might have more than one account, so in that case, the account is the subject. Subjects can also be programs, services, or anything with a cybersecurity context.

Integrity

Integrity is ensuring that only authorized parties are making changes to resources. An unauthorized user maliciously changing data isn’t the only type of integrity violation. Bit errors caused by faulty hardware, mistakes by administrators, an internal user purposely altering or modifying data, and software bugs can all violate integrity.

Availability

Availability means that information and systems are operating when needed. A secure and unaltered copy of a file is not useful if it’s on a server that nobody can access. Vendors going out of business, employees standing around after a ransomware payload detonates, a denial-of-service attack, or intentionally locking out a user account with too many wrong password attempts are all examples of potential availability losses.

Frameworks

Think of a cybersecurity control, any control. The most common first answers to this question are passwords, antivirus, multi-factor authentication (MFA), and spam filtering, among others. Now, if you implement all of them, everything is done, right? Maybe, but not likely—there are plenty of other factors to consider.

What about policies, risk management, or availability controls like backups? What metrics are you monitoring? A framework can help you structure these conversations and discussions, just like asking “what about” questions.

NIST Cybersecurity Framework

One common cybersecurity framework is the NIST Cybersecurity Framework (CSF). It breaks cybersecurity programs into five areas: identify, protect, detect, respond, and recover. Specific items within each category ensure nothing from a cybersecurity program is missing.

For example, an item from the CSF is:

Function: Identify
Category: Asset management
Subcategory: Inventory of physical devices and systems within the organization

Compliance

Compliance is the adherence to a set of requirements. In the context of IT and cybersecurity, it’s a collection of required controls or objectives that we need to create controls to meet. So, in other words, almost exactly like frameworks. For MSPs, compliance takes two forms: internal operations and participation in clients’ compliance programs.

Compelled vs. elective compliance

Compelled compliance means compliance factors that are required. It’s often tied to a specific industry or data type, and the organization must meet those requirements to continue operating or working with that information. Some examples include: HIPAA for health information, PCI for credit card transactions, CMMC for government contracting, and the NYSDFS regulations for financial clients in New York.

Elective compliance refers to optional frameworks. Organizations adhere to these regulations and perform audits to demonstrate their cybersecurity posture with potential customers or partner companies. Some examples include: SOC 2, ISO 27001, CSA’s STAR program, HECVAT, and C5.

Clients are ultimately responsible for their own regulatory obligations. As MSPs, we participate in the process, are specifically named in some controls, and must follow client requirements, but the burden to maintain compliance remains with each client.

Scoping

Scope refers to the assets—systems, data, personnel, geographic locations—that the compliance program covers. Compliance programs always have an associated scope, though some frameworks allow the organization to set the scope themselves, and some pre-define it. For example:

PCI applies to any asset that interacts with cardholder information
SOC 2 applies only to what the audit scope listed in the report is

Risk management

Cybersecurity programs exist to measure and manage risk. All the controls, compliance requirements, policies, cybersecurity tools, and even insurance exist to accomplish one of those tasks. But risk doesn’t exist in a vacuum. Risks are risks to something—for example, the confidentiality of an asset or the availability of a service. Some important things about risk to note include:

Risk cannot be reduced to zero—taking risks is an inherent part of business
The goal is to minimize risk to an allowable level, defined by an organization’s risk tolerance
To reduce risk, we treat it, or if it’s already below the risk threshold, we accept it

Risk assessment

Risk assessments analyze threats to assets in terms of preventing the accomplishment of business outcomes. Multiple assessment strategies exist, and specific regulatory frameworks may have unique requirements.

If there are specific types of information or assets—for example, personal health information (PHI), controlled unclassified information (CUI), or personally identifiable information (PII)—that are protected by additional regulatory obligations, consider the risk to those information types in the assessment.
Some high-level methodologies are the CIS risk assessment method (RAM) or the NIST guide for conducting risk assessments. Organizations may also choose to use their own methodology or one that is required for compliance purposes.

The output of a risk assessment is a prioritized list of risks to organizational objectives and critical assets, which you can use as an input for risk treatment.

Risk treatment

Risk treatment is sometimes called risk reduction, but that’s inaccurate. There are multiple possible actions when faced with a risk:

Accept: This means formally acknowledging the risk, deciding it’s below the organization’s risk tolerance or that the benefit is enough to warrant it, and choosing to proceed anyway.

Transfer: This means moving the risk to someone else. Usually, this is synonymous with obtaining insurance.
Mitigate: This means reducing the risk to an acceptable level using cybersecurity controls—which might mean adding additional authentication, more frequent backups, background checks, etc. This is the root reason for implementing cybersecurity controls.
Avoid: This means deciding the risk is too great and cannot be cost-effectively mitigated. Examples might be opening a new location in a foreign country or a new service offering.
Ignore: This is not a recommended action—identified risks should be addressed, whether they are accepted or mitigated.

Least privilege

Least privilege means to grant the least access required to perform a job. Usually, this comes up when discussing file system access or what sections of the internal knowledge base each employee can access. For example, if someone from HR tries to access the finance folder, that shouldn’t be allowed.

Least privilege also applies to functions. For an MSP, that means that members of the backup team should be the only accounts that can change backup configurations. Or, with an endpoint protection solution, only certain employees would have access to remove protection or add exclusions.

Lastly, MSPs must consider the risks of a compromised tech account in a backup management system. If that technician has access to every client, the confidentiality of every client’s data is at risk. If, instead, each technician’s account has access to only the specific clients that that person works with, a much smaller amount of client data is at risk. In a company with multiple offices, a least-privilege approach might limit techs to access only clients associated with their home location.

Role-based access control

Role-based access control means that privileges are assigned to specific groups of individual accounts that are grouped based on their dedicated roles. However, it’s also important to note that some employees fit into multiple roles, and some will have individual permissions that don’t align with any. Sometimes that means a new role and associated group, and sometimes that just means it’s an exception.

During access reviews:

Check group memberships and the access granted to individual groups
Review any individually assigned permissions and confirm that there’s an associated exception with documentation and approval

Separation of duties

Separation of duties prevents any one person from making critical system changes without help. It’s separate from the approval process. For example, an MSP might have a cybersecurity team that reviews applications, and there might also be a separate team that manages internal resources. An application of separation of duties might mean that the internal IT team doesn’t have written access to the cybersecurity team systems.

Scale is also a factor in this concept. For smaller organizations, it’s often necessary for employees to have fractional roles. Also, consider that the concept isn’t just related to direct technology. In finance, separation of duties might mean that the person who approves a transaction is separate from the person who executes it.

Defense in depth

Defense in depth is the concept of layered cybersecurity. No cybersecurity control is entirely effective, both in terms of breadth and depth of coverage. For example, let’s say a malicious email gets through the firewall, or new malware isn’t detected, or passwords are compromised frequently. If you follow a defense in depth concept, it’s possible that:

The malicious email that got through had a link that was stopped by DNS filtering
The malware that wasn’t detected by the endpoint software was stopped by application safe listing
The account with the compromised password was still protected by multi-factor authentication

That’s defense in depth. Multiple controls combined to provide better overall protection.

Shared responsibility

Creating a secure environment requires action from all parties. For example, clients are responsible for informing the MSP about changes, and MSPs are responsible for confirming identity before granting access requests.

The breakdown comes when these distinctions aren’t clear upfront. A common mechanism to define these roles is called a shared responsibility matrix. The shared responsibility matrix lists responsibilities in one column, then each party in subsequent columns with marks to indicate who is responsible.

Summary

This blog was definition focused, with the explicit purpose of imparting knowledge of the common language, concepts, and terminology used by the cybersecurity community. For a more detailed understanding of each of these definitions and how they impact MSPs and client programs, check out the full “The Ultimate Operations Guide for MSP Cybersecurity” eBook.