In this article, we will answer the following questions:

• Where is the border between the areas of responsibility of the client and the provider?
• Can it be moved and how to fix it?
• How to choose a cloud provider and the final list of services to be sure that the requirements of standards and laws are properly met?

Absolute protection: myth or reality?

Buying cloud services, the client expects that he will not be engaged in non-core activities for him, and all the work to maintain the infrastructure will fall on the cloud provider. A similar assumption for information security services, unfortunately, does not work.

So far, everything is going well, the client of the information security system perceives it according to the principle "works – and well", but in the event of a hack, he immediately declares that he expected security guarantees. Some may even immediately require the provider to ensure that the cloud solution is completely unbreakable.

Therefore, sometimes it becomes a very big problem to explain to the customer that there is no absolute unbreakability. In many cases, the provider can ensure the operability of the information security system, but cannot come up with the logic of its operation and protection rules.

Of course, a cloud provider deals with the security of its own cloud, but in traditional IT systems, performance and speed are indicators of quality. Information security is expected to be free from incidents and to comply with legal and regulatory requirements.

But information security incidents are not a degradation of performance, which is relatively easy to measure, or a system shutdown (although this happens); they are ultimately associated with data or the process of data processing. And to measure their criticality, and just to understand what is just a log record, and what is an incident is difficult. For example, has the antivirus responded to a malicious virus or a legitimate script? If it was a virus, and the antivirus blocked it, that's good. And if not blocked, then how many computers have become infected, and who is responsible for the failure of the special anti-virus protection tool?

In addition, legislation and standards introduce the concept of financial liability for non-compliance with information security requirements. Therefore, information security services are complicated by measuring their quality and responsibility, which can occur not only for the information security incidents that have occurred but also for non-compliance with requirements even in the absence of real hacks.

In addition, there is no absolute security: even theoretically, it is impossible to guarantee the complete absence of system hacks. Therefore, when interacting with a cloud provider, it is very important to define and legally fix who is responsible for what: what is in the provider's area of ​​responsibility and what is in the client's area of ​​responsibility.

Responsibility boundaries – who is responsible for what?

The answer to this question depends on the type of service itself and its practical implementation.

Basically, the following logic applies here:

• Everything that the cloud provider controls and that the cloud client cannot control should be in the cloud provider's area of ​​responsibility.
• Everything that the cloud client controls and cannot be controlled by the cloud provider should be in the client's area of ​​responsibility.

In practice, there are several additional factors:

1. The provider may offer additional services that require security or information security services.
2. "Gray zones". Services or technical solutions that can be controlled by both the provider and the performer.

With services located at the intersection of areas of responsibility, we can apply the approach "who makes decisions – the one who is responsible for implementation."

It is easier to describe this using examples with specific types of services.

IaaS

The provider provides virtual capacity for service deployment. However, he does not create virtual machines and has no control over their contents.

Thus, the provider controls:

• The premises in which the cloud is located (DPC). And is responsible for the physical protection of these premises;
• The technical network that provides the vital activity of the cloud and connections with providers and the Internet;
• The virtualization environment, and the service systems that support the cloud. And is responsible for protecting the virtualization environment; trusted boot of virtual machines; anti-virus protection of service components of the cloud; as well as protection against unauthorized access to service components of the cloud.
• Access control for your own administrators;
• Protection of workplaces of their own administrators;
• Collection and storage of logs generated by cloud components.

The cloud provider also provides processes for updating, identifying, and eliminating vulnerabilities at the cloud level on its own.

The client receives virtual capacities on which he deploys his virtual machines, installs his software, and lets his users there.

Thus, it is the client who controls:

• Internet access segmentation and protection;
• VM anti-virus protection;
• VM renewal;
• Control and elimination of vulnerabilities in VM;
• Authorization and configuration of access to OS and software;
• Application security: their updating, absence of vulnerabilities;
• Controlling the access of your employees. Including the granting of the right to employees to leave applications with the provider's technical support service.
• Logging settings in applications. Identification and analysis of information security incidents.
• Data protection in motion. In fact – the actions of legal users.
• Data encryption, if necessary.

The hardest part is with the gray area. It most often occurs either for technological reasons or as some kind of additional service from the provider. In the gray zone, the logic is usually "the one who can know how it is needed – he is responsible."

The following protection measures are in the gray zone:

