Section 2.5 Patch Management

As you study this section, answer the following questions:

• Why are patch management systems necessary?
• What is the intent of patch testing?
• What are the benefits of centralized operating system, application, and device management?

In this section, you will learn to:

• Configure password policies
• Manage certificates
• Analyze passwords using rainbow tables
• Configure account password policies
• Manage certificates

The key terms for this section include:

Description of the Table

Description of the Table

Term	Definition
Operating system, application, and firmware patching	Operating system, application, and firmware patching is updating existing software on a computer or device to fix bugs, address security vulnerabilities, and improve overall performance.
Patch management	Patch management can be a manual process, an automated process, or a combination of both. Patch automation is essential but often requires occasional manual work to address problems related to deployment or installation errors.
Patch testing	Patch testing verifies a patch's functionality and compatibility before deploying it on a computer or device. It is an essential part of the patching process, ensuring that the patch does not cause any negative impacts on the system and its components.

This section helps you prepare for the following certification exam objectives:

Exam	Objective
CompTIA CySA+ CS0-003	2.5 Explain concepts related to vulnerability response, handling, and management Patching and configuration management Testing Implementation Rollback Validation Maintenance windows
TestOut CyberDefense Pro	3.1 Implement security controls to mitigate risk Detect unpatched systems 3.2 Implement system hardening Check service configuration 5.1 Implement Identity and Access Management (IAM) Manage certificates Configure account policies and account control

2.5.1 Software Patching and Host Protections

This lesson covers the following topics:

• Operating system, application, and firmware patching
• Patch management
• Patch management considerations
• Patch testing

Operating System, Application, and Firmware Patching

Operating system, application, and firmware patching is updating existing software on a computer or device to fix bugs, address security vulnerabilities, and improve overall performance. The patches may include updates to existing features or introducing entirely new features. The patches are developed by the software developer and released periodically.

The volume of software vulnerabilities and related patches and updates continues to expand ever-increasingly. Managing and applying patches is time-consuming and necessitates a centralized patch management system. Patches are inevitable and apply to various operating systems, application software, cloud instances, and device firmware.

Patch Management

Patch management can be a manual process, an automated process, or a combination of both. Patch automation is essential but often requires occasional manual work to address problems related to deployment or installation errors. For example, administrators might develop custom scripts to help patch management systems more accurately identify missing patches, search for specific hardware information, or gracefully stop and start system services before patching.

An effective patch management strategy requires patch management software to be configured based on the risks associated with each system and its applications. Mission-critical systems must be treated differently than less critical ones to support availability requirements. Desktops are often patched as quickly as possible after a brief testing phase.

Testing, implementation, rollback, and validation are all crucial parts of the patching and configuration management process:

1. Testing consists of verifying the functionality and compatibility of a patch before deployment, as well as any potential risks it poses to the system.
2. After the tests have been conducted, the patch can be implemented on the computer or device.
3. In the event of a problem, the patch can be rolled back to avoid further disruption to the system.
4. Finally, the patch must be validated to ensure it is effective and secure before deployment.

Patch Management Considerations

Important patch management considerations include the following:

• An individual or task-specific team responsible for reviewing vendor-supplied newsletters and security patch bulletins.
• Mechanisms to patch operating systems and all applications running on them, regardless of application vendor.
• Patch management principles that incorporate cloud resources.
• Assigning updates into urgent, important, and non-critical categories.
• A patch test environment where urgent and important patches can be installed, tested, and analyzed before deployment into production.
• Detailed logging designed to support monitoring and troubleshooting of patch deployment activities.
• A method to evaluate firmware updates before deployment.
• Immediate push delivery of critical security patches.
• A routine schedule for the rollout of non-critical patches.

Patch Testing

Patch testing verifies a patch's functionality and compatibility before deploying it on a computer or device. It is an essential part of the patching process, ensuring that the patch does not cause any negative impacts on the system and its components. Patch testing typically consists of simulating the environment that the patch will be deployed to so that the patch can be tested in a secure environment. The results of patch testing provide insight into the stability and security of the patch, allowing the software developer to make necessary adjustments before releasing the patch.

