Cyber security considerations for consumers of managed services (ITSM.50.030)

1 Introduction

Small or medium businesses may want to use service providers to remotely manage their organizations’ information technology (IT) infrastructure, cyber security, and other related business operations. However, managed service providers (MSPs) are attractive targets for cyber criminals because they have access to numerous client systems and a lot of data. If an MSP is compromised, their clients are also vulnerable; a compromise can result in stolen proprietary information and disrupted business operations, which can result in financial loss and potential harm to an organization’s reputation.

You can use this document to help your organization determine whether an MSP has the capabilities to deliver services effectively and securely. This document introduces some security topics that you should consider before and during the process of procuring managed IT services. These topics include the following:

• Data security;
• Legal compliance;
• Service provider assessments;
• Access control;
• Encryption;
• Incident response;
• Business continuity and disaster recovery;
• Supply chain integrity;
• Exit strategies; and
• Data destruction.

Your organization and the MSP both have roles when it comes to protecting systems and data. Your organization is the data owner and is legally responsible for data security. Therefore, it is critical that you explicitly define your organization’s security requirements and ask an MSP the right questions before you sign on to use a service. Having this information will ensure that you define an effective service level agreement with the MSP.

For an overview on some best practices when contracting an MSP, see Cyber Security Best Practices: Contracting with Managed Service Providers ^{Footnote 1}.

1.1 Managed services

An MSP is a company that remotely manages IT infrastructure and user end systems on behalf of a client. According to the MSP Alliance, MSPs typically have the following distinguishing characteristics:

• Provide some form of network operation centre (NOC) service and help desk service;
• Monitor and manage remotely all or most of the objects for the client;
• Maintain proactively the objects under management for the client; and
• Use some form of predictable billing model (i.e. client has an accurate total amount for regular IT management expenses).

Note that there are differences between cloud services and managed services. The main difference revolves around who has control over the data and the processes. With managed services, the consumer (e.g. your organization) dictates the technology and operating procedures. However, with cloud services, the service provider dictates both the technology and the operational procedures available to the consumer (e.g. your organization).

In this document, we assume that your organization will use at least some infrastructure in the cloud.

2 Security considerations for consumers

For each topic covered in this section, we include a description to provide you with more context, an explanation of why the topic is important, and a checklist of activities and questions to help you determine whether an MSP is right for your organization. Depending on your organization’s business needs, some of the security topics may be more relevant than others.

Note that this document does not help you identify your organization’s business requirements. Your business requirements are specific to your organizational environment and circumstances.

2.1 Data security

Before contracting potential service providers, you should identify the data that will be accessible to the service provider and the sensitivity level of that data. By understanding your data and its sensitivity, you can identify the security controls that are required to protect it appropriately.

Data sensitivity is measured by the impact a compromise would have on your organization’s ability to achieve its mandate. Data sensitivity is categorized as high, medium, or low:

• High (H): Compromise has a critical or a prohibitive impact on your organization’s ability to achieve its mandate;
• Medium (M): Compromise has a major impact on your organization’s ability to achieve its mandate; or
• Low (L): Compromise has a moderate impact on your organization’s ability to achieve its mandate.

Data sensitivity considers the compromise’s impact on the data’s confidentiality, integrity, and availability, which are the three pillars of IT security. Confidentiality protects information from unauthorized disclosure. Integrity protects information from unauthorized changes. Availability ensures that information is available when it is required. You should apply values of high, medium, and low for each of these three areas to construct a three part data security profile.

For example, consider a data set that has a data security profile of H/M/L. You can interpret the three parts of the data security profile in the following ways:

1. A data confidentiality compromise (H) has a critical or prohibitive impact on your organization’s ability to achieve its mandate;
2. A data integrity compromise (M) has a major impact on your organization’s ability to achieve its mandate; and
3. A data availability compromise (L) has a moderate impact on your organization’s ability to achieve its mandate.

Note that data classification can be time sensitive. For example, the sensitivity of election result data is much higher the day of an election than the day after. We recommend that you classify your data based on the highest level of expected injury that could result if that data is compromised. See Annex 1 of ITSG-33 IT Security Risk Management: A Lifecycle Approach ^{Footnote 2} for more information on classifying and categorizing your data.

2.2 Legal and regulatory compliance

