I have started on a journey to nut out a unique protection model with the aim of applying it to the Microsoft Cloud to simplify the application and understanding of cybersecurity for people. My initial thoughts are here:
A simplified protection model
With input from a few, I’ve now progressed my thinking.
The latest model is shown above. The containers are:
1. Service – For example: Microsoft 365 or Gmail, etc
2. Device – For example: Windows 10 desktop, iPhone, Android phone, Mac PC, etc
3. Identity – For example: Azure AD credentials, Google or Apple account, etc
4. Data – For example: Files, folders, email messages, etc
Through and into these containers flows data from connectors like:
1. Email
2. Connections – For example: networked devices, the Internet, etc
3. Apps – For example: desktop apps like Office, accounting apps, etc
4. Browser – For example: Edge, Firefox, Chrome, etc
Let’s just focus on the email connector initially, as shown above. You see that in the above model that the device container is missing. This is because email can be delivered without the need of a device. That is an email can be sent to Exchange Online in Microsoft 365, received, verified that a user with that identity exists, and then finally delivered to the users inbox. That can all happen without the interaction of the user and without the need of a device.
If we expend this out one level the inbound email received by Exchange Online (Service B) has to have been sent by another email service (Service A shown above). Service A must contain an identity (i.e. the sender of the email) and the actual message (i.e data).
This however, still hasn’t involved a user. It has simply been a ‘service to service’ process.
At the end of the chain will be a device (a Windows 10 PC say), logged into via a user account (identity), that created that data with an app (say Outlook). That data (email message) is then moved by the email connector firstly to Service A which then again uses an email connector to move it to Service B as shown above.
Putting specific identifiers on things you get the above.
So the model seems to scale but we need to re-focus it on protection. Looking at the above, it is clear that you can only control so much of the ‘chain’, as you see highlighted by the ‘control boundary’. Therefore, we should focus our efforts on only what we can control and protect.
With said focus, we can now start to map capabilities to protect the environment. For example, with email, we can ensure we have appropriate DNS records. This capability lies outside the Service boundary (here M365) but still within our control boundary. When data passes over any security boundary it creates logs. In the case of emails, this would be information that could be examined using features like Message trace in Microsoft 365.
After the data, flowing through the connector, passes across a boundary and writes log data, security features of that container can now be applied to the data. In the example, once an email is delivered to Exchange Online in Microsoft 365 it then typically has anti-spam and anti-malware as well as other filtering policies applied. Additional protection can also be provided in the form of Microsoft Defender for Office 365 (shown as ATP in the above image to keep things short).
So, that is just my brief thinking around the Email connector but I feel that the model works well so far helping to simplify security I hope. I’ll keep expanding what I have and begin to incorporate more specific examples of where Microsoft Cloud security products fit into this model. Hopefully, the more built out the model becomes the easier for people it will be to understand the total breadth of Microsoft can offer to help protect your environment.
As always, love to hear your thoughts and feedback on what I’m developing here, so don’t be shy. Look out for future model enhancements coming soon!
CIAOPS 