Patch testing aims to determine whether a software patch creates problems with the organization's unique mix of hardware, software, and configuration settings. Patch testing should primarily involve testing a patch on a single isolated system to determine whether a patch causes problems, such as software crashes or system instability. Additionally, testing should validate those issues addressed by the software patchwork as expected. For example, a patch successfully removes a vulnerability. A common way to test a patch is by setting up a non-production environment hosting like-for-like mission-critical applications, including enterprise applications and networking systems (where available). Doing this allows patches to be deployed by infrastructure teams, validated by software support staff, and assessed by security teams before deployment into the production environment. Additionally, vulnerability scans should verify that patches only resolve vulnerabilities and do not introduce any new ones!

2.5.2 Configuration Management

This lesson covers the following topic:

• Centralized operating system, application, and device management

Centralized Operating System, Application, and Device Management

Centralized operating system, application, and device management is a process that allows for the management of multiple systems, applications, and devices from a single location. This allows administrators to easily manage, update, and configure various systems, applications, and devices on the network from a central server instead of performing these tasks manually. Centralized operating system, application, and device management also allow for automated patching and configuration management processes, ensuring that all systems, applications, and devices are updated with the latest patches and configurations.

A Centralized Configuration Management System (CCMS) should be used to implement this. A centralized configuration management system allows an administrator to define device configuration settings on a management server and then push the settings to endpoints in an automated way.

Centralizing configurations enables consistency as the configuration is defined once and applied to many systems. Additionally, the configuration is enforced, meaning the central management server will overwrite changes made to an individual endpoint's configuration. As a result, the central management server can provide near real-time visibility into configuration changes. Near-real-time visibility into device configurations enables continuous compliance monitoring. When a secure configuration is centrally configured and controlled in this way, any changes to it (on an endpoint) will generate an immediate alert.

Examples of configuration management tools include the following:

• Chef - https://www.chef.io/
• Puppet - https://puppet.com/
• Ansible - https://www.ansible.com/
• Terraform - https://www.terraform.io/

The following video discusses the importance of configuring and implementing endpoint security controls:

Video

Click one of the buttons to take you to that part of the video.

Configuring & Implementing Endpoint Security Controls 00:00-08:05 James Stanger: Well, welcome everybody. We're gonna be talking about implementing endpoint security controls. And to that end, I've got Gareth Marchant here. Gareth, how you doing?

Gareth Marchant: Hi, James. Great. Happy to be here.

James Stanger: It's good to have you here, 'cause we're gonna learn from your wisdom about what it means to kinda configure these controls—things from hardening techniques to talking about what trustworthy computing means and various compensating controls. So, Gareth, tell us a bit about your background, and then let's start talking about security controls.

Gareth Marchant: Yeah, sure. I've been in the IT field for well over 20 years now. I've worked in private sector, public sector, local governments, federal government agencies, and I've been doing training education work now for the plus side of ten years.

James Stanger: And you've done that in the U.S., in the U.K. You have a global presence.

Gareth Marchant: Yeah, indeed, I have had a lot of opportunity to teach law enforcement agencies in the U.K. And actually, I once had an opportunity to teach for NATO over there in Belgium. So, it's been a lot of fun.

James Stanger: You know, I've been talking to CIOs and CISOs over the last year and a half or so, and the message is pretty clear: with various issues—whether it be COVID or the attacks that are going on—the idea of the perimeter is effectively dead, right?

Gareth Marchant: Yeah.

James Stanger: So let's focus on endpoints. When it comes to the endpoints there, first of all, let's define what endpoint means these days.

Gareth Marchant: So, it's so true. What does the computer look like anymore? I mean, for so many people, their computer is a phone. You know, that whole idea of a computer is different. People are doing more things with phones and tablets than they've ever done before. But, you know, an endpoint could be for any one person, it could be their phone, their tablet, their laptop, or maybe even a desktop. So it's become very dynamic and sorta difficult to track.

