CompTIA CYSA+ CS0-002 – Mitigating Vulnerabilities Part 2

4. Hardening and Patching (OBJ 1.3)

Hardening and patching. In this lesson we’re going to talk about two key terms. And I know I’ve used these words before, but we’ve never really defined them. These are hardening and patching. Now, when I talk about system hardening, this is the process by which a host or other device is made more secure through the reduction of a device’s attack surface area. Now, what does that mean when I talk about an attack surface area? Well, when I talk about an attack surface I’m talking about the services and the interfaces that allow a user or program to communicate with a target system. This allows all of these different services that are there to be vulnerable for somebody to attack them, right? And that’s the idea of system hardening. This I want to close down as many of those as I don’t need because that will end up hardening my system and reducing that attack surface.

Now, any service or interface that is enabled through the default installation and left unconfigured should be considered a vulnerability. And so you should scan that, you should identify it and then mitigate or remediate that based on what you need to do as part of your system hardening. Now, when we start talking about system hardening, I have this wonderful system hardening security checklist. These are ten major areas that you need to check when you’re trying to harden a given system. First you need to remove or disable devices that are not needed or used. For example, are you using WiFi? If not, disable it and take out the WiFi card. Are you using a CDROM or a floppy drive? If not, take those things out. Anything you don’t need you should remove or disable because anything you don’t need is another thing that’s open and could be used by an attacker and that makes it part of our larger attack surface.

So by removing it, we are going to harden our system and reduce the attack surface. The second thing is we want to install operating system application firmware and driver patches regularly. If Microsoft knows there’s a vulnerability in Windows and they put out a patch on Patch Tuesday, you should be downloading that patch, testing that patch and then deploying that patch across your network because you want to make sure you are patched regularly and up to date with the latest security precautions. Because if somebody has a patch out there, bad guys will usually reverse engineer that patch and create an exploit. So you need to make sure that you are patched to prevent those exploits from being effective against your systems. The third thing I want you to think about is uninstalling all unnecessary network protocols.

Now, what I mean here is not necessarily your WiFi, but instead all of those network protocols that might be used on your system. Are you running a web server if you’re not closed port 80? Are you running a mail server if not, closed port 25? Are you running an SSH server if not close. Port 22 as a standard workstation, you really should have no ports that are open unless you have something open for something like a host based intrusion detection system to be able to receive reports and send reports back. Other than that, everything should be pretty much locked down on a system. On a server you should only have the ports open for the services you need. So if you’re running a file server or a web server or an email server, those ports should be open, but everything else should be closed.

The fourth thing we want to look at is uninstalling or disabling all unnecessary services and shared folders. Anytime you have something that is open or shared or a service that is again, something that is increasing your attack surface. So again, you’ll see the common theme here anything you’re not using, go ahead and uninstall it or disable it. I prefer to uninstall it because that way nobody else can enable it. But if you can’t uninstall it, then you should at least disable it. Fifth, you need to enforce access control list on all system resources. This means if you have local system files or folders or shared files and folders or printers, all of those things have to be controlled using the appropriate access control list. And we’ll talk more about access control later on as we define the four different types.

But for now, just remember you want to make sure you’re enforcing access control using the appropriate ACLs. Number six, we want to restrict user accounts to the least privilege needed. You’ll hear this concept a lot in security always use least privilege. If you can do this with a user account and not use an admin account, go ahead and use a user account. If you’re a user, do you need to have admin rights? No, you just need to be able to access the computer and run your systems. And so you’ll have these different things like guests and users and super users and then admins. And you only want to use admin accounts when you have to because there’s a high level of privilege associated with them and that would also increase your attack surface. Next we want to look at number seven, which is to secure the local admin or root account.

And one of the ways to do this is by renaming it and changing the password. Everybody knows on a Linux system the root account is called Root. Everybody knows on a Windows system the administrator account is called administrator. So you should disable those two accounts and instead create another super user that is called something else. So instead of calling it Administrator, I might call it Jason Adm. Or if instead of calling it root, I might call it route. One, two, three, whatever you want to do to try to make it at least a little bit harder for the attacker is a good thing. And then always make sure you change that default password. If you have the default password of Tor for root, which is root spelled backwards, you are going to get hacked really, really quickly. And so you want to make sure you keep those things in mind and always change those passwords.

