More and more users are bringing their entire IT infrastructure to the public cloud. However, in case of insufficient anti-virus control in the infrastructure of the customer, serious cyber risks arise. Practice shows that up to 80% of existing viruses live perfectly in a virtual environment. In this post, we will talk about how to protect IT resources in the public cloud and why traditional antiviruses are not quite suitable for this purpose.
To begin with, we will tell you how we came to the idea that the usual anti-virus protection tools are not suitable for a public cloud and other approaches to protecting resources are required.
First, as a rule, providers provide the necessary measures to ensure that their cloud platforms are protected at a high level. For example, we at #CloudMTS analyze all network traffic, monitor the security logs of our cloud, and regularly perform pentests. Cloud segments given to individual customers must also be securely protected.
Secondly, the classic way to deal with cyber risks involves installing an antivirus and antivirus management tools on each virtual machine. However, with a large number of virtual machines, this practice may be inefficient and require significant amounts of computing resources, thereby additionally loading the customer's infrastructure and reducing the overall performance of the cloud. This has become a key prerequisite for finding new approaches to building effective anti-virus protection for customers' virtual machines.
In addition, most antivirus solutions on the market are not adapted to meet the challenges of protecting IT resources in a public cloud environment. As a rule, they are heavyweight EPP solutions (Endpoint Protection Platforms), which, moreover, do not allow the necessary customization on the side of the cloud provider's clients.
It becomes obvious that traditional antivirus solutions are poorly suited to work in the cloud, as they seriously load the virtual infrastructure during updates and scans, and also do not have the necessary role management levels and settings. Next, we will analyze in detail the reasons why the cloud needs new approaches to anti-virus protection.
What antivirus should be able to do in a public cloud
So, let's pay attention to the specifics of working in a virtual environment:
Efficiency of updates and scheduled mass checks. If a significant number of virtual machines running traditional antivirus initiate an update at the same time, a so-called “storm” of updates will occur in the cloud. The power of an ESXi host hosting several virtual machines may not be enough to handle a flurry of the same type of tasks that are started by default. From the point of view of a cloud provider, such a problem can lead to additional loads on a number of ESXi hosts, which will eventually lead to a drop in the performance of the cloud virtual infrastructure. This may affect, among other things, the performance of virtual machines of other cloud clients. A similar situation can arise when starting a mass scan: simultaneous processing by the disk system of many requests of the same type from different users will negatively affect the performance of the entire cloud. With a high degree of probability, a decrease in the performance of storage systems will affect all clients. Such intermittent loads do not please either the provider or its customers, as they affect the "neighbors" in the cloud. From this point of view, traditional antivirus can be a big problem.
Safe Quarantine. If a file or document potentially infected with a virus is found in the system, it is sent to quarantine. Of course, the infected file can be deleted immediately, but this is often not acceptable for most companies. Corporate enterprise anti-viruses that are not adapted to work in the provider's cloud, as a rule, have a common quarantine zone - all infected objects fall into it. For example, found on the computers of company users. The clients of the cloud provider "live" in their own segments (or tenants). These segments are opaque and isolated: customers do not know about each other and, of course, do not see what others are hosting in the cloud. Obviously, a document containing confidential information or a trade secret can potentially be included in the general quarantine, which will be accessed by all users of the antivirus in the cloud. This is unacceptable for the provider and its customers. Therefore, there can be only one solution - this is a personal quarantine for each client in his segment, where neither the provider nor other clients have access.
Individual security policies. Each client in the cloud is a separate company whose IT department sets its own security policies. For example, administrators define scanning rules and scheduling antivirus checks. Accordingly, each organization should have its own control center to configure antivirus policies. At the same time, the specified settings should not affect other cloud clients, and the provider should be able to make sure that, for example, antivirus updates are running normally for all client virtual machines.
Organization of billing and licensing. The cloud model is flexible and involves paying only for the amount of IT resources that has been used by the customer. If there is a need, for example, due to the seasonality factor, then the amount of resources can be quickly increased or reduced - all based on the current needs for computing power. Traditional antivirus is not so flexible - as a rule, the client buys a license for a year for a predetermined number of servers or workstations. Cloud users, on the other hand, regularly disconnect and connect additional virtual machines depending on their current needs - accordingly, anti-virus licenses must support the same model.
The second question is what exactly will be covered by the license. Traditional antivirus is licensed by the number of servers or workstations. Licenses for the number of protected virtual machines do not quite fit within the cloud model. The client can create any number of virtual machines convenient for him from the available resources, for example, five or ten machines. This number is not constant for most customers, and it is not possible for us, as a provider, to track its change. It is not technically possible to license by CPU: customers receive virtual processors (vCPUs), which should be used for licensing. Thus, the new model of anti-virus protection should allow the customer to determine the required number of vCPUs for which he will receive anti-virus licenses.
Legal Compliance. An important point, since the applied solutions must ensure compliance with the requirements of the regulator. For example, often the "inhabitants" of the cloud work with personal data. In this case, the provider must have a separate certified cloud segment that fully complies with the requirements of the Law on Personal Data. Then companies do not need to “build” the entire system for working with personal data on their own: purchase certified equipment, connect it and configure it, and pass certification. To protect the ISPDs of such clients, the antivirus must also comply with the requirements of Russian legislation and have a FSTEC certificate.
We have reviewed the mandatory criteria that must be met by anti-virus protection in the public cloud. Next, we will share our own experience in adapting an anti-virus solution to work in the provider's cloud.
How can you make friends between antivirus and the cloud
As our experience has shown, choosing a solution based on description and documentation is one thing, but implementing it in practice in an already working cloud environment is a completely different task in terms of complexity. We will tell you what we did in practice and how we adapted the antivirus to work in the provider's public cloud. The vendor of the anti-virus solution is Kaspersky, which has anti-virus protection solutions for cloud environments in its portfolio. We settled on Kaspersky Security for Virtualization (Light Agent).
It includes a single console of Kaspersky Security Center. Light agent and security virtual machines (SVM, Security Virtual Machine) and KSC integration server.
After we studied the architecture of the Kaspersky solution and conducted the first tests together with the vendor's engineers, the question arose of integrating the service into the cloud. The first implementation was carried out jointly at the Moscow cloud site. And here is what we understood.
In order to minimize network traffic, it was decided to place an SVM on each ESXi host and “attach” the SVM to ESXi hosts. In this case, the light agents of the protected virtual machines access the SVM of the ESXi host they are running on. A separate administrative tenant was chosen for the main KSC. As a result, subordinate KSCs are located in the tenants of each individual client and access the superior KSC located in the management segment. This scheme allows you to quickly solve problems that arise in tenants of clients.
In addition to the issues with raising the components of the anti-virus solution itself, we were faced with the task of organizing network interaction through the creation of additional VxLANs. And although the solution was originally intended for enterprise clients with private clouds, with the help of engineering ingenuity and technological flexibility of NSX Edge, we managed to solve all the problems associated with the separation of tenants and licensing.
We worked closely with Kaspersky engineers. So, in the process of analyzing the solution architecture in terms of network interaction between system components, it was found that, in addition to access from light agents to SVM, feedback is also needed - from SVM to light agents. This network connectivity is not possible in a multitenant environment due to the possibility of identical network settings of virtual machines in different cloud tenants. Therefore, at our request, colleagues from the vendor redesigned the network interaction mechanism between the light agent and SVM in terms of eliminating the need for network connectivity from SVM to light agents.
After the solution was deployed and tested on the Moscow cloud site, we replicated it to other sites, including the certified cloud segment. The service is now available in all regions of the country.
The architecture of the information security solution within the framework of the new approach
The general scheme of how an anti-virus solution works in a public cloud environment is as follows:
The scheme of the anti-virus solution in the public cloud environment #CloudMTS
Let us describe the features of the operation of individual elements of the solution in the cloud:
• A single console that allows clients to centrally manage the protection system: run scans, control updates, and monitor quarantine zones. It is possible to set up individual security policies within your segment.
It should be noted that although we are a service provider, we do not interfere with the settings set by customers. The only thing we can do is reset the security policies to default in case a reconfiguration is needed. For example, this may be necessary if the client has accidentally tightened them or loosened them significantly. A company can always get a control center with default policies, which they can then configure on their own. The disadvantage of Kaspersky Security Center is that so far the platform is available only for the Microsoft operating system. Although light agents can work with both Windows and Linux machines. However, Kaspersky Lab promises that in the near future KSC will work under Linux OS. One of the important features of KSC is the ability to manage quarantine. Each client company in our cloud has a personal one. This approach eliminates situations where a virus-infected document accidentally gets on public display, as could happen in the case of a classic corporate antivirus with general quarantine.
• Light agents. As part of the new model, a lightweight Kaspersky Security agent is installed on each virtual machine. This allows you not to store the anti-virus database on each VM, which reduces the amount of disk space occupied. The service is integrated with the cloud infrastructure and works through SVM, which increases the density of virtual machines on the ESXi host and the performance of the entire cloud system. The light agent builds a queue of tasks for each virtual machine: check the file system, memory, etc. But the SVM is responsible for performing these operations, which we will talk about later. The agent also performs the functions of a firewall, controls security policies, sends infected files to quarantine, and monitors the overall "health" of the operating system on which it is installed. All this can be managed using the already mentioned single console.
• Security Virtual Machine. All resource-intensive tasks (updating anti-virus databases, scheduled scans) are handled by a separate Security Virtual Machine (SVM). She is responsible for the work of a full-fledged anti-virus engine and databases for it. A company's IT infrastructure may include multiple SVMs. This approach increases the reliability of the system - if a machine fails and does not respond for thirty seconds, agents automatically start looking for another one.
• KSC Integration Server. One of the components of the main KSC, which assigns its SVMs to light agents in accordance with the algorithm specified in its settings, and also controls the availability of SVMs. Thus, this software module provides load balancing for all SVMs of the cloud infrastructure.
Algorithm of working in the cloud: reducing the load on the infrastructure
In general, the antivirus operation algorithm can be represented as follows. The agent accesses the file on the virtual machine and checks it. The result of the check is stored in a common centralized database of SVM verdicts (it is called Shared Cache), each entry in which identifies a unique file sample. This approach allows you to ensure that the same file is not checked several times in a row (for example, if it was opened on different virtual machines). The file is rescanned only if it has been modified or the scan has been started manually.
Implementation of an anti-virus solution in the provider's cloud
The image shows a general scheme for implementing a solution in the cloud. In the control zone of the cloud, the main Kaspersky Security Center is deployed, and an individual SVM is deployed on each ESXi host using the KSC integration server (each ESXi host has its own SVM associated with special settings on the VMware vCenter Server). Clients work in their own cloud segments, which host virtual machines with agents. They are managed through individual KSC servers subordinate to the main KSC. If it is necessary to protect a small number of virtual machines (up to 5), the client can be granted access to the virtual console of a special dedicated KSC server. Network communication between client KSCs and the main KSC, as well as light agents and SVMs, is carried out using NAT through EdgeGW client virtual routers.
According to our estimates and the results of tests by colleagues in the vendor, Light Agent reduces the load on the virtual infrastructure of customers by about 25% (compared to a system using traditional anti-virus software). In particular, the standard Kaspersky Endpoint Security (KES) antivirus for physical environments consumes almost twice as much server CPU time (2,95%) as the light agent-based virtualization solution (1,67%).
CPU load comparison graph
A similar situation is observed with the disk write access rate: for a classic antivirus it is 1011 IOPS, for a cloud antivirus it is 671 IOPS.
Disk access rate comparison graph
Performance gains help maintain infrastructure stability and make more efficient use of computing power. By adapting to work in a public cloud environment, the solution does not reduce the performance of the cloud: it centrally checks files and downloads updates, distributing the load. This means that, on the one hand, threats that are relevant to the cloud infrastructure will not be missed, on the other hand, the requirements for virtual machine resources will be reduced by an average of 25% compared to traditional antivirus.
In terms of functionality, both solutions are very similar to each other: below is a comparison table. However, in the cloud, as the above test results show, it is still best to use a solution for virtual environments.
About billing within the framework of the new approach. We decided to use a model that allows you to obtain licenses by the number of vCPUs. This means that the number of licenses will be equal to the number of vCPUs. Antivirus can be tested by leaving a request .
In the next cloud topic, we will talk about the evolution of cloud WAFs and what is better to choose: hardware, software or cloud.
The text was prepared by employees of the #CloudMTS cloud provider: Denis Myagkov, lead architect and Alexey Afanasiev, information security product development manager.
Source: habr.com