There is a new security risk in the form of remote desktop vulnerability. It is a Microsoft-related risk, and it requires a patch which many people loathe in OT environments. Let’s leave the ‘To patch or not to patch’ debate for another day and assume that patching these risks will be required at some point. Instead, let’s walk through what managing a cyber security threat looks like through two different operating companies.

One of the operating companies has a robust and fully functional OTSM program enabled by agent-based technology that provides a real-time, comprehensive inventory as well as the ability to take action on those endpoints. The other operating company is at the beginning of its cyber security journey and has no such central or coordinated capabilities to respond. Both companies have thousands of assets to sort through, dispersed among a number of geographically separated locations. They also both have a central supporting team ready and able to assist. But that is where the similarities end.

The relatively immature company is doing what many operational companies are in the thick of: They are sifting through any form of asset inventory they can get their hands on. Sometimes it is a relatively accurate spreadsheet of the asset type or OEM vendor, and other times, it is a list of IP addresses with some supporting content from a passive listening tool or network management inference.

In most cases, the full depth and breadth of assets and their underlying characteristics are relatively unknown. They rely on tribal knowledge to prioritize what to do first (which systems to address, how should we patch, where/when who should test patching). Finally, they manually connect (either remotely – hopefully – or in person) to ultimately update patches on those systems.

Many operational companies can use SCCM or WSUS to identify which OT systems require the patch, but that is a one-dimensional view without any operational context. Most WSUS/SCCM/Scan-based patching tools are not uniformly or completely deployed, and they often take additional time to inventory, deploy, confirm and update than an agent-based approach.

The process consumes many hours and diverts scarce staff from otherwise operational or process improvement tasks and projects for days and weeks until resolved – or at least until the risk level is reduced enough to appease a corporate appetite for risk acceptance.

So what is the alternative?  The second operating company with the agent-based OTSM platform.

 

Tackling cyber security risk in the form of remote desktop vulnerability:

Step 1 – Identify all assets with RDP risk

Assets can be identified with a simple click of the mouse in the enterprise roll-up. Assets are displayed with: Asset name, OS version, physical location, owner, criticality to operations, and any other asset-based or metadata characteristics the assessment team desires. The details about the assets (criticality, location, owner, etc.) mean a contextual risk assessment can be applied and will point to a true risk ranking or prioritization for this organization.

Bonus analysis: Because the assets also show their subnets, and the inventory tool enumerates firewall configuration rules, risk assessment or remediation at the communication level (i.e. disable RDP on the switch/router/firewall) can also be specifically targeted and managed.

Step 2 – Use the filtered list in scope of assets

To immediately improve security and buy time for the patching team to test and plan, use the filtered list of in-scope assets to send a command via the agent to the endpoints in order to disable the RDP service and/or close the RDP port. This, in conjunction with a company-wide communication about the temporary removal of RDP, effectively manages to protect the company and inform its operators of a change in the process during this security event.

Bonus: This setting can be set to ‘make it a policy’ which means the service/port disable command is enforced until you have finished patching or in lieu of patching if RDP is not needed on those endpoints.

Step 3 – Test the safe application of the patch

The core team or multiple teams at multiple sites per asset type or class should begin to test the safe application of the patch. The agent helps to deploy, install or rollback patches from the central team as well as track progress in all areas during this phase.

Step 4 – Begin roll out to all assets

Rolling out patching to all infected assets can be done in stages whereby certain asset classes are done at once, as a group, or one at a time. All possible deployment scenarios are supported by the agent/central reporting console through the use of conditional membership. This means identifying “If => Then” statements about an asset type (desktop, server, OS version, location) to create sub-groups of assets to target and manage a rollout along with safe operational needs.

Most importantly, the patch deployment is made to be an offer, meaning an operational (or other) human needs to be at the console of the end device to accept and oversee the installation of the patch. (

Bonus: A ‘do not reboot’ flag can be set so operations control any need for a reboot. Because the detailed asset list shows the location, you can give a laser-focused list of which systems are in scope and where they are located (building, floor, room, and rack) to speed up remediation.

Step 5: Track progress along the way

With inventory updates occurring in real-time, you can track the progress as you go. As the patches are deployed, the vulnerability count and assets in scope decline, providing real-time progress status.

 

Many companies struggle mightily with asset inventory and patching among many other endpoint management tasks. But it is cyber events or security risks like remote desktop vulnerabilities that provide ROI to motivate organizations to move forward and embrace endpoint management.

Next time you consider inventory, take time to consider the benefits of an agent-based approach in asset inventory for coverage and comprehension, as well as what the agent is capable of once you discover what you have.

Related Resources

Whitepaper

OT Endpoint Management Whitepaper

OT endpoint management is necessary to protect the world’s infrastructure, but it is often not deployed due to several key challenges. Find out how to overcome those hurdles.

Learn More
Whitepaper

OT Endpoint Protection Whitepaper

OT endpoint protection is necessary to protect the world’s infrastructure but faces many challenges. Find out how to overcome those hurdles today.

Learn More
Whitepaper

OT Systems Management Whitepaper

Achieving a mature level of OTSM is critical to improve overall ROI from increasingly connected industrial systems and to ensure foundational elements of OT cyber security are in place to protect critical infrastructure from targeted and untargeted attacks.

Learn More

Subscribe to stay in the loop

Subscribe now to receive the latest OT cyber security expertise, trends and best practices to protect your industrial systems.