Security Doesn't Stop At (Product) Retirement
By Ross Saunders
Software products, similar to vehicles, old houses, and technologies, eventually reach the point where the cost of rebuilding and refactoring becomes greater than the cost of rewriting and releasing under a newer platform, language, or architecture. During these sunset phases of a product, development is often ramped down, resources are reduced, systems are terminated, and focus is given to the new products, betas, and rollout efforts. The risk of neglect towards critical “life support systems” at these stages is high, particularly in the security space.
When companies start placing focus on releasing the new product, it becomes very difficult to motivate spending more money and effort on a product that is going to be retired in the near future. It makes sense to focus on making sure that the new product succeeds in its place, and that there aren’t gaps in functionality or teething problems. That all said, until the retiring system is ultimately taken offline and is inaccessible, there is still a threat that it can be exploited.
If anything, monitoring products nearing retirement may actually need more resources than in its earlier lifetime. This is because libraries and dependencies that are in use are not going to be updated as frequently, if at all. We see all too often that a client’s software package is highly secure and robust, only to find that a vulnerability assessment identifies a javascript library or outdated certificate that compromises security. As you wind down development, your view needs to expand into the increased risk of dependencies becoming dated.
Similarly, depending on the length of your sunset and how long your system will be live without updates, the likelihood of attack may also increase. Attacks are constantly evolving, and something that may not have been a threat previously suddenly becomes one, and circumvents a security feature of your product.
You need to be open to the fact that there may be a window where you will need to apply critical updates to the product that is in sunset, and it is advisable that you build this into your resource planning. Configurations, libraries, and the codebase can all become sources of risk, and there should be some contingency to deal with that. This also illustrates the value in realistically estimating and sticking to your timelines of migrating a userbase from the old to the new, and not having the old system exposed for longer than expected. We have worked with platforms that have taken years to sunset, and development had to re-start because of it.
In the end, activities like proactive monitoring, patching of servers, addressing logs, and ongoing vulnerability management must continue to take place as-usual for as long as the system is live. If the system is in use and accessible, it is still in production and you must treat it that way. Instead of focusing on switching from the one to the other in an “old and new” fashion, concentrate on your risk management, likelihood of vulnerability, time to sunset, and an integration of resources between one product and the other.
