The National Institute of Standards and Technology (NIST) released a draft of guidelines designed to allow organizations to adopt mobility from the ground up. They based this around corporate owned, personally enabled (COPE) deployments.
We’ve looked at NIST previously after they released 2017 password complexity guidelines to overwrite their 2003 version that had introduced a lot of what we hated about dealing with passwords (e.g., certain character length, rotation, etc.).
Now, NIST is taking aim at helping organizations get into mobility (which Jack has said before should be basically every one by this point).
National Institute of Standards and Technology
To understand why this best practices guide is so interesting requires a quick look at NIST itself. While not a regulatory body, they often release standards around security frameworks that help organizations comply with protecting data. While NIST didn’t originate to get organizations to comply, they are endorsed by the federal government, and, often, compliance is needed to work with the government agencies.
These NIST guidelines are different, though, as it’s intended for any organization looking to develop a mobility framework but maybe doesn’t know how to start. It’s not the first time NIST covered mobility before, with more general security guidelines released in 2013 where they recommended organizations have policies to cover data communication and storage, user/device authentication, and mobile applications. The NIST guidelines [PDF] review what organizations should consider, but don’t provide a lot in the way of direction, leaving organizations on their own.
NIST guidelines for COPE and mobility
In July, NIST released a draft [PDF] of their mobility guidelines based upon COPE deployments, and accepted comments until late September. In the 350-page draft, they outlined a very detailed standards-based approach for implementing mobility. They worked with some well-known security vendors like Lookout and Palo Alto Networks and considered both iOS and Android when developing these guidelines.
The mobility guidelines explain how to implement security controls to protect business data on COPE devices, deployment of configurations and organizational policies, an examination of the security of mobile applications, how to prevent Man in the Middle-type attacks and phishing attacks, and set user privacy settings.
Organizations should deploy an on-premise EMM with cloud and agent solutions, including ones for mobile threat defense, mobile threat intelligence, secure boot, and VPNs.
NIST explains that they put together the mobility guidelines since many admins don’t always know the best policies and standards to implement. From the user perspective, employees aren’t always thrilled with the amount of visibility organizations can have over devices and limiting what users can do.
One thing to note, though, for any organization considering giving the NIST mobility guidelines a go, they stress that the guide is currently based on a lab environment vs. production environment. This could make the NIST guidelines look easier to implement; plus it also requires you have the necessary people in place.
My only issue with their draft, is that given how deep they dive, it’s not great for smaller organizations with limited budget and employees. But, at the same time, organizations could pull out useful aspects and deploy a more limited version of what’s suggested by NIST.
Quick look at what NIST recommends
Organizations should deploy in a three-step process (with millions of smaller steps contained within each). First you conduct a risk assessment, select and implement the mobility architecture, and finish with security testing.
Before you can start to select the right EMM vendors, your team needs to conduct a risk assessment in order to identity threat sources, vulnerabilities, the likelihood of the aforementioned threats/vulnerabilities occurring, and how the company would get impacted. If your team isn’t sure what risks to consider, NIST has you covered. Some example risks could be outsider access to sensitive data, phishing, etc.
With that done, you also need to undergo a privacy risk assessment. COPE involves devices that users might not own but are allowed to have personal data on; employees need to be sure that they can trust their personal data remains private. Some aspects of privacy to consider is how do you handle blocking access or wiping devices, monitoring usage, and data sharing. NIST offers guidance on how to limit the above through selective data wiping, having employees constantly back up personal data, and limiting what employees have access to wipe or block access.
With the threat and privacy assessments out of the way, it’s time to actually figure out how to develop the architecture and what vendor products is needed. Obviously, this is the most complicated step, but NIST offers several tools that they believe when implemented together provide a complete setup. (You’ll notice all the products are ones sold by vendors NIST spoke with for this draft.)
The final piece of the mobility guidelines framework involves security analysis. With the architecture in place, it’s time to go through testing. NIST provides a list of threat events to test the security of your mobility architecture against—once that’s handled, you’re ready to start rolling out into production with employees.
It seems like a fairly in-depth guide that larger organizations could implement, though it’d be easier done when you’re first getting off the ground rather than having been around for decades.
Overall, if you’ve paid any attention to EMM vendors from the last few years or read our website, then what NIST outlines here is not anything revolutionary. However, knowing what you need and actually implementing that are two different things and the NIST mobility guidelines are definitely useful. You get everything you need while acknowledging both privacy and security, while coming at mobility from a standards approach, making it possible for organizations to deploy.