- If your AI-generated code becomes faulty, who faces the most liability exposure?
- These discoutned earbuds deliver audio so high quality, you'll forget they're mid-range
- This Galaxy Watch is one of my top smartwatches for 2024 and it's received a huge discount
- One of my favorite Android smartwatches isn't from Google or OnePlus (and it's on sale)
- The Urgent Need for Data Minimization Standards
To Patch or Not to Patch in OT – That Is the Real Challenge
The objective of an organization when implementing cybersecurity controls is to eliminate risk, but this oftentimes involves settling for managing risk at an acceptable level. Each organization defines what that acceptable level is depending on several factors including the environment, the criticality of function, the asset type, etc.
There are many methods and techniques that an organization can then use to manage this risk. One of the most commonly used methods is patching. At the heart of it, patches are an element of an overall risk management program. As such, various sources must be taken into consideration in conjunction with the risk management process.
Patching as a risk management strategy is a lot more mature on the Information Technology (IT) side of cybersecurity than it is on the Operational Technology (OT) side. These two distinct worlds are converging into a paradigm that brings converged cybersecurity to the forefront. With this transition underway, it is only natural that we evaluate the use of successful IT cybersecurity strategies such as patching in the OT world. Though these departments have historically not had any reason to understand each other’s motivations or priorities, it is possible for IT and OT practitioners to agree and collaborate on ensuring the overall cyber health of their organization. Both understand the catastrophic consequences of not doing so.
A difficult balance
What do you think of when your mind goes to an OT environment? Is it all about old legacy machines and some specialized devices such as Programmable Logic Controllers (PLC), Servos, Variable Frequency Drives (VFD), RTUs and other remote IO devices? If so, you are almost right. But also remember there is a fair number of IT like assets in that environment, too. As a result, patching in the OT environment is not altogether a wrong or far-fetched notion. It’s just not a blanket one.
It is worthwhile to note that these environments are fairly static in nature and are designed and optimized to perform certain repetitive tasks. This is especially true in process and discrete manufacturing where production and uptime targets are very crucial and important. The adage “if it isn’t broke, don’t fix it” describes the attitude observed by most engineering and operation managers in such environments as well as informs the approach taken by maintenance. This attitude is also one of the primary causes of risk that threat actors can exploit as a means of breaking into your OT environment. Ironic, isn’t it?
In case you are not aware, most industrial (OT) environments operate processes and controls that form part of their intellectual property or “special sauce,” as it is often referred to in such circles. To get a bit technical, the engineering or operations manager will have you believe that within these controls are the recipes and batch data that cannot be shared outside the physical plant and that needs to be protected. Cyber risk poses a big threat to such intellectual property, a danger which is only compounded by the loss of productivity. Isn’t it ironic that one attitude says “don’t fix what is working,” while at the same time the same attitude is a contributor to growing risk in the OT environment? It is often a daunting task to reconcile the two.
To patch or not to patch
The first step to making that decision is to evaluate the feasibility of patching. Applying patches to the OT environment, which consists of industrial control systems (ICS), is a delicate balance that hinges on the benefit (security) of what this patch can provide versus the disruption (operational) it can cause.
For me, there is another, more important issue that we need consider: are these ICS devices patchable? If not, then why not?
Depending on the answers to these questions, and also driven by their set or operational and security priorities, asset owners may find themselves needing to upgrade these devices just because patches aren’t available for legacy. Even if fixes were available, asset owners might not be able to apply them due to the risk of these devices getting knocked out of service.
Additionally, these legacy ICS are insecure by design, and these patches cannot fix this fact. However, there is opportunity to apply patches to select ICS devices (which are more modern and patchable) as well as the range of IT assets in OT environment. How? One proposed methodology is to use the decision-tree approach.
The Decision Tree Approach
The ICS-Patch project was published with the intent to “assist ICS asset owners with the decision of what to patch when.” This project outlines two approaches:
- Risk-driven: This approach recommends that an asset owner makes a decision to patch or not patch purely based on the contribution that the applicable patch makes towards reducing risk.
- Automation-driven: By eliminating human decision making on what to patch and when, this automated approach will determine and recommend the best available security patch.
This project takes a look at a number of factors through the lens of possible decision points such as security posture change, exposure and safety (harm to or the loss of human life). ICS-Patch offers a decision tree to determine whether applying a security patch on an ICS cyber asset should be deferred, scheduled or applied as soon as possible (ASAP).
Each decision point in the tree helps move the ICS-Patch process closer to the patch application decision. This helps asset owners to address risk metrics and vulnerability management. ICS-Patch isn’t perfect, but it gives a good starting point for those organizations that are ready to tackle patching in an ICS environment with OT resource assistance.
Utilizing a strong asset inventory / asset management product is at the heart of the ICS-Patch guidance. Asset information gets fed into the decision tree to help guide you towards a decision. Knowing what you have in your OT environment, specifically the vulnerabilities that exist on these assets, is the first step towards developing a strategy to manage and mitigate risk. Once you have visibility of an industrial control system, you can start to put other protective controls in place and continuously monitor for threats that impact risk. I encourage customers to start here and work towards defining a three-year plan on mitigating risk while supporting operations.
Tripwire’s solution can address OT cybersecurity
For addressing asset inventory, Tripwire Industrial Visibility (TIV) is a comprehensive, industrial-focused solution for gaining visibility into what you have in your environment along with exposing risks that should be addressed. The solution provides a foundation for organizations to start gaining visibility so they can implement strategies such as ICS-Patch to mitigate risk. InfoSec’s, IT’s, Engineering’s and Operations’ goals can be supported with Tripwire’s portfolio of solutions that enable visibility to and protection from events that threaten safety, quality and productivity for mission-critical systems.
You can learn more about Tripwire Industrial Visibility here: https://www.tripwire.com/products/tripwire-industrial-visibility.