When data is stored outside of your organization’s infrastructure, you need to know where it is stored (i.e. the geographical location). Data stored outside of Canada is subject to different privacy, security, and data ownership laws and regulations. Depending on the industry or the sector to which your organization belongs, the data may also be subject to different regulations and standards that govern the data’s retention, disclosure to third parties, and chain of custody.

Canada’s privacy laws (i.e. the Privacy Act and the Personal Information Protection and Electronic Documents Act [PIPEDA]) align with the European Union’s (EU) privacy laws (e.g. General Data Protection Regulations [GDPR]). In Canadian and EU legislation, organizations must ask individuals for permission to collect their personal data. In Canada and the EU, individuals also have the right to be forgotten^{Footnote 2}. Other countries may view privacy differently and do not comply with the GDPR, which can interfere with the confidentiality of your organization’s data.^{Footnote 3}

If data is stored outside of Canada, different laws (e.g. national security priorities) may take precedence over Canadian privacy laws. If you are using managed services that store data outside of Canada, you should review the applicable laws and the possible impacts to privacy. This precedence can interfere with the availability of consumer data if a security threat or a legal case occurs.

In the IT Policy Implementation Notice: Direction for Electronic Data Residency ^{Footnote 3}, the Treasury Board of Canada Secretariat (TBS) requires that sensitive data^{Footnote 4} collected or processed by the Government of Canada (GC) is stored within the geographical boundaries of Canada or within the premises of a GC department located abroad (e.g. Canadian consulate). This requirement ensures that the GC can maintain continuous access to the data for business continuity.

If your organization is a non-GC organization, we recommend that you ensure all sensitive data (M/M/M or above) is stored only in data centres located within the geographical boundaries of Canada. Additionally, various industries have specific compliance standards and directives, such as audit regulations, that require standard data retention periods. Your organization is responsible for determining whether or not a prospective MSP adheres to these requirements.

If your data is stored outside of your organizational premises or infrastructure (i.e. in a cloud infrastructure), it is critical to ensure that your organization retains legal ownership. Your organization is legally responsible for the privacy of data. Ensure that you can maintain control of this data by maintaining ownership within a cloud infrastructure. Ask your provider!

2.3 Service provider assessments and audit reports

Once you have classified your organization’s data, you can compare your organization’s security control requirements with the service provider’s ability to apply adequate safeguards to that data.

2.3.1 Service provider assessments

Service providers can be assessed against recognized security standards and frameworks to determine their capabilities in terms of protecting sensitive data. Some examples of security standards and frameworks include:

• International Organization for Standardization (ISO) – ISO270001/2 ^{Footnote 4};
• Information Systems Audit and Control Association (ISACA) – Control Objective for Information and Related Technologies (COBIT) ^{Footnote 5};
• Cloud Security Alliance (CSA) – Security Trust Assurance and Risk (STAR) ^{Footnote 6};
• National Institute of Standards and Technology (NIST) – Risk Management Framework ^{Footnote 7}; and
• Our ITSG-33 ^{Footnote 2}.

We developed service provider assessment programs, which support TBS’s Contract Security Program. We conduct these assessments by using recognized security frameworks to evaluate the security capabilities of service providers and their abilities to protect Canadians’ sensitive data.

2.3.2 Security control audit reports

The International Standard on Assurance Engagements (ISAE) No. 3402, Assurance Reports on Controls at a Service Organization (ISAE 3402) ^{Footnote 9Footnote 5} is an auditing standard for the controls used by service organizations. This standard ensures that adequate security controls are in place for accurate financial reporting. A third party audits the service provider’s controls to produce service organization controls (SOC) reports to demonstrate the service provider’s compliance with ISAE 3402. These reports can be used to determine the effectiveness of the design and the implementation of technical and non-technical security controls. See below for descriptions of SOC 2 and SOC 3 reports.

2.4 Access control

Access control (e.g. an access control policy) determines who can access your organization’s data, systems, and networks. In this context, access control should align with the confidentiality and integrity pillars of the data sensitivity profile described in section 2.1.

Your organization’s access control policy should persist when you use managed services, regardless of whether the data is stored on site or in the cloud. When using managed services, your organization and the service provider must agree on the roles and responsibilities related to access control. You must also define the authentication and authorization mechanisms, which are two elements of access control. Authentication refers to any process or measure that is used to verify a user’s identity, and authorization refers to access privileges that are granted to a user, program, or process.

