Zero? Trust? - Part 2.

Part 2, a problem.

OneDrive, the file sharing platform under Microsoft's Office 365 umbrella, up until recently worked in much the same was as your on-prem file server. Documents/files have permissions, these permissions can be set by a system/space admin, the folder owner or the document owner, and can be inherited. Other features to share the documents exist, such as granting permissions to anyone with a valid link, and the ability to create a HTTP-accessed site which can be shared with all users in your org's O365 ecosystem.

We'll look at a possible scenario for data leakage in OneDrive below:

The problems in the traditional model of inherited permissions, and long thin Chains of Trust are obvious:

1. The security level is strongest at the top of the diagram. This is where InfoSec creates their policies, the OneDrive admins craft their permissions models and configure settings. It's likely that InfoSec will validate who is an admin, and check their work on the settings.
2. As we move down the diagram, we see our Chain of Trust develop. The trust exists between the users of our solution, and cannot be easily validated. As per the previous discussion on the principles of Zero Trust, trust here is somewhat automatic - or at least deemed essential: "In order to allow users to create and collaborate on documents, I MUST trust them to maintain their own sharing permissions"
3. The document owner trusts the document reviewer, BUT doesn't inform the reviewer of the sensitivity of the document. Even if they did, would the reviewer have honoured the requirements to keep the data secure? Is the owner going to bother validating how the reviewer treats the document? Can they see that it was copied?
4. The Chain of Trust has ended, yet the data is still moving. Unable to protect itself, or inform the OneDrive ecosystem that it needs protection, its copied into a SharePoint Team Site, and then downloaded by a user who is wholly untrusted. 
5. As the data moves around, there are opportunities using detective and responsive controls to help to minimise the risk of it leaving the ecosystem, including:

• DLP. When the data got downloaded to the USB drive, DLP could have lept into action, blocking based on certain regex matches, if they were present. DLP can create a lot of noise (scales with the amount of data processed), and helpdesk churn for unblocking false positives. Users also become adept at altering data so that it's still human-usable, but doesn't trigger naive regex matches.
• Scanning internal sites for confidential data. Again, you're relying on regex matching, and whatever process/tool you create for this will have to scale. More data will mean more alerts, false positives, helpdesk tickets, work for the security staff etc.
• CAS. Another solution which carries considerable merit, but suffers from the same problems as the others - it must be able to scale with your business.

Fundamentally though, our problem remains - the final link in the Chain of Trust was effectively broken and yet the data kept on moving. The data wasn't able to validate the chain of trust, none of the participants in the chain were able to see that the chain had been broken. 

Next, we'll look at how OneDrive's Sensitivity Labels and Label Policies enable data to become "smart", and what does to our chain of trust.