ICS Antivirus Protection for computer systems on Level 3 and below

When properly deployed and up-to-date, antivirus (AV) software is an important part of a defense-in-depth strategy to guard against…

ICS Antivirus Protection for computer systems on Level 3 and below

When properly deployed and up-to-date, antivirus (AV) software is an important part of a defense-in-depth strategy to guard against malicious software (malware) in industrial control systems (ICS), where applicable and tested. Antivirus (AV) is widely used in both ICS, Operational Technology (OT), and information technology (IT) systems since it is an effective defensive measure against malware.

In business IT environments, it is common practice to configure each AV client to update directly from the AV vendor or to update from the organization’s servers, located in a secured subnet within the enterprise network (which gets their updates from the antivirus vendor).

Following “best practice designs” for the ICS and OT networks, the ICS / OT and IT systems should be separated by an ICS/OT demilitarized zone (DMZ) at Level 3.5 of the Purdue Model, which should contain only the ICS servers that are accessible from the IT network. Maintaining separation between general IT and ICS systems makes keeping antivirus software up to date a little bit more complicated and requires a different antivirus update method.

The recommended secure network architecture for ICS places the antivirus, Windows Server Update Services (WSUS), and patch server(s) in the Plant DMZ (See figure 2) Level 3.5. In this architecture, each level should only send or receive traffic to a directly adjacent level through zones and conduits. This precludes the AV/WSUS/patch server from communicating directly with either the vendor antivirus servers (which are outside of the organization entirely) or the organization’s enterprise antivirus servers (which are normally in the enterprise network). See figure 1.

The different levels for updating AV servers and their (AV) clients.
Figure 1: The conceptual flow of AV updates to reach the AV clients

Restricting the flow of data only to adjacent zones complicates the antivirus update process, so a better method is needed:

A) One method is to download the updates from the vendor antivirus servers to a dedicated host, write the updates to removable media, and use that media to update the AV/WSUS/patch server. Although at first glance this method appears to be time-consuming, in practice, it is not. If the System Owner (SO) uses this method, it is important to take precautions to reduce the risk of introducing malware or compromising the ICS. This would include verifying that the update source is legitimate, that the hash values of the updates are correct, and that staff members handle distribution media securely. System Owners should also ensure that staff members handle media in accordance with the organization’s removable media policy and other guidance.

This method of transferring antivirus updates uses the following steps:

· Make certain you have updated and tested backups.

· Verify the source of the update.

· Download the update file(s) to a dedicated host (server or workstation).

· Scan the downloaded file(s) for malware.

· Verify the cryptographic hash of each downloaded file(s).

· Scan the removable media for malware or other unexpected data before use to verify its integrity. The safest options are to securely erase the removable media and reformat the drive with the appropriate file system (for flash or magnetic media) or to use a new CD or DVD (for optical media) for each update.

· Write the file(s) to the removable media. Dedicate this media exclusively for updates.

· Lock the media so others cannot write to it.

· Load the media into the test environment and verify that it has no adverse impact on the test system. The backups taken and verified previously might be needed in case of a catastrophic failure.

· Re-scan the media for malware or other unexpected data to verify that nothing transferred to the removable media from the test environment host.

· Install the update on a non-critical endpoint or segment of the system and verify that it has no adverse impact on the production system.

· Install the update on the remaining hosts.

· Monitor the system for any unusual behavior and verify the proper operation of the ICS.

· Schedule automatic scans. Pick a time when the system load is the lowest.

This method is common in air-gapped networks. While this method is more labor intensive than automatic chaining of updates, it is not prohibitively time-consuming.

B) Another method is to automatically “daisy chain” the updates. In this method, the update server in the DMZ automatically takes its updates from another server in the enterprise zone, which, in turn, automatically gets its updates from the antivirus vendor’s servers.

The verification of the update and its source, along with the testing of updates, is very important. Verifying the update requires more than merely checking the URL or the source IP address of the vendor; SO must also verify that each file used in the update is legitimate by verifying that the cryptographic hash for the file is correct.

An issue that arises from chaining automatic updates is that staff might not follow the organization’s change management process. For many products, automatic updates are convenient and easy to configure, which makes ignoring change management procedures very tempting for busy personnel. Since ICS environments are very sensitive and the impacts of downtime can be serious, it is important for personnel to follow strict change management procedures and update antivirus software when operations are minimally impacted. SO should require this as part of a facility’s regular maintenance.

The recommended secure network architecture depicts the AV/WSUS/ patch server as a single server hosting three separate virtual application servers. This increases the risk of a compromise of either the server’s operating system or the applications. If possible, these applications (AV/WSUS/patch) should reside on their physical own hosts, and the hosts hardened and traffic restricted.

Regardless of the configuration, there is always the possibility of incompatibility or constraint having an adverse impact on the system, so testing is prudent. It is also important to back up any production endpoint (if possible) before updating it. If there is an adverse impact from the AV update, it will be easier and faster to recover from it with a backup. SO should document the transfer and testing of AV updates as part of a comprehensive change management program that could be also used for vulnerability updates.

Testing is a critical step since AV updates (like vulnerability patching/updates) can adversely affect ICS environments; there have been cases where ICS applications have malfunctioned due to the installation or updating of antivirus software. Since antivirus scanning can significantly increase CPU and/or memory utilization, it can interfere with applications and processes on servers or workstations that have outdated or otherwise insufficient hardware. This is one reason why it is important to maintain test environments that closely approximate the production environments. Updates should be installed on a test system and the proper operation of the system checked for adverse impacts or anomalous behavior first. If there are no issues, deploy the update into production systems in order of least criticality. In each operational system, update non-critical assets first since any adverse impact would less likely interrupt or otherwise degrade operations. For example, update the backup HMI server before the primary HMI.

The purpose of updating antivirus software is to ensure a higher level of protection. The resulting higher level of protection reduces downtime and other adverse impacts that are the consequences of a compromise of the ICS. The method should be tailored to the environment to support both the operational and security needs of the organization, but it should always include verification of the updates, maintain separation of levels to support defense in depth, and provide adequate testing of each update.

Figure 2: ICS Network Design concept following Purdue Model and Zero Trust Architecture

If you’d like to learn more about ICS Antivirus Protection, contact us via the methods below! We’d be happy to answer any questions or to discuss further!

Contact Us

Twitter

LinkedIn

Our Website

Contact Us Form