ASSESSING
Getting an accurate index of all your assets in the ICS environment.
This can be a manual process whereby you open each and every electrical cabinet, look inside every network closet and panel, and inventory every desktop in your production facility. However, an automated approach might be easier and more comprehensive while also less error-prone.
Tools such as the open source grassmarlin , or one of the paid-for ICS-specific Intrusion Detection System (IDS) solutions (CyberX, Claroty, Nozomi, Forescout, Indegy, PAS Global LLC) can passively index your assets by sniffing the network. Although these tools do a fantastic job, they can miss an asset if it is in a tough part of the network or somehow otherwise out of reach of the aforementioned tools (offline). I suggest using a combination of sniffing tools, an off-hours scan with a properly configured Nmap scan, and some elbow-grease work of manually inventorying and indexing to get the best results.
After you have made a list of all the assets you have in the ICS environment, details such as operating system version, firmware revision, patch level, software inventory, and running services on must be added to the list, as well as a criticality scoring and a value for the asset. A criticality scoring for an asset is a way to identify how important, valuable and integral the asset is to the overall production process or the survivability of the organization.
These asset details will help assess proper risk scoring and will ultimately allow for intelligent prioritization of risk mitigation.
After a list of assets with accompanying software, firmware, and operating system patch levels and revisions is assembled, the next step is to compare these revisions, versions, and patch levels against known vulnerabilities for them.
A manageable approach would be to run an automated vulnerability scan with Nessus or Qualys. An automated vulnerability scan is faster and often more reliable, as it can find—and sometimes even verify—a large set of known vulnerabilities, as well as check for common misconfiguration or default (weak) settings. Be warned that a vulnerability scan is intense and can cause ICS equipment to buckle under the additional network traffic. It is highly recommended to run a scan such as this during production downtime, though be prepared to verify the ICS equipment works as expected afterwards.
Now that we know what we have (asset list) and what is wrong with it (asset vulnerabilities), the next step is to see how likely the discovered vulnerabilities in our assets are to be exploited, and what the potential impact and consequence of successful exploitation would be. The process that helps us define this is called threat modeling. Threat modeling uses risk scenarios to define possible threat events and the impact and consequence of a threat event. For a threat event to be feasible, the following elements must be present: a threat source to carry out the event; a threat vector to exploit the vulnerability; and a target with a vulnerability. In a way, creating risk scenarios is about trying to predict where a threat is most likely going to target and strike.

MONITORING
Permanently monitor the plant pertaining to the cybersecurity threats, including the assessed and known vulnerabilities, as well as the previously unknown (day-one) threats. Analyze the historian data to look up the possible outliers and the discrepancies in the data flow, which might be an indication of an attack.

SECURING
Repeat the assessment of the vulnerabilities in permanent cycles and mitigate risks by securing the vulnerable spots in the ICS:

If the IEC 62443 standardization framework is taken as a reference the process will have the following structure:

1. Asset Owner is determining the targeted Security Level (SL).

2. IEC 62443-2-1 helps to assess and establish the cybersecurity policies for the asset owner. IEC 62443-2-4 helps to communicate these policies to the system integrators and component manufacturers down the line.

ALPHA will have to concentrate on these two regulatory frameworks in the first place. IEC 62443 provides Foundational Requirements (FR) to be met.

3. Every FR must be mapped to the corresponding System Requirement (SR) and Component Requirement (CR):

4. Dealing with the SL non-conformities:

ALPHA will ultimately derive the component requirements and system requirements from the foundational requirements under the consideration of the targeted security level of the asset owner and communicate those to the system integrators and product manufacturers down the line. Afterwards ALPHA will check the solution for the compliance with the relevant norm and the asset owner targeted security level.