• Managing the access of the client's employees to the data center. If an employee had a pass to the data center, and the employee quit, and they forgot to revoke the pass, then the provider cannot find out about the fact of dismissal.
• Firewalling.
• From a technological point of view, the provider automatically provides clients with some kind of firewall.
• But, firstly, this firewall may not have some functionality required for the standard: for example, the basic VMWare NSX Edge firewall cannot work as an IPS. And PCI DSS requires IPS.
• Secondly, this firewall may not have any FSTEC certificate required by the client. And this is not the same firewall that the provider uses to protect the cloud itself – the client needs their own firewall.
• Thirdly, someone has to configure access rules on this firewall. And only the client can come up with these rules – the provider simply does not know which network ports the client's applications can legitimately use.
• Backup. The provider usually knows how to do it, but it is the client who must say what exactly needs to be copied, how often, and how long to store.
• Storage and processing of logs. Many providers can provide a log storage service. This is a demanded service, since logs can take up quite large amounts of disk space, and they need to be stored for a long time.
• But there is a big difference between storing logs and analyzing information security incidents: the analysis of information security incidents is performed using logs, and knowledge about which events and in which systems look suspicious or incorrect.
• Encryption of hard disks of virtual machines. Since, on the one hand, encryption is needed so that the provider is guaranteed not to be able to see the data, and on the other hand, the hypervisor must be able to start the virtual machine. Those. you will have to load the decryption keys into the hypervisor maintained by the ISP.
• Protecting access to data when providing administration services for a virtual machine or applications in the cloud.
• The provider can provide OS or software administration services on virtual machines hosted in the cloud. But there are two nuances here. The first is not the fact that the process of access of the provider's employees to the client's resources needs to be brought in line with the requirements of 152-FZ. Second, under the rather simple word "administration" many complex processes can be hidden: for example, should the administrator keep track of the relevance of OS versions, or just update upon request? If the administrator must independently monitor the relevance – can he simply update the OS, or must somehow test compatibility with the software running on the updated server? If the software is not compatible, what to do with the update? Can and should an administrator monitor the composition of software and system services on the administered server? If so, how does he understand which services and software are allowed? And what if the software is not compatible with the OS update?

Clients often ask:

What is so difficult about handing over an OS upgrade service, or taking configuration control measures?

Controlling configurations actually boils down to analyzing the update: controlling the installed software, the installed version, available updates, and the status of the successful installation of these updates, as well as the settings of this software, and bringing them into line with the documents. And we have already considered an example with the complexity of the update process above.

PaaS

The provider provides the client with virtual facilities, on which a platform for working with data or applications has already been deployed and configured.

The most common examples are DBaaS, containerization service, S3.

The provider controls:

• Everything that has been described for IaaS;
• Security of access of own administrators to platform administration (anti-virus protection, updates, etc.);
• Security of the provided platform: update, control and elimination of vulnerabilities;
• The relevance of the created customer user accounts and the compliance of their passwords with the password complexity and renewal policies;
• Collection and storage of platform logs

The client controls:

• Correctness of settings and configurations of what works inside the platform: node in the case of containerization; logical structure of the database in the case of DBaaS; public access settings in the case of S3.
• Controlling the access of your employees. Including – the issuance of the right to employees to leave applications in the technical support service of the provider.
• Logging settings in applications. Identification and analysis of information security incidents.
• Data protection in motion. In fact – the actions of legal users

The following protection measures are in the gray zone:

