If IT (information technology) refers to systems that store, process and provide information in an organization, business, institution or factory, OT (operational technology) refers to control and safety systems and equipment involved in industrial processes. Most often, operational technology is an interface with the physical world and includes industrial control systems (ICS) such as control, surveillance and data acquisition systems (SCADA) and distributed control systems (DCS). Safetech experts have some recommendations on how to deal with cyber security within OT – operational technology environments.
The most important element is visibility, and for this, all connections to SCADA networks must be identified. A risk analysis is needed to assess whether all connections to the SCADA network are necessary and what risk each of them raises. All types of connections must be identified – local networks, extended networks, business networks, wireless networks, partner networks, connections to regulators, etc. because the goal is to figure out what can be done to protect them. This analysis will allow a comprehensive understanding of the role of each connection and the actual degree of protection it has.
After identification and inventory, we need to disconnect connections that are not necessary for the SCADA network, business process and SCADA network security. This is the only way can we ensure the highest level for OT systems, as any connection can involve a risk that we would rather not take. We also need to remove services that are not used on process networks, such as corporate email, file-sharing, internet access and other IT protocols.
At the same time, you need to be aware that security through obscurity is not real security, so we can’t rely on that alone. SCADA control servers are built on commercial operating systems, even when we talk about custom systems. They can also be built on open-source systems, which have elements that can be known by the attacker. As far as possible, we must remove and disable these unused services.
Some SCADA systems use unique proprietary protocols in communications between field devices and servers. Therefore, the security of these systems often relies solely on the secrecy of these protocols. It is important to understand that this kind of obscurity offers very little real security; proprietary protocols and default settings should not be the basis for our system protection.
Let’s not forget that suppliers can equip systems with service interfaces or back-doors to manage them. They should be changed because the attackers can know them too!
Another measure that needs to be implemented is to secure remote channels. These systems are connected to suppliers that perform various service operations so these channels must be managed and secured.
The physical safety of the equipment should not be neglected either; in particular, ports or cables are not allowed to be left unattended or connected in unsecured racks.
An insistent recommendation is that OT flows are integrated into the incident response streams and monitoring flows that the company has. In addition, SCADA networks and systems need to be audited a regular action, an activity essential for the continued effectiveness of security. In this regard, many security tools are available, both commercial and open-source, that allow system administrators and security officers to conduct audits of their systems and networks to identify active services, and correct problems and vulnerabilities. The use of these tools will not solve systemic problems but will eliminate the path of minimum resistance that would allow an attacker access. Identified vulnerabilities should be analyzed to determine how relevant they are and to take corrective action where appropriate.