SOC ABC OT. Why classic SOC won’t protect the process control system

It’s not a secret for anyone that the main experience and expertise in the SOC subject in Russia (and, in principle, in the world) is mainly focused on the issues of control and security of corporate networks. This can be seen from releases, reports at conferences, round tables, and so on. But as threats develop (we will not recall the set soreness of Stuxnet, but, nevertheless, we will not pass by Black / Gray Energy, Industroyer and Triton) and the regulatory requirements of the law “On the security of critical information infrastructure of the Russian Federation) the question of the need to cover the attention of SOC and the holy of holies of all industrial companies is the ICS segments. We made the first careful approach to this projectile about a year and a half ago (1, 2). Since then, there has been a little more experience and research, and we felt the strength to launch a full cycle of materials devoted to SOC OT issues. Let’s start with how the technologies and processes of the corporate SOC, which we have long been accustomed to, differ from the industrial SOC (things will come naturally to personnel issues). If you are not indifferent to the topic, please, under cat.

In order for the analysis to be substantive, we first 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 article, 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 the seemingly simple solution with an air gap, the situation for large federal companies with distributed facilities (this is especially important 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. Even 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 basic applications.

Therefore, how to properly decompose SIEM components by sites is a very serious question. We will return to it in one of our further materials, since the margin of this diary is too small to contain it there will be too much information for one article.

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. 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 AWP, the fact of detecting malware that requires mandatory investigation, etc.

Significant restrictions on the Use-Case operation 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 walk past the holy of holies – SCADA systems… If at the level of the information security system, operating systems and network flows, all the segments are at least slightly, 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:

1. Assemble the stand and check the success of receiving events
2. Draw a general architectural solution with all technical details
3. Agree it with the vendor in a few months
4. Check again at the customer’s stand with combat load emulation
5. 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, which 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.

Do not touch, it’s for the new year APCS, or Peculiarities of working with hosts and vulnerabilities in APCS

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 a severe allergy 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 unfortunate 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 APCS (in addition to manual control) is the previously mentioned network traffic analysis systems and industrial intrusion detection systems. Each new node, having appeared 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.

By 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 aggressive scanning and software verification to 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, not everything is 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:

• Network indicators (IP addresses, URLs, domain names) aimed at detecting an attacker’s interaction with the Internet to upload a payload to an infected host, compromise data through phishing, or connect a bot with a control center to transfer the host under the attacker’s control. If we are talking about a truly isolated segment, such connections will fail by default, and attackers will not gain control of the potentially infected machine. Nevertheless, fixing such attempts and identifying, albeit not activated, “crazy” malicious utility in the critical segment of production is also very important.
• Host-level indicators (MD5-sum of the process, its name, changed when installing / running the registry branch, etc.), aimed at identifying signs of an attacker’s activity on a server / workstation during the launch / pinning of a malicious utility. Again, given the general usefulness of information in the mature ICS segment, there is little chance of launching this kind of utility. Antivirus software adapted for technological processes, as a rule, functions not even in the signature mode, but in the whitelisting mode, by default cleaning out everything suspicious that it encounters on the hosts under its control. And in exactly the same way – it is important to record the launch of “strange” utilities on the hosts of the ICS segment. In this case, TI is used as an attribution tool for the attack vector and the attacker.

As a result, for attacks aimed at ICS, information on TTP, tactics and approaches of attackers, which is extremely rare in the TI market, and the tactics and approaches of attackers to an attack, which will make it possible to adapt defense mechanisms and approaches to monitoring and identifying threats in the segment, gains much greater weight.

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.