Although you can accept the risk of running unsupported software, you should treat it as a temporary strategy. In this post, I discuss the importance of establishing a policy for upgrading, replacing, or retiring unsupported software across the organization.

The cost and resources required to update unsupported software may be greater than the perceived cost and impact of an adverse event caused by unsupported software. Consequently, based on its risk tolerance, your organization may decide to allow unsupported software on its network. This decision is generally made by IT management during risk management planning. Such a decision implements a solution that should only be short term and temporary.

Senior leadership should fully understand the risks of running unsupported operating systems and establish a policy for preventing unsupported software on its network. Such a policy must be part of your organization's overall risk management program and should direct how software should be maintained.

The policy for upgrading, replacing, or retiring software assets should also align with your organization's risk management plan. It should specifically identify resources and earmark funding to implement the policy.

Check back next week to read a summary of the actions you can take to protect your networks from exposure caused by unsupported software, or subscribe to a feed of the Insider Threat Blog to be alerted when a new post is available.

SEI LIBRARY

LATEST POST

According to DevSecOps: Early, Everywhere, at Scale, a survey published by Sonatype, "Mature DevOps organizations are able to perform automated security analysis on each phase (design, develop, test) more often than non-DevOps organizations." Since DevOps enables strong collaboration and automation of the process and enforces traceability, mature DevOps organizations are more likely to perform automated security analysis than non DevOps organizations. My previous blog post, Microcosm: A Secure DevOps Pipeline as Code, helped address the problem that most organizations do not have a complete deployment pipeline in place (and are therefore not considered to be DevOps mature) by automating penetration tests of software applications and generating HTML reports as part of the build process through the Jenkins CI service. In this follow-up blog post, I explore the use of a service evolution of Microcosm as a simple one-stop shop for anyone interested in learning how to implement a DevSecOps pipeline.