Number eight you want to disable unnecessary default user and group accounts. Again, if you’re not using it and you don’t need it, you should go ahead and disable it. This also helps harden your system and reduce your attack surface. Number nine we want to verify permissions on system accounts and groups. This is because we can see things that happen, like permission creep, where people gain permissions over time and they never get those permissions taken away. For example, I worked at one company for almost a decade and every time I moved positions, they added different security controls. They said, oh, well now you work in accounting, for instance, so you need these access to the accounting share drives, but you might still have your access to the human resource files because you were in human resources last.

And then you move over to the tech side and now you’ve got all three accesses. And so what should happen is every time you move to a new department, your permissions should get taken away and only the permissions you need should be added. This is the idea of verifying permissions on the accounts and on the groups. This should also be done routinely, whether that’s monthly or quarterly, against your entire system to make sure everyone has the right permissions for what they need. And number ten, you always want to make sure you’re installing anti malware software and you need to update its definitions automatically and regularly. So just having antivirus software on your computer is not good enough. It needs to check every single day for the latest updates and scheduled to automatically do it scans.

This will help keep your system protected. If you do these ten things, your system is going to be pretty strong and pretty well hardened. Now, the other thing you need to consider is how are you going to harden your systems against availability attacks. Remember, we have three sides of the triangle confidentiality, integrity and availability. Everything we just talked about was a lot to do with confidentiality and integrity, making sure our data is the way we want it to be and that only the right people can read it. But if we want to start focusing on availability, what can we do? If I have a server, it should be powered by an Ups or a battery backup. This will make sure that it can stay online even if the power goes down in the facility.

And that will give it enough time for your secondary power to come online, which might be a generator. For instance. This is the idea of how you can make sure you’re protected against availability tax that have to do with power outages. But power outages aren’t the only thing we have to worry about. For instance, in my area we have an issue with our primary Internet connection. If power is out in town for more than an hour, we lose our primary Internet connection. So we have a backup Internet connection, we have a backup cellular modem. In addition to that we have a backup microwave connection or a satellite connection. And so that way we have multiple different paths so we won’t be offline. That’s the idea of making sure you’re protecting yourself against availability.

Now, I only talked about power and Internet here, but there are lots of other things that are threats to your availability. And you need to think through these as you’re building out your server farms and your systems, because that is one of the ways you can harden those systems, is making sure they’re resilient against these availability attacks. Now, the last thing I want to talk about here is the second part of this topic. We talked about hardening, now we’re going to talk about patching and this comes down to patch management. Patch management involves identifying, testing and deploying operating system and application updates. As I mentioned, patches are going to be there to help you fix security bugs. When Microsoft knows there’s a bug in their software, they’re going to release a patch.

You need to identify that you have the appropriate software that needs to be patched. You need to make sure that you test that patch before installing it and then you need to deploy that across your network so everything gets updated. These patches are often classified as critical, security critical, recommended, and optional. If it’s a critical or a security critical, you probably should make sure you get those out quicker. If it’s something that’s optional, you could probably wait a little while on that. And again, this all goes back to your risk appetite and risk management. Now when you’re trying to conduct patch management at the enterprise level, you’re going to need some sort of patch management tool suite.

There are lots of different tool suites out there, but two of the most common are made by Microsoft. Microsoft has the System Center Configuration Manager or Sccm. And the Endpoint Manager. As you can see here on the screen. These are designed to support both Microsoft systems as well as having some ability to detect things on other systems as well. But really they’re primarily focused on Microsoft systems. Now one of the things you have to be aware of when you’re dealing with patch management is that just patching is actually an availability risk in itself because when I install a patch I actually can put that onto a critical system and then that system needs to be rebooted.

When I do that, that might take 510 15 minutes to reboot that server and that means that server is down for that time. So you need to make sure you’re planning when these patches are going to go out? You can’t just do it in the middle of the workday. You’re going to have to have a downtime window or a maintenance window for you to be able to install those patches to critical systems if you don’t have a fully redundant network that’s built. Luckily, most of our organizations have moved to the cloud. Now most of us have a fully redundant network built out, so we can take a single server offline, patch it, and then bring it back up. But if you’re still working with some of these older legacy systems, you may have to reboot the system manually and you may not have a backup.

