Data Security Requirements

Prepararsi a rispondere alle domande sulla sicurezza dei dati

Flussi di dati

Crea (o aggiorna, se necessario) un diagramma o una descrizione del flusso di dati che illustri in che modo l'app o il sistema tratta i Dati della Piattaforma.

1. Lato client: includi tutti i software client, come i browser, i dispositivi mobili e qualsiasi altro tipo di dispositivo supportato.
2. Lato server: includi tutti gli ambienti del server o del cloud correlati e identifica quanto segue.
1. I componenti in cui i Dati della Piattaforma:
1. Entrano o escono dall'ambiente del server (ad esempio, listener web e API REST)
2. Vengono scritti su memorie durevoli, come database, dischi o file di registro
2. Il modello di hosting, ad esempio:
1. Self hosted: server propri di un'organizzazione, in esecuzione in un data center di proprietà o condiviso.
2. Infrastruttura come servizio (IaaS): come AWS EC2, Microsoft Azure IaaS e Google Compute Engine.
3. Piattaforma come servizio (PaaS): come AWS Elastic Beanstalk, Google App Engine e Force.com.
4. Backend come servizio (BaaS): come AWS Amplify, Azure Mobile Apps, Firebase e MongoDB Switch.
5. Ibrido: una combinazione dei modelli precedenti.

Infine, il diagramma o la descrizione del flusso di dati deve includere:

1. Dove vengono generati e trasmessi/memorizzati/rinnovati i token d'accesso alle API di Meta, sia nel software client che in quello server (se applicabile al design del sistema)
2. In che modo recuperi i Dati della Piattaforma dalle API di Meta, con particolare riferimento a Informazioni personali (IIP) come il nome, l'indirizzo e-mail, il genere, la data di nascita e altri dati dell'utente
3. Come usi, memorizzi e trasmetti questi dati
4. Tutte le quarte parti a cui vengono inviati i Dati della Piattaforma

Preparazione delle prove

Potrebbe venirti richiesto di presentare prove a sostegno delle risposte relative alle protezioni della sicurezza dei dati che implementi. Ti consigliamo di leggere la Guida alle prove contenuta in questo documento per trovare esempi di prove accettabili e preparare le prove in modo adeguato. Accettiamo i più comuni tipi di file di documenti, oltre a screenshot e registrazioni dello schermo. Assicurati che i file non siano protetti da password. Puoi caricare più file, per un massimo di 2 GB ciascuno. Accettiamo file in formato .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip e .zipx.

Tipi di prove

Per le app a cui viene chiesto di caricare prove relative alle protezioni della sicurezza dei dati, Meta richiede due diversi tipi di documentazione:

1. Prove relative alla normativa o alla procedura: un documento relativo alla normativa o alla procedura che spieghi l'approccio alla sicurezza dei dati per [questa protezione]
2. Prove relative all'implementazione: prove ottenute dal sistema o dall'app, come la configurazione dello strumento o uno screenshot, che dimostrano in che modo hai implementato una determinata protezione

Prove relative alla normativa o alla procedura

Le prove relative alla normativa o alla procedura, talvolta definite come controllo amministrativo, sono documenti scritti che descrivono l'approccio utilizzato per una determinata protezione della sicurezza dei dati. Il tipo di prove può variare: può trattarsi dell'estratto di una serie di normative interne, di una parte o di tutta una pagina wiki interna oppure, se non disponi di una documentazione preesistente, di un documento creato ex novo che descriva l'approccio che utilizzi. In ogni caso, le prove relative alla normativa o alla procedura da te caricate devono illustrare chiaramente in che modo l'approccio a una determinata protezione si riferisce ai requisiti di Meta. Fornisci solo la normativa o i contenuti che sono pertinenti e necessari al controllo di sicurezza di Meta, oppure usa la casella di testo aperta associata alla domanda per indirizzare i nostri addetti al controllo verso le sezioni pertinenti.

Prove relative all'implementazione

Le prove relative all'implementazione illustrano nella pratica il modo in cui hai implementato la normativa o la procedura, direttamente attraverso uno screenshot o una registrazione dello schermo. I diversi sviluppatori presentano configurazioni diverse, pertanto non possiamo fornire esempi adatti a tutti gli scenari possibili. Premesso ciò, le prove relative all'implementazione devono essere dettagliate tanto quanto gli esempi che abbiamo fornito, nella misura del possibile.

Completezza delle prove

Comprendiamo che possa essere oltremodo impegnativo preparare prove relative all'implementazione che dimostrino in modo esaustivo l'implementazione di una determinata protezione della sicurezza dei dati. Pertanto, ti consigliamo di presentare le prove secondo le indicazioni qui riportate, avendo cura di oscurare le informazioni sensibili dalle prove prima di inviarle:

1. Le prove relative alla normativa o alla procedura devono chiaramente soddisfare o superare i requisiti di Meta
1. Meta controllerà le prove relative alla normativa o alla procedura per individuare le dichiarazioni in linea con i requisiti di Meta per una determinata protezione.
2. Aggiungi delle note al documento per mettere in evidenza le sezioni pertinenti.
3. Ad esempio, per quanto riguarda la protezione "Abilita la crittografia TLS 1.2" o successive, per tutte le connessioni di rete in cui vengono trasmessi i Dati della Piattaforma, una prova accettabile deve includere un documento che dichiari esplicitamente che:
1. I Dati della Piattaforma di Meta non devono mai essere trasmessi attraverso reti non attendibili in formato non crittografato
2. Tutti i listener web (ad esempio, i bilanciatori del carico rivolti a Internet) che ricevono o restituiscono i Dati della Piattaforma saranno configurati in modo da abilitare la crittografia TLS 1.2
3. Tutti i listener web che ricevono o restituiscono i Dati della Piattaforma saranno configurati in modo che i seguenti elementi siano disabilitati: SSL v2, SSL v3, TLS 1.0 e TLS 1.1
2. Le prove relative all'implementazione devono contenere uno o più esempi di implementazione di ciascuna normativa o procedura
1. Carica uno o più documenti, screenshot o configurazioni dello strumento che dimostrino in che modo hai implementato ciascuna protezione
2. Meta controllerà le prove relative all'implementazione per assicurarsi che siano in linea con le prove relative alla normativa o alla procedura
3. Ad esempio, per quanto riguarda la protezione Abilita la crittografia TLS 1.2 o successive, per tutte le connessioni di rete in cui vengono trasmessi i Dati della Piattaforma, una prova accettabile deve includere il report del test Qualys SSL relativo a uno dei domini web configurati in base alla normativa o alla procedura in questione.

Le informazioni sensibili da oscurare dalle prove

