Not so long ago, we conducted another assessment of compliance with the requirements of GOST R 57580 (hereinafter referred to as simply GOST). The client is a company that develops an electronic payment system. The system is serious: more than 3 million users, more than 200 thousand transactions daily. Information security is taken very seriously there.
During the evaluation process, the client casually reported that the development department plans to use containers in addition to virtual machines. But with this, the client added, there is one problem: in GOST about the same Docker - not a word. How to be? How to evaluate the security of containers?
It's true, GOST only says about hardware virtualization - about how you need to protect virtual machines, a hypervisor, a server. We turned to the Central Bank for clarification. The answer puzzled us.
GOST and virtualization
To begin with, we recall that GOST R 57580 is a new standard that spells out βrequirements for ensuring the information security of financial organizationsβ (FI). Among such FIs are operators and participants of payment systems, credit and non-credit organizations, operating and clearing centers.
From January 1, 2021, FIs are required to conduct . We, ITGLOBAL.COM, are an audit company that conducts such an assessment.
There is a subsection in GOST dedicated to the protection of virtualized environments - No. 7.8. The term "virtualization" is not specified there, there is no division into hardware and container virtualization. Any IT specialist will say that from a technical point of view, this is incorrect: a virtual machine (VM) and a container are different environments, with different isolation principles. From the point of view of the vulnerability of the host on which the VM and Docker containers are deployed, this is also a big difference.
It turns out that the information security assessment of VMs and containers should also be different.
Our Central Bank Questions
We sent them to the Information Security Department of the Central Bank (the questions are given in abbreviated form).
- How should virtual containers like Docker be considered when conducting a GOST conformity assessment? Is it correct to evaluate the technology in accordance with subsection 7.8 of GOST?
- How to evaluate virtual container management tools? Can they be equated with server virtualization components and evaluated under the same GOST subsection?
- Do I need to separately assess the security of information inside Docker containers? If so, what safeguards should be taken into account in the evaluation process for this?
- If containerization is equated to a virtual infrastructure and is assessed in accordance with subsection 7.8, how are the GOST requirements for the introduction of special information protection tools implemented?
Central Bank response
Below are the main excerpts.
βGOST R 57580.1-2017 establishes implementation requirements through the application of technical measures in relation to the following measures of the RFP of subsection 7.8 of GOST R 57580.1-2017, which, in the opinion of the Department, can be extended to cases of using container virtualization technologies, taking into account the following:
- the implementation of measures ZSV.1 - ZSV.11 for the organization of identification, authentication, authorization (access control) in the implementation of logical access to virtual machines and server virtualization components may differ from cases of using container virtualization technology. With this in mind, in order to implement a number of measures (for example, DIA.6 and DIA.7), we believe it is possible to recommend that financial institutions develop compensatory measures that will pursue the same goals;
- the implementation of measures ZSV.13 - ZSV.22 for the organization and control of information interaction of virtual machines provides for the segmentation of the computer network of a financial organization to distinguish between informatization objects that implement virtualization technology and belong to different security loops. With this in mind, we consider it appropriate to provide for appropriate segmentation when using container virtualization technology (both in relation to executable virtual containers and in relation to virtualization systems used at the operating system level);
- the implementation of measures ZV.26, ZV.29 - ZV.31 to organize the protection of virtual machine images should be carried out by analogy also in order to protect the base and current images of virtual containers;
- implementation of measures ZVS.32 - ZVS.43 for registration of information protection events related to access to virtual machines and server components of virtualization should be carried out by analogy also with respect to elements of the virtualization environment that implement container virtualization technology.
What does it mean
Two main conclusions from the response of the Department of Information Security of the Central Bank:
- measures for protecting containers are no different from measures for protecting virtual machines;
- it follows that in the context of information security, the Central Bank equates two types of virtualization - Docker containers and VMs.
The response also mentions "compensatory measures" to be applied to neutralize the threats. But it is not clear what these βcompensatory measuresβ are, how to measure their adequacy, completeness and effectiveness.
What is wrong with the position of the Central Bank
If the assessment (and self-assessment) use the recommendations of the Central Bank, you need to solve a number of technical and logical difficulties.
- Each executable container requires the installation of information protection software (ISP) on it: antivirus, integrity control, work with logs, DLP systems (Data Leak Prevention) and so on. All this is installed on the VM without any problems, but in the case of a container, installing an information protection system is an absurd move. The container carries the minimum amount of body kit that is needed for the service to function. Installing IPS in it contradicts its meaning.
- By the same principle, container images should also be protected - it is also not clear how to implement this.
- GOST requires restricting access to server virtualization components, i.e., to the hypervisor. What is considered a server component in the case of Docker? Doesn't this mean that each container needs to be run on a separate host?
- If for conventional virtualization it is possible to distinguish between VMs by security loops and network segments, then in the case of Docker containers within the same host, no.
In practice, most likely, each auditor will evaluate the security of containers in his own way, based on his knowledge and experience. Well, or not evaluate at all, if there is neither one nor the other.
Just in case, we add that from January 1, 2021, the minimum score should not be lower than 0,7.
By the way, we regularly post the answers and comments of regulators related to the requirements of GOST 57580 and the Regulations of the Central Bank in our .
What to do
In our opinion, financial institutions have only two options for solving the problem.
1. Refuse to implement containers
A solution for those who are ready to afford to use only hardware virtualization and at the same time are afraid of low GOST ratings and Central Bank fines.
Plus: it is easier to fulfill the requirements of subsection 7.8 of GOST.
Less: will have to abandon new development tools based on container virtualization, in particular from Docker and Kubernetes.
2. Refuse to comply with the requirements of subsection 7.8 GOST
But at the same time, apply the best practices in ensuring information security when working with containers. This is a solution for those who value new technologies and the opportunities they provide. Here, by βbest practicesβ we mean the norms and standards accepted in the industry for ensuring the security of Docker containers:
- host OS security, properly configured logging, prohibition of data exchange between containers, and so on;
- using the Docker Trust feature to check the integrity of images and using the built-in vulnerability scanner;
- we must not forget about the security of remote access and the network model as a whole: attacks like ARP-spoofing and MAC-flooding have not been canceled.
Plus: no technical restrictions on the use of container virtualization.
Less: there is a high probability that the regulator will punish for non-compliance with GOST requirements.
Conclusion
Our client decided not to refuse containers. At the same time, he had to significantly revise the scope of work and the timing for the transition to Docker (they stretched out for six months). The client is well aware of the risks. He also understands that during the next assessment of compliance with GOST R 57580, much will depend on the auditor.
What would you do in this situation?
Source: habr.com