Zero Trust, the concept of securing services and devices based on an implicit lack of trust, which can be applied to Industry 4.0, is a subject that is used in all cases in IT. It may seem that there is no longer a company, that does not use Zero Trust’s complete approach to security. However, the reality is not so bright.
What problems and challenges does Industry 4.0 pose in terms of security? We will provide answers to these questions below. They will be based on visible trends in the manufacturing industry, as well as lessons learned from Grandmetric’s safety audits.
Let’s start from the beginning.
The network at the production sites is made up of three main segments:
All these structures are linked by a data transport based on Ethernet and IP protocols. As the TCP/IP stack operates in each of the segments mentioned above. The known problems of classical networks, including the attack vectors, also become problems of networks where production is carried out.
What does that mean?
All these structures are linked by a data transport based on Ethernet and IP protocols. As the TCP/IP stack operates in each of the segments mentioned above, the known problems of classical networks, and within them the attack vectors, also become problems of critical networks, where production is carried out.
Problems of broadcast networks are most often related to the use of vulnerabilities or specifics of protocols, such as ARP, DHCP. In consequence, they lead to the possibility of using the so-called spoofing. Spoofing is the impersonation of other devices in a network by exploiting the information exchange mechanisms of Ethernet and IP networks. Such activities can lead to destabilisation of services through DoS/DDoS attacks, phishing or, in the case of OT networks, changing commands/orders, in which case we are dealing with MITM (Man-in-the-Middle) attacks. In the latter case, the attacker steals data by intervening in the exchange of information between the operators and the terminal device.
When discussing problems of Enterprise IT, we can talk about similar problems in the critical networks of manufacturing companies.
Whenever dealing with Industry 4.0, we need to be aware of further challenges imposed by general technological trends and, consequently, ensuring the security of infrastructure elements as a whole in an Industry 4.0 architecture.
These challenges may be related to:
All these challenges have resulted in the Zero Trust idea starting to appear increasingly in the OT network, which, in turn, has been operating in the IT Enterprise network for more than a dozen years now.
In a nutshell, the idea is that we trust nothing and no one in the context of our network, systems, and users, who want to connect to it. Our task, on the other hand, is to verify the exact context of such a connection within the type of device, where it is connected, and what permissions it may receive as a result.
There are three areas in this idea, where it should be applied:
Zero Trust is based on a few basic elements that need to be taken care of.
In particular, those are:
What is behind these terms, and what should we do to make our OT network operate
according to the Zero Trust concept?
Let’s try to answer these questions by exploring each of the four elements.
Visibility is all about being aware of what is going on in our network. Why is that so important? When there is an abnormality in the network, and insights into the network are lacking, we cannot locate the problem or know its cause. As a result, we cannot promptly respond and take action to ensure the security of our network.
We can see what is happening in the network, for example, using sensors embedded in Industrial Ethernet devices. Their job is to report what they see to a central system, such as Cisco Cyber Vision. This allows us to see the relationship between the different devices and the communication between them. In the next step, this can be used to properly isolate devices or segment the network.
Another element that allows you to define the security of end device connections is compliance with the defined policy. Why is this important?
When an unidentified device connects to our network and is not compliant with our policy, or its software is vulnerable, it should be denied. This is how Endpoint Compliance works.
This element has two key distinctions. The first of them is Common Vulnerabilities and Exposure (CVE). This is a classification and description of known threats associated with a specific device or its firmware. It allows us to decide more accurately whether a device can operate in our network. The second distinctive feature is the Risk Score. It’s a parameter that determines the level of risk associated with the connecting device.
When mentioning OT networks and the idea of Zero Trust, we cannot overlook segmentation. In practice, it consists of isolating individual network sections and then defining the permitted communication between each segment. Most often, a segment is a group of devices that naturally communicate with each other. Segmentation naturally isolates devices in individual zones that do not need to communicate with each other. Such an approach reduces the probability of an attack spreading to the entire network if one segment is compromised.
The fact that we know what is happening in our network, and that we only include devices that comply with our policy, does not ensure that we avoid an attack on our network at all.
A system that implements Zero Trust should enable the detection of threats and then guide or assist in their elimination. When the system detects suspicious behavior in the network, it can respond and, for instance, cut the suspicious device off from the network.
In order to answer this question, we should start by asking ourselves, “what stage are we currently at? What does our network look like when we examine its security?” Our audits show that it is relatively easy to get unauthorized access to a wired or wireless network, which can result in serious security incidents. We know that OT networks are a critical area of manufacturing companies, yet their security remains at a relatively lower level than Enterprise IT systems.
Physical control of the premises is argued to be a better solution than logical security. However, during our audits, we observe that such control is carried out by a human operator, who acts (or not) according to a specific procedure. We have repeatedly demonstrated that physical protection is inadequate and that procedures do not provide for, say, social engineering attacks, resulting in infrastructure being effectively compromised.
Another element is the lack of segmentation. Sometimes this can be desirable, as segmentation is not a panacea in all cases. We also observe the lack of updating the systems used to control production and deliver services. The final element is the lack of monitoring activities within the OT/IT network.
Studies show that it takes more than a year from the time an attack occurs until the IT department is able to identify it (in the case of targeted attacks, such as ATP). In the meantime, the attacker can do a lot.
Often, the decision to implement a Zero Trust model also comes after an audit, during which we conduct a controlled attack that identifies a number of vulnerabilities. We have several scenarios prepared that show how easy it is to break into a network when you don’t protect the network, the users, or the data.
Based on our experience from audits and penetration tests carried out at production sites, we will show some examples of how a network or systems (including OT) can be successfully compromised.
Testing IT infrastructure is generally a process, in which there are no rules. This means that all methods (within ethical limits) leading to a certain result are allowed. Below, I have cited some examples of vulnerabilities and the train of thought that led to their detection.
Targets for one of the audits included checking the resistance of the Wi-Fi access network to unauthenticated connection, as well as the security of IT systems, including mail servers, hosted on-premise on the client’s network.
The testers saw a potential opportunity to use one of the devices – nota bene standing in the corridor of the protected area belonging to the process part of the building (OT) – as a candidate for a security breach attempt. It was a printer, one the one hand connected to an Ethernet socket, and the other having Wi-Fi enabled. As it happens, the Ethernet socket was dual (2xRJ45) and active. After connecting to a free slot, the tester got into the printer interface, getting administrator rights (weak password)! Scanning through the device’s settings, we obtained information on:
a) the Wi-Fi connection method (PSK), which made it easy for us to crack the shared key in about 15 minutes,
b) e-mail server settings,
c) existing users, logins, and e-mails within the company.
It turned out that, by establishing communication with the mail server, without additional credentials, using only the knowledge of the settings, we can send any messages. 2 objectives were met, but it became apparent after a moment’s reflection, that if we could send messages within the company mail, we could try to grant access to protected premises in the OT zone by preparing an appropriate message. Which we managed to do after about 20 minutes.
Interestingly, by penetrating deeper into the possibilities associated with the active Ethernet socket, another field of possibilities further opened up. When the network has a “flat” structure (no segmentation), in a few more minutes, we can obtain a list of hosts (devices) with their potential vulnerabilities. We can analyze this data and launch attacks on devices in OT, IT, and all, from which we are not isolated.
What else should we point to? In this era of mass deployment of IIoT devices and systems, we are increasingly seeing the use of PSK-protected Wi-Fi transmission. By knowing or extracting the shared key, we can attack applications within OT, IIoT, spoof devices and, for example, change parameters read by sensors that further cause specific outcome actions.
The consequence of failing to properly segment can be a relatively simple obtaining of information about all devices connected to the network (scanning). Moreover, an attacker can easily exploit this fact by sending several packets to impersonate a device used for communication, e.g. to important servers, operator stations etc. A Man-in-the-Middle attack, as this is the name of the above scenario, leads to the possibility of viewing, personalizing, changing messages, such as instructions to the PLC.
Another consequence of accessing the list of devices on the network without segmentation is the acquisition of CCTV device data, which may not necessarily be an end in itself, but will allow viewing and drawing conclusions needed in the next steps of taking control of infrastructure and procedures.
When carrying out pentester projects as part of our audits, in the vast majority of cases none of the users notice that we have been online for a while. Except, of course, for the insiders, who commissioned the “controlled intrusion”.
This is excellent evidence that we should monitor the strange, unusual things occurring in our network.
Examples of attacks continued
The company has an NFS – Network File System – server, which is used to store backups. Because the network structure is flat, we access it without additional permissions. There, we find a lot of confidential information for us to develop and continue our attack.
Another example is the execution of PHP code on a server, that allows us to extract passwords. It can affect both the SCADA server and other servers in critical areas, as well as services in the Enterprise IT area.
Another example would be accessing a Windows server from Active Directory. It was implemented from the guest room. It means that any guest “off the street” landing on the guest network can reach the AD server.
By the way, given this type of attack, it is worth remembering that many systems responsible for control in OT networks (Supervisors) run on Windows. In the event of an attack, it can be quite easy to take over administrative control of our server. Below is the PoC for Blue keep.
As we already know, Industry 4.0 poses considerable challenges for so-called automation and IT departments. If not addressed in time, could become critical to the functioning of the entire business. To take any action to ensure the security of our infrastructure, we first need to answer the question of where we are today, including what the state of our security is.
Once we have identified the state of our knowledge and security of our infrastructure, as well as the risks involved, we can begin to design and then implement the idea of Zero Trust. As we have shown in our material, the Zero Trust idea is able to overcome numerous challenges, and its postulates can be the foundation of the Industry 4.0 architecture.
Are Zero Trust solutions the same for everyone?
No. We must remember that this is not an “out of the box” solution. When deciding to implement the Zero Trust idea in our organization, we first need to analyze the feasibility from the perspective of our case: our production process, the systems functioning in our company, the business directions, in which our company is heading. It’s also worth being aware of how we work, where our workplace is, how our users, professionals, and contractors travel, and what this will look like in the near future. The outlined information is important, because every network is different, just as the nature of the businesses run is different. To implement Zero Trust, we need to know all the aspects that relate to and impact a secure IT and OT infrastructure.
Leave a Reply