James Stanger: And so we're also seeing endpoints—whether in the military they're using drones, for example. We're seeing operational controls get IP enabled, so now we're seeing, whether it be pipelines, tanks, the electrical grid, et cetera, things like that. So, endpoints have certainly changed. So what does it mean to harden them these days? 'Cause we could talk about, "I remember the good old days." You know, you get rid of all those ports, right?

Gareth Marchant: Yeah.

James Stanger: Or only use the port for the business and all that. Which is part of it, but, you know, there was getting rid of those unnecessary services. But what are some of the more advanced things that people are doing?

Gareth Marchant: So, you know, especially as we talk about the perimeter really dissolving and the idea of, you know, what's inside and outside, has really sort of gone away. And everything is connected now. You know, everthing's on the network. You know, nothing's really operating in a bubble.

And so, you know, one of the things is perhaps—it's not very glamorous—but knowing what's there; understanding what devices are out there; what they do; what they run; what they should be doing; what the expectations are for those things to do; how they should be communicating; what they should be communicating with; and really understanding all of those things to then be able to restrict them in a way that they can only do those things.

You know, on the individual device, limiting its capabilities for sure. But then, you know, isolating and segmenting these things in ways that are appropriate so that they can only communicate with what they need to, 'cause if these things are breached or attacked, their ability to communicate with other things can be the difference between this being sort of a quick incident that we can resolve, you know, in a few minutes, or, you know, a widespread company outage.

James Stanger: It's interesting you bring up incident response. So, it seems to me that if you proactively implement, say, shell restrictions or ASLR, these different things, it basically makes incident response truly possible. Is that about right?

Gareth Marchant: Yeah. Well, you know, prevention can only get you so far, and doing things like, you know, allow lists and block lists and leveraging the capabilities of the hardware platforms, making sure things like data execution prevention and these things are turned on and being used, is really important.

To try to stop it in the first place is one of things we're trying to stop.

But I think it was the former director of the FBI was credited with saying there's two kinds of organizations, right: those that have been breached and those that don't know that they've been breached yet.

James Stanger: haha.

Gareth Marchant: And so, you know, you have to assume this is gonna happen. If they can attack, you know, large scale super advanced companies like, you know, Twitter and Intel and Facebook and the Pentagon, for heaven's sake, what hope do we stand? And so, you know, building out an infrastructure in a way where you can get visibility into what's happening and know what normal looks like so you can get early warning and respond to these things before it turns into a tragedy—that's really where endpoint detection response comes into play.

James Stanger: And it seems to me as though there's two pieces of this: the visibility, right? And back in the day it was antivirus, but now we have so many more granular things. But it's interesting you used the term segmentation. It's like a microsegmentation of whatever computing device, so that you can get in trustworthy computing elements. You could put in, you know, whether it be shell restrictions or disabling, you know, kind of enabling the no execute and never execute bits. So we're getting very, very specific in there. 'Cause once that rogue process is in, it's all about trying to stop the spread, right?

Gareth Marchant: Yeah, exactly. It serves two purposes. You know, one, it stops that rogue process from being able to do what it tries to do, but then on the flip side of that, because of being able to define exactly what I expect to occur at the endpoint, when something, you know, some sort of variance from that, I can tell really quickly that something's not right, so it's gonna block it, but it's also gonna let me know, you know, something's not quite right here.

James Stanger: Very good. And so, let's talk a bit about some of these compensating controls that are often put in there 'cause people talk about host based intrusion detection systems. You know, some sort of agent or even agent-less type of thing listening in on there. What are some of the capabilities these days, these things seem to have?

Gareth Marchant: So, you know, obviously, you know, essential malware protections that we've sort of seen for decades now, right? But so much more than that. You know, long gone are the days where you had this endpoint protection that would periodically download signature. That just doesn't work, right? I mean, the ability to create, you know, these dynamic pieces of malware that can avoid detection, I meant, there's lots of different way to do that. I'm sure many YouTube channels that attest to that.

So, you know, we need all the help we can get. And so being able to have something on the endpoints that have some sort of a threat intelligence connection to it that can let me know and reduce that time frame between when a new type of attack has been identified and what that looks like, so my endpoints can tell what that is.

