With remote working, BYOD, employees using their own devices and shared access to collaborative cloud apps from business partners – we need to include device control when allowing access to our cloud services.
Many cloud services have admin options to restrict access and functionality, sadly many of these features are unused, either because they seem complex or not important compared to other aspects of the service. One that is often ignored is setting policies by device.
Cloud services often allow collaboration between different users and their strength is the wide device support they offer; the assumption is that most can be accessed either via specific apps or most browsers on most operating systems. The users may be employees or business partners and may be using managed, unmanaged, trusted or untrusted devices with the latest security updates or old systems with no device security – so now is the time to review and set policies based on device information.
Here’s some of the potential different risky scenarios we should be controlling.
- An employee using BYOD or unmanaged devices and downloading confidential information onto an insecure device that is subsequently lost or infected to exfiltrate data.
- An employee logging in from a friend of family member’s device and again downloading information or editing a document on that device and uploading it, potentially uploading malware.
- A business partner using their own device, uploading malware inadvertently as their device wasn’t secured.
Policies to address these and other risky scenarios could include:
- Allow users to view but not download content to unmanaged devices.
- Disallow uploads from unknown devices.
- Implement DLP policies to all devices downloading data when outside the organisation.
Cloud admins need to consider each of these scenarios and decide the appropriate policies and define them in the cloud service. There are many possible conditions, though obviously not all cloud services support each condition. By using Boolean logic, many different sets of criteria can be compared to consider each of the conditions
- Managed / unmanaged device
- Operating system in use
- Activity (upload, post, download)
- Agent (McAfee MCP, Zscaler, others)
- Managed by EMM systems such as MobileIron and AirWatch
- IP address for geo-location
- User/group as defined in authentication system (LDAP etc.)
- Request classifier (allowing deeper drill down into cloud services)
- User domain
The actions based on the conditions that could be supported include:
- Allow access / Deny access
- Check certificate on the device
- Step-up Authentication to re-authenticate the user
- Proxy all subsequent traffic from this device to enable other controls
- Redirect traffic
- Implement specific DLP policy
Not all cloud services offer policies based on each condition, what is supported is worth checking before buying a particular cloud service, or use this list to lobby for stronger policy capabilities in your favorite service. Each service has admin capabilities to define these services, though it is often much easier to set it once and push out to all cloud services by using a CASB solutions such as MVISION Cloud.
To dig deeper into “request classifier”, this can refer to parts of a cloud service allowing admins to define more granular policies, such as allowing unmanaged devices to access OneDrive but not SharePoint or blocking a device not on the corporate network from accessing the O365 Admin portal.
Device control is only one row of the Cloud Security 3600 Shared Responsibility Model – There are nine rows in total, the whole paper is available from here.
About the Author
Categories: Cloud Security