Panoramica del framework di certificazione microsoft 365

  • Articolo

Questo articolo fornisce informazioni dettagliate, tra cui l'elenco dei controlli di sicurezza della certificazione Microsoft 365 e il supporto per isv e sviluppatori sottoposti a certificazione Microsoft 365.

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 la possibilità di condividere gli attributi di conformità delle 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)

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. Esaminare i framework di controllo di conformità per verificare se l'app è idonea prima di iniziare la certificazione. Per qualsiasi domanda, 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 ISV rispondono a una serie di domande sulle procedure di sicurezza e gestione dei dati dell'app. Le app possono essere attestate dall'editore nel Centro per i partner Microsoft e ricevere filtri dedicati e non validi nel marketplace Microsoft AppSource al termine.

Esaminare i criteri di controllo Non è necessario 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. Alcuni controlli verranno considerati come "hard fail", il che significa che la mancanza di questi controlli di sicurezza comporterà una valutazione non riuscita.

Importante

Intervallo di tempo per l'invio: In media il processo di valutazione dovrebbe richiedere 30 giorni, a condizione che gli ISV siano in grado di controllare frequentemente lo stato dell'invio e rispondere ai commenti e alle richieste di prove supplementari in modo tempestivo. All'avvio del processo di certificazione, è consentito completare la valutazione per un massimo di 60 giorni. Se tutti gli invii non sono stati completati entro il periodo di tempo di 60 giorni, all'invio verrà generato un errore e il processo deve ricominciare. Questi risultati non saranno resi pubblici.

Ambito di certificazione

L'ambiente nell'ambito supporta il recapito del codice app/componente aggiuntivo e supporta tutti i sistemi back-end con cui l'app/componente aggiuntivo potrebbe comunicare. Tutti gli ambienti aggiuntivi connessi all'ambiente nell'ambito verranno inclusi anche nell'ambito, a meno che non sia presente una segmentazione adeguata E gli ambienti connessi a non possono influire sulla sicurezza dell'ambiente nell'ambito.

Eventuali ambienti di ripristino di emergenza separati dovranno anche essere inclusi nell'ambiente nell'ambito, in quanto questi ambienti sarebbero necessari per soddisfare il servizio nel caso in cui si verificasse qualcosa nell'ambiente primario. Gli ambienti di backup remoti dovranno essere inclusi anche perché questi ambienti possono archiviare i dati Microsoft e pertanto dovranno essere applicati controlli di sicurezza adeguati.

Il termine componenti di sistema nell'ambito fa riferimento a TUTTI i dispositivi e i sistemi usati nell'ambiente definito nell'ambito. I componenti nell'ambito includono, ma non sono limitati a:

  • Applicazioni Web
  • Server (fisici o virtuali che possono essere in locale o nel cloud)
  • Controlli di sicurezza di rete(NSC), ad esempio firewall
  • Interruttori
  • Servizi di bilanciamento del carico
  • Infrastruttura virtuale
  • Portali di gestione Web del provider di servizi cloud
  • Risorse cloud (Macchine virtuali, servizio app, account di archiviazione, istanze EC2 e così via)

Importante

I componenti di sistema esposti al pubblico sono soggetti ad attacchi da parte di attori esterni alle minacce e sono quindi a rischio molto maggiore. In genere, questi sistemi vengono segmentati lontano da altri componenti interni del sistema usando un controllo di sicurezza di rete (NSC) che crea una zona demilitarizzata (DMZ). L'intenzione è che la rete perimetrale sia meno attendibile rispetto alla rete interna e una maggiore sicurezza aiuterebbe a proteggere ulteriormente i sistemi interni e i dati qualora i sistemi pubblici dovessero essere compromessi. Idealmente si usa una rete perimetrale, ma questo non è fattibile o necessario in alcuni scenari di distribuzione.

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.

L'appendice C fornisce informazioni dettagliate sui controlli di sicurezza che probabilmente saranno applicabili in base ai tipi di distribuzione seguenti e in base al fatto che l'app esfiltra i dati di Microsoft 365:

  • ISV ospitato
  • IaaS ospitato
  • PaaS/Serverless ospitato
  • Ibrido ospitato
  • Shared Hosted

Quando viene distribuito IaaS o PaaS, devono essere fornite prove che convalidano l'allineamento dell'ambiente a questi tipi di distribuzione.

Campionamento

Le richieste di prove a supporto della valutazione della certificazione devono essere basate su un campione dei componenti del sistema nell'ambito in considerazione dei diversi sistemi operativi, della funzione primaria del dispositivo, dei diversi tipi di dispositivo (ad esempio server, NSC, router e così via) e della posizione. All'inizio del processo di certificazione verrà selezionato un campione appropriato. La tabella seguente deve essere usata come guida in cui il campionamento verrà determinato in base ai fattori descritti in precedenza:

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

Nota

Se vengono identificate discrepanze tra i dispositivi inclusi nel campione iniziale, le dimensioni del campione possono essere aumentate durante la valutazione.

Processo di certificazione end-to-end

Per iniziare la certificazione Microsoft 365:

  1. Passare al Centro per i partner e completare l'attestazione dell'editore. Se l'invio ha più di tre mesi, inviare di nuovo per la revisione e la convalida.

  2. Nel Centro per i partner selezionare "Avvia certificazione" per iniziare l'invio del documento iniziale. Ciò consentirà agli analisti di certificazione di determinare cosa è incluso nell'ambito della valutazione in base all'architettura dell'app e al modo in cui gestisce i dati Microsoft.

Consiglio

Seguire la guida pratica per istruzioni dettagliate per ottenere la certificazione dell'app Microsoft 365.

Il processo di certificazione viene eseguito in due fasi, come descritto di seguito:

L'invio iniziale di documenti consente all'analista di comprendere l'app, i flussi di dati, definire l'ambiente nell'ambito, identificare i controlli di sicurezza applicabili e determinare i componenti di sistema da cui devono essere raccolte le prove. L'ISV deve fornire le informazioni richieste per consentire all'analista della certificazione di completare questa fase del processo, ovvero circa il 5% del processo complessivo.

Full Evidence Review è il processo in cui l'ISV invia elementi di prova che illustrano come l'ambiente nell'ambito soddisfa i controlli di sicurezza. Durante questa fase di controllo verranno eseguite più interazioni tra l'ISV e l'analista, ovvero il resto del processo.

Valutazione

Dopo l'accettazione dell'invio iniziale del documento, il set di controlli di sicurezza verrà visualizzato automaticamente nel portale. Gli ISV devono fornire prove per ogni controllo che dimostri che il controllo è in atto e che hanno 60 giorni per inviare tutte le prove. Un analista esaminerà l'evidenza e approverà il controllo o richiederà prove nuove o aggiuntive.An analyst will review the evidence and either approve the control or request new or additional evidence.

Certificazione

Dopo che un invio è stato convalidato da un analista, gli ISV ricevono una notifica della decisione di certificazione. Le app con certificazione riceveranno un badge per l'applicazione all'interno di AppSource e pagine di documentazione Microsoft dedicate con report dettagliati degli attributi di sicurezza e conformità.

Rivedere e ricertificare

Le app con certificazione Microsoft 365 devono essere ricertificate su base annuale. Ciò richiederà la riconvalida dei controlli nell'ambito rispetto all'ambiente nell'ambito corrente. Questo processo può iniziare fino a 90 giorni prima della scadenza della certificazione. Le certificazioni esistenti non scadranno durante il periodo di ricertificazione. La ricertificazione in tutti i programmi scade in occasione dell'anniversario di un anno della certificazione Microsoft 365.

Se la certificazione non viene rinnovata prima della data di scadenza, lo stato di certificazione delle app verrà revocato. Tutti i tag, le icone e la personalizzazione della certificazione associata verranno rimossi dall'app e gli ISV non potranno pubblicare annunci per l'app come Microsoft 365 Certified.

Se un'applicazione subisce modifiche significative al di fuori dell'intervallo di tempo di invio della ricertificazione, agli ISV viene chiesto di notificare eventuali aggiornamenti al Programma di conformità delle app Microsoft.

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 della certificazione esamineranno le prove fornite per determinare se sono stati soddisfatti tutti i controlli per la certificazione Microsoft 365.

Per ridurre la quantità di tempo necessaria per completare la valutazione, è necessario fornire in anticipo una o tutta la documentazione dettagliata nell'invio iniziale della documentazione .

Gli analisti della certificazione esamineranno prima di tutto le prove fornite dall'invio della documentazione iniziale e le informazioni sull'attestazione dell'editore per identificare le linee di indagine appropriate, le dimensioni del campionamento e la necessità di ottenere ulteriori prove come descritto in precedenza. Gli analisti di certificazione analizzeranno tutte le informazioni raccolte per trarre conclusioni su come e se si soddisfano i controlli all'interno di questa specifica di certificazione di Microsoft 365.

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:

  1. Sicurezza delle applicazioni
  2. Sicurezza operativa/distribuzione sicura
  3. 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 elementi di questa specifica includono alcuni criteri di errore automatici:

  • Autorizzazioni API che non seguono il principio dei privilegi minimi (PoLP).
  • Nessun report di test di penetrazione quando è necessario.
  • Nessuna difesa antimalware.
  • L'autenticazione a più fattori non viene usata per proteggere l'accesso amministrativo.
  • Nessun processo di applicazione di patch.
  • Nessuna informativa sulla privacy gdpr appropriata.

Sicurezza delle applicazioni

Il dominio di sicurezza dell'applicazione è incentrato su tre aree:

  • Convalida delle autorizzazioni GraphAPI
  • Controlli di connettività esterni
  • Test di penetrazione

Convalida delle autorizzazioni GraphAPI

La convalida delle autorizzazioni GraphAPI viene eseguita per convalidare che l'app/componente aggiuntivo non richieda autorizzazioni eccessivamente permissive. Questa operazione viene eseguita controllando manualmente le autorizzazioni richieste. Gli analisti di certificazione faranno riferimento a questi controlli rispetto all'invio dell'attestazione del server di pubblicazione e valuteranno il livello di accesso richiesto per garantire che vengano soddisfatte le procedure con privilegi minimi. Se gli analisti di certificazione ritengono che queste procedure con privilegi minimi non siano soddisfatte, gli analisti di certificazione avranno una discussione aperta con l'ISV per convalidare la giustificazione aziendale per le autorizzazioni richieste. Eventuali discrepanze rispetto all'invio dell'attestazione del server di pubblicazione trovato durante questa revisione dovranno essere corrette.

Controlli di connettività esterni

Come parte della valutazione, verrà eseguita una leggera procedura dettagliata delle funzionalità delle applicazioni per identificare eventuali connessioni effettuate al di fuori di Microsoft 365. Tutte le connessioni non identificate come Microsoft o le connessioni dirette al servizio verranno contrassegnate e discusse durante la valutazione.

Test di penetrazione

Una revisione adeguata dei rischi associati all'app/componente aggiuntivo e all'ambiente di supporto è essenziale per garantire ai clienti la sicurezza dell'app/componente aggiuntivo. I test di sicurezza delle applicazioni sotto forma di test di penetrazione DEVONO essere eseguiti se l'applicazione ha connettività a qualsiasi servizio non pubblicato da Microsoft. Se una volta distribuita l'app funziona autonomamente accedendo solo al servizio Microsoft, ad esempio GraphAPI, non è necessario eseguire il test di penetrazione. Il test di penetrazione è ancora necessario se l'ambiente nell'ambito è ospitato in Azure.

Ambito dei test di penetrazione

Per i test di penetrazione dell'infrastruttura sia interni che esterni, tutte le attività di test di penetrazione DEVONO essere eseguite nell'ambiente di produzione live che supporta la distribuzione dell'app/componente aggiuntivo (ad esempio, in cui è ospitato il codice app/componente aggiuntivo che in genere sarà la risorsa all'interno del file manifesto) insieme a eventuali ambienti aggiuntivi che supportano il funzionamento dell'app/componente aggiuntivo (ad esempio, se l'app/componente aggiuntivo comunica con altre applicazioni Web esterne a Microsoft 365). Quando si definisce l'ambito per i test di penetrazione, è necessario prestare attenzione a garantire che tutti i sistemi o gli ambienti "connessi a" che possono influire sulla sicurezza dell'ambiente nell'ambito siano inclusi anche nelle attività di test di penetrazione DI TUTTI.

È consigliabile eseguire test di penetrazione delle applicazioni Web nell'ambiente di produzione live. Tuttavia, sarebbe accettabile eseguire test solo dell'applicazione Web usando un ambiente di test/UAT, purché sia confermato all'interno del report di test di penetrazione che la stessa codebase operava esattamente all'interno dell'ambiente di test/UAT al momento del test.

Quando le tecniche vengono usate per segmentare gli ambienti nell'ambito da altri ambienti, le attività di test di penetrazione DEVONO convalidare l'efficacia di tali tecniche di segmentazione. Questa operazione deve essere dettagliata all'interno del report di test di penetrazione.

Nota

I test di penetrazione interni devono essere eseguiti a meno che l'ambiente di hosting non sia classificato solo come PaaS.

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 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 si impegnano in test di penetrazione, i test di penetrazione possono essere condotti gratuitamente per la certificazione Microsoft 365. Microsoft organizzerà e coprirà il costo di un test di penetrazione per un massimo di 12 giorni di test manuali. I costi dei test di penetrazione vengono calcolati in base al numero di giorni necessari per testare l'ambiente nell'ambito. Tutte le spese che superano i 12 giorni di test saranno responsabilità dell'ISV.
  • Gli ISV dovranno presentare prove e ricevere l'approvazione per il 50% dei controlli nell'ambito prima che venga eseguito il test di penetrazione. Per iniziare, compilare l'invio iniziale del documento e scegliere di includere i test di penetrazione come parte della valutazione. Si verrà contattati per definire l'ambito e pianificare il test di penetrazione al termine del 50% dei controlli.
  • Il report emesso al termine del test della penna verrà fornito all'ISV dopo aver completato la certificazione. Questo report insieme alla certificazione Microsoft 365 può essere usato per mostrare ai potenziali clienti che l'ambiente è sicuro.
  • Gli ISV saranno anche responsabili di dimostrare che le vulnerabilità identificate nel test di penetrazione sono state risolte prima dell'assegnazione di una certificazione, ma non devono produrre un report pulito.

Una volta organizzato un test di penetrazione, l'ISV è responsabile delle tariffe associate alla riprogrammazione e all'annullamento come segue:

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 riprenotazione aziendale. 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 patchin linea con le organizzazioni definite per l'applicazione di patch 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 le correzioni delle vulnerabilità identificate durante l'analisi delle vulnerabilità vengono applicate 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

I dati in transito tra l'utente dell'applicazione, i servizi intermedi e i sistemi ISV devono essere protetti dalla crittografia tramite una connessione TLS che supporta almeno TLS v1.1. (È consigliabile usare TLS v1.2+). Vederel'appendice A.

Dove l'applicazione recupera e archivia i dati di Microsoft 365, sarà necessario implementare uno schema di crittografia dell'archiviazione dati che segue la specifica definita 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: dettagli oranizzazione (nome, indirizzo e altre informazioni personali identificabili), il tipo di dati personali trattati, per quanto tempo verranno conservati i 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 dei framework di conformità esterni facoltativi

Anche se non è obbligatorio, se attualmente si è in conformità con ISO 27001, PCI DSS, FedRAMP o SOC2, è possibile scegliere di usare queste certificazioni per soddisfare alcuni dei controlli di certificazione di Microsoft 365. Gli analisti tenteranno di allineare i framework di sicurezza esterni esistenti al framework di certificazione microsoft 365. Tuttavia, se la documentazione di supporto non è in grado di fornire la garanzia che i controlli di certificazione di Microsoft 365 siano stati valutati come parte del controllo/valutazione dei framework di sicurezza esterni, sarà necessario fornire prove aggiuntive dei controlli in vigore.

La documentazione deve dimostrare adeguatamente che l'ambiente nell'ambito per la certificazione Microsoft 365 è stato incluso nell'ambito di questi framework di sicurezza esterni. La convalida di questi framework di sicurezza verrà soddisfatta accettando prove di certificazioni valide condotte da società esterne di terze parti affidabili. Queste società affidabili devono essere membri di organismi di accreditamento internazionali per i programmi di conformità pertinenti. Vedere Standard di conformità e certificazione ISO per ISO 27001 e Valutatori di sicurezza qualificati (QSA) per PCI DSS.

La tabella seguente evidenzia i framework esterni e la documentazione richiesti dagli analisti di certificazione come parte di questo 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.

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.

Ulteriori informazioni