Patch management in an operational technology (OT)/industrial control system (ICS) setting is full of challenges. From proprietary hardware and software to a lack of staff, inadequate or non-existent testing equipment, and regulatory reporting and system maintenance, many organizations struggle to determine what is in scope. This results in unmanaged patches.
What is OT/ICS patch management?
Software patching is often thought of as a basic cyber security process. On the surface, it appears to be a straightforward practice: simply apply updates to your OT systems.
The software updates are provided by the vendors that are intended to close any security or functional holes in your systems. This is so basic on paper that it is often overlooked or neglected by many security teams and system operators.
Patch management is defined as a comprehensive cycle of ensuring baseline data, identifying available patches and known vulnerabilities, reviewing patches for applicability and OEM-vendor approval, designing deployment or mitigation strategies, executing patch deployment and confirmation and re-establishing baselines.
But as it turns out, patching is not so straightforward after all. In fact, it is likely the single most time-consuming task that the North American power industry faces in adhering to regulatory expectations.
This is due to a combination of factors, most notably:
- Lack of automatic inventory/monitoring of end systems
- Difficulty in monitoring patch releases for all systems/applications
- Time and expertise to review, approve or mitigate patches in a workflow
- Testing and individually assigning patches to groups of endpoints
- Time to deploy on each device and confirm update working as appropriate
- Time to document changes and update baselines
Because of these patch management challenges, we created a six-step, end-to-end patching process. These will significantly reduce the time and complexity and improve the quality and compliance-readiness by integrating each of the critical steps in a single-flow process.
Six steps to effective OT/ICS patch management
Step 1: Establish baseline OT asset inventory
The first problem many organizations face is gathering a comprehensive asset inventory to understand what assets they have plugged in, where they are located, and what software is deployed. Some organizations have managed to compile a reasonable list of assets, either manually or through the extension of existing corporate tools or agent-based technologies.
However, almost all industrial operator networks struggle to connect on a regular basis (let alone automatically) to the non-Windows machines. In a typical operational network, these proprietary systems constitute up to 75% of all assets.
Step 2: Gather software patch and vulnerability information
The second challenge is the ability to monitor what patches are available and required. The core components of Windows, Linux, Unix, Office, and other products like Adobe are straightforward (either from Microsoft or the OEM vendor-approved MS patches). Third-party apps, however, usually require a manual review of the vendor’s website to look for new updates.
Operators need to research patches to determine what, if any, security components are addressed. The sheer volume of these apps makes the task exponentially difficult. In fact, one of our clients in the power industry is currently monitoring just under 300 third-party apps that fall into this category at just one facility.
But patch availability is only half of the equation. Effective patch management requires robust vulnerability assessment capabilities. Traditional IT tools with scan-based approaches are not effective and/or safe for OT/ICS systems due to the sensitive nature of the devices and their firmware
Therefore, a specific OT/ICS vulnerability assessment is required to use the data available from the robust software and asset inventory described above.
Step 3: Identify vulnerability relevancy and filter to assign to endpoints
One of the most challenging elements of patching is using the asset inventory to determine which assets should apply which updates – or filtering in other words.
Many companies gather lists of potential patches available for software, but linking it back to assets to ensure whether that particular patch is relevant becomes a logistical headache and labor burden.
Step 4: Review, approve and mitigate patch management
Many patch management processes end there and leave the approval and action to another set of tools or processes.
Step 5: Test and deploy vulnerability patches
Testing software patches in cybersecurity is often a luxury that clients do not have time to conduct.
Many people manage the administrative review and approval of patches then leave it to engineers to support and manage the deployment of the approved packages, allowing company staff to focus on their operational tasks instead of repetitive compliance tasks.
Step 6: Profile and document systems pre- and post-patching
One of the more tedious regulatory and managerial tasks related to patch management is the requirement to baseline systems before and after the application of a patch. Any changes to that baseline need to be captured and entered into corporate change management workflows in order to secure the new configuration and maintain compliance.