2.4.1 Access control policy

Your organization is responsible for your access control policy. You must clearly define all access control requirements to the service provider so that you can determine whether they can support these requirements. Access control should be based on the principle of least privilege, meaning that individuals should only have the privileges that they need to perform their work functions. Service providers should only have the access that enables them to effectively manage their services.

2.4.2 System administrators and physical access to servers

System administrators (SAs) pose a large risk to data; SAs can access multiple clients and may have physical access to client servers. Examples of other personnel who may have physical access to servers include facility maintenance staff and external hardware and software maintenance staff. If managed services are deployed outside of your organization’s infrastructure, you should consider other standards that address the ways in which you can effectively limit access to physical servers for administrators or other personnel.

2.4.3 Password policy

If an MSP provides services within your organization’s infrastructure, the MSP must align with your access control structure (i.e. authentication and authorization). However, if an MSP provides services outside of your infrastructure, such as in a cloud infrastructure, you should ensure that the MSP supports authentication mechanisms that are appropriate to the classification level of the data deing stored.

In a traditional on-premises IT infrastructure, it is your organization that dictates a minimum password policy (e.g. complexity, maximum time between mandatory password changes, use of passphrases). Passphrases and passwords must conform to this policy. With managed services, your organization and the MSP should agree on a password policy that meets or exceeds your existing password policy.

You need an effective password policy to prevent threat actors from easily guessing or cracking passwords. Although users may find it onerous to create passphrases and complex passwords, we recommend that you review the minimum practices defined in ITSAP.30.032 Best Practices for Passphrases and Passwords ^{Footnote 10}. We find that the following standards produce the best deterrent effect:

• Passphrases should be at least 4 words and 15 characters long;
• Passwords should be at least 12 characters long; and
• Passcodes and PINs should only be used if you cannot use passphrases and passwords;
  • Use randomly generated PINs where available.

Two-factor authentication (2FA) uses a combination of two different authentication factors when you access an account, making it more secure. The authentication factors should include at least two separate factor types:

• Something you know (e.g. a password or PIN);
• Something you have (e.g. a token or a smartcard); and
• Something you are (e.g. a biometric, like a fingerprint).

Note that an authentication process that requires a password and a PIN is not true 2FA because both are a single factor type (i.e. something you know).

Because of the widespread nature of phishing attacks and password theft, many services, including most social media platforms, have added 2FA options. We strongly recommend that you use 2FA for these platforms, especially for important public-facing accounts.

2.4.4 Federated authentication

In an on-premises IT infrastructure, passwords are used and stored internally only. However, when identity is verified in the cloud, some of, or all, your infrastructure authentication services (including usernames and passwords) may exist outside your organization’s internal IT infrastructure. Passwords are the “keys to the kingdom” because they are used to control access to your organization’s data. Passwords need to be protected appropriately. As a best practice, passwords that reside outside your organization’s trusted space must never be stored or transmitted in plaintext. Additionally, no entity outside of your organization should both hold your data and the credentials to access that data.

We recommend that you use federated identity, which works in the following way:

1. You enter a password to access resources that are stored outside of your organization’s infrastructure;
2. An authentication mechanism hashes this password and sends the hash to a third party federated service, which holds your organization’s (encrypted) passwords;
3. The federated service performs a hash function on the stored password and compares this hash against the hash received to validate that they match;
4. The federated service generates a certificate (or token) if the hashes match; and
5. The certificate is sent to the service provider, authenticating you and authorizing your access to the appropriate resources.

A cloud provider may offer authentication services, but this is not true federation as they do not leverage a third party. These services can present a risk because the cloud provider can access both your credentials and your data. However, this can be a reasonable risk if the cloud provider has internal processes to isolate the authentication process from your data, protecting against possible exploits. You should ensure that, if the provider offers authentication services, they can attest that their authentication services are appropriately isolated from your data.

2.5 Encryption

Encryption uses a random string of bits (i.e. an encryption key) to convert readable information into unreadable cipher text. Encryption hides the contents of sensitive data to prevent unauthorized access. Encryption is the key mechanism to protect the confidentiality of data in transit over the Internet and data at rest. Therefore, encryption aligns with the confidentiality pillar of the data sensitivity profile (i.e. M/M/M as defined in section 2.1).

