Securing Legacy Devices at Risk

As we move into 2021, it’s only natural to embrace new trends in technology and security. However, it’s perhaps increasingly relevant to consider the older technologies that remain in use in many environments. Indeed, Legacy systems still power many mission-critical applications in high-risk industries like Aerospace (Yes, Some Boeing 747s Still Run on Floppy Disks), Defense, and Healthcare (Medical Device Security Stymied by Legacy Tech, Flawed Segmentation.)

While many organizations are quickly upgrading recently End of Life platforms like Windows 7, to Supported ones like Windows 10, many remaining systems lack a clear upgrade path, and simply cannot be replaced. This represents a valuable target for hackers, and a significant challenge for organizations and their IT staff.

When it comes time to confront these risks, Genian NAC can play a key role in identifying, avoiding and mitigating risk associated with Legacy Devices.

Identification and Classification

Genian NAC leverages proprietary Device Platform Intelligence to provide high accuracy, continual platform fingerprinting, and provides important contextual information including associated CVE’s and platform lifespan. Accurate results can often be obtained within hours or minutes of deploying Genian NAC, depending on how much traffic is being generated on the network. This can be the starting point for your threat avoidance and mitigation efforts.

create EOL groups

Risk avoidance and mitigation

After identifying your legacy systems, it’s important to consider if they have been updated to the most recent patch. Just because new patches are not being released by the systems maker does not mean that there is no update available for these systems. At least make sure your EOL systems have installed the last official update before support was ended. In some cases, third-party companies may offer ongoing security updates for the end of life systems, long after the system maker drops support. Lastly, practices such as hardening these systems by disabling any unnecessary features should also be utilized.

Next, utilize segmentation practices such as keeping vulnerable legacy devices in separate LANs or VLANs. This can help make them more difficult for attackers to find, and more difficult for a compromised system to find other vulnerable systems. This also makes it more likely for a breach or attempted breach to trigger your intrusion detection system, both because an attacker will need to do more network surveillance to navigate this environment and because you can set more specific criteria for what traffic is considered abnormal network traffic in these segments. Genian NAC includes a network anomaly detection feature with Virtual IP honeypots so you can easily add an additional layer of intrusion detection targeted at specific segments. Lastly this form of segmentation allows for you to utilize your existing Access Control List and Firewall solutions in your environment to control traffic ensuring only acceptable data is sent to and from your legacy devices.

In environments where legacy devices must be kept in the same segment with other devices, you can utilize the Genian NAC Agent to keep Windows and Mac systems locked to baseline secure configurations, and use ARP enforcement to grant least privilege access by controlling traffic at Layer 2, and filtering by Source/Destination, time of day, and protocol. These privileges can be assigned dynamically using mandatory, attribute based, role based or rule-based access control models.

Lastly, you can utilize Genian NAC’s Device Platform Intelligence in a second way to determine if one of your legacy systems has been compromised or is being impersonated by a network intruder, using the “Admin-Confirmed Platform” feature. Genians DPI uses active and passive scanning to determine a Node’s platform. An administrator can confirm this platform. If these scans results one day show a different platform (Windows Server 2000 begins behaving like a Linux machine), a platform conflict is recorded in the node information. Nodes with platform conflicts can be grouped, and blocked by an Enforcement Policy. This detected vs Admin-Confirmed conflict mechanism can also be utilized more specifically for OS (as detected by an agent) or for Node Type, which is a broader measurement, and less prone to false positive alerts.

As with any other Enforcement actions, external notifications can be sent to administrators and security systems by way of Syslog, Email, SMS, or SNMP.

Scroll to Top

We use cookies to help improve this website and enhance your browsing experience You can change your cookie settings at any time. • Privacy • Terms