Operating System Security – CompTIA Security+ SY0-501 – 3.3

| December 8, 2017


Maintaining the security of our operating systems is an ongoing necessity. In this video, you’ll learn about patch management, least functionality, application management, and other OS security requirements.

<< Previous Video: Hardware Security Next: Peripheral Security >>


When securing operating systems, there are some broad categorizations that you can consider when you’re planning your security strategy. One broad category of operating systems is a network operating system. This OS is focused on connecting many different devices together over a network connection.

Another type of OS might be one that focuses on providing a particular service. For example, you might have a web server or a database server, and that particular system is dedicated to providing that function.

And a very well known operating system is the workstation’s operating system, the one you use at your desk to be able to perform email functions, use your office applications, or browse the internet.

Some operating systems may be built and designed to be used in a purpose-built appliance. In these situations, the end user may never really see the underlying operating system. It’s usually also a very minimal operating system that’s designed to work on that hardware.

Another category of operating system is one that might go into a kiosk, like the ones that you see here at an airport. In these devices, they’re very public computers and the operating system is locked down so that you can only perform specific functions available from that kiosk.

And the last category of operating systems we’ll discuss are those specifically designed to run on mobile devices. Your mobile phones and tablets have very specific input and output requirements and you need an operating system designed to work with these portable platforms.

We often mentioned that an important security consideration for your operating systems is to always have the latest versions of patches installed onto those devices. This is more important than you might think. We have a number of vulnerabilities and security problems that have been identified that can only be resolved by installing these patches, and if there is a delay in installing these, it’s that much more time the bad guys can use to get into your system.

If you’re using an operating system that’s been around for a while, there may be a single large set of updates called a service pack. Microsoft is well-known for putting together a large group of patches and providing those as a single update called Service Pack 1, Service Pack 2, and so on. There are updates that are also released every month, so it’s very common to install the latest service pack and then to include all of the monthly updates since that service pack has been released.

If these security patches are planned to be released at a set time every month, it makes it easier for the security team to plan their testing and deployment process for those patches. But occasionally, a security vulnerability will be found that is more emergent and a patch needs to be installed immediately. You see this very often four zero-day discoveries that need to be patched as soon as possible. In those cases, the manufacturer tends to go out-of-band of those normal releases, and updates the security patch as quickly as possible. You then need to make sure that you’re staying up to date with all the large service pack updates, all of your monthly updates, and any out-of-band updates that might come through, as well.

If you’re using the Windows operating system, you can use the built in utility, Windows Update. You can bring this up on your workstation and see all of the previous updates that have been installed and any updates that may need to be applied to your workstation. These Windows updates can also be managed through a central console, for example, the Windows Server Update Services. This is a centralized view of all of your systems where you can manage updates and software patches for everybody who’s on your Windows domain.

If you’re using Mac OS, you may find a software update option under the Apple menu. Newer versions of Mac OS have integrated all of these patches into the App Store, and so the Apple menu option is changed to show App Store instead of Software Update.

If you’re using Linux, the options available to you for performing updates may depend on the distribution that you’ve chosen. So you might use yum or apt-get, or there might be a graphical front-end that you can use for doing all of your OS updates.

If you’re managing a large group of operating systems that need to be updated, then this process may require a little bit of planning before you begin rolling out the patches. That’s because sometimes, installing a patch onto a system may introduce other problems with the operating system or problems with the applications that you use on that operating system. Remember that you don’t have to deploy all of the patches that are available, but you do want to make sure you get the ones that are security-related. And, of course, this is something that’s important to manage centrally, that way you can download the patches, test them, and then tell your management server how and when to roll out all of the patches to all of your systems.

Every service you’re running on your operating system has the potential to cause some type of security problem. We never know exactly which one of these services is going to have a security vulnerability and there’s nothing more frustrating than having a zero-day vulnerability that makes your system less secure, especially when that vulnerability is associated with a service that you don’t even use.

Unfortunately, it may be difficult to determine what services are necessary and which ones are unnecessary for the way that you use your operating system. A good example of this is in Windows 7, where there were over 130 services included by default. In Windows 10, this number goes up to 240. That means you may have to go through quite a bit of research to determine which of those 240 different services are necessary on my operating system, and which ones can we disabled by default.

