What NIST SP 800-46 says about telework and personal devices

NIST SP 800-46 Rev. 2 is NIST’s guide to securing telework, remote access and personal devices (bring your own device, BYOD). It tells you to assume that devices and networks outside the office are hostile. Each organization decides which kinds of device may reach which systems, giving the least-controlled devices the least access. For organizations with higher security needs, it suggests sign-in that doesn’t rely on passwords alone. It doesn’t ban personal devices.

What the guide covers

NIST published Rev. 2 in July 2016. It covers the devices people use, the remote access servers they connect to, and the internal systems they reach. It also covers the policy that ties them together. It’s written for federal agencies, and NIST says nongovernmental organizations may use it voluntarily.

Start by assuming the outside is hostile

The guide’s first recommendation is to plan as if the places, networks and devices outside your control are hostile. It spells out three assumptions:

• Telework devices will be lost or stolen, and whoever gets one will try to pull data from it or use it to get in.
• Networks outside the office can’t be trusted, so traffic may be read or changed.
• Devices will get malware.

For a lost or stolen device, the options it gives are encrypting the device’s storage, encrypting sensitive data on it, or not storing sensitive data there at all. To stop someone from using a lost device to get in, the main option is strong authentication, “preferably multi-factor.”

Four kinds of device

The guide sorts devices by who is responsible for securing them:

• Organization: bought, configured and managed by the company.
• Third-party-controlled: managed by a contractor, partner or vendor, under a contract with you.
• BYOD: owned by the worker, who is fully responsible for securing it.
• Unknown: devices nobody vouches for, such as a hotel kiosk or a relative’s laptop. The guide calls their use extremely risky.

The trouble with devices you don’t control is enforcement. The guide notes that even with agreements in place, those agreements “generally cannot be automatically enforced.” So an infected or poorly secured device may end up connected to your systems. Telling users their duties improves security on personal devices, it says, but doesn’t match controls you enforce on your own devices.

Four ways to reach company systems

The guide groups remote access into four methods, which differ in where software and data end up.

Most of these methods can let people store data on their device, and data can also land there by accident, for example in the browser’s cache. The guide asks that data sent to remote workers follow your data retention rules.

Direct application access is the method that fits a cloud app opened in a browser. The guide says the app itself provides the security in that case: encryption, sign-in and so on. It sees this as generally acceptable only for systems on the network’s edge or in a public cloud, not for internal ones.

Give the least-controlled devices the least access

The guide says a telework security policy should spell out which forms of remote access you allow and which types of device may use each one. It should also say what access each kind of worker gets and how accounts are set up. Its example tiers access by device. Company computers reach many resources. Personal and contractor computers reach a limited set. Personal phones and tablets reach just one or two low-risk resources, webmail for example.

The factors it lists include how sensitive the work is, how confident you can be that a device follows your rules, cost, and where people work from. For high-risk work, it suggests allowing only company devices with multi-factor sign-in and encrypted storage.

Signing in from a device you don’t control

On authentication, the guide makes three points. If passwords are the only check, the remote access password should generally differ from the company’s other passwords. It makes an exception for direct application access, and says to assume some people will reuse passwords anyway. Where security needs are higher, consider sign-in that doesn’t rely on passwords alone. It also notes that many organizations make people sign in again during long sessions, such as after 8 hours or after 30 minutes idle.

The guide also covers checks on the device itself before access is granted, such as up-to-date patches and antimalware. It warns that malware can easily get around many of these checks. It suggests mobile device management, and app management that keeps work apps and data in a separate space that can be wiped when someone leaves.

What that leaves to account controls

With direct application access, nothing sits between the personal device and the app except the app’s own sign-in. So for cloud apps used from personal devices, the account controls carry the weight. That means who has a login, how strong the sign-in is, whether the password stays on the device, and how fast access ends when someone leaves. How the device-side options compare is covered in Options for letting staff use personal devices for work systems. What a personal computer keeps afterward is in What work data stays on a personal computer, and how to keep it off.