See Part 1 with Levels 1 – 3. I must admit I switched the order of Basic Detection and eliminate High Consequence Events multiple times in writing this article. As always I welcome your comments including your own maturity levels.
Maturity Level 4: Basic Detection
Basic Detection should leverage existing cyber incident detection sources with a high signal to noise ratio. The type of signals that say if this happens we need to launch an investigation almost 100% of the time.
The first step is to deploy a detection/protection control for your Windows servers and workstations if you have not already. It is rare to see an ICS today without at least anti-virus deployed. Application whitelisting based solutions are better and ideal for many ICS that have few changes after deployed. Consider whether this is the time to deploy application whitelisting to your ICS Windows computers.
Then develop an automated process (preferred) or daily task to monitor the basic detection sources such as:
- Anti-virus / Application Whitelisting/ Endpoint Detection Alerts (even when the solution blocks something)
- New blocked egress (from the ICS outbound) communication patterns at your security perimeters.
- Repeated blocked remote access alerts.
- An account newly created or granted administrator or other high privileges.
You can add to this list. The criteria is if you get this alert or event you will investigate.
Maturity Level 5: Eliminate High Consequence Events
Security controls primarily reduce the likelihood of an incident caused by a cyber or cyber/physical attack. The consequence of the successful attack is the other side of the risk equation, and warrants attention at this point prior to putting in more security controls.
Can an attacker with access and administrative rights to your ICS or its network cause the high consequence event (HCE) via a cyber or cyber/physical attack? You should be able answer no to this question. If not, it is time to look at unhackable devices and systems, processes, recovery, alternate supplies and other solutions so this is not true.
While encouraged by INL’s CCE, Cyber PHA and other consequence efforts, I think these are only a start, and can be somewhat timid. My 2022 keynote, Security Truths and Consequences will focus on how consequence reduction, not more security controls, is the key to managing OT/ICS cyber risk. (will be given first at S4x22)
Maturity Level 6: Incident Response
The ability to recover in Maturity Level 3 is a big part, but far from all that is required, for incident response. Do you have an OT/ICS incident response plan and playbooks for a variety of scenarios? Have you gone through exercises to train on and refine these plans and playbooks? The early exercises are hugely revealing on false expectations and hard decisions that will be faced.
I’ve written a lot about the OT Detection market, and the most immediate benefit of this solution is its contribution of forensic data for incident response. More than giving you an asset inventory and much more than detection (because what good is detection if you can’t respond). It also is an opportunity to get a third party on incident response retainer who has expertise in the tool and OT incident response. Given the low level of required OT incident response and the expertise required, most asset owners will find it more effective (in cost and performance) to have an outside OT incident response team work with their engineers and OTsec professionals in the event of a real or possible incident.
I could go on with Maturity Levels 7 – 9, 10 – 12, etc. The ordering becomes much more asset owner / sector / ICS specific. The biggest gap between this list and what I commonly see in asset owners is they have bypassed Level 3 (RTO), Level 4 (Basic Detection), Level 5 (Consequence Reduction) and Level 6 (Incident Response) to focus on IT good security practices (cyber hygiene). It’s not that these security controls are bad or won’t work in OT. It’s just that they are not where your early focus should be on in effective OT/ICS cyber risk management.