CISSP: Domain 7, Module 2
The course is part of this learning path
This course is the 2nd 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:
- Employ resource protection techniques
- Conduct incident response
- Operate and maintain preventative measures
- Implement and support patch and vulnerability management
- Participate in and understand change management processes
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.
Now we move into the implementation and supporting of patch and vulnerability management. In this section, we're going to talk about patch management systems and vulnerability management systems. Patch and vulnerability management is a key part of configuration in change management, involving the deployment of software updates, which is also known as patch management. Flaws in vendor products are continuously being discovered. The development and distribution of vendor patches results in a never-ending cycle of required updates to production systems, having taken on the name of Black Tuesday with Microsoft's program of releasing patches. Managing these updates is not, however, a trivial task for any organization; the patch management process must be formalized through change and configuration management to ensure that changes to existing configurations are carefully controlled, and continued system reliability and availability has greater assurance.
Now, the main objective of the patch management program is to create a consistently configured environment that is secure against known vulnerabilities in operating systems and application software. Unfortunately, as with many technology-based problems, good practical solutions are not as apparent. So the questions we have to ask about whether or not a patch is necessary, what is the risk if the flaw is not patched? Always a question, what happens if we do? What happens if we don't? Is the system likely to be exposed to threats that might exploit the vulnerability? Will special privileges be required for the vulnerability to be exploited? Always an important question, because it means that if it is going to be exploited, an attacker who's seeking to do so may have to eventually escalate his privileges to the point of being a sysadmin. Can the vulnerability be used to gain administrative privileges to the target? If that were the case, then exploiting the patch might help them in that escalation process.
How easy is it to exploit the vulnerability? And will the vulnerability require physical access to the system or can it be exploited remotely? This is a very significant point. Physical security to prevent the asset from physical access by the assaulter may be something relatively easy to do. But as is often the case, remote access is rather more difficult to defend against, and we have to look at the process from start to finish. Having the patch, we need to think through the process of, how do we take it apart? How do we examine what it's going to do, determine the necessity for having it in the first place, whether or not we need it at all, and then going through the process of programming a proper well-controlled process of deployment, release, and actualization?
We should establish a schedule that can be published, so that users can plan their work accordingly. We have to be sure that they're always notified whenever a patch is going to be done, whether it's a scheduled one or an unscheduled, say, an emergency type. Updates should, as best we can, be scheduled during periods of low activity or even in the overnight period. We need to make certain that a full system backup is conducted prior to deploying patches. It is not uncommon that whenever a patch has been put in place, things do not go exactly as planned. It is better to practice caution and make sure that we have a backup of the system in its completeness before the patch is applied to ensure that if something does go wrong, we'll be able to restore the operation in a relatively short time, and if nothing goes wrong and everything goes as planned, then we'll be able to carry on, make a copy after the now properly working patch is in place and we baseline the system.
Whenever possible, an update should be deployed in stages. That depends on how complex and how many components are going to be affected by the change. We always need to apply these things, and then confirm that the updates are deployed to all the appropriate machines and that they have installed correctly, and that they're doing what and only what they're supposed to. Take nothing for granted. And then, once we've established definitively that everything has gone according to plan, we document the changes and put in place the new documented baseline of the system.
We do something a little different with our vulnerability management system. We first must recognize that vulnerabilities will arise from a variety of sources. They can be system flaws or failures in policies, or the failure of a user to perform a procedure correctly. The most common type of flaw in software is the buffer overflow. Now, flaws are generally fixed by a patch, by new code, or by a hardware change in some cases, and misconfigurations are implementation errors that can expose a system to an attack. Policy violations are found with a comprehensive network scanning tool. All of these different things must be done on a routine basis to ensure that we're keeping vigilance over the system, and managing our vulnerabilities. Because that is us managing and controlling the attack surface we present to potential attackers.
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.