Panoramica del framework di certificazione Microsoft 365

Questo articolo fornisce informazioni dettagliate sulla certificazione Microsoft 365, tra cui un elenco dei controlli di sicurezza necessari e indicazioni per ISV e sviluppatori.

La certificazione Microsoft 365 è un controllo indipendente della sicurezza e della privacy di app, componenti aggiuntivi, agenti e ambiente back-end di supporto (collettivamente denominati app) che si integrano con la piattaforma Microsoft 365. Le app che superano l'abbonamento saranno designate come Microsoft 365 Certified in tutto l'ecosistema di Microsoft 365 e possono essere trovate facilmente nei marketplace di Microsoft 365 tramite filtri di ricerca e personalizzazione incentrati sulla conformità. Gli ISV avranno l'opportunità di condividere gli attributi di conformità della propria app in pagine dedicate all'interno di questo set di documentazione.

La certificazione Microsoft 365 è disponibile per i seguenti tipi di applicazioni:

  • Componenti aggiuntivi di Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
  • App di Teams
  • Soluzioni SharePoint
  • App Web (SaaS)
  • Estensioni Copilot

Importante

La certificazione Microsoft 365 è una revisione rigorosa della sicurezza e della conformità di un'app rispetto al framework di certificazione Microsoft 365 e richiede un notevole impegno di tempo e risorse per essere completata. Prima di iniziare, esaminare i framework di controllo della conformità per verificare che l'app sia idonea. Se hai domande, invia un'e-mail appcert@microsoft.coma .

Condizioni

Partecipando al programma di certificazione Microsoft 365, l'utente accetta queste condizioni supplementari e di rispettare tutta la documentazione di accompagnamento che si applica alla partecipazione al programma di certificazione Microsoft 365 con Microsoft Corporation ("Microsoft", "noi", "ci" o "nostro"). L'utente dichiara e garantisce di avere l'autorità necessaria per accettare le presenti condizioni supplementari della certificazione Microsoft 365 per conto proprio, di una società e/o di un'altra entità, a seconda dei casi. Microsoft potrà cambiare, emendare o risolvere questi termini supplementari in qualsiasi momento. La partecipazione continua a partecipare al programma di certificazione di Microsoft 365 dopo eventuali modifiche o modifiche implica l'accettazione delle nuove condizioni supplementari. In caso di mancata accettazione delle nuove condizioni supplementari o in caso di risoluzione di tali condizioni supplementari, è necessario interrompere la partecipazione al programma di certificazione Microsoft 365.

Prerequisiti

Prima che la certificazione Microsoft 365 possa essere assegnata, un'app deve completare quanto segue:

Verifica autore Quando un'app ha un autore verificato, l'organizzazione che pubblica l'app è stata verificata come autentica da Microsoft. La verifica di un'app include l'uso di un account Microsoft Cloud Partner Program (CPP) verificato e l'associazione del PartnerID verificato a una registrazione dell'app. Ottieni la verifica dell'autore

L'attestazione dell'autore è un processo self-service in cui gli sviluppatori di app (ISV) completano una serie di domande sulle loro procedure di sicurezza, ad esempio la gestione dei dati sensibili. Al termine, l'app riceverà una pagina di documenti che potrà condividere con i clienti e che include le risposte fornite.

Rivedere i criteri di controllo. Non è sempre necessario rispettare tutti i controlli per ottenere una certificazione. Tuttavia, le soglie (che non saranno divulgate) sono attive per ciascuno dei tre domini di sicurezza discussi in questo documento di panoramica e devono essere superate. Il mancato rispetto dei controlli critici etichettati come "hard fail" comporterà il fallimento della valutazione.

Struttura dei costi

ISV collaborerà con la società di revisione per pagare la certificazione. Per ulteriori informazioni e per aprire un conto presso la società di revisione Claranet - clicca qui.

Tipo di controllo Contenuto Qualifiche professionali
Standard Valutazione completa rispetto a tutti i controlli applicabili Necessario per nuove valutazioni e ricertificazioni che non si qualificano per un audit satellitare. Necessario se una ricertificazione non supera i criteri di rischio stabiliti per un audit satellitare
Controllo satellitare In caso di soddisfacimento dei criteri, riduzione dei controlli fissati per il secondo e il terzo anno di valutazione Idoneo dopo aver completato la certificazione standard nell'anno 1. Per l'anno 2 e l'anno 3 se non sono stati apportati cambiamenti significativi e superare la valutazione del rischio
Tempi supplementari imbullonati Compilabile su richiesta, include il tempo di creazione di report Aggiunto solo quando un invio richiede più tempo con il revisore
Tariffa giornaliera Pentest Pentest mirato per impegno e in linea con i requisiti di certificazione che copre l'intero ambito concordato della valutazione Necessario se l'app non ha già un test della penna di terze parti affidabile negli ultimi 12 mesi
Clona Conferma di una presentazione clonata, revisione di eventuali controlli che necessitavano di ulteriori prove Un'app che condivide lo stesso ambiente back-end di un'app che ha recentemente completato la certificazione

Periodo di invio

Il processo di presentazione per ottenere la certificazione prevede due fasi:

Fase 1: Invio iniziale del documento (periodo di 14 giorni)

In questa fase, l'ISV deve inviare la documentazione che fornisce una panoramica dell'ambiente di supporto dell'app. Ciò include, a titolo esemplificativo:

  • Diagramma architettonico/flusso di dati
  • Elenchi dei componenti di sistema
  • Inventari di asset software

Un analista esaminerà questa documentazione per definire l'ambito della valutazione. L'ISV ha 14 giorni di tempo per completare e caricare la documentazione richiesta. Il mancato rispetto di questa scadenza può ritardare il processo o comportare un mancato invio.

Fase 2: Revisione completa delle prove (periodo di 60 giorni)

Una volta definito l'ambito, l'ISV passerà alla fase di raccolta delle prove. In questa fase:

  1. L'ISV deve caricare le prove di tutti i controlli applicabili definiti nell'ambito.

  2. Queste prove saranno sottoposte a revisione, revisioni (se necessario) e a un processo finale di domande e risposte.

  3. Durante questo periodo possono essere condotti anche test di penetrazione.

L'ISV ha 60 giorni per completare questa fase, a partire dalla prima presentazione delle prove, che include:

  • Caricamento delle prove per tutti i controlli
  • Revisione e feedback degli analisti
  • Eventuali revisioni necessarie delle prove presentate
  • Completamento del processo di domande e risposte

Mancato rispetto della scadenza

Se l'ISV non riesce a completare il processo entro l'intervallo di 60 giorni, la valutazione avrà esito negativo. Tuttavia, a discrezione dell'analista, una proroga fino a 60 giorni può essere concessa in circostanze valide, ad esempio:

  • Festività stagionali
  • Ritardi nei test di penetrazione
  • Modifiche interne
  • Tempo necessario per implementare le modifiche necessarie per soddisfare i requisiti di controllo

