Panoramica del framework di certificazione microsoft 365
Questo articolo fornisce informazioni dettagliate sulla certificazione Microsoft 365, incluso 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 e ambiente back-end di supporto (collettivamente definito app) che si integra con la piattaforma Microsoft 365. Le app che passano saranno designate microsoft 365 certificate in tutto l'ecosistema 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à dell'app nelle pagine dedicate all'interno di questo set di documentazione.
La certificazione Microsoft 365 è disponibile per i tipi di applicazioni seguenti:
- 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 impegno notevole in termini di tempo e risorse per il completamento. Prima di iniziare, esaminare i framework di controllo di conformità per verificare che l'app sia idonea. In caso di domande, inviare un messaggio di posta elettronica appcert@microsoft.coma .
Termini
Partecipando al programma di certificazione Microsoft 365, l'utente accetta queste condizioni supplementari e si conforma a qualsiasi documentazione che si applica alla partecipazione al programma di certificazione Microsoft 365 con Microsoft Corporation ("Microsoft", "noi", "noi" o "nostro"). L'utente dichiara e garantisce di avere l'autorità di accettare queste condizioni supplementari per la certificazione Microsoft 365 per conto proprio, di una società e/o di un'altra entità, a seconda dei casi. Possiamo modificare, modificare o terminare questi termini supplementari in qualsiasi momento. La partecipazione continua al programma di certificazione Microsoft 365 dopo qualsiasi modifica o modifica significa che accetti le nuove condizioni supplementari. Se non si accettano le nuove condizioni supplementari o se terminiamo queste condizioni supplementari, è necessario interrompere la partecipazione al programma di certificazione Microsoft 365.
Prerequisiti
Prima di ottenere la certificazione Microsoft 365, un'app deve completare quanto segue:
Verifica del server di pubblicazione Quando un'app ha un editore 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. Ottenere la verifica dell'autore
L'attestazione del server di pubblicazione è un processo self-service in cui gli sviluppatori di app (ISV) completano una serie di domande sulle procedure di sicurezza, ad esempio la gestione dei dati sensibili. Al termine, l'app riceverà speciali notifiche e presentazioni nel marketplace Microsoft AppSource.
Esaminare i criteri di controllo Non è sempre un requisito rispettare tutti i controlli per ottenere una certificazione. Tuttavia, le soglie (che non verranno divulgate) sono valide per ognuno dei tre domini di sicurezza descritti in questo documento di panoramica e devono essere passate. Se non si soddisfano i controlli critici etichettati come "hard fail", la valutazione avrà esito negativo.
Intervallo di tempo per l'invio
Esistono due fasi del processo di invio per ottenere la certificazione:
Fase 1: Invio iniziale del documento (intervallo di tempo di 14 giorni)
In questa fase, l'ISV deve inviare la documentazione che fornisce una panoramica dell'ambiente di supporto delle app. Ciò include, ma non è limitato a:
- Diagramma architetturale/Flusso di dati
- Elenchi di componenti di sistema
- Inventari degli asset software
Un analista esaminerà questa documentazione per definire l'ambito della valutazione. L'ISV ha 14 giorni per completare e caricare la documentazione necessaria. Il mancato rispetto di questa scadenza può ritardare il processo o causare un invio non riuscito.
Fase 2: Revisione completa delle prove (intervallo di tempo di 60 giorni)
Dopo aver definito l'ambito, l'ISV procederà alla fase di raccolta delle evidenze. In questa fase:
- L'ISV deve caricare l'evidenza su tutti i controlli applicabili definiti dall'ambito.
- Questa prova verrà sottoposta a revisione, revisioni (se necessario) e a un processo di controllo di qualità finale.
- Se necessario, anche i test di penetrazione possono essere eseguiti durante questo periodo.
L'ISV ha 60 giorni per completare questa fase, a partire dal primo invio di prove, che include:
- Caricamento dell'evidenza per tutti i controlli
- Revisione e feedback degli analisti
- Eventuali revisioni necessarie per l'invio di prove
- Completamento del processo di controllo di qualità
Mancato rispetto della scadenza
Se l'ISV non riesce a completare il processo entro l'intervallo di tempo di 60 giorni, la valutazione avrà esito negativo. Tuttavia, a discrezione dell'analista, può essere concessa un'estensione fino a 60 giorni aggiuntivi 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 è possibile concedere ulteriori estensioni, una volta esauriti entrambi i 60 giorni.
Ambito di certificazione
L'ambiente nell'ambito comprende tutti i sistemi e l'infrastruttura necessari per distribuire l'app o il codice del componente aggiuntivo, insieme a tutti i sistemi back-end di supporto con cui l'app/componente aggiuntivo può comunicare. Eventuali ambienti aggiuntivi connessi all'ambiente nell'ambito devono essere inclusi anche nell'ambito, a meno che non venga implementata una segmentazione adeguata e gli ambienti connessi non possano compromettere la sicurezza dell'ambiente nell'ambito.
Nota: tutti gli ambienti di ripristino di emergenza separati devono essere inclusi anche 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 perché possono archiviare dati Microsoft sensibili. Pertanto, è necessario implementare controlli di sicurezza adeguati per questi ambienti.
Il termine componenti di sistema nell'ambito include tutti i dispositivi e i sistemi usati attivamente all'interno dell'ambiente definito nell'ambito. Questi componenti includono, ma non sono limitati a:
- Applicazioni Web
- Server (fisici o virtuali, che si trovano in locale o nel cloud)
- Interruttori
- Servizi di bilanciamento del carico
- Infrastruttura virtuale
- Portali di gestione Web del provider di servizi cloud
- Risorse cloud (Macchine virtuali, servizi app, account di archiviazione, database e così via)
Importante
I componenti di sistema pubblici sono particolarmente vulnerabili agli attacchi da parte di attori esterni delle minacce e quindi a un rischio più elevato. In genere, questi sistemi devono essere isolati dai componenti interni del sistema tramite l'implementazione di controlli di sicurezza di rete,ad esempio una zona demilitarizzata (DMZ). Lo scopo di una rete perimetrale è quello di fungere da zona buffer, limitando l'attendibilità estesa ai sistemi esterni e migliorando la sicurezza per proteggere i sistemi e i dati interni. Anche se una rete perimetrale può essere ancora ideale in alcuni casi, le architetture cloud moderne spesso si basano su misure di sicurezza alternative personalizzate per scenari di distribuzione specifici.
Infrastruttura distribuita come servizio (IaaS), Piattaforma distribuita come servizio (PaaS) e Software as a Service (SaaS)
Quando IaaS e/o PaaS vengono usati 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 essere dotati di verifica esterna indipendente delle procedure consigliate per la sicurezza da parte del provider della piattaforma cloud tramite report di conformità esterni come i report PCI DSS, Attestazione di conformità (AOC), ISO 27001 o SOC 2 tipo II.
Per informazioni dettagliate su quali controlli di sicurezza sono probabilmente applicabili al tipo di distribuzione e se l'ambiente elabora o trasferisce i dati di Microsoft 365, vedere l'appendice C. I tipi di distribuzione includono:
ISV Ospitato: applicazione ospitata da fornitori di software indipendenti ospitata da IaaS: infrastruttura fornita da piattaforme cloud di terze parti. PaaS/Serverless Hosted: applicazioni con una media dell'architettura basata su piattaforma o serverless. Ibrido ospitato: combinazione di componenti locali e ospitati nel cloud. Condiviso ospitato: ambienti cloud condivisi utilizzati da più tenant.
Nei casi in cui è in uso IaaS o PaaS, è necessario verificare che la distribuzione sia allineata ai controlli di sicurezza previsti per l'architettura pertinente.
Campionamento
Per garantire una valutazione approfondita, il campionamento dei componenti del sistema nell'ambito deve prendere in considerazione fattori come i sistemi operativi, la funzione del dispositivo primario, il tipo di dispositivo (ad esempio, server, router, controlli di sicurezza di rete) e la posizione geografica. Gli esempi vengono selezionati all'inizio del processo di certificazione in base a queste considerazioni. La tabella seguente illustra le dimensioni del campionamento in base alla popolazione di componenti nell'ambito:
| Dimensioni 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 vengono identificate discrepanze tra i dispositivi durante la valutazione, le dimensioni del campione possono essere modificate per garantire una presentazione adeguata dell'ambiente.
Panoramica del processo di certificazione
Per iniziare il processo di certificazione microsoft 365:
Attestazione server di pubblicazione Passare al Centro per i partner e completare il modulo Attestazione server di pubblicazione. Nota: se l'invio ha più di tre mesi, è necessario inviarlo di nuovo per la revisione e la convalida.
Avviare la certificazione Una volta nel Centro per i partner, selezionare l'opzione "Avvia certificazione" per iniziare l'invio del documento iniziale. 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.
La certificazione viene eseguita in due fasi principali:
Invio iniziale di documenti In questa fase vengono forniti i dettagli chiave per consentire agli analisti di comprendere la progettazione, il flusso di dati e l'ambiente nell'ambito dell'app. Gli analisti determineranno i controlli di sicurezza applicabili e descrivono i componenti di sistema che richiedono prove. È necessario fornire una documentazione accurata per facilitare questa revisione, che rappresenta circa il 5% del processo complessivo.
Verifica completa delle prove In questa fase vengono inviate prove dettagliate che dimostrano la conformità con i controlli di sicurezza per l'ambiente nell'ambito. Gli analisti lavoreranno a stretto contatto con l'utente durante questa fase per esaminare, chiarire e verificare gli invii. Questa fase accetta il resto del processo.
Valutazione
Dopo l'approvazione dell'invio iniziale del documento, nel portale verrà visualizzato un elenco dei controlli di sicurezza necessari. Sono disponibili 60 giorni per fornire prove per ogni controllo, confermando che è operativo. Gli analisti esamineranno le prove e le approveranno o richiederanno ulteriori dettagli o revisioni.
Certificazione
Dopo che l'invio è stato esaminato e convalidato da un analista, si riceverà una notifica relativa alla decisione di certificazione. Alle app che soddisfano correttamente i criteri di certificazione verrà assegnato un badge, che verrà visualizzato nella presentazione di AppSource e nelle pagine Microsoft Docs associate. Queste pagine forniranno anche report dettagliati sugli attributi di sicurezza e conformità dell'app.
Rivedere e ricertificare
Le app con certificazione Microsoft 365 devono essere ricertificate ogni anno per garantire la conformità continua agli standard Microsoft. Il processo di ricertificazione prevede la rivalutazione dei controlli nell'ambito per confermare l'allineamento con l'ambiente corrente. È possibile iniziare il processo di ricertificazione 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:
Il badge di certificazione e la personalizzazione dell'app verranno rimossi.
Gli ISV non saranno più autorizzati a commercializzare l'app come Microsoft 365 Certified.
Se sono presenti modifiche significative all'app al di fuori del periodo di ricertificazione pianificato, gli ISV devono informare il Programma di conformità delle app Microsoft per assicurarsi che l'app rimanga conforme.
Invio iniziale del documento
L'invio iniziale deve includere le informazioni seguenti:
| Panoramica della documentazione | Dettagli della documentazione |
|---|---|
| Descrizione dell'app/componente aggiuntivo | Descrizione dello scopo e della funzionalità dell'app/componente aggiuntivo. Questo dovrebbe fornire all'analista della certificazione una buona comprensione del funzionamento dell'app/componente aggiuntivo e dell'uso previsto |
| Report di test di penetrazione | Report di test di penetrazione completato negli ultimi 12 mesi. Questo report deve includere l'ambiente che supporta la distribuzione dell'app/aggiunta insieme a qualsiasi altro ambiente che supporti il funzionamento dell'app/componente aggiuntivo. Nota: se l'ISV attualmente non esegue test di penetrazione annuali, Microsoft coprirà il costo del test della penna tramite il processo di certificazione. |
| Diagrammi di architettura | Diagramma dell'architettura logica che rappresenta una panoramica generale dell'infrastruttura di supporto dell'app. Deve includere tutti gli ambienti di hosting e l'infrastruttura di supporto per l'app. Questo diagramma DEVE descrivere tutti i diversi componenti di sistema di supporto all'interno dell'ambiente per aiutare gli analisti di certificazione a comprendere i sistemi nell'ambito e a determinare il campionamento. Indicare anche il tipo di ambiente di hosting usato. ISV Ospitato, IaaS, PaaS o Ibrido. Nota: Dove viene usato SaaS, indicare i vari servizi SaaS usati per fornire servizi di supporto all'interno dell'ambiente. |
| Footprint pubblico | Dettagli su tutti gli URL e gli indirizzi IP pubblici usati dall'infrastruttura di supporto. Questo deve includere l'intervallo IP instradabile completo allocato all'ambiente a meno che non sia stata implementata una segmentazione adeguata per dividere l'intervallo in uso (saranno necessarie prove adeguate di segmentazione) |
| Diagrammi del flusso di dati | Diagrammi di flusso che illustrano in dettaglio quanto segue: |
| ✓ Flussi di dati di Microsoft 365 da e verso l'app/componente aggiuntivo (inclusi EUII e OII). | |
| ✓ Flussi di dati di Microsoft 365 all'interno dell'infrastruttura di supporto (se applicabile). | |
| ✓ Diagrammi che evidenziano dove e quali dati vengono archiviati, come vengono passati i dati a terze parti esterne (inclusi i dettagli di quali terze parti) e come i dati vengono protetti in transito su reti aperte/pubbliche e inattivi. | |
| Dettagli dell'endpoint API | Elenco completo di tutti gli endpoint API usati dall'app. Per comprendere l'ambito dell'ambiente, specificare i percorsi degli endpoint API all'interno dell'ambiente. |
| Autorizzazioni dell'API Microsoft | Fornire la documentazione che illustra in dettaglio TUTTE le API Microsoft usate insieme alle autorizzazioni richieste per il funzionamento dell'app/componente aggiuntivo insieme a una giustificazione per le autorizzazioni richieste |
| Tipi di archiviazione dati | Archiviazione dei dati e gestione dei documenti che descrivono: |
| ✓ In che misura i dati di Microsoft 365 EUII e OII vengono ricevuti e archiviati | |
| ✓ 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 di dati forniti in precedenza). | |
| Conferma della conformità | Documentazione di supporto per i framework di sicurezza esterni inclusi nell'invio dell'attestazione del server di pubblicazione o da prendere in considerazione quando si esaminano i controlli di sicurezza della certificazione microsoft 365. Attualmente sono supportati i quattro elementi seguenti: |
| ✓ Attestazione di conformità (AOC) PCI DSS . | |
| ✓ Report SOC 2 tipo I/Tipo II. | |
| ✓ ISMS / IEC - 1S0/IEC 27001 Dichiarazione di applicabilità (SoA) e certificazione. | |
| ✓ FedRAMP FedRAMP Authorization Package e FedRAMP Readiness Assessment Report. | |
| Dipendenze Web | Documentazione che elenca tutte le dipendenze usate dall'app con le versioni in esecuzione correnti. |
| Inventario software | Inventario software aggiornato che include tutto il software usato nell'ambiente nell'ambito insieme alle versioni. |
| Inventario hardware | Inventario hardware aggiornato usato dall'infrastruttura di supporto. Verrà usato per facilitare il campionamento durante l'esecuzione della fase di valutazione. Se l'ambiente include PaaS, specificare i dettagli dei servizi cloud o delle risorse utilizzate. |
Attività di raccolta e valutazione delle prove
Gli analisti di certificazione dovranno esaminare le prove in tutti i componenti di sistema all'interno del set di esempi definito. I tipi di prove necessari per supportare il processo di valutazione includono uno o tutti i seguenti:
Raccolta di prove
- Documentazione iniziale, evidenziata nella guida all'invio della documentazione iniziale
- Documenti dei criteri
- Elaborare i documenti
- Impostazioni di configurazione del sistema
- Modificare i ticket
- Modificare i record di controllo
- Report di sistema
- Minuti riunione
- Contratti/contratti
Verranno usati vari metodi per raccogliere le prove necessarie per completare il processo di valutazione. Questa raccolta di prove può essere sotto forma di:
- Documenti
- Screenshot
- Interviste
- Screenharing
Le tecniche di raccolta delle prove usate verranno determinate durante il processo di valutazione. Per esempi specifici del tipo di prova richiesto nell'invio, vedere la Guida all'evidenza di esempio.
Attività di valutazione
Gli analisti di certificazione esamineranno le prove inviate per verificare che tutti i controlli necessari per la certificazione Microsoft 365 siano soddisfatti. Per accelerare il processo, assicurarsi che tutta la documentazione specificata nell'invio iniziale della documentazione sia completa e fornita in anticipo.
Durante la revisione, gli analisti valuteranno le prove dell'invio iniziale e dell'attestazione del server di pubblicazione. Determineranno l'ambito dell'indagine, il lato del campionamento e se sono necessarie prove aggiuntive. Gli analisti useranno tutte le informazioni raccolte per valutare la conformità con la specifica della certificazione Microsoft 365 e decidere se l'app soddisfa i controlli definiti.
Criteri di certificazione delle app
L'app e l'infrastruttura di supporto e la documentazione di supporto verranno valutate nei tre domini di sicurezza seguenti:
- Sicurezza delle applicazioni
- Sicurezza operativa/distribuzione sicura
- Sicurezza e privacy nella gestione dei dati
Ognuno di questi domini di sicurezza include controlli chiave specifici che includono 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, ogni dominio di sicurezza viene valutato usando un sistema di assegnazione dei punteggi per determinare un punteggio complessivo da ognuno dei domini. I punteggi per ognuno dei controlli di certificazione di Microsoft 365 vengono 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 punteggio percentuale minimo da considerare come pass. Alcuni fattori causano errori automatici, tra cui
Uso di autorizzazioni API che non rispettano il principio dei privilegi minimi (PoLP)
Mancanza di report di test di penetrazione quando necessario.
Assenza di difese antimalware.
Errore di implementazione dell'autenticazione a più fattori (MFA) per l'accesso amministrativo.
Processi di applicazione di patch mancanti o insufficienti.
Mancanza di informativa sulla privacy gdpr conforme.
Sicurezza delle applicazioni
Il dominio di sicurezza dell'applicazione valuta le aree seguenti:
- Convalida delle autorizzazioni GraphAPI
- Controlli di connettività esterni
- Test di penetrazione
Convalida delle autorizzazioni GraphAPI
Ciò garantisce che l'app o il componente aggiuntivo non richieda autorizzazioni eccessive o eccessivamente permissive. Gli analisti di certificazione esaminano manualmente le autorizzazioni richieste dall'app e le verificano in base all'invio dell'attestazione del server di pubblicazione.
L'obiettivo è verificare che le autorizzazioni richieste rispettino il 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 del server di pubblicazione devono essere risolte durante questa verifica.
Controlli di connettività esterni
Come parte del processo di certificazione, gli analisti eseguono una revisione generale delle funzionalità dell'applicazione per identificare eventuali connessioni esterne effettuate al di fuori di Microsoft 365.
Tutte le connessioni non identificate come servizi Microsoft o non correlate al servizio verranno segnalate per la discussione durante la valutazione per garantire la conformità con gli standard di sicurezza e funzionalità.
Test di penetrazione
Il test di penetrazione è fondamentale per identificare e attenuare i rischi associati all'app o al componente aggiuntivo e al relativo ambiente di supporto. In questo modo l'app garantisce ai clienti garanzie di sicurezza adeguate.
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, potrebbe non essere necessario eseguire il test di penetrazione. Tuttavia, le app ospitate in Azure devono essere sottoposte a test di penetrazione per garantire la sicurezza dell'ambiente nell'ambito.
Ambito dei 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 o il componente aggiuntivo. Tra queste vi sono anche:
Ambiente in cui è ospitato il codice dell'app o del componente aggiuntivo (in genere a cui si fa riferimento nel file manifesto)
Eventuali ambienti aggiuntivi che interagiscono con o supportano il funzionamento dell'app/componente aggiuntivo (ad esempio, se l'app/componente aggiuntivo comunica altre applicazioni Web all'esterno di Microsoft 365).
Quando si definisce l'ambito per il 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: è consigliabile eseguire test di penetrazione delle app Web direttamente nell'ambiente di produzione live. Tuttavia, i test delle app Web possono essere eseguiti in un ambiente test/UAT (User Acceptance Testing), a condizione che il report di test di penetrazione confermi che la stessa codebase viene usata in produzione al momento del test.
Convalida della segmentazione: se si usano tecniche di segmentazione per isolare ambienti nell'ambito da altri ambienti, il report di test di penetrazione deve convalidare l'efficacia di queste tecniche di segmentazione. In questo modo non vengono introdotte vulnerabilità tramite il processo di segmentazione.
Requisiti di test di penetrazione
I report sui test di penetrazione verranno esaminati per verificare che non siano presenti vulnerabilità che soddisfano i criteri di errore automatici seguenti descritti nei controlli seguenti.
| Tipo di criteri | Controlli di test di penetrazione |
|---|---|
| Criteri generali | L'applicazione Web (autenticata e non autenticata) e i test di penetrazione dell'infrastruttura interna (se applicabile) ed esterna devono essere eseguiti ogni anno (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 dei test di penetrazione o prima, a seconda del processo di applicazione di patch documentato dell'ISV. | |
| Footprint esterno completo (indirizzi IP, URL, endpoint API e così via) DEVE essere incluso nell'ambito dei test di penetrazione e deve essere chiaramente documentato nel rapporto di test di penetrazione. | |
| A meno che l'ambiente non sia allineato a PaaS, le reti interne complete DEVONO essere incluse nell'ambito dei test di penetrazione e devono essere chiaramente documentate nel report di test di penetrazione. | |
| Il test di penetrazione delle applicazioni Web DEVE includere tutte le classi di vulnerabilità; Ad esempio, il più recente OWASP Top 10 o SANS Top 25 CWE. La raccomandazione è che questo sia dettagliato all'interno del report di test di penetrazione in caso contrario sarà difficile da dimostrare. | |
| Le vulnerabilità o le vulnerabilità critiche e ad alto rischio considerate come un errore automatico DEVONO essere rivisitate dalla società di test di penetrazione e chiaramente evidenziate come fisse all'interno del report di 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 inserimento SQL. | |
| Presenza di script tra siti. | |
| Presenza di vulnerabilità di attraversamento della directory (percorso file). | |
| Presenza di vulnerabilità HTTP, ad esempio la divisione della risposta dell'intestazione, il contrabbando delle richieste e gli attacchi Desync. | |
| Presenza di divulgazione del codice sorgente (inclusa 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 report devono essere in grado di fornire una garanzia sufficiente che tutti gli elementi descritti nella sezione relativa ai requisiti di test di penetrazione precedenti possano essere dimostrati.
Requisiti e regole di test di penetrazione gratuiti
Per gli ISV che attualmente non eseguono test di penetrazione, Microsoft offre un servizio di test di penetrazione gratuito come parte del processo di certificazione Microsoft 365. Questo servizio copre fino a 12 giorni di test manuali, con costi aggiuntivi per tutti i giorni necessari oltre a questa responsabilità dell'ISV.
Requisiti
Requisiti di pre-test: l'ISV deve inviare prove e ricevere l'approvazione per il 50% dei controlli nell'ambito prima di pianificare il test di penetrazione.
Report di test: questo report, insieme alla certificazione Microsoft 365, può essere usato per dimostrare ai clienti che l'ambiente è sicuro.
Correzione della vulnerabilità: gli ISV sono responsabili della risoluzione di eventuali vulnerabilità identificate durante i test prima che sia possibile ottenere la certificazione. Tuttavia, non è necessario un report pulito, solo la prova di conferma che le vulnerabilità sono state adeguatamente affrontate.
Considerazione aggiuntive
Una volta organizzato un test di penetrazione, l'ISV è responsabile della copertura di eventuali tariffe associate alla riprogrammazione o all'annullamento.
| Riprogrammazione della scala cronologica delle tariffe | Percentuale pagabile |
|---|---|
| Richiesta di riprogrammazione ricevuta più di 30 giorni prima della data di inizio pianificata. | 0% pagabile |
| Richiesta di riprogrammazione ricevuta da 8 a 30 giorni prima della data di inizio pianificata. | 25% pagabile |
| Riprogrammare la richiesta ricevuta entro 2-7 giorni prima della data di inizio pianificata con una data di ri-prenotazione dell'azienda. | 50% pagabile |
| Richiesta di riprogrammazione ricevuta meno di 2 giorni prima della data di inizio. | 100% pagabile |
| Scala cronologica della tariffa di annullamento | Percentuale pagabile |
|---|---|
| Richiesta di annullamento ricevuta più di 30 giorni prima della data di inizio pianificata. | 25% pagabile |
| Richiesta di annullamento ricevuta da 8 a 30 giorni prima della data di inizio pianificata. | 50% pagabile |
| Richiesta di annullamento ricevuta entro 7 giorni prima della data di inizio pianificata. | 90% pagabile |
Sicurezza operativa
Questo dominio misura l'allineamento dei processi di distribuzione e infrastruttura di supporto di un'app con le procedure consigliate per la sicurezza.
Controlli
| Famiglia di controlli | Controlli |
|---|---|
| Formazione sulla sensibilizzazione | Fornire prove che l'organizzazione fornisce formazione di sensibilizzazione sulla sicurezza agli utenti del sistema informativo (tra cui manager, dirigenti senior e appaltatori) come parte della formazione iniziale per i nuovi utenti o quando richiesto dalle modifiche del sistema informativo. |
| Fornire la prova di una frequenza di formazione sulla consapevolezza definita dall'organizzazione. | |
| Fornire prove della documentazione e del monitoraggio delle singole attività di sensibilizzazione sulla sicurezza del sistema informativo mantenendo i singoli record di formazione su una frequenza definita dall'organizzazione. | |
| Protezione da malware - antivirus | Fornire la prova che la soluzione antimalware è attiva e abilitata in tutti i componenti del sistema campionati e configurata per soddisfare i criteri seguenti: |
| Se antivirus, l'analisi all'accesso è abilitata e le firme sono aggiornate entro 1 giorno e blocca automaticamente malware o avvisi e quarantena quando viene rilevato malware. | |
| Oppure se EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus) viene eseguita l'analisi periodica, i log di controllo vengono generati e vengono mantenuti aggiornati continuamente e con funzionalità di apprendimento automatico. | |
| Se EDR/NGAV blocca il malware noto e identifica e blocca nuove varianti di malware in base ai comportamenti macro, oltre ad avere funzionalità complete di elenco sicuro. | |
| 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 subisce un processo di approvazione e si disconnette prima della distribuzione | |
| Tale tecnologia di controllo delle applicazioni è attiva, abilitata e configurata in tutti i componenti di sistema campionati come documentato. | |
| Gestione delle patch - Applicazione di patch e classificazione dei rischi | Documentazione dei criteri di fornitura che regola il modo in cui vengono identificate le nuove vulnerabilità di sicurezza e viene assegnato un punteggio di rischio. |
| Fornire la prova di come vengono identificate nuove vulnerabilità di sicurezza. | |
| Fornire prove che dimostrino che a tutte le vulnerabilità viene assegnata una classificazione dei rischi una volta identificata. | |
| Fornire la prova che tutti i componenti del sistema campionati vengono sottoposti a patch in linea con gli intervalli di tempo definiti dalle organizzazioni e che i sistemi operativi e i componenti software non supportati non sono in uso. Se applicabile, deve includere la base di codice se viene usata la tecnologia serverless o PaaS oppure sia l'infrastruttura che la codebase se viene usato IaaS. | |
| Linee guida per l'intervallo di tempo per l'applicazione di patch: critico, entro 14 giorni, alto, entro 30 giorni, medio, entro 60 giorni. | |
| Analisi delle vulnerabilità | Fornire i report trimestrali sull'analisi delle vulnerabilità dell'infrastruttura e dell'applicazione Web. L'analisi deve essere eseguita in base all'intero footprint pubblico (indirizzi IP e URL) e agli intervalli IP interni. |
| Fornire prove dimostrabili che la correzione delle vulnerabilità identificate durante l'analisi delle vulnerabilità viene applicata a patch in linea con l'intervallo di tempo di applicazione delle patch documentato. | |
| Controlli di sicurezza di rete (NSC) | Fornire la prova che i controlli di sicurezza di rete (NSC) sono installati sul limite dell'ambiente nell'ambito e installati tra la rete perimetrale e le reti interne. |
| And if Hybrid, On-prem, IaaS also provide evidence that all public access terminates at the perimeter network.AND if Hybrid, On-prem, IaaS also provide evidence that all public access terminates at the perimeter network. | |
| Verificare che tutti i controlli di sicurezza di rete (NSC) siano configurati per eliminare il traffico non definito in modo esplicito all'interno della base delle regole e che le verifiche delle regole NSC (Network Security Controls) vengano eseguite almeno ogni 6 mesi. | |
| Modificare il controllo | Fornire la prova che le modifiche introdotte negli ambienti di produzione vengono implementate tramite richieste di modifica documentate che contengono 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 la prova che esistono ambienti separati in modo che: gli ambienti di sviluppo e test/staging impongono la separazione dei compiti dall'ambiente di produzione, la separazione dei compiti viene applicata tramite controlli di accesso, i dati di produzione sensibili non sono in uso negli ambienti di sviluppo o di test/staging. | |
| Sviluppo/distribuzione di software sicuro | Fornire criteri e procedure che supportano lo sviluppo di software sicuro e includono standard di settore e/o procedure consigliate per la codifica sicura. Ad esempio Open Web Application Security Project (OWASP) Top 10 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 vengano sottoposte a un processo di revisione e approvazione da parte di un secondo revisore prima di essere uniti al ramo principale, siano presenti controlli di accesso appropriati, tutto l'accesso venga applicato tramite l'autenticazione a più fattori (MFA) | |
| Fornire la prova che tutte le versioni effettuate negli ambienti di produzione vengono esaminate e approvate prima della distribuzione. | |
| Gestione account | Fornire la prova che le credenziali predefinite sono disabilitate, rimosse o modificate nei componenti di sistema campionati. |
| Fornire la prova che è in atto un processo per proteggere (rafforzare) gli account del servizio 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 dell'utente vengono seguiti all'interno dell'ambiente, un criterio password/passphrase sicuro o altre mitigazioni appropriate sono in atto, è in atto un processo e seguito almeno ogni tre mesi per disabilitare o eliminare gli account non usati 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 console, incluso l'accesso a qualsiasi repository di codice e interfacce di gestione cloud. | |
| Eventlogging, revisione e avvisi di sicurezza | Fornire la prova che sono immediatamente disponibili almeno 30 giorni di dati di registrazione eventi di sicurezza, con 90 giorni di log eventi di sicurezza conservati. |
| Fornire la prova che i log vengono esaminati periodicamente e che eventuali eventi/anomalie di sicurezza identificati durante il processo di revisione vengono esaminati e risolti | |
| Fornire la prova che le regole di avviso sono configurate in modo che vengano attivati avvisi per l'analisi per i seguenti eventi di sicurezza, se applicabile: creazione/modifica di account con privilegi, attività o operazioni con privilegi/rischio elevato, eventi malware, manomissione del log eventi, eventi IDPS /WAF. (se configurato) | |
| Gestione dei rischi delle informazioni | Fornire la prova che un processo o un criterio di gestione dei rischi di sicurezza delle informazioni formale ratificato sia documentato e stabilito. |
| Fornire la prova che una valutazione formale dei rischi di sicurezza delle informazioni a livello aziendale viene eseguita almeno ogni anno. | |
| OR for Targeted Risk Analysis (O per l'analisi dei rischi mirata): un'analisi dei rischi mirata è documentata ed eseguita almeno ogni 12 mesi per ogni istanza in cui non è presente 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 utenti e dati, su sospetto o conferma di compromissione. | |
| Verificare che la valutazione dei rischi per la sicurezza delle informazioni includa componenti di sistema o risorse interessate, minacce e vulnerabilità o matrici equivalenti, di impatto e probabilità o equivalenti, la creazione di un piano di trattamento del rischio/registro dei rischi. | |
| Fornire la prova che sono in atto processi di gestione dei rischi che valutano e gestiscono i rischi associati a fornitori e partner commerciali ed è possibile identificare e valutare le modifiche e i rischi che potrebbero influire sul sistema di controlli interni. | |
| Risposta agli eventi imprevisti di sicurezza | Specificare il piano/la procedura di risposta agli eventi imprevisti di sicurezza ratificato. |
| Fornire prove che descrivono come l'organizzazione risponde agli eventi imprevisti, mostrando come viene mantenuta e che include i dettagli del team di risposta agli eventi imprevisti, tra cui informazioni di contatto, un piano di comunicazione interno durante l'evento imprevisto e la comunicazione esterna a parti rilevanti, ad esempio stakeholder chiave, marchi di pagamento e acquirenti, organismi normativi (ad esempio 72 ore per GDPR), autorità di vigilanza, amministratori, clienti e passaggi per attività come la classificazione degli eventi imprevisti, il contenimento, la mitigazione, il ripristino e il ritorno alle normali operazioni aziendali a seconda del tipo di evento imprevisto | |
| Fornire la prova che tutti i membri del team di risposta agli eventi imprevisti hanno ricevuto una formazione annuale che consente loro di rispondere agli eventi imprevisti. | |
| Fornire la prova che la strategia di risposta agli eventi imprevisti e la documentazione di supporto vengono riviste e aggiornate in base alle lezioni apprese da un esercizio di tabella superiore, alle lezioni apprese in risposta a un evento imprevisto e alle modifiche dell'organizzazione. | |
| Piano di continuità aziendale e piano di ripristino di emergenza | Fornire la prova che la documentazione esiste e viene gestita, che descrive il piano di continuità aziendale. |
| Fornire la prova che il piano di continuità aziendale dettaglia il personale pertinente e i relativi ruoli e responsabilità, tra cui: funzioni aziendali con requisiti e obiettivi di emergenza associati, procedure di backup di sistema e dati, configurazione e pianificazione/conservazione, obiettivi di priorità e intervallo di tempo di ripristino, un piano di emergenza che descrive in dettaglio azioni, passaggi e procedure da seguire per restituire sistemi informativi critici, funzioni aziendali e servizi da eseguire in caso di un interruzione imprevista e non pianificata, un processo stabilito che copre l'eventuale ripristino completo del sistema e il ritorno allo stato originale. | |
| Fornire la prova che la documentazione esiste, viene gestita e descrive il piano di ripristino di emergenza e include almeno: il personale e i relativi ruoli, responsabilità e processo di escalation, l'inventario dei sistemi informativi usati per supportare funzioni e servizi aziendali critici, le procedure e la configurazione di backup di sistema e dati, un piano di ripristino che descrive in dettaglio le azioni e le procedure da seguire per ripristinare i sistemi informativi critici e i dati al funzionamento. | |
| Fornire la prova che il piano di continuità aziendale e il piano di ripristino di emergenza vengono esaminati almeno ogni 12 mesi per garantire che rimanga valido ed efficace in situazioni avverse. | |
| Fornire la prova che il piano di continuità aziendale viene aggiornato in base alla revisione annuale del piano, tutto il personale pertinente che riceve formazione sui ruoli e le responsabilità assegnati nei piani di emergenza, il piano/i viene testato tramite esercizi di continuità aziendale o ripristino di emergenza, i risultati dei test sono documentati, incluse le lezioni apprese dall'esercizio o dalle modifiche dell'organizzazione. |
Sicurezza e privacy per la gestione dei dati
Per garantire la sicurezza dei dati, tutti i dati in transito tra l'utente dell'applicazione, i servizi intermedi e i sistemi ISV devono essere crittografati tramite la connessione TLS (Transport Layer Security). È necessario almeno TLS 1.2, con TLS 1.3 o versione successiva fortemente consigliato. Per altre informazioni, vedere l'appendice A.
Per le applicazioni che recuperano o archiviano dati di Microsoft 365, è obbligatorio implementare uno schema di crittografia dell'archiviazione dati. Questo deve essere in linea con le specifiche descritte nell'appendice B.
Controlli
| Famiglia di controlli | Controlli |
|---|---|
| Dati in transito | Fornire la prova che convalida che la configurazione TLS sia TLS1.2 o superiore entro i requisiti di configurazione del profilo TLS e che venga mantenuto e eseguita un'inventario di chiavi e certificati attendibili. |
| Fornire prove che mostrano che la compressione TLS è disabilitata per tutti i servizi pubblici che gestiscono le richieste Web per impedire la perdita di informazioni sul rapporto di compressione Made Easy (CRIME) e TLS HSTS è abilitato e configurato per 180 giorni in tutti i siti. | |
| Dati inattivi | Fornire la prova che i dati inattivi sono 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 pari o superiori a 256 bit. |
| Conservazione, backup ed eliminazione dei dati | Fornire la prova che un periodo di conservazione dei dati approvato sia formalmente stabilito e documentato. |
| Fornire la prova che i dati vengono conservati solo per il periodo di conservazione definito, come illustrato nel controllo precedente. | |
| Fornire la prova che i processi sono in atto per eliminare in modo sicuro i dati dopo il periodo di conservazione. | |
| Fornire la prova che è in atto un sistema di backup automatizzato e configurato per eseguire i backup in orari pianificati. | |
| Fornire le informazioni di backup delle prove viene testato in linea con la procedura di pianificazione del backup e ripristinato periodicamente per confermare l'affidabilità e l'integrità dei dati. | |
| Vengono implementati controlli di accesso e meccanismi di protezione appropriati (ad esempio backup non modificabili) per garantire che i backup o gli snapshot di sistema siano protetti da accessi non autorizzati e per garantire la riservatezza, l'integrità e la disponibilità dei dati di backup. | |
| Gestione accesso ai dati | Fornire la prova che viene mantenuto un elenco di utenti con accesso ai dati e/o alle chiavi di crittografia. Includendo la giustificazione aziendale per ogni persona e confermando che questo elenco di utenti è stato formalmente approvato in base ai privilegi di accesso necessari per la funzione di processo 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 vigore contratti di condivisione dei dati con tutte le terze parti che utilizzano 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 un criterio o un'altra forma di documentazione/sistema informatizzato per il modo in cui le attività di gestione delle informazioni sulla privacy vengono mantenute per la riservatezza e l'integrità del sistema. Determina i ruoli, le responsabilità e le autorità di ogni persona che gestisce il sistema, inclusi processori e controller pii. |
| Fornire prove dei processi per verificare che la minimizzazione delle informazioni personali sia in corso, la de-identificazione e l'eliminazione delle informazioni personali vengono eseguite alla fine del periodo di elaborazione, sono in atto controlli per la trasmissione delle informazioni personali, inclusa la riservatezza, la registrazione del trasferimento di informazioni personali da un paese/area geografica a un altro esiste con il consenso espresso a farlo. | |
| GDPR | Fornire la prova che gli interessati sono in grado di generare richieste SAR, che l'ISV è in grado di identificare tutte le posizioni dei dati degli interessati quando rispondono a una richiesta DISA, che esiste un periodo di conservazione per i backup che consente ai client che richiedono la rimozione dei dati tramite SAR di essere rimossi come backup in sequenza in un periodo di tempo (ciclo di vita delle eliminazioni di backup meno recenti/riscritto). |
| Fornire l'informativa sulla privacy che deve contenere tutti gli elementi necessari come segue: i dettagli dell'organizzazione (nome, indirizzo e altre informazioni personali identificabili), il tipo di dati personali trattati, la durata della conservazione dei dati personali, la liceità del trattamento dei dati personali, i diritti degli interessati; tra cui: diritti dell'interessato, diritto di essere informato, diritto di accesso da parte dell'interessato, diritto di cancellazione, diritto alla restrizione del trattamento, diritto alla portabilità dei dati, diritto all'oggetto, diritti in relazione al processo decisionale automatizzato, inclusa la profilatura. | |
| HIPAA | Fornire la prova che: esiste un criterio per la gestione HIPAA e HIPAA all'interno dell'organizzazione per personale, appaltatori, fornitori e così via. Verificare che l'organizzazione garantisca riservatezza, integrità e disponibilità di ePH. |
| Verificare che l'utente: fornire protezione da usi ragionevolmente previsti o divulgazioni di tali informazioni che non sono consentite dalla regola sulla privacy, garantire la conformità con la regola di sicurezza da parte della sua forza lavoro. Specificare un piano di backup dei dati e ripristino di emergenza ai sensi della versione 164.308 (a)(7)(ii)(A) e 164.308 (a)(7)(ii)(B). |
Revisione facoltativa del framework di conformità esterna
Se l'organizzazione è già conforme ai framework di sicurezza esterni, ad esempio ISO 27001, PCI DSS, FedRAMP o SOC 2 di tipo 2, è possibile scegliere di sfruttare queste certificazioni per soddisfare alcuni dei controlli di certificazione di 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 di Microsoft 365 sono stati valutati in modo esplicito come parte del controllo o della valutazione del framework esterno, è necessario fornire prove aggiuntive per verificare che questi controlli siano presenti.
Requisiti della documentazione
La documentazione deve dimostrare chiaramente che l'ambiente nell'ambito della certificazione Microsoft 365 è incluso nell'ambito dei framework di sicurezza permanenti. La convalida di questi framework verrà soddisfatta accettando prove di certificazioni valide rilasciate da revisori di terze parti attendibili e accreditati.
Questi revisori di terze parti devono essere membri di organismi di accreditamento internazionali, ad esempio:
Standard di certificazione e conformità per ISO 27001
Quality Security Assessors (QSA) per PCI DSS
Per altri dettagli, vedere le linee guida e gli standard specifici per i framework esterni rilevanti per la certificazione.
La tabella seguente descrive i framework e la documentazione richiesti accettati dagli analisti di certificazione come parte del processo di convalida.
| Standard | Requisiti |
|---|---|
| ISO 27001 | Sarà necessaria una versione pubblica dell'Informativa sull'applicabilità (SOA) e una copia del certificato ISO 27001 emesso. Il SOA riepiloga la posizione in ognuno dei 114 controlli di sicurezza delle informazioni e verrà usato per identificare se eventuali esclusioni di controlli non descritti in modo soddisfacente nel certificato ISO 27001. Se non è possibile determinare questo problema esaminando la versione pubblica del SOA, l'analista potrebbe dover accedere all'intero SOA se iso 27001 verrà usato 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 controllo come descritto in precedenza. |
| PCI DSS | È necessario fornire un documento di attestazione di conformità (AOC) di livello 1 valido che identifica chiaramente i componenti dell'applicazione e del sistema nell'ambito. Un AOC di autovalutazione non verrà accettato come prova di soddisfare le procedure consigliate per la sicurezza. L'AOC verrà usato per determinare quali controlli della specifica di certificazione di Microsoft 365 sono stati valutati e confermati nell'ambito della valutazione PCI DSS. |
| SOC 2 | Il report SOC 2 (Tipo II) deve essere corrente (emesso negli ultimi 15 mesi e il periodo di tempo dichiarato iniziato negli ultimi 27 mesi) da usare come prova di conformità con uno dei controlli di valutazione all'interno del framework di certificazione Microsoft 365. |
| FedRAMP | Il Federal Risk and Authorization Management Program (FedRAMP) è un programma a livello federale statunitense istituito nel 2011. Offre 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
Anche se gli standard o i framework di sicurezza esterni possono essere inviati come prova di supporto per soddisfare determinati controlli di certificazione Microsoft 365, per ottenere la certificazione Microsoft 365 è necessaria una valutazione separata. Il raggiungimento della certificazione Microsoft 365 non implica che l'app abbia superato completamente i controlli per questi framework esterni. La specifica di certificazione Microsoft 365 è incentrata su un subset specifico di controlli derivati da questi framework per offrire a Microsoft un livello di sicurezza più elevato per quanto riguarda il comportamento di sicurezza dell'app.
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 eventuali framework di conformità della sicurezza esterni supportati e devono essere indicati chiaramente nella documentazione fornita.
✓ I framework di conformità della sicurezza esterni supportati DEVONO essere correnti, ovvero entro gli ultimi 12 mesi (o entro 15 mesi se la rivalutazione è attualmente in corso e possono essere fornite prove).
✓ I framework di conformità della sicurezza esterni supportati DEVONO essere eseguiti da una società accreditata indipendente.