return
Day by day we think about security from several points of view, we evaluate a need and according to that need we implement as architects what we believe is most convenient in each case.
Sometimes we think about what would be more effective, according to the technology in which we operate, and we also say that the old perimeter-based thinking no longer serves us and we find that the list of strategies is getting smaller and smaller.
Some schools may point out that standards-based security is also one of the main reasons for a false sense of security, as it leads analysts into a comfort zone that in many cases is impossible to get out of. While the latter may be true, the reality is that standards help us a lot in creating processes, a well-used standard is a great tool to combat risks in all areas in which we operate.
It can be at the network level, at the application level and in different systems as well, but even more so in one of the areas that lately is attracting attention or in fact is starting to focus on security more frequently, we are talking about the industrial areas, more particularly the industrial areas that have the need to implement effective controls in their ICS systems.
In general, not too long ago there was a lack of standards regulating the designs and corresponding architectures focused on improving these areas. In this opportunity we will analyze how this lack of standards influences areas that are not focused on safety because their nature is associated with the operation technologies.
Improving the security of industrial control systems (ICS) usually involves a thorough risk assessment followed by a security assessment, both supplemented by reports detailing vulnerabilities, weaknesses and recommendations. Then comes a flurry of activity in the form of risk mitigation plans focused on determining which findings actually merit the investment needed for mitigation, mitigation plans that are utterly extensive and nearly impossible to follow. So this issue usually ends in an agreement with the relevant auditor or a gap compliance commitment. This level of approval has its benefits, but it tends to reduce the security issue to a focused list of findings that represent only a portion of the complete ICS security picture. After reviewing the findings, mitigation measures can take one to three years to complete, depending on factors such as current ICS security maturity, agility and available budget, plus the full operational cost of having to slow down activities completely because it is unlikely to have a testing platform equal to the productive one due to the complexity of some environments. By then, it is time for a complete re-evaluation.
The necessary improvements can be implemented, but what is missing in this approach is cohesion. Improving ICS security is not just about addressing weaknesses by adding security controls. Those controls must be carefully selected, complementary, and jointly support a clear understanding of how to prevent, monitor, detect, and respond to cybersecurity incidents within those environments. Improving cybersecurity in an ICS cannot be included in a simple sequential roadmap of phases. Ideally, depending on the security requirements and protection levels identified during the risk assessment process, the ICS should be segmented into security zones that can operate at different stages of maturity, like any solution that wants to improve a breach that has not been addressed particularly for quite some time.
IEC 62443 separates an organization with ICS into security zones based on risk assessment. The standard provides guidance on how to select the zones and assign the respective security levels (SL), in order to be able to apply those maturity phases discussed above.
Certain controls are required for each level, since an organization must evaluate the assigned levels in order to be able to apply security conscientiously at each stage of the analysis of the architecture to be evaluated. As with any standard, the corresponding gaps must be evaluated to see how far we are from the standard we want to impose in the area in which we are deployed. These zones or levels are associated with a Security Level range from 0 to 4.
Characteristics of the security levels
To achieve an optimum level of safety and to meet safety requirements, the SRs (System Requirements) are deployed based on the required protection against specific threats. The IEC 62443 protection levels are listed below.
Implementing these segmented levels, according to the requirements of the area, can make security solutions much simpler to implement. Since it is not the same to apply a level to the whole architecture (much more expensive), than to treat each part of our ICS independently to economize the efforts according to the risk.
When an organization separates its ICS environments into multiple zones, there is never absolute risk isolation between all zones, so a weakened zone can affect surrounding zones in two ways.
To assist in the definition of each SL (Security Level) the standard provides a definition of threats for each level where they can be visualized through a table that allows a dialogue on the more specific issues. The threat landscape differs depending on each sector, industry and type of organization. This standard provides us with solid definitions and a good place to start considering them as a good starting point to define the defense posture to be developed. Below is an example of mapping SRs from the fundamental requirements and their respective enhancements (REs) to the security levels.
Potentially, SLs could pose unique differences for each security zone, such as threats, operational changes and technology such as the Industrial Internet of Things (IIoT), which can change the attack surface of an ICS. SLs help set objectives, but these must be flexible and actively aligned to keep up with global changes in threats. No standard gives us an accurate picture aligned to the local conditions of each of the solutions associated with an ICS, we must always have the ability to adapt, which gives us versatility when it comes to switching between these surfaces.
It is also important to understand the role of the countermeasures that we can generate, for example when we look for a list of recommendations, we identify the opportunities and capabilities to expand the countermeasures in the near future where it benefits the rest of the zones, it is a bit the art of recycling the effort to avoid having an overload of work when remediating an ICS, everything we can do has to be sufficiently adaptable and malleable according to the environment and the rest of the mechanisms. This idea of how to approach the issue from a recycling point of view transforms the illusion of time savings into a net time savings, which is reflected in the day-to-day. Thus maximizing our return on investment.
Importance of Zones and Subzones
Each safety zone and the communication path between them (conduit) is assigned a target security level (SL-T). To achieve what the Standard considers a satisfactory safety level ("security level achieved" or SL-A), several contributing factors must be present. These factors must be taken into account when establishing safety zones and conduits, and their respective safety levels.
As we will see, an ICS can be segmented into security zones, but communication paths can leave residual attack vectors between those segments. This concept of naming each part of our system is a powerful concept that provides us with the necessary foundation for segmentation.
Because an ICS is a system of systems, depending on the industry in which it operates, it can be separated into smaller groups, physical systems, such as machines, application systems, , which carry out operational functions sharing operational risk, and information assets. A security zone can be located within these groups, sharing common requirements and creating imaginary boundaries that separate them. An ICS may be structured so that a small part, such as a boiler, requires a slightly higher level of security, but can otherwise benefit from the security level of the surrounding assets. For these cases, a sub-zone can be used. When segmenting, a security zone and sub zone are simply logical constructs of the operations of an ICS and should be considered outside the context of the actual physical network and components.
After reviewing and understanding the required communication paths between the security zones, this segmentation structure can be superimposed with the hardware and network of the physical control system, so that the controls are applied in that instance and the translation of the segmentation needs can be performed, and then a solution can be carried out according to the solved problem.
There are situations in which information must flow into, within and out of a security zone by means of communication. This also includes intermittent communications through programming terminals, mobile devices and removable storage devices, among others. The Standard refers to these communication channels as conduits, which can be identified as trusted or untrusted.
Communications within a zone are mostly recognized as trusted conduits. Untrusted conduits are communications coming from other security zones that are not at the same security level or that are made through a communication channel that is not at the same security level.
When modeling zones and conduits, there are a number of important rules that professionals should keep in mind. Here are a few of them:
In the following image, we can visualize examples of a correct and an incorrect configuration so that you can understand the difference between the two architectures.
For many organizations, segmentation can be a difficult process. That is why zones should be abstracted without focusing too much on the actual hardware and software. Only after applying the SLs should the ICS equipment (such as network equipment, PLCs, drives, computers, firewalls, services, protocols) be overlaid. This process will clearly show all the deficiencies of the shared hardware, network paths and software present in the environment.
That information can identify opportunities that help minimize the allocation of higher SLs in many areas, thereby reducing costs. Each environment is different, but the processes used may include the following principles:
Some ICS environments can be problematic because control systems can have a significant data relationship with enterprise information systems, creating an operational dependency that must accommodate wide security zones; a wide security zone implies greater monitoring. In addition to this, information systems tend to reside within the enterprise, making it difficult to create independent hierarchical zones for defense in depth. But nevertheless in these architectures, it can be useful to use switches with network access control to generate multiple sub-zones in existing and new environments that require such interaction.
Conclusion
Among other things, we must learn to refine our design tools, and improve our abstraction capacity when evaluating complex or seemingly complex environments such as ICS. Less complexity in the solutions leads us to understand the problem with a much higher scalability, with respect to complex systems.
Perhaps the time has come for the operation technologies to insert in their architecture processes, security professionals who open the way through the power of abstraction to simplify the solutions to their maximum possible expression aiming at the efficiency of communications in these areas. In response to this initial sentence, is standards-based security effective? It often helps to guide processes, but if we only apply the standard, it may soon lose its apparent effectiveness. So it should be our tool, but it should not be the only reference tool to solve problems.
