Patching and Change Management in CISSP Domain 7: A Deep Dive

Introduction

Hey, I’m Rob Witcher, 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

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.

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.

Or 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.

Whitelist

One method of doing so is whitelists. We create a list of programs that are allowed to run on the system, a whitelist, and any software that is not on the list, like malware, is not allowed to be installed and executed on the system.

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, baselines, and disaster recovery plans.

Overview

And that is an overview of pathing and change management within Domain 7, covering the most critical concepts to know for the exam.

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!