CS4NSP Episode 4: Devices Deserve Zero Trust from the Outset

Brief at the Start

Go straight to the full length version

Devices are the least trustworthy elements of your security; when combined with low-trust People, you have a disaster waiting to happen. 

If a user’s device enables them to do their job, it will enable an attacker who compromises it to access all those resources as well. Once the attacker has a foothold on the device, they will look for other vulnerabilities on it or in different systems so that they can do things not even the user has permission for.

For this reason, CONTROLLING THE DEVICE IS JUST AS IMPORTANT AS CONTROLLING THE PERSON. But unlike our faith in humanity, we need to have ZERO TRUST in a device from the outset.

The more permissions a user has for their job, the more critical it is to control the device to reduce the chances of an attacker taking it over. Attackers will gain control of a device by exploiting vulnerabilities in its software, running other malicious software on it, or, more usually, a combination of the two.

For this reason, the most effective way of controlling the device is to ensure:

• It runs only approved software;
• All software is kept up to date; and 
• The operating system is configured to limit further the harm a user or hacker can do.

Because these devices are such vulnerable points, we will frequently need to monitor them so that we can respond when odd or concerning activities happen.

Just because your organisation adopts a policy like Bring Your Own Device (BYOD) doesn’t mean the requirement for control no longer exists. If anything, this makes it harder, not easier, to manage. You will need to work out how to apply equivalent controls over a device you don’t own, or change how assets (see Episode 2 for our definition of an ASSET) are accessed to reduce their vulnerability to compromised devices.

Like the TRUST PERSONA in Episode 3, you can define a range of different DEVICE PROFILES that implement various levels of control. You can then select the most appropriate profile as the minimum requirement to access a particular asset classification or mitigate a level of risk.

Get the Full Version

Lets start with the ‘Why’

With a nod to Simon Sinek, let’s start by asking why the DEVICE is so important. In Episode 3, we looked at the complex issue of People Trust. It is well known that hackers will frequently look to achieve their objectives by misleading people and taking advantage of their human weaknesses. If they can convince you to transfer a big chunk of money into their bank account by making you believe they are the CFO or a key supplier, why would they go any further?

We know that PEOPLE present a vulnerable point, so we manage that risk. We limit their permissions to no more than they need for their job, and we give them training so that they are more likely to spot this type of manipulation. This is particularly true for people with access to the most valuable assets. We might enhance this by strengthening key processes, such as those controlling finances, so that more than one person is required to complete a transaction.

But it doesn’t matter how well we manage the People vulnerabilities if the device presents an easy target. If the attacker can compromise the device, then they have the potential to act like the user without that user even being aware. It doesn’t matter how aware and cautious your people are; with control over the device, the hacker can act with impunity. For example, if the user has access to a significant proportion of the organisation’s sensitive information, then the hacker’s little piece of ransomware code will be able to use their permissions to encrypt all of those vital documents, denying everyone the ability to use them until the ransom is paid.

Once an attacker has a foothold, they will unlikely settle for just the user’s permissions. They will look for other vulnerabilities on the device or in other systems it is connected to in order to increase their permissions and, therefore, the damage they can do.

What does ‘Control’ mean in this context?

If the hackers are trying to gain access to and control of the device, then we need to try to prevent that. That means we need to minimise the chances that the attacker can run or install malicious software (malware) on the device and minimise the vulnerabilities they could exploit. The most common techniques include the following (but this is by no means exhaustive):

• Software Updates.   Ensure that the operating system and any software installed are updated to quickly remove vulnerabilities. Ideally this should be done automatically where possible. Where risk warrants it this can be complemented with tools that scan the device for known vulnerabilities.
• Authorised Software Only.   Ensure only pre-approved software runs on the device.
• No Local Administrator.   Users with local administrator privileges can do anything to the device. All they have to do is confirm their actions without the requirement for any additional controls or authorisation. Users should not be given these privileges, and administrator tasks such as changing critical operating system settings, installing potentially dangerous software, or disabling anti-virus should require a specific administrator account.
• Minimum Software & Services.   Every item of software has the potential to present a vulnerability. Therefore, software and services should only be installed or enabled on the device if required for the job. For example, why retain all of that additional software that the manufacturer installs on your laptop when you buy it and that nobody uses? Windows also includes a myriad of applications and services that are unnecessary for most jobs. For example, most users don’t need to be able to access their laptop remotely or run a web server on it.
• Configure the Operating System.   Like the principle of installing only the minimum necessary software and services, the operating system should be configured with only those settings and freedoms required for the job. This aspect covers a vast and diverse range of controls that are well beyond the scope of this article. A (very) few examples include ensuring storage disks are encrypted, preventing users from running scripts, limiting where users can source software, controlling what can be connected to a USB port, and defining how virus checks should operate. If you don’t know how a device has been configured, you have to assume it has been done badly; many of the default settings are dangerously, and unnecessarily permissive.
• Enforce and Monitor.   These controls are not a one-off. You can’t just implement them and then forget about them. They must be enforced to ensure they remain in place. Monitoring the device’s operation may also be important so that suspicious activities and infringements are detected and responded to.

Translating Control into Trust?

Just like with people, how much we can trust different devices exists on a continuum. We will have a high degree of trust in a device if we have tight control over it, have applied very stringent policies to its configuration, management and monitoring, and are confident that users cannot override these controls.

At the other end of the spectrum are the devices visitors to our website use. We likely don’t know who the people are or what state their device is in. In this situation, there is no basis for trust in the device, in the same way you have no trust in the individual.

In between will be a range of different trust levels. The lack of direct control over the device may undermine trust, as is the case with suppliers when they use their own IT. Or if you apply less stringent controls to the devices given to some of your staff.

