With DevOps and automated CI/CD pipelines, developers can crank out value for customers at an incredible pace, but that’s a lot of new software for organizations to secure. Those who are lucky enough to have dedicated application security resources still struggle to keep up - they’re typically outnumbered by developers 100:1; and most organizations don’t even have that.
Fortunately, many teams are aware of this challenge and are taking steps to address it. DevSecOps and other approaches shift security earlier into the development process, and are gaining momentum and empower developers to “build security into” their applications.
What about the many applications that aren’t currently under active development? Most application inventories includes apps that may not have had a code change in years (if not decades). They certainly weren’t built using the best modern DevSecOps processes - and attackers know it! All attackers care about is gaining access - whether that entry may be through the front door or a disused side door. A neglected segment of an organization’s technology stack that is no longer monitored or cared for could be an attacker’s ideal point of entry.
Legacy apps are a part of any company’s growth story, whether an organization grows organically or through M&A. Some apps may just roll on in production, year after year, without any updates. Others may fall out of use as internal processes shift and those who designed the apps move on: either case creates potential gaps in the security perimeter.
Through M&As, an organization may inherit these types of problems, bringing a whole new segment of technology into the stack including legacy apps that no one has eyes on anymore. What organizations need to realize is that just because an app isn’t under active development or in daily use doesn’t mean it can’t represent risk to the business. Here are some best practices to ensure enterprises aren’t victimized by a legacy app-related security incident.
Maintain an accurate inventory of all applications - You can only start to address risk in legacy apps when you know what and where they are. It’s important to create and maintain a single catalog of all applications and application dependencies running in the corporate environment. List their name, technology stack, purpose, users, and who in the organization may have first-hand knowledge of their implementation (if such a person exists!)
Don’t forget third-party applications and components. Vulnerable third-party components are a common cause of breaches. This could be an arduous process depending on the size and age of your application landscape, but should only be needed once. Then be sure to employ good policies to keep it current.
Use Standards and Current Compliance Requirements - Do your legacy applications meet the GDPR requirements? Legacy systems and modern applications alike come under the same level of scrutiny and even if you’re not subject to GDPR, associations like the National Institute of Standards and Technology (NIST) establish security guidelines and regulations specifically to help organizations achieve sound security postures. Cross referencing legacy code against current compliance standards can be good method for identifying security flaws. It’s important to conduct a complete, top-to-bottom audit.
Address technical debt regularly and incrementally - Updating, monitoring and maintaining legacy apps takes time – especially if it piles up over months or years. It’s also among the least exciting work on developers’ plates. So rather than leave it until it’s too late (and developers who built legacy functionality have moved on to other roles), consider dedicating a portion of development time to ongoing technical debt and maintenance.
It could be a dedicated sprint that teams take turns owning, or it could be a small percentage of each teams’ sprints on a regular basis. However it fits, a little legacy love spread out is better than a big security nightmare in the future!
Implement Specific Security Policies for Removing Legacy Apps - Consider that not all applications will remain relevant to the business. As organizations grow, different workflows will develop, and different team members will become reliant on different applications. Schedule time to determine and sunset any applications that are no longer needed.
Just as consumers should be in the habit of deleting any applications that they don’t regularly use on their devices, organizations should also retire any apps that no longer serve a business purpose or are sporadically used by staff. If the business is not getting anything out of the application, it is simply a potential source of risk with no corresponding reward.
This extends to third-party applications, too. Many OS and other technologies have reached their end of their support period and no longer receive security updates, but they may host or otherwise support legacy applications.
Prioritize Full-Stack Security Observability - It is important to keep in mind that many of the apps an organization currently relies on may eventually become legacy apps in the not-too-distant future. Organizations that wish to protect themselves from being victimized by legacy app related incidents in the future should focus their time on establishing full-stack security observability today, so that they will be able to maintain insight into every aspect of the organization, even those that eventually fall into disuse.
A comprehensive security strategy has to include every aspect of the technology stack, even the disused and relatively unknown potential points of ingress. By following these guidelines, organizations will better understand the potential risk legacy apps pose, and how to protect themselves from these risks before they become problematic.