Microsoft 365 Security platform explained – part 1 – the strategy

In the latest blog post I’ve just shared my view on the real Cloud Security and Compliance model, and I made it in a totally vendor-agnostic way.

Let’s decline it in the Microsoft world of solutions, and specifically starting from the first realm that we call “Modern Workplace”, the IT environment where the digital transformation journey of an organization typically starts.

These solutions help employees to use the best collaboration tools that enable them to securely access applications (inside and outside the company) and to process data (with colleagues and external partners) without sacrificing the mandatory need of the Security and Compliance teams to have this productivity environment, without any tangible perimeter, still under total control of the company.

In this Microsoft realm, the Cloud Security and Compliance model can be declined with the following diagram:


When the Microsoft Office 365 suite is at the center of your risk assessment evaluations, you should understand how the several security and compliance controls are layered over the stack from the endpoint to the cloud applications inside Office 365.

The key infrastructure security solutions in the middle of this stack at layer 3 are represented by the Microsoft Enterprise Mobility and Security (EMS) solutions: a fundamental note is these are able to secure even non-Microsoft applications (3rd party web applications in the cloud and on-premises) and to protect data processed by non-Microsoft devices (iOS and Android devices as well), as I’ll show you better in a future blog post of this series where I’ll go deep in the several solutions layers (Identity, Information and Threat Protection).

Where we consider the Windows PC as the main device to enable this secure productivity environment, you may note from the green square box in the picture how Microsoft has been able to build a commercial bundle to help customers to acquire the full set of licenses and related security and compliance features to secure the full end-to-end stack from the device to the cloud productivity suite: Microsoft 365 !

The following picture adds just a bit of licensing detail: every product suite inside Microsoft 365 Enterprise is offered in two flavors, the Enterprise E3 or E5, and the size of the relative boxes is there to suggest how they broaden the spectrum of coverage over the main Identity, Information and Threat Protection solutions areas.


Hoping these diagrams are quite clear, I can now use them to make an example to demonstrate the Microsoft strategy behind the Microsoft 365 Security platform to offer a layered incremental feature set depending on the component and the licensing level of choice.

Example: Multi-Factor Authentication (MFA) capabilities.

Just to catch even the interest of novice readers not so expert about security, let me remind that MFA is the technology solution that adds a second authentication factor to prove the real identity of the user after the less secure first one (the password), as maybe everyone experiments when making disposition actions in their internet banking web application.


As you can see from the light green boxes from the Office 365 E3, to the EMS E3 layer and ending on the EMS E5 layer, there are 3 incremental solutions that offer MFA capabilities over the platform:

  • The MFA features inside Office 365 E3 are not so granular: think about them as a big power supply handle to switch on/off MFA for all Office 365 applications (and only for them!) and for all user/group without any ability to selectively choose which application/user/group should benefit from it.
  • Azure MFA inside Azure AD Premium P1 plan is the complete MFA feature set to gain granularity to specify which application (even a not Microsoft one!) and which user/group should benefit from it. The only “limitation” with regards to the following solution is related to the static setting nature of these capabilities.
  • The best of breed MFA capabilities offered in the Microsoft 365 security platform are represented by the ability of Azure AD Identity Protection to offer MFA as one of the dynamic and automatic remediation actions where the Azure AD solution, powered by machine learning and artificial intelligence analysis of the authentication logs at sign-in, may rate at high risk a specific user/session combination. This is the most powerful and with the best user experience way to harden the access to Azure AD protected applications (Microsoft and not).

This incremental progression I’ve just shared represents the Microsoft strategy behind the different types of security and compliance solution in the platform: the more you need security feature richness, 3rd party application protection, automation of protection, and the empowering by machine learning and artificial intelligence, the more you need to move towards EMS and specifically to the best M365 E5 plan.

Now at this point I hope you may be eager to know which are the specific security and compliance solutions included in this Microsoft 365 Security platform…

…I’ll be glad to give you this view in the next blog post, stay tuned!

Ciao

Feliciano

Il Cloud (Microsoft) quale acceleratore della compliance GDPR – 2a parte

[This blog post has been republished as-is on February 2019]

Nello scorso blog post vi avevo lasciato con una domanda che qui riprendo:

dal momento che il contratto cloud di Microsoft include già le tutele contrattuali necessarie, posso dire quindi di aver già soddisfatto tutti i requisiti di conformità GDPR nell’utilizzo di tali servizi ?