Your organization is the data owner and is legally responsible for protecting the privacy of your organization’s sensitive data. You must decide which level of encryption to use. You also need to ensure that the MSP can support your selected level of encryption and that the MSP has controls in place so that no one outside your organization can access both your encrypted data and the associated encryption keys to decrypt the data.

2.5.1 Encryption in transit and at rest

With sensitive data, you must ensure that you apply measures that protect data in its various states, such as when it is in transit and at rest. Data in transit is data that is active and moving from location to another, such as across the Internet or within a private network. Data at rest refers to data that is inactive. In this state, your data may reside in databases, data warehouses, spreadsheets, archives, back-ups, and mobile devices. You should consider which encryption levels to use for data in transit (e.g. HTTPS web traffic) and data at rest (e.g. the encrypted contents in storage at a data centre).

2.5.2 Key management outside consumer infrastructure

Encryption is the predominant security control that is used to protect the confidentiality of data. However, note that if you lose control of the encryption keys (i.e. the random string of bits used to encrypt and decrypt data), you lose control of the data. In best practice, keys should be stored in your organization’s trusted, internal infrastructure only. However, to manage encryption keys, your organization needs to manage infrastructure that can be expensive and have staff who specialize in key management. For smaller organizations, this is rarely feasible.

Service providers often have sound key management infrastructure and appropriate policies to lock down access. You can request to review the MSP’s key management capabilities. Keep the following considerations in mind:

• Resources outside of your organization should never have access to both your data and the keys used to decrypt this data. Access control policies and mechanisms should be in place to ensure that encryption keys are isolated from the data they protect.
• Encryption keys should never exist in plaintext outside of your organization’s trusted infrastructure. Encryption keys should be encrypted at rest, at the same level, or higher, than the data they are protecting.

Remember that your organization always has an option. You can use a third party to manage encryption keys if the MSP’s key isolation policy is insufficient for your needs. This may add complexity to service level negotiations but would be worth it to keep your data safe.

2.6 Incident response

Even with security controls in place, incidents can still happen. A security incident is any intentional or unintentional damage, theft, or unauthorized access that has a direct or indirect impact on the security of your organization’s systems or services. Incidents can impact the provisioning or the security of a service, causing unplanned business interruptions. An incident may be caused by one of the following examples:

• Data breach;
• Theft or loss of assets;
• Malicious code;
• Network scans;
• Denial of service attacks;
• Fraud; or
• Server failure.

When an incident occurs, your organization needs to respond quickly to minimize the resulting damage. A general incident response plan includes steps to identify, contain, remediate, and communicate the issue. When an incident occurs, it can be identified by your organization (e.g. usability issues with a service) or by the service provider (e.g. a back-end issue). Because of this, you need to ensure that you have an effective communication path and that you can support each other.

When you use a service provider, your organization remains accountable for incident response, even if your organization is not solely responsible for implementing all steps of the incident management process. You should work with the service provider to coordinate an incident response plan. In this response plan, you should separate the roles and responsibilities of your organization and the service provider. A service provider may offer similar services to many customers. As a result, the service provider’s priorities will differ from your organizational priorities. For example, your organization might experience an issue that is catastrophic to your business and that requires an immediate response. However, your request for an immediate response may sit in the service provider’s queue because they are busy supporting many other organizations with multiple critical issues.

You must establish clear requirements for incident response, and you should ensure that the service provider can support your requirements. We recommend that you work with the service provider to define and agree upon expectations related to the level of service your organization requires. Your service level agreement with the service provider should specify the expected turnaround times, communication media, escalation processes, metrics for assessing performance, and penalties for not meeting turnaround times.

Incidents can occur repeatedly, which can indicate a more significant problem. When procuring managed services, it is important to ensure that the service provider has a capability to report on incidents over time so that underlying problems can be identified. An example could be data spills involving sensitive data. If this occurs once or infrequently, incidents can be managed individually. However, if data spillage occurs numerous times, then there may be a more significant problem, which may justify costs to revamp security training to address data spillage or to implement measures such as data loss prevention (DLP) or cross-domain solutions (CDS).

2.6.1 Event logging support

The service provider has direct access to systems associated with the services they provide. As such, the service provider may be able to provide log data or monitoring services related to the following:

• Virus scans;
• Detection of non-standard or suspicious code, files, or folders on hosts (host based sensors);
• Signature auditing;
• Use of bandwidth;
• Event monitoring; and
• User activity monitoring.

