Appendice e glossario della documentazione sulla conformità delle app di Microsoft 365

Appendice A

Requisiti di configurazione del profilo TLS

Tutto il traffico di rete, all'interno di una rete virtuale, di un servizio cloud o di un data center, deve essere protetto con un minimo di TLS v1.1 (È consigliabile usare TLS v1.2+ ) o un altro protocollo applicabile. Le eccezioni a questo requisito sono:

• Reindirizzamento da HTTP a HTTPS. L'app può rispondere tramite HTTP per reindirizzare i client a HTTPS, ma la risposta non deve contenere dati sensibili (cookie, intestazioni, contenuto). Non sono consentite altre risposte HTTP oltre ai reindirizzamenti a HTTPS e alla risposta ai probe di integrità. Vedere di seguito.
• Probe di integrità. L'app può rispondere ai probe di integrità tramite HTTP solo se i probe di integrità HTTPS non sono supportati dall'entità di controllo.
• Accesso ai certificati. L'accesso agli endpoint CRL, OCSP e AIA ai fini della convalida del certificato e del controllo delle revoche è consentito tramite HTTP.
• Comunicazioni locali. L'app può usare HTTP (o altri protocolli non protetti) per le comunicazioni che non lasciano il sistema operativo, ad esempio la connessione a un endpoint server Web esposto in localhost.

La compressione TLS DEVE essere disabilitata.

Appendice B

Requisiti di configurazione del profilo di crittografia

Solo le primitive e i parametri di crittografia sono consentiti come indicato di seguito:

Crittografia simmetrica

Crittografia

 ✓ Sono consentiti solo AES, BitLocker, Blowfish o TDES. Sono consentite tutte le lunghezze >di chiave supportate =128 (128 bit, 192 bit e 256 bit) e possono essere usate (sono consigliate chiavi a 256 bit).

 ✓ È consentita solo la modalità CBC. Ogni operazione di crittografia deve usare un vettore di inizializzazione (IV) generato in modo casuale.

 ✓ L'uso di crittografie a flusso, ad esempio RC4, NON è consentito.

Funzioni hash

 ✓ Tutto il nuovo codice deve usare SHA-256, SHA-384 o SHA-512 (collettivamente noto come SHA-2). L'output può essere troncato a non meno di 128 bit

 ✓ SHA-1 può essere usato solo per motivi di compatibilità.

 ✓ L'uso di MD5, MD4, MD2 e altre funzioni hash NON è consentito, anche per applicazioni non crittografiche.

Autenticazione dei messaggi

 ✓ Tutto il nuovo codice DEVE usare HMAC con una delle funzioni hash approvate. L'output di HMAC può essere troncato a non meno di 128 bit.

 ✓ HMAC-SHA1 può essere usato solo per motivi di compatibilità.

 ✓ La chiave HMAC DEVE essere di almeno 128 bit. Sono consigliate chiavi a 256 bit.

Algoritmi asimmetrici

Crittografia

 ✓ RSA è consentito. La chiave DEVE essere di almeno 2048 bit e deve essere usata la spaziatura interna OAEP. L'uso della spaziatura interna PKCS è consentito solo per motivi di compatibilità.

Firme

 ✓ RSA è consentito. La chiave DEVE essere di almeno 2048 bit e deve essere usata la spaziatura interna PSS. L'uso della spaziatura interna PKCS è consentito solo per motivi di compatibilità.

 ✓ECDSA è consentito. La chiave DEVE essere di almeno 256 bit. È necessario usare la curva NIST P-256, P-384 o P-521.

Scambio di chiavi

 ✓ ECDH è consentito. La chiave DEVE essere di almeno 256 bit. È necessario usare la curva NIST P-256, P-384 o P-521.

 ✓ ECDH è consentito. La chiave DEVE essere di almeno 256 bit. È necessario usare la curva NIST P-256, P-384 o P-521.

Appendice C

Raccolta di prove - Delta per ISO 27001

Se è già stata raggiunta la conformità ISO27001, i seguenti delta (gap) non completamente coperti da ISO 27001 dovranno essere esaminati almeno nell'ambito della certificazione Microsoft 365.

Nota

Nell'ambito della valutazione della certificazione Microsoft 365, l'analista della certificazione determinerà se uno dei controlli ISO 27001 mappati non è stato incluso nell'ambito della valutazione ISO 27001 e può anche decidere di eseguire controlli di esempio che sono stati trovati da includere per fornire ulteriori garanzie. Eventuali requisiti mancanti nell'ISO 27001 dovranno essere inclusi nelle attività di valutazione della certificazione Microsoft 365.

Protezione da malware - Antivirus

