This week we published the S4x19 video on three proposed revisions to the Common Vulnerability Scoring System (CVSS) for ICS vulnerabilities. It’s worth a watch and hopefully it will be one more trigger for ICS-CERT to earn the “ICS” in their title and add ICS intelligence to their work.
From an ICS owner/operator perspective, the Never, Next, Now approach to ICS security patching that Art Manion of CERT/CC presented resonated most with me. Perhaps because it is consistent with the ICS security patching advice we have providing that is often considered heresy when first heard by a CISO or IT security team.
Desktop and server security patching is time consuming, and ICS, or other mission critical IT, security patching takes even more resources due to the required testing and rollback procedures. While OT teams often overstate the impossibility and risk in patching ICS given system redundancy, there are devices that can only be patched during a planned outage.
The main issue or case against prioritizing ICS security patching in an ICS security program is a high percentage of security patches have a negligible, almost zero, reduction of a risk due to the still insecure by design nature of deployed ICS applications, devices and protocols. There are a growing number of ICS security audits that end with the key metric, often reported to executive management and even the Board, being patch status. The result is limited time and resources being squandered on this negligible risk reduction activity, and a false sense that the company has addressed ICS cyber risk. The goal should not be to see who can deploy and maintain the most good security practices in an ICS; the goal is to manage risk and mitigate risk where necessary.
The two things I like about Art’s approach are 1) It ties security patching to risk and 2) It is a simplified three tiered approach. Art presented a flowchart (see above) that asset owners use to determine if a patch should be applied Never, Next or Now. My guidance for the past five years has been a similar three-tiered approach.
Art: Now / Dale: ASAP
My recommendation is asset owners identify the attack surface accessible through the ICS security perimeter, and apply any security patches related to vulnerabilities in that attack surface as soon as possible. If you have a good security perimeter, this should be a small attack surface and subsequently result in a very small number of emergency security patching occasions.
Art’s approach requires more analysis, Patching Now is required if:
- An exploit of the vulnerability would lead to an inability or significant degradation to perform the mission, even though there is no evidence of a proof of concept exploit or exploitation occurring.
- There is proof of concept exploit code or direct evidence of exploits in the wild, and the vulnerability in an ICS computer or device has some or significant exposure to external networks.
The second bullet is related to my attack surface approach. The first bullet is likely going to lead to a lot of security patching of insecure by design devices and applications. It may make more sense in five years as early adopter asset owners finally get rid of insecure by design issues.
There is also question of what Now and ASAP mean in terms of time. I meant ASAP in terms of days or a week. The accessible attack surface from outside the security perimeter should not include anything that would cause a significant operational impact, so the rare problem generated through patching is less of an issue.
Art: Next / Dale: Quarterly
I recommend asset owners next identify anything that can communicate with the computers or devices in the previous / ASAP category, and patch these identified computers and devices in the next patch cycle. I’ve nominally recommended this as every quarter, and some asset owners do more frequently and others less. The key is whatever is selected is actually accomplished. It is a commitment not a goal. Some asset owners apply patches monthly and commit to, and are audited on, quarterly. In general, give yourself some room when you start out so you don’t begin with huge failure.
This selection is based on the likely attack path, from the corporate network to the accessible computer/device inside the security perimeter and then a pivot to the computer/device in this category. This also has ramifications for your security architecture inside the security perimeter for a more mature ICS security program. Small architecture changes can dramatically reduce the cyber assets and patching in this category.
Art’s Next category covers a lot of different cases. It is probably easier to identify what is outside the Next category. Next is everything except:
- Anything in the Now category previously defined
- Anything where the mission impact is little or none, and a combination of Exposure and Loss being little or some (the Never category)
Art: Never / Dale: Annual
This is the catch all for security patches that did not fall into the previous two categories, and it could be a substantial percentage of the security patches. This is actually cyber maintenance to prevent obsolescence rather than an action taken to reduce the risk of the security vulnerability. If there is a planned shut down every two years, then set this time period to two years. The key is to maintain the cyber assets, just like the physical assets are maintained.
Art defined the category in a similar way even though he admitted that the Never term could be misleading. It really is Never apply the patch to address the vulnerability risk, not never upgrade your software to address obsolescence issues.
Summary
Spend your time on mitigating and managing ICS cyber risk, not blindly applying checklists of security controls and practices.
Simplify your ICS security patching strategy by having a small number of categories, three seems good, that determine what security patches are applied in specified time frames. Two methods were described here. You can come up with your own.
Get internal buy off on this approach and have this be what you are measured on related to ICS security patching. Do this proactively by talking with and educating those that manage risk before the executive management has a different expectation for ICS security patching.