Non possono essere concesse ulteriori proroghe, una volta esauriti entrambi i periodi di tempo di 60 giorni.

Ambito di validità della certificazione

L'ambiente nell'ambito comprende tutti i sistemi e l'infrastruttura necessari per distribuire l'app, il componente aggiuntivo o il codice dell'agente, insieme a tutti i sistemi back-end di supporto con cui l'app/componente aggiuntivo/agente può comunicare. Anche tutti gli ambienti aggiuntivi connessi all'ambiente nell'ambito devono essere inclusi nell'ambito, a meno che non venga implementata un'adeguata segmentazione e gli ambienti connessi non possano compromettere la sicurezza dell'ambiente nell'ambito.

Nota: anche eventuali ambienti di ripristino di emergenza separati devono essere inclusi nell'ambiente nell'ambito, poiché questi ambienti possono essere fondamentali per mantenere la continuità del servizio in caso di errori dell'ambiente primario.

Inoltre, anche gli ambienti di backup remoto devono essere incorporati nell'ambito poiché possono archiviare dati Microsoft sensibili. Pertanto, devono essere implementati adeguati controlli di sicurezza per questi ambienti.

Il termine componenti di sistema nell'ambito include tutti i dispositivi e i sistemi utilizzati attivamente all'interno dell'ambiente nell'ambito definito. Questi componenti includono, a titolo esemplificativo:

  • Applicazioni Web
  • Server (fisici o virtuali, localizzati on-premise o nel cloud)
  • Cambia
  • Servizi di bilanciamento del carico
  • Infrastruttura virtuale
  • Portali di gestione Web dei provider di servizi cloud
  • Risorse cloud (Macchine virtuali, servizi app, account di archiviazione, database e così via)

Importante

I componenti di sistema rivolti al pubblico sono particolarmente vulnerabili agli attacchi da parte di attori delle minacce esterne e quindi a rischio maggiore. In genere, questi sistemi devono essere isolati dai componenti del sistema interno attraverso l'implementazione di controlli di sicurezza di rete (NSC), come una zona demilitarizzata (DMZ). Lo scopo di una DMZ è quello di fungere da zona cuscinetto, limitando la fiducia estesa ai sistemi esterni e migliorando la sicurezza per salvaguardare i sistemi e i dati interni. Sebbene una DMZ possa ancora essere ideale in alcuni casi, le moderne architetture cloud spesso si basano su misure di sicurezza alternative su misura per scenari di distribuzione specifici.

Infrastruttura distribuita come servizio (IaaS), PaaS (Platform as a Service) e SaaS (Software as a Service)

Laddove IaaS e/o PaaS viene utilizzato per supportare l'ambiente nell'ambito in esame, il provider della piattaforma Cloud sarà responsabile di alcuni dei controlli di sicurezza valutati durante il processo di certificazione. Gli analisti dovranno ricevere una verifica esterna indipendente delle migliori pratiche di sicurezza da parte del provider della piattaforma cloud attraverso report di conformità esterni come PCI-DSS, Attestation of Compliance (AOC), ISO 27001 o SOC 2 Type II.

Per informazioni dettagliate sui controlli di sicurezza probabilmente applicabili al tipo di distribuzione e sul fatto che l'ambiente elabori o trasferisca i dati di Microsoft 365, vedere l'Appendice C. I tipi di distribuzione includono:

  • ISV ospitato: applicazione ospitata da fornitori di software indipendenti.
  • Hosting IaaS: infrastruttura fornita da piattaforme cloud di terze parti.
  • PaaS/Serverless Hosted: applicazioni con media di architettura basata su piattaforma o serverless.
  • Ospitato in modo ibrido: una combinazione di componenti locali e ospitati nel cloud.
  • Ospitato condiviso: ambienti cloud condivisi usati da più tenant.

Nei casi in cui è in uso IaaS o PaaS, l'evidenza deve convalidare che la distribuzione sia in linea con i controlli di sicurezza previsti per l'architettura pertinente.

Campionamento

Per garantire una valutazione approfondita, il campionamento dei componenti di sistema inclusi nell'ambito deve considerare fattori quali i sistemi operativi, la funzione principale del dispositivo, il tipo di dispositivo (ad esempio, server, router, controlli di sicurezza della rete) e la posizione geografica. I campioni vengono selezionati all'inizio del processo di certificazione sulla base di queste considerazioni. La tabella seguente guida la dimensione del campionamento in base alla popolazione di componenti nell'ambito:

Dimensione della popolazione Esempio
<=5 1
>5 & <10= 2
>10 & <=30 3
>30 4

Ciò garantisce una valutazione rappresentativa della conformità dell'ambiente tra diverse configurazioni e modelli di distribuzione.

Nota

Se durante la valutazione vengono individuate discrepanze tra i dispositivi, la dimensione del campione può essere adattata per garantire un'adeguata presentazione dell'ambiente.

Panoramica del processo di certificazione

Per iniziare il processo di certificazione di Microsoft 365:

  1. Attestazione dell'autore Passare al Centro per i partner e compilare il modulo di attestazione dell'autore. Nota: se l'invio risale a più di tre mesi prima, è necessario inviarlo nuovamente per la revisione e la convalida.

  2. Avvia certificazione Una volta nel Centro per i partner, seleziona l'opzione "Avvia certificazione" per iniziare l'invio iniziale del documento. Questo passaggio consente agli analisti di certificazione di identificare l'ambito della valutazione in base all'architettura dell'app e al modo in cui gestisce i dati Microsoft. A questo punto ti verrà richiesto di creare un account con Claranet Limited.

La certificazione si svolge in due fasi principali:

  1. Invio iniziale del documento In questa fase, fornisci i dettagli chiave per aiutare gli analisti a comprendere la progettazione dell'app, il flusso di dati e l'ambiente nell'ambito. Gli analisti determineranno i controlli di sicurezza applicabili e delineeranno i componenti di sistema che richiedono prove. È necessario fornire una documentazione accurata per facilitare questa revisione, che rappresenta circa il 5% del processo complessivo.

  2. Revisione completa delle prove In questa fase vengono presentate prove dettagliate che dimostrano la conformità ai controlli di sicurezza per l'ambiente nell'ambito. Gli analisti lavoreranno a stretto contatto con te durante questa fase per esaminare, chiarire e verificare le tue richieste. Questa fase richiede il resto del processo.

Valutazione

Una volta approvato l'invio iniziale del documento, nel portale verrà visualizzato un elenco dei controlli di sicurezza richiesti. Hai 60 giorni per fornire prove per ogni controllo, confermando che è in atto e operativo. Gli analisti esamineranno le tue prove e le approveranno o richiederanno ulteriori dettagli o revisioni.

Certificazione

Una volta che la tua presentazione è stata esaminata e convalidata da un analista, riceverai una notifica relativa alla decisione di certificazione. Le app che soddisfano i criteri di certificazione riceveranno un badge, che verrà visualizzato nell'elenco AppSource e nelle pagine di Microsoft Docs associate. Queste pagine forniranno anche report dettagliati sugli attributi di sicurezza e conformità dell'app.

