CISSP: Domain 7, Module 1
The course is part of this learning path
This course is the first of 4 modules of Domain 7 of the CISSP, covering Security Operations.
The objectives of this course are to provide you with the ability to:
- Understand and support investigations
- Understand requirements for investigation types
- Conduct logging and monitoring activities
- Secure the provisioning of resources through configuration management
- Understand and apply foundational security operations concepts
This course is designed for those looking to take the most in-demand information security professional certification currently available, the CISSP.
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.
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
So we're going to move into section four and discuss secure provisioning of resources through configuration management. So here we're going to talk about asset inventory and the process of configuration management. Fundamental to any sort of a change, control, or configuration management system and its success will begin with an inventory of hardware and software. Now doing an inventory of all the hardware is a way of identifying what is present, what is and should be and what is and shouldn't be included in this. And the same is true of software. We're looking to identify what software is present, the vendor, the licenses, and this is done for a couple of reasons. One is so that we know what we have, and two so that we know what our license posture is to be sure we're not at risk for operating unlicensed software, which means it essentially is not part of our normal inventory, and perhaps it's not licensed or being paid for.
Now having developed inventories of both hardware and software, we want to employ a configuration management process. Now, to break this down, configuration management is a discipline for evaluating, coordinating, approving or disapproving, and implementing the changes to artifacts used to construct and maintain software systems. Now to compare configuration management with change control, the easiest way to remember is change management, or change control, is more of a macrolevel institutional or organizational level process, whereby change is identified, analyzed, and then in some controlled way, introduced into the organization if it's found that that is beneficial. Configuration management would be more of a microlevel process, by which we break the changes down into smaller and smaller pieces to implement into the various components within the organization.
We, of course, must begin with a concept of what our configuration or change management process should be. And then, of course, we build policies and procedures and standards to guide how it will be performed. So we need to have policy and procedure in place, first that we define the set of artifacts that will be placed under the jurisdiction of a configuration management process, how the artifacts will be named so that we have a consistent and clear nomenclature. There must be a controlled method by which artifacts will enter and leave the controlled set. We have to have something a little bit beyond the configuration management process itself because we have to define how an artifact under CM is allowed to change. Artifacts that we have configuration management over can change in a wide variety of ways, but not all of which are ways in which we want it to. And so, we must identify what the roadmap will be for allowed changes. This, of course, means we're going to have to deal with version control. And how the versions of an artifact are made available and under what conditions each can be used is part of this process and must be publicized to all those interested and concerned parties. There will be a tool set, of course. And the tool set must be used. And how it's used must be committed to policy and procedure. And those authorized to perform these functions have to be trained in it.
The assets that we place under configuration management will, of course, be of a variety of kinds. Some will be physical, some will be virtual, some will be cloud, perhaps, if cloud computing is part of your operation, and then, of course, we have the applications.
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.