Means GOSPKA. Translate terminology
If you work in a company that falls under action No. 187-ФЗ (“On the Security of the Critical Information Infrastructure of the Russian Federation”), then you do not need to explain what GOSPKA is and why it is needed. For the rest, let us explain: GOSPKA decodes as the State System for the Detection, Prevention and Elimination of the Consequences of Computer Attacks Architecturally, it is a single geographically distributed complex of centers of various sizes, exchanging information about cyber attacks. Such centers are obliged to create all the companies that own the objects of the critical information infrastructure (such companies are called KII entities).
For quite a long time, the main document defining the principles of the functioning of the State BESPCA centers and their interaction with the higher center was the Methodological Recommendations for the Establishment and Operation of the State Breweries Centers, developed by the FSB. We have previously reviewedof this document and noted that the main focus of his attention was the construction of processes for managing incidents and monitoring the security of subjects of the State Administration for Antimonopoly Policy. But at the same time, this approach left a sufficiently large field for different interpretations of how much the tasks should be solved by the Center for State Social Policy and what tools are required for this. Recently, "Requirements for the means intended for detecting, preventing and eliminating the effects of computer attacks and responding to computer incidents." Let's try to figure out what the regulator is waiting for from companies that build GOSPKA centers, and investigate this issue.
Hierarchy of interaction between the centers of the State Bureau
There have been known attempts to build centers of the State National Bureau of Antimonopoly Policy on IDS-systems exclusively. There are also vendors on the market that position IDS or SOA as a universal solution to a problem. The subjects of the CII had a lot of questions regarding the functionality and requirements for SIEM systems, which many companies considered almost the only tool needed to create a GOSEPA center.
Now, with the advent of the document Requirements for Means for Detecting, Preventing and Eliminating the Consequences of Computer Attacks and Responding to Computer Incidents, the first clarity arises with regard to the actual requirements of the regulator to the tools of the center.
The document identifies the five main subsystems of the GosSOPKA center:
Let's try to go through each of the items in sequence. Immediately make a reservation that the issues of "Orthodoxy" of the product and the need for import substitution are not considered here, we will deal exclusively with technical aspects.
In our opinion, this item is one of the most important from the point of view of resolving disputes about the means that can be used, since the discussion "whether you need a SIEM, or simply enough SOA subsystems" is ongoing and does not subside.
Let's take a closer look at the document:
First of all, we are talking about a tool that collects information security events. Not incidents (the outcome of the work of the remedies), not the raw traffic or a copy thereof, but events. This gives us a fairly clear hint that log processing is needed.
The note to this item also contains a fairly detailed and broad list of potential sources that should give these events. The list included not only classic security tools (firewalls, SOA, antiviruses), but also infrastructure sources (network equipment and operating systems), as well as applied control systems for network equipment, quality of service monitoring systems, etc.
All this, as well as the words “correlation and aggregation of events” mentioned in the functional requirements, in our opinion, quite accurately defines the target point technology as a SIEM platform .
This should be quite fully followed by the previously published methodological recommendations, because in order to fully identify computer incidents of the categories “unauthorized access”, “password selection” and “HPE”, one active remedy will not be enough.
Will any platform marketed as a SIEM be equally suitable? In our opinion, no, since the text still indicates at least two very important requirements:
Integrally, these requirements demonstrate a very serious attitude of the regulator to the functionality of the detection system. In my opinion, they indirectly make it clear that the formal execution of the implementation of guidelines (for example, “malware can be caught by network traffic, we do not need an antivirus” or “we just need to connect only two sources to meet the requirements”) are unlikely to have into existence. It will require serious elaboration of the threat model and work on setting up monitoring scenarios.
The next section, warning tools, is much closer and more understandable to the safety officer by both the formulations and approaches. The following functions are assigned to the means of warning:
The described list of functions is most often implemented by software products of the Vulnerability Scanner class or security scanners. It would seem that the non-obvious name “warning system” carries a very correct logic: it is impossible to prevent a potential attack development vector and identify weak points of the infrastructure if you do not have complete information about its condition, nodes used, program or process vulnerabilities of your assets.
The task of managing assets and vulnerabilities, for all the seeming simplicity, is fraught with a huge number of pitfalls. But a discussion of these details is not part of the current material and may appear in our future articles. I just want to note that almost all companies are equipped with the means required to solve the problem, since similar requirements have already appeared in various orders and orders of the FSTEC, and even in the law on personal data. The key task is to “revive” the existing tool and launch processes in reality, and not on paper.
Here both the name of the tool and the requirements for it received a rather unexpected interpretation. As a means of liquidation, we have a solution that is similar in functionality to the incident management platform, which in the IT world is called the service desk, and in the IB it is proudly referred to as the Incident Response Platform (although the IRP also has specialized functionality). In fact, the main tasks of the subsystem are:
Based on this, the functionality of the system and the name of the system are built. The elimination of the incident primarily requires the interaction of different departments of the company, and managing the liquidation process, monitoring its timing and completeness in this case comes to the fore. Therefore, the center of the State Bureau of Emergency Situations, as responsible for this process, must have the appropriate tools.
The choice of solutions and technologies created specifically for the tasks of information security on the market is still very limited. But in the document there are no direct restrictions on the use for this purpose of a common IT system (in standard or individual versions) with some modifications for information security tasks. Usually, the service desk systems are a highly customizable constructor, so revision should not be difficult.
The functionality and tasks of the KSPA subsystem are primarily aimed at analyzing network traffic, both in real-time mode (in order to detect attacks or attempts of unauthorized access to network equipment), and to record and store network traffic for its further use in retrospective analyzing an event or investigating an incident. These requirements are not fundamentally new. The task of recording network traffic has been posed to all owners of state information systems since 2010 as part of a joint order of the FSTEC and the FSB. These requirements may be unexpected for commercial companies, but in fact their implementation also poses no particular difficulties.
Requirements for exchange subsystems and cryptographic protection of communication channels are also quite familiar and, probably, do not require additional explanations.
As a short summary - the output of this document has placed a lot of points over I with regard to the tools and technologies that need to be equipped with the StateSNCA center. Now each customer has a formal list of requirements, which will be useful both for comparing vendors and for making decisions on the purchase / replacement of technology. And the appearance of clarity in such matters always positively affects the efficiency and speed of steps taken by specific subjects to connect, as well as the general security of critical information infrastructures.
For quite a long time, the main document defining the principles of the functioning of the State BESPCA centers and their interaction with the higher center was the Methodological Recommendations for the Establishment and Operation of the State Breweries Centers, developed by the FSB. We have previously reviewedof this document and noted that the main focus of his attention was the construction of processes for managing incidents and monitoring the security of subjects of the State Administration for Antimonopoly Policy. But at the same time, this approach left a sufficiently large field for different interpretations of how much the tasks should be solved by the Center for State Social Policy and what tools are required for this. Recently, "Requirements for the means intended for detecting, preventing and eliminating the effects of computer attacks and responding to computer incidents." Let's try to figure out what the regulator is waiting for from companies that build GOSPKA centers, and investigate this issue.
Hierarchy of interaction between the centers of the State Bureau
There have been known attempts to build centers of the State National Bureau of Antimonopoly Policy on IDS-systems exclusively. There are also vendors on the market that position IDS or SOA as a universal solution to a problem. The subjects of the CII had a lot of questions regarding the functionality and requirements for SIEM systems, which many companies considered almost the only tool needed to create a GOSEPA center.
Now, with the advent of the document Requirements for Means for Detecting, Preventing and Eliminating the Consequences of Computer Attacks and Responding to Computer Incidents, the first clarity arises with regard to the actual requirements of the regulator to the tools of the center.
The document identifies the five main subsystems of the GosSOPKA center:
- Detection Tools
- Warning tools
- Liquidation means
- Decryption Tools (PPCA)
- Information exchange tools
- Means of cryptographic protection of communication channels
Let's try to go through each of the items in sequence. Immediately make a reservation that the issues of "Orthodoxy" of the product and the need for import substitution are not considered here, we will deal exclusively with technical aspects.
Detection tools, but not SOA. Four letters
In our opinion, this item is one of the most important from the point of view of resolving disputes about the means that can be used, since the discussion "whether you need a SIEM, or simply enough SOA subsystems" is ongoing and does not subside.
Let's take a closer look at the document:
First of all, we are talking about a tool that collects information security events. Not incidents (the outcome of the work of the remedies), not the raw traffic or a copy thereof, but events. This gives us a fairly clear hint that log processing is needed.
The note to this item also contains a fairly detailed and broad list of potential sources that should give these events. The list included not only classic security tools (firewalls, SOA, antiviruses), but also infrastructure sources (network equipment and operating systems), as well as applied control systems for network equipment, quality of service monitoring systems, etc.
All this, as well as the words “correlation and aggregation of events” mentioned in the functional requirements, in our opinion, quite accurately defines the target point technology as a SIEM platform .
This should be quite fully followed by the previously published methodological recommendations, because in order to fully identify computer incidents of the categories “unauthorized access”, “password selection” and “HPE”, one active remedy will not be enough.
Will any platform marketed as a SIEM be equally suitable? In our opinion, no, since the text still indicates at least two very important requirements:
- The detection system should not only correlate and detect incidents, but also preserve the results of their processing and “information about information security events, including in their original form.” Considering the list of sources indicated above, as well as the recommended storage depth (at least 6 months), this is a full-fledged platform with enhanced Log Management functionality and the willingness to handle very significant event streams. This greatly reduces the list of potential options.
- The detection system should have “built-in support for various IS event sources and the possibility of developing additional modules providing information from new IB event sources”, that is, the possibility of promptly refining the list and the list of connected sources. This imposes requirements on the availability of an open API for the development of such connection methods (in SIEM-slang - connectors) or the ability to quickly obtain such a refinement from the vendor.
Integrally, these requirements demonstrate a very serious attitude of the regulator to the functionality of the detection system. In my opinion, they indirectly make it clear that the formal execution of the implementation of guidelines (for example, “malware can be caught by network traffic, we do not need an antivirus” or “we just need to connect only two sources to meet the requirements”) are unlikely to have into existence. It will require serious elaboration of the threat model and work on setting up monitoring scenarios.
Warn or inventory it.
The next section, warning tools, is much closer and more understandable to the safety officer by both the formulations and approaches. The following functions are assigned to the means of warning:
- Inventory of infrastructure assets with the ability to store and supplement information.
- Collection and evaluation of information resources vulnerabilities.
- Collection and evaluation of information on deficiencies (in our reading - configuration errors) of information resources.
The described list of functions is most often implemented by software products of the Vulnerability Scanner class or security scanners. It would seem that the non-obvious name “warning system” carries a very correct logic: it is impossible to prevent a potential attack development vector and identify weak points of the infrastructure if you do not have complete information about its condition, nodes used, program or process vulnerabilities of your assets.
The task of managing assets and vulnerabilities, for all the seeming simplicity, is fraught with a huge number of pitfalls. But a discussion of these details is not part of the current material and may appear in our future articles. I just want to note that almost all companies are equipped with the means required to solve the problem, since similar requirements have already appeared in various orders and orders of the FSTEC, and even in the law on personal data. The key task is to “revive” the existing tool and launch processes in reality, and not on paper.
Elimination as a joint work to eliminate
Here both the name of the tool and the requirements for it received a rather unexpected interpretation. As a means of liquidation, we have a solution that is similar in functionality to the incident management platform, which in the IT world is called the service desk, and in the IB it is proudly referred to as the Incident Response Platform (although the IRP also has specialized functionality). In fact, the main tasks of the subsystem are:
- Incident registration with the ability to edit and supplement the incident card.
- The ability to manage its life cycle with the transfer of the incident between the responsible and departments.
- The possibility of collecting the final card of the incident according to the formats approved by NCCI.
Based on this, the functionality of the system and the name of the system are built. The elimination of the incident primarily requires the interaction of different departments of the company, and managing the liquidation process, monitoring its timing and completeness in this case comes to the fore. Therefore, the center of the State Bureau of Emergency Situations, as responsible for this process, must have the appropriate tools.
The choice of solutions and technologies created specifically for the tasks of information security on the market is still very limited. But in the document there are no direct restrictions on the use for this purpose of a common IT system (in standard or individual versions) with some modifications for information security tasks. Usually, the service desk systems are a highly customizable constructor, so revision should not be difficult.
Other means of the center GosSOPKA
The functionality and tasks of the KSPA subsystem are primarily aimed at analyzing network traffic, both in real-time mode (in order to detect attacks or attempts of unauthorized access to network equipment), and to record and store network traffic for its further use in retrospective analyzing an event or investigating an incident. These requirements are not fundamentally new. The task of recording network traffic has been posed to all owners of state information systems since 2010 as part of a joint order of the FSTEC and the FSB. These requirements may be unexpected for commercial companies, but in fact their implementation also poses no particular difficulties.
Requirements for exchange subsystems and cryptographic protection of communication channels are also quite familiar and, probably, do not require additional explanations.
As a short summary - the output of this document has placed a lot of points over I with regard to the tools and technologies that need to be equipped with the StateSNCA center. Now each customer has a formal list of requirements, which will be useful both for comparing vendors and for making decisions on the purchase / replacement of technology. And the appearance of clarity in such matters always positively affects the efficiency and speed of steps taken by specific subjects to connect, as well as the general security of critical information infrastructures.