Introduction to EOL Best Practice
End-of-life (EOL) software refers to software that is no longer supported or maintained by its developer. This may be due to the vendor going out of business or as a natural part of product life cycles. Often the end-of-life software can simply be upgraded to a new version or migrated to a newer solution from the same vendor but when this is not available you will need to find alternative solutions either in-house or in the marketplace.
As the end-of-life date nears and the software products become unsupported software you will stop receiving security patches and the supplier will stop providing software support. The use of EOL software, therefore, comes with risks that only get worse as time passes.
Some vendors use the term EOS instead of EOL. EOS stands for “End Of Support” or “End of Sale”, It refers to the date on which a specific version of the software or an operating system will no longer be supported by the vendor.
After the EOS date, the vendor will no longer provide security updates, bug fixes, or technical support for that version of the software. It’s important to note that after the EOS date, the software will still work but it will be more vulnerable to security risks as it will not receive any patches for newly discovered vulnerabilities.
It’s important for organizations to plan and prepare for EOS dates in order to ensure that their systems are up-to-date and secure.
As a customer, you should check your software license agreement as some software does not automatically come with a ‘right to use’. This is only maintained by running a supported version and paying maintenance. So there may be a contractual reason, with financial penalties for continuing to run EOL software. Even if you accept these penalties, some software requires the vendor to issue license keys when it is reinstalled or on an annual basis. These may become hard or impossible to obtain for EOL software depending on your vendor.
Best practices for dealing with end-of-life/legacy software include:
1 – Create an inventory of all the software used in your business.
The first task is to establish if you have any software which will become end-of-life or which is already beyond its sell-by date.
Large IT Departments will often follow ITIL best practices and maintain a CMDB. A CMDB, or Configuration Management Database, is a centralized repository that stores information about the hardware and software assets, as well as the relationships and dependencies, of an organization’s IT infrastructure. The CMDB serves as a “single source of truth” for IT operations, providing a comprehensive view of the organization’s IT environment and supporting the tracking, management, and reporting of IT assets and configurations.
A CMDB is used to:
- Track and manage IT assets, including hardware, software, and licenses
- Identify and document the relationships and dependencies between IT assets
- Facilitate change management and incident management processes
- Provide a basis for reporting and compliance
- Automate IT operations and improve service delivery
- Provide the ability to maintain an accurate inventory of assets, to track their location and status, and to be able to plan for their replacement.
CMDBs are often implemented as part of ITIL (Information Technology Infrastructure Library) and IT service management (ITSM) frameworks, and are typically integrated with other IT management tools such as incident management, problem management, and change management systems.
If your organization doesn’t already have a CMBD then you can create a simple Software Inventory. Creating a software inventory involves identifying, cataloging, and tracking all the software that is installed and in use within an organization.
Here are the steps to create a software inventory:
Identify all devices:
Determine all the devices that are in use within the organization, including servers, desktops, laptops, and mobile devices.
Collect data:
Use software inventory tools or scripts to collect data on the software that is installed on each device, including the name, version, and license information.
Document the inventory:
Create a spreadsheet or database to document the inventory, including the software name, version, license information, and the devices it is installed on. This should include the EOL date for the installed version and the target upgrade version if a newer version is available.
Keep it up to date:
Schedule regular scans to ensure the inventory is up to date and to identify newly installed software.
Validate/audit the inventory:
Verify that the inventory is accurate by cross-checking it against the devices and software in use.
Review licenses:
Review the licenses for each software and ensure compliance with the terms of use.
Share the inventory:
Share the inventory with relevant stakeholders, including IT staff and management, to ensure that everyone is aware of the software in use and can plan for upgrades and replacements as needed.
Depending on the size of your organization and the number of devices, creating a software inventory may be a complex task that requires additional resources or specialized tools. There are several tools available that can be used to create a software inventory. Some examples include:
Microsoft System Center Configuration Manager (SCCM):
SCCM is a comprehensive management tool that can be used to inventory software on Windows devices, including servers and workstations.
Lansweeper:
Lansweeper is a network inventory tool that can be used to scan and inventory software on Windows and Mac devices, as well as mobile devices.
Spiceworks:
Spiceworks is a free, open-source network inventory and management tool that can be used to inventory software on Windows, Mac, and Linux devices.
PDQ Inventory:
PDQ Inventory is a paid tool that can be used to inventory software on Windows devices, including servers and workstations.
AIDA64:
AIDA64 is a system information, diagnostic, and benchmarking tool that can be used to inventory software on Windows devices.
GLPI:
GLPI is a free open-source IT asset management software that can be used to inventory software and hardware.
Open-AudIT:
Open-AudIT is a free open-source software inventory tool that can be used to inventory software on Windows, Mac, Linux, and Unix devices.
Each software inventory tool has its own features, functionalities, and pricing, so it’s important to evaluate the best option based on your organization’s needs and budget.
2 – Stay informed about software updates and vulnerabilities
You need to keep track of the EOL dates for all software applications and EOL operating systems in use and stay informed about any security vulnerabilities that may arise. Staying informed about software updates and vulnerabilities is important to ensure the security and stability of your organization’s systems. Here are some best ways to stay informed:
Assign an owner: Make sure each piece of software has a nominated owner in your organization who has direct responsibility for staying informed.
Set-up Service Review Meetings: For the vendors of your most important software, you should set up regular service review meetings. Software updates, bug fixes, security threats, and vulnerabilities should be standing items on the agenda.
Most software vendors will be only too happy to have service review meetings as they seldom want customers running old versions of their applications as these become increasingly difficult to provide technical support and security updates for.
Include it in your contract: If you commission bespoke software and pay for ongoing maintenance you should write into the contract a clause stating the vendor is to notify you of any security issues or vulnerabilities without delay as they are discovered, and patches and updates as they become available. For example:
“The supplier shall promptly inform the customer of any security issues and vulnerabilities discovered in the software, without delay. The supplier shall also provide the customer with any patches and updates as they become available to address such issues and vulnerabilities. The supplier shall make every effort to ensure that any such patches and updates are made available in a timely manner, and shall provide the customer with an estimated timeline for their release, whenever possible.”
This clause ensures that the customer is kept informed about any security issues and vulnerabilities that may affect the software, and that the supplier takes responsibility for addressing them in a timely manner. It also allows the customer to be aware of any expected timelines for the resolution of the issues.
Please note that this is a sample clause and you should consult with a lawyer to ensure that it meets the legal requirements of your jurisdiction and the specific needs of your business.
Subscribe to vendor security alerts: Many software vendors provide email or RSS feeds for security alerts and updates. Subscribe to these alerts to stay informed about any new vulnerabilities or patches.
Use a software vulnerability scanner: Use a vulnerability scanner to periodically scan your network for known vulnerabilities and to check for missing patches. Software vulnerability scanners are tools that are used to identify security vulnerabilities in software systems. They work by conducting a thorough examination of the software and its associated configurations, identifying any potential weaknesses or vulnerabilities that could be exploited by attackers.
There are two main types of vulnerability scanners: network-based and host-based.
Network-based vulnerability scanners: These scanners scan a network from an external perspective, looking for open ports, services, and vulnerabilities. They work by simulating an attack on the network and identifying any weaknesses that can be exploited.
Host-based vulnerability scanners: These scanners run on a specific host and scan the software, configurations, and settings of that host. They can also scan the host’s memory and operating system, looking for vulnerabilities in the software and configurations.
Both types of scanners use a database of known vulnerabilities, which is regularly updated with new information, to identify potential issues. When a vulnerability is identified, the scanner will report the issue and provide a recommended solution.
Vulnerability scanners use databases of known vulnerabilities to identify potential issues in the software and configurations they are scanning. These databases are regularly updated with new information about vulnerabilities as they are discovered.
There are several databases that vulnerability scanners may use, including:
Common Vulnerabilities and Exposures (CVE) – a standardized list of vulnerabilities and exposures that are maintained by the MITRE Corporation.
National Vulnerability Database (NVD) – a comprehensive database of vulnerabilities that is maintained by the US National Institute of Standards and Technology (NIST).
Software Vulnerability Database (SVD) – a database of vulnerabilities that is maintained by the United States Computer Emergency Readiness Team (US-CERT).
Common Weakness Enumeration (CWE) – a list of common software weaknesses that is maintained by the MITRE Corporation.
Common Attack Pattern Enumeration and Classification (CAPEC) – a list of common attack patterns and techniques that is maintained by the MITRE Corporation.
OWASP Top Ten – a list of the top ten web application security risks compiled by the Open Web Application Security Project (OWASP).
These databases are widely used in the industry, and many vulnerability scanners use one or more of them to identify vulnerabilities in the software systems they are scanning. Some scanners also use proprietary databases or combine information from multiple sources.
3 -Export data and deinstall end-of-life software
Often legacy applications or end-of-life applications are kept online just so that staff can access historical records. You should consider if the data can be exported and the application closed down.
Many older software applications use proprietary data formats. This means that the data you have in the application will probably not be accessible once you deinstall the application and can no longer run the software. I recommend that you find a way to dump your data out of the legacy application into a portable format. Once the data is exported you can decommission the legacy end-of-life software and stop paying maintenance on it.
There are several file formats that can be used for data export, and each has its own set of pros and cons. Here is a summary of some of the most commonly used formats:
JSON (JavaScript Object Notation):
- Pros: JSON is a lightweight, human-readable format that is easy to parse and generate. It is also widely supported by many programming languages and applications.
- Cons: JSON can become verbose and difficult to read when representing complex data structures.
XML (Extensible Markup Language):
- Pros: XML is a flexible, self-describing format that can be used to represent complex data structures. It is also widely supported by many programming languages and applications.
- Cons: XML can be verbose and difficult to read, especially for large data sets. It also requires a more complex parsing process compared to JSON.
CSV (Comma Separated Values):
- Pros: CSV is a simple, easy-to-read format that can be opened in most spreadsheet programs. It is also supported by most programming languages and is a good choice for data that needs to be imported into other systems.
- Cons: CSV has limited support for complex data structures and may not be able to handle large data sets or binary data.
PDF (Portable Document Format)
- Pros: PDF is a widely supported format that can be used to export data in a printable format. It’s a good option for data that needs to be shared with other users and can be protected with password encryption and digital signatures.
- Cons: PDF is not easily machine-readable, and it’s not recommended for data that needs to be imported into other systems.
ASCII Text Files:
- Pros: ASCII text files are a simple, easy-to-read format that can be opened in most text editors. It’s widely supported across platforms and is small in size.
- Cons: ASCII text files are not recommended for large data sets or data with complex structures. It’s also not recommended for data that needs to be imported into other systems.
Ultimately, the choice of file format will depend on the specific needs of your project and what the legacy application will allow you to do. JSON and XML are good choices for complex data structures and web applications, while CSV is a good choice for data that needs to be imported into other systems. PDF is a good option for data that needs to be shared with other users and ASCII Text Files are good for small data sets or data that needs to be read by humans.
4 -Keep software updated:
Ensuring that software is kept up to date is an important aspect of maintaining the security and functionality of a system. Here are some best practices for keeping software up to date:
Automate software updates: Use tools and software that can automatically check for updates and install them in the background. This ensures that updates are installed as soon as they become available, reducing the risk of exploitation of known vulnerabilities.
Set up notifications: Set up notifications for software updates, such as email alerts, so that you are informed when an update is available. This way you can schedule the update at a convenient time and minimize disruption to the end users.
Test updates before deployment: Before deploying an update, test it in a test environment to ensure that it does not cause any issues with existing systems and configurations.
Prioritize critical updates: Prioritize the installation of critical updates that address security vulnerabilities or critical bugs. These updates should be installed as soon as they are available to minimize the risk of exploitation.
Keep an inventory of software / CMDB: Keep track of all software that is installed on your system and ensure that they are all up-to-date. This can be done by maintaining a software inventory or CMDB (see above), which should include version numbers, vendor information, and expiration dates.
Have a patch management plan: Develop a patch management plan that outlines the process for identifying, testing, and deploying software updates. This plan should be reviewed and updated regularly.
Train your team: Regularly train your team on security best practices, including the importance of keeping software up to date, and the steps they need to take to ensure that software is updated in a timely manner.
By following these best practices, you can ensure that your software is kept up to date, reducing the risk of exploitation of known vulnerabilities, and helping to maintain the security and functionality of your system.
5 – Conduct a risk assessment: Evaluate the potential risks associated with continuing to use EOL software and determine if a replacement is necessary.
Factors to consider include the criticality of the software to business operations, the likelihood of security vulnerabilities being discovered, and the potential impact of a security breach.
Identification of mitigation strategies: Based on the risk evaluation, identify potential mitigation strategies such as upgrading to a newer version, replacing the software with a different product, or implementing compensating controls such as security monitoring and incident response plans.
Click here to download our free Microsoft Word Software Risk Assessment form template.
5 – Ensure you have a backup and recovery policy covering end-of-life software
Here is an example backup and recovery policy for legacy and end-of-life software:
Purpose: The purpose of this policy is to ensure that all end-of-life software and data are backed up and can be recovered in the event of a failure or disaster.
Scope: This policy applies to all end-of-life software and data that are used within the organization.
Backup Schedule: Backups of end-of-life software and data will be performed on a daily basis and stored offsite at a secure location.
Recovery Process: In the event of a failure or disaster, the recovery process for end-of-life software and data will be initiated immediately. The recovery process will be tested on a regular basis to ensure that it is functioning properly.
Retention: Backups of end-of-life software and data will be retained for a minimum of 3 months.
Responsibilities: The IT department is responsible for implementing and maintaining this policy, and all employees are responsible for ensuring that their end-of-life software and data are included in the backup process.
Review: This policy will be reviewed and updated on a regular basis to ensure that it remains current and effective.
This is an example, it can be modified to suit the needs of your organization. It is important to consult with legal, IT, and compliance teams before finalizing the policy.
Note: The most important thing with any backup solution is to ensure you test that it works by restoring it to a test system on a regular basis.
6 Consider third-party support: Consider purchasing third-party support for EOL software if it is mission-critical and replacement is not possible in the short term.
you can use third parties to provide support for end-of-life (EOL) software. This is a common practice for organizations that have software that is no longer supported by the vendor. Third-party support providers offer a variety of services, including security updates, bug fixes, and technical support.
Using third-party support providers can be a cost-effective way to extend the life of EOL software and ensure that it continues to function properly. However, it’s important to research and select a reputable provider that has experience with the specific software you are using. It is also important to verify that the provider’s support is compliant with legal and regulatory requirements.
It’s also important to note that not all software can be supported by a third-party provider and in some cases, it may be necessary to migrate to a newer version of the software or a different product altogether.
Additionally, it’s important to consider the risk that comes with the use of third-party support for end-of-life software, as it might not be fully compliant with the latest security standards, and support providers may not have access to all the fixes and updates that the vendor would have. You are more likely to find third-party support for popular software and software where you have access to the source code.
Product management for EOL Products
So far we have only discussed best practices for handling end-of-life products from a customer’s perspective. Much of the advice given above is also relevant to software vendors for their own management of EOL products. Within software companies, the Product Management Team should have an End-of-life process followed by product managers with a set of activities that a company undertakes to phase out or discontinue a product. The EOL process typically includes the following steps:
Planning: This involves identifying the product that is reaching the end of its lifecycle and determining the best course of action for discontinuing it. This might include evaluating the product’s financial performance, customer demand, and the availability of alternative products.
Communication / EOL Announcement: This involves informing customers, end users, partners, and other stakeholders about the product’s upcoming EOL. This might include sending out notifications, holding customer webinars, or providing detailed information on the company’s website. Before the product becomes formally EOL there will be an end of sale (EoS) date, when new customers will no longer be offered the EOS software product.
Support: This involves providing ongoing support and maintenance for the product during the transition period. This might include providing software updates, bug fixes, and technical assistance to customers. This has to be balanced against using development resources for newer products that may have a larger user base. Providing support for as long as reasonably possible is good for customer loyalty, after all they have been paying you maintenance for many years.
Migration: This involves helping customers transition to a new product, latest version, or solution. This might include providing training, documentation, and other resources to assist with the transition.
Retirement: This involves officially discontinuing the product and ceasing all support and maintenance activities. In some sectors there will be competitive pressure to maintain support for as long as possible, the iPhone v Android is a good example.
It’s important to note that the EOL process can take several months or even years, depending on the product and the company’s strategy. The objective of the EOL process is to ensure a smooth transition for customers and minimize disruptions to the business. Additionally, it’s important to plan for the EOL phase of the product life cycle in a way that it does not harm the customer’s business process or cause a negative impact on their business.
0 Comments