Those kinds of capabilities are the kinds of things, you know, that we need now. There's no chance for me to sort of put some simple static, you know, endpoint protection software in place and think that that's gonna protect me against some of the stuff that's out there, because, you know, as these new things come out, you know, globally, you need to know about them as quickly as possible because they can spread in a heartbeat, like we saw with NotPetya for example.

I mean, it just went from, "Hey, there's this thing out there," to, "Boom," right? The internet was infected. So we need to know quickly, and having those capabilities to detect early is essential.

James Stanger: And so the whole point about these endpoint security controls is to allow organizations to pivot more quickly and more intelligently. Is that fair enough?

Gareth Marchant: Yeah, exactly. I think that's a great summary.

James Stanger: Well, thanks so much, Gareth, for your perspective on this—talking about endpoint security controls. We'll talk to you more about a few things later.

Gareth Marchant: That sounds great, James. Thanks so much for the opportunity to talk about it.

James Stanger: Yeah, man.

2.5.3 Configure Password Policies

Click one of the buttons to take you to that part of the video.

Configure Password Policies on Windows 00:00-00:18 In this demonstration, we're going to talk about password and account lockout policies. Enforcing these policies on a Windows workstation can dramatically increase the overall security of your system, so it's important to understand, at very least, the basic measures you have available.

Password Policies 00:18-01:03 We want to accomplish two things with the password policies in this lesson. First, we want to make it so that an attacker can't keep trying passwords over and over without any ramifications. Second, we want to make sure that the passwords users define for their accounts are strong, meaning that they're not too easy for an attacker to guess. For Windows computers that aren't part of a domain, which is the case here, these password policies are found in Local Security Policy.

So, let's come down here and search for Local Security Policy. We go to Account Policies to see a list of all the available options. Let's start with password policies. These policies are going to define the parameters that users will have to stay within to create accounts on our system.

Minimum Password Length 01:03-01:48 First off is the Minimum password length policy. Notice that it's set to 0 by default, meaning that there's no minimum password length right now. With the policy configured like this, I could make a password that's one character long. That's a really bad idea.

Basically, the longer a password is, the harder it's going to be to guess. Right now, the industry standard is at least eight characters. Longer is better, assuming you can remember it. Let's go ahead and just use 8 for our purposes today. When you define this length, you do need to be careful. If you're security conscious, the temptation is to crank this number way up to 14 or more.

Remember that the longer you make a password, the more difficult it is to remember. And the more difficult a password is to remember, the more likely it is that your users are going to write it down somewhere, so just always keep that in mind. Let's click OK to move on.

Password Complexity Requirements 01:48-02:54 Next we want to look at the Password must meet complexity requirements policy. Notice that this is disabled by default. Let's go ahead and enable it.

We'll go over to the Explain tab to learn what this policy actually does. Right here it tells us that if this policy is enabled, passwords have to meet the following minimum requirements: It can't contain the user's account name or parts of the user's full name that exceed two consecutive characters. It has to be at least six characters long, and it has to contain characters from three of the following four categories: uppercase characters A through Z, lowercase characters a through z, numbers 0 through 9, and non-alphabetical characters like !, $, #, %, and so on.

Alright, our policy is enabled now. A user's password has to contain characters from at least three of these four categories. It's important to note that when we turn this policy on, it's not actually going to be enforced on existing passwords. It'll only be enforced the next time the user changes their password. If we click OK, it shows us that it's enabled.

Now we have a minimum length set to 8 characters, and we've specified that it need to be complex as well.

Maximum Password Age 02:54-03:27 Next, we need to look at the Maximum password age. Right now, it's set to 42 days. This parameter specifies how long a user can have the same password. Previous guidelines suggested that the longer a password is in use, the more likely it is to be compromised. Recent research suggests, though, that changing passwords frequently can actually make you more vulnerable to security breaches. Regardless, Microsoft still recommends frequent changes.

Let's go ahead and set a maximum password age of 30 days. Users will be forced to change their passwords every month. Seems reasonable. I'll just click OK to move on.