Per comprendere in quale misura le tutele contrattuali siano in grado di coprire i requisiti di conformità GDPR nel caso di servizi cloud è necessario rifarsi allo schema classico del NIST che descrive le varie tipologie di cloud pubblico possibili:


In questo schema, valorizzato in alto nel contesto delle soluzioni Microsoft, si potrà riconoscere come varia il livello di corresponsabilità operativa quando ci si sposta da uno scenario puro on-premise a sinistra (dove tutto è gestito dal cliente), via via verso modelli di cloud che fanno aumentare l’ambito operativo in carico al Cloud Service Provider (CSP), dove il modello di tipo Software as a Service (SaaS) a destra è quello più estremo in cui potrà apparire che sia quasi tutto in carico al CSP, e quindi Microsoft.

Se ci riflettete, questo modello di corresponsabilità operativa che varia in base al tipo di servizio cloud, si può leggere anche per chiarire come variano le tutele contrattuali che un CSP è in grado di fornire: maggiore è la responsabilità operativa, maggiore la responsabilità anche ai fini compliance (vedi riquadro rosso nella figura che segue):


Ma è bene aver chiaro che (attenzione, questo è il punto cruciale di questa spiegazione!) questo ambito di cui stiamo parlando è solo il primo dei possibili livelli su cui è necessario introdurre dei controlli di sicurezza per garantire una adeguata protezione del dato quando si considera l’utilizzo di servizi in cloud (come ricorda la nota “(1)-Cloud Security Level” che ho riportato in basso a destra nell’immagine che ho appena riportato).

Quali sono gli altri livelli? Ecco, schematizzando una interazione tra un endpoint (un PC, un tablet, uno smartphone, un dispositivo IoT, etc..) ed un servizio applicativo in cloud, questo di seguito potrebbe essere un modello che vi fa apprezzare quanti altri livelli di sicurezza vanno considerati:


Il primo livello di cui detto è solo quello relativo all’infrastruttura cloud realizzata per offrire l’applicazione considerata: per questo livello vale quanto già detto, ossia più il tipo di cloud è verso il SaaS, maggiore è la responsabilità operativa (e di compliance) in carico al CSP.

E’ però fondamentale riconoscere che esiste un ambito intermedio che permette l’interazione tra l’endpoint e l’applicazione cloud che va considerato come ulteriore anello da mettere in sicurezza.

Nel contesto delle soluzioni Microsoft ho ritenuto utile distinguere questo ambito intermedio in due livelli:

  • Livello 2: sono le funzionalità di sicurezza native della stessa applicazione cloud di interesse. Disponibili come parte della stessa applicazione, ma con attivazione e gestione ancora a carico del cliente.
  • Livello 3: sono soluzioni di sicurezza di infrastruttura, offerte come soluzioni aggiuntive che sta al cliente valutare, ed eventualmente acquisire ed attivare.

Ultimo, ma non meno importante, bisogna ricordare che non si può tralasciare di rafforzare la sicurezza dell’endpoint.

Facciamo un esempio pratico per farvi ritrovare con applicazioni e soluzioni reali: supponiamo che la “Cloud Application” sia Exchange Online come parte della suite Microsoft Office 365.

Il Livello 1 è l’infrastruttura cloud Microsoft per offrirvi la soluzione di posta in cloud, su cui – in quanto SaaS – la quasi totalità della gestione operativa e quindi delle tutele compliance è di Microsoft. Sta a Microsoft documentare quanto bene si operi la gestione di tale livello per garantire un trattamento a norma.

Il Livello 2 è rappresentato dalle funzionalità di sicurezza (Identity Protection, Information Protection, Threat Protection, etc) incluse nativamente in Office 365/Exchange Online. In ambito clienti medio-grandi, queste variano in base ai piani di licenza Enterprise: maggiore il livello di licenza/piano Enterprise, maggiori le funzionalità incluse.

Prendiamo in esame la funzionalità di autenticazione per accedere alla casella di posta: normalmente i clienti realizzano una federazione di identità per riutilizzare l’identità e le credenziali on-premise di Active Directory per accedere in Single Sign-On (SSO) alla casella ospitata sul cloud.

In questo caso la robustezza dell’accesso alla casella di posta è legata a quanto sia protetta l’identità on-premise e quanto sia robusta la relativa password: il governo di questo anello della catena di sicurezza è ancora in carico al cliente nonostante la casella sia ospitata sul cloud Microsoft!!

