1. Home
  2. Training Library
  3. Security
  4. Security Courses
  5. CSSLP Domain 7:2 - Secure Software Operations and Maintenance

Secure Software Disposal

Contents

keyboard_tab
Start course
Overview
Difficulty
Beginner
Duration
38m
Students
22
Description

This course covers the security aspects that a CSSLP needs to keep in mind when dealing with the final stages of the software development life cycle including operations, maintenance, incident management, and the software disposal process.

Learning Objectives

  • Get a solid understanding of software sustaining engineering
  • Understand the software maintenance process
  • Learn about incident management and software disposal

Intended Audience

This course is intended for anyone looking to develop secure software as well as those studying for the CSSLP certification.

Prerequisites

Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.

Transcript

Now, all of this brings us to the point where everything is now in operation. So the next major milestone to be considered is what do we do about assured disposal? Eventually, all software goes obsolete, and no software truly will sustain forever upgrades and version changes, without significant core or code changes within. So we have to consider assured disposal as the endpoint at the end of life for every program we're going to have, or build, or operate.

We have to plan for this inevitable obsolescence. And it means that we have to have a process for finding the replacement, deciding on what that's going to be, going through all the processes we've talked about throughout this entire course, and then plan for the termination of the delivery of software services for that element that is going to be retired. We're going to sustain it for a while, but we're not gonna upgrade it anymore. And then eventually we'll stop doing that. And eventually, you're going to have to convert to the new program that is replacing it, is kind of the logic here.

We'll operate it for a while, but it's going to be in a deprecated form, meaning that it's not gonna have the latest and greatest features or functions, because it is going to be replaced. So you are already getting the user population set mentally that they're going to have to plan to adopt the new thing. 'Cause the old thing is eventually going to go away. Now in the course of its use, the program that we are going to retire is very likely going to acquire information that will be of a sensitive nature, it may represent a trade secret, a host of other things. And so our process needs to recognize these potentials, air on the side of caution and be sure that when this program is disposed of that it doesn't provide any sort of leakage of any intellectual property or sensitive information about itself to anyone who may not be authorized for it. Along with that, we need to plan for a smooth transition to the replacement product. That will involve things like piloting, test runs, training, staged rollouts while retaining the original for limited time.

So, this promotes the idea of parallel operations with a definite sunset point for the old and a definite sunrise point for the new. Now all of these components are the ones to retired, it's advisable to keep them in an archive for historical or audit purposes. And quite frankly, as a just in case, if there is a problem with the new thing, we have a fallback that we can revert to, if we need to, hopefully, that won't be necessary but we still have to plan for it.

About the Author
Avatar
Ross Leo
Instructor
Students
5766
Courses
75
Learning Paths
17

Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years.  He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant.  His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International.  A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center.  From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.

 

Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004.   During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide.  He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004.  Mr. leo is an ISC2 Certified Instructor.

Covered Topics