• Firewalling. For the reasons already described
• Backup. For the same reasons.
• Log processing. And it becomes more difficult with it: setting up the collection of logs is usually carried out at the platform level. But how the client wants to analyze the logs, and what is important for him to see in the logs, can vary greatly.
• The use of optional security tools, the installation of which is required at the OS level (outside the user's control). For example, does S3 need antivirus? Not everyone, and it is not necessary to implement it at the S3 level.

In the case of PaaS, the most common problem is just updating and installing security patches: by and large, the provider either maintains a single configuration for all copies of the platform or allows you to customize each copy of the platform for different clients requests.

But if all copies of the platform are configured in the same way, then there is a chance that customers using legacy software or legacy methods will sooner or later face incompatibility between their software and the platform. And if the provider configures each individual copy of the platform for the needs of the client, then again there is a need to describe the update process and determine who is responsible if there is no way to update.

SaaS

In this case, the provider takes over all the IT and cybersecurity parts of the work and offers customers the opportunity to simply use the application: a web disk, or 1C, and the like.

From the user's point of view, everything is simple – everything is controlled by the provider.

But for the provider it is difficult, so it is desirable for the client to find out how the provider implements this.

Is it possible to move the border of the area of ​​responsibility

It is possible, but the customer needs to prepare for this.

In fact, for any increase in the provider's responsibility, the client must describe to the provider exactly how to work.

If the provider needs to control the update, then:

• What packages (only OS, or some other software)?
• What should the provider do with the detected non-updated machines?
• If the provider has to update them, should they test compatibility with the software? And How?
• If the software is not compatible with updates – what should the provider do.

Likewise for vulnerability management, configuration control, integrity, and even antivirus.

In fact, it is necessary to describe the IS management procedures, consisting of:

• Determining the "correct" state;
• Determination of the coverage area. For example, update everything or just the OS;
• Definition of control measures and metrics;
• Determination of the way of informing about the events that happened, if the work went according to plan
• Identifying ways to communicate negative events that have occurred (i.e. when something went wrong)
• A way to negotiate exceptions. For example, how to agree on the impossibility of updating the OS under some specific software, and even so that, on the one hand, you do not try to update the OS every week, and on the other hand, remember that the problem exists – it was simply postponed for later.

How to choose the right cloud provider

In practice, the client needs to choose a cloud that provides a sufficient level of quality, performance, and compliance with the necessary information security requirements. And with the latter, there are a number of tricks. They are easier to describe with examples.

PCI DSS standards are quite advanced. So clouds that meet these standards, all other things being equal, can be considered more secure.

Each of the standards has its own ways of confirming compliance.

Protection of personal information

Conformity can be confirmed in two ways: conformity assessment or attestation.

Compliance assessment can be carried out by a cloud provider independently (a less common option) or with the involvement of auditors.

As a result of the compliance assessment, the cloud provider brings its processes in line with the requirements for protecting personal data of the level of protection specified in the assessment and installs the required protections at the cloud level. Everything.

The main thing is for the client not to forget with such a provider to sign an order for the processing of personal data and to develop his own security system “inside” the cloud along with the relevant documents.

Attestation is a separate procedure and is optional. During certification, first, the cloud provider independently, or with the help of special auditors, brings itself into compliance with the requirements for a certain level of security, and then a company with a special license again checks that everything is configured and described correctly – and issues a certificate.

The difficulty is that the attestation does not allow changing the attested cloud. And in case of changes in the cloud, the certificate must be received again.

Another difficulty is that if a client wants to certify his system (which, by the way, is not necessary at all), then the cloud needs to be certified. It will be very difficult to certify a system hosted in the cloud with a conformity assessment.

Payment card data protection – PCI DSS

PCI DSS describes the different types of companies covered by the standard and different levels of compliance.

Cloud providers fall into the “service providers” type, and Level 1 is relevant for the public cloud. It requires a certification audit.

As a result, the cloud provider must have the following documents:

• Certificate of conformity
• AOC document. This document describes which services of the provider have been certified.

This is quite important to understand because a certificate issued, for example, for a Co-location service (i.e. placing equipment in a data center) will not help a client placing virtual machines in the cloud in any way.

You also need to remember that S3 services, resource administration in the cloud, DBaaS, etc. – are all services separate from the cloud itself (hosting virtual resources), and they must be reflected in the AOC.

And before placing the systems, the client needs to sign an agreement on the division of areas of responsibility with the provider – this is a standard document for PCI DSS.

Confirmation of the quality of the provider own IS management system – ISO 27001

The standard is completely voluntary, and the scope of the certificate of conformity with the standard must necessarily indicate to which processes it is applied in each particular case. The provider chooses the processes that are brought into compliance on his own – and they must be indicated in the certificate.

Brief summary

The most important things:

• From a technical point of view, the provider provides two main parameters of the cloud: reliability and performance.
• From the point of view of information security, the provider can confirm compliance with some legal requirements for information security or standards.
• Also, from the point of view of information security, a provider can confirm the quality of their own security management processes using a certificate of compliance with the requirements of the ISO 27001: 2013 standard (the version of the ISO 27001: 2005 standard is, unfortunately, very outdated).