Suppose I decide to use an outdated application for some reason: maybe I can't update it for compatibility reasons, or updates are not provided in the official repositories I use, or maybe I just don't feel like upgrading it because it just works and I see no reason to update it. For all I know, this application might be full of vulnerabilities that were only patched in later versions.

The question is: can I get infected by using such an application if its input data is trusted? For example, I'm not talking about a PDF reader that you can use to open random documents, maybe downloaded from the internet or sent by your friends, because that would be input data that you can't really trust. Imagine instead that you used that PDF reader only to open documents that you have written yourself (so it's trusted data). Or think of offline password managers, where password databases are supposed to be trusted (it's your data).

I'd guess it's safe to use an outdated application provided that the input is trusted and that it doesn't open any ports for communicating on the internet, but I'm not sure if I'm missing anything.

1 Answer 1


Good question. It depends.

If you are actually able to segregate this device from the rest of the network, then yes, it may be ok. For instance, you allow this device to only talk to its trusted sources, when those conversations conform to very specific, well-formed conversation parameters. You are referring to Critical Security Control 2.10 "Physically or logically segregating high risk applications."

This shouldn't be a first option. But, when legacy applications need to be run then the risk should be reduced as much as possible by logical/physical segregation. For instance. Don't run this application on the same box as anything else. Defiantly not a DHCP server, SQL database, or web server for obvious reasons. This app gets its own device (virtual or physical) and only gets to talk to trusted sources (OSI layers 2, 3 and 7) that are explicitly allowed.

A great many business need to run apps like this, and while this should be avoided if at all possible, there is a right way to manage the risk imposed by such an application.

The key is to know exactly what a legitimate conversation/interaction with this application looks like and impose strict technical controls that prevent anything outside a "known good" conversation. Know what inputs, devices, applications, conversation cadence, conversation length, session duration, OS services, users... are required to preform the specific function of the vulnerable app, and limit the permissions and controls to prevent any wiggle room. Have IDS alert on anything outside these parameters. Have local and network firewalls tuned to these parameters. Put the device on it's own VLAN. Have a dedicated, lowest possible permission user account for this app if you can.

Will that mitigate all your risk? No. You are using a vulnerable app. Will that risk be acceptable? Maybe. That's up to you and your CISO.

  • OP, does that answer your question?
    – sadtank
    Jan 22, 2019 at 19:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .