Alleen goedgekeurde symmetrische bloksleutels en sleutellengten gebruiken
Titel
Details
Onderdeel
Webtoepassing
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Producten moeten alleen die symmetrische blokcoderingen en bijbehorende sleutellengten gebruiken die expliciet zijn goedgekeurd door de Crypto Advisor in uw organisatie. Goedgekeurde symmetrische algoritmen bij Microsoft omvatten de volgende blokcoderingen:
Voor nieuwe code zijn AES-128, AES-192 en AES-256 acceptabel
Voor achterwaartse compatibiliteit met bestaande code is 3DES met drie sleutels acceptabel
Voor producten die symmetrische blokcoderingen gebruiken:
Advanced Encryption Standard (AES) is vereist voor nieuwe code
3DES (Triple Data Encryption Standard) met drie sleutels is toegestaan in bestaande code voor achterwaartse compatibiliteit
Alle andere blokcoderingen, waaronder RC2, DES, 2 Key 3DES, DESX en Skipjack, mogen alleen worden gebruikt voor het ontsleutelen van oude gegevens en moeten worden vervangen als ze worden gebruikt voor versleuteling
Voor symmetrische blokversleutelingsalgoritmen is een minimale sleutellengte van 128 bits vereist. Het enige algoritme voor blokversleuteling dat wordt aanbevolen voor nieuwe code is AES (AES-128, AES-192 en AES-256 zijn allemaal acceptabel)
3DES met drie sleutels is momenteel acceptabel als deze al in gebruik is in bestaande code; overgang naar AES wordt aanbevolen. DES, DESX, RC2 en Skipjack worden niet langer als veilig beschouwd. Deze algoritmen mogen alleen worden gebruikt voor het ontsleutelen van bestaande gegevens ten behoeve van achterwaartse compatibiliteit en gegevens moeten opnieuw worden versleuteld met behulp van een aanbevolen blokcodering
Houd er rekening mee dat alle symmetrische blokcoderingen moeten worden gebruikt met een goedgekeurde coderingsmodus, waarvoor een geschikte initialisatievector (IV) moet worden gebruikt. Een geschikte IV is meestal een willekeurig getal en nooit een constante waarde
Het gebruik van verouderde of anderszins niet-goedgekeurde cryptoalgoritmen en kleinere sleutellengten voor het lezen van bestaande gegevens (in plaats van het schrijven van nieuwe gegevens) kan worden toegestaan na de cryptoraadbeoordeling van uw organisatie. U moet echter een uitzondering op deze vereiste indienen. Bovendien moeten producten in bedrijfsimplementaties overwegen beheerders te waarschuwen wanneer zwakke crypto wordt gebruikt om gegevens te lezen. Dergelijke waarschuwingen moeten verklarend en uitvoerbaar zijn. In sommige gevallen kan het passend zijn om groepsbeleid het gebruik van zwakke crypto te controleren
Toegestane .NET-algoritmen voor beheerde cryptoflexibiliteit (in volgorde van voorkeur)
AesCng (FIPS-compatibel)
AuthenticatedAesCng (FIPS-compatibel)
AESCryptoServiceProvider (FIPS-compatibel)
AESManaged (niet-FIPS-compatibel)
Houd er rekening mee dat geen van deze algoritmen kan worden opgegeven via de SymmetricAlgorithm.Create methoden of CryptoConfig.CreateFromName zonder wijzigingen aan te brengen in het machine.config-bestand. Houd er ook rekening mee dat AES in versies van .NET vóór .NET 3.5 de naam RijndaelManaged, en AesCngAuthenticatedAesCng beschikbaar zijn >via CodePlex en CNG vereisen in het onderliggende besturingssysteem
Goedgekeurde blokcoderingsmodi en initialisatievectoren gebruiken voor symmetrische coderingen
Titel
Details
Onderdeel
Webtoepassing
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Alle symmetrische blokcoderingen moeten worden gebruikt met een goedgekeurde symmetrische coderingsmodus. De enige goedgekeurde modi zijn CBC en CTS. Met name de werkingswijze van het elektronisch codeboek (ECB) moet worden vermeden; voor het gebruik van ECB is een Crypto Board-beoordeling van uw organisatie vereist. Al het gebruik van OFB, SSL, CTR, CCM en GCM of een andere versleutelingsmodus moet worden gecontroleerd door de Crypto Board van uw organisatie. Het opnieuw gebruiken van dezelfde initialisatievector (IV) met blokcoderingen in 'streaming coderingsmodi', zoals CTR, kan ertoe leiden dat versleutelde gegevens worden onthuld. Alle symmetrische blokcoderingen moeten ook worden gebruikt met een geschikte initialisatievector (IV). Een geschikte IV is een cryptografisch sterk, willekeurig getal en nooit een constante waarde.
Goedgekeurde asymmetrische algoritmen, sleutellengten en opvulling gebruiken
Titel
Details
Onderdeel
Webtoepassing
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Het gebruik van verboden cryptografische algoritmen brengt aanzienlijke risico's met zich mee voor de productbeveiliging en moet worden vermeden. Producten mogen alleen die cryptografische algoritmen en bijbehorende sleutellengten en opvulling gebruiken die expliciet zijn goedgekeurd door de Crypto Board van uw organisatie.
RSA- kan worden gebruikt voor versleuteling, sleuteluitwisseling en handtekening. RSA-versleuteling mag alleen de opvulmodi OAEP of RSA-KEM gebruiken. Bestaande code mag de PKCS #1 v1.5 opvullingsmodus alleen gebruiken voor compatibiliteit. Het gebruik van null-opvulling is expliciet verboden. Sleutels >= 2048 bits is vereist voor nieuwe code. Bestaande code kan sleutels < 2048 bits alleen ondersteunen voor achterwaartse compatibiliteit na controle door de Crypto Board van uw organisatie. Sleutels < 1024 bits mogen alleen worden gebruikt voor het ontsleutelen/verifiëren van oude gegevens en moeten worden vervangen als ze worden gebruikt voor versleutelings- of ondertekeningsbewerkingen
ECDSA- mag alleen worden gebruikt voor ondertekening. ECDSA met >=256-bits sleutels is vereist voor nieuwe code. Op ECDSA gebaseerde handtekeningen moeten een van de drie NIST-goedgekeurde curven gebruiken (P-256, P-384 of P521). Curven die grondig zijn geanalyseerd, kunnen alleen worden gebruikt na een beoordeling met de Crypto Board van uw organisatie.
ECDH- mag alleen worden gebruikt voor sleuteluitwisseling. ECDH met >=256-bits sleutels is vereist voor nieuwe code. Sleuteluitwisseling op basis van ECDH moet een van de drie door NIST goedgekeurde curven (P-256, P-384 of P521) gebruiken. Curven die grondig zijn geanalyseerd, kunnen alleen worden gebruikt na een beoordeling met de Crypto Board van uw organisatie.
DSA- kan acceptabel zijn na beoordeling en goedkeuring van de Crypto Board van uw organisatie. Neem contact op met uw beveiligingsadviseur om de Crypto Board-beoordeling van uw organisatie te plannen. Als uw gebruik van DSA is goedgekeurd, moet u het gebruik van sleutels met een lengte van minder dan 2048 bits verbieden. CNG ondersteunt 2048-bits en grotere sleutellengten vanaf Windows 8.
Diffie-Hellman- mag alleen worden gebruikt voor sessiesleutelbeheer. Sleutellengte >= 2048 bits is vereist voor nieuwe code. Bestaande code kan sleutellengten < 2048 bits alleen ondersteunen voor achterwaartse compatibiliteit na beoordeling door het Crypto Board van uw organisatie. Sleutels < 1024 bits mogen niet worden gebruikt.
Goedgekeurde generatoren voor willekeurige getallen gebruiken
Titel
Details
Onderdeel
Webtoepassing
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Producten moeten goedgekeurde generatoren voor willekeurige getallen gebruiken. Pseudorandom-functies zoals de rand van de C-runtimefunctie, de .NET Framework klasse System.Random of systeemfuncties zoals GetTickCount moeten daarom nooit in dergelijke code worden gebruikt. Gebruik van het algoritme dual elliptic curve random number generator (DUAL_EC_DRBG) is verboden
CNG- BCryptGenRandom(gebruik van de vlag BCRYPT_USE_SYSTEM_PREFERRED_RNG aanbevolen, tenzij de aanroeper kan worden uitgevoerd op een IRQL groter dan 0 [dat wil PASSIVE_LEVEL])
Windows Store-apps- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom of . GenerateRandomNumber
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
Apple OS X (<10.7)- Gebruik /dev/random om willekeurige getallen op te halen
Java(inclusief Google Android Java-code)- klasse java.security.SecureRandom. Houd er rekening mee dat ontwikkelaars voor Android 4.3 (Jelly Bean) de door Android aanbevolen tijdelijke oplossing moeten volgen en hun toepassingen moeten bijwerken om de PRNG expliciet te initialiseren met entropie van /dev/urandom of /dev/random
Gebruik geen symmetrische stroomcoderingen
Titel
Details
Onderdeel
Webtoepassing
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Symmetrische stroomcoderingen, zoals RC4, mogen niet worden gebruikt. In plaats van symmetrische stroomcoderingen moeten producten een blokcodering gebruiken, met name AES met een sleutellengte van ten minste 128 bits.
Producten mogen alleen goedgekeurde MAC-algoritmen (Message Authentication Code) of HMAC (Hash-Based Message Authentication Code) gebruiken.
Een berichtverificatiecode (MAC) is een stukje informatie dat is gekoppeld aan een bericht waarmee de ontvanger de authenticiteit van de afzender en de integriteit van het bericht kan verifiëren met behulp van een geheime sleutel. Het gebruik van een mac op basis van hash (HMAC) of op blokcodering gebaseerde MAC is toegestaan zolang alle onderliggende hash- of symmetrische versleutelingsalgoritmen ook zijn goedgekeurd voor gebruik; dit omvat momenteel de HMAC-SHA2-functies (HMAC-SHA256, HMAC-SHA384 en HMAC-SHA512) en de CMAC/OMAC1- en OMAC2-BLOK-gebaseerde MACs (deze zijn gebaseerd op AES).
Het gebruik van HMAC-SHA1 is mogelijk toegestaan voor platformcompatibiliteit, maar u moet een uitzondering op deze procedure indienen en de Crypto-beoordeling van uw organisatie ondergaan. Afkapping van HMAC's tot minder dan 128 bits is niet toegestaan. Het gebruik van klantmethoden om een sleutel en gegevens te hashen, is niet goedgekeurd en moet de Crypto Board-beoordeling van uw organisatie ondergaan voordat ze worden gebruikt.
Alleen goedgekeurde cryptografische hashfuncties gebruiken
Titel
Details
Onderdeel
Webtoepassing
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Producten moeten gebruikmaken van de SHA-2-familie van hash-algoritmen (SHA256, SHA384 en SHA512). Als er een kortere hash nodig is, zoals een 128-bits uitvoerlengte om een gegevensstructuur te passen die is ontworpen met de kortere MD5-hash in gedachten, kunnen productteams een van de SHA2-hashes (meestal SHA256) afkappen. Houd er rekening mee dat SHA384 een afgekapte versie van SHA512 is. Afkapping van cryptografische hashes voor beveiligingsdoeleinden tot minder dan 128 bits is niet toegestaan. Nieuwe code mag geen gebruik maken van de hashalgoritmen MD2, MD4, MD5, SHA-0, SHA-1 of RIPEMD. Hash-conflicten zijn rekenkundig haalbaar voor deze algoritmen, waardoor ze effectief worden verbroken.
Toegestane .NET-hashalgoritmen voor beheerde cryptoflexibiliteit (in volgorde van voorkeur):
SHA512Cng (FIPS-compatibel)
SHA384Cng (FIPS-compatibel)
SHA256Cng (FIPS-compatibel)
SHA512Managed (niet-FIPS-compatibel) (gebruik SHA512 als algoritmenaam in aanroepen naar HashAlgorithm.Create of CryptoConfig.CreateFromName)
SHA384Managed (niet-FIPS-compatibel) (gebruik SHA384 als algoritmenaam in aanroepen naar HashAlgorithm.Create of CryptoConfig.CreateFromName)
SHA256Managed (niet-FIPS-compatibel) (gebruik SHA256 als algoritmenaam in aanroepen naar HashAlgorithm.Create of CryptoConfig.CreateFromName)
SHA512CryptoServiceProvider (FIPS-compatibel)
SHA256CryptoServiceProvider (FIPS-compatibel)
SHA384CryptoServiceProvider (FIPS-compatibel)
Sterke versleutelingsalgoritmen gebruiken om gegevens in de database te versleutelen
Versleutelingsalgoritmen definiëren gegevenstransformaties die niet eenvoudig kunnen worden teruggedraaid door onbevoegde gebruikers. SQL Server kunnen beheerders en ontwikkelaars kiezen uit verschillende algoritmen, waaronder DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bits RC4, DESX, 128-bits AES, 192-bits AES en 256-bits AES
SSIS-pakketten moeten worden versleuteld en digitaal worden ondertekend
De bron van een pakket is de persoon of organisatie die het pakket heeft gemaakt. Het uitvoeren van een pakket vanuit een onbekende of niet-vertrouwde bron kan riskant zijn. Om onrechtmatige manipulatie van SSIS-pakketten te voorkomen, moeten digitale handtekeningen worden gebruikt. Om de vertrouwelijkheid van de pakketten tijdens opslag/overdracht te waarborgen, moeten SSIS-pakketten ook worden versleuteld
Digitale handtekening toevoegen aan essentiële databasebeveiligbare onderdelen
In gevallen waarin de integriteit van een beveiligbare kritieke database moet worden gecontroleerd, moeten digitale handtekeningen worden gebruikt. Databasebeveiligbare onderdelen, zoals een opgeslagen procedure, functie, assembly of trigger, kunnen digitaal worden ondertekend. Hieronder ziet u een voorbeeld van wanneer dit nuttig kan zijn: stel dat een ISV (Onafhankelijke softwareleverancier) ondersteuning heeft geboden voor software die aan een van hun klanten wordt geleverd. Voordat ondersteuning wordt geboden, wil de ISV ervoor zorgen dat een database die in de software kan worden beveiligd, niet per ongeluk of door een kwaadwillende poging is gemanipuleerd. Als het beveiligbare digitaal is ondertekend, kan de ISV de digitale handtekening verifiëren en de integriteit valideren.
SQL Server EKM gebruiken om versleutelingssleutels te beveiligen
SQL Server Extensible Key Management maakt de versleutelingssleutels waarmee de databasebestanden worden beveiligd, in staat om op te slaan op een extern apparaat, zoals een smartcard, USB-apparaat of EKM/HSM-module. Hiermee kunt u ook gegevensbeveiliging van databasebeheerders (met uitzondering van leden van de groep sysadmin) inschakelen. Gegevens kunnen worden versleuteld met behulp van versleutelingssleutels waartoe alleen de databasegebruiker toegang heeft op de externe EKM/HSM-module.
De functie AlwaysEncrypted gebruiken als versleutelingssleutels niet moeten worden weergegeven in de database-engine
Always Encrypted is een functie die is ontworpen om gevoelige gegevens te beschermen, zoals creditcardnummers of nationale/regionale identificatienummers (bijvoorbeeld Amerikaanse burgerservicenummers), die zijn opgeslagen in Azure SQL Database of SQL Server databases. met Always Encrypted kunnen clients gevoelige gegevens in clienttoepassingen versleutelen en de versleutelingssleutels nooit onthullen aan de database-engine (SQL Database of SQL Server). Als gevolg hiervan biedt Always Encrypted een scheiding tussen degenen die eigenaar zijn van de gegevens (en deze kunnen bekijken) en degenen die de gegevens beheren (maar geen toegang mogen hebben)
Cryptografische sleutels veilig opslaan op IoT-apparaat
Titel
Details
Onderdeel
IoT-apparaat
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
Apparaatbesturingssysteem - Windows IoT Core, apparaatconnectiviteit - Azure IoT-apparaat-SDK's
Symmetrische of persoonlijke certificaatsleutels veilig in een met hardware beveiligde opslag, zoals TPM of smartcardchips. Windows 10 IoT Core ondersteunt de gebruiker van een TPM en er zijn verschillende compatibele TPM's die kunnen worden gebruikt: Discrete TPM (dTPM). Het wordt aanbevolen om een firmware of discrete TPM te gebruiken. Een software-TPM mag alleen worden gebruikt voor ontwikkelings- en testdoeleinden. Zodra een TPM beschikbaar is en de sleutels erin zijn ingericht, moet de code waarmee het token wordt gegenereerd, worden geschreven zonder dat gevoelige informatie erin hard wordt gecodeerd.
Voorbeeld
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);
Zoals u kunt zien, is de primaire sleutel van het apparaat niet aanwezig in de code. In plaats daarvan wordt deze opgeslagen in de TPM op sleuf 0. TPM-apparaat genereert een SAS-token met korte levensduur dat vervolgens wordt gebruikt om verbinding te maken met de IoT Hub.
Genereer een willekeurige symmetrische sleutel van voldoende lengte om verificatie te IoT Hub
Titel
Details
Onderdeel
IoT-cloudgateway
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
Gatewaykeuze - Azure IoT Hub
Referenties
N.v.t.
Stappen
IoT Hub een apparaatidentiteitsregister bevat en tijdens het inrichten van een apparaat automatisch een willekeurige symmetrische sleutel genereert. Het wordt aanbevolen om deze functie van het Azure IoT Hub Identity Registry te gebruiken om de sleutel te genereren die wordt gebruikt voor verificatie. IoT Hub kunt u ook een sleutel opgeven tijdens het maken van het apparaat. Als een sleutel wordt gegenereerd buiten IoT Hub tijdens het inrichten van het apparaat, is het raadzaam om een willekeurige symmetrische sleutel of ten minste 256 bits te maken.
Zorg ervoor dat er een apparaatbeheerbeleid is ingesteld dat een pincode vereist en extern wissen toestaat
Titel
Details
Onderdeel
Dynamics CRM Mobile-client
SDL-fase
Implementatie
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Zorg ervoor dat er een apparaatbeheerbeleid is ingesteld dat een pincode vereist en extern wissen toestaat
Zorg ervoor dat er een beleid voor apparaatbeheer is ingesteld dat een pincode/wachtwoord/automatisch vergrendelen vereist en alle gegevens versleutelt (bijvoorbeeld BitLocker)
Titel
Details
Onderdeel
Dynamics CRM Outlook-client
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Zorg ervoor dat er een beleid voor apparaatbeheer is ingesteld dat een pincode/wachtwoord/automatisch vergrendelen vereist en alle gegevens versleutelt (bijvoorbeeld BitLocker)
Zorg ervoor dat ondertekeningssleutels worden overgerold wanneer u identity server gebruikt
Zorg ervoor dat ondertekeningssleutels worden overgerold wanneer u Identity Server gebruikt. In de koppeling in de sectie Verwijzingen wordt uitgelegd hoe dit moet worden gepland zonder onderbrekingen te veroorzaken voor toepassingen die afhankelijk zijn van Identity Server.
Zorg ervoor dat cryptografisch sterke client-id en clientgeheim worden gebruikt in Identity Server
Titel
Details
Onderdeel
Identiteitsserver
SDL-fase
Ontwikkelen
Toepasselijke technologieën
Algemeen
Kenmerken
N.v.t.
Referenties
N.v.t.
Stappen
Zorg ervoor dat cryptografisch sterke client-id en clientgeheim worden gebruikt in Identity Server. De volgende richtlijnen moeten worden gebruikt bij het genereren van een client-id en -geheim:
Een willekeurige GUID genereren als de client-id
Een cryptografisch willekeurige 256-bits sleutel genereren als het geheim