Revisione e rinnovo del certificato

Le app certificate Microsoft 365 devono essere sottoposte a una nuova certificazione annuale per garantire la continua conformità agli standard Microsoft. Il processo di rinnovo della certificazione comporta la rivalutazione dei controlli nell'ambito per confermare che siano allineati con l'ambiente corrente. È possibile iniziare il processo di rinnovo della certificazione fino a 90 giorni prima della scadenza della certificazione per evitare interruzioni. Le certificazioni rimarranno valide durante questo periodo.

Se la ricertificazione non viene completata prima della data di scadenza, la certificazione verrà revocata. Di conseguenza:

  • La certificazione, il badge e la personalizzazione dell'app verranno rimossi.

  • Gli ISV non saranno più autorizzati a commercializzare l'app come Microsoft 365 Certified.

Se vengono apportate modifiche significative all'app al di fuori del periodo di ricertificazione pianificato, gli ISV devono informare il programma di conformità delle app Microsoft per garantire che l'app rimanga conforme.

Invio iniziale del documento

L'invio iniziale deve includere le seguenti informazioni:

Panoramica della documentazione Dettagli della documentazione
Descrizione app/componente aggiuntivo/agente Descrizione dello scopo e della funzionalità dell'app/componente aggiuntivo/agente. Ciò dovrebbe fornire all'analista di certificazione una buona comprensione del funzionamento dell'app/componente aggiuntivo/agente e dell'uso previsto.
Report sui test di penetrazione Report di test di penetrazione completato negli ultimi 12 mesi. Questo rapporto deve includere l'ambiente che supporta la distribuzione dell'app/componente aggiuntivo/agente, insieme a qualsiasi ambiente aggiuntivo che supporti il funzionamento dell'app/componente aggiuntivo/agente. Nota: se l'ISV attualmente non esegue test di penetrazione annuali, il team di audit può completarne uno a un costo aggiuntivo.
Diagrammi di architettura Diagramma di architettura logica che rappresenta una panoramica generale dell'infrastruttura di supporto dell'app. Devono essere inclusi tutti gli ambienti host e le infrastrutture di supporto che supportano l'app. Questo diagramma DEVE rappresentare tutti i diversi componenti del sistema di supporto all'interno dell'ambiente per aiutare gli analisti della certificazione a comprendere i sistemi nell'ambito e a determinare il campionamento. Indicare anche il tipo di ambiente di hosting utilizzato. ISV ospitato, IaaS, PaaS o ibrido. Nota: Se viene utilizzato SaaS, indicare i vari servizi SaaS utilizzati per fornire servizi di supporto all'interno dell'ambiente.
Impronta pubblica Visualizzare in dettaglio tutti gli indirizzi IP pubblici e gli URL usati dall'infrastruttura di supporto. Ciò deve includere l'intero intervallo IP instradabile allocato all'ambiente, a meno che non sia stata implementata un'adeguata segmentazione per suddividere l'intervallo in uso (sarà necessaria un'adeguata prova della segmentazione).
Diagrammi del flusso di dati Diagrammi di flusso che descrivono in dettaglio quanto segue:
✓ Flussi di dati di Microsoft 365 da e verso l'app/componente aggiuntivo/agente (inclusi EUII e OII).
✓ Flussi di dati Microsoft 365 all'interno dell'infrastruttura di supporto (ove applicabile).
✓ Diagrammi che evidenziano dove e quali dati vengono archiviati, come i dati vengono trasmessi a terze parti esterne (compresi i dettagli di quali terze parti) e come i dati sono protetti in transito su reti aperte/pubbliche e a riposo.
Dettagli dell'endpoint API Elenco completo di tutti gli endpoint API usati dall'app. Per comprendere l'ambito dell'ambiente, specificare le posizioni degli endpoint API all'interno dell'ambiente.
Autorizzazioni API Microsoft Fornire la documentazione che illustra in dettaglio tutte le API Microsoft in uso, nonché le autorizzazioni richieste per il funzionamento dell'app/componente aggiuntivo/agente, nonché una giustificazione per le autorizzazioni richieste
Tipi di archiviazione dei dati Archiviazione e gestione dei dati documenti che descrivono:
✓ In che misura vengono ricevuti e archiviati Microsoft 365 Data EUII e OII
✓ Il periodo di conservazione dei dati.
✓ Perché vengono acquisiti i dati di Microsoft 365.
✓ Dove vengono archiviati i dati di Microsoft 365 (devono essere inclusi anche nei diagrammi di flusso dei dati forniti sopra).
Conferma di conformità Documentazione di supporto per i framework di sicurezza esterni inclusi nell'invio dell'attestazione dell'autore o da prendere in considerazione durante la revisione dei controlli di sicurezza della certificazione Microsoft 365. Al momento sono supportati i quattro elementi seguenti:
✓ Attestazione di conformità PCI DSS (AOC).
✓ Rapporti SOC 2 Tipo I/Tipo II.
✓ Dichiarazione di applicabilità (SoA) e certificazione ISMS / IEC - 1S0/IEC 27001.
✓ Pacchetto di autorizzazione FedRAMP FedRAMP e report di valutazione della preparazione FedRAMP.
Dipendenze Web Documentazione che elenca tutte le dipendenze usate dall'app con le versioni in esecuzione correnti.
Inventario software Un inventario software aggiornato che include tutto il software utilizzato nell'ambiente nell'ambito insieme alle versioni.
Inventario hardware Inventario hardware aggiornato usato dall'infrastruttura di supporto. Questo sarà utilizzato per aiutare con il campionamento durante l'esecuzione della fase di valutazione. Se l'ambiente include PaaS, fornire i dettagli relativi ai servizi/risorse cloud utilizzati.

Attività di raccolta e valutazione delle evidenze

Gli analisti della certificazione dovranno esaminare le prove in tutti i componenti del sistema all'interno del set di campioni definito. I tipi di prove richieste per supportare il processo di valutazione includono uno o tutti i seguenti:

Raccolta delle prove

  • Documentazione iniziale, evidenziata nella guida all'invio della documentazione iniziale
  • Documenti dei criteri
  • Elaborare documenti
  • Impostazioni di configurazione di sistema
  • Cambia ticket
  • Record di controllo delle modifiche
  • Report di sistema
  • Minuta della riunione
  • Contratti/accordi

Verranno utilizzati vari metodi per raccogliere le prove necessarie per completare il processo di valutazione. Questa raccolta di prove può avvenire sotto forma di:

  • Documenti
  • Screenshot
  • Interviste
  • Condivisione dello schermo

Le tecniche di raccolta delle prove utilizzate saranno determinate durante il processo di valutazione. Per esempi specifici del tipo di prove richieste nella tua presentazione, consulta la Guida alle prove di esempio.

Condivisione delle prove