Although you may be able to find a lot of information about these services on the manufacturer’s website or from third party sites, sometimes it takes some trial and error to determine if a particular service is important for the way that you use your operating system.

Here’s the list of services from my default Windows 10 desktop, and I have to determine which of these services are necessary and which ones are not necessary for the use of my system. You can see how difficult it might be to go through every single one of these services, research and understand what the purpose of that service is, and then determine on whether you can disable or enable that service in your operating system.

If you want to minimize the security risk of an operating system, then you need to limit what that operating system is able to do. You need to examine the requirements for a particular workstation or operating system and then get an understanding of what the least functionality would be for that particular OS. This least functionality may vary widely, depending on how a particular operating system is used. For example, someone in shipping and receiving would have a very different set of functionality than somebody who’s working in IT development, and both of those would be very different than a system that you’re setting up to be a kiosk.

This means that you need to examine many different aspects of how this particular operating system might be used. If you want to tighten things down, you might disable printer installations, disable the changing of the system time on that computer, disable taking ownership of file system objects, and configure your system so that services are not able to log on to the operating system.

You’ll eventually begin to build a very fine-tuned secure configuration for your operating systems. The idea is to provide all of the functionality needed for the user, but also maintain the security of the OS. A lot of these secure configuration settings will apply regardless of how the operating system is used. If it’s a Windows operating system that’s used in shipping and receiving or Windows operating system that’s used as a kiosk, there will be similarities for the security posture of both of those operating systems.

For example, we might want to configure all of our systems to stay updated automatically with the latest patches. If we do find a system that has been compromised, we’re not going to clean the OS, we’re going to completely delete everything on that system and re-image from a known good image. Once you have built this standard configuration, you want to be sure nobody makes any changes to it unless you go through a formal change control process. And you’ll want to perform regular integrity checks to make sure that once you’ve installed this system and implemented the secure configuration that nothing has changed with the OS.

Fortunately a lot of the work on categorizing what a secure operating system might look like have already been documented. One example of this is the Common Criteria for Information Technology Security Evaluation. You may hear this referred to simply as Common Criteria. It’s an international standard that designates exactly what type of security controls are implemented in an operating system. We reference these control levels as Evaluation Assurance levels, or EAL. You’ll find there are different levels between EAL1 through EAL7. When an operating system is EAL compliant, we tend to call it a trusted operating system. It’s very common, in fact, to call EAL4 as the accepted minimum level for security in this Evaluation Assurance Level scale.

Applications that are running in your operating system could be dangerous. It might be an application that’s designed to take advantage of a vulnerability, it might be an application that looks like one thing, but instead is something malicious– like a Trojan horse– or it may be malware that’s sent to us as an email attachment and we inadvertently click and infect our system.

In most operating systems, you can set security policies that will allow or disallow certain applications from executing. You might perform a whitelisting policy which only allows a certain list of applications to execute. Or your policy may be a blacklisting policy that allows all applications to execute, except this list of blacklisted apps. Whitelist is going to be very restrictive– nothing is going to run unless it’s on the whitelist. This also means that you, as the security administrator, will be required to maintain and update this list as new applications are approved by the organization.

The blacklist is the opposite– there is a list of known bad applications that will not execute in this operating system. Often, this list is provided by a third party or from your anti-virus or anti-malware software.

The options for performing blacklisting and whitelisting may be based around the operating system that you’re using, but you might have a number of options available, such as an application hash. You can define a particular executable and then assign that executable as being able to run or not being able to run in your system. You might also want to set policies for certain applications that are digitally signed by a particular publisher. For example, you may decide in your environment, that all applications that have been digitally signed by Microsoft and by Adobe are able to run in your network.

You might also want to set a certain path so that only applications that are running from a protected path on your network are allowed to execute.

And lastly, you might want to set these applications to only run if you’re in a particular network zone. For example, certain applications would only be able to work on the corporate network and would not be able to work on a public network.

Our operating systems often include a number of different user accounts, so it may make sense to disable any accounts that you’re not specifically using. For example, there might be a guest account configured in your operating system by default. By disabling the guest account, you’re creating limits on what someone’s able to do on your system. Many of these user accounts then can be disabled or deleted completely. And you may want to tell your system to disable any interactive logins for accounts that are used as services, that way, only actual users are able to log in interactively to your operating system.

Category: CompTIA Security+ SY0-501

Comments are closed.

X