Se la protezione da malware è in atto tramite il controllo dell'applicazione e viene attestata all'interno di ISO 27001 Report non è necessaria alcuna ulteriore indagine. Se non è presente alcun controllo delle applicazioni, gli analisti di certificazione dovranno identificare e valutare le prove dei meccanismi di controllo delle applicazioni per prevenire la detonazione del malware all'interno dell'ambiente. In questo modo sarà necessario:

• Dimostrare che il software antivirus è in esecuzione in tutti i componenti di sistema campionati.

• Dimostrare che l'antivirus è configurato in tutti i componenti del sistema campionati per bloccare automaticamente il malware, mettere in quarantena & avviso o per avvisare.

• Il software antivirus DEVE essere configurato per registrare tutte le attività.

Gestione delle patch - Applicazione di patch

Poiché gli audit ISO 27001 non valutano in modo specifico questa categoria, è necessario:

• I componenti software e i sistemi operativi non più supportati dal fornitore non DEVONO essere usati nell'ambiente. I criteri di supporto DEVONO essere applicati per garantire che i componenti software o i sistemi operativi non supportati vengano rimossi dall'ambiente e che sia necessario un processo per identificare quando i componenti software vanno alla fine del ciclo di vita

Analisi delle vulnerabilità

Poiché gli audit ISO 27001 non valutano in modo specifico questa categoria, è necessario:

• Dimostrare che viene eseguita l'analisi trimestrale delle vulnerabilità interna ed esterna.

• Verificare che la documentazione di supporto sia disponibile per la correzione delle vulnerabilità in base alla classificazione dei rischi e in linea con la specifica come indicato di seguito:

✓ Correggere tutti i problemi di rischio critici e elevati in linea con la classificazione dei rischi per l'analisi interna.

✓ Correggere tutti i problemi di rischio critico, elevato e medio in linea con la classificazione dei rischi per l'analisi esterna.

✓ Dimostrare che la correzione viene eseguita in linea con i criteri di correzione delle vulnerabilità documentati.

Firewall - Firewall (o tecnologie equivalenti)

Poiché gli audit ISO 27001 non valutano in modo specifico questa categoria, è necessario:

• Dimostrare che i firewall sono installati sul limite dell'ambiente nell'ambito.

• Dimostrare che i firewall sono installati tra la rete perimetrale e le reti attendibili.

• Dimostrare che tutti gli accessi pubblici terminano nella rete perimetrale.

• Dimostrare che le credenziali amministrative predefinite vengono modificate prima dell'installazione nell'ambiente attivo.

• Dimostrare che tutto il traffico consentito attraverso i firewall passa attraverso un processo di autorizzazione, che comporta la documentazione di tutto il traffico con una giustificazione aziendale.

• Dimostrare che tutti i firewall sono configurati per eliminare il traffico non definito in modo esplicito.

• Dimostrare che i firewall supportano solo la crittografia avanzata in tutte le interfacce amministrative non console.

• Dimostrare che le interfacce amministrative non console del firewall esposte a Internet supportano l'autenticazione a più fattori.

• Dimostrare che le verifiche delle regole del firewall vengono eseguite almeno ogni 6 mesi

Firewall - Web Application Firewall (WAF)

Verrà fornito un credito aggiuntivo se viene distribuito un WAF per proteggere dalla miriade di minacce e vulnerabilità delle applicazioni Web a cui l'applicazione può essere esposta. Quando è presente un WAF o simile, è necessario:

• Dimostrare che waf è configurato in modalità di difesa attiva o il monitoraggio più con avvisi.

• Dimostrare che waf è configurato per supportare l'offload SSL.

• È configurato in base al set di regole di base OWASP (3.0 o 3.1) per la protezione dalla maggior parte dei tipi di attacco seguenti:

✓ Problemi di protocollo e codifica.

✓ Intestazione injection, richiesta di contrabbando e divisione della risposta.

✓ Attacchi di attraversamento di file e percorsi.

✓ Attacchi rfi (Remote File Inclusion).

✓ Attacchi di esecuzione remota del codice.

✓ Attacchi php injection.

✓ Attacchi di scripting tra siti.

✓ Attacchi SQL injection.

✓ Attacchi di correzione della sessione.

Controllo delle modifiche

Poiché i controlli ISO 27001 non valutano in modo specifico alcuni elementi dei processi di richiesta di modifica, è necessario:

• Dimostrare che le richieste di modifica hanno i dettagli seguenti:

✓ Impatto documentato.

✓ Dettagli sui test di funzionalità da eseguire.

✓ Dettagli delle eventuali procedure di back-out.

• Dimostrare che il test delle funzionalità viene eseguito dopo il completamento delle modifiche.

• Dimostrare che le richieste di modifica vengono firmate dopo il test delle funzionalità.

Gestione account

Poiché i controlli ISO 27001 non valutano in modo specifico alcuni elementi dei processi di gestione degli account, è necessario:

• Dimostrare come ✓s vengono implementati per attenuare gli attacchi di riproduzione (ad esempio, MFA, Kerberos).
• Dimostrare in che modo gli account che non sono stati usati in 3 mesi vengono disabilitati o eliminati.
• ✓o altre mitigazioni appropriate devono essere configurate per proteggere le credenziali utente. I criteri password minimi seguenti devono essere usati come linee guida:

✓ Lunghezza minima della password di 8 caratteri.

✓ Soglia di blocco dell'account non superiore a 10 tentativi.

✓ Cronologia password di almeno cinque password.

✓ Imposizione dell'uso di password complesse.

• Dimostrare che L'autenticazione a più fattori è configurata per tutte le soluzioni di accesso remoto.

• Dimostrare che la crittografia avanzata è configurata in tutte le soluzioni di accesso remoto.

• Se la gestione di DNS pubblico non rientra nell'ambiente nell'ambito, tutti gli account utente in grado di apportare modifiche dns devono essere configurati per l'uso dell'autenticazione a più fattori.

Rilevamento e prevenzione delle intrusioni (FACOLTATIVO)

Poiché i controlli ISO 27001 non valutano in modo specifico alcuni elementi dei processi idps (Intrusion Detection and Prevention Services), è necessario:

• IDPS DEVE essere distribuito nel perimetro dell'ambiente di supporto.

• Le firme IDPS DEVONO essere mantenute aggiornate entro l'ultimo giorno.

• IDPS DEVE essere configurato per l'ispezione TLS.

• IDPS DEVE essere configurato per TUTTO il traffico in ingresso e in uscita.

• IDPS DEVE essere configurato per l'avviso.

Registrazione eventi

Poiché i controlli ISO 27001 non valutano in modo specifico alcuni elementi dei processi di registrazione degli eventi di sicurezza, è necessario:

• Dimostrare che i sistemi pubblici eseguono la registrazione in una soluzione di registrazione centralizzata che non si trova all'interno della rete perimetrale.

• Dimostrare come sia immediatamente disponibile un valore minimo di 30 giorni di dati di registrazione, con 90 giorni di conservazione.

Revisione (registrazione dei dati)

Poiché i controlli ISO 27001 non valutano in modo specifico alcuni elementi di questa categoria, è necessario:

• Dimostrare come vengono condotte le verifiche giornaliere dei log e come vengono identificate eccezioni e anomalie che mostrano come vengono gestite.

Avvisi

Poiché i controlli ISO 27001 non valutano in modo specifico alcuni elementi di questa categoria, è necessario:

• Dimostrare in che modo gli eventi di sicurezza sono configurati per attivare gli avvisi per la valutazione immediata.

• Dimostrare come il personale è disponibile 24 ore su 24, 7 giorni su 7, per rispondere agli avvisi di sicurezza.

Gestione dei rischi

Poiché gli audit ISO 27001 non valutano in modo specifico alcuni elementi dei processi di valutazione dei rischi, è necessario:

• Dimostrare che è stato stabilito un processo formale di gestione dei rischi.

Risposta agli eventi imprevisti

Poiché i controlli ISO 27001 non valutano in modo specifico alcuni elementi dei processi e dei criteri di risposta agli eventi imprevisti, è necessario:

• Dimostrare che il piano o la procedura di risposta agli eventi imprevisti include:

✓ Procedure di risposta specifiche per i modelli di minaccia previsti.

✓ Funzionalità di gestione degli eventi imprevisti allineate a NIST Cybersecurity Framework (Identificare, proteggere, rilevare, rispondere, recuperare).

✓ L'IRP copre i sistemi nell'ambito.

✓ Formazione annuale per il team di risposta agli eventi imprevisti.

Appendice D

Raccolta di prove - Delta per PCI DSS

Se hai già raggiunto la conformità PCI DSS, i seguenti differenziali (gap) non interamente coperti da PCI DSS dovranno, almeno, essere esaminati come parte della certificazione Microsoft 365.

Nota

Nell'ambito della valutazione della certificazione Microsoft 365, l'analista della certificazione determinerà se uno dei controlli PCI DSS mappati non è stato incluso nell'ambito della valutazione PCI DSS e può anche decidere di campionare i controlli che sono stati trovati da includere per fornire ulteriore garanzia. Eventuali requisiti mancanti nel PCI DSS dovranno essere inclusi nelle attività di valutazione della certificazione Microsoft 365.

Protezione da malware - Controllo delle applicazioni

Se la protezione da malware è in atto tramite l'uso di anti-virus ed è attestata all'interno del rapporto PCI DSS non è necessaria alcuna ulteriore indagine. Se non è presente alcun antivirus, gli analisti di certificazione dovranno identificare e valutare le prove dei meccanismi di controllo delle applicazioni per prevenire la detonazione del malware all'interno dell'ambiente. In questo modo sarà necessario:

• Dimostrare come viene eseguita l'approvazione dell'applicazione e verificare che sia stata completata.

• Dimostrare che esiste un elenco completo di applicazioni approvate con giustificazione aziendale.

• È disponibile una documentazione di supporto che illustra in dettaglio come il software di controllo dell'applicazione è configurato per soddisfare meccanismi di controllo dell'applicazione specifici, ad esempio l'elenco di autorizzazioni, la firma del codice e così via.

• Dimostrare che in tutti i componenti di sistema campionati il controllo dell'applicazione è configurato come documentato.

Gestione delle patch - Classificazione dei rischi

Poiché i controlli PCI DSS non valutano in modo specifico questa categoria, è necessario:

• Dimostrare come viene condotta la classificazione dei rischi delle vulnerabilità.

Analisi delle vulnerabilità

Poiché i controlli PCI DSS non valutano in modo specifico questa categoria, è necessario:

• Dimostrare che la correzione viene eseguita in linea con i criteri di correzione delle vulnerabilità documentati.

Firewall - Firewall (o tecnologie equivalenti)

Poiché i controlli PCI DSS non valutano in modo specifico questa categoria, è necessario:

• Dimostrare che i firewall supportano solo la crittografia avanzata in tutte le interfacce amministrative non console.

• Dimostrare che le interfacce amministrative non console del firewall esposte a Internet supportano l'autenticazione a più fattori.

Verrà fornito un credito aggiuntivo se un Web application firewall (WAF) viene distribuito per proteggere dalla miriade di minacce e vulnerabilità dell'applicazione Web a cui l'applicazione può essere esposta. Quando è presente un WAF o simile, è necessario:

• Dimostrare che waf è configurato in modalità di difesa attiva o il monitoraggio più con avvisi.

• Dimostrare che waf è configurato per supportare l'offload SSL.

• È configurato in base al set di regole di base OWASP (3.0 o 3.1) per la protezione dalla maggior parte dei tipi di attacco seguenti:

✓ Problemi di protocollo e codifica.

✓ Intestazione injection, richiesta di contrabbando e divisione della risposta.

✓ Attacchi di attraversamento di file e percorsi.

✓ Attacchi rfi (Remote File Inclusion).

✓ Attacchi di esecuzione remota del codice.

✓ Attacchi php injection.

✓ Attacchi di scripting tra siti.

✓ Attacchi SQL injection.

✓ Attacchi di correzione della sessione.

Controllo delle modifiche

Poiché i controlli PCI DSS non valutano in modo specifico alcuni elementi dei processi di richiesta di modifica, è necessario:

• Dimostrare che le richieste di modifica vengono generate prima di essere effettuate negli ambienti di produzione.

• Dimostrare che le modifiche sono autorizzate prima di passare all'ambiente di produzione.

• Dimostrare che il test delle funzionalità viene eseguito dopo il completamento delle modifiche.

• Dimostrare che le richieste di modifica vengono firmate dopo il test delle funzionalità.

Sviluppo/distribuzione di software sicuro

Poiché i controlli PCI DSS non accedono in modo specifico ad alcuni elementi di processi di sviluppo e distribuzione software sicuri, Questa operazione richiede:

• I repository di codice DEVONO essere protetti da MFA.

• Devono essere applicati controlli di accesso adeguati per proteggere i repository di codice da modifiche di codice dannose.

Gestione account

Poiché i controlli PCI DSS non valutano in modo specifico alcuni elementi dei processi di gestione degli account, è necessario:

• Illustrare come vengono implementati i meccanismi di autorizzazione per attenuare gli attacchi di riproduzione (ad esempio MFA, Kerberos).

• È necessario configurare criteri password complesse o altre mitigazioni appropriate per proteggere le credenziali utente. I criteri password minimi seguenti devono essere usati come linee guida:

✓ Lunghezza minima della password di 8 caratteri.

✓ Soglia di blocco dell'account non superiore a 10 tentativi.

✓ Cronologia password di almeno cinque password.

✓ Imposizione dell'uso di password complesse.

• Dimostrare che la crittografia avanzata è configurata in tutte le soluzioni di accesso remoto.

• Se la gestione di DNS pubblico non rientra nell'ambiente nell'ambito, tutti gli account utente in grado di apportare modifiche dns devono essere configurati per l'uso dell'autenticazione a più fattori.

Rilevamento e prevenzione delle intrusioni (FACOLTATIVO)

Poiché i controlli PCI DSS non valutano in modo specifico alcuni elementi dei processi idps (Intrusion Detection and Prevention Services), è necessario:

• IDPS DEVE essere configurato per l'ispezione TLS.

• IDPS DEVE essere configurato per TUTTO il traffico in ingresso e in uscita.

Gestione dei rischi

Poiché i controlli PCI DSS non valutano in modo specifico alcuni elementi dei processi di valutazione dei rischi, è necessario:

• Dimostrare che la valutazione del rischio include matrici di impatto e probabilità.

Risposta agli eventi imprevisti

Poiché i controlli PCI DSS non valutano in modo specifico alcuni elementi dei processi e dei criteri di risposta agli eventi imprevisti, lo sviluppatore dovrà:

• Illustrare le funzionalità di gestione degli eventi imprevisti allineate a NIST Cybersecurity Framework (Identificare, proteggere, rilevare, rispondere, ripristinare).

Appendice E

Raccolta di prove - Delta per SOC 2

Se hai già raggiunto la conformità SOC 2, i seguenti delta (gap) non completamente coperti da SOC 2 dovranno essere esaminati come parte della certificazione Microsoft 365.

Nota

Come parte della valutazione della certificazione Microsoft 365, l'analista della certificazione determinerà se uno dei controlli SOC 2 mappati non è stato incluso nell'ambito della valutazione SOC 2 e può anche decidere di campionare i controlli che sono stati trovati per essere inclusi per fornire ulteriore garanzia. Eventuali requisiti mancanti nella valutazione SOC 2 dovranno essere inclusi nell'ambito delle attività di valutazione della certificazione Microsoft 365.

Protezione da malware - Controllo delle applicazioni

Se la protezione da malware è in atto tramite l'uso di anti-virus ed è attestata all'interno del report SOC 2 non è necessaria alcuna ulteriore indagine. Se non è presente alcun antivirus, gli analisti di certificazione dovranno identificare e valutare le prove dei meccanismi di controllo delle applicazioni per prevenire la detonazione del malware all'interno dell'ambiente. In questo modo sarà necessario:

• È disponibile una documentazione di supporto che illustra in dettaglio come il software di controllo dell'applicazione è configurato per soddisfare meccanismi di controllo dell'applicazione specifici, ad esempio l'elenco di autorizzazioni, la firma del codice e così via.

• Dimostrare come viene eseguita l'approvazione dell'applicazione e verificare che sia stata completata.

• Dimostrare che esiste un elenco completo di applicazioni approvate con giustificazione aziendale.

• Dimostrare che in tutti i componenti di sistema campionati il controllo dell'applicazione è configurato come documentato.

Gestione delle patch - Applicazione di patch

Poiché i controlli SOC 2 non valutano in modo specifico questa categoria, è necessario:

• Qualsiasi problema basso, medio, alto o critico deve essere patchato all'interno delle normali finestre delle attività di applicazione di patch.

• I componenti software e i sistemi operativi non più supportati dal fornitore non DEVONO essere usati nell'ambiente. I criteri di supporto DEVONO essere applicati per garantire che i componenti software o i sistemi operativi non supportati vengano rimossi dall'ambiente e che sia necessario un processo per identificare quando i componenti software terminano il ciclo di vita.

Firewall - Firewall

Poiché i controlli SOC 2 non valutano in modo specifico i controlli delle modifiche negli elenchi di controllo di accesso del firewall, è necessario:

• Dimostrare che tutto il traffico consentito attraverso i firewall passa attraverso un processo di autorizzazione che comporta la documentazione di tutto il traffico con una giustificazione aziendale.

• Dimostrare che le verifiche delle regole del firewall vengono eseguite almeno ogni sei mesi.

Verrà fornito credito aggiuntivo se viene distribuito un Web application firewall (WAF) o simile per proteggere dalla miriade di minacce e vulnerabilità dell'applicazione Web a cui l'applicazione può essere esposta. Quando è presente un WAF o simile, è necessario:

• Dimostrare che waf è configurato in modalità di difesa attiva o il monitoraggio più con avvisi.

• Dimostrare che waf è configurato per supportare l'offload SSL.

