Security professionals are prone to delivering edicts about securing code in new dev projects, but what about the mountain of existing code that is already in production?
Both security professionals and stakeholders alike often overlook the huge amount of legacy code which imposes an unmeasured and unaccounted risk on an organization.
Some companies can have hundreds or even thousands of domains. Product specific domains and websites are often spun up during the release of a product, then they are left online indefinitely. Even if we imagine, hypothetically, that these websites had no security flaws the day they were put into production, over time many will metastasize into a risk-filled PR nightmare waiting to happen.
But how does this happen? Most security professionals now agree to the common wisdom that a site can be “secure” on the day it is put into production, but as time inexorably pushes forward, the risk associated with a site increases.
Specific mechanisms can introduce risk over time, including the following:
The threat landscape is continually changing, not only with particular attacks against applications, but against the language, encryption algorithms, even increasing computing power at the hands of your angatonists. For example, password storage best practices evolve over time. What seemed secure years ago may be demonstrably insecure today. Time and technology advances have armed attackers with cloud computing power and knowledge on the weaknesses of older algorithms.
Internal apps being externally exposed
This happens much more than anyone will admit. Websites developed for internal use are almost never developed to the same security standard as websites which are developed to be outwardly exposed. However, over time – due to mergers, acquisitions, partnerships, business pressures, and desires for greater automation – internal applications are exposed to the internet.
Applications that were written in older proprietary web platforms such as Microsoft Active Server Pages may be frozen in time – the language has been abandoned, which also may require older versions of databases, operating systems, web servers, web containers, etc.
Insecure/out of date frameworks and libraries
I’ve discussed this in previous articles, but the principle holds true for legacy applications as well. The libraries and frameworks that applications use can go out of date quickly. For example, the popular platform “Struts 2” has numerous publicly disclosed vulnerabilities as noted in the NIST National Vulnerability Database.
Now that we see how risk arises over time in all applications, how do we protect legacy applications?
1. Measure the risk in the legacy apps. All applications in your environment should be monitored for security considerations. Frameworks, libraries, platforms should be accounted for, and updated as needed.
2. Consider the fact that legacy applications will need monitoring, maintenance, and functional modifications and make sure the right resources are in place ahead of time. It shouldn’t be a scramble to determine who needs to update these apps. Having a team in place, or factoring in a given number of hours for your development teams to dedicate to legacy applications should be included in standard working procedure
3. Virtual patching using a web application firewall can be used to give your legacy apps some protection while the security changes are being made.
4. Ensure that you have a plan for decommissioning an application. Not all applications will have a relevant business use case at all times. Having a plan in place to determine how to take applications that are no longer useful to the business, will speed the time required to take these applications offline and further reduce the risks that these unused applications can pose to your organization.
Following these steps will help your teams to ensure that they not only have a clearer picture of all applications on your site, but also a clearer understanding of the potential risks they may pose and how to remediate those risks well ahead of time.