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 their 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 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 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 meta data characteristics the assessment team desires. The details about the assets (criticality, location, owner, etc.) means 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 a 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 end points 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 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 end points.
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 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 controls any need for a reboot. Because the detailed asset list shows 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 end point 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 end point 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.