From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Decommission software

From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Start my 1-month free trial Buy for my team

Decommission software

“

- [Instructor] Decommissioning old and insecure versions of your applications is an important step within your lifecycle. One of the best ways to do this is by leveraging end-of-life policies and data disposition concepts to help you securely decommission those applications when the time comes. When an application reaches end of life, that means the powers that be have made a formal decision to stop investing time and resources in developing, and maybe even maintaining that application. That end-of-life label doesn't mean that the end users need to abandon the app right away, though. There are actually a handful of related labels that provide more details and guidance. Think of end of life as the first step in the process. Once this decision has been made, then you should start making plans to migrate your business processes to another solution. Software vendors might also define end of sale and end of availability dates. When an app reaches the end of sale stage, customers can no longer purchase new licenses for or instances of that application from the company who created it. If the app is being resold by third parties, that app may still be available for a short while until it reaches the end of availability stage. This point is reached when the resellers run out of licenses that they may have already purchased. When an app reaches end of service life, though, that's when the risks associated with using that app escalate. At this stage, the company that created the app will no longer offer technical support. If the app breaks, you're on your own. As the CSSLP, you want to make sure to include this information in your end-of-life policies so that they don't come back to bite you if not handled properly. Start with credential removal. As business processes are migrated to newer supported applications, so are the user accounts. So, what do you do with the accounts in the old application? Ideally, you turn them off as soon as they're no longer needed, and this doesn't just apply to user accounts. This applies to all administrator accounts, as well as system and service accounts that were used to keep the application up and running. Don't turn things off too quickly. Refer to your design and implementation docs to determine the sequence for disabling and ultimately removing these credentials. You'll also want a policy that focuses on configuration removal. Remember, your application is useless without the infrastructure that enables the app to function in the first place. You want to refer to your design and implementation documentation again, this time, with an eye on the infrastructure and integrated components that your app relies on. If you've made any configuration settings to the database, the operating system, or maybe to the network to support your application, you want to modify those configurations to ensure that your infrastructure is properly protected once the old application is fully removed. And don't forget your APIs. You want to review them from both a credential perspective and a configuration perspective to ensure that you've taken the necessary steps to securely disable and remove them, as well. As you build out your decommissioning procedures, keep in mind how these procedures will impact your service level agreements and vice versa. As a quick reminder, a service level agreement is a contractual commitment to deliver a certain level of application quality and support. Your SLAs will likely include commitments around responding to customer support requests, around developing and deploying security patches, and around providing both updates and bug fixes to keep the product working as designed. Make sure you incorporate your SLA requirements into your decommissioning planning efforts.

Contents