Enforce Password History 03:27-04:04 Now we need to look at Enforce password history. Right now, this option is disabled because it's set to 0, and no passwords are currently remembered. If we enable this policy, we're telling Windows to go ahead and remember a certain number of past user passwords.

If we do, users won't be allowed to reuse any of those old passwords that Windows kept in memory. Since the value is 0 right now, a user could just keep using their password over and over again. That's not very good from a security standpoint. We'll tell Windows to remember 5 passwords. That means the user has to use five unique passwords before they'll be allowed to reuse a previous one. We'll click OK again.

Minimum Password Age 04:04-05:22 Now let's go to Minimum password age. This policy is a little bit confusing to new system administrators. A maximum password age makes sense, right? We don't want users to have the same password for a long period of time, but why would we care about setting a minimum password age? Why would we want to set a barrier for how long a user has to keep the same password before they change it?

The issue here is that some users want to keep using their favorite password, and so they'll use that password over and over. But since we've enforced password history, they have to use five new passwords before they can use an old password again, anyway, right? Well, some users are smart and will just change their password five times in a row within a few minutes so they can get back to their favorite password. That's why we set a minimum password age. Both these settings work in conjunction for better security.

Like the maximum age, this is set to 0 by default. Let's change that. I'm gonna go with a 5-day minimum. Now a user will have to wait 25 days before they can reuse an old password. I'll select OK again.

Alight, there's one more policy here under Password Policy that you should be familiar with. This is one that you should almost never enable. It's called Store passwords using reversible encryption. The only time you'd ever want to enable this is if you were on a very old network that uses older Windows NT systems. We're not, so we're going to leave it set to the default setting of Disabled.

Account Lockout Policy 05:22-05:48 Now let's take a look at Account Lockout Policy. The goal behind configuring account lockout is to prevent intrusion attempts. A common attack technique is for attackers to try one password after another on a given user account, hoping that they'll eventually find the right one. Account lockout policies configure the system so that it locks if someone tries to log in a certain number of times incorrectly within a given time period. If that happens, we're going to assume that they're not the real user.

Account Lockout Threshold 05:48-06:20 The first parameter we need to look at is the Account lockout threshold. This specifies the number of invalid login attempts we want to allow. Right now, it's set to 0. That disables the policy, and that's not a good thing because an attacker can just sit there and try one password after another until they find the right one. We want to provide the legitimate user with a few opportunities to enter the wrong password because that happens to all of us once in a while. I'll go ahead and give the user 3 invalid logon attempts. An authorized user should be able to get it right in that number of tries. I'll click OK.

Account Lockout Counter and Duration 06:20-07:16 Notice that when I do, this window suggests that we change the values of the other policies to the values specified here. It's going to set the Account lockout duration to 30 minutes and the Reset account lockout counter after policy to 30 minutes as well. That's fine with me.

Using these settings, you're going to slow an attacker way down. They'll only be able to try three different passwords inside of a 30-minute window before the account gets locked. And then we told the system to wait 30 minutes before they can try to log in again. This is especially important in today's world because password cracking has gotten pretty complex. There are password-cracking engines that can throw out massive amounts of data at a time from huge lists of words and phrases. Something like that could break a system's defenses in no time if you didn't have these precautions up.

Alright, at this point, we've greatly increased our system's overall security. If you compare the system security now to what it was when we started this demo, you'll see that it's going to be a lot more difficult for an attacker to break in and compromise our data.

Summary 07:16-07:28 And that'll wrap up everything for now. In this lesson, we talked about how to secure our systems by setting password and account lockout policies.

2.5.4 Manage Certificates

Click one of the buttons to take you to that part of the video.

Managing Certificates 00:00-01:50 In this demonstration, we're going to practice managing the public key infrastructure.

To do this, we'll use the Windows Server 2019 system that already has Active Directory Certificate Services installed, which makes it a certificate authority, or CA.

It's called Active Directory Certificate Services because the CA itself is integrated with Active Directory to authenticate certificate requests.

We're going to practice requesting, approving, issuing, and revoking certificates on the CA. In order to manage the CA, we need to launch the CA console by clicking Tools and Certificate Authority.

