For the analysis to be substantive, first we will fix that we are comparing the SOC OT with the structure of the monitoring center, which is implemented in our Solar JSOC.
Among other things, it will allow us to discuss these differences in the context of the tasks of the GosSOPKA center, which is also responsible for industrial segments.
Details about each level of the model can be found in earlier articles on infrastructure inventory , monitoring , Threat Intelligence ( 1 , 2 ), security control , personnel and processes.... In the current material, we will focus on the central block of Security Monitoring (the features of the response and investigation processes in the automated process control system will be in further articles).
Theater starts with a hanger, and SOC starts with monitoring
It seems that in the field of event monitoring, correlation and incident detection, everything is already defined and known. And even bridging the air gap to collect security events is a fairly tried- and-true topic . But, nevertheless, there are a couple of nuances that are definitely worth paying attention to.
General SOC architecture... Despite a seemingly simple solution with an air gap, the situation for large federal companies with distributed facilities (this is especially true for the power industry) is rather complicated. The number of objects is measured in thousands, often it is not even possible to place an event collection server on them, each of the objects is quite compact, but can generate significant information security events. On top of the described situation, the problem of communication channels is often superimposed, so narrow that at least some significant load on the transmission of events to the "center" begins to interfere with the operation of the main applications.
Therefore, how to correctly decompose SIEM components by sites is a very serious question. We will return to it in one of our further materials, since
Use-Case Specialization and Profiling . Even without touching on the topic of completely specialized scenarios that are relevant only for the ICS segment, it is worth noting that even standard incidents in the ICS have a completely different meaning and criticality. We are all accustomed to using Remote Admin Tools on a corporate network for a long time. But it is obvious that the criticality of such an incident, as well as, in principle, of successful communication with the Internet in a closed technological network, is enormous. The same applies to the installation of a new system service at a technological workstation, the fact of detecting malware that requires mandatory investigation, etc.
Significant restrictions on the use of Use-Case are introduced by restrictions on the implementation of information security systems (usually, technological segments are not very rich in them), and the use of outdated, legacy versions of operating systems (and technologists look at the installation of Sysmon with distrust).
Nevertheless, a very large volume of Use-Case of the corporate environment can be successfully applied to the ICS segment and provide a sufficiently high level of overall infrastructure control.
Well, it's hard to pass by the holy of holies - SCADA systems... If at the level of information security systems, operating systems and network flows, all the segments are at least a little, but similar, then when moving deeper, key differences arise. In terms of corporate networks and segments, everyone dreams of business monitoring and business application connectivity. And this process, although complex (the logs mutate and do not want to pretend to be CEF, normal information can only be obtained from the database, but administrators swear and complain about the slowdown), but generally implemented. In the technological segment, when connecting upper and middle-level systems, these problems are elevated to an absolute in connection with the space criticality of technological downtime. In order to take the first steps to connect the source, you need:
- Assemble a stand and check the success of receiving events
- Draw a general architectural solution with all technical details
- Agree it with the vendor in a few months
- Check again at the customer's stand with combat load emulation
- Very carefully (as in the joke about hedgehogs) to implement the solution into the production
Sadness, longing, business processes. And this despite the fact that, as a rule, the equipment of the APCS is characterized by sufficiently capacious, complete, understandable and high-quality logging.
But, fortunately (or by coincidence), usually a different approach can be implemented in the ICS segments. Most of the protocols in them do not imply encryption or masking of transmitted information. Therefore, one of the most common approaches for monitoring and parsing control commands is the implementation of industrial intrusion detection systems or industrial firewalls that allow you to work with a copy or actual network traffic and parse protocols and control commands with subsequent logging. Some of them, among other things, have a built-in basic correlation engine inside (saving us from the horror of normalization, categorization and profiling of events), but at the same time they are not a full replacement for the SIEM system.
, ,
Moving on. It would seem that the issues of inventory in the ICS network should be the least painful. The network is quite static, the equipment is isolated from common segments, making changes to the architecture requires a whole working project. A fairy tale about corporate networks - "Just fix the model and enter it in the CMDB." But, as usual, there is a nuance: for the ICS segment, the appearance of any new equipment is one of the extremely important signs of an incident or attack, and it must be identified without fail. And with all this, the classical methods of inventory (sparing modes of operation of vulnerability scanners) cause the most severe allergies among technologists, and even among security personnel of the automated process control system. It is not uncommon in a corporate network when even Inventory Scan in an unsuccessful mode at an unsuccessful time could “put” some specific application.Naturally, no one is ready to take on such risks in the automated process control system.
Therefore, the main inventory tool in the automated process control system (in addition to manual control) is the previously mentioned network traffic analysis systems and industrial intrusion detection systems. Each new node, appearing in the network, begins to communicate with its neighbors. Both the methods and protocols of communication, the specificity of packets and service fields allow not only to quickly see the new “neighbor”, but also to clearly identify it.
In contrast, the process of identifying and managing vulnerabilities is more conservative. As a rule, the infrastructure is updated and patched infrequently and in a very controlled manner; the list of application software and technological equipment is fixed. Therefore, to determine the list and status of current vulnerabilities in the ICS segment, it is usually enough to determine the versioning of the key software and check the manufacturers' bulletins. As a result, we are moving away from the aggressive scanning and software verification mode to the methods of technical and manual versioning audit and analytics of an expert from the industry.
The process of analyzing or identifying threats is built in a similar way. As a rule, a one-time fixed model is modernized either upon the fact of a critical rebuilding of the infrastructure (adding new nodes, updating the firmware version of critical equipment, etc.), or upon revealing a new vulnerability relevant to the infrastructure and / or a new attack vector. However, with them, too, everything is not so simple.
OT Threat Intelligence or are isolated networks dreaming of indicators of compromise?
Could information about new threats and attack vectors be useless? I would like to immediately answer “no”, but together let's try to understand the applicability of classic TI data in the mature OT segment.
TIs are usually feeds (data streams) or IoCs (indicators of compromise to identify specific malware or hacking tools). They contain the following characteristics:
- (IP-, URL, ), upload «» , . , , . , , «» .
- (MD5- , , / ..), / / . , . , , , , whitelisting, , . – «» . TI .
As a result, for attacks aimed at ICS, information on TTP, tactics and approaches of attackers to an attack, which is extremely rare in the TI market, gains much greater weight, which will allow appropriately adapting defense mechanisms and approaches to monitoring and identifying threats in the segment.
These and many other nuances force us to take a very serious and thoughtful approach to the process of building such a SOC or the choice of a contractor, as well as to seriously think about the strategy for forming an OT SOC. Should it intersect with the SOC IT or function separately from it, is it possible for some kind of mutual enrichment and synergy in processes, teams and tasks to be solved. In our next article, we will try to highlight the different approaches of international teams to this issue. Be safe in all aspects of your infrastructure and life.