Durante il processo di certificazione, gli ISV possono scegliere di condividere le prove di conformità direttamente con i potenziali clienti. La casella di controllo presente nella finestra di dialogo di caricamento del file, selezionata per impostazione predefinita, concede agli amministratori di Microsoft 365 l'accesso alla prova di certificazione dell'app nell'interfaccia di amministrazione di Teams e nell'interfaccia di amministrazione di Microsoft 365. Gli amministratori di Microsoft 365 sono responsabili della configurazione, della gestione e della protezione dei servizi e delle risorse di Microsoft 365 all'interno di un'organizzazione. Questa trasparenza ha lo scopo di semplificare la due diligence per le organizzazioni che valutano nuove applicazioni per accelerare il processo decisionale. Se un ISV preferisce non rendere pubbliche queste prove, può semplicemente deselezionare la casella al momento della presentazione, mantenendo il pieno controllo su come e quando viene divulgata la documentazione di conformità.

Attività di verifica dell'apprendimento

Gli analisti della certificazione esamineranno le prove inviate per verificare che tutti i controlli richiesti per la certificazione Microsoft 365 siano soddisfatti. Per accelerare il processo, assicurarsi che tutta la documentazione specificata nella presentazione della documentazione iniziale sia completa e fornita in anticipo.

Durante la revisione, gli analisti valuteranno le prove dalla presentazione iniziale e dall'attestazione dell'editore. Determineranno l'ambito dell'indagine, il lato del campionamento e se sono necessarie ulteriori prove. Gli analisti useranno tutte le informazioni raccolte per valutare la conformità alla specifica di certificazione Microsoft 365 e decidere se l'app soddisfa i controlli definiti.

Criteri di certificazione dell'app

L'app, la relativa infrastruttura di supporto e la documentazione di supporto verranno valutate nei tre domini di sicurezza seguenti:

  1. Sicurezza delle applicazioni
  2. Sicurezza operativa
  3. Gestione dei dati, sicurezza e privacy

Ognuno di questi domini di sicurezza include controlli chiave specifici che comprendono uno o più requisiti che verranno valutati come parte del processo di valutazione. Per garantire che la certificazione Microsoft 365 sia inclusiva per gli sviluppatori di tutte le dimensioni, ognuno dei domini di sicurezza viene valutato utilizzando un sistema di punteggio per determinare un punteggio complessivo da ognuno dei domini. I punteggi per ognuno dei controlli di certificazione Microsoft 365 sono allocati tra 1 (basso) e 3 (alto) in base al rischio percepito che tale controllo non venga implementato. Ognuno dei domini di sicurezza avrà un segno percentuale minimo per essere considerato un superamento. Alcuni fattori causano errori automatici, tra cui:

  • Utilizzo di autorizzazioni API che non aderiscono al principio dei privilegi minimi (PoLP)

  • Mancanza di rapporti di test di penetrazione quando richiesto.

  • Assenza di difese anti-malware.

  • Mancata implementazione dell'autenticazione a più fattori (MFA) per l'accesso amministrativo.

  • Processi di applicazione delle patch mancanti o insufficienti.

  • Mancanza di informativa sulla privacy GDPR non conforme.

Sicurezza delle applicazioni

Il dominio della sicurezza delle applicazioni valuta le aree seguenti:

  • Test di penetrazione
  • Convalida dell'autorizzazione dell'API Graph
  • Intelligenza Artificiale Responsabile

Test di penetrazione

I test di penetrazione sono fondamentali per identificare e attenuare i rischi associati all'app o al componente aggiuntivo e al relativo ambiente di supporto. In questo modo si garantisce che l'app fornisca garanzie di sicurezza adeguate ai clienti.

Il test di penetrazione è obbligatorio per qualsiasi app che si connette a servizi esterni non ospitati o gestiti da Microsoft. Se l'app viene distribuita come soluzione autonoma che usa solo servizi Microsoft come GraphAPI, il test di penetrazione potrebbe non essere necessario. Tuttavia, le app ospitate in Azure devono essere sottoposte a test di penetrazione per garantire la sicurezza dell'ambiente nell'ambito.

Ambito del test di penetrazione

Test dell'infrastruttura: per l'infrastruttura interna ed esterna, i test di penetrazione devono essere eseguiti nell'ambiente di produzione live che supporta l'app, il componente aggiuntivo o l'agente. Tra queste vi sono anche:

Ambiente in cui è ospitato l'app, il componente aggiuntivo o il codice dell'agente (in genere indicato nel file manifesto).

Eventuali ambienti aggiuntivi che interagiscono con o supportano il funzionamento dell'app/componente aggiuntivo/agente (ad esempio, se l'app/componente aggiuntivo/agente comunica con altre applicazioni Web all'esterno di Microsoft 365).

Quando si definisce l'ambito per i test di penetrazione, è fondamentale includere tutti i sistemi o gli ambienti connessi che possono influire sulla sicurezza dell'ambiente nell'ambito.

Raccomandazioni

Test di penetrazione delle applicazioni Web: si consiglia di eseguire i test di penetrazione delle app Web direttamente sull'ambiente di produzione live. Tuttavia, il test delle app Web può essere condotto in un ambiente di test/UAT (User Acceptance Testing), a condizione che il report del test di penetrazione confermi che la stessa base di codice viene utilizzata in produzione al momento del test.

Convalida della segmentazione: se le tecniche di segmentazione vengono utilizzate per isolare gli ambienti nell'ambito da altri, il rapporto del test di penetrazione deve convalidare l'efficacia di queste tecniche di segmentazione. Ciò garantisce che non vengano introdotte vulnerabilità attraverso il processo di segmentazione.

Requisiti dei test di penetrazione

I report dei test di penetrazione verranno esaminati per garantire che non vi siano vulnerabilità che soddisfano i criteri di errore automatico descritti nei controlli seguenti.

Tipo di criteri Controlli del test di penetrazione
Criteri generali I test di penetrazione delle applicazioni Web (autenticati e non autenticati) e dell'infrastruttura interna (se applicabile) ed esterna DEVONO essere eseguiti annualmente (ogni 12 mesi) e condotti da una società indipendente affidabile.
La correzione delle vulnerabilità critiche e ad alto rischio identificate DEVE essere completata entro un mese dalla conclusione del test di penetrazione, o prima a seconda del processo di applicazione delle patch documentato dell'ISV.
Footprint esterno completo (indirizzi IP, URL, endpoint API e così via) DEVE essere incluso nell'ambito del test di penetrazione e deve essere chiaramente documentato all'interno del rapporto del test di penetrazione.
A meno che l'ambiente non sia allineato a PaaS, le reti interne complete DEVONO essere incluse nell'ambito del test di penetrazione e devono essere chiaramente documentate all'interno del report del test di penetrazione.
I test di penetrazione delle applicazioni Web DEVONO includere tutte le classi di vulnerabilità; ad esempio, l'attuale OWASP Top 10 o SANS Top 25 CWE. La raccomandazione è che questo sia dettagliato all'interno del rapporto del test di penetrazione, altrimenti sarà difficile da dimostrare.
Le vulnerabilità critiche e ad alto rischio o le vulnerabilità considerate come errore automatico DEVONO essere nuovamente testate dalla società di test di penetrazione ed evidenziate chiaramente come risolte nel report del test di penetrazione.
Criteri di errore automatico: Presenza di un sistema operativo non supportato o di una libreria JavaScript non supportata.
Presenza di account amministrativi predefiniti, enumerabili o indovinabili.
Presenza di rischi di injection di SQL.
Presenza di script intersito.
Presenza di vulnerabilità di attraversamento della directory (percorso file).
Presenza di vulnerabilità HTTP, ad esempio suddivisione delle risposte dell'intestazione, contrabbando di richieste e attacchi di desincronizzazione.
Presenza di divulgazione del codice sorgente (incluso LFI).
Qualsiasi punteggio critico o elevato come definito dalle linee guida per la gestione delle patch CVSS.
Qualsiasi vulnerabilità tecnica significativa che può essere facilmente sfruttata per compromettere una grande quantità di EUII o OUI.