We can see here the CA itself and the certificate categories: Revoke Certificates, Issue Certificates, Pending Requests, and Failed Requests.

By default, the CA is set to automatically approve any new certificate requests. However, we don't want that to happen.

Instead, we want to move the certificate request to a pending state, here in Pending Requests, until an administrator comes through and manually reviews the request. Then he or she either approves or denies it.

To make sure that this is set correctly, we're going to right-click on the CA, go to Properties, go to Policy Module, go to Properties again, and we can see that it's already currently set.

We set the certificate request status to Pending. The administrator must explicitly issue the certificate. That's exactly what we want. So, we're going to hit Cancel and then Cancel again.

Now if you actually did make any of those changes, you would start and stop the service for the certificate authority before they would be pushed through. You have to do that here: Start and Stop.

Request a Certificate 01:50-03:20 With that setting checked, we want to request a new certificate now. There are two different ways to do this.

With the first method, I install the certificate authority and I also install the Certificate Enrollment Page. This allows users to request certificates using a web page running from the Internet Information Server Service on the CA itself.

Let's go ahead and open up Internet Explorer. We're going to point it to the right URL for the local host. There it is. It's going to be local host /certsrv. You see here the first task on the list is request a certificate.

Alright, we're going to come back to this window a little bit later. The second method is using the MMC console. Let's go ahead and right-click on the window. Go to Run, MMC, and hit Yes.

First, we're going to need to add some snap-ins. So, we're going to go Add or Remove Snap-in. We need the Certificate snap-in. Go to Add, My User Account, Finish, and Okay. The snap-in is here.

Now we can see all the different types of certificates that we can create for our current user. We're going to actually create one under Personal.

Go to Certificates, right-click, click All Tasks, and Request New Certificate. Go through Next, Next, Select User, Enroll, and Finish.

Approve a Certificate 03:20-05:41 Now let's go back to our CA console. If we go into Pending Requests, we can see that it was properly sent straight to our Pending Requests. It wasn't actually issued.

So, you can see this certificate is the original certificate that was issued when we created our CA. Let's go back to Pending Requests.

From this screen, we can view the pending request and see the request ID here.

This is where we can now request whether we want to approve or deny this certificate. If we right-click it, we have the option to issue or deny. Let's go ahead and issue this certificate.

Now the certificate request is gone from Pending. If we go to Issued Certificates, we can now see It's been officially issued.

If I wanted to use this certificate, I could open up a web browser and access the enrollment web page on the CA. Then I would click View the status of this certificate request right here.

Because it's approved, I can actually download and use the certificate at this point. We can also verify this by going back to the MMC console. If we go to Active Directory User Object and then Certificates, we can see the certificate that was just issued to my user account. This one right here.

We can see all sorts of information here. For example, who it's issued to, who it was issued by, and the certificate authority, which is our certificate authority.

We see the certification expiration date here and its intended purpose. So, that's a personal certificate. It's intended for EFS encryptions, securing email, and client authentication. It was created using the user certificate template.

If we double-click the certificate, we can view the date range when it's valid and we can go to the Details tab. Here we can view additional details about the certificate. And if we click the Certificate Path tab, we can view the certificate path up to the root CA.

In this demonstration, we only have one CA and there are no subordinate CAs. So, the certificate path is actually really short. But in many organizations, you'll have one or more root CAs with subordinate CAs associated with it.

So, the Certificate Path tab can be used to view the path through the subordinate CAs up to the root CA. Let's close this and go back to our CA console.

Revoke a Certificate 05:41-08:14 There may be different situations when the certificate shouldn't be used. For example, this is the case if the private key gets compromised in some way. In these situations, we should no longer use this certificate for encryption.

We would need to revoke it. To do this, we simply right-click the certificate, go to All Tasks, and to Revoke. You can specify a reason code for why this certificate is being revoked.

If you look, the last code is Certificate Hold. This is used in situations where you think there might be a problem with the certificate but you're not 100 percent sure.