Non inviare prove che contengano uno qualsiasi di questi valori in forma leggibile (non oscurata). Se per uno screenshot usi un editor di immagini, sovrapponi un riquadro nero sul valore da rimuovere. Se usi un editor di PDF, anziché aggiungere semplicemente un elemento sopra il testo, assicurati di oscurarlo con uno strumento che rimuova i valori (ad esempio, lo strumento "Oscura" dell'app in anteprima di Apple).

• Dati sanitari
• Dati finanziari
• Indirizzi IP
• Password, credenziali e token d'accesso
• Chiavi di crittografia
• Indirizzi fisici
• Informazioni identificative personali (IIP) riguardanti un individuo (senza includere aziende o altre organizzazioni aziendali), dipendenti o altri affiliati che potrebbero identificare tale individuo direttamente o indirettamente, come ad esempio:

  • Nome
  • Indirizzi e-mail
  • ID utente
  • Date di nascita
  • Dati sulla posizione
  • Dati sanitari
  • Identità culturale, sociale e politica
  • Dati che potrebbero essere altrimenti identificabili con un individuo nel contesto specifico delle prove
• Passaggi di riproduzione dettagliati per le vulnerabilità (ad esempio, nel report di un test di penetrazione)
• Dati che gli sviluppatori conoscono o dovrebbero ragionevolmente conoscere e che provengono da o riguardano bambini di età inferiore ai 13 anni

Protezione dei Dati della piattaforma memorizzati lato server con crittografia a riposo

Domanda: Adotti la crittografia a riposo per tutti i Dati della piattaforma memorizzati in un ambiente cloud, server o data center?

Intenzione

La crittografia a riposo protegge i Dati della piattaforma rendendoli indecifrabili senza una chiave di decodifica separata. Ciò fornisce un ulteriore livello di protezione contro gli accessi di lettura non autorizzati.

• Nei server o negli ambienti cloud, dove tendono a concentrarsi i Dati della piattaforma correlati a tutti gli utenti di un'app, la crittografia a riposo riduce il rischio di violazione dei dati.
• Ad esempio, la crittografia a riposo offre protezione contro minacce come l'accesso non autorizzato al backup di un database, che potrebbe presentare misure di protezione meno rigide rispetto al database di produzione stesso.

Riepilogo dei requisiti

Se memorizzi i Dati della piattaforma lato server:

• DEVI proteggere questi Dati:

  • Con la crittografia a riposo
  • Con protezioni alternative accettabili (vedi Protezioni alternative accettabili)

• A seconda del tipo di crittografia utilizzata:

  • È accettabile la crittografia a livello dell'app (ad es. un software che crittografa o decodifica colonne specifiche in un database) o dell'intero disco.
  • Sebbene si consigli di usare crittografie standard del settore (ad es. AES, BitLocker, Blowfish, TDES, RSA), non imponiamo algoritmi o lunghezze di chiave specifici.

Se lo sviluppatore NON memorizza i Dati della piattaforma lato server, questo requisito non è applicabile.

Casi speciali

Archiviazione lato server tramite IaaS, self-hosting o hosting ibrido

Questa domanda è pertinente se memorizzi i Dati della piattaforma tramite hosting IaaS (ad es. AWS EC2, IaaS di Microsoft Azure o Google Compute Engine), self-hosting o un approccio ibrido.

Archiviazione lato server tramite prodotti SaaS, PaaS o BaaS

Tuttavia, esistono altri modelli di hosting back-end che costituiscono casi speciali:

Questa domanda non è pertinente se memorizzi i Dati della piattaforma solo tramite una di queste soluzioni (e non tramite IaaS, self-hosting o hosting ibrido). Dovrai invece illustrare questa relazione nella sezione Fornitori di servizi della Valutazione sulla protezione dei dati.

• BaaS: ad es. AWS Amplify, App mobili di Azure, PlayFab di Azure, Firebase di Google e MongoDB Switch
• PaaS: ad es. AWS Elastic Beanstalk, Google App Engine, Force.com
• SaaS: ad es. MailChimp o Salesforce

Archiviazione lato server tramite API di Meta

Se archivi i dati della Piattaforma solo tramite un'API di Meta, ad esempio usando player.setDataAsync(), nell'SDK per Giochi istantanei la domanda non si applica.

Guida alle prove

Se ti viene richiesto di inviare le prove relative a questa protezione, segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione.

Esempi di prove relative all'implementazione

AWS RDS

AWS RDS: la crittografia a riposo è configurabile in AWS RDS, quindi gli sviluppatori devono assicurarsi che l'opzione di configurazione sia impostata per applicare questa protezione.

Per un'istanza RDS rappresentativa che contiene i Dati della piattaforma, utilizza lo strumento AWS CLI per recuperare la relativa configurazione StorageEncrypted.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

In AWS DynamoDB viene applicata la crittografia a riposo come impostazione predefinita. Puoi recuperare la configurazione della crittografia a riposo per una tabella usando questi comandi.

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

AWS DocumentDB deve essere configurato per applicare la crittografia a riposo. Per un cluster rappresentativo che contiene i Dati della piattaforma, utilizza questi comandi per recuperare la configurazione StorageEncrypted.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

È possibile configurare i bucket di AWS S3 per applicare la crittografia a riposo a tutti gli oggetti creati all'interno del bucket. Utilizza questi comandi per elencare i bucket e recuperare la configurazione per la crittografia predefinita del bucket.

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

Consulta la documentazione di Microsoft sulla crittografia a riposo in Azure pertinente all'utilizzo dell'organizzazione dei relativi servizi.

Google Cloud Platform

Consulta la documentazione di Google sulla crittografia a riposo in Google Cloud Platform.

Protezioni alternative accettabili

Se non implementi la crittografia a riposo nell'ambiente lato server, puoi proteggere i Dati della piattaforma in un modo alternativo che sia comunque accettabile. In questo caso, è necessario descrivere quanto segue:

1. Riservatezza dei Dati della piattaforma: l'archiviazione di Dati della piattaforma specifici viene considerata di rischio più basso o più elevato. Dovrai cercare quali attributi utente specifici dei Dati della piattaforma sono memorizzati lato server.
2. Controlli applicati per ridurre la probabilità di pericoli specifici
1. Controlli per evitare di compromettere reti contenenti Dati della piattaforma
2. Controlli per evitare di compromettere app o sistemi che hanno accesso a Dati della piattaforma
3. Controlli per evitare di perdere supporti di archiviazione fisici (ad es. dispositivi di archiviazione di rete non più in uso) contenenti Dati della piattaforma
4. Controlli per evitare di perdere supporti di archiviazione fisici (ad es. dispositivi di archiviazione di rete non più in uso) contenenti Dati della piattaforma
5. Controlli per evitare l'accesso non autorizzato a copie di backup di archiviazioni contenenti backup di Dati della piattaforma
3. Forza dell'evidenza: assicurati di tenere presente se queste protezioni sono state valutate da un ispettore indipendente, ad esempio nell'ambito di un audit SOC2.

Proteggere dalla perdita i Dati della piattaforma memorizzati sui dispositivi e i supporti rimovibili dell'organizzazione

Domanda: In particolare per quanto riguarda i dati memorizzati sui dispositivi dell'organizzazione e su quelli personali: Adotti la crittografia a riposo o disponi di normative e regole per ridurre il rischio di perdita dei dati per tutti i Dati della piattaforma memorizzati su questi dispositivi?

Intenzione

Se uno sviluppatore consente l'utilizzo dei Dati della piattaforma su dispositivi come i computer portatili dei dipendenti o su dispositivi di memorizzazione rimovibili (ad esempio, le unità USB), tali dati sono ad alto rischio di accesso non autorizzato in caso di smarrimento o furto dei dispositivi. Gli sviluppatori devono adottare misure per limitare questo rischio.

Riepilogo dei requisiti

• Per ridurre il rischio di accesso non autorizzato ai Dati della piattaforma, gli sviluppatori devono disporre di controlli tecnici (preferibili) o amministrativi (non preferibili, ma accettabili) relativi ai Dati della piattaforma sui dispositivi (ad esempio, i computer portatili) e sui supporti rimovibili dell'organizzazione.

  • Controlli tecnici. Alcuni esempi di controllo tecnico includono: 1) permettere solo ai dispositivi gestiti di connettersi alla rete aziendale, 2) applicare la crittografia completa del disco sui dispositivi gestiti (ad esempio, BitLocker), 3) bloccare i supporti rimovibili (ad esempio, le unità USB) dalla connessione ai dispositivi gestiti, 4) utilizzare la tecnologia Data Loss Prevention (DLP) sui dispositivi gestiti.
  • Controlli amministrativi. Esempi di controlli amministrativi includono la documentazione scritta sulle normative e la formazione annuale sulle modalità accettabili di gestione dei Dati della piattaforma sui dispositivi dell'organizzazione e su quelli personali.

Guida alle prove

Se ti viene richiesto di inviare le prove relative a questa protezione, segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione.

Potresti usare uno o entrambi: a) controlli tecnici (ad esempio, la crittografia del disco) o b) regole/normative per ridurre il rischio di perdita dei Dati della piattaforma memorizzati su dispositivi dell'organizzazione come computer portatili e cellulari.

I controlli tecnici possono includere:

• Blocco della connessione dei dispositivi non gestiti ai servizi sensibili, come la rete di produzione
• Applicazione della crittografia del disco sui dispositivi gestiti (ad esempio, tramite BitLocker su Windows o FileVault su Mac)
• Blocco dell'utilizzo di supporti rimovibili (ad esempio, le unità USB) sui dispositivi gestiti
• Utilizzo del software DLP sui dispositivi gestiti per bloccare la gestione impropria dei Dati della piattaforma (ad esempio, l'invio di un allegato e-mail)

Le regole/normative possono includere:

• Una documentazione che descriva le soluzioni accettabili e non accettabili di gestione dei dati, in generale, e dei Dati della piattaforma in particolare
• Un meccanismo di informazione delle linee guida per i membri dell'organizzazione (ad esempio, un accordo contrattuale come condizione di assunzione, formazione, promemoria periodici via e-mail)

Esempio di prove

Un'organizzazione classifica i Dati della piattaforma di Meta come "dati privati" in base ai propri standard di classificazione dei dati. L'organizzazione ha creato delle Linee guida sulla gestione dei dati e tutto il personale è tenuto a comprenderle e a rispettarle.

Protezione dei Dati della Piattaforma trasmessi tramite reti con crittografia dei dati in transito

Domanda: Abiliti il protocollo di sicurezza TLS 1.2 o superiore per tutte le connessioni di rete che passano attraverso le reti pubbliche dove vengono trasmessi i Dati della piattaforma, si connettono a esse o le attraversano? Inoltre, ti assicuri che i Dati della piattaforma non vengano mai trasmessi su reti pubbliche in forma non crittografata (ad esempio, tramite HTTP o FTP) e che non vengano mai usati i protocolli di sicurezza SSL v2 e SSL v3?

Intenzione

I Dati della piattaforma trasmessi tramite Internet sono accessibili a chiunque sia in grado di osservare il traffico di rete. Pertanto, devono essere protetti mediante crittografia per evitarne la lettura da parte di tali soggetti non autorizzati.

• La crittografia in transito protegge i Dati della piattaforma durante la trasmissione lungo reti non affidabili (ad es., Internet) rendendoli decifrabili solo ai dispositivi di origine e destinazione.
• In questo modo, le parti intermedie della trasmissione non potranno leggere i Dati della piattaforma, anche se sono in grado di vedere il traffico di rete (il cosiddetto attacco man-in-the-middle).
• La crittografia in transito più diffusa è la TLS poiché si tratta della tecnologia che i browser usano per proteggere le comunicazioni verso i siti web, come le banche.

Riepilogo dei requisiti

Se elabori o meno i Dati della Piattaforma lato server:

• I Dati della Piattaforma di Meta non devono mai essere trasmessi attraverso reti non attendibili in formato non crittografato.
• Per tutti i listener web (ad esempio, i bilanciatori del carico rivolti a Internet) che ricevono o restituiscono i Dati della Piattaforma, devi:

  • Abilitare la crittografia TLS 1.2 o superiore.
  • Disabilitare la crittografia SSL v2 e SSL v3.
• TLS 1.0 e TLS 1.1 possono essere usati esclusivamente per la compatibilità con dispositivi client che non supportano TLS 1.2 o superiore.
• Meta consiglia, ma non richiede, che la crittografia in transito venga applicata alla trasmissione dei Dati della Piattaforma che rientrano completamente nelle reti private, ad esempio in un Virtual Private Cloud (VPC).

La tabella che segue riepiloga la normativa sulla crittografia in transito per diversi tipi di trasmissione.

Guida alle prove

Se ti viene richiesto di inviare le prove relative a questa protezione, segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione. Un modo semplice di produrre prove dell'implementazione che dimostrino la configurazione di uno dei listener web consiste nell'usare lo strumento Qualys SSL Server Test.

• Esegui lo strumento Qualys SSL Server Test su uno o più listener web configurati in modo identico (anche quelli eseguiti su porte non standard).
• Seleziona l'opzione "Do not show the results on the boards" (Non mostrare i risultati sulle bacheche) per impedire che i risultati vengano aggiunti al sito web di Qualys. Salva l'intera pagina dei risultati del test in PDF. Ripeti i passaggi precedenti per ogni listener web da o verso il quale trasmetti i Dati della Piattaforma con una configurazione TLS diversa.

Esempi di prove relative all'implementazione

Questo è un esempio di risultato dello strumento Qualys SSL Server Test. Leggi le annotazioni in rosso nella sezione Configurazione, che riepiloga quali versioni SSL/TLS sono supportate. Nota: questo esempio include solo le prime due pagine; tu devi includere l'intero risultato del test.

Protezioni alternative accettabili

Puoi proteggere i Dati della Piattaforma in transito con un tipo diverso di crittografia oltre a quella TLS; l'approccio può essere accettabile solo se garantisce la stessa protezione. In questo caso, devi inviare i dettagli della crittografia a Meta affinché possa controllarli:

• Crittografia simmetrica o asimmetrica?
• Algoritmo di crittografia (ad esempio, AES, BitLocker, TDES, RSA)?
• Qual è la lunghezza minima della chiave?

Testare app e sistemi in cerca di vulnerabilità e problemi di sicurezza

Domanda: Esegui test di app e sistemi in cerca di vulnerabilità e problemi di sicurezza almeno ogni 12 mesi? (Ad esempio, esegui un test di penetrazione manuale?)

Intenzione

Gli sviluppatori devono effettuare test in cerca di vulnerabilità e problemi di sicurezza così da individuarli in modo proattivo e, auspicabilmente, prevenire gli incidenti di sicurezza prima che si verifichino

• Sviluppatori di app che usano la piattaforma di Meta per elaborare i Dati della Piattaforma con il software che scrivono tramite app/sistemi che configurano e gestiscono
• Software e configurazioni di sistema potrebbero presentare vulnerabilità di sicurezza che utenti malintenzionati potrebbero sfruttare, con conseguenti accessi non autorizzati ai Dati della Piattaforma

Riepilogo dei requisiti

Si applica a tutti gli sviluppatori:

• È necessario aver verificato che il software usato per elaborare i Dati della Piattaforma non presenti vulnerabilità di sicurezza in uno dei modi seguenti:

  • Un test di penetrazione dell'app/sistema
  • Una scansione delle vulnerabilità/analisi statica del software
• I risultati del test devono indicare l'assenza di vulnerabilità critiche o di gravità elevata non risolte
• Il test deve essere stato completato negli ultimi 12 mesi

Requisiti aggiuntivi per gli sviluppatori che elaborano i Dati della Piattaforma lato server:

• È necessario aver testato in modo specifico il software lato server per verificare la presenza di vulnerabilità di sicurezza in uno dei modi seguenti:

  • Un test di penetrazione dell'app/sistema
  • Una scansione delle vulnerabilità/analisi statica. È necessario anche aver testato la configurazione del cloud per verificare la presenza di problemi di sicurezza se si utilizza un hosting provider cloud. Questo requisito si applica indipendentemente dal tipo di hosting (ad esempio BaaS, PaaS, IaaS, self hosted o ibrido)

Guida alle prove

Se ti viene richiesto di inviare le prove relative a questa protezione, segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione.

Se l'organizzazione tratta i Dati della Piattaforma in un ambiente cloud o server:

• Invia prove che dimostrino che un test di penetrazione o l'esecuzione di uno strumento SAST sono stati completati. Le prove devono contenere:

  • Una dichiarazione dell'ambito di applicazione del test
  • La data in cui il test è stato completato, che deve rientrare negli ultimi 12 mesi
  • Un riepilogo o un elenco delle vulnerabilità scoperte durante il test. Il riepilogo o l'elenco deve indicare anche in quale categoria si trova la vulnerabilità (ad esempio critica, alta, media, bassa, informativa). In genere ci aspettiamo che non ci siano vulnerabilità critiche o di gravità elevata non risolte.

• Se applicabile (cioè se usi un hosting cloud come AWS, GCP, Azure o simili), invia le prove che dimostrano che è stato effettuato un controllo della configurazione del cloud, ad esempio il risultato di un'esecuzione di NCC Scout Suite, AWS Config o simili. Se ciò non è applicabile all'organizzazione, quando invii le prove includi un documento che spieghi il motivo per cui il controllo della configurazione del cloud non è applicabile.
• Prima di inviare le prove, rimuovi o oscura le informazioni sensibili, come i passaggi dettagliati per la riproduzione delle vulnerabilità

Se l'organizzazione NON elabora i Dati della Piattaforma in un ambiente cloud o server:

• Invia prove che dimostrino che un test di penetrazione o l'esecuzione di uno strumento SAST sono stati completati. Le prove devono contenere:

  • Una dichiarazione dell'ambito di applicazione del test
  • La data in cui il test è stato completato, che deve rientrare negli ultimi 12 mesi
  • Un riepilogo o un elenco delle vulnerabilità scoperte durante il test. Il riepilogo o l'elenco deve indicare anche in quale categoria si trova la vulnerabilità (ad esempio critica, alta, media, bassa, informativa). In genere ci aspettiamo che non ci siano vulnerabilità critiche o di gravità elevata non risolte.
• Prima di inviare le prove, rimuovi o oscura le informazioni sensibili, come i passaggi dettagliati per la riproduzione delle vulnerabilità

Esempio di prove

Test di penetrazione: un'organizzazione commissiona un test di penetrazione del proprio software in esecuzione sul lato server che si integra con le API di Meta ed elabora i Dati della Piattaforma. La società di test completa il test e redige una lettera di riepilogo come quella riportata di seguito. Si prega di notare le annotazioni in rosso, che mettono in evidenza la data in cui è stato effettuato il test (che deve essere stato eseguito entro gli ultimi 12 mesi) e un riepilogo dei risultati critici/di elevata gravità non risolti al termine del test (o di un nuovo test, se applicabile). Prima di inviare il report, rimuovi o oscura le informazioni sensibili, in particolare i passaggi dettagliati per la riproduzione delle vulnerabilità.

Analisi statica: se usi un approccio diverso, ad esempio uno strumento SAST, esporta i risultati in un documento che includa la data di esecuzione del SAST e un elenco di risultati che includa il tipo di risultato e la sua gravità/criticità.

Controllo della configurazione del cloud

Uno sviluppatore ricorre a NCC Scout Suite usando l'insieme di regole predefinito per il proprio provider cloud (in questo caso, AWS) per esaminare la propria configurazione cloud alla ricerca di vulnerabilità e problemi di sicurezza. Lo strumento genera un file JSON contenente i risultati dettagliati dell'esecuzione. In questo esempio, diversi problemi sono stati contrassegnati con la gravità "Pericolo" e lo sviluppatore deve controllarli e risolverli.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

Un altro approccio al controllo della configurazione del cloud da parte degli sviluppatori usa l'insieme di regole di Amazon Web Services.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

Protezioni alternative accettabili

Se gestisci un programma di divulgazione delle vulnerabilità (VDP) funzionante, ad esempio usando le piattaforme BugCrowd o HackerOne, puoi presentarlo come protezione alternativa a un test di penetrazione o a una scansione delle vulnerabilità. Per dimostrarlo, devi inviare le prove che dimostrino che:

• Non ci sono esclusioni dall'ambito di applicazione del VDP in merito alle modalità di elaborazione dei Dati della Piattaforma
• Nel corso degli ultimi 12 mesi sono state effettuate ricerche e segnalazioni di vulnerabilità, in genere indicate da almeno 1 report di vulnerabilità valida al mese
• Alle vulnerabilità inviate (valide) viene assegnato un punteggio di gravità, ad esempio utilizzando il CVSS 3.1
• Le vulnerabilità vengono risolte in un tempo ragionevole, in genere meno di 90 giorni dopo la data di invio

In questo caso, le prove devono includere:

• Una dichiarazione dell'ambito di applicazione e il modo in cui questo si relaziona con il software utilizzato per elaborare i Dati della Piattaforma
• Un report delle vulnerabilità inviate nel programma negli ultimi 12 mesi Il report deve includere il titolo della vulnerabilità, la data di invio, la data di risoluzione (se risolta) e la categoria/punteggio di gravità.

Proteggere la chiave segreta e i token d'accesso dell'API di Meta

Domanda: I token d'accesso e le chiavi segrete dell'API di Meta sono protetti in entrambi i seguenti modi?

1. Non memorizzando mai i token di accesso dell'API di Meta sui dispositivi client in modo che siano accessibili al di fuori dell'app e dell'utente attuali.
2. Utilizzando una banca dati (ad es. Vault by Hashicorp) con un servizio di gestione delle chiavi (KMS) separato se i dati sono memorizzati in un ambiente cloud, server o data center.

Intenzione

Token d'accesso e chiavi segrete sono fondamentali per garantire la sicurezza con cui le API di Meta decidono quali azioni consentire. Se un soggetto non autorizzato ottiene l'accesso a queste credenziali, potrebbe chiamare le API di Meta, assumendo l'identità dello sviluppatore reale, ed effettuare azioni per cui abbiamo concesso l'autorizzazione all'app (ad es. lettura dei dati sugli utenti dell'app dalle API di Meta).

• Nell'ambito dell'uso della Piattaforma di Meta, hai accesso a credenziali sensibili. In particolare:

  • Token d'accesso: quando gli utenti concedono l'autorizzazione alle app, il software riceve delle credenziali, chiamate token d'accesso, utilizzate nelle successive chiamate API.
  • Chiavi segrete: Meta condivide le chiavi segrete con gli sviluppatori, aspettandosi che solo soggetti affidabili (ad es. amministratori delle app) all'interno delle organizzazioni vi abbiano accesso.
• I soggetti non autorizzati in grado di leggere queste credenziali sensibili possono usarle per chiamare le API di Meta al posto tuo (ciò viene a volte definito rappresentazione di token), con conseguente accesso non autorizzato ai Dati della piattaforma.
• Pertanto, queste credenziali devono essere protette da accessi non autorizzati per evitare i furti di identità.

Riepilogo dei requisiti

Token d'accesso

1. Nei dispositivi client, i token d'accesso di Meta non devono essere scritti in modo tale che altri utenti o processi possano leggerli.
2. Lati server. Se elabori o memorizzi i token di accesso di Meta lato server, tali token di accesso:
1. Devono essere protetti usando una banca dati (ad es. Vault di Hashicorp) con un servizio di gestione delle chiavi (KMS) separato e dove l'accesso alla chiave di decodifica è limitato all'app.
2. Non devono essere scritti nei file di registro

Per quanto riguarda le chiavi segrete, deve essere presente una delle due seguenti condizioni:

1. Non rivelare mai le chiavi segrete al di fuori degli ambienti server protetti (ad es. non vengono mai restituite da una chiamata di rete al browser o all'app mobile e le chiavi segrete non sono incorporate nel codice distribuito ai client mobili o nativi/desktop).
2. Devi aver configurato le app come di tipo native/desktop in modo che le API di Meta non ritengano più affidabili le chiamate API contenenti le chiavi segrete.

Guida alle prove

Se ti viene richiesto di inviare le prove relative a questa protezione, segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione.

Includi la documentazione sulla normativa per la protezione dei token d'accesso e delle chiavi segrete dell'API di Meta. Se l'app elabora i token di accesso Meta lato server, includi prove che dimostrino le protezioni adottate (ad es. l'uso di una banca dati, la dimostrazione che i valori sono memorizzati in un formato crittografato, la configurazione dell'app per richiedere la verifica della chiave segreta).

Esempio di prove

Un'organizzazione usa AWS Secrets Manager per memorizzare in modo sicuro i dati sensibili, comprese le chiavi segrete di Meta.

Un'organizzazione ha configurato la sua app di Meta per richiedere la verifica della chiave segreta per le chiamate API.

Protezioni alternative accettabili

1. Se non proteggi i token di accesso memorizzati sul lato server con una banca dati o con la crittografia a livello di app, esistono altre soluzioni:
1. Proteggi la chiave segreta usando una banca dati o la crittografia dell'applicazione in cui la chiave è accessibile esclusivamente all'app
2. Configura l'app per richiedere la verifica della chiave segreta per tutte le chiamate API a Meta
2. Se l'approccio numero 1 di cui sopra non è praticabile (ad es. non è possibile richiedere la verifica della chiave segreta perché bloccherebbe alcune chiamate API necessarie), Meta prenderà in considerazione qualsiasi altro tipo di controllo in atto per limitare il rischio di un uso non autorizzato dei token di accesso rispetto al rischio di un uso improprio dei token di accesso memorizzati.

Disporre di un piano di gestione degli incidenti e testare i sistemi e i processi di gestione degli incidenti

Domanda: esegui test di sistemi e processi da usare per rispondere a un incidente relativo alla sicurezza (ad esempio, una violazione dei dati o un attacco informatico) almeno ogni 12 mesi?

Intenzione

Prima o poi tutte le aziende subiscono un incidente di sicurezza, quindi è fondamentale che le organizzazioni abbiano previsto in anticipo le azioni da intraprendere per contenere gli incidenti, comunicare con gli stakeholder, riprendersi e imparare da quanto accaduto.

• In caso di incidente di sicurezza, disporre di un piano o di un manuale, nonché di un team di persone formate sulle azioni da intraprendere, può ridurre la portata dell'incidente e, in definitiva, limitare l'esposizione dei Dati della Piattaforma.
• Nonostante le organizzazioni presentino svariati livelli di efficienza nelle risposte agli incidenti, richiediamo almeno un piano di base che comprenda attività chiave (rilevare, reagire, riprendersi e controllare), con responsabilità e ruoli assegnati al personale.

Riepilogo dei requisiti

Gli sviluppatori devono possedere:

• Un piano di gestione degli incidenti che soddisfi i criteri minimi di Meta.
• Questo documento deve includere (almeno): (1) ruoli e responsabilità, (2) rilevamento, (3) passaggi di reazione in conformità agli obblighi legali applicabili (ad esempio, notifica della violazione dei dati alle autorità di controllo competenti e ai soggetti interessati) e ripresa, nonché (4) un processo di controllo successivo all'incidente.
• Prove documentate che dimostrino che il piano è stato testato di recente (negli ultimi 12 mesi) e che tutto il personale in esso indicato ha partecipato.

Guida alle prove

Segui le istruzioni riportate in Preparazione delle prove per preparare sia le prove relative alla normativa o alla procedura che quelle relative all'implementazione.

• Invia il piano di gestione degli incidenti (uno o più documenti). Deve contenere: ruoli e responsabilità, rilevamento, risposta e ripresa, nonché controllo successivo all'incidente.

  • Se non disponi di un piano di gestione degli incidenti, su Internet sono disponibili numerose risorse che possono esserti d'aiuto, come ad esempio il modello di piano di gestione degli incidenti di Counteractive e Ulteriori riferimenti e letture.
• Invia le prove che dimostrano che hai testato il piano negli ultimi 12 mesi. Le prove possono assumere forme diverse, ma devono includere:

  • La descrizione dello scenario (ad esempio, la simulazione di una situazione di emergenza in risposta a un attacco ransomware)
  • La data in cui si è svolto il test
  • Il ruolo di ciascun partecipante
  • Qualora uno dei membri del personale selezionato per la sezione ruoli e responsabilità del piano non abbia partecipato, il motivo di tale assenza
• Ti invitiamo a oscurare le informazioni sensibili (ad esempio IIP come il nome e l'indirizzo e-mail dell'individuo) da queste prove prima di inviare le prove di implementazione

Piano di gestione degli incidenti

Uno sviluppatore ha creato un piano di gestione degli incidenti completo basato su questo modello. Queste immagini descrivono solo l'indice del documento, ma di seguito è disponibile un link al modello completo.

Consulta il Modello completo del piano di gestione degli incidenti di Counteractive (formato docx)

Test di gestione degli incidenti

Uno sviluppatore ha condotto un test del proprio piano di gestione degli incidenti tramite la simulazione di una situazione di emergenza e ha documentato i risultati ottenuti sulla base di questo modello.

Richiedere l'autenticazione a più fattori per l'accesso remoto

Domanda: Richiedi l'autenticazione a più fattori per l'accesso remoto a ogni account in grado di connettersi all'ambiente cloud o server e/o per accedere ai servizi che usi per distribuire, mantenere, monitorare e gestire i sistemi in cui archivi i Dati della Piattaforma di Meta?

Intenzione

Una tecnica comune usata dagli utenti malintenzionati per ottenere l'accesso ai dati riservati prevede innanzitutto l'accesso agli strumenti usati dagli sviluppatori per creare o gestire le proprie app o i propri sistemi. Esistono strumenti avanzati per hackerare gli account protetti solo mediante password. L'autenticazione a più fattori offre un ulteriore livello di sicurezza contro questo rischio.

• Gli sviluppatori software usano diversi strumenti per creare, implementare e amministrare le proprie app o i propri sistemi.
• È prassi comune utilizzare questi strumenti da remoto su Internet (ad es., un dipendente che lavora da casa e invia una nuova funzione software o aggiorna la configurazione cloud).
• Gli strumenti protetti con autenticazione a un solo fattore (nome utente e password) sono particolarmente esposti agli attacchi di acquisizione dell'account. Ad esempio, gli utenti malintenzionati possono usare strumenti per provare combinazioni di nome utente e password ricavate da uno strumento per ottenere l'accesso a un altro strumento.
• L'autenticazione a più fattori offre protezione contro questi tipi di attacchi richiedendo un ulteriore fattore rispetto alla password al momento dell'accesso (ad es., un codice generato da un'app di autenticazione).

Riepilogo dei requisiti

In relazione al trattamento dei Dati della Piattaforma da parte di un'organizzazione, l'accesso remoto ai seguenti tipi di strumenti deve essere protetto mediante l'autenticazione a più fattori (non una semplice password):

• Strumenti usati per l'implementazione e la gestione di modifiche a codice/configurazione all'interno di app/sistemi
• Accesso amministrativo ad ambienti cloud o server, laddove applicabile

In particolare, l'autenticazione a più fattori o una protezione alternativa accettabile è richiesta per i seguenti casi:

• Strumenti di collaborazione/comunicazione, ad esempio e-mail aziendali o Slack
• Repository di codice, ad esempio GitHub o altri strumenti usati per tenere traccia di configurazioni/codice delle app/sistemi
• Se elabori i Dati della Piattaforma lato server:

  • Strumenti di implementazione software, ovvero strumenti usati per l'implementazione del codice in ambienti cloud/server (ad es., Jenkins o altri strumenti di integrazione continua/implementazione continua)
  • Strumenti amministrativi, ovvero portali o altri accessi usati per la gestione/il monitoraggio di ambienti server o cloud
  • Accesso remoto ai server, ovvero SSH, computer remoti o strumenti simili usati per l'accesso remoto a server in esecuzione lato server

Per quanto riguarda l'implementazione dell'autenticazione a più fattori:

• L'uso di un'app o di un hardware per l'autenticazione (ad esempio, YubiKey) è consigliato e preferibile ai codici inviati via SMS
• Le organizzazioni, tuttavia, possono usare qualsiasi implementazione dell'autenticazione a più fattori

Guida alle prove

Se ti viene richiesto di inviare le prove relative a questa protezione, segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione.

• Le prove relative all'implementazione devono dimostrare che l'autenticazione a più fattori viene applicata agli strumenti pertinenti all'ambiente sopra elencati (ad esempio, strumenti di collaborazione, repository di codice, distribuzione di cloud/server, portale amministrativo di cloud/server, accesso remoto di cloud/server)
• L'implementazione varia in base alla configurazione:

  • Ad esempio, se usi un provider SSO, può trattarsi dello screenshot di una configurazione globale per l'organizzazione o dello screenshot di una configurazione per app.
  • Se non disponi di un provider SSO, potrebbe trattarsi dello screenshot della configurazione di un particolare strumento.
• In ogni caso, sono necessarie prove che dimostrino che l'autenticazione a più fattori è abilitata per tutti gli utenti e non per un solo account.

Esempio di prove

AzureAD

Un'organizzazione usa AzureAD come soluzione di accesso singolo (SSO). Questa normativa esige un'autenticazione a più fattori.

La normativa viene quindi mappata sulle app cloud a cui si applica. Se si usa questo approccio, le prove devono mostrare tutta la sezione degli Elementi selezionati per chiarire quali applicazioni cloud richiedono l'autenticazione a più fattori.

Okta

Questa regola richiede l'autenticazione a più fattori per tutti gli accessi.

AWS IAM

Questo è l'esempio di una normativa AWS IAM che consente la configurazione dell'autenticazione a più fattori, ma che vieta altre azioni se l'autenticazione a più fattori non è presente.

GitHub

Un'organizzazione ha configurato l'autenticazione su GitHub in modo da richiedere l'autenticazione a più fattori per tutti i membri dell'organizzazione.

Protezioni alternative accettabili

• Per tutte le tipologie di accesso remoto presenti nell'organizzazione, ma per le quali non viene applicata l'autenticazione a più fattori, devi descrivere se usi uno o più di questi approcci per impedire l'acquisizione di account:

  • Requisiti per una password forte: ad esempio, un livello minimo di complessità della password, il divieto di usare parole del dizionario, il divieto di usare password che sono state oggetto di precedenti violazioni
  • Backoff di autenticazione: utilizzo di uno strumento che prevede periodi di attesa sempre più lunghi tra i tentativi di accesso falliti dalla stessa origine
  • Blocchi automatici: ad esempio, un meccanismo che blocca automaticamente l'accesso a un account dopo 10 tentativi di accesso falliti

Predisporre un sistema per la manutenzione degli account utente

Domanda: Hai predisposto un sistema per la manutenzione degli account (assegnazione, revoca, controllo di accessi e privilegi)?

Intenzione

Adottare buone pratiche di gestione degli account è fondamentale per evitare l'uso non autorizzato di account finalizzato ad accedere ai Dati della Piattaforma. In particolare, gli sviluppatori devono assicurarsi che l'accesso a risorse o sistemi venga revocato quando non più necessario.

• Gli account sono le unità di gestione di base per concedere alle persone l'accesso a sistemi, dati e funzioni amministrative.
• Agli account vengono concesse autorizzazioni che consentono azioni specifiche: una buona prassi è quella di concedere solo le autorizzazioni minime necessarie a un account (il cosiddetto principio del privilegio minimo).
• Quando una persona lascia un'organizzazione, è fondamentale che i suoi account utente vengano tempestivamente disabilitati per:

  • (1) prevenire gli accessi da parte di tale persona (l'ex dipendente);
  • (2) ridurre la probabilità che una persona non autorizzata possa usare l'account senza essere individuata. Ad esempio, gli utenti malintenzionati possono usare l'ingegneria sociale per indurre l'assistenza informatica a reimpostare la password di un account. Se l'account appartiene a un dipendente in servizio, è probabile che questi segnali l'impossibilità di effettuare l'accesso, mentre se l'account è ancora attivo ma appartiene a un ex dipendente, è facile che questo tipo di attacco passi inosservato.
• Per questo motivo, le organizzazioni devono dotarsi di un metodo sistematico per la gestione degli account, la concessione di autorizzazioni o privilegi e la revoca degli accessi non più necessari.

Riepilogo dei requisiti

• Devi disporre di uno strumento o un processo per la gestione degli account relativo a strumenti/sistemi/app:

  • usati per le comunicazioni interne (ad es. Slack o e-mail aziendali);
  • usati per l'invio di software (ad es. repository di codice);
  • usati per la gestione e amministrazione dei sistemi (se applicabile al trattamento dei Dati della Piattaforma).
• Devi controllare regolarmente (almeno una volta ogni 12 mesi) le concessioni degli accessi e disporre di un relativo processo di revoca qualora questi: (1) non siano più necessari; (2) non siano più in uso.
• Devi inoltre disporre di una procedura per revocare tempestivamente l'accesso a questi strumenti quando una persona lascia l'organizzazione.
• Meta non richiede:

  • che venga usato uno strumento specifico: lo sviluppatore può utilizzare un prodotto directory, come Google Cloud Identity o Microsoft Azure Active Directory, un prodotto cloud, come AWS Identity and Access Management (IAM), oppure un foglio di calcolo aggiornato regolarmente;
  • che ci sia un unico strumento consolidato per la gestione degli account per i diversi tipi di accesso.

Guida alle prove

Segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione.

• Normativa/procedura: fornisci normative documentate e documenti sulla procedura relativi alle pratiche di gestione degli account. Ci aspettiamo che questo documento contenga procedure per creazione di account, concessione di autorizzazioni, complessità minima delle password, normativa per il blocco degli account, normativa per l'autenticazione a più fattori, procedure di reimpostazione degli account e procedura per revocare l'accesso dopo un periodo di inattività o quando le persone abbandonano l'organizzazione (ad es. quando un dipendente rassegna le dimissioni o viene licenziato).
• Prove relative all'implementazione: fornisci prove su almeno uno dei seguenti strumenti o processi adottati per gestire gli account (o indica come non applicabile all'ambiente): (1) indirizzo e-mail aziendale e strumenti per la collaborazione, (2) repository di codice, (3) strumenti di distribuzione cloud/server, (4) portale di amministrazione cloud/server, (5) accesso remoto cloud/server (ad es. SSH o desktop remoto). Per lo strumento o il processo rappresentativo specifico, includi prove che dimostrino quanto segue:

  • È stato revocato l'accesso a questi strumenti delle persone che hanno lasciato l'organizzazione (ad es. un report relativo alla riconciliazione che confronta gli account utente e i dati autorevoli dei membri attuali dell'organizzazione).
  • Vengono revocati gli accessi che non sono utilizzati per un certo periodo di tempo (ad es. un report dove viene mostrato che l'ultima data di accesso di un titolare rappresentativo di account utente attivo rientra nei 90 giorni precedenti, se il periodo massimo di inattività è di 3 mesi).

Esempi di prove

Normativa/procedura: lo sviluppatore ha creato una gestione standard del ciclo di vita degli accessi che include procedure per concedere, controllare e revocare l'accesso.

Esempio di implementazione: viene revocato l'accesso per gli ex dipendenti

Lo sviluppatore utilizza Workday come origine autorevole per i dati delle risorse umane (HR), che comprendono la situazione lavorativa attuale. Questo sviluppatore usa Google Cloud Identity come identity provider (IdP) per gestire gli account utente e concedere l'accesso a sistemi e strumenti informativi.

Lo sviluppatore fornisce prove che l'accesso degli ex dipendenti è stato revocato mostrando che di recente è stato eseguito un report relativo alla riconciliazione (entro i 12 mesi precedenti). In questo report viene mostrato che non esistono account utente attivi in Google Cloud Identity assegnati a persone che non siano dipendenti attivi, in base a un report di Workday sui dipendenti attuali.

Esempio di implementazione: viene revocato l'accesso quando non è più utilizzato

Lo sviluppatore usa Google Cloud Identity come identity provider (IdP) per gestire gli account utente e concedere l'accesso a sistemi e strumenti informativi.

Lo sviluppatore fornisce prove che l'accesso viene revocato quando non è più utilizzato (ad es. nessun accesso nei 6 mesi precedenti). Fornisce dati sulla directory utente ordinati per ultimo accesso, per dimostrare che non sono presenti account utente attivi dove l'ultimo accesso è precedente al periodo stabilito.

Esempio di implementazione: GitHub (repository di codice)

Lo sviluppatore usa uno strumento di accesso singolo (SSO) per gestire le identità e concedere l'accesso a sistemi e strumenti informativi. Lo sviluppatore ha configurato GitHub per richiedere l'autenticazione SSO.

Mantenere i software aggiornati

Domanda: Hai predisposto un sistema per mantenere aggiornati ambienti e codici di sistema, tra cui server, macchine virtuali, distribuzioni, librerie, pacchetti e software antivirus?

Intenzione

I componenti software ricevono aggiornamenti o patch regolari per risolvere vulnerabilità di sicurezza. Questi componenti raggiungono la fine della loro vita quando non sono più supportati. Gli sviluppatori che integrano o si affidano a questi componenti devono mantenerli aggiornati per evitare l'esecuzione di software con vulnerabilità note.

• Gli sviluppatori di app si servono di svariati software di terzi per l'esecuzione di app/sistemi che trattano i Dati della Piattaforma.
• Ad esempio, gli sviluppatori usano tutti o alcuni tra i seguenti elementi:

  • Librerie, SDK, pacchetti: gli sviluppatori integrano questi elementi nel loro codice personalizzato per creare un'app.
  • Immagini di macchine virtuali, contenitori e sistemi operativi di app: le app vengono eseguite all'interno di uno o più contenitori, che forniscono servizi come la virtualizzazione e l'accesso a reti e archivi.
  • Browser, sistemi operativi e altre applicazioni utilizzati da dipendenti/collaboratori: software eseguiti su dispositivi mobili e computer portatili che gli sviluppatori usano per creare ed eseguire i propri sistemi.
• In questi componenti vengono regolarmente individuate vulnerabilità di sicurezza, con conseguente rilascio di patch.
• Le vulnerabilità risolte dalle patch vengono quindi divulgate in database pubblici con una valutazione della gravità (bassa, media, alta o critica).
• Pertanto, gli sviluppatori che usano la Piattaforma Meta devono dotarsi di un metodo sistematico di gestione delle patch:

  • identificando le patch pertinenti per le proprie app e i propri sistemi;
  • stabilendo le priorità delle urgenze in base all'esposizione;
  • applicando patch come attività aziendale continuativa.

Riepilogo dei requisiti

Per i seguenti componenti software, ove applicabile, devi dotarti di un metodo definito e ripetibile per identificare le patch disponibili in grado di risolvere le vulnerabilità di sicurezza, stabilire le priorità in base ai rischi e applicare le patch come attività continuativa:

1. Librerie, SDK, pacchetti, contenitori di app e sistemi operativi usati in ambienti server o cloud
2. Librerie, SDK, pacchetti utilizzati in dispositivi client (ad es. all'interno di app mobili)
3. Sistemi operativi e applicazioni usati dai membri per la creazione e la gestione di app e sistemi (ad es. sistemi operativi e browser in esecuzione sui computer portatili dei dipendenti)

Meta non richiede l'uso di uno strumento specifico per queste attività. È comune che un'organizzazione utilizzi diversi approcci per mantenere aggiornati diversi tipi di software (ad es. librerie integrate nell'app vs aggiornamenti dei sistemi operativi per i computer portatili dei dipendenti).

Il diagramma qui sotto illustra dove potrebbero essere richieste patch per diversi tipi di architettura.

Guida alle prove

Se ti viene richiesto di inviare le prove relative a questa protezione, segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione.

Inizia identificando i tipi di software interessati nell'ambiente, ad es. librerie, SDK, pacchetti, immagini di macchine virtuali, contenitori e sistemi operativi di app, browser, sistemi operativi e altre applicazioni usati da dipendenti/collaboratori.

Potresti avere uno o più strumenti che utilizzi per le seguenti attività:

• Inventario: attesta tramite uno screenshot o un altro documento la presenza di uno strumento o un processo che, sostanzialmente, rappresenta una lista di librerie, pacchetti, SDK, contenitori, server e sistemi operativi di app interessati per cui sono necessarie patch. Sono necessari inventari per un esempio di ogni tipo di software (ad es. app cloud, app client, dispositivi dei dipendenti).
• Identificare le patch software disponibili: dev'essere presente uno strumento o un processo per identificare le patch di sicurezza esistenti che sono pertinenti per l'inventario.
• Stabilire le priorità: dev'essere presente uno strumento o un processo (ad es. ticket di Jira, problemi di GitHub, foglio di calcolo di monitoraggio) in base a cui viene assegnata una priorità alle patch pertinenti.

  • Applicazione di patch
  • Dimostra tramite uno screenshot o un documento che, dopo aver identificato le patch pertinenti e stabilito la relativa priorità, queste vengono implementate nelle varie destinazioni.
• Includi normative su tempo per la risoluzione e uso di software End Of Life (EOL).

Esempi di prove

Snyk per un'app Node.js: lo sviluppatore utilizza l'interfaccia a riga di comando di Synk per identificare le dipendenze di terzi integrate che presentano vulnerabilità di sicurezza note e stabilisce le priorità in base alla gravità di queste ultime.

NPM Audit

Lo sviluppatore utilizza NPM Audit per trovare vulnerabilità nelle dipendenze usate in un'applicazione Node. L'immagine di esempio qui sotto mostra diverse vulnerabilità con gravità alta per cui sono necessarie patch.

Trivy

Lo sviluppatore usa Trivy per trovare vulnerabilità in un'immagine della macchina. L'immagine di esempio qui sotto mostra vulnerabilità con gravità alta nelle librerie incluse nell'immagine per cui sono necessarie patch.

Windows Server Update Services (WSUS)

Lo sviluppatore utilizza Windows Server Update Services (WSUS) per gestire la propria flotta di server e PC/computer portatili. L'immagine di esempio qui sotto mostra una vista amministratori dello strumento WSUS, che consente di controllare, approvare e distribuire gli aggiornamenti di Windows.

Disporre di un sistema di registrazione degli accessi e tracciare dove sono stati inviati e memorizzati i Dati della Piattaforma

Intenzione

Senza file di registro affidabili, può essere difficile o impossibile per uno sviluppatore rilevare un accesso non autorizzato ai Dati della Piattaforma.

• I registri di audit consentono a un'organizzazione di registrare il verificarsi di un evento, ad esempio qualora un determinato utente abbia inviato una query sulle tabelle del database contenenti i Dati della Piattaforma.
• Questi registri possono poi supportare processi come l'attivazione di avvisi automatizzati in base ad attività sospette o perizie forensi a seguito dell'identificazione di un problema relativo alla sicurezza.

Riepilogo dei requisiti

Se tratti i Dati della Piattaforma lato server, all'interno di quell'ambiente:

• Devi mantenere dei registri di audit che registrino gli eventi principali (ad esempio, l'accesso ai Dati della Piattaforma, l'uso di account con autorizzazioni elevate, le modifiche alla configurazione del registro di audit).
• I registri di audit devono essere consolidati in un archivio centrale e protetti dall'eventualità di alterazioni o eliminazioni.

Guida alle prove

Se ti viene chiesto di caricare delle prove, queste devono dimostrare che:

• Conosci le attuali modalità di archiviazione, accesso e trasferimento dei Dati della Piattaforma e puoi illustrarle, ad esempio, attraverso un diagramma del flusso di dati che mostri una panoramica generale del sistema, designi i servizi che memorizzano i Dati della Piattaforma e mostri i punti di ingresso e di uscita, compresi i trasferimenti previsti a qualsiasi servizio di quarte parti.
• Hai implementato registri di audit resistenti alle manomissioni.
• Gli eventi relativi all'accesso ai Dati della Piattaforma sono acquisiti nei registri.

Monitorare i trasferimenti dei Dati della Piattaforma e punti chiave in cui i Dati della Piattaforma possono lasciare il sistema (ad esempio, terzi, endpoint pubblici)

Intenzione

Per un'organizzazione è importante capire come ci si aspetta che i Dati della Piattaforma vengano trattati e poi monitorare l'effettivo trattamento, in modo da assicurarsi che i Dati della Piattaforma vengano utilizzati solo per gli scopi previsti

• Uno sviluppatore deve conoscere il modo attuale in cui i Dati della Piattaforma vengono archiviati, trasmessi attraverso le reti e scritti nei backup (che possono essere replicati altrove)
• Ad esempio, grazie al monitoraggio si possono individuare situazioni in cui i Dati della Piattaforma vengono trasmessi in modo imprevisto o se vengono trasmessi su una rete senza un'adeguata crittografia in transito, in modo da poter intervenire

Riepilogo dei requisiti

Se tratti i Dati della Piattaforma lato server, all'interno di quell'ambiente devi:

• Mantenere un diagramma accurato del flusso di dati che mostri dove i Dati della Piattaforma vengono archiviati, elaborati e trasmessi attraverso le reti
• Configurare il monitoraggio (ad esempio, i registri di audit con un prodotto di monitoraggio automatico) per i trasferimenti dei Dati della Piattaforma al di fuori del sistema
• Configurare, se possibile, il sistema di monitoraggio per lanciare avvisi che vengano controllati tempestivamente in caso di trasferimenti inaspettati di Dati della Piattaforma (vedi anche il requisito seguente: Disporre di un sistema automatizzato di monitoraggio dei registri e di altri eventi di sicurezza e generare avvisi per eventi anomali o legati alla sicurezza)

Guida alle prove

Se ti viene richiesto di inviare le prove relative a questa protezione, segui le istruzioni riportate in Preparazione delle prove sia per le prove relative alla normativa o alla procedura sia per quelle relative all'implementazione.

Ti invitiamo a fornire prove che dimostrino che:

• Conosci le attuali modalità di archiviazione, accesso e trasferimento dei Dati della Piattaforma e puoi illustrarle, ad esempio, attraverso un diagramma del flusso di dati che mostri una panoramica generale del sistema, designi i servizi che memorizzano i Dati della Piattaforma e mostri i punti di ingresso e di uscita, compresi i trasferimenti previsti a qualsiasi servizio di quarte parti.
• Sono stati implementati registri di audit resistenti alle manomissioni.
• Gli eventi relativi al trasferimento dei Dati della Piattaforma vengono acquisiti nei registri e devono includere l'ora, l'identità dell'utente o dell'app che compie l'azione, nonché l'origine e la destinazione.

Disporre di un sistema automatizzato per il monitoraggio dei registri e di altri eventi di sicurezza e generare avvisi per eventi anomali o legati alla sicurezza

Intenzione

Affidarsi al controllo umano per identificare un comportamento inaspettato in un sistema moderno accessibile via Internet non è realistico. Esistono invece strumenti in grado di inserire file di registro e altri segnali per lanciare allarmi che richiedono ulteriori indagini da parte del controllo umano.

Riepilogo dei requisiti

Se tratti i Dati della Piattaforma lato server, all'interno di quell'ambiente devi:

• Disporre di uno strumento in grado di inserire i file di registro e altri eventi, stabilire regole che lancino gli allarmi in caso di rilevamento e possedere un meccanismo che inoltri gli allarmi al controllo umano (ad esempio, un investigatore addetto alla sicurezza che è di turno)
• Inserire i segnali pertinenti nello strumento (ad esempio, i registri di accesso al web, i tentativi di autenticazione, le azioni intraprese dagli utenti con privilegi di alto livello)
• Nel corso del tempo, adattare e perfezionare le regole per mantenere un equilibrio tra segnale e rumore (ad esempio, evitando un numero eccessivo di falsi allarmi, ma evitando anche di ignorare gli eventi che meritano un'indagine)

Guida alle prove

A questo scopo, gli sviluppatori adottano comunemente uno strumento di Security Information and Event Management (SIEM), ad esempio:

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

Devi fornire le prove che dimostrano che le origini dei segnali pertinenti vengono inoltrate allo strumento di loro scelta, che sono stati configurati i trigger o gli allarmi, che gli allarmi sono inoltrati al personale responsabile del follow-up e, infine, che esiste un processo in base al quale gli allarmi vengono adattati periodicamente (ad esempio, tramite cicli di revisione e aggiornamento mensili).

Glossario

A

Terza parte: nella terminologia sulla gestione dei rischi, terza parte si riferisce agli sviluppatori nella Piattaforma Meta (l'aggettivo "proprietario/a/i/e" si riferisce a Meta; "seconda parte" si riferisce alle persone che usano i Prodotti di Meta).

Quarta parte: nella terminologia sulla gestione dei rischi, quarta parte si riferisce alle aziende a cui si affidano gli sviluppatori per fornire loro servizi a livello aziendale (l'aggettivo "proprietario/a/i/e" si riferisce a Meta, "seconda parte" agli utenti di Meta e "terza parte" agli sviluppatori nella Piattaforma Meta). Token d'accesso: una credenziale, ad esempio una password, che consente al software di chiamare un'API per eseguire una determinata azione (ad es. leggere dati dal profilo di un utente).

Amazon Web Services (AWS): la suite di Amazon per i servizi di cloud computing.

ID per singola app (ASID): un identificativo unico che Meta genera quando una persona sceglie di utilizzare un'app. Gli ASID aiutano a migliorare la privacy degli utenti rendendo più difficile correlare gli insiemi di dati agli utenti nelle app, dato che un utente singolo che usa 2 app possiede ASID diversi per ognuna di queste.

Chiave segreta: una chiave segreta condivisa che Meta mette a disposizione degli sviluppatori tramite la Dashboard gestione app. Possedere una chiave segreta autorizza i software a eseguire alcune azioni tramite l'API Graph, quindi gli sviluppatori devono assicurarsi che le parti non autorizzate non abbiano accesso alla chiave segreta.

Compromissione dell'app: se un utente malintenzionato riesce a ottenere l'accesso non autorizzato alla rete interna di un'organizzazione tramite una configurazione errata o una vulnerabilità nell'app (ad es. una vulnerabilità software in un'app web), si verifica una compromissione dell'app. Una possibile misura difensiva per la compromissione dell'app è un test di penetrazione dell'app stessa. Vedi anche Compromissione della rete.

Contenitore di applicazioni: un contenitore che crea pacchetti di codice software e dipendenze correlate in modo che un'app venga eseguita in diversi tipi di server (ad es. server che utilizzano diversi sistemi operativi come Linux o Windows Server). Lo sviluppatore crea un'immagine del contenitore che crea pacchetti della propria app. Un motore o un runtime del contenitore di applicazioni ospita (esegue) l'immagine del contenitore.

Crittografia dell'applicazione: un metodo per proteggere i dati in cui il software applicativo stesso esegue le operazioni di crittografia e decodifica. Al contrario, il protocollo Transport Layer Security (TLS) crittografa agevolmente i dati in transito quando un'applicazione stabilisce una connessione sicura con un server remoto (ad es. tramite HTTPS) e i provider di cloud offrono servizi per crittografare in modo trasparente i dati a riposo.

API (Interfaccia di programmazione dell'app): consente a 2 computer di comunicare tra loro su una rete, ad esempio un'app mobile che recupera il meteo di oggi per un determinato luogo da un sistema centralizzato di previsioni metereologiche.

Verifica della chiave segreta: un livello di sicurezza aggiuntivo per le chiamate API a Meta in cui uno sviluppatore genera un parametro (la verifica della chiave segreta) con cui dimostra che è in possesso della chiave segreta. La verifica della chiave segreta è il prodotto di una funzione hash (nota anche come funzione unidirezionale) basato sulla chiave segreta e il token d'accesso. Configurare un'app in modo che richieda la verifica della chiave segreta durante le chiamate all'API Graph riduce i potenziali danni da violazione dei token d'accesso dell'utente, dato che questi non possono essere usati senza la verifica della chiave segreta come parametro aggiuntivo.

B

BaaS (Backend as a Service): uno stile di cloud computing che fornisce una suite di funzionalità lato server per uno sviluppatore di app, in modo che questi possa concentrarsi sulla creazione del front-end (cioè la parte di un'app con cui interagiscono gli utenti). Le soluzioni BaaS sono simili a quelle PaaS e, per di più, aggiungono servizi come l'autenticazione dell'utente e le notifiche push mobili. Ecco alcuni tra i prodotti BaaS più popolari: AWS Amplify, app mobili di Azure, Firebase e MongoDB Switch

C

Testo crittografato: è un sinonimo di dati crittografati ed è il nome assegnato ai dati che vengono resi non leggibili tramite un algoritmo di crittografia. L'opposto del testo crittografato è il testo semplice.

Lato client: di solito le persone interagiscono con i servizi accessibili da Internet aprendo un sito web in un browser o eseguendo un'app mobile su telefono o tablet. Il browser o le app mobili vengono indicati come client locali o lato client. I client effettuano richieste da computer remoti (server) tramite Internet.

Cloud computing: si riferisce a uno stile di gestione per computer, reti e archivi server che permette a un'organizzazione di non preoccuparsi dell'ambiente fisico (ad es. un data center pieno di rack di server e cavi di rete). Al contrario, l'organizzazione può effettuare il provisioning di queste risorse on demand e pagare i servizi che utilizza.

Configurazione cloud: l'insieme di opzioni di cloud computing che un'organizzazione ha impostato in relazione al suo provider di servizi cloud che esegue alcuni software. Ecco alcuni esempi di configurazione cloud: quali tipi di connessioni di rete sono consentiti o bloccati, dove vengono scritti i file di registro e per quanto tempo vengono conservati e l'insieme di utenti autorizzati ad apportare modifiche alla configurazione cloud.

Controlli di compensazione: un controllo di sicurezza diverso da alcuni insiemi di requisiti di base, ma con lo scopo di offrire una protezione analoga per un determinato rischio.

D

Database: un software che consente di archiviare, leggere, aggiornare ed eliminare dati arbitrari. I database possono essere eseguiti in client e server. Le organizzazioni che si integrano con la Piattaforma Meta normalmente archiviano i dati che recuperano dall'API Graph all'interno di un database in esecuzione lato server.

Decodifica: processo in cui i dati crittografati vengono riportati al formato originale. In altre parole, la decodifica cambia il testo crittografato in testo semplice.

E

Crittografia: processo in cui i dati vengono trasformati in un formato utilizzabile solo dalle persone in grado di decodificarlo. In altre parole, la crittografia cambia il testo semplice in testo crittografato.

Crittografia a riposo: dati protetti con crittografia quando vengono scritti in un archivio permanente (ad es. un disco rigido). La crittografia a riposo fornisce un livello di protezione aggiuntivo per gli accessi non autorizzati, poiché un soggetto in grado di leggere i file non elaborati nel dispositivo di archiviazione vedrà il testo crittografato e non sarà in grado di decodificarlo, a meno che non riesca anche a ottenere l'accesso alla chiave di decodifica.

Crittografia in transito: dati protetti con crittografia quando vengono trasmessi in una rete. La crittografia in transito fornisce protezione da eavesdropping lungo il percorso di rete, poiché un soggetto in grado di leggere i pacchetti di rete vedrà il testo crittografato e non sarà in grado di decodificarlo, a meno che non riesca anche a ottenere l'accesso alla chiave di decodifica.

Software End Of Life (EOL): quando un'organizzazione sceglie di interrompere il supporto (ad es. creazione di patch per risolvere vulnerabilità di sicurezza) per un prodotto software, quel software viene considerato EOL. Dato che questi software non vengono più mantenuti, diventa molto rischioso eseguirli.

G

Google Cloud Platform (GCP): la suite di Google per i servizi di cloud computing. API Graph: il metodo principale tramite cui le app leggono e scrivono nel social graph di Meta. Tutti gli SDK e i Prodotti di Meta interagiscono in qualche modo con l'API Graph.

H

Funzione hash: una funzione di crittografia che considera qualsiasi dato come input e genera come output un codice breve che non può essere ripristinato all'input originale. In crittografia, le funzioni hash vengono usate per proteggere dati come le password: anziché memorizzare le password di un utente mediante testo semplice rischiando così il furto, queste vengono prima trasformate con una funzione hash e poi memorizzate. In seguito, per confermare che l'utente abbia inserito la password corretta, il sistema utilizza la stessa funzione hash per trasformare l'input e confrontare l'hash risultante con il valore memorizzato. Viene anche chiamata funzione unidirezionale, poiché l'hash di output non può essere ripristinato all'input originale.

Ambiente ospitato: si riferisce a un insieme di server, reti e dispositivi di archiviazione remoti che un'organizzazione esegue nel proprio data center o all'interno di un data center condiviso con altri clienti. Oggi questo metodo viene utilizzato relativamente poco, poiché il cloud computing è diventato più diffuso.

I

Identity Provider (IdP): un servizio cloud usato per centralizzare la gestione delle identità digitali e autenticare gli utenti. Le organizzazioni che si servono di un IdP di solito configurano le app cloud in modo che si basino sull'IdP stesso per l'autenticazione degli utenti. Le organizzazioni possono quindi gestire gli utenti creando app specifiche e concedendovi l'accesso e disabilitando gli account utente a livello centrale all'interno dell'IdP, anziché doverlo fare più volte per ogni app cloud.

Gestione delle identità e degli accessi: si riferisce alla categoria di strumenti e processi usati per gestire gli account e concedere l'accesso ai sistemi.

IaaS (Infrastructure as a Service): un approccio di cloud computing che permette ai clienti di configurare servizi di computing, archiviazione e rete senza essere responsabili delle risorse fisiche stesse (ad es. gestione di un data center pieno di server, dispositivi di rete e array di archiviazione). Rispetto all'approccio PaaS, quello IaaS offre all'organizzazione più controllo sulla configurazione delle proprie risorse cloud, ma al costo di una maggiore complessità di gestione delle risorse. Ecco alcuni tra i prodotti IaaS più popolari: Amazon EC2, Microsoft Azure IaaS e Google Compute Engine

L

Libreria: blocchi predefiniti di software preesistenti, di solito di un'azienda o di uno sviluppatore esterni, usati per gestire determinate attività all'interno di app o sistemi di un altro sviluppatore. Le librerie semplificano lo sviluppo di un'app, poiché lo sviluppatore non deve creare tutto da zero se esiste già una libreria per una determinata funzione. Tuttavia, le librerie possono contenere vulnerabilità di sicurezza, o possono includere librerie aggiuntive con vulnerabilità, quindi gli sviluppatori che le utilizzano come parte dell'app devono sapere quali librerie sono in uso e mantenerle aggiornate nel tempo.

M

Client mobile o app mobile: un'app che una persona installa sul proprio telefono o tablet da uno store di app mobili (ad es. App Store iOS o Google Play Store). Non è raro che i client mobili comunichino tramite Internet con l'API REST di un'organizzazione, e possono anche comunicare con altre parti (ad es. con l'API Graph tramite l'SDK di Facebook per Android).

Autenticazione a più fattori: un approccio di autenticazione che richiede più di un fattore per ottenere l'accesso a un'app o a un sistema. Questo approccio, al contrario dell'autenticazione a fattore singolo che si basa solo su una password per l'autenticazione dell'utente, di solito richiede anche uno o più dei seguenti elementi: un codice inviato tramite e-mail o SMS, il codice di un'app di autenticazione, una scansione biometrica o una chiave di sicurezza. Questa autenticazione protegge dalle intrusioni rendendo più difficile ai soggetti non autorizzati la forzatura di un account, ad es. tentando ripetutamente di accedere a un account tramite un indirizzo e-mail noto e password frequenti, finché il tentativo non va a buon fine.

N

Software nativo: le app che sono scaricate e installate su computer portatili o dispositivi mobili vengono dette software nativi (ad es. l'app Facebook per iOS). Al contrario, un'app che viene eseguita all'interno di un browser viene detta app web (ad es. aprire Facebook usando il browser Chrome).

Compromissione della rete: se un utente malintenzionato riesce a ottenere l'accesso non autorizzato alla rete interna di un'organizzazione tramite una configurazione errata o una vulnerabilità nella rete stessa, si verifica una compromissione della rete. Una possibile misura difensiva per la compromissione della rete è l'esecuzione di una scansione di rete per identificare configurazioni errate e vulnerabilità nella rete connessa a Internet. Vedi anche Compromissione dell'app.

Scansione di rete: un processo di gestione dei rischi che utilizza software per: (1) identificare i server attivi in una rete che rispondono a comunicazioni remote, quindi (2) scoprire se uno di questi server sta eseguendo versioni precedenti del software note per essere vulnerabili a uno o più attacchi alla sicurezza. Un'organizzazione può utilizzare periodicamente la scansione di rete per assicurarsi che non ci siano porte aperte impreviste nel perimetro di rete, ad esempio.

Node Package Manager (NPM): uno strumento usato dagli sviluppatori JavaScript per accelerare lo sviluppo, consentendo di includere pacchetti preimpostati in un'app o in un sistema. NPM include funzioni per controllare l'insieme di pacchetti utilizzati da un'app e identificare quelli con vulnerabilità di sicurezza note.

O

Bucket per l'archiviazione degli oggetti: un tipo di archivio permanente nel cloud che permette alle organizzazioni di memorizzare facilmente i file in archivi permanenti, compresi i file molto grandi, senza doversi preoccupare di adeguare le risorse fisiche (ad es. gli array di archiviazione) o di come eseguire il backup di questi file per garantire che non vengano persi in caso di disastro, ad esempio un incendio o un'inondazione.

Sistema operativo: il software in esecuzione su un computer o un dispositivo mobile che consente alle applicazioni di eseguire e usare le risorse di processore, memoria, archiviazione e rete di quel dispositivo, ad esempio Microsoft Windows, Apple macOS o iOS e Linux.

Membro dell'organizzazione: una persona con un ruolo e responsabilità all'interno di un'organizzazione, ad esempio un dipendente, un collaboratore esterno, un collaboratore occasionale, un tirocinante o un volontario.

Dispositivo dell'organizzazione: un computer o dispositivo mobile usato da un membro dell'organizzazione nel contesto di lavoro per l'organizzazione stessa.

P

Condizione della Piattaforma 6.a.i: si riferisce alla sezione (6), titolo (a), paragrafo (i) delle Condizioni della Piattaforma di Meta, che illustra gli obblighi degli sviluppatori della Piattaforma correlati alla sicurezza dei dati.

Pacchetto: un sinonimo di libreria.

Patch: aggiornamenti del software che risolvono vulnerabilità di sicurezza, correggono bug o aggiungono nuove funzionalità. Tutti i tipi di software ricevono patch, compresi sistemi operativi, contenitori, librerie e SDK.

Test di penetrazione: un attacco simulato a un'app o un sistema dove il tester tenta di trovare vulnerabilità nel codice o nella configurazione che potrebbero essere sfruttate da un soggetto non autorizzato. I tester di penetrazione si servono di strumenti simili a quelli dei criminali informatici per eseguire una ricognizione, cercare potenziali punti deboli e testare le vulnerabilità che potrebbero essere utilizzate per ottenere l'accesso non autorizzato. Al termine di un test di penetrazione, il tester crea un report che descrive i risultati, insieme alla gravità di ciascuno; l'organizzazione che esegue la manutenzione del software è responsabile di fornire correzioni che ne risolvano le vulnerabilità.

Testo semplice: è un sinonimo di dati non crittografati ed è il nome assegnato ai dati non protetti da crittografia. PaaS (Platform as a Service): un approccio di cloud computing con cui un cliente implementa un'applicazione in una piattaforma gestita dal provider di servizi cloud. Rispetto all'approccio IaaS, quello PaaS è più facile da gestire per i clienti, poiché l'host cloud gestisce sia le risorse fisiche (server, dispositivi di archiviazione e dispositivi di rete) sia il sistema operativo e il contenitore di applicazione dove viene eseguita l'app del cliente. Ecco alcuni tra i prodotti PaaS più popolari: AWS Elastic Beanstalk, Google App Engine, Force.com

Porta: quando un client effettua una connessione con un server tramite Internet, l'indirizzo di destinazione è composto da 2 parti: (1) un indirizzo IP (Protocollo Internet) per il server e (2) un numero di porta in quel server a cui risponde un'applicazione specifica. Normalmente i protocolli usano porte riservate (ad es. 443 per HTTPS), ma lo sviluppatore, se lo desidera, può servirsi di porte personalizzate per le comunicazioni di rete.

R

API REST: uno stile ampiamente adottato per creare servizi accessibili dal web dove il client e il server comunicano tramite protocollo HTTP. Uno sviluppatore nella Piattaforma Meta potrebbe ospitare un'API REST in un sottodominio come api.esempio.com a/da cui la propria app mobile invia e riceve i Dati della piattaforma.

S

Secure Shell (SSH): uno schema di comunicazione che consente agli amministratori di accedere da remoto ai server ed eseguire programmi negli stessi. Viene indicato come sicuro poiché le comunicazioni tra client e server sono protette da eavesdropping, a differenza dei protocolli precedenti come Telnet. È noto anche come Secure Socket Shell.

Secure Sockets Layer (SSL): una versione non sicura e obsoleta della crittografia in transito. La versione sicura più recente viene chiamata Transport Layer Security (TLS).

Server: un computer che fornisce servizi da remoto su una rete. I browser e le app mobili si connettono ai server tramite Internet.

Elaborazione serverless: uno stile di cloud computing dove l'host cloud gestisce l'infrastruttura fisica, il sistema operativo del server e il contenitore. Lo sviluppatore è responsabile solo del codice personalizzato e delle librerie associate, oltre che della configurazione cloud.

Lato server: i dati o l'elaborazione nel lato opposto a una connessione di rete (cioè in un server) vengono detti lato server. Al contrario, i dati o l'elaborazione in un dispositivo locale come un computer portatile o un dispositivo mobile vengono detti lato client.

Accesso singolo (SSO): una soluzione in cui le app si basano su una directory utente centralizzata (cioè un IdP) per autenticare gli utenti. Oltre a centralizzare l'amministrazione di account utente e accessi alle app per l'organizzazione, è vantaggiosa anche per gli utenti, poiché questi hanno un solo insieme di credenziali e non viene chiesto loro di mantenere credenziali diverse (ad es. nome utente e password) per ogni app.

SDK (Software Development Kit): un blocco predefinito di codice che uno sviluppatore può usare per semplificare il processo di sviluppo per una data necessità. Ad esempio, Meta crea e mantiene SDK che semplificano il lavoro con l'API Graph per gli sviluppatori iOS e Android. Come per le librerie, gli sviluppatori che utilizzano gli SDK nelle proprie app devono mantenerli aggiornati nel tempo.

SaaS (Software as a Service): consente ai clienti di usare app basate su cloud tramite Internet. A differenza di PaaS o IaaS, il cliente di un'app SaaS non implementa un codice personalizzato né è responsabile di configurazione, aggiornamento o patch dell'app, poiché sono tutte responsabilità del fornitore del software SaaS. Ecco alcuni tra i prodotti SaaS più popolari: Dopbox, MailChip, Salesforce, Slack

Analisi statica: vedi Test di sicurezza delle applicazioni statiche (SAST).

Test di sicurezza delle applicazioni statiche (SAST): un approccio per trovare le vulnerabilità in un software eseguendo uno strumento apposito nel codice di origine. Uno strumento SAST identifica le vulnerabilità potenziali, come quelle elencate nel progetto OWASP Top 10, e poi lo sviluppatore è responsabile di controllare i risultati, distinguere i veri positivi dai falsi positivi e correggere le vulnerabilità nel software. Uno strumento SAST può essere utile perché consente agli sviluppatori di trovare le vulnerabilità prima che vengano implementate in produzione, ma, a differenza di un test di penetrazione, non è in grado di trovare le vulnerabilità correlate alla configurazione di produzione dell'app.

T

Transparent Data Encryption: un tipo di crittografia a riposo applicata di solito all'archiviazione del database (cioè ai contenuti stessi del database e ai relativi file di registro). In questa soluzione, il software del database gestisce le chiavi di crittografia e organizza in modo trasparente le operazioni di crittografia (dopo le scritture) e quelle di decodifica (dopo le letture).

Transport Layer Security (TLS): uno schema di crittografia in transito che utilizza la crittografia per proteggere da eavesdropping i dati trasmessi tramite reti lungo il percorso di rete. TLS è la versione sicura più recente della tecnologia obsoleta precedente nota come SSL.

Autenticazione a due fattori (2FA): un sinonimo di autenticazione a più fattori. Vault: un sistema di gestione dei segreti per dati sensibili come chiavi di crittografia, token d'accesso e altre credenziali. Un vault permette di controllare rigorosamente chi è in grado di accedere ai segreti che contiene e offre servizi aggiuntivi come la conservazione dei registri di controllo.

V

Macchina virtuale: è molto simile a un contenitore di applicazioni; tuttavia, una macchina virtuale viene eseguita in un host detto hypervisor, mentre un contenitore di applicazioni viene eseguito nel motore di un contenitore. La differenza principale è che un'immagine di macchina virtuale contiene un sistema operativo, al contrario di un contenitore di applicazioni. Sia le macchine virtuali sia i contenitori di applicazioni includono applicazioni e dipendenze come le librerie.

Virtual Private Cloud (VPC): un termine usato da AWS per riferirsi a un insieme di risorse cloud simile a una rete tradizionale in un data center nell'era pre-cloud.

Vulnerabilità: un difetto in un sistema o in un'app che può essere sfruttato, ad es. per leggere dati che un determinato soggetto altrimenti non sarebbe autorizzato a leggere.

Programma di divulgazione delle vulnerabilità (VDP): un approccio con cui le organizzazioni richiedono report sulle vulnerabilità di sicurezza a ricercatori (detti anche hacker etici), in modo da scoprire le vulnerabilità e correggerle prima che gli utenti malintenzionati le sfruttino. Un VDP efficace richiede un insieme di ricercatori che cerchino attivamente le vulnerabilità, analisti all'interno dell'organizzazione che controllino le informazioni in arrivo e assegnino loro una priorità e tecnici esperti di sicurezza informatica in grado di creare e implementare correzioni per le vulnerabilità.

Analisi delle vulnerabilità: un approccio che utilizza un software per cercare vulnerabilità in server, reti e app. Rispetto a un test di penetrazione, l'analisi delle vulnerabilità è più economica e, di conseguenza, può essere eseguita ripetutamente (ad es. ogni mese o trimestre), ma di solito un test di penetrazione rileva vulnerabilità che l'analisi delle vulnerabilità non riesce a trovare. Questo perché i tester di penetrazione esperti sono dotati di competenze analitiche e istintive difficili da replicare con approcci esclusivamente automatizzati. Vedi anche Scansione di rete.

W

App web: le app web sono programmi eseguiti nei browser e comprendono risorse come documenti HTML, codice JavaScript, video e altri contenuti multimediali e CSS per la definizione dello stile. Al contrario di un'app mobile, che le persone installano su un cellulare da uno store di app, le app web vengono semplicemente recuperate da un server remoto tramite il browser (ad es. www.facebook.com), senza bisogno di un passaggio di installazione.