Home / Blog / Zones and conduits, protecting our industrial network

Zones and conduits, protecting our industrial network

Posted on 06/21/2018, by INCIBE
Zones and conduits, protecting our industrial network

Background

The security in the industrial networks is highly subject to the different levels of the automation pyramid (ISA-95), ), as already shown in previous articles. This regulation created the basis for the IEC-62443, evolution of the ISA99, specifically the IEC-62443-3-2 "Standard addresses security risk assessment and system design for IACS", which introduces the "zones" and "Conduits" for a secure segmentation of industrial networks, applying defence in depth.

Security zones are defined in the standard as "groups of physical or logical assets that share common security requirements, which have clearly defined borders (physical or logical)". The connections among these zones are called conduits and must include security measures in order to control their access, resist denial of service attacks, prevent the spreading of any other type of attack, act as a shield for other systems in the network and protect the integrity and confidentiality of communications.

A security zone requires an objective security level (SLT), which is based on criticality and impact factors. The equipment of the security zone must offer a level of security provision (SLC) that must be equal to the SLT. If it is not, including security technologies and/or policies/procedures in order to compensate the lag must be necessary.

So, for example, if we have a system that includes several monitoring devices based on Windows XP/server 2003 (e.g. HMI, history, etc.), as well as multiple PLCs to perform local control functions, we will quickly realize that, if we include them in the same zone, the SLT should be the same for everyone. This is not logical and would imply inefficiencies in the security investment. In this case, the best solution is defining two different zones, one for the PLCs and another for the Windows equipment, interconnected by means of a "conduit" and focusing on securing each of these zones separately, as well as the conduit itself. Securing the conduit by means of a firewall, for example, already reinforces the SLC of each zone.

 

Zones and Conduits

 

Management of zones and conduits

The main goal of the separation of different elements within an industrial network, in zones and conduits, is to create a cybersecurity network architecture. This model of cybersecurity network architecture is not unique as it is based on guides to good practices, experiences and, above all, on the needs and limitations of each particular case, so that different approaches to secure architectures can coexist, even within the same company. Nevertheless, we must take into account at least a minimum number of zones and conduits for it to be considered secure, which are based on the ISA-95 automation pyramid, segregating the network in at least one "zone" for each level of said automation pyramid.

In the following picture, a possible architecture is represented (keep in mind that it does not have to be unique), which would provide a solution to a secure network architecture based on zones and conduits.

 

Secure architecture designed by means of Zones and Conduits

 

Zones and conduits must be defined in a document and must have a series of fields that define them, such as those explained in ISA-62443-3-2 standard. Some of them are:

  • Name or unique identifier of the zone/conduit
  • Logical limits
  • Physical limits, if applicable
  • List of all access points and all the assets involved
  • List of all types of data flows/protocols associated with each access point
  • Connected zones and conduits
  • Asset list
  • Assigned security level

The fields that define the zones or conduits are not standardised, but in some regulations or good practices, you can find some of the most representative ones, such as those that have been listed, even though these fields must be customised depending on the particular industrial environment.

The final document must be something deep and intense based on the own experience and the objective system of the analysis in question. For example, in a specific infrastructure, the devices identified within a zone may belong to different "areas of the company" (Systems area, telecommunications area, manufacturers area, operation engineers area, etc.). Accessing this information may be relevant when defining this zone. Therefore, regarding this particular case, you can create a series of specific fields to consider this information relevant for the system under study.

The result of this definition of zones and conduits is set forth in a document where all the elements identified in a previous risk analysis, within the industrial network, clearly belong to a certain zone and their communication flows are reflected in the corresponding conduit, if this Communication is done among zones.

Increasing security levels in a zone

There are several methods to increase security levels in zones, but the most important one is a proper design of the same. When we face too many protocols of communication among zones, that is, a conduit that is too extensive, we must consider whether the size of the area is really the right one.

In this case, the solution may be achieved by simply creating different "sub-zones", which group characteristics or risks and create, in this way, several different "sub-conduits" among said "sub-zones".

One of the solutions to monitor conduits is firewalls which, by means of access control rules, allow communication among zones or deny it. Generally, this kind of control enables constructing rules sufficiently granulated and specific for providing a solution to our demand. In order to carry out this type of rules as restrictively as possible, we must create the definition of this conduit as restrictive as possible. This will enable us to quickly transfer what was previously described in the definition of said conduit to the rules of the firewalls themselves.

For example, we identify an asset in a "zone" by its IP and its MAC, and within a conduit we allow SNMP traffic to manage said device from the SNMP-Traps administration and traffic network to the server that receives this type of messages, whose IP is known. In said conduit, allowing the input/output SNMP traffic by means of a rule in the firewall meet the permission requirements on said traffic, but does not meet the imposed restrictions.

Several rules must be created regarding the SNMP protocol, specifically for the IP and MAC: an exclusive output to the server IP, allowing SNMP-Traps type messages, and another that may enable SNMP traffic to be managed by the administration VLAN, as a much better approach to the restrictions imposed in said conduit. Subsequently, introducing specific changes will be easier if we lower the risk level and if we want that, in this conduit, this device only communicates by means of the secure version of SNMP, version 3. We must simply introduce this change in the specific rule, avoiding collisions with other devices by using more general rules.

But when more control of communications is needed due to face a critical infrastructure, for example, in order to strength the level of security we can use other types of network elements. Some elements, such as transparent firewalls, could be included in this area. By means of their specific characteristics and their capabilities to carry out DPI (deep packet inspection) these kind of firewalls can be a key for strengthening the level of security of the most critical industrial networks.

Another element that is interesting in the case of critical infrastructures is the data diode, which enables the flow only in one direction, being able to control a conduit between zones like, for example, between the DMZ and the internal network. Additionally, another security element can be added, such as a firewall, in order to raise the security level of outgoing traffic on said conduit, if necessary.

Conclusions

The design of a secure network architecture, using a model based on zones and conduits, is not a closed process, but must be considered as a cycle of continuous improvement. This cycle must always take into account the risk analysis and security policies that the infrastructure wants to adopt. We must iterate on these four elements, always as a continuous improvement, reducing the accepted risk, raising the requirements of the security policy and making the changes in the relevant areas and channels to absorb that improvement.

The last point that should be highlighted is that a series of audits must be carried out, either internal or external, that enable monitoring the access rules involved in each conduit. Likewise, audits on the devices within each zone must also be carried out, which will complement our defence in depth, raising the level of security of the entire infrastructure, in general.