• È configurato in base al set di regole di base OWASP ((3.0 o 3.1) per la protezione dalla maggior parte dei tipi di attacco seguenti:

 ✓ Problemi di protocollo e codifica.

 ✓ Intestazione injection, richiesta di contrabbando e divisione della risposta.

 ✓ Attacchi di attraversamento di file e percorsi.

 ✓ Attacchi rfi (Remote File Inclusion).

 ✓ Attacchi di esecuzione remota del codice.

 ✓ Attacchi php injection.

 ✓ Attacchi di scripting tra siti.

 ✓ Attacchi SQL injection.

 ✓ Attacchi di correzione della sessione.

Controllo delle modifiche

Poiché i controlli SOC 2 non valutano in modo specifico alcuni elementi dei processi di richiesta di modifica, lo sviluppatore dovrà:

• Dimostrare in che modo gli ambienti di sviluppo/test sono separati dall'ambiente di produzione che applica la separazione dei compiti.

• Dimostrare in che modo i dati in tempo reale non vengono usati negli ambienti di sviluppo/test.

• Dimostrare che il test delle funzionalità viene eseguito dopo il completamento delle modifiche.

• Dimostrare che le richieste di modifica vengono firmate dopo il test delle funzionalità.

Sviluppo/distribuzione di software sicuro

Poiché i controlli SOC 2 non accedono in modo specifico ad alcuni elementi dei processi di sviluppo e distribuzione software sicuri, Questa operazione richiede:

• È NECESSARIO disporre di un processo di sviluppo software stabilito e documentato che copre l'intero ciclo di vita dello sviluppo software.

• Gli sviluppatori DEVONO sottoporsi al training sicuro del codice software almeno ogni anno.

• I repository di codice DEVONO essere protetti da MFA.

• Devono essere applicati controlli di accesso adeguati per proteggere i repository di codice da modifiche di codice dannose.

Gestione account

Poiché i controlli SOC2 non valutano in modo specifico alcuni elementi dei processi di gestione degli account, è necessario:

• Illustrare come vengono implementati i meccanismi di autorizzazione per attenuare gli attacchi di riproduzione (ad esempio MFA, Kerberos).

• Dimostrare in che modo gli account che non sono stati usati in 3 mesi vengono disabilitati o eliminati.

• È necessario configurare criteri password complesse o altre mitigazioni appropriate per proteggere le credenziali utente. I criteri password minimi seguenti devono essere usati come linee guida:

 ✓ Lunghezza minima della password di 8 caratteri.

 ✓ Soglia di blocco dell'account non superiore a 10 tentativi.

 ✓ Cronologia password di almeno 5 password.

 ✓ Imposizione dell'uso di password complesse

• Dimostrare che gli account utente univoci vengono rilasciati a tutti gli utenti.

• Se la gestione di DNS pubblico non rientra nell'ambiente nell'ambito, tutti gli account utente in grado di apportare modifiche dns devono essere configurati per l'uso dell'autenticazione a più fattori.

Rilevamento e prevenzione delle intrusioni (FACOLTATIVO).

Poiché i controlli SOC 2 non valutano in modo specifico alcuni elementi dei processi idps (Intrusion Detection and Prevention Services), è necessario:

• Le firme IDPS DEVONO essere mantenute aggiornate, entro l'ultimo giorno

• IDPS DEVE essere configurato per l'ispezione TLS

• IDPS DEVE essere configurato per TUTTO il traffico in ingresso e in uscita

Registrazione eventi

Poiché i controlli SOC 2 non valutano in modo specifico alcuni elementi dei processi di registrazione degli eventi di sicurezza, è necessario:

• Dimostrare come, in tutti i componenti di sistema all'interno del set di esempio, il sistema seguente sia configurato per registrare gli eventi seguenti

 ✓ Accesso utente ai componenti di sistema e alle applicazioni.

 ✓ Tutte le azioni eseguite da un utente con privilegi elevati.

 ✓ Tentativi di accesso logico non validi.

Dimostrare che gli eventi registrati contengono; come minimo, le informazioni seguenti:

 ✓ Utente.

 ✓ Tipo di evento.

 ✓ Data e ora.

 ✓ Indicatore di esito positivo/negativo.

 ✓ Etichetta per identificare il sistema interessato.

• Dimostrare che tutti i componenti di sistema all'interno del set di esempi sono configurati per usare la sincronizzazione dell'ora e che sono uguali ai server ora primari/secondari.

• Dimostrare che i sistemi pubblici eseguono la registrazione in una soluzione di registrazione centralizzata che non si trova all'interno della rete perimetrale.

• Dimostrare che i sistemi pubblici eseguono la registrazione in una soluzione di registrazione centralizzata che non si trova all'interno della rete perimetrale.

• Dimostrare in che modo la soluzione di registrazione centralizzata è protetta da manomissioni non autorizzate dei dati di registrazione.

• Dimostrare come sia immediatamente disponibile un valore minimo di 30 giorni di dati di registrazione, con 90 giorni o più conservati.

Gestione dei rischi

Poiché i controlli SOC2 non valutano in modo specifico alcuni elementi dei processi di valutazione dei rischi, è necessario:

• Dimostrare che una valutazione formale del rischio viene condotta almeno ogni anno.

Risposta agli eventi imprevisti.

Poiché i controlli SOC2 non valutano in modo specifico alcuni elementi dei processi e dei criteri di risposta agli eventi imprevisti, è necessario:

• Dimostrare che il piano o la procedura di risposta agli eventi imprevisti include:

 ✓ Procedure di risposta specifiche per i modelli di minaccia previsti.

 ✓ Processo di comunicazione documentato per garantire una notifica tempestiva delle principali parti interessate (marchi/acquirenti di pagamenti, organismi di regolamentazione, autorità di vigilanza, amministratori, clienti e così via.

Appendice F

Hosting dei tipi di distribuzione

Microsoft riconosce che si distribuiranno applicazioni e si archivierà il codice app/componente aggiuntivo in ambienti di hosting diversi. Le responsabilità complessive di alcuni controlli di sicurezza all'interno della certificazione Microsoft 365 dipenderanno dall'ambiente di hosting usato. L'appendice F esamina i tipi di distribuzione comuni e ne esegue il mapping rispetto ai controlli di sicurezza valutati come parte del processo di valutazione. Sono stati identificati i tipi di distribuzione di hosting seguenti:

Tipi di hosting	Descrizione
ISV ospitato	I tipi ospitati ISV possono essere definiti come la posizione in cui si è responsabili dell'infrastruttura usata per supportare l'ambiente app/componente aggiuntivo. Può trovarsi fisicamente all'interno di data center o data center di terze parti con un servizio di co-localizzazione. In definitiva, si dispone della proprietà completa e del controllo amministrativo sull'infrastruttura di supporto e sull'ambiente operativo.
Infrastruttura distribuita come servizio (IaaS) (https://azure.microsoft.com/overview/what-is-iaas/)	L'infrastruttura distribuita come servizio è un servizio fornito in base al quale l'infrastruttura di supporto fisico viene gestita e gestita per loro conto dal provider di servizi cloud (CSP). In genere, la rete, l'archiviazione, i server fisici e l'infrastruttura di virtualizzazione sono tutte responsabilità del CSP. Il sistema operativo, il middleware, il runtime, i dati e le applicazioni sono responsabilità dell'utente. Anche le funzionalità di firewalling vengono gestite e gestite da terze parti, tuttavia la manutenzione della base di regole del firewall in genere rimane di responsabilità dei consumatori.
Piattaforma distribuita come servizio/Serverless (PaaS) (https://azure.microsoft.com/overview/what-is-paas/)	Con Platform as a Service viene effettuato il provisioning con una piattaforma gestita che presenta un servizio che può essere usato. Non è necessario eseguire funzioni sysadmin perché il sistema operativo e l'infrastruttura di supporto sono gestiti dal CSP. Questa operazione viene in genere usata quando le organizzazioni non vogliono presentare un servizio Web e possono invece concentrarsi sulla creazione del codice sorgente dell'applicazione Web e sulla pubblicazione dell'applicazione Web nei servizi Web gestiti dal cloud. Un altro esempio può essere un servizio di database in cui viene fornita la connettività a un database, ma l'infrastruttura di supporto e l'applicazione di database vengono astratte dal consumer. Nota: Serverless e PaaS sono simili, quindi ai fini della certificazione Microsoft 365 Hosting Deployment Type serverless e PasS sono considerati gli stessi
Ibrido ospitato	Con il tipo ospitato ibrido, è possibile usare più tipi ospitati per supportare varie parti dell'ambiente di supporto. Questo potrebbe essere più il caso in cui le app/componenti aggiuntivi vengono usate in più stack di Microsoft 365. Sebbene la certificazione Microsoft 365 supporti la distribuzione di app/componenti aggiuntivi in più servizi Microsoft 365, una valutazione dell'intero ambiente di supporto (tra app/componenti aggiuntivi) deve essere valutata in linea con ognuno dei "mapping dei tipi ospitati" applicabili. In alcuni casi, è possibile utilizzare tipi ospitati diversi per un singolo componente aggiuntivo, in cui questa operazione viene eseguita, l'applicabilità dei criteri dovrà comunque seguire i criteri "Mapping di tipi ospitati" tra i vari tipi ospitati.
Hosting condiviso	L'hosting condiviso è la posizione in cui si ospita l'ambiente all'interno di una piattaforma condivisa da più singoli consumer. La specifica di certificazione Microsoft 365 non è stata scritta per tenere conto di questo problema a causa dell'adozione del cloud, l'hosting condiviso non è comune. Se si ritiene che sia in uso, contattare Microsoft perché sarà necessario creare requisiti aggiuntivi per tenere conto dei rischi aggiuntivi in questo tipo di tipo di hosting.

Appendice G

Ulteriori informazioni

Panoramica del programma di conformità delle app di Microsoft 365Che cos'è l'attestazione di Microsoft 365 App Publisher?Che cos'è la certificazione Microsoft 365?

Glossario

AIA

*Authority Information Access è un descrittore di posizione del servizio usato per trovare il certificato dell'autorità di certificazione emittente.

CRL

*L'elenco di revoche di certificati consente a un endpoint SSL (Secure Sockets Layer) di verificare che un certificato ricevuto da un host remoto sia valido e attendibile.

Punteggio CVSS

*Common Vulnerability Scoring System è uno standard pubblicato che misura la vulnerabilità e calcola un punteggio numerico in base alla relativa gravità.

Linee guida per la gestione delle patch cvss

• Critico (9.0 - 10.0)
• Alto (7,0 - 8,9)
• Medio (4.0 - 6.9)
• Basso (0,0 - 3,9)

DMZ

*La zona demilitarizzata è una rete intermedia fisica o logica che interagisce direttamente con reti esterne o non proprietarie mantenendo la rete privata interna dell'host separata e isolata.

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.

EUII

Informazioni personali dell'utente finale.

GDPR

*Il regolamento generale sulla protezione dei dati è un regolamento sulla privacy e sulla protezione dei dati dell'Unione europea (UE) per tutti i dati dei cittadini dell'UE indipendentemente dalla posizione in cui si trova il sito dell'applicazione.

HSTS

*HTTP Strict Transport Security usa un'intestazione di risposta HTTP che indica al Web browser di accedere solo al contenuto tramite HTTPS. Questo è progettato per proteggere da attacchi di downgrade e cookie hijacking.

IEC

*International Electrotechnical Commission.

ISMI

*Sistema di gestione della sicurezza delle informazioni.

ISV

I fornitori indipendenti di sicurezza sono individui e organizzazioni che sviluppano, commercializzano e vendono software che viene eseguito su piattaforme software e hardware di terze parti.

ISO 27001

Un framework di specifica del sistema di gestione della sicurezza delle informazioni per tutti i controlli tecnici in un'organizzazione elabora criteri e procedure di gestione dei rischi.

LFI

L'inclusione di file locali consente a un utente malintenzionato di includere file in un server tramite il Web browser.

NIST

Il National Institute of Standards (NIST), un'agenzia non normativa del Dipartimento del Commercio degli Stati Uniti, fornisce indicazioni alle organizzazioni del settore privato negli Stati Uniti per valutare e approvare la loro capacità di prevenire, rilevare e rispondere agli attacchi informatici.

Modifiche non significative

• Correzioni di bug minori.
• Miglioramenti delle prestazioni minori.
• Sistemi operativi/librerie/patch dell'applicazione client e server.

OCSP

Online Certificate Status Protocol viene usato per controllare lo stato di revoca dei certificati digitali X.509.

OII

Informazioni identificabili sull'organizzazione.

OWASP

Aprire Progetto di sicurezza dell'applicazione Web.

PCI DSS

Payment Card Industry Data Security Standard, un'organizzazione che mantiene gli standard per la sicurezza dei dati dei titolari di carte in tutto il mondo.

Test della penna

Il test di penetrazione è un metodo per testare un'app Web simulando attacchi dannosi per individuare vulnerabilità di sicurezza che un utente malintenzionato potrebbe sfruttare.

SAML

Security Assertion Markup Language è uno standard aperto per lo scambio di dati di autenticazione e autorizzazione tra l'utente, il provider di identità e il provider di servizi.

Dati sensibili

• Dati di controllo di accesso.
• Contenuto del cliente.
• Informazioni sull'identità dell'utente finale.
• Dati di supporto.
• Dati personali pubblici.
• Informazioni pseudonime dell'utente finale.

Modifiche significative

• Rilocazione dell'ambiente di hosting.
• Aggiornamenti principali all'infrastruttura di supporto; ad esempio l'implementazione di un nuovo firewall, gli aggiornamenti principali ai servizi front-facing e così via.
• Aggiunta di funzionalità e /o estensioni all'app.
• Aggiornamenti all'app che acquisisce dati sensibili aggiuntivi.
• Modifiche ai flussi di dati o ai modelli di autorizzazione dell'app
• Aggiunta di endpoint API o funzioni dell'endpoint API.

SOC 2

Service Organization Control 2, una procedura di controllo tecnico costituita da cinque principi del servizio trust per garantire che i provider di servizi gestivano in modo sicuro i dati e la privacy per i client di un'organizzazione.

SSL

Secure Sockets Layer.

TLS

Transport Layer Security.