In a perfect world, we’d apply every security patch the moment it’s released. But we don’t live in a perfect world. The reality is, patching can be slow, and it’s often for very good reasons.
Maybe you’re running an industrial control system (ICS) where uptime is non-negotiable. Taking a system offline for an unplanned patch could halt production, making scheduled maintenance windows the only viable option. Or perhaps your organization has a rigorous validation process, requiring extensive testing to ensure a patch doesn’t break compatibility with other critical software.
Whatever the reason for the delay, one thing is certain: you can’t leave your systems exposed while you wait. The focus shouldn’t be on why you’re slow to patch, but on how you can actively defend yourself in the interim.
This guide will walk you through creating temporary, yet powerful, security measures by deconstructing recent real-world vulnerabilities and building a monitoring plan around them.
To make this practical, let’s look at a few recent vulnerabilities flagged by CISA that impact industrial environments. Two notable ones affect Rockwell’s FactoryTalk suite and provide an excellent backdrop for our discussion, as ICS networks are a prime example of where immediate patching is often not feasible.
The vulnerabilities in question included:
Improper Access Control: A flaw where a user with “read-only” permissions could potentially execute commands they shouldn’t have access to.
SQL Injection (SQLi): A classic vulnerability where the system failed to properly sanitize user input, allowing an attacker to manipulate the backend database.
The permanent fix is straightforward: upgrade to a patched version of the software. For example, for the Rockwell vulnerabilities, the advice is to upgrade to a version beyond $8.31$. However, as we’ve established, getting to that “permanent fix” can take time due to maintenance schedules, vendor availability, or compatibility testing.
So, what do you do between now and then? You dig deeper.
When patching isn’t an immediate option, your goal is to achieve a similar level of security through “compensating controls.” This means understanding the vulnerability at a technical level and setting up targeted monitoring to detect and block attempted exploits.
Let’s use the Rockwell FactoryTalk vulnerabilities as our guide.
First, we need to know what we’re working with. A quick look at the FactoryTalk documentation reveals its core components:
Operating System: Runs primarily on Windows Server (from Server 2012 to 2019). This tells us that Windows Event Logs and native Windows protocols are in play.
Database: Utilizes Microsoft SQL Server. This is a critical piece of information. It means we can focus our efforts on SQL-related protocols and logs.
Software Dependencies: The environment likely includes components like Microsoft Office, IE11, and the .NET Framework.
Knowing this stack (Microsoft OS, MS SQL, .NET) gives us a concrete list of technologies we can monitor.
Since we know we’re dealing with a Microsoft SQL Server backend, we can zero in on its specific communication protocol: Tabular Data Stream (TDS). TDS is the protocol that applications use to talk to an SQL Server database.
The good news is that TDS is a well-understood protocol. Network analysis tools like Wireshark (and its command-line-interface version, Tshark) include powerful TDS “dissectors.” A dissector is a component that understands a protocol’s structure, allowing you to see the actual SQL queries, responses, and function calls being sent across your network. This visibility is the foundation of our temporary defense.
Now that we can see inside the TDS traffic, we can look for specific, suspicious activities related to our target vulnerabilities.
For the Improper Access Control Vulnerability:
The vulnerability report states that a user with read-only privileges could execute SQL statements. Here’s how to hunt for that:
Baseline User Activity: First, identify the normal user accounts that interact with the FactoryTalk database. In many ICS environments, this is a surprisingly small and consistent list.
Identify Read-Only Users: Within that list, determine which users should only have read permissions.
Hunt for Execution Attempts: With your baseline established, you can now monitor for anomalies. Using your TDS dissector, create alerts for when a designated “read-only” user attempts to run functions associated with execution or writing data (e.g., INSERT, UPDATE, DELETE, stored procedures like xp_cmdshell). Seeing a read-only account trying to execute commands is a major red flag.
For the SQL Injection (SQLi) Vulnerability:
The report notes a lack of input validation, allowing an attacker to write to the database. Here’s a monitoring strategy for that:
Baseline Queries: In stable environments like ICS, the number and type of legitimate SQL queries are often highly predictable. Profile these normal queries. Any query that falls outside this established pattern is immediately suspicious.
Look for SQLi Signatures: Scan TDS traffic for characters and strings commonly used in SQL injection attacks. This includes single quotes ('), double dashes (--), semicolons (;), and commands like UNION, SELECT, and EXEC.
Monitor Communication Paths: Note which machines and user accounts typically communicate with the SQL server. If a new, unauthorized machine or user account suddenly initiates TDS traffic, it warrants immediate investigation.
While network traffic analysis is powerful, it’s not your only tool. Don’t forget to leverage host-based logs. Correlating network alerts with on-device logs provides a much richer picture of an attack. Be sure to collect and analyze:
SQL Server Logs: These logs can capture failed logins, error messages, and executed queries directly from the source.
Windows Security & Application Logs: These can reveal suspicious process creation, service modifications, and other signs of compromise on the server itself.
By combining deep network inspection with host-based logging, you create a robust web of compensating controls. You gain situational awareness. While the vulnerability technically still exists on the box, you’ve effectively “virtually patched” it by building a system that can detect and respond to any attempt to exploit it.
This proactive monitoring approach bridges the critical gap between a vulnerability’s disclosure and its permanent fix. It ensures that while you’re waiting for that next maintenance window, you’re not flying blind. Remember, patching is the destination, but smart monitoring is how you stay safe during the journey.
Our products are designed to work with
you and keep your network protected.