Importante

I rapporti devono essere in grado di fornire garanzie sufficienti che tutto ciò che è descritto nella sezione precedente sui requisiti dei test di penetrazione possa essere dimostrato.

Convalida delle autorizzazioni dell'API Graph

In questo modo si garantisce che l'app, il componente aggiuntivo o l'agente non richieda autorizzazioni eccessive o eccessivamente permissive. Gli analisti della certificazione esaminano manualmente le autorizzazioni richieste dall'app e le confrontano con l'invio dell'attestazione dell'autore.

L'obiettivo è verificare che le autorizzazioni richieste siano conformi al principio dei privilegi minimi. Se gli analisti rilevano che l'app richiede autorizzazioni che superano il necessario, si impegneranno con l'ISV per convalidare la giustificazione aziendale per queste autorizzazioni. Eventuali discrepanze identificate tra le autorizzazioni richieste e l'invio dell'attestazione dell'autore devono essere risolte durante questa revisione.

Intelligenza Artificiale Responsabile

Le informazioni inviate in risposta ai controlli dell'intelligenza artificiale responsabile verranno esaminate insieme al file manifesto dell'app fornito dall'ISV. Ciò consente all'analista di verificare l'integrazione di Microsoft Copilot con l'app in fase di certificazione, fornendo una chiara comprensione di come i due interagiscono tra loro e quali azioni vengono intraprese per conto del cliente. Riconosciamo che è fondamentale che l'intelligenza artificiale venga utilizzata in modo responsabile e laddove il cliente sia pienamente informato. A condizione che le informazioni condivise siano allineate con le funzionalità dell'app previste e con il Responsible AI Standardo NIST Trustworthy & Responsible Artificial Intelligence Resource Center di Microsoft, questi controlli saranno considerati approvati (soggetti ai consueti controlli Q/A).

L'intento è quello di collaborare ulteriormente con Microsoft per fornire alcuni dettagli di questo controllo nelle pagine pubbliche pertinenti, per consentire ai clienti di prendere decisioni pienamente informate sull'uso dei propri dati quando si tratta di Copilot e della relativa app.

Sicurezza operativa

Questo dominio misura l'allineamento dell'infrastruttura di supporto e dei processi di distribuzione di un'app con le procedure consigliate per la sicurezza.

Controlli