You need to explicitly define your requirements and responsibilities with regards to log support to identify potential security incidents. You may not need to see all the logs, but you should be aware of events that impact your data.

2.7 Business continuity and disaster recovery

Business continuity refers to your organization’s ability to continue operations when something goes wrong (e.g. a disruption or disaster). If you use a service provider, you depend on them to support the ongoing availability of the services that you use. You should know the actions that the service provider takes to prevent failures and the ways in which the service provider supports the recovery of these services in the event of disaster. Business continuity and disaster recovery refer directly to the availability pillar of the data sensitivity profile (see section 2.1).

2.7.1 Redundancy

Uptime refers to the service provider’s guaranteed percentage of time that they can provide services. Note that not all service providers, including CSPs, have the same uptimes. You should ensure that you can access your organization’s data when it is needed.

Hardware failures happen, but systems can continue to operate based on the amount of redundancy and the failover mechanisms that are in place. As part of your organization’s business continuity planning, determine your uptime requirements, as well as the maximum time you can afford to be down without significantly impacting your business (i.e. maximum tolerable downtime). Note that your uptime and maximum tolerable downtime requirements may vary depending on your business functions and processes. For example, the acceptable downtime for an electoral administration organization during election day is much less tolerable than downtime the day after the election.

2.7.2 Disaster recovery

In a perfect situation, disasters do not occur, and recovery is not necessary. However, your organization needs to be prepared for scenarios in which things go wrong so that you can recover quickly and reduce the impact to your business operations. Your organization is responsible for establishing and testing a disaster recovery plan. You may want to outsource certain aspects of that plan (e.g. backing up data) to a service provider. You must work with the MSP to ensure that outsourced services work and that your roles and responsibilities are clear.

2.8 Supply chain integrity

Your supply chain is your network of suppliers, service providers (also referred to as sub-processors), partner organizations, and resources that are involved in creating and delivering your business products and services. Your supply chain is critical to your business activities, but it can also be a high-value target for threat actors.

As indicated in the Cyber Centre’s National Cyber Threat Assessment 2018 ^{Footnote 13} , sophisticated cyber threat actors continue to exploit the relationships between businesses and their suppliers and service providers, including information and communication technology (ICT) supply chains. Industry research also confirms that half of all observed cyber attacks involve supply chain compromises.

Regardless of the size of your organization, you should consider the risks associated with your supply chain and ICT products and services (e.g. end user devices, software, networking solutions, servers). When procuring managed services, it remains your responsibility to protect the security of your information. Therefore, you must understand the assurance level that the service provider can provide for the technology that they are responsible for.

2.9 Data and service portability

After entering a contract with a service provider, your organization may decide to go another way due to service dissatisfaction or changing business needs. Vendor lock-in occurs when it is not financially feasible to port data from one provider to another (e.g. large penalties associated, proprietary data formats, ownership of data).

Data portability refers to the ability to move data from one system or server to another. Your organization should consider an exit strategy, in case the need arises, when entering a service contract.

2.10 Data destruction

Once data is no longer needed for business purposes, and it meets its retention period, it should be destroyed. Data destruction involves destroying the data that is stored on tapes, hard disks, and other forms of electronic or physical media so that it is completely unreadable and cannot be accessed or used for unauthorized purposes. Proper data destruction ensures that your organization complies with legal and regulatory requirements. It also decreases the risk of data spills and breaches. Data spills can lead to non-compliance with legislative and policy requirements, loss of reputation, negative media coverage, loss of revenue, regulatory fines, prosecution, and legal fees.

When procuring cloud services, you must ensure that data is secured and effectively destroyed according to your organization’s requirements (e.g. information management policy, retention schedule). In the cloud, physical destruction of hardware is extremely difficult because the CSP owns the hardware and may host multiple clients on the same hardware. Instead the most effective means of destroying data is crypto-shredding. Crypto-shredding refers to encrypting data that is no longer needed and then deliberately deleting or overwriting the encryption keys to make the data inaccessible.

Please note that cloud infrastructure is built on the principle of redundancy (i.e. there are many instances of data). To destroy the data completely, all instances of the data must be located. Also be aware of offline copies, such as back-ups or other downloads, to ensure that they are included in the destruction process.

3 Supporting content