We want to put the certificate on hold without fully revoking it so that we can verify whether or not it's an issue that would require it to be fully revoked or not. If there is no issue, we can take it off hold and continue using it. If there's a problem, we can fully revoke it.

If you were to use one of the other options here to revoke the certificate, such as Key Compromise, you couldn't unrevoke it. It's gone. You'll have to issue a new certificate. Let's go ahead and put it in Certificate Hold and hit Yes.

You see it clears out the Issued Certificates, and now it's on hold. Let's go to Revoke. You can see right here the revocation reason: Certificate Hold.

Because we just held it instead of revoking it all the way, we can unrevoke it. To do this, we right-click, go to All Tasks, and Unrevoke Certificate. Alright, it removed it.

If we go back to Issued Certificates, we can see the certificate is back for use again. Let's go ahead and do this again. But this time, go to All Tasks and revoke it for a different reason.

Let's go ahead and just say Key Compromise. Hit Yes. Alright, now it's revoked. If we go back to Revoked Certificates and we right-click, go to All Tasks, and try to unrevoke it, we can't.

We get this error: unrevoke command failed. Certificates can only be unrevoked if they're revoked with reason code Certificate Hold.

So, this certificate no longer can be used. You would have to reissue a new certificate in order for them to use it.

After you've revoked a certificate, you need to let everyone know that the certificate has been revoked and shouldn't be used anymore. This is done by publishing the latest Certificate Revocation List.

To do this, we go to our Revoked Certificates folder, we right-click, go to All Tasks, and then click Publish. This will publish the latest list of revoked certificates to the Certificate Revocation List.

Certificate Revocation List 08:14-09:24 There are two different types of Certificate Revocation Lists, or CRLs. You can publish a full CRL, which contains a list of all the revoked certificates. Or we can just publish a delta CRL which only contains the certificates that have been revoked since the last time the full CRL was published.

For our purposes, we're going to publish a new CRL because it's the first time we've actually published a CRL from this CA. Let's go ahead and click Okay.

If you forget to do this manually, it's okay because the CA should be configured to automatically publish the CRL at a particular interval. If we right-click, hit Revoke Certificates again, and go to Properties this time, we can see the CRL publishing parameters.

By default, the full CRL is published once a week and the delta CRLs are published once a day.

If we click the View CRLs tab, then click CRL, and then click the revocation list, we can see the current CRL and the certificates that were just revoked. Because this CA hasn't been in use very long, there are not many certificates to be revoked. Let's go ahead and close it. Click OK and OK.

Authority Information Access 09:24-10:44 Alright, now let's look at the properties of the CA. Let's right-click to Root CA and Properties. Alright, we're going to go to the Extensions tab. The Extensions tab has two acronyms that are very important to understand.

The first one is Authority Information Access, or AIA. The AIA allows end users to obtain the certificate used by the CA itself. This can be very useful if you have a root CA that is offline for security reasons.

This is not an uncommon configuration. Some organizations will keep their root CAs offline all the time to make them less susceptible to compromise. But we still need to have a copy of the root CA certificate.

To make this possible, we use AIA to publish a copy of the root CA certificate to some other location so that users can still access the root CA certificate. This is important because we need that root CA certificate with the CA's public key in order to verify digital signatures that the CA has implemented.

If the CA digitally signs something, you must have a copy of its public key to verify that signature. AIA makes that public key available offline. If we didn't do this and the root CA was offline, we'd have to figure out some other way to get a copy of that key.

CRL Distribution Point 10:44-11:44 In addition to AIA, we also have CRL and CRL Distribution Point, also known as CDP. This is where users go to get a copy of the latest CRL. The same issue exists here as exists with the root CA's public key.

If the root CA is offline, we can't access the CRL. We can't let everybody know which certificates have been revoked. What we can do is publish the CRL to some other location that clients can access.

For example, we can publish it to Active Directory via LDAP. We could access it on a web page, or we could put it in the file system.

Let's go ahead and click Cancel. If we go back to our Internet Explorer page, we can see there's an option to download the CA certificate or view the certificate chain or CRL.

This option, Download a CA certificate, is AIA. This one is CDP. If we click this option, we could download the latest CRL or the latest delta CRL.