And so that would be an availability risk that you have to consider. Finally, when we talk about patches, you have to remember that patches don’t always exist. You might have a piece of software that’s really, really old or a system that’s really, really old and manufacturer just doesn’t even exist anymore. They’ve gone out of business, in which case there is no patch available. Instead, you’ll have to use compensating controls. So if you’re looking for patches that don’t exist things like legacy systems, proprietary systems, ICS SCADA or Internet of Things systems and devices and you can’t find it, you may have to either take that thing off the network if you can assume that business risk or you’re going to put in compensating controls to overcome the fact that you can’t patch that vulnerability.

Now, what do I mean by this? Let’s say you had an older network file system and it requires port four four five to be open for it to be able to share those files. Well, we don’t want to have port four four five open to the Internet because that would be a vulnerability. So a compensating control, if I can’t patch this software against a given vulnerability, is to make sure that this file server is only available internal to the network and I can block it from getting out of the firewall or anything outside the firewall from getting to this file server. By doing this, I put a compensating control in place such as blocking port four four five from the Internet, and that can solve the problem of an exploit over port four four five that this older proprietary system may be vulnerable to.

5. Remediation Issues (OBJ 1.3

Remediation issues. In this lesson we’re going to talk about some of the issues you may face when you try to remediate a vulnerability. Now, there are numerous issues that can arise during attempts to remediate a vulnerability and some of these you can control and some of them you can’t. For instance, you need to ask yourself is the risk high enough to spend time and money on this particular issue? Again, I’ve mentioned this before, if it’s a $10,000 problem, you’re not going to spend a million dollars to fix it. And so it’s going to be hard for you to get the budgetary approval to fix that issue. So that way you wouldn’t be able to remediate that issue. Instead you’d have to accept it. You may ask yourself, can I use a compensating control instead? Well, possibly, depending on what that thing is.

For instance, if you have a web server that’s vulnerable on port 80, you can’t just shut down port 80 because you would stop the function of the web server. And so in that case, a compensating control couldn’t be used. But there may be some other control you can put in place. And so these are the things you have to think about as you go forward. Now, what are some of the main places that we have issues? Well, we have issues with legacy systems and proprietary systems. We have issues with organizational governance, we have issues with business process interruption, degrading functionality and MoU and SLAs. In this lesson we’re going to talk about all of these topics. Now, the first one is legacy systems. What is a legacy system? Well, I like to think about a legacy system as something old.

It’s a computer system that’s no longer supported by its vendor and so no longer can be provided with security updates and patches. For instance, if you work in a manufacturing plant, there might be some system that is critical to your operations, but it is 20 or 30 years old and the person who made that is no longer in business. Well, you’re not going to get any more security updates for patches for that thing, but it still works and it still runs and it might cost you millions of dollars to replace it. So what do you do? Well, you don’t patch it. Instead you start finding compensating controls like isolating it onto its own network and things like that to make sure that that system can keep running and keep the business operating.

So when we’re dealing with legacy systems, we’re dealing with these old systems that are no longer supported. On the other hand, we have another category of systems that are often not supported well and these are proprietary systems. Proprietary systems are systems that are owned by its developer or vendor, where the lack of vendor support could be an inhibitor to your remediation. Now, what do I mean by this? Well, I have a couple of proprietary systems in my business. It’s particular software that we have had coded by a developer. Now we don’t actually have the coder on staff, it’s a third party company. And so if we need to have updates and security done, we have to contract them again to get them to support it because we pay them and they fix the system.

Now that’s one simple example of a proprietary system, but there’s actually larger ones too. For example, if you look at the US department of Defense, they’ve got lots of proprietary systems. Not anyone can just go out and buy an F 16 or an Abrams tank. These all have different systems that were built specifically for that purpose. And so they can’t go to Microsoft and say, hey, give me a patch for an Abrams tank. Instead they have to go back to that original vendor and depending on the contract they have in place with that vendor, they might get monthly updates, or every six month updates, or every year updates, or as required updates. And so that can actually inhibit your remediation. Because if you’re on a six month cycle and you identify a vulnerability today, it might take six months for them to code you a patch and then send it to you.

So these are issues you have to think about when you’re dealing with proprietary systems. Another hindrance for you is organizational governance. Organizational governance is the system by which an organization makes and implements decisions in pursuit of its objectives. Now why would this be a hindrance? Well, because a lot of organizations don’t value security. Now if you work for a cybersecurity company, they probably care about security. But if you work for something like a hospital, they care about security. But that’s not their top priority. Their top priority is making sure that patients get the health care they need. And so these organizations tend to be run by doctors and hospital administrators, not security professionals.

And so organizational governance may put you at bay and say you can’t patch those systems right now because what if you had to patch all the X ray machines in a hospital and it’s going to take them down for two days? They’re not going to allow you to do that. They’re going to say we’re just going to keep operating them, right? And they would have to find out some alternate way to be able to get those things patched because they can’t take them all down at once. So this is the idea of organizational governance. Sometimes that organizational inertia, that governance that tells you how you’re going to do things can really handcuff you as a cybersecurity professional. So keep that in mind. This brings us to another similar concept known as business process interruption.

Now business process interruption is any period of time when an organization’s way of doing business operations is interrupted. And this can be caused by an outside force, but it can also be caused by our own security personnel. I mentioned previously, if you’re going to install a patched to a server and you have to reboot that server, it might take ten or 15 or 20 minutes for that server to come back online. During that ten or 15 or 20 minutes, that server isn’t doing its job. You have now interrupted the business process and so you would have to figure out when is the best time to do this. You may find out at two in the afternoon. This thing needs to be patched right now, but your business doesn’t close till eleven at night.

What are you going to do? Most likely you’re going to try to put some kind of compensation in place, additional monitoring in place and wait until the business is closed and then do the update overnight. This is why a lot of security people end up working overnight shifts because we’re working while the other people in the business are actually sleeping. Because what we do could affect their business. Now this becomes harder when you start dealing with 24/7 operations. Amazon. com never sleeps. Deontraining. com never sleeps. It’s available 24 hours a day. So we had to build our systems in place so that we can work through these problems and we can still do our security patching and updating without interrupting our business processes. Another thing you have to worry about is degrading functionality.

Now degrading functionality is a period of time when the organization systems are not performing at peak functionality and this could lead to business process interruption. For instance, let’s say I have two web servers that are forward facing to the internet and I’m there behind a load balancer. Can I take one down and patch it while the other one carries a load? Yes, I can. But I’m now going to be in a degraded condition because I only have half of my capacity while the one is offline being repaired. Then when I bring it online, I can bring the other one offline and do the same thing. That’s one way that we do our patching of our systems is that way we can take one offline, patch it and bring it back on.

By doing that, because we have the redundancy built in, we can minimize our business process interruption. But if that one server that was online went offline because of an availability attack at that time, we would then be completely down. So we are operating in degraded functionality. We are only one of two servers up instead of two of two servers up. So we lost our redundancy there. That’s the idea of degrading functionality. The next concept we have to talk about is Memorandums of Understandings or MoUs. An MoU usually has a preliminary or exploratory agreement to express an intent to work together that is not legally binding and does not involve the exchange of money. Essentially, I like to call these handshake deals.

They’re not contractually binding, but I’ve used a lot of MoUs in my day. For instance, early in my career, I was based out of one building and I worked with another competitor who happened to be based out of a different building. And we had an MoU that if there was some kind of a major outage and my facility was down on power and their facility wasn’t, we could actually come over to their facility and work. And the same thing that if their facility was down and ours was up, they would come over to us and work. And so we had this friendly competitiveness between us where we actually helped each other because we weren’t direct competitors, but we were in the same general business space. And so we had a lot of the same equipment, a lot of same phone lines, a lot of same computer systems.

And so that worked out well, but there’s really nothing to hold either of us to it. If it was a really bad day and their power went out and my guys were all busy, I would say, sorry, I’ve got no room for you. There’s nothing you can do about it. There was no contract, right? And that’s the idea of an MoU. It’s just kind of a gentleman’s agreement, if you will, or a handshake deal. Now, on the other side of things, we have a service level agreement, and this is really where you want to get to when you’re starting to deal with third party contractors and vendors. This is a contractual agreement that sets out the detailed terms under which an ongoing service will be provided.

So if I’m going to buy a proprietary system from somebody, I shouldn’t have an MoU that tells me how they’re going to support me. I should have an SLA. That SLA should give us terms for what kind of patch support they’re going to give us and what kind of forensic support and instant response support and things like that. Anything can be contractually binding inside of this SLA. For instance, I have an SLA with my underlying service provider for our website. They have a 99. 99% uptime. Now, if they don’t maintain that 99% point 99% uptime, that means they’re actually going to have to refund us money because they’re not meeting their portion of the SLA. That’s the idea of an SLA. There are terms and there are consequences if that agreement is broken because it is a contract.

• Category: Uncategorized