The challenge is that while many get excited about the new software when it’s installed, too few make long-term plans for removal at software end of life.
Federal agencies have a software accumulation problem. While they have countless options when it comes to selecting software, IT leaders routinely purchase and build out mission-specific environments and when those resources are no longer needed, they have to decide what to do. So what options do you have? Do you replace or do you remove? And, in either case, do you feel confident that you will be able to completely replace or remove? This question may not be as simple as it sounds.
The challenge is that while many get excited about the new software when it’s installed, too few make long-term plans for removal at software end of life (EOL), and most assume they can coast—especially when the tool’s contract duration is several years and the tool is operating as it was intended, complete with security patches. However, the federal procurement process can be quite extensive, requiring months or even years and can be fraught with other delays like award protests. Too often, this means that while software works great for the duration of the contract, if it reaches EOL before a replacement is acquired, the software can leave government endpoints vulnerable to cyberattacks. When coupled with the federal status quo of using data that’s often days or even weeks old, teams have limited ability to identify and respond to threats before they result in compromise or breach.
Instead of the status quo, teams should implement a modern tool rationalization approach that allows them to revisit their entire process. They should reevaluate priorities, validate installed applications are meeting mission needs, and proactively replace software with a platform instead of point solutions to ensure both security and mission sustainment—all while maintaining real-time visibility into threats and keeping networks protected. A chain is only as strong as its weakest link and vulnerable endpoints make vulnerable networks.
Unsupported Software Creates Unsecure Networks
As new technology replaces old, software reaches its EOL. Take Adobe Flash Player, for example. At the height of its popularity, Flash was installed on nearly 1 billion endpoints. That number has dwindled over the years with an increased reliance on HTML5 to deliver animation and interactive content. In December 2020, Adobe finally ended support for this product.
Once EOL occurs, support costs drastically increase and vendors discontinue patches and updates. Until the software is uninstalled, agencies’ endpoints are left open to critical (and noncritical) vulnerabilities that the vendor will not fix.
Unsupported software leaves government systems wide open for attack. When software is unsupported, it’s not a secret. Your attackers will know this and use this information in their attacks. Attackers will create and use zero-day exploits, vulnerabilities for which a patch does not exist, whenever possible. If software has a vulnerability that is not patched, it may have an exploit available that leaves your systems vulnerable to unauthorized remote access as long as the software remains in your environment. A window of vulnerability will eventually close, but this is not so with unsupported software. If you choose to continue running unsupported code, the only way to prevent zero-days from being exploited is by applying mitigation or standard defense in depth strategies—which does not guarantee success. And, any mitigation effort is only intentionally successful if you learn of the vulnerability and a mitigation technique. Unsupported code rarely goes through the same rigorous and continual security evaluations so it leaves more opportunities for attackers and less for agency employees.
After EOL, malware creators stand by and then aggressively target systems running old software the moment the opportunity presents itself—and they will likely target systems still running software they know will be vulnerable.
While the problems associated with EOL software are not unique to the federal government, the lengthy procurement and approval process to replace software systems compounds an already complex problem and creates potentially dangerous scenarios for federal agencies where security can be a matter of public safety and national security.
Managing Software for Mission Success
Agency leaders need to think ahead, plan for their software’s EOL, and adopt a modern approach to rationalize tools and assets. Tool duration should be set by mission needs and risk management practices, not convenience or contract duration.
Once a specific software reaches EOL, agencies have a few realistic options: procure extended support, uninstall the software, or find an alternative.
Agencies should routinely evaluate if tools are essential. If EOL software is still crucial to mission operations, teams might contact the vendor for extended support or search for an alternative to replace or greatly increase security surrounding the software. If the tool is nonessential, teams should uninstall all instances across the network.
With Adobe, many developers and users discontinued their use of Flash a long time ago. However, there may be users that still rely on the software. Regardless, it’s important to issue the last call and find a solution that securely meets mission needs.
When looking for EOL software, consider all the places it could exist. Software can exist as a standalone application, browser plugin, or as an extension/component that is used by other applications. Completely removing EOL software involves removing all of these instances across all endpoints. When reviewing software scope, consider all platforms that the software could have ever existed on, and consider that during the lifespan of the application it may have reached its tentacles into many parts of the agency.
Retire EOL Software, Revitalize Endpoint Protection
When retiring EOL software, federal IT teams need real-time visibility into their environments. They need the ability to identify the endpoints that had the software installed, where it’s actively being used, and track any vulnerabilities related to it as well as any ongoing remediation efforts.
Retiring software generally follows a standard process. First, a decision is made to retire software based on an ad-hoc request, event (such as vendor notification or contract termination), or time-based predetermined decision. Next, internal decision points occur which decide whether the agency will continue to use, pay for support, or identify a new solution. And finally, the agency implements the software decommission. This article highlights some reasons why you may want to consider more ad-hoc requests and vendor notifications and less time-based ones to trigger a software decommission. And of course, if you never onboard the software, you will have no need to decommission it later.
Remember, if agencies do not secure endpoints in real-time, then their networks are not secure. It’s not uncommon for agencies to work off data that is days or weeks old. However, today’s cyber attackers only need minutes to achieve their goals. Attacks on federal systems are coordinated and executed in real-time, so it’s critical federal organizations have the same speed, scale, and accuracy—all of which are only possible with real-time data for enterprise visibility and control.
Source: https://www.nextgov.com/ideas/2021/04/how-do-you-retire-technology-and-limit-risk/173448/
