Since the acceptance of the various IEC62443 modules as national standards: SANS62443-2-1/4, SATS62443-1-1 and SATR62443-3-1, there has been confusion about the requirements, methodologies and implementation. In this we are not unique as similar confusion reigned when ISA99 (the precursor of the IEC standard) was introduced internationally.
Two aspects are causing particular concern:
• Implementation of a cybersecurity management system (CSMS).
• Risk assessment.
In the case of the CSMS, there are extensive application notes and papers available. This article addresses the second and arguably more frustrating aspect.
The rationale behind risk assessment
SANS62443-2-1:2016 indicates that the risk analysis should consist of two aspects. The first is the rationale that covers situation/risks specific to the business. The second is the risk identification, classification and assessment with section 4.2.3 detailing all the requirements, and this is exactly where most of the confusion arises. Once one analyses the requirements it can be condensed into the following key outcomes:
• A risk assessment methodology must be selected – it is not prescribed.
• A high level risk assessment is required.
• A detailed risk assessment is required after the high level assessment and prioritisation.
• The methodologies do not need to be the same.
• Periodic reassessment is required.
Unfortunately, in South Africa very few operators of industrial plants actually implement the risk assessment process for cybersecurity, and those that do, almost never go into the detailed assessment requirements. As will be explained, there are good reasons why both must be done.
The high level assessment establishes the baseline and should deliver the following outcomes:
• Establishing the ‘real estate’ – this means what equipment is being used/affected and having as much detail as possible.
• Get general information around vulnerabilities and support status of xthe equipment.
• Determine management/process gaps through an evaluation process. Addressing these gaps (policies, procedures training etc.) is not part of the risk assessment process and is typically handled by a separate team.
• Do preliminary system segregation (this is on a theoretical not actual implementation level).
• Determine the target SL (security level) per zone.
• Do preliminary prioritisation of zone security implementations.
There are numerous tools available to do this assessment and selection is very dependent on the type of industry. Both this and the detailed assessment require a comprehensive team to complete successfully. The SL determination is critical as it determines the minimum level of security controls that must be put in place. Since there are always limitations on security budgets, the prioritisation allows one to focus on the zones with the greatest impact.
A security zone will typically contain two or more systems. The detailed assessment allows for lower level prioritisation, specifically:
• System priority.
• Specific vulnerability priority.
Three steps to a structured approach
Unfortunately, unlike the high level assessment there is no single software tool to address the process and one needs to use a variety of tools and systems together, check and verify the information. It is also an iterative process where certain steps might have to be repeated multiple times as new information is uncovered. Much of the information gathered in the high level assessment will be reused. Detailed discussion of the process falls outside the scope of this article; however, Proconics uses a NIST800-82R2-based process that is shown below. It consists of three phases with sub steps in each.
Stage 1 – asset ID and characterisation: define business objectives (business rationale in SANS62443); system classification; asset ID; network topology and data flow; and risk pre-screening (optional).
Stage 2 – vulnerability and threat modelling: security policy review; standards audit and GAP analysis; industrial cyber vulnerability assessment; threat assessment; attack vector assessment; risk scenario creation; and scenario validation (optional).
Stage 3 – risk calculation and management: calculate quantitative (monetary/safety) risk; prioritise mitigation; and mitigation validation (optional).
In conclusion, it can be seen that while the SANS62443 suite can be daunting, if one follows a structured and complete approach it is possible to manage risks. The process described here is not perfect and will not guarantee a fully secured plant, but it does allow for continuous and incremental improvement in security deployment.
For more information contact Cobus Pool, Proconics, +27 17 620 9600, mail@proconics.co.za, www.proconics.co.za
| Tel: | +27 17 620 9600 |
| Email: | proposals@proconics.co.za |
| www: | www.proconics.co.za |
| Articles: | More information and articles about Proconics |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version