Famiglia di controlli Controlli
Formazione sulla consapevolezza Fornire prove che l'organizzazione fornisce una formazione consolidata sulla consapevolezza della sicurezza agli utenti dei sistemi informativi (inclusi manager, dirigenti senior e appaltatori) come parte della formazione iniziale per i nuovi utenti o quando richiesto da modifiche del sistema informativo.
Fornire prove di una frequenza di formazione sulla consapevolezza definita dall'organizzazione.
Fornire prove della documentazione e del monitoraggio delle attività di sensibilizzazione alla sicurezza dei singoli sistemi informativi conservando i record di formazione individuali con una frequenza definita dall'organizzazione.
Protezione malware - antivirus Fornire la prova che la soluzione antimalware sia attiva e abilitata in tutti i componenti di sistema campionati e configurata per soddisfare i criteri seguenti:
Se antivirus, la scansione all'accesso è abilitata e le firme sono aggiornate entro 1 giorno e blocca automaticamente il malware o gli avvisi e mette in quarantena quando viene rilevato malware.
OPPURE, se EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus), viene eseguita una scansione periodica, vengono generati registri di controllo, vengono mantenuti continuamente aggiornati e dispongono di funzionalità di autoapprendimento.
Se EDR/NGAV, blocca il malware noto e identifica e blocca le nuove varianti di malware in base ai comportamenti macro, oltre ad avere funzionalità complete di elenco indirizzi attendibili.
Protezione da malware - Controlli delle applicazioni Fornire prove dimostrabili dell'esistenza e dell'aggiornamento di un elenco approvato di software/applicazioni con giustificazione aziendale.
Che ogni applicazione sia sottoposta a un processo di approvazione e firma prima della distribuzione.
Che la tecnologia di controllo delle applicazioni sia attiva, abilitata e configurata in tutti i componenti di sistema campionati, come documentato.
Gestione delle patch - applicazione di patch e classificazione dei rischi Fornire la documentazione sulle politiche che regola il modo in cui vengono identificate le nuove vulnerabilità di sicurezza e assegnato un punteggio di rischio.
Fornire prove di come vengono identificate le nuove vulnerabilità di sicurezza.
Fornire prove che dimostrino che a tutte le vulnerabilità viene assegnata una classificazione di rischio una volta identificate.
Fornire la prova che tutti i componenti di sistema campionati vengono patchati in linea con i tempi di applicazione delle patch definiti dall'organizzazione e che i sistemi operativi e i componenti software non supportati non sono in uso. Se applicabile, ciò dovrebbe includere la base di codice se si usa la tecnologia serverless o PaaS, o sia l'infrastruttura che la base di codice se si usa IaaS.
Applicare patch linee guida per l'intervallo di tempo, ad esempio "critico - entro 14 giorni, alto - entro 30 giorni, medio - entro 60 giorni".
Analisi delle vulnerabilità Fornire i report trimestrali di scansione delle vulnerabilità dell'infrastruttura e delle applicazioni Web. La scansione deve essere eseguita sull'intera impronta pubblica (indirizzi IP e URL) e sugli intervalli IP interni.
Fornire prove dimostrabili che la correzione delle vulnerabilità identificate durante la scansione delle vulnerabilità viene corretta in linea con i tempi di applicazione delle patch documentati.
Controlli di sicurezza di rete (NSC) Fornire la prova che i controlli di sicurezza di rete (NSC) sono installati sul confine dell'ambiente nell'ambito e installati tra la rete perimetrale e le reti interne.
E se Hybrid, On-premise, IaaS forniscono anche la prova che tutti gli accessi pubblici terminano nella rete perimetrale.
Verificare che tutti i controlli di sicurezza di rete (NSC) siano configurati per eliminare il traffico non definito in modo esplicito nella base di regole e che le revisioni delle regole dei controlli di sicurezza di rete (NSC) vengano eseguite almeno ogni sei mesi.
Controllo delle modifiche Fornire prove che qualsiasi modifica introdotta agli ambienti di produzione sia implementata attraverso richieste di modifica documentate che contengano l'impatto della modifica, i dettagli delle procedure di back-out, i test da eseguire, la revisione e l'approvazione da parte del personale autorizzato.
Fornire prove dell'esistenza di ambienti separati in modo che: gli ambienti di sviluppo e di test/staging impongano la separazione dei compiti dall'ambiente di produzione, la separazione dei compiti venga applicata tramite controlli di accesso, i dati di produzione sensibili non siano in uso all'interno degli ambienti di sviluppo o di test/staging.
Sviluppo/distribuzione sicura del software Fornire criteri e procedure che supportino lo sviluppo sicuro del software e includano standard di settore e/o procedure consigliate per la codifica sicura. Ad esempio OWASP (Open Web Application Security Project) o SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE).
Fornire la prova che i repository di codice sono protetti in modo che: tutte le modifiche al codice siano sottoposte a un processo di revisione e approvazione da parte di un secondo revisore prima di essere fuse con il ramo principale, siano in atto controlli di accesso appropriati, tutti gli accessi siano applicati tramite autenticazione a più fattori (MFA)
Fornire la prova che tutti i rilasci effettuati negli ambienti di produzione vengono esaminati e approvati prima della distribuzione.
Gestione account Fornire prove del fatto che le credenziali predefinite siano disabilitate, rimosse o modificate nei componenti di sistema campionati.
Fornire la prova che è in atto un processo per proteggere gli account di servizio (protezione avanzata) e che questo processo è stato seguito.
Fornire la prova che: gli account utente univoci vengono rilasciati a tutti gli utenti, i principi dei privilegi minimi utente vengono seguiti all'interno dell'ambiente, sono in atto criteri di password/passphrase complesse o altre mitigazioni adeguate, è in atto un processo seguito almeno ogni tre mesi per disabilitare o eliminare gli account non utilizzati entro tre mesi.
Verificare che l'autenticazione a più fattori sia configurata per tutte le connessioni di accesso remoto e tutte le interfacce amministrative non della console, incluso l'accesso a tutti i repository di codice e alle interfacce di gestione cloud.
Registrazione degli eventi, revisione e avvisi di sicurezza Fornire la prova che i dati di registrazione degli eventi di sicurezza di almeno 30 giorni siano immediatamente disponibili, con 90 giorni di conservazione dei registri eventi di sicurezza.
Fornire prove del fatto che i log vengono esaminati periodicamente e che eventuali potenziali eventi/anomalie di sicurezza identificati durante il processo di revisione vengono analizzati e risolti
Fornire la prova che le regole di avviso sono configurate in modo che gli avvisi vengano attivati per l'analisi degli eventi di sicurezza seguenti, se applicabile: creazione/modifica di account con privilegi, attività o operazioni con privilegi/ad alto rischio, eventi malware, manomissione del registro eventi, eventi IDPS/WAF. (se configurato)
Gestione dei rischi delle informazioni Fornire la prova che una politica/processo formale di gestione dei rischi per la sicurezza delle informazioni ratificato sia documentato e stabilito.
Fornire la prova che una valutazione formale dei rischi per la sicurezza delle informazioni a livello aziendale viene effettuata almeno una volta all'anno.
OR per l'analisi mirata dei rischi: un'analisi mirata dei rischi è documentata ed eseguita almeno ogni 12 mesi per ogni caso in cui non è in atto un controllo tradizionale o una best practice del settore, in cui una limitazione progettuale/tecnologica crea il rischio di introdurre una vulnerabilità nell'ambiente o mette a rischio gli utenti e i dati, in caso di sospetto o conferma di compromissione.
Convalidare che la valutazione dei rischi per la sicurezza delle informazioni includa componenti di sistema o risorse interessate, minacce e vulnerabilità o equivalenti, matrici di impatto e probabilità o equivalenti, la creazione di un registro dei rischi/piano di trattamento dei rischi.
Fornisci la prova di disporre di un processo di gestione del rischio che valuta e gestisce i rischi associati a fornitori e partner commerciali e puoi identificare e valutare modifiche e rischi che potrebbero influire sul tuo sistema di controlli interni.
Risposta agli eventi imprevisti di sicurezza Fornire il piano/procedura di risposta agli incidenti di sicurezza (IRP) ratificato.
Fornire prove che illustrino il modo in cui l'organizzazione risponde agli incidenti, mostrando come viene mantenuta e che includano dettagli del team di risposta agli incidenti, comprese le informazioni di contatto, un piano di comunicazione interna durante l'incidente e la comunicazione esterna alle parti interessate, ad esempio stakeholder chiave, marchi di pagamento e acquirer, organismi di regolamentazione (ad esempio 72 ore per GDPR), autorità di vigilanza, amministratori, clienti, nonché passaggi per attività quali la classificazione degli incidenti, il contenimento, la mitigazione, il ripristino e il ritorno alle normali operazioni aziendali a seconda del tipo di incidente
Fornire la prova che tutti i membri del team di risposta agli incidenti hanno ricevuto una formazione annuale che consente loro di rispondere agli incidenti.
Fornire prove che la strategia di risposta agli incidenti e la documentazione di supporto siano esaminate e aggiornate in base alle lezioni apprese da un esercizio da tavolo, alle lezioni apprese dalla risposta a un incidente, ai cambiamenti organizzativi.
Piano di continuità aziendale e piano di ripristino di emergenza Fornire la prova dell'esistenza e del mantenimento della documentazione che delinea il piano di continuità aziendale.
Fornire prove che il piano di continuità operativa descriva in dettaglio il personale pertinente e i relativi ruoli e responsabilità, tra cui: funzioni aziendali con requisiti e obiettivi di emergenza associati, procedure di backup del sistema e dei dati, configurazione e pianificazione/conservazione, priorità di ripristino e obiettivi temporali, un piano di emergenza che descriva in dettaglio le azioni, le fasi e le procedure da seguire per ripristinare l'operatività dei sistemi informativi critici, delle funzioni aziendali e dei servizi in caso di interruzione imprevista e non programmata, un processo consolidato che copre l'eventuale ripristino completo del sistema e il ritorno allo stato originale.
Fornire la prova che la documentazione esiste, è mantenuta e delinea il piano di ripristino di emergenza e include come minimo: personale e i suoi ruoli, responsabilità e processo di escalation, inventario dei sistemi informativi utilizzati per supportare funzioni e servizi aziendali critici, procedure e configurazione di backup del sistema e dei dati, un piano di ripristino che descriva in dettaglio le azioni e le procedure da seguire per ripristinare l'operatività dei sistemi informativi e dei dati critici.
Fornire la prova che il piano di continuità operativa e il piano di ripristino di emergenza vengono rivisti almeno ogni 12 mesi per garantire che rimangano validi ed efficaci in situazioni avverse.
Fornire prove che il piano di continuità operativa viene aggiornato in base alla revisione annuale del piano, a tutto il personale pertinente che riceve una formazione sui ruoli e sulle responsabilità assegnati nei piani di emergenza, che i piani siano in fase di test attraverso esercizi di continuità aziendale o di disaster recovery, che i risultati dei test siano documentati, comprese le lezioni apprese dall'esercizio o dai cambiamenti organizzativi.

