By Scott Russ
Modernizing an antiquated application can have substantial business benefits. Sometimes these benefits come in the form of direct revenue generation because the updated platform is simply more efficient. Other times the benefits are more subtle. A modern application requires less maintenance, which has a trickle down impact on IT resource utilization and stakeholder satisfaction. These revenue and resource efficiencies very often serve as the drivers for businesses to uplift their outdated applications.
Compliance as a Driver
If the lure of better performance and less overhead hasn’t tipped the scales enough to take action on that legacy platform, security compliance certainly should. By the time an organization starts to analyze whether or not an application still meets security regulations, the situation is dire indeed. The very nature of regulation and compliance is inherently behind the times.
The Reality of Regulation
Regulation only occurs after an egregious risk appears and impels governing bodies to address it for the good of an entire industry. To explore this concept, let’s take an in-depth look at how regulation and compliance standards are determined in the security industry, and how this process played out for the vulnerabilities discovered in the first version of the transport layer security encryption protocol (TLS 1.0).
It all starts with a vulnerability. Somewhere out there, a flaw is discovered, exposing an application to a potential risk. The exposed risk could be as benign as ICMP responding on a system, or it could be as nefarious as allowing unauthorized root access. In our TLS example the flaw was first reported in 2011. Once a vulnerability is discovered, two actions typically happen simultaneously. First, the organization who developed the application addresses the vulnerability with a patch or an updated version. Of course this assumes the developer is still in business and supports the application, which isn’t always the case. In the case of TLS 1.0, the fix was to upgrade to TLS 1.1, which had already been around for 5 years when the TLS 1.0 vulnerability was discovered. Secondly (or simultaneously), after a vulnerability is identified, active exploitation occurs. Threat actors begin attacking the vulnerability in an attempt to gain unauthorized access into an environment.
After some time, it becomes apparent that exploitation of the vulnerability carries with it a significant risk. The risk is then large enough for governing bodies to take notice and start the process of creating regulation, which will force the users of an application to address it.
This initial regulation will go through many iterations before it is finalized. Its creators will debate the wording for quite some time to ensure it is comprehensive and sufficiently eliminates the risk. Once there is agreement among governing bodies, the regulation is finalized.
Organizations must be given ample time to react to the new regulation. There is usually a substantial compliance grace period to allow companies time to adjust without causing too much impact to their business. In our TLS 1.0 example, PCI regulation allowed organizations to continue using the flawed protocol until 2018 even though the risks had been known since 2011. How much does risk aggregate by ignoring a vulnerability for seven years?
As shown with TLS, the entire process, from the identification of a vulnerability through the compliance grace period, usually takes a few years. What does this mean for your non-compliant platform? It means that the application has been subjecting the organization to significant risk for a long time.
Modernization as a Risk Mitigation Necessity
There are many reasons to modernize a legacy application. Revenue generation and platform efficiency are examples of proactive reasons; compliance is reactive. If security compliance is a concern with any of your legacy applications, then upgrading is no longer a matter of convenience; it is a risk-reducing necessity.
Published on 01.21.20