Think of it like a car. When you have owned a car for some time you are familiar with how it will perform, you have adjusted settings, maintained the brakes and checked the tyre pressures. You trust your own car to perform as expected. When you hire a car you will have a bit less trust. If it is new there might be some implicit trust from the manufacturers reputation, but if it has been around the block and you don’t know the hiring company you may experience some anxiety; but over time you will get familiar with how it is performing and operating. When you get into a taxi, particularly in some parts of the world where maintenance doesn’t seem to be as important you will probably have very little trust at all and this is unlikely to change over time.

Just like the Trust Personas described in Episode 3, we can define a set of DEVICE PROFILES, each of which would deliver a different level of trust. You can see an illustrative collection in the figure below; note that this is illustrative and is not a recommendation. It is highly simplified; there will likely be many additional criteria either in the profiles or within the baseline and enhanced configuration policies.

Controlling and validating that trust

So, once we have decided what controls we need for various Device Profiles; what do we do then? How do we configure our devices to meet the standard and verify that this is the case at the time of use? There are a number of different ways of doing this:

• Declare a Policy.   You could make it the standard policy and trust everyone to comply with that policy. But this comes back to the question of how much can you trust your people to understand and implement the requirements consistently.
• Manually Manage Devices.   You could have a few people who are responsible for configuring all of your devices; your system administrators or IT staff. But this is going to be a challenge as you grow. It will also be a particular challenge if your team is distributed over a wide area or you operate remote or hybrid working practices. And unless you require people to periodically bring their devices back to the management staff, you may not be able to confirm that the original policy hasn’t been compromised.
• Use Device Management Tooling.   The most efficient method from an operations perspective is to use a Device Management tool. These applications enable you to define your compliance and configuration policies and then apply them before the device is allowed to join your environment and access assets. They come at a cost though. They also require security and technical expertise to develop and maintain the policies, and there is the initial effort required to set them up.

Irrespective of the solution you choose, and whether you do it in-house or outsource the task, there will be many devices that you will not be able to control in this way. For instance, unless you issue suppliers with your own devices for them to use, you are unlikely to have anything more than contractual assurances that the devices they are using are secure. This should be reflected in the level of trust you have and the access you are willing to grant them.

But we allow our staff to “Bring Your Own Device” (BYOD)!

The concept of Bring Your Own Device, or BYOD, can be contentious and has been vigorously debated since it was introduced more than ten years ago. I won’t try to argue whether it is a good or bad idea in the round. But it does make security significantly harder to implement, manage and enforce.

One of the key problems relates to the issue of ownership. If the user owns the device then the employer can’t just impose control without consent¹. That consent will be challenging to achieve if the controls restrict what the individual can do in their own time and with their own device for their own purposes (as it inevitably will). For example, the device owner may be reluctant to agree that they should not have administrator privileges or be able to install software of their choice.

It is even harder, if not impossible, to dictate what the device owner can use it for. For example, how can you tell someone that they must not go to certain websites that you consider dangerous with their own device and for their own purposes. As a result, there will be a significantly increased risk that the device being used to handle sensitive information has picked up some nasty malware while visiting a “special interests” website.

Some types of device are easier than others. Modern mobile phones have better abilities to differentiate between information from a corporate environment (such as an email account) and information from another context. This means that it may be more acceptable for the owner to accept a Device Management solution that won’t have visibility of their personal data, particularly if the alternative is carrying two phones around.

Also, many of your people may be willing to accept a Device Management tool if they recognise the threat to the business is also a threat to them. But this will depend how controlling the profile you want to apply is, and the trust they have in you to not abuse the access to their device. Installing surveillance-ware might just push that trust over the edge! Regardless, you are unlikely to be able to rely on that goodwill and need to have a Plan B for those who prefer to opt out.

Irrespective of the pros and cons, if you adopt a BYOD policy, recognise the risks this introduces and manage them accordingly.

Everything we do is through the Browser, so that’s safe and we don’t need to worry do we?

Increasingly, our applications and services are accessible through the Web Browser without needing an application installed on the device itself. This does simplify what you are trying to control. However, browsers are one of the most compromised and attacked application types.

Imagine your browser was a bucket. You are using it to collect the weeds from your garden, store your clean laundry, wash your car, prepare your dinner, and to cap it all you are brushing your teeth in it at the end of the day. Browsers go to some of the most untrusted and unsavoury parts of the internet and also to some of the most sensitive.

The companies that build and maintain mainstream browsers put a lot of effort into ensuring activities in one tab (one section of your bucket) cannot cross-contaminate another. But vulnerabilities are constantly being uncovered.

So the first thing you need to ask yourself is how can you be confident that the Browser being used is up to date and not carrying any known vulnerabilities.

The second issue relates to those useful browser extensions that you can install. Like the ones that block advertisements, enable you to play your music in the background, or let you play games when you aren’t busy. The problem is that there are a lot of malicious extensions as well. Ones that spy on every page you visit and every character you enter in. How can you be sure that the browser being used has no spyware extension or other malware installed?

There are solutions to this, where only a controlled ‘Enterprise’ Browser can be used to access your assets and services. But just assuming that the Browser is inherently secure is not effective.

Summary

Establishing trust in devices is just as important as establishing trust in people. But, it is generally harder to achieve with confidence. It also tends to be unpopular, because it constrains what people can do with their wonderfully versatile computers, mobile phones and tablets. This can be eased by adopting a range of DEVICE PROFILES for different RISK PROFILES. But ultimately, control restricts freedom. So, the Device Profiles and the method of managing them need to be sympathetic to the jobs that the user is trying to do. Otherwise, they may try to find ways around the controls.

1. For the avoidance of doubt, this article should not be interpreted as legal advice which should be sought from a properly qualified advisor as necessary. ↩︎