Gestione dei dati, sicurezza e privacy

Per garantire la sicurezza dei dati, tutti i dati in transito tra l'utente dell'applicazione, i servizi intermediari e i sistemi ISV devono essere crittografati tramite connessione TLS (Transport Layer Security). È necessario almeno TLS 1.2, mentre TLS 1.3 o versione successiva è fortemente consigliato. Per ulteriori dettagli, vedere l'Appendice A.

Per le applicazioni che recuperano o archiviano i dati di Microsoft 365, è obbligatorio implementare uno schema di crittografia dell'archiviazione dei dati. Ciò deve essere in linea con le specifiche descritte nell'Appendice B.

Controlli

Famiglia di controlli Controlli
Dati in transito Fornire prove che convalidino che la configurazione TLS sia TLS1.2 o successiva entro i requisiti di configurazione del profilo TLS e che venga mantenuto e mantenuto un inventario di chiavi e certificati attendibili.
Fornire prove mostra che la compressione TLS è disabilitata per tutti i servizi pubblici che gestiscono le richieste Web per prevenire il rapporto di compressione Info-leak Made Easy (CRIME) e TLS HSTS è abilitato e configurato su 180 giorni in tutti i siti.
Dati inattivi Fornire la prova che i dati inattivi siano crittografati in linea con i requisiti del profilo di crittografia, usando algoritmi di crittografia come Advanced Encryption Standard (AES), RSA e Twofish con dimensioni della chiave di crittografia di 256 bit o superiori.
Conservazione, backup ed eliminazione dei dati fornire la prova che un periodo di conservazione dei dati approvato è formalmente stabilito e documentato.
Fornire prove del fatto che i dati vengono conservati solo per il periodo di conservazione definito, come descritto nel controllo precedente.
Fornire prove dell'esistenza di processi per eliminare in modo sicuro i dati dopo il periodo di conservazione.
Fornire la prova che un sistema di backup automatico sia in atto e configurato per eseguire i backup a orari pianificati.
Fornire prove che le informazioni di backup vengono testate in linea con la procedura di pianificazione del backup e ripristinate periodicamente per confermare l'affidabilità e l'integrità dei dati.
Fornire prove Vengono implementati controlli di accesso e meccanismi di protezione appropriati (ad es. backup immutabili) per garantire che i backup / istantanee di sistema siano protetti da accessi non autorizzati e per garantire la riservatezza, l'integrità e la disponibilità dei dati di backup.
Gestione dell'accesso ai dati Fornire la prova che viene mantenuto un elenco di utenti con accesso ai dati e/o alle chiavi di crittografia. Inclusa la motivazione aziendale per ogni persona e la conferma, questo elenco di utenti è stato formalmente approvato in base ai privilegi di accesso necessari per la loro funzione lavorativa e gli utenti sono configurati con i privilegi descritti nell'approvazione.
Fornire la prova che viene mantenuto un elenco di tutte le terze parti con cui vengono condivisi i dati e che sono in essere accordi di condivisione dei dati con tutte le terze parti che consumano i dati.
Privacy L'organizzazione dispone di un sistema di gestione delle informazioni sulla privacy (PIM) stabilito, implementato e mantenuto che mantiene l'impegno di leadership tramite una politica o un'altra forma di documentazione/sistema computerizzato per il modo in cui vengono mantenuti gli sforzi di gestione delle informazioni sulla privacy per la riservatezza e l'integrità del sistema. Determina i ruoli, le responsabilità e le autorità di ogni persona che gestisce il sistema, inclusi i responsabili del trattamento e i titolari del trattamento delle informazioni personali.
Fornire prove dei processi per verificare che la minimizzazione delle PII sia in corso, che la de-identificazione e l'eliminazione delle PII vengano effettuate alla fine del periodo di elaborazione, che siano in atto controlli per la trasmissione delle PII, inclusa l'eventuale riservatezza, che la registrazione del trasferimento delle PII da un paese/regione a un altro esista con il consenso esplicito a farlo.
GDPR Fornire la prova che gli interessati sono in grado di generare SAR, che l'ISV è in grado di identificare tutte le posizioni dei dati degli interessati quando risponde a una richiesta SAR, che esiste un periodo di conservazione per i backup che consente ai client che richiedono la rimozione dei dati tramite SAR da rimuovere mentre i backup a rotazione per un periodo vengono rimossi (ciclo di vita delle eliminazioni/riscritte di backup meno recenti).
Fornire l'informativa sulla privacy che deve contenere tutti gli elementi richiesti come segue: dettagli organizzativi (nome, indirizzo e altre informazioni personali identificabili), tipo di dati personali trattati, per quanto tempo verranno conservati i dati personali, liceità del trattamento dei dati personali, diritti degli interessati; tra cui: diritti dell'interessato, diritto di essere informato, diritto di accesso dell'interessato, diritto alla cancellazione, diritto di limitazione del trattamento, diritto alla portabilità dei dati, diritto di opposizione, diritti in relazione al processo decisionale automatizzato, compresa la profilazione.
HIPAA Fornisci la prova che: esiste una politica per la gestione HIPAA e HIPAA all'interno della tua organizzazione per personale, appaltatori, fornitori, ecc. Verifica che la nostra organizzazione garantisca la riservatezza, l'integrità e la disponibilità di ePH.
Verificare di: fornire protezione contro usi o divulgazioni ragionevolmente previsti di tali informazioni che non sono consentiti dalla norma sulla privacy, garantire la conformità alla regola di sicurezza da parte della propria forza lavoro. Fornire un piano di backup dei dati e ripristino di emergenza ai sensi di 164.308 (a)(7)(ii)(A) e 164.308 (a)(7)(ii)(B).

Revisione del framework di conformità esterna facoltativa

Se l'organizzazione è già conforme a framework di sicurezza esterni, ad esempio ISO 27001, PCI-DSS, FedRAMP o SOC 2 Type 2, è possibile scegliere di sfruttare queste certificazioni per soddisfare alcuni dei controlli della certificazione Microsoft 365. Gli analisti cercheranno di allineare i framework di sicurezza esterni esistenti ai requisiti di certificazione di Microsoft 365.

Tuttavia, se la documentazione di supporto non dimostra che i controlli di certificazione Microsoft 365 sono stati valutati in modo esplicito come parte del controllo o della valutazione del framework esterno, è necessario fornire ulteriori prove per verificare che questi controlli siano in atto.

Requisiti di documentazione:

La documentazione deve dimostrare chiaramente che l'ambiente nell'ambito per la certificazione Microsoft 365 è incluso nell'ambito dei framework di sicurezza eterna. La convalida di questi framework sarà soddisfatta accettando la prova di certificazioni valide rilasciate da revisori di terze parti affidabili e accreditati.

Questi revisori di terze parti devono essere membri di organismi internazionali di accreditamento, quali:

  • Standard di certificazione e conformità per ISO 27001

  • Valutatori di sicurezza della qualità (QSA) per PCI-DSS

Per ulteriori dettagli, consulta le linee guida e gli standard specifici per i framework esterni rilevanti per la certificazione.

La tabella seguente illustra i framework e la documentazione necessari accettati dagli analisti di certificazione come parte del processo di convalida.

Standard Requisiti
ISO 27001 Sarà richiesta una versione pubblica della Dichiarazione di applicabilità (SOA) e una copia del certificato ISO 27001 emesso. La SOA riassume la tua posizione su ciascuno dei 114 controlli di sicurezza delle informazioni e verrà utilizzata per identificare eventuali esclusioni di controlli che non sono dettagliati in modo soddisfacente nel certificato ISO 27001. Se ciò non può essere determinato esaminando la versione pubblica della SOA, l'analista potrebbe aver bisogno di accedere alla SOA completa se verrà utilizzato ISO 27001 per convalidare alcuni dei controlli di sicurezza della certificazione Microsoft 365. Oltre a convalidare l'ambito delle attività di valutazione ISO 27001, gli analisti confermeranno anche la validità della società di audit come sopra descritto.
ISO 22301 È necessario fornire un certificato ISO 22301 valido rilasciato da un organismo di certificazione accreditato e un documento che descriva l'ambito della valutazione del sistema di gestione della continuità operativa (BCMS). La documentazione relativa al certificato e all'ambito verrà utilizzata per verificare che l'applicazione nell'ambito, i servizi di supporto e i processi operativi siano stati valutati nell'ambito di un programma formale di gestione della continuità aziendale. Gli analisti della valutazione esamineranno l'ambito della certificazione, confermeranno la validità dell'organismo di certificazione e determineranno quali controlli di continuità aziendale della certificazione Microsoft 365 possono essere soddisfatti tramite i dati della valutazione ISO 22301.
Norma ISO 27031 Deve essere fornito un certificato ISO 27031 valido o un rapporto di valutazione rilasciato da un organismo di certificazione o valutazione accreditato, che identifichi chiaramente l'applicazione, l'infrastruttura e i servizi di supporto delle tecnologie dell'informazione e della comunicazione (ICT) nell'ambito. La documentazione verrà utilizzata per valutare la preparazione ICT per la continuità aziendale, compresa la pianificazione del ripristino di emergenza, le capacità di ripristino e i processi di resilienza. Gli analisti della valutazione esamineranno l'ambito della valutazione, confermeranno la validità dell'organizzazione di valutazione e determineranno quali controlli di ripristino di emergenza e resilienza operativa della certificazione Microsoft 365 possono essere soddisfatti tramite le prove della valutazione ISO 27031
PCI DSS È necessario fornire un documento valido di attestazione di conformità di livello 1 che identifichi chiaramente l'applicazione nell'ambito e i componenti del sistema. Un COA di autovalutazione non sarà accettato come prova del rispetto delle migliori pratiche di sicurezza. Il COA verrà usato per determinare quali controlli della specifica di certificazione Microsoft 365 sono stati valutati e confermati nell'ambito della valutazione PCI DSS.
SOC 2 Il report SOC 2 (Tipo II) deve essere aggiornato (emesso negli ultimi 15 mesi e nel periodo di tempo dichiarato iniziato negli ultimi 27 mesi) per essere usato come prova di conformità con uno qualsiasi dei controlli di valutazione nell'ambito di questo framework di certificazione Microsoft 365.
FedRAMP Il Federal Risk and Authorization Management Program (FedRAMP) è un programma a livello di governo federale degli Stati Uniti istituito nel 2011. Fornisce un approccio standardizzato alla valutazione della sicurezza, all'autorizzazione e al monitoraggio continuo per i prodotti e i servizi cloud.
Struttura Considerazioni aggiuntive
ISO 27001 Appendice C: Raccolta di prove - Delta per ISO 27001.
PCI-DSS Appendice D: Raccolta di prove - Delta per PCI-DSS.
SOC 2 Appendice E: Raccolta di prove - Delta per SOC 2.

Nota

Mentre gli standard o i framework di sicurezza esterni possono essere inviati come prova a sostegno del rispetto di determinati controlli della certificazione Microsoft 365, l'ottenimento della certificazione Microsoft 365 richiede una valutazione separata. L'ottenimento della certificazione Microsoft 365 non implica che l'app abbia superato completamente i controlli per questi framework esterni. La specifica di certificazione Microsoft 365 si concentra su un sottoinsieme specifico di controlli derivati da questi framework per fornire a Microsoft un livello superiore di garanzia del comportamento di sicurezza dell'app.

Requisiti per l'uso di framework di conformità esterni

Requisiti per l'uso di framework di conformità esterni

L'ambiente nell'ambito e tutti i processi aziendali di supporto devono essere inclusi nell'ambito di qualsiasi framework di conformità della sicurezza esterno supportato. Questi devono essere chiaramente documentati nella documentazione fornita.

I framework di conformità della sicurezza esterna devono essere aggiornati, ossia devono essere valutati negli ultimi 12 mesi (o entro 15 mesi se è possibile verificare una nuova valutazione in corso con prove a supporto)

Le valutazioni di conformità della sicurezza esterna devono essere condotte da un'azienda indipendente e accreditata.

Criteri di convalida del framework esterno

Valutazione SOC 2 tipo 2

  • Il report SOC 2 deve essere di tipo 2
  • Il controllo SOC 2 deve includere l'ambiente M365 da valutare
  • L'audit SOC 2 deve essere completato negli ultimi 12 mesi
  • I controlli devono essere presentati in modo equo e progettati correttamente come richiesto per un rapporto di tipo 2
  • L'audit SOC 2 deve essere condotto da una terza parte esterna qualificata
  • Le procedure di prova devono confermare che i controlli di sicurezza sono in atto e adeguatamente convalidati dall'auditor.

Valutazione ISO 27001

  • L'audit ISO 27001 deve includere l'ambiente specificato in questa valutazione M365
  • Il certificato ISO 27001 deve essere aggiornato e applicabile all'entità
  • La valutazione ISO 27001 deve essere condotta da una terza parte esterna accreditata (gli audit interni ISO 27001 non sono accettati)
  • La valutazione ISO 27001 deve essere completata negli ultimi 12 mesi

Valutazione PCI-DSS

  • Il documento AOC deve definire chiaramente l'ambiente M365 da valutare
  • Il COA deve essere aggiornato
  • Il COA deve essere approvato dal QSA e dall'ente

Ulteriori informazioni

  • Ultimo aggiornamento: