Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

4/17/2019
02:30 PM
Tim Buntel
Tim Buntel
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Legacy Apps: The Security Risk Lurking in Dusty Corners

Four best practices to keep old code from compromising your enterprise environment.

A successful DevOps transformation empowers teams to release applications and add value for their organization faster than ever before. And now, with DevSecOps emphasizing early, integrated testing, security is being built into that high-velocity process. It's a tremendous improvement over past approaches in which security was tacked on to the very end of the development pipeline.

Still, many enterprises, even those with mature DevSecOps processes, tend to overlook a significant risk in their application portfolio: legacy apps that predate these improved processes. These application inventories include apps that may not have had a code change in years — and certainly weren't built using the best modern DevSecOps processes. Attackers know this and are happy to exploit it. 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 ingress.

These apps, lurking in dusty corners, might be used daily and no longer be under active development. Or they might be used infrequently, in forgotten production environments. Either way, they represent real risk for the business. The good news is that smart security teams that follow the four best practices below can mitigate the threats of legacy app-related security incidents.

Best Practice 1: Address "Tech Debt" Regularly and Incrementally
There's no escaping the fact that updating, monitoring, and maintaining legacy apps takes time, and, much like a sink full of dishes or a pile of dirty laundry, these tasks only become more time-consuming the longer they are put off. Rather than letting this "tech debt" become too daunting, it's worth considering dedicating a portion of the development team's time to reducing their maintenance efforts. This could involve the creation of a dedicated sprint team that takes turns owning this initiative or a by focusing a small percentage of each team's bandwidth on securing legacy apps and code on a regular basis.

Best Practice 2: Leverage Standards and Compliance Requirements
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 industry-approved frameworks can be a good method for identifying security flaws, making the security audit process a much less daunting task.

Best Practice 3: Maintain an Accurate Application Inventory
A critical step in addressing legacy app-related risk is establishing what apps are running on the corporate infrastructure. Start by creating a single catalog of applications and dependencies running in the corporate environment — including third-party apps and components. List each application's name, technology stack, purpose, users, and who in the organization may have firsthand knowledge of its implementation. This can be an arduous task, but if businesses employ policies to keep the inventory current after the initial lift, it's worth it.

Best Practice 4: Security Policies for Removing Legacy Apps
As organizations grow, workflows shift, and different team members become reliant on different applications. To deal with this constant state of change, IT and security teams need to implement a plan and process for reviewing the technology stack and sunsetting applications that no longer serve a business function. If the business is not getting anything out of an internal or third-party application, it is simply a potential source of risk with no corresponding reward.

A comprehensive security strategy must be just that: comprehensive. Modern businesses must account for every segment of the technology stack, not just those components being actively developed today. By following these guidelines, organizations will better understand the potential risk that legacy apps pose, and how to protect themselves from these risks before they become problematic.

Related Content:

 

 

 Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Tim Buntel is vice president of application security products at Threat Stack. Prior to this role, Tim has built globally-recognized software businesses for 20 years at startups, mid-sized companies in transition, and the largest global brands, including Atlassian, Adobe, ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
REISEN1955
50%
50%
REISEN1955,
User Rank: Ninja
4/17/2019 | 2:52:19 PM
And machines too
Every firm has a legacy system, one old Compaq Prolinea that has weird or ancient software installed on it 20 years ago that is used every 30 days to run a reel-to-reel data tape.  (Aon had one of those).  And those can be stuffed anywhere in a firm too.  So an inventory of these specific machines is important.  Another hole are special use machines like a UPS shipping computer.  Supported by God knows who and rarely updated with patch.  These little nuclear bombs are also scattered around in a dark department cove.   Lastly, and these are not turned on perhaps, just old old computers never thrown out. Not a direct threat but still, if disposed of, a hole out there.  
A Realistic Threat Model for the Masses
Lysa Myers, Security Researcher, ESET,  10/9/2019
USB Drive Security Still Lags
Dark Reading Staff 10/9/2019
How to Think Like a Hacker
Dr. Giovanni Vigna, Chief Technology Officer at Lastline,  10/10/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-4031
PUBLISHED: 2019-10-16
IBM Workload Scheduler Distributed 9.2, 9.3, 9.4, and 9.5 contains a vulnerability that could allow a local user to write files as root in the file system, which could allow the attacker to gain root privileges. IBM X-Force ID: 155997.
CVE-2019-17626
PUBLISHED: 2019-10-16
ReportLab through 3.5.26 allows remote code execution because of toColor(eval(arg)) in colors.py, as demonstrated by a crafted XML document with '<span color="' followed by arbitrary Python code.
CVE-2019-17627
PUBLISHED: 2019-10-16
The Yale Bluetooth Key application for mobile devices allows unauthorized unlock actions by sniffing Bluetooth Low Energy (BLE) traffic during one authorized unlock action, and then calculating the authentication key via simple computations on the hex digits of a valid authentication request. This a...
CVE-2019-17625
PUBLISHED: 2019-10-16
There is a stored XSS in Rambox 0.6.9 that can lead to code execution. The XSS is in the name field while adding/editing a service. The problem occurs due to incorrect sanitization of the name field when being processed and stored. This allows a user to craft a payload for Node.js and Electron, such...
CVE-2019-17624
PUBLISHED: 2019-10-16
In X.Org X Server 1.20.4, there is a stack-based buffer overflow in the function XQueryKeymap. For example, by sending ct.c_char 1000 times, an attacker can cause a denial of service (application crash) or possibly have unspecified other impact.