No system is secure with the default configurations. In this video, you’ll learn about hardening mobile devices, servers, embedded systems, IoT devices, and more.
When you first install an operating system, the default configuration is rarely secure. You may need to provide additional configurations to increase the security posture of that operating system. Knowing exactly which configuration settings to change could be challenging. Fortunately, many manufacturers will create hardening guides that are specific to that application or that operating system.
And if you run across a device or system that doesn’t have a hardening guide, you might try reaching out to the manufacturer or check some online message boards. And you may find that some third parties have created their own security hardening guides helping to keep those devices secure for the entire community. The mobile devices we use every day are very good examples of devices that must be hardened.
Fortunately, the manufacturer of these devices often provide hardening guides and suggestions for keeping those devices secure. Manufacturers will release patches for bug fixes. But many of these also include security updates. When we install the patch, we’re closing any vulnerabilities that might be used to attack those devices.
Another common hardening technique is to segment the data that is stored on these mobile devices. If you’re working for a company, there’s usually a segment that is set aside just for company data and another segmentation that’s set aside for your user data. This provides a logical separation between your personal information and information that might be proprietary to your company. And if an attacker does find a way to gain access to one of those segments, they would not necessarily have access to any other data on that device.
If you’re managing a large group of mobile devices, then you’re probably using a Mobile Device Manager, or an MDM, to be able to monitor those devices and push out any security updates. Of course, it’s not just our mobile devices that need hardening. We also have to Harden our workstations that are running Windows, macOS, Linux, and other operating systems. These platforms also have periodic updates. These are bug fixes, security patches, and they can apply to the operating system itself, applications running on the operating system, or the firmware of the device.
Many of these companies will compile the security patches and then release all of them on one day of the month. This allows you, as the security administrator, to test all of those patches at one time before deploying them. This simplifies the process and makes it much more efficient to get these patches out to those devices. And of course, a good security best practice is to always remove any software that you’re not using on that device. Every piece of software is a potential opening for a vulnerability. So removing that from the system gets rid of that particular security risk.
Our network infrastructure is always working behind the scenes. And we have to consider security hardening for our switches, routers, firewalls, and other network infrastructure devices. These devices generally don’t run an off-the-shelf operating system. So you probably won’t find Windows, Linux, or macOS running inside of a switch. Instead, this embedded operating system has been created specifically to run this network infrastructure device. And you’ll usually have limited access to the operating system that is inside of these devices.
One common best practice for these devices is to always change the default credentials. It’s usually best to configure some type of authentication, whether it’s local on this device or whether it points back to a central authentication server. And if you’re not sure if there are any patches for these devices, you should check with the manufacturer.
They’re the only ones who have patches available for these purpose-built appliances. And they aren’t usually updated that frequently. Because these updates are relatively rare, a security release or patch from the manufacturer would be an important event. So you should check those patches to see if that’s something that should be deployed in your infrastructure.
Many organizations will have centralized cloud management workstations that are used to manage all of the cloud-based infrastructure. This device tends to have complete access to the cloud-based systems, so it’s important that workstation is also secure. We can also use our cloud management workstation to ensure that we’re using least privilege. This means that we are configuring applications and devices in the cloud to only have the minimum access required to perform their function.
So you would evaluate all of the services running in your cloud, any network settings, application rights and permissions, and anything else that might allow that particular application to work in the cloud. It’s also useful to have Endpoint Detection and Response, or EDR, installed on these cloud-based systems. That way we can monitor for any potential attacks and confirm that those devices are up to date with the latest anti-malware technologies.
And of course, you should always have a backup. Even cloud-based devices are prone to outages. So you want to be sure that you’re constantly backing up all of these systems. And backing up to a separate cloud provider would also be a good best practice.
We also need to make sure that we’re hardening all of the servers that we have in place. These are usually running Windows, Linux, or a similar operating system. These may have individual updates for the operating system, or there may be groups of updates referred to as service packs. Any time there’s a security patch for an operating system, we want to be sure we’re addressing and installing that particular patch to keep that OS secure.
These devices also have an authentication process, so we want to be sure that we’re using a minimum password length and that our passwords are properly complex. We also want to set least privilege for all of the accounts on these servers and disable any accounts that may not be used. In some cases, these servers may only be communicating with a set number of devices. In that case, we may want to set policies within the server itself or on our firewalls that would limit what devices may be able to access these servers. And of course, these servers should have EDR, antivirus, anti-malware, or some other client-based security technology.
If your organization uses large, industrial equipment, then you’re probably familiar with SCADA. This is the Supervisory Control and Data Acquisition system. This might also be referred to as the Industrial Control System, or ICS. This is a combination of network connectivity and platforms that manage, monitor, and control all of these industrial devices. So if your organization manages power generation, you have manufacturing equipment, or anything else that is large-scale industrial systems, you’re probably using SCADA and ICS.
These usually take advantage of a distributed control system to provide real-time information on how the system is performing and monitoring the ongoing process of that device. If you ever need to make changes or control the device, you can also do that from this centralized control system. These devices tend to be very well secured to the point that, in many cases, these SCADA systems are on their own, isolated network that is separated from the rest of the organization by an air-gap. There’s often very limited access to these systems and certainly no access from the internet.
Embedded systems provide another challenge for device hardening because they have their own operating system running inside a purpose-built appliance. We often see these embedded systems in things like smartwatches, televisions, and purpose-built appliances. Because of this limited access to the operating system, these devices can sometimes be challenging to upgrade. And in the case of a purpose-built appliance, it may be very unusual to receive a security patch.
This means, if you do receive a notification for a security patch for an embedded device, you should look into installing that as soon as possible. Because of this limited security that we often see with embedded systems, we want to be sure that we always keep those devices up to date with the latest security patches. And you might even want to consider taking these embedded devices and specialized systems and putting them on their own segmented network. It might be useful not only to have them on their separate network but provide additional security by using a firewall in front of that network.
Some specialized equipment may include a Real-Time Operating System or an RTOS. Real-time operating systems tend to be deterministic, which means that there is a certain expectation of time frames for every process to occur on those systems. With a real-time operating system, individual processes have a certain expectation of running in that OS in a particular time frame. This is especially important for industrial equipment, military equipment, or automobiles where you need to make a lot of decisions in a very short period of time.
These should obviously be isolated from the rest of the network so that no other device can affect the running of the RTOS. You should also consider running with the minimum amount of services. That way you would have only those services necessary running on those particular systems. And if those devices need to communicate out to the network, you may want to consider a separate firewall or a host-based security technology.
And if you’re managing devices that are communicating across the network to control lighting, heating and cooling, or some other type of automation, then you’re dealing with security around Internet of Things, or IoT. It’s very convenient to be able to control and monitor these systems across the network. But unfortunately, the manufacturers of heating and cooling systems or lighting systems are not necessarily security experts. So it might make sense to add a little extra security when it comes to IoT.
For that reason alone, you’d probably want to put security patches at a higher priority when it comes to IoT devices. If there’s a patch released for a cooling system or a lighting system, you want to be sure to deploy those as soon as possible. And if you want to limit the scope of any potential exploit, you may want to segment those IoT devices onto their own network. If an attacker was able to gain access to one of those IoT devices, they would only be limited to the other IoT devices on that segmented network.