In the process of evaluating, the client casually said that the development department, in addition to virtual machines, plans to use containers. But with this, the client added, there is one problem: in GOST there is not a word about the same Docker. How to be? How to assess the safety of containers?
It is true, GOST says only about hardware virtualization - about how to protect virtual machines, a hypervisor, a server. We turned to the Central Bank for an explanation. The answer puzzled us.
GOST and virtualization
To begin with, let us recall that GOST R 57580 is a new standard, which spells out the "requirements for ensuring the information security of financial organizations" (FO). These FIs include operators and participants of payment systems, credit and non-credit institutions, operational and clearing centers.
From January 1, 2021, FDs are required to assess compliance with the new GOST requirements every two years . We, ITGLOBAL.COM, are an audit company that conducts such an assessment.
GOST has a subsection 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 a different principle of isolation. From the point of view of the vulnerability of the host on which VMs 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 questions Central Bank
We sent them to the Information Security Department of the Central Bank (the questions are given in abbreviated form).
- How to consider Docker-type virtual containers when conducting GOST compliance assessment? Is it correct to evaluate the technology in accordance with subsection 7.8 of GOST?
- How do I evaluate virtual container controls? Can they be equated with the server components of virtualization and evaluated according to the same GOST subsection?
- Do I need to separately assess the security of information inside Docker containers? If so, what safeguards should be considered in the assessment process?
- If containerization is equated to virtual infrastructure and is assessed in accordance with subsection 7.8 - how are the GOST requirements for the implementation of special information security tools implemented?
Central Bank response
Below are the main excerpts.
“GOST R 57580.1-2017 establishes requirements for implementation by applying technical measures in relation to the following measures of ZI of subsection 7.8 of GOST R 57580.1-2017, which, according to the Department, can be extended to cases of using container virtualization technologies, taking into account the following:
- .1 – .11 , , ( ) . (, .6 .7) , ;
- .13 – .22 , , . ( , );
- .26, .29 – .31 ;
- the implementation of measures ZVS.32 - ZVS.43 to register information security events related to access to virtual machines and server components of virtualization should be carried out by analogy with respect to elements of the virtualization environment that implement the technology of container virtualization. "
What does it mean
Two main conclusions from the answer of the Information Security Department of the Central Bank:
- measures to protect containers are the same as measures to protect virtual machines;
- from this 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" that need to be applied to neutralize threats. However, it is not clear what these “compensating measures” are, how to measure their adequacy, completeness and effectiveness.
What is wrong with the position of the Central Bank
If you use the recommendations of the Central Bank in assessing (and self-assessing), you need to solve a number of technical and logical difficulties.
- Each executable container requires the installation of information security software (SSS) on it: antivirus, integrity control, work with logs, DLP systems (Data Leak Prevention), and so on. All this can be installed on a VM without any problems, but in the case of a container, installing an SZI is an absurd move. The container carries the minimum amount of "body kit" that is needed for the service to function. Installing an information security system in it contradicts its meaning.
- By the same principle, container images should be protected - how to implement this is also unclear.
- , . . . Docker? , ?
- , Docker- — .
In practice, it is likely that each auditor will assess the safety of containers in their own way, based on their knowledge and experience. Well, or not at all, if there is neither one nor the other.
Just in case, we add that from January 1, 2021, the minimum estimate must be at least 0.7.
By the way, we regularly post the answers and comments of regulators related to the requirements of GOST 57580 and the Central Bank Regulations in our Telegram channel .
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.
Cons: you will have to abandon new development tools based on container virtualization, in particular, Docker and Kubernetes.
2. Refuse to fulfill the requirements of subsection 7.8 of GOST
But at the same time - to apply the best practices in ensuring information security when working with containers. This is a solution for those who are more interested in new technologies and the opportunities they provide. By "best practices" we here mean the norms and standards adopted in the industry for ensuring the safety 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 in general: no one has canceled attacks like ARP-spoofing and MAC-flooding.
Plus: no technical restrictions on the use of container virtualization.
Minus: there is a high probability that the regulator will punish for non-compliance with GOST requirements.
Conclusion
Our client decided not to give up containers. At the same time, he had to significantly revise the scope of work and the timing of the transition to Docker (they stretched for six months). The client is well aware of the risks. He also understands that during the next conformity assessment with GOST R 57580, a lot will depend on the auditor.
What would you do in this situation?