Usare solo crittografie a blocchi simmetriche e lunghezze di chiave approvate
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
I prodotti devono usare solo le crittografie a blocchi simmetriche e le lunghezze di chiave associate esplicitamente approvate dal consulente per la crittografia dell'organizzazione. Gli algoritmi simmetrici approvati da Microsoft includono le crittografie a blocchi seguenti:
Per il codice nuovo, sono accettabili AES-128, AES-192 e AES-256.
Per la compatibilità con le versioni precedenti del codice esistente, è accettabile 3DES a tre chiavi.
Per i prodotti che usano le crittografie a blocchi simmetriche:
Per il codice nuovo, è necessario Advanced Encryption Standard (AES).
Triple Data Encryption Standard (3DES) a tre chiavi è consentito nel codice esistente per la compatibilità con le versioni precedenti.
Tutte le altre crittografie a blocchi, incluse RC2, DES, 3DES a 2 chiavi, DESX e Skipjack, possono essere usate solo per decrittografare i dati precedenti e devono essere sostituite se usate per la crittografia.
Per gli algoritmi di crittografia a blocchi simmetrici, è necessaria una lunghezza minima della chiave di 128 bit. L'unico algoritmo di crittografia a blocchi consigliato per il codice nuovo è AES (AES-128, AES-192 e AES-256 sono tutti accettabili)
3DES a tre chiavi è attualmente accettabile se è già in uso nel codice esistente. È consigliata la transizione ad AES. DES, DESX, RC2 e Skipjack non sono più considerati sicuri. Questi algoritmi possono essere usati solo per decrittografare i dati esistenti ai fini della compatibilità con le versioni precedenti e i dati devono essere crittografati di nuovo con una crittografia a blocchi consigliata.
Si noti che tutte le crittografie a blocchi simmetriche devono essere usate con una modalità di crittografia approvata, che richiede l'uso di un vettore di inizializzazione appropriato. Un vettore di inizializzazione appropriato è in genere un numero casuale, mai un valore costante.
L'uso di algoritmi di crittografia legacy o comunque non approvati e di lunghezze di chiavi inferiori per la lettura dei dati esistenti (contrariamente alla scrittura di nuovi dati) può essere consentito dopo la revisione da parte del team di crittografia dell'organizzazione. È tuttavia necessario prevedere un'eccezione per questo requisito. Nelle distribuzioni aziendali inoltre si deve considerare per i prodotti la possibilità di avvisare gli amministratori quando viene usata una crittografia debole per leggere i dati. Tali avvisi devono essere descrittivi e operativi. In alcuni casi, può essere appropriato che i Criteri di gruppo controllino l'uso della crittografia debole.
Algoritmi .NET consentiti per la flessibilità crittografica gestita (in ordine di preferenza):
AesCng (conforme allo standard FIPS)
AuthenticatedAesCng (conforme allo standard FIPS)
AESCryptoServiceProvider (conforme allo standard FIPS)
AESManaged (non conforme allo standard FIPS)
Si noti che nessuno di questi algoritmi può essere specificato tramite i metodi SymmetricAlgorithm.Create o CryptoConfig.CreateFromName senza apportare modifiche al file machine.config. Si noti inoltre che AES nelle versioni di .NET prima di .NET 3.5 è denominato RijndaelManagede sono >disponibili tramite CodePlex e AesCngAuthenticatedAesCng richiedono CNG nel sistema operativo sottostante
Usare modalità di crittografia a blocchi approvate e vettori di inizializzazione per crittografie simmetriche
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
Tutte le crittografie a blocchi simmetriche devono essere usate con una modalità di crittografia a blocchi approvata. Le sole modalità approvate sono CBC e CTS. In particolare, è consigliabile evitare la modalità operativa ECB (Electronic Code Book). Per usare ECB, è necessaria la revisione da parte del team di crittografia dell'organizzazione. Ogni utilizzo di OFB, CFB, CTR, CCM e GCM o di altre modalità di crittografia deve essere esaminato dal team di crittografia dell'organizzazione. Con il riutilizzo dello stesso vettore di inizializzazione con crittografie a blocchi nelle "modalità di crittografia di flusso", ad esempio CTR, i dati crittografati potrebbero essere rivelati. Tutte le crittografie a blocchi simmetriche devono anche essere usate con un vettore di inizializzazione appropriato. Un vettore di inizializzazione appropriato è un numero casuale con una crittografia complessa, mai un valore costante.
Usare riempimenti, lunghezze di chiave e algoritmi asimmetrici approvati
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
L'uso di algoritmi di crittografia vietati costituisce un grave rischio per la sicurezza dei prodotti e deve essere evitato. I prodotti devono usare solo gli algoritmi di crittografia e le lunghezze di chiave e i riempimenti associati esplicitamente approvati dal team di crittografia dell'organizzazione.
RSA: può essere usato per la crittografia, lo scambio di chiave e la firma. La crittografia RSA deve usare solo le modalità di riempimento OAEP o RSA-KEM. Il codice esistente può usare la modalità di riempimento PKCS #1 v1.5 solo per la compatibilità. L'uso del riempimento null è esplicitamente vietato. Le chiavi >= 2048 bit sono necessarie per il nuovo codice. Il codice esistente può supportare chiavi < a 2048 bit solo per la compatibilità con le versioni precedenti dopo una revisione da parte della Crypto Board dell'organizzazione. Le chiavi < a 1024 bit possono essere usate solo per decrittografare/verificare i dati precedenti e devono essere sostituiti se usati per operazioni di crittografia o firma
ECDSA: può essere usato solo per la firma. ECDSA con >chiavi =256 bit è necessario per il nuovo codice. Le firme basate su ECDSA devono usare una delle tre curve approvate da NIST (P-256, P-384 o P521). Le curve che sono state analizzate a fondo possono essere usate solo dopo una revisione da parte del team di crittografia dell'organizzazione.
ECDH: può essere usato solo per lo scambio di chiave. ECDH con >chiavi =256 bit è necessario per il nuovo codice. Lo scambio di chiave basato su ECDH deve usare una delle tre curve approvate da NIST (P-256, P-384 o P521). Le curve che sono state analizzate a fondo possono essere usate solo dopo una revisione da parte del team di crittografia dell'organizzazione.
DSA: può essere accettabile dopo la revisione e l'approvazione da parte del team di crittografia dell'organizzazione. Contattare il consulente per la sicurezza per pianificare una revisione da parte del team di crittografia dell'organizzazione. Se l'uso di DSA è approvato, tenere presente che sarà necessario impedire l'uso di chiavi con una lunghezza inferiore a 2048 bit. CNG supporta chiavi di lunghezza pari e superiore a 2048 bit a partire da Windows 8.
Diffie-Hellman: può essere usato solo per la gestione delle chiavi della sessione. La lunghezza della chiave >= 2048 bit è necessaria per il nuovo codice. Il codice esistente può supportare lunghezze < di chiave a 2048 bit solo per la compatibilità con le versioni precedenti dopo una revisione da parte della Crypto Board dell'organizzazione. Non è possibile usare chiavi < a 1024 bit.
Usare generatori di numeri casuali approvati
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
I prodotti devono usare generatori di numeri casuali approvati. Le funzioni pseudocasuali, ad esempio la funzione runtime C rand, la classe .NET Framework System.Random o le funzioni di sistema come GetTickCount, non devono quindi mai essere usate in tale codice. L'uso dell'algoritmo DUAL_EC_DRBG (Dual Elliptic Curve Deterministic Random Bit Generator) è proibito.
CNG: BCryptGenRandom. È consigliato l'uso del flag BCRYPT_USE_SYSTEM_PREFERRED_RNG a meno che il chiamante non possa essere eseguito con un IRQL maggiore di 0, ovvero PASSIVE_LEVEL.
CAPI: cryptGenRandom.
Win32/64: RtlGenRandom (le nuove implementazioni devono usare BCryptGenRandom o CryptGenRandom) * rand_s * SystemPrng (per la modalità kernel)
.NET: RNGCryptoServiceProvider o RNGCng.
Applicazioni Windows Store: Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom o .GenerateRandomNumber.
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *byte )
Apple OS X (<10.7) - Usare /dev/random per recuperare numeri casuali
Java(compreso il codice Java di Google per Android) - classe java.security.SecureRandom. Tenere presente che, per Android 4.3 (Jelly Bean), gli sviluppatori devono seguire la soluzione alternativa consigliata da Android e aggiornare le applicazioni per inizializzare il generatore PRNG con l'entropia da /dev/urandom o /dev/random.
Non usare crittografie di flusso simmetriche
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
Non devono essere usate crittografie di flusso simmetriche, ad esempio RC4. Invece delle crittografie di flusso simmetriche, i prodotti devono usare una crittografia a blocchi, in particolare AES con una lunghezza di chiave di almeno 128 bit.
Usare algoritmi MAC/HMAC/hash con chiave
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
I prodotti devono usare solo algoritmi MAC (Message Authentication Code) o HMAC (Hash Message Authentication Code) approvati.
Un codice MAC è un'informazione allegata a un messaggio che consente ai destinatari di verificare sia l'autenticità del mittente che l'integrità del messaggio con una chiave privata. L'uso di codice MAC basato su hash (HMAC) o di codice MAC basato sulla crittografia a blocchi è consentito purché anche tutti gli algoritmi di crittografia simmetrica o hash sottostanti siano approvati per l'uso. Attualmente sono inclusi i codici MAC basati sulla crittografia a blocchi CMAC/OMAC1 e OMAC2 (basati su AES) e le funzioni HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 e HMAC-SHA512).
L'uso di HMAC-SHA1 può essere consentito per la compatibilità con la piattaforma, ma sarà necessario prevedere un'eccezione a questa procedura e superare la revisione del team di crittografia dell'organizzazione. Non è consentito il troncamento dei codici HMAC a meno di 128 bit. L'uso dei metodi dei clienti per l'hash di una chiave e dei dati non è approvato e deve superare la revisione del team di crittografia dell'organizzazione prima di poter essere adottato.
Usare solo funzioni hash crittografiche approvate
Titolo
Dettagli
Componente
Applicazione Web
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
I prodotti devono usare la famiglia SHA-2 di algoritmi (SHA256, SHA384 e SHA512). Se è necessario un hash più breve, ad esempio una lunghezza di output di 128 bit, per la corrispondenza con una struttura di dati progettata per il più breve hash MD5, i team dei prodotti possono troncare uno degli hash SHA-2 (in genere, SHA256). Si noti che SHA384 è una versione troncata di SHA512. Il troncamento di hash crittografici per motivi di sicurezza a meno di 128 bit non è consentito. Il codice nuovo non deve usare gli algoritmi hash MD2, MD4, MD5, SHA-0, SHA-1 o RIPEMD. Da un punto di vista computazionale, le collisioni di hash sono possibili per questi algoritmi, che li interrompono in modo efficace.
Algoritmi hash .NET consentiti per la flessibilità crittografica gestita (in ordine di preferenza):
SHA512Cng (conforme allo standard FIPS)
SHA384Cng (conforme allo standard FIPS)
SHA256Cng (conforme allo standard FIPS)
SHA512Managed, non conforme allo standard FIPS. Usare SHA512 come nome di algoritmo nelle chiamate a HashAlgorithm.Create o CryptoConfig.CreateFromName
SHA384Managed, non conforme allo standard FIPS. Usare SHA384 come nome di algoritmo nelle chiamate a HashAlgorithm.Create o CryptoConfig.CreateFromName
SHA256Managed, non conforme allo standard FIPS. Usare SHA256 come nome di algoritmo nelle chiamate a HashAlgorithm.Create o CryptoConfig.CreateFromName
SHA512CryptoServiceProvider (conforme allo standard FIPS)
SHA256CryptoServiceProvider (conforme allo standard FIPS)
SHA384CryptoServiceProvider (conforme allo standard FIPS)
Usare algoritmi di crittografia avanzata per crittografare i dati nel database
Gli algoritmi di crittografia definiscono trasformazioni dei dati che non possono essere facilmente invertite da utenti non autorizzati. SQL Server consente ad amministratori e sviluppatori di scegliere tra diversi algoritmi, inclusi DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, RC4 a 128 bit, DESX, AES a 128 bit, AES a 192 bit e AES a 256 bit.
I pacchetti SSIS devono essere crittografati ed essere con firma digitale
L'origine di un pacchetto è la persona o l'organizzazione che ha creato il pacchetto. L'esecuzione di un pacchetto da un'origine ignota o non attendibile potrebbe essere rischiosa. Per impedire la manomissione non autorizzata dei pacchetti SSIS, è consigliabile usare le firme digitali. Per garantire la riservatezza dei pacchetti durante l'archiviazione o il transito, i pacchetti SSIS devono anche essere crittografati.
Aggiungere la firma digitale alle entità a protezione diretta del database critiche
Qualora sia necessario verificare l'integrità di un'entità a protezione diretta del database critica, è consigliabile usare le firme digitali. Le entità a protezione diretta del database critiche, ad esempio stored procedure, funzioni, assembly o trigger, possono essere con firma digitale. Ecco un esempio di quando ciò può essere utile: si supponga che un fornitore di software indipendente (ISV) abbia fornito supporto per un software distribuito a uno dei clienti. Prima di fornire il supporto, l'ISV vuole assicurarsi che un'entità a protezione diretta del database nel software non sia stata manomessa per errore o intenzionalmente. Se l'entità a protezione diretta è con firma digitale, l'ISV può verificarne la firma digitale e convalidarne l'integrità.
Usare EKM di SQL Server per proteggere le chiavi di crittografia
Extensible Key Management di SQL Server consente di archiviare le chiavi di crittografia che proteggono i file di database in un dispositivo off-box, ad esempio una smart card, un dispositivo USB o un modulo EKM/HSM. Consente anche la protezione dei dati da parte degli amministratori del database (tranne i membri del gruppo sysadmin). I dati possono essere crittografati utilizzando le chiavi di crittografia a cui hanno accesso solo gli utenti del database nel modulo esterno EKM/HSM.
Usare la funzionalità AlwaysEncrypted se le chiavi di crittografia non devono essere rivelate al motore di database
Always Encrypted è una funzionalità progettata per proteggere i dati sensibili, ad esempio numeri di carta di credito o numeri di identificazione nazionali/regionali (ad esempio i numeri di sicurezza sociale degli Stati Uniti), archiviati in database Azure SQL o SQL Server. La funzionalità Always Encrypted consente ai client di crittografare i dati sensibili nelle applicazioni client e di non rivelare mai le chiavi di crittografia al motore di database (database SQL o SQL Server). Di conseguenza, Always Encrypted consente di separare i proprietari dei dati (che possono visualizzarli) e le persone incaricate della gestione dei dati (che però non devono poter accedere ai dati).
Archiviare le chiavi di crittografia in modo sicuro nel dispositivo IoT
Titolo
Dettagli
Componente
Dispositivo IoT
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
Sistema operativo dispositivo: Windows IoT Core, connettività dispositivo: Azure IoT SDK per dispositivi
Archiviare le chiavi private dei certificati o simmetriche in modo sicuro in una risorsa di archiviazione hardware protetta, ad esempio chip di smart card o TPM. Windows 10 IoT Core supporta l'utente di un TPM e sono disponibili diversi TPMS compatibili che possono essere usati: TPM discreti (dTPM). È consigliabile usare un modulo TPM firmware o discreto. Un modulo TPM software deve essere usato solo a scopo di sviluppo e test. Quando un modulo TPM è disponibile ed è stato effettuato il provisioning delle chiavi, il codice che genera il token deve essere scritto senza codificare le informazioni sensibili.
Esempio
TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM
string hubUri = myDevice.GetHostName();
string deviceId = myDevice.GetDeviceId();
string sasToken = myDevice.GetSASToken();
var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);
Come si può osservare, la chiave primaria del dispositivo non è presente nel codice. Viene invece archiviata nello slot 0 del modulo TPM. Il dispositivo TPM genera un token di firma di accesso condiviso temporaneo che viene quindi usato per connettersi all'hub IoT.
Generare una chiave simmetrica casuale sufficientemente lunga per l'autenticazione nell'hub IoT
Titolo
Dettagli
Componente
Gateway IoT cloud
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
Opzione gateway: Hub IoT di Azure
Riferimenti
N/D
Passaggi
L'hub IoT contiene un registro di identità del dispositivo e durante il provisioning genera automaticamente una chiave simmetrica casuale. È consigliabile usare questa funzionalità del registro di identità dell'hub IoT di Azure per generare la chiave usata per l'autenticazione. L'hub IoT consente anche di specificare una chiave durante la creazione del dispositivo. Se viene generata una chiave all'esterno dell'hub IoT durante il provisioning del dispositivo, è consigliabile creare una chiave simmetrica casuale o almeno a 256 bit.
Assicurarsi che sia attivo un criterio di gestione dei dispositivi che richiede di usare il PIN e consente la cancellazione remota.
Titolo
Dettagli
Componente
Client Dynamics CRM Mobile
Fase SDL
Distribuzione
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
Assicurarsi che sia attivo un criterio di gestione dei dispositivi che richiede di usare il PIN e consente la cancellazione remota.
Assicurarsi che sia attivo un criterio di gestione dei dispositivi che richiede PIN/password/blocco automatico e crittografa tutti i dati (ad esempio, BitLocker)
Titolo
Dettagli
Componente
Client Dynamics CRM per Outlook
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
Assicurarsi che sia attivo un criterio di gestione dei dispositivi che richiede PIN/password/blocco automatico e crittografa tutti i dati (ad esempio, BitLocker)
Assicurarsi che venga eseguito il rollover delle chiavi di firma quando si usa Identity Server
Assicurarsi che venga eseguito il rollover delle chiavi di firma quando si usa Identity Server. Il collegamento nella sezione Riferimenti illustra come pianificarlo senza causare interruzioni delle applicazioni basate su Identity Server.
Assicurarsi che l'ID client sicuro crittograficamente sicuro, il segreto client viene usato in Identity Server
Titolo
Dettagli
Componente
Identity Server
Fase SDL
Compilare
Tecnologie applicabili
Generico
Attributes (Attributi)
N/D
Riferimenti
N/D
Passaggi
Assicurarsi che vengano usati un ID client e un segreto client con crittografia complessa in Identity Server. È consigliabile seguire queste linee guida durante la generazione di un ID e un segreto client:
Generare un GUID casuale come ID client
Generare una chiave a 256 bit casuale tramite crittografia come segreto