Patching and Change Management in CISSP Domain 7: A Deep Dive
Download FREE Audio Files of all the MindMaps
and a FREE Printable PDF of all the MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Transcript 7.4
Introduction
Hey, I’m Rob Witcher from Destination Certification, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major patching and change management topics in Domain 7, to understand how they interrelate, and to guide your studies and help you pass the CISSP exam.
This is the fourth of six videos for domain 7. I have included links to the other MindMap videos in the description below. These MindMaps are one part of our complete CISSP MasterClass.
Patch management, the proactive process to monitor for new vulnerabilities and patch releases, acquire or create patches, evaluate them, prioritize, schedule the instillation, deploy, verify, document, and update baselines.
Why do we proactively do all of this?
From a security perspective, patching is about creating a consistently configured environment that is secure against known vulnerabilities. We want to ensure that all systems that need to be patched are patched in a timely manner, creating a consistently configured environment. An important limitation of patch management is that we can only patch for known vulnerabilities, so we cannot for instance patch for zero days.
Determine if Patch is available
The first step in the patch management process is to pro-actively determine if a patch is available. And let me re-emphasize pro-active. Organizations must have processes in place to identify if new patches are available as most software and systems do not have auto-update features or provide notifications when new patches are available. A few ways organizations can identify a need to patch include: threat intelligence, vendor notifications, and various types of scanning.
Threat Intelligence
Threat intelligence is where organizations gather information about new threats and threat actors that could cause harm to their environment. This process can identify when patching is required by identifying vulnerabilities that could be exploited by newly identified threats.
Vendor Notification
Another method of identifying a need to patch is when the vendor tells you a patch is available. This is easy with systems that have built-in notification systems like windows and iOS devices. But many software and systems have no built-in notification capability, so it is up to the organization to subscribe to a vendors mailing list, rss feed, or twitter account and monitor these feeds to identify relevant new patches.
Pro-actively checking
As part of maintaining a consistently configured environment, organizations also need to pro-actively scan their systems to ensure they are in compliance with baselines – in other words to ensure that all required patches have been installed in a timely manner. There a few ways this can be done.
Agent
An agent is a small piece of software that is installed on a system, to monitor that system and report on the current patch level of the system.
Agentless
Agentless implies there is no agent, no software, installed on the target system to report on patch levels. Instead a scanning tool is used to connect to systems and query each system as to its current patch level. These scans can be run periodically as part of verifying compliance to baselines.
Passive
And finally, a more subtle technique of checking a system’s patch level is not to install an agent, or use a tool to query the system, instead we carefully inspect network packets being sent by the system.
I spoke of fingerprinting in the domain 6 video on vulnerability assessment. Essentially the idea that we can determine the exact version of a system, and thus it’s patch level, by closely inspecting the exact construction of network packets as there will be subtle differences in the way different versions of a system construct packets. Why would we ever use passive techniques to determine patch levels? Typically, because the systems we want to ensure are being patched are not directly in our control – think systems managed for us by a vendor – we want to verify that the vendor is patching the systems in a timely manner.
Implement through Change Management
Now once a need to patch has been identified we prioritize, schedule, deploy, verify, and document the patch through the change management process, which we’ll talk about in a couple of minutes.
Timing
One of the most important things we have to ensure, from a patching perspective, is that patches are installed timely. In other words, if a new vulnerability has been identified that is actively being exploited we may need to deploy a new patch extremely rapidly and treat it as an emergency change.
Deploy
When it comes to deploying, or installing patches, we always want to try and minimize the impact to the organization, which is why patching is often performed in the middle of the night and coordinated with operations. There are two main methods we can use to deploy patches: automated and manual.
Automated
Automated means we use software to automate the installation of patches. For example, the Auto Update feature built into windows. Automated patching is a good way to deploy patches quickly across a large number of systems, but it’s typically not a great idea to auto-update high value, mission critical servers as patching often breaks existing functionality.
Manual
This is where we tend to use manual patching. For high value systems we want a system administrator to manually install the patch and verify that the patch fixed what it needed to, or added some new functionality, and through regression testing, verify that no existing functionality has been broken.
Change Management
Now let’s talk change management. Change management is the process that ensures that the costs and benefits of changes are analyzed and that changes are made in a controlled manner to reduce risk.
High-level, this is what the change management process looks like. We need a rigorous process to ensure that we understand how big of a deal a requested change is - what it will cost, how much effort it will take, how bad it would be for the organization if the change doesn’t go well - this is what we’re looking at as part of the impact assessment. The results of the impact assessment are a critical input for the rest of the process. For instance, if it’s a major change, thats going to cost millions, you probably need to get approval from a whole bunch of senior stakeholders. Conversely if it’s a super minor change, auto approval might suffice. Once a change is approved, you have to do an appropriate amount of build and testing of the change - you have to notify the right people at different steps throughout the change process - we’ll talk about that in a moment, you then need to implement the change, do an appropriate amount of validation testing after the change is made, and update various things after the change is made - such as DRP plans or configurationbaselines. And very importantly there needs to be good documentation through every step of the change management process.
Alright, lets get into steps one-by-one.
Change Request
The change management process begins with a change request. Change requests can come from practically anywhere, a system owner wanting some new functionality, a customer identifying a bug in a system, the results of a root cause analysis from an incident, or even through threat intelligence that we need to patch a system.
Assess Impact
For every change request that comes in, an impact assessment must be performed.
Emergency Change vs. Standard process
Is this a minor change requiring little effort and will have zero impact on customers, or is it a massive change requiring hundreds of hours of development, millions of dollars and will have a significant impact on multiple stakeholders from across the organization and customers, or is this a high priority patch that we need to treat as an emergency change and get it deployed yesterday.
The impact assessment drives the rest of the change management process, what degree of approvals are required, what level of testing and validation, who needs to be notified, etc.
The change management process needs to be flexible to address these different types of changes.
Approval
Ideally, we also want a flexible approval process. For minor changes, we may allow auto-approval, and at the other end the spectrum we may have changes that require multiple levels or approval from stakeholders across the organization and everything signed in triplicate.
Based on impact, severity, etc.
What drives these different approval requirements is the impact the change will have on the various stakeholders, the level of effort required to implement the change, whether it is an emergency change, etc.
CCB, CAB, ECAB
When it comes to getting approval from stakeholders across the organization, this is where CCBs, CABs and ECABs come in. These are groups of people who are subject matter experts from across the organization. Change Control Boards (CCBs) focus on approving changes within specific projects. Change Advisory Boards (CABs) cover approval of changes related to the entire service lifecycle. Emergency Change Advisory Board (ECABs), focus on emergency changes, as you might expect.
Also, approvals are not just required right before a change is made. Approvals may be required through multiple steps in the change management process
Build & Test
Changes, things like new software, patches, a new camera system, or a new front gate, need to be built and tested before they are deployed into production.
Notification
The notification step, where we notify relevant stakeholders about a change, is stuck here in the middle, but it is important to note that notifications occur throughout the change management process. Before, possibly during, and after a change has been made. And who are these relevant stakeholders that need to be notified? Anyone that is impacted by the change: system owners, management, administrator, customers, maybe even regulators.
Implement
Implementation is where we make the change.
Validation
Which then requires validation - testing
Test New Functionality
Is the new functionality that the change was supposed to provide working correctly?
Regression Testing
And regression testing specifically validates that existing functionality was not broken by the implementation of the change.
Version & Baseline
And finally once a change has been made we need to check to see if a few things need to be updated: including master images, configuration baselines, disaster recovery plans, etc.
And that is an overview of Patching and Change Management within Domain 7, covering the most critical concepts you need to know for the exam.
Busy life? Only have a few hours to study per week? Our CISSP MasterClass adjusts to your schedule.
You can learn more about our CISSP MasterClass here: destcert.com/CISSP
Link in the description below as well.
If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.
I will provide links to the other MindMap videos in the description below.
Thanks very much for watching! And all the best in your studies!
