Okay. The final element of this chapter and really of the course is a hole.
All good things must come to an end. So at the point in which the software has outlived its usefulness, we need to start thinking about disposing of the product. And again, this could be software. This could be a system.
And when we talk about that, we talk about sun setting, and we generally have sun setting criteria. That tells us when it is time to go ahead and decommission the product, so to speak.
So whether or not the software has maybe reached the end of its vendor support, you know, vendors will put out multiple versions of software, and at some point in time, they'll say we're no longer supporting version three,
and they kind of do that to force other users upgrade. But at that point, where I no longer get the support from the vendor, I get no more patches. No more security fixes. Um, I really is time to bring a new product in.
Maybe the software is no longer compatible with our environment. Maybe we've changed our system architecture. We changed hardware. Maybe there's another product that performs the same functionality, but cheaper or more secure. There could be a 1,000,000 reasons that we decide to go ahead and sunset the product.
But at any rate, once the decision has been made, we have tohave specific set of processes that will detail how we're gonna go about doing this. For instance. Maybe we have a database, and we have to think about securely migrating all the information in that database into the new database.
Um, we may have to talk about
what we do with that old database how we, uh,
destroyed the remnants of data
that might be in that honest, specific system, for instance, making sure that the data is backed up in archive before we do destroy the software, the system.
Sometimes we look to 1/3 party escrow. Maybe we'd pay 1/3 party to store.
maybe the backed up version of information, Um, sort of like archival, But we're outsourcing that to 1/3 party we may discard. You know, we may just find that the software can be freely disposed of whatever, you know, but it all is driven by the sensitivity and the value of the assets.
Ah, and what it's protecting. So ultimately again it goes back to what policy says and our policies air driven by risk management. So we dispose of the software and of any of the data elements in the means that are documented and in such a way that it supports the security policy of our organization.
Ah, Decommissioning software. We've gotta have that strategy for what we're gonna do with the information, how you handle the information,
how we're gonna coordinate with other systems if we're bringing new software in
again. We've talked about media sanitation,
any sort of agreements that have to be terminated based on no longer using the software, making sure that we have archived our data.
Any sort of assets have been disposed of in the manner that's appropriate. So ultimately, what this all comes down to is finding a graceful means of disposing off the system or the software, making sure that any remnants of data, if they're sensitive or destroyed,
if they're not sensitive, we may decide that we need toe archive those and keep them available, depending on whatever our data retention policy. Maybe, but just like everything else, there should be a process should be graceful process that's predefined, and we should follow that process in the Decommissioning of a system or of a software
So ultimately, this does wrap up Part seven, which covered deployment operations, maintenance and disposal, and the reason all of these elements were kind of group together in a relatively short chapter. WAAS. The majority of this class focuses on software development,
right? So once the product's been developed and we're handing it over to the vendor, we have less and less hands on through the deployment operations, maintenance and disposal peace. So they kind of loved the last four elements there together, and then we covered that quickly. But really the majority.
Your test comes from the 1st 6 and really even the 1st 5
sections all about okay, what are the basics for security? How do we get good security requirements? How do we incorporate those requirements into our design?
How do we take that design and implement the code based on the design? How do we test the secure software? And then how do we turn that over to the customer to get software acceptance? And then ultimately, we deploy it out into operations where it's continually maintained and monitored, and then ultimately, at
we have the disposal.
So we've covered quite a lot of information for Theo. Examination preparation for this class. The CSS LP certification is a great one to get. I would really encourage you to do some study. There's a lot of information on the exam, So take your time and study. I would encourage you to find some review
good quality review questions to prepare you for. Hi, how I s C Square's been a word. Those questions put in your time and effort. It's a great certification tohave, and it really states that you understand how security should be implemented into the software development life cycle.
So I hope this class has been helpful to you. I wish you the best of luck,
and as always, if you have any common or feet back,
please feel free to use those options and provide us with any information or any comments that you like.
I wish you best of walk from the certification, and, uh, hopefully we'll have another class together in the future. Thanks so much