Continuando con l’esempio, se il cliente disponesse di piani di licenza Office 365 E3, avrebbe a disposizione delle funzionalità di Multi-Factor Authentication (MFA) per rendere più robusto l’accesso alla posta (tramite l’uso di un cellulare che può ricevere il secondo fattore di autenticazione, come quando accediamo al conto corrente bancario online): decidere se usare questa funzionalità ed attivarla, è ancora una prerogativa in carico al cliente! (quindi ancora una sua responsabilità in ottica compliance/GDPR)

Le funzionalità MFA incluse in Office 365 E3 permettono di essere applicate come singolo interruttore ON/OFF per tutti gli utenti e per tutte le applicazioni della suite (Exchange, Sharepoint, Onedrive for Business, Skype for Business, etc…) senza possibilità granulare di attivazione per singolo utente/gruppo o per singola applicazione: è solo con l’utilizzo di una soluzione di livello 3, Azure MFA (acquisibile singolarmente o come parte della suite di soluzioni di sicurezza denominata Enterprise Mobility & Security (EMS)), che è possibile guadagnare la massima capacità funzionale e in particolare la granularità di poter abilitare l’MFA solo per alcuni utenti/gruppi o solo per alcune applicazioni.

Decidere se adottare tale soluzione per rispondere al meglio ad alcuni requisiti compliance/GDPR è ancora una prerogativa del cliente!!

Come lo è anche decidere le soluzioni di sicurezza da implementare a livello di endpoint: cosa dite, ai fini compliance/GDPR è la stessa cosa decidere di mantenere i client su Windows XP (ormai non più supportato e quindi non più protetto dagli aggiornamenti di sicurezza), o evolvere verso il recente e quindi più robusto/aggiornato Windows 10??

Se quindi applicassimo il modello di sicurezza che vi ho appena proposto (in presenza di una applicazione cloud) allo scenario di esempio della produttività personale con soluzioni Microsoft, questo sarebbe il risultato corrispondente:


La suite di soluzioni Microsoft 365 (che racchiude licenze e relative funzionalità di Windows, EMS ed Office 365) è in grado quindi di offrire sia le tutele contrattuali dovute in quanto soluzioni cloud (livello 1) sia di offrire le soluzioni tecnologiche necessarie per mettere in sicurezza il trattamento del dato sugli ulteriori livelli (Livello 2, livello 3, livello Endpoint) che serve comunque indirizzare per un adeguata gestione del rischio.

Vi lascio con una considerazione per permettervi di fare un confronto con le altre soluzioni cloud sul mercato: tutti i Cloud Service Provider dovranno offrirvi (entro il 25 maggio) le tutele contrattuali GDPR per il livello 1, ma quanti sono in grado di offrirvi anche un insieme di soluzioni di sicurezza che si integrino tra di loro nel modo migliore possibile e verso le soluzioni on-premise per mettere in sicurezza gli altri livelli??

E per il confronto con le soluzioni totalmente on-premise? Nel caso di scenario puro on-premise tutta la catena di controlli e quindi di tutele tecnico-organizzative è solo in carico al cliente con tutto quello che ne consegue in termini di costi e tempi… mentre le soluzioni cloud, che – ripeto – devono essere contrattualmente conformi alla GDPR, permettono sia di “trasferire” una parte della gestione e quindi del rischio e di realizzare soluzioni di protezione in modo significativamente più rapido ed efficace di quanto si possa fare on-premise.

Ecco perché il Cloud, e solo quello Microsoft (per la capacità distintiva di offrirvi anche soluzioni di sicurezza di infrastruttura integrate tra loro), è a tutti gli effetti considerabile quale acceleratore della compliance (sia in generale che quella GDPR, nello specifico di questo momento storico), e questa a sua volta in grado di poter agire da acceleratore per la trasformazione digitale tanto necessaria e finora spesso frenata proprio dalle perplessità sul cloud nei confronti della conformità normativa.

Ai prossimi post il compito di illustrarvi questo insieme davvero ricco di funzionalità di sicurezza incluse in Microsoft 365.

P.S. ricordo il post che agirà da sommario di tutti i miei post a tema GDPR:

A presto!

 Feliciano

@felicianointini
(mostly in Italian – technical & non technical tweets)


@NonSoloSecurity
(English only – technical only)