Protecting against vulnerabilities is a constant challenge. In this video, you’ll learn about standard operating environments (SOE), unpatched systems, end of service life (EOSL), and more.
If many of you work in a corporation, you may have noticed that most of you are using similar laptops or similar desktop computers. If everyone has similar equipment, it becomes much easier to update, much easier to manage, and ultimately, much easier to secure. One of the things we have to worry about is someone bringing in a non-compliant system. This would be a system that is not part of the Standard Operating Environment or the SOE.
The SOE commonly consists of computers that have been thoroughly checked, a specific set of software has been installed, and everything on that system is up to date with the latest security requirements for the organization. And keeping these systems in compliance is an ongoing process. Every time there’s a patch or an update, we have to check that patch and make sure that it doesn’t affect the security of the system in any way. So if there is an operating system update, an application patch, or anything else that changes on that system, we have to test it before deploying it into the field.
Someone connecting a non-compliant system to the network makes an easy place for an attacker to gain access to all of your data. So we commonly put hardware and software in place to look for any of these non-compliant systems. For example, many organizations have an Active Directory infrastructure, and that allows them to set group policies to enable or disable aspects of the operating system.
Many organizations will also implement next-generation firewalls so that they can see every bit of data that’s traversing their network, and they know every application that’s in use. They can also set policies to allow or disallow access to individual applications. And one of the things that you probably don’t see are the ongoing scans occurring behind the scenes by your IT department to see if they can locate any devices on the network that shouldn’t be there.
An unpatched system contains known vulnerabilities that an attacker could use to gain access to those systems. For that reason, we are very diligent about making sure that we are patching and updating all of the systems on our network. You’ve probably seen this on Microsoft Patch Tuesday. This is the second Tuesday of every month where Microsoft releases the latest batch of updates for their operating systems.
Very commonly up until patch Tuesday, no one knew that those vulnerabilities existed. But the moment that Microsoft introduces those patches, the entire world is now informed of any security vulnerabilities. From that point forward, the race is on. Your organization needs to test all of these patches and then deploy them to every device in the network. At the same time, the attackers are writing exploits to be able to take advantage of these brand new vulnerabilities.
The winner of this race is going to be the one that is able to deploy these patches first, or the one that is going to create exploits first. If you’re going to win this race, you need to make sure that you have a process in place for testing and deploying these systems as quickly as possible. That’s easier said than done, because many organizations will have hundreds or even thousands of devices that need to be patched. This is why a lot of organizations have built an entire series of processes and procedures to push out these patches to every device as quickly as possible.
They also know that missing any of these devices could be a critical flaw. If a device doesn’t get these patches, then it will be susceptible to these new exploits. So we have to make sure that we are not only covering all of the devices on our network. We’re also making sure that we haven’t missed any of these devices during the update process.
We are constantly working to make this patching process more efficient. So as we are testing, prioritizing, and deploying these patches, we’re finding ways to improve the efficiency and the speed at getting all of these updates out to all of our systems. Security in an organization is often seen as a roadblock or something that is preventing the organization from performing the task that they need. In reality, of course, the security is put in place to make the data and the systems as safe as possible.
But often we find that certain applications or certain systems will simply not work properly with the existing security in place. We might also find times when our troubleshooting process makes a system less secure. For example, you may need to disable antivirus during troubleshooting to make sure that it’s not antivirus that’s causing our problem. Or maybe we need to disable our personal firewall and see if that’s causing the communications problem that we are experiencing.
What we have to remember is, at the end of our troubleshooting task, to make sure that we have re-enabled antivirus, re-enabled our firewall, or that we have an automated process in place to automatically re-enable those security tools. Some individuals in an organization might feel that if antivirus is causing the problem, then we should disable antivirus, or if the personal firewall is causing this problem, then we should disable the personal firewall.
Fortunately, many organizations have evolved past the point of simply turning off security to circumvent those problems, and instead addressing each individual issue as a way to troubleshoot and resolve security issues so that all of these can work together. It’s said that all good things must come to an end eventually, and that’s certainly true in the world of operating systems. We’ve certainly seen migrations in operating systems through the years, and it’s not uncommon to upgrade or replace operating systems as they get older.
Most operating systems have a publicly stated timeline on when that operating system is active. And eventually, there will be an end-of-life date associated with that operating system. We refer to this as the EOL date. This is when the manufacturer stops selling that operating system, but they may still continue to support the operating system going forward for a certain amount of time. So although there might not be any new features over the next two years with this operating system, we will still continue to get security patches and minor updates that fix problems with the operating system.
A significant date, especially one that is a concern for security professionals, is the end of service life, or EOSL. This is when the manufacturer is not selling the operating system, and they are no longer supporting the operating system. This means if a security vulnerability is found in that software, it’s unlikely that this company will be producing any patches or updates.
In some circumstances with very large companies, you might have the option to have a premium cost support option that provides extended coverage for an additional time frame. However, this is not the norm for most organizations. And if you do have equipment that is at its end of service life, you might want to consider swapping that out for something that’s more supportable.
Many of us own our own mobile phone, but we also use that same phone when we’re at work. We refer to this as bring your own device or bring your own technology. The employee brings their phone but also includes company data and company applications on that same phone. This brings up some interesting security concerns because we want to be sure that phone provides the proper security, especially if the company’s data happens to exist on that device.
Many organizations have implemented Mobile Device Managers, or MDMs, to solve some of the problems that we have with combining these two devices into one single device. For example, it’s both a home device and a work device at the same time, which means we have personal data and corporate data on that same device. How are we planning to protect the data? Many mobile device managers will partition away part of the device for home data, and part of the device for corporate data. If you leave the organization, that MDM simply deletes the corporate data, leaving your private information intact.
This same concern occurs if someone wants to upgrade their phone, or they want to sell the phone to someone else. Once they get a new phone, they need to go through the process of adding all the corporate data. But we also have to think about how we remove the corporate data from the old device, as well. This is another place where a mobile device manager can be valuable, because from that central MDM console, you can select any device and choose to delete all of the data on that device.
That MDM is also good for adding security policies onto these devices, so they will monitor for any changes and look for any type of malicious software. This prevents an attacker from infecting our mobile device, which ultimately may allow the attacker access to our corporate data.