I’ve been pulled into discussions in social and in the OnRamp and Highway ICS Security training the past two weeks on which of the five NIST CSF Functions (Identify, Protect, Detect, Respond, Recover) should be prioritized in an ICS security program. The easy answer is all should be considered in a holistic manner (holistic being my second least favorite term in ICS security; second only to cyber hygiene).
Unlike cyber hygiene, holistic is not an improperly used or wrong term. Asset owners should approach their ICS security program in a holistic manner. My issue with the term is it is often used to excuse bad behavior … vendor: “yes, we have this awful vulnerability, but we aren’t going to fix it, and it shouldn’t be a risk if you implement a holistic approach”. Or holistic used by many organizations and roles to avoid making hard resource decisions or addressing significant risk related problems.
Over ten years ago an ICS asset owner client pushed us in an assessment to provide a list of the top 5 things they should do in 0 to 6 months and the top 5 things they should do in the next 6 to 18 months. The items had to be achievable in those time frames.
Our approach then, and continuing today, was to create a list of recommended actions that were selected and prioritized by efficient risk reduction. Meaning – where would the asset owner get the most risk reduction for the next dollar or hour spent on risk reduction? If the client was just starting their ICS security program it was very gratifying for the team to see how much risk reduction could be achieved with minimal effort with an efficient risk reduction approach and corresponding focus.
Of course in a perfect world you would develop and meet a target profile for all five NIST CSF Functions, Categories and Subcategories (holistic) that is in line with the company’s risk management program. This is where you want to get to. It is overwhelming, and often unachievable, to start with this, and early wins are important for both those doing the work and management.
So here are some thoughts of ordering and importance of the five NIST CSF Functions from an efficient risk reduction perspective.
1. Protect, when just getting started, is almost always the most efficient risk reduction. This typically begins with segmenting the enterprise from the ICS zones, some endpoint protection for mass market malware, and attention to remote access.
After the initial Protect controls are in place there is typically a drastic reduction in additional Protect controls contributing to risk reduction, primarily due to the insecure by design nature of the protocols and PLC/Level 1 devices deployed.
2. Recover should be, and rarely is, what needs to be addressed next. Many asset owners believe they are solid on the ability to recover due to redundancy. Unfortunately, a cyber attack will likely take out the primary and standby server or device since they are identical and interconnected. Recovery time objectives (RTO) should be set, approved by management, and periodically tested and proven.
The key here is you need to be able to recover the function / the process / the output, not necessarily all, or even any, of the cyber assets.
3. Identify: Asset Inventory would be next in this general analysis. We could debate what should be in that asset inventory. Vendor, sw/fw version, IP and MAC address, physical location and criticality would be a starting point. A lot of the other NIST CSF controls will leverage this asset inventory).
Additional Identify subcategories should be addressed as required to support the Protect, Detect, Respond and Recover subcategory activities. I must admit that how early to do how much in the Identify category is the question I struggle most with in this ordering. Some of it is based on how far Identify controls are in place for the rest of the organization. For example, if there is a well documented and functioning risk management program, then the Identify elements around ICS risk management are of great value. The converse is true if the executives are not managing non-ICS risk in a programmatic way.
———
Now this is where the current discussions often devolve into should I spend my resources on Detect or more Protect. My answer is Detect, after or in conjunction with Respond.
4. Respond is next. The benefits of Detecting an attack are significantly reduced if you have no plan to respond to this information.
5. Followed by Detect. In fact this could be 4a and 4b and done together. You will be modifying your Incident Response Plan as additional Detect capabilities are brought in. The main point is buying an ICS Detection product without an Incident Response capability for ICS is not wise. Because ICS Incident Response is a specialized skill that is not commonly needed, I have written that the detection vendors will offer this as a service, and this service may be more valuable to the asset owner than the product.
6. Protect to move past insecure by design. There is more risk reduction achieved by spending resources Detect/Respond prior to trying to patch everything in ICS and other elements people put in cyber hygiene. The primary reason is the insecure by design nature in ICS makes the risk reduction of these labor intensive efforts very small.
That said, at some point in your ICS security program maturity, it is time to address the insecure by design issue. PLC’s are now available with signed firmware. Encrypted and authenticated ICS security protocols are becoming available. On a new system you will want to invest heavily in Protect up front if it is available. It is the legacy systems when the decision of accelerating upgrades, not always ‘forklift upgrades’ (EB), to address security is a more nuanced question.
———
One final and important comment on Efficient Risk Reduction. Don’t forget about the Consequence side of the risk equation. We have often found that as early as #2 above that consequence reduction is by far the most efficient risk reduction expenditure of resources.