Summary 11:44-12:15 That's it for this demonstration. In this demo, we talked about managing certificates in the public key infrastructure. We looked at how you request a certificate and talked about using manual approval of certificates. We talked about how to issue certificates and about how to revoke certificates.

We ended this demonstration by talking about how to make the CA's public keys available via AIA and also how to publish the Certificate Revocation List.

2.5.5 Analyze Passwords using Rainbow Tables

You are the security analyst for a small corporate network. Part of your role is to ensure secure access to the company website. You want to verify that the passwords being used meet the company's requirements. To do this, you captured some password hashes in a file named captured_hashes.txt and saved it in the /root directory. You want to use a rainbow table to analyze the passwords captured in this hash file to see if they meet the company's website requirements. Rainbow tables speed up the process of cracking password hashes. A rainbow table is a table of password and their computed hashes.

The password requirements for your website are as follows:

• The password must be eight or more characters in length.
• The password must include at least one upper and one lowercase letter.
• The password must have at least one of these special characters: !, ", #, $, %, &, _, ', *, or @
• All passwords are encrypted using an md5 or sha1 hash algorithm.

In this lab, your task is to:

• View /usr/share/rainbowcrack/charset.txt to determine which rainbowcrack charset includes all the characters required for your company's website password requirements.
• Use rtgen to create a md5 rainbow table using the values in the following table.

rtgen usage parameter	value
hash_algorithm	md5 or sha1
charset	Determine based on password policy
plaintext_len_min	1
plaintext_len_max	20
table_index	0
chain_len	1000
chain_num	1000
part_index	0

• Use rtgen to create a sha1 rainbow table using the values in the previous table.
• Use rtsort . to sort the rainbow tables.
• Usercrack . -l /root/captured_hashes.txt to analyze the passwords.
• Answer the questions.

The type of charset that can be used to create a rainbow table is stored in the /usr/share/rainbowcrack/charset.txt file. This file can be viewed using the cat command.

2.5.8 Maintenance Windows

This lesson covers the following topics:

• Understand maintenance windows
• Analysis of events
• Patch management

Understand Maintenance Windows

Many organizations adopt routine maintenance windows so administrators can perform maintenance tasks during these pre-established times. Maintenance windows enable preventative maintenance and consistent deployment of noncritical patches. All work planned during maintenance windows should comply with change management policies. Computers and devices are often restarted during maintenance windows, and various services are also modified, restarted, and added. Monitoring infrastructure must be able to correlate events like these to a scheduled maintenance window to adjust alert severity ratings.

Maintenance tasks typically fall into one of two categories:

Category	Description
Proactive	Proactive maintenance is designed to prevent future issues or safely perform work that may impact system performance. Maintenance windows are generally associated with preventative maintenance tasks, as reactive maintenance typically cannot be delayed.
Reactive	Administrators perform reactive maintenance in response to a problem or an outage.

Analysis of Events

Analysis of events occurring during maintenance is essential, as a savvy attacker might try to avoid detection by performing actions during these times. Knowing what will happen in a maintenance window is critical to help discern between authorized and unauthorized events. A poorly planned and managed maintenance window can be a nightmare for the SOC as it tries to manage a sudden surge in alerts and warnings generated by numerous services as they are added, modified, and restarted.

Patch Management

Patch management teams rely on maintenance windows to complete patch rollouts. The duration of the maintenance window can be a significant constraint.

Change management policy dictates that patching must finish quickly enough to accommodate rollback plans if trouble occurs without overrunning the maintenance window. Change management rollback is the process of undoing a system's changes to restore the system to an earlier, pre-change state.

Rollbacks can be performed manually or automatically, depending on the system, and are done to return a system to its previous state. The need for a rollback is not always obvious. Even after passing initial tests, some changes introduce issues that may not become apparent until a system is subjected to heavy workloads or scenarios that are not easy to test.

After changes have been made to a system, analysts must monitor it to verify that it is operating as expected. Monitoring often involves log monitoring (looking for errors or warnings) and performance monitoring (comparing characteristics against an established baseline).