Usar somente codificações de bloco simétricas e comprimentos de chave aprovados
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Os produtos devem usar somente essas codificações de bloco simétricas e os comprimentos de chave associados que foram explicitamente aprovados pelo Supervisor de criptografia em sua organização. Os algoritmos simétricos aprovados na Microsoft incluem as seguintes codificações de bloco:
Para um novo código, AES-128, AES 192 e AES-256 são aceitáveis.
Para garantir a compatibilidade com versões anteriores do código existente, a chave tripla 3DES é aceitável.
Para os produtos que usam codificações de bloco simétricas:
A criptografia AES (Advanced Encryption Standard) é necessária para novos códigos.
O padrão de criptografia 3DES (Triple Data Encryption Standard) com três chaves é permitido em códigos existentes e para garantir a compatibilidade com versões anteriores.
Todas as outras codificações de bloco, incluindo RC2, DES, 3DES com duas chaves, DESX e Skipjack, só podem ser usadas para descriptografar os dados antigos e devem ser substituídas se utilizadas para criptografia.
Para algoritmos de criptografia de bloco simétrica, é preciso ter um comprimento mínimo de chave de 128 bits. O algoritmo de criptografia de bloco único recomendado para o novo código é o AES (AES-128, AES-192 e AES-256 são aceitáveis).
O 3DES com três chaves é atualmente aceitável se já estiver em uso no código existente. É recomendável mudar para AES. Os algoritmos DESX, DES, RC2 e Skipjack não são mais considerados seguros. Eles só devem ser usados para descriptografar os dados existentes por conta de sua compatibilidade com versões anteriores. Depois disso, os dados devem ser criptografados novamente com uma codificação de bloco recomendada.
Observe que todas as codificações de bloco simétricas devem ser usadas com um modo de codificação aprovado, que exige o uso de um vetor de inicialização (IV) apropriado. Normalmente, um IV apropriado é um número aleatório e nunca um valor constante.
O uso de algoritmos de criptografia herdados ou não aprovados e de comprimentos de chave menores para ler dados existentes (em vez de gravar novos dados) pode ser permitido após a revisão dos especialistas em criptografia de sua organização. No entanto, você deve solicitar uma exceção para esse requisito. Além disso, em implantações empresariais, os produtos devem avisar os administradores quando uma criptografia fraca for usada para ler dados. Esses avisos devem ser explicativos e acionáveis. Em alguns casos, pode ser apropriado deixar que a Política de Grupo controle o uso de criptografia fraca.
Algoritmos do .NET permitidos para agilidade criptográfica gerenciada (em ordem de preferência)
AesCng (em conformidade com FIPS)
AuthenticatedAesCng (em conformidade com FIPS)
AESCryptoServiceProvider (em conformidade com FIPS)
AESManaged (sem conformidade com FIPS)
Observe que nenhum desses algoritmos pode ser especificado com o método SymmetricAlgorithm.Create ou CryptoConfig.CreateFromName sem que o arquivo machine.config seja alterado. Observe também que o AES nas versões do .NET anteriores ao .NET 3.5 é denominado RijndaelManaged, e que AesCng e AuthenticatedAesCng estão >disponíveis no CodePlex e exigem CNG no sistema operacional subjacente
Usar modos de codificação de bloco aprovados e vetores de inicialização para codificações simétricas
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Todas as codificações de bloco simétricas devem ser usadas com um modo de decodificação simétrica aprovado. Os únicos modos aprovados são CBC e CTS. Em particular, o modo de livro de código eletrônico (ECB) de operação deve ser evitado. Seu uso exige a revisão dos especialistas em criptografia de sua organização. Todos os usos de OFB, CFB, CTR, CCM e GCM, ou de qualquer outro modo de criptografia, devem revisados pelos especialistas em criptografia de sua organização. Reutilizar o mesmo vetor de inicialização (IV) com codificações de bloco em "modos de codificações de streaming", como CTR, pode fazer com que dados criptografados sejam revelados. Todas as codificações de bloco simétricas também devem ser usadas com IV apropriado, que é um número aleatório criptograficamente forte e nunca um valor constante.
Usar algoritmos assimétricos, comprimentos de chave e preenchimentos aprovados
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
O uso de algoritmos criptográficos proibidos gera um risco significativo para a segurança do produto e deve ser evitado. Os produtos devem usar somente os algoritmos de criptografia, os comprimentos de chave associados e o preenchimento que foram explicitamente aprovados pelos especialistas em criptografia de sua organização.
RSA - pode ser usada para assinatura, troca de chaves e criptografia. A criptografia RSA deve usar somente os modos de preenchimento OAEP ou RSA-KEM. O código existente pode usar o modo de preenchimento PKCS #1 v 1.5 somente para fins de compatibilidade. O uso do preenchimento nulo é expressamente proibido. É necessário usar chaves com 2048 bits ou mais para um novo código. O código existente pode oferecer suporte a chaves com menos de 2048 bits somente para garantir a compatibilidade com versões anteriores após a revisão dos especialistas em criptografia de sua organização. As chaves com menos de 1024 só podem ser usadas para descriptografar ou verificar dados antigos e devem ser substituídas para operações de criptografia ou assinatura
ECDSA - pode ser usada somente para assinatura. É necessário o ECDSA com chaves de 256 bits ou mais para um novo código. As assinaturas baseadas em ECDSA devem usar uma das três curvas NIST aprovadas (P-256, P-384 ou P521). As curvas que foram minuciosamente analisada poderão ser usadas somente após uma revisão dos especialistas em criptografia de sua organização.
ECDH - pode ser usada somente para troca de chaves. É necessário o ECDH com chaves de 256 bits ou mais para um novo código. As trocas de chaves baseadas em ECDH devem usar uma das três curvas NIST aprovadas (P-256, P-384 ou P521). As curvas que foram minuciosamente analisada poderão ser usadas somente após uma revisão dos especialistas em criptografia de sua organização.
DSA - pode ser aceitável após revisão e aprovação dos especialistas em criptografia de sua organização. Entre em contato com o consultor de segurança para agendar uma revisão com os especialistas em criptografia de sua organização. Se o uso da DSA for aprovado, você precisará proibir o uso de chaves com menos de 2048 bits de comprimento. A CNG oferece suporte a chaves com 2048 bits ou mais a partir do Windows 8.
Diffie-Hellman - pode ser usada somente para o gerenciamento de chaves de sessão. É necessário usar chaves com 2048 bits ou mais para um novo código. O código existente pode dar suporte a chaves com menos de 2048 bits somente para garantir a compatibilidade com versões anteriores, após um exame do Conselho de criptografia de sua organização. Chaves com menos de 1024 bits não podem ser usadas.
Usar um número aleatório de geradores aprovados
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Os produtos devem usar um número aleatório de geradores aprovados. Funções pseudoaleatórias, como o aleatório da função de runtime C, a classe System.Random do .NET Framework ou funções de sistema, como GetTickCount, nunca devem ser usadas em um código como esse. O uso do algoritmo do gerador de número aleatório de curva elíptica dupla (DUAL_EC_DRBG) é proibido.
CNG- BCryptGenRandom (é recomendável usar o sinalizador BCRYPT_USE_SYSTEM_PREFERRED_RNG, exceto se o chamador executar um IRQL maior que 0 [PASSIVE_LEVEL])
CAPI- cryptGenRandom
Win32/64- RtlGenRandom (as novas implementações devem usar BCryptGenRandom ou CryptGenRandom) * rand_s * SystemPrng (para o modo kernel)
.NET- RNGCryptoServiceProvider ou RNGCng
Aplicativos da Windows Store- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom ou .GenerateRandomNumber
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
Apple OS X (10.7 ou anterior)- Use /dev/random para recuperar números aleatórios
Java(including Google Android Java Code) – java.security.SecureRandom class. (observe que para o Android 4.3 (Jelly Bean), os desenvolvedores devem seguir a solução alternativa recomendada para o Android e atualizar os aplicativos para inicializar explicitamente a PRNG com entropia de /dev/urandom ou /dev/random)
Não usar codificações de fluxo simétricas
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Codificações de stream simétricas, como RC4, não devem ser usadas. Em vez de codificações de stream simétricas, os produtos devem usar uma codificação de bloco, especificamente a AES com uma chave de pelo menos 128 bits.
Usar algoritmos MAC, HMAC e de hash com chave
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Os produtos devem usar somente algoritmos de código de autenticação de mensagem (MAC) ou de código de autenticação de mensagem baseada em hash (HMAC) aprovados.
Um código de autenticação de mensagem (MAC) é um trecho de informação anexado a uma mensagem que permite ao destinatário verificar a autenticidade do remetente e a integridade da mensagem usando uma chave secreta. O uso de qualquer MAC baseado em hash (HMAC) ou MAC baseado em codificação de bloco é permitido, desde que todos os hash subjacente ou algoritmos de criptografia simétrica também estejam aprovados para uso. Isso atualmente inclui as funções HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 e HMAC-SHA512) e os MACs baseados em codificação de bloco CMAC/OMAC1 e OMAC2 (esses são baseados na AES).
O uso de HMAC-SHA1 pode ser permitido para garantir a compatibilidade com a plataforma, mas você precisará emitir uma exceção para esse procedimento e ser submetido à revisão dos especialistas em criptografia de sua organização. Não é permitido truncar HMACs para menos de 128 bits. Usar métodos de clientes para hash de chave e dados não é permitido. Eles precisam ser revisados pelos especialistas em criptografia de sua organização antes do serem usados.
Usar apenas as funções aprovadas do hash criptográfico
Title
Detalhes
Componente
Aplicativo Web
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Os produtos devem usar a família SHA-2 de algoritmos de hash (SHA256, SHA384 e SHA512). Se for necessário usar um hash mais curto, com um comprimento de saída de 128 bits para ajustá-lo a uma estrutura de dados criada com o hash MD5 menor em mente, as equipes de produtos podem truncar um dos hashes SHA2 (normalmente o SHA256). Observe que o SHA384 é uma versão truncada do SHA512. Por motivos de segurança, não é permitido truncar hashes criptográficos para menos de 128 bits. O novo código não deve usar os algoritmos de hash MD2, MD4, MD5, SHA-0, SHA-1 ou RIPEMD. É possível realizar colisões de hash computacionalmente para esses algoritmos, o que efetivamente os quebrará.
Algoritmos de hash do .NET permitidos para agilidade criptográfica gerenciada (em ordem de preferência)
SHA512Cng (em conformidade com FIPS)
SHA384Cng (em conformidade com FIPS)
SHA256Cng (em conformidade com FIPS)
SHA512Managed (não compatível com FIPS) (use SHA512 como nome de algoritmo nas chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA384Managed (não compatível com FIPS) (use SHA384 como nome de algoritmo nas chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA256Managed (não compatível com FIPS) (use SHA256 como nome do algoritmo nas chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA512CryptoServiceProvider (em conformidade com FIPS)
SHA256CryptoServiceProvider (em conformidade com FIPS)
SHA384CryptoServiceProvider (em conformidade com FIPS)
Usar algoritmos de criptografia forte para criptografar dados no banco de dados
Os algoritmos de criptografia definem as transformações de dados que não podem ser facilmente revertidas por usuários não autorizados. O SQL Server permite que administradores e desenvolvedores escolham entre vários algoritmos, incluindo DES, Triplo DES, TRIPLE_DES_3KEY, RC2, RC4, RC4 de 128 bits, DESX, AES de 128 bits, AES de 192 bits e AES de 256 bits.
Os pacotes do SSIS devem ser criptografados e assinados digitalmente
A origem de um pacote é a pessoa ou organização que criou o pacote. Pode ser arriscado executar um pacote de origem desconhecida ou não confiável. Para evitar que os pacotes do SSIS sejam inadvertidamente alterados, use assinaturas digitais. Para garantir a confidencialidade dos pacotes durante seu trânsito/armazenamento, os pacotes do SSIS precisam ser criptografados
Adicionar assinatura digital a protegíveis de banco de dados críticos
Quando for necessário verificar a integridade de um banco de dados crítico protegível, use assinaturas digitais. Os protegíveis de um banco de dados, como um procedimento armazenado, uma função, um assembly ou um disparo, podem ser assinados digitalmente. Abaixo está um exemplo de quando isso pode ser útil: digamos que um ISV (fornecedor independente de software) ofereceu suporte a um software distribuído para um de seus clientes. Antes de fornecer o suporte, o ISV pode querer ter certeza de que um protegível do banco de dados no software não foi alterado por engano ou de forma maliciosa. Se o protegível estiver assinado digitalmente, o ISV poderá verificar sua assinatura digital e validar sua integridade.
Usar EKM do SQL Server para proteger chaves de criptografia
O gerenciamento extensível de chaves do SQL Server permite que as chaves de criptografia que protegem os arquivos de banco de dados sejam armazenadas em um dispositivo externo, como um cartão inteligente, dispositivo USB ou um módulo EKM/HSM. Isso também permite proteger os dados dos administradores de banco de dados (exceto dos membros do grupo sysadmin). Com o uso de chaves de criptografia, é possível criptografar dados aos quais somente o usuário do banco de dados tem acesso no módulo externo de EKM/HSM.
Usar o recurso AlwaysEncrypted para não revelar as chaves de criptografia ao mecanismo de banco de dados
O Always Encrypted é um recurso para proteger dados confidenciais, como números de cartão de crédito ou números de identificação nacional/regional (por exemplo, os números do seguro social dos EUA), armazenados nos Bancos de dados SQL do Azure ou do SQL Server. Esse recurso permite que os clientes criptografem dados confidenciais em aplicativos clientes e nunca revelem as chaves de criptografia para o mecanismo de banco de dados (Banco de dados SQL ou SQL Server). Consequentemente, o Always Encrypted diferencia os proprietários dos dados (que podem vê-los) de quem gerencia os dados (mas não deve ter acesso).
Armazenar chaves de criptografia com segurança no dispositivo IoT
Title
Detalhes
Componente
Dispositivo IoT
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
Sistema operacional do dispositivo - Windows IoT Core, Conectividade do dispositivo - SDKs do dispositivo IoT do Azure
Armazene chaves privadas simétricas ou de certificado com segurança em um armazenamento de hardware protegido, um TPM ou chips de cartão inteligente. O Windows 10 IoT Core dá suporte para usuário de um TPM e há vários TPMs compatíveis que podem ser usados: dTPM (TPM Discreto). É recomendável usar um TPM Discreto ou de Firmware. Um TPM de Software deve ser usado apenas para fins de testes e desenvolvimento. Depois que um TPM estiver disponível e as chaves forem provisionadas nele, o código que gera o token deve ser escrito sem conter informações confidenciais.
Exemplo
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);
Como podemos ver, a chave primária do dispositivo não está presente no código. Em vez disso, ela está armazenada no slot 0 do TPM. O dispositivo do TPM gera um token SAS de curta duração que é usado para estabelecer uma conexão com o Hub IoT.
Gerar uma chave simétrica aleatória com um tamanho suficiente para autenticação no Hub IoT
Title
Detalhes
Componente
Gateway de Nuvem IoT
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
Opção de gateway - Hub IoT do Azure
Referências
N/D
Etapas
O Hub IoT contém um Registro de Identidade de dispositivo e, ao provisionar um dispositivo, gera automaticamente uma chave simétrica aleatória. É recomendável usar esse recurso do Registro de Identidade do Hub IoT do Azure para gerar a chave usada para autenticação. O Hub IoT também permite que uma chave seja especificada durante a criação do dispositivo. Se uma chave é gerada fora do Hub IoT durante o provisionamento do dispositivo, é recomendável criar uma chave simétrica aleatória ou com pelo menos 256 bits.
Garanta que uma política de gerenciamento de dispositivos esteja aplicada, que ela exija um PIN de uso e permita a limpeza remota do dispositivo.
Title
Detalhes
Componente
Cliente móvel do Dynamics CRM
Fase do SDL
Implantação
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Garanta que uma política de gerenciamento de dispositivos esteja aplicada, que ela exija um PIN de uso e permita a limpeza remota do dispositivo.
Garanta que uma política de gerenciamento de dispositivos esteja aplicada, que exija PIN, senha ou bloqueio automático e criptografe todos os dados (por exemplo, o BitLocker)
Title
Detalhes
Componente
Cliente do Outlook do Dynamics CRM
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Garanta que uma política de gerenciamento de dispositivos esteja aplicada, que exija PIN, senha ou bloqueio automático e criptografe todos os dados (por exemplo, o BitLocker)
Garantir que as chaves de assinatura sejam trocadas quando o Servidor de identidade for usado
Garanta que as chaves de assinatura sejam trocadas quando o Servidor de identidade for usado. O conteúdo do link na seção Referências explica como isso deve ser planejado sem causar interrupções em aplicativos que dependem do Servidor de identidade.
Garantir que ID de cliente e segredo do cliente criptograficamente fortes sejam usados no Identity Server
Title
Detalhes
Componente
Servidor de identidade
Fase do SDL
Build
Tecnologias aplicáveis
Genérico
Atributos
N/D
Referências
N/D
Etapas
Garantir que ID de cliente e segredo do cliente criptograficamente fortes sejam usados no Identity Server. As seguintes diretrizes devem ser usadas durante a geração de um segredo e uma ID de cliente:
Gerar um GUID aleatório como o ID do cliente
Gerar uma chave de 256 bits criptograficamente aleatória como o segredo