Breyta

Deila með

Security Frame: Cryptography | Mitigation

  • Grein
Product/Service Article
Web Application
Database
IoT Device
IoT Cloud Gateway
Dynamics CRM Mobile Client
Dynamics CRM Outlook Client
Identity Server

Use only approved symmetric block ciphers and key lengths

Title Details
Component Web Application
SDL Phase Build
Applicable Technologies Generic
Attributes N/A
References N/A
Steps

Products must use only those symmetric block ciphers and associated key lengths which have been explicitly approved by the Crypto Advisor in your organization. Approved symmetric algorithms at Microsoft include the following block ciphers:

  • For new code AES-128, AES-192, and AES-256 are acceptable
  • For backward compatibility with existing code, three-key 3DES is acceptable
  • For products using symmetric block ciphers:
    • Advanced Encryption Standard (AES) is required for new code
    • Three-key triple Data Encryption Standard (3DES) is permissible in existing code for backward compatibility
    • All other block ciphers, including RC2, DES, 2 Key 3DES, DESX, and Skipjack, may only be used for decrypting old data, and must be replaced if used for encryption
  • For symmetric block encryption algorithms, a minimum key length of 128 bits is required. The only block encryption algorithm recommended for new code is AES (AES-128, AES-192 and AES-256 are all acceptable)
  • Three-key 3DES is currently acceptable if already in use in existing code; transition to AES is recommended. DES, DESX, RC2, and Skipjack are no longer considered secure. These algorithms may only be used for decrypting existing data for the sake of backward-compatibility, and data should be re-encrypted using a recommended block cipher

Please note that all symmetric block ciphers must be used with an approved cipher mode, which requires use of an appropriate initialization vector (IV). An appropriate IV, is typically a random number and never a constant value

The use of legacy or otherwise unapproved crypto algorithms and smaller key lengths for reading existing data (as opposed to writing new data) may be permitted after your organization's Crypto Board review. However, you must file for an exception against this requirement. Additionally, in enterprise deployments, products should consider warning administrators when weak crypto is used to read data. Such warnings should be explanatory and actionable. In some cases, it may be appropriate to have Group Policy control the use of weak crypto

Allowed .NET algorithms for managed crypto agility (in order of preference)

  • AesCng (FIPS compliant)
  • AuthenticatedAesCng (FIPS compliant)
  • AESCryptoServiceProvider (FIPS compliant)
  • AESManaged (non-FIPS-compliant)

Please note that none of these algorithms can be specified via the SymmetricAlgorithm.Create or CryptoConfig.CreateFromName methods without making changes to the machine.config file. Also, note that AES in versions of .NET prior to .NET 3.5 is named RijndaelManaged, and AesCng and AuthenticatedAesCng are >available through CodePlex and require CNG in the underlying OS

Use approved block cipher modes and initialization vectors for symmetric ciphers

Title Details
Component Web Application
SDL Phase Build
Applicable Technologies Generic
Attributes N/A
References N/A
Steps All symmetric block ciphers must be used with an approved symmetric cipher mode. The only approved modes are CBC and CTS. In particular, the electronic code book (ECB) mode of operation should be avoided; use of ECB requires your organization's Crypto Board review. All usage of OFB, CFB, CTR, CCM, and GCM or any other encryption mode must be reviewed by your organization's Crypto Board. Reusing the same initialization vector (IV) with block ciphers in "streaming ciphers modes," such as CTR, may cause encrypted data to be revealed. All symmetric block ciphers must also be used with an appropriate initialization vector (IV). An appropriate IV is a cryptographically strong, random number and never a constant value.

Use approved asymmetric algorithms, key lengths, and padding

Title Details
Component Web Application
SDL Phase Build
Applicable Technologies Generic
Attributes N/A
References N/A
Steps

The use of banned cryptographic algorithms introduces significant risk to product security and must be avoided. Products must use only those cryptographic algorithms and associated key lengths and padding that have been explicitly approved by your organization's Crypto Board.

  • RSA- may be used for encryption, key exchange and signature. RSA encryption must use only the OAEP or RSA-KEM padding modes. Existing code may use PKCS #1 v1.5 padding mode for compatibility only. Use of null padding is explicitly banned. Keys >= 2048 bits is required for new code. Existing code may support keys < 2048 bits only for backwards compatibility after a review by your organization's Crypto Board. Keys < 1024 bits may only be used for decrypting/verifying old data, and must be replaced if used for encryption or signing operations
  • ECDSA- may be used for signature only. ECDSA with >=256-bit keys is required for new code. ECDSA-based signatures must use one of the three NIST approved curves (P-256, P-384, or P521). Curves that have been thoroughly analyzed may be used only after a review with your organization's Crypto Board.
  • ECDH- may be used for key exchange only. ECDH with >=256-bit keys is required for new code. ECDH-based key exchange must use one of the three NIST approved curves (P-256, P-384, or P521). Curves that have been thoroughly analyzed may be used only after a review with your organization's Crypto Board.
  • DSA- may be acceptable after review and approval from your organization's Crypto Board. Contact your security advisor to schedule your organization's Crypto Board review. If your use of DSA is approved, note that you will need to prohibit use of keys less than 2048 bits in length. CNG supports 2048-bit and greater key lengths as of Windows 8.
  • Diffie-Hellman- may be used for session key management only. Key length >= 2048 bits is required for new code. Existing code may support key lengths < 2048 bits only for backwards compatibility after a review by your organization's Crypto Board. Keys < 1024 bits may not be used.

    Use approved random number generators

    Title Details
    Component Web Application
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References N/A
    Steps

    Products must use approved random number generators. Pseudorandom functions such as the C runtime function rand, the .NET Framework class System.Random, or system functions such as GetTickCount must, therefore, never be used in such code. Use of the dual elliptic curve random number generator (DUAL_EC_DRBG) algorithm is prohibited

    • CNG- BCryptGenRandom(use of the BCRYPT_USE_SYSTEM_PREFERRED_RNG flag recommended unless the caller might run at any IRQL greater than 0 [that is, PASSIVE_LEVEL])
    • CAPI- cryptGenRandom
    • Win32/64- RtlGenRandom (new implementations should use BCryptGenRandom or CryptGenRandom) * rand_s * SystemPrng (for kernel mode)
    • .NET- RNGCryptoServiceProvider or RNGCng
    • Windows Store Apps- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom or .GenerateRandomNumber
    • Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
    • Apple OS X (<10.7)- Use /dev/random to retrieve random numbers
    • Java(including Google Android Java code)- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and update their applications to explicitly initialize the PRNG with entropy from /dev/urandom or /dev/random

    Do not use symmetric stream ciphers

    Title Details
    Component Web Application
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References N/A
    Steps Symmetric stream ciphers, such as RC4, must not be used. Instead of symmetric stream ciphers, products should use a block cipher, specifically AES with a key length of at least 128 bits.

    Use approved MAC/HMAC/keyed hash algorithms

    Title Details
    Component Web Application
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References N/A
    Steps

    Products must use only approved message authentication code (MAC) or hash-based message authentication code (HMAC) algorithms.

    A message authentication code (MAC) is a piece of information attached to a message that allows its recipient to verify both the authenticity of the sender and the integrity of the message using a secret key. The use of either a hash-based MAC (HMAC) or block-cipher-based MAC is permissible as long as all underlying hash or symmetric encryption algorithms are also approved for use; currently this includes the HMAC-SHA2 functions (HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512) and the CMAC/OMAC1 and OMAC2 block cipher-based MACs (these are based on AES).

    Use of HMAC-SHA1 may be permissible for platform compatibility, but you will be required to file an exception to this procedure and undergo your organization's Crypto review. Truncation of HMACs to less than 128 bits is not permitted. Using customer methods to hash a key and data is not approved, and must undergo your organization's Crypto Board review prior to use.

    Use only approved cryptographic hash functions

    Title Details
    Component Web Application
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References N/A
    Steps

    Products must use the SHA-2 family of hash algorithms (SHA256, SHA384, and SHA512). If a shorter hash is needed, such as a 128-bit output length in order to fit a data structure designed with the shorter MD5 hash in mind, product teams may truncate one of the SHA2 hashes (typically SHA256). Note that SHA384 is a truncated version of SHA512. Truncation of cryptographic hashes for security purposes to less than 128 bits is not permitted. New code must not use the MD2, MD4, MD5, SHA-0, SHA-1, or RIPEMD hash algorithms. Hash collisions are computationally feasible for these algorithms, which effectively breaks them.

    Allowed .NET hash algorithms for managed crypto agility (in order of preference):

    • SHA512Cng (FIPS compliant)
    • SHA384Cng (FIPS compliant)
    • SHA256Cng (FIPS compliant)
    • SHA512Managed (non-FIPS-compliant) (use SHA512 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
    • SHA384Managed (non-FIPS-compliant) (use SHA384 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
    • SHA256Managed (non-FIPS-compliant) (use SHA256 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
    • SHA512CryptoServiceProvider (FIPS compliant)
    • SHA256CryptoServiceProvider (FIPS compliant)
    • SHA384CryptoServiceProvider (FIPS compliant)

    Use strong encryption algorithms to encrypt data in the database

    Title Details
    Component Database
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References Choosing an encryption algorithm
    Steps Encryption algorithms define data transformations that cannot be easily reversed by unauthorized users. SQL Server allows administrators and developers to choose from among several algorithms, including DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES, and 256-bit AES

    SSIS packages should be encrypted and digitally signed

    Title Details
    Component Database
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References Identify the Source of Packages with Digital Signatures, Threat and Vulnerability Mitigation (Integration Services)
    Steps The source of a package is the individual or organization that created the package. Running a package from an unknown or untrusted source might be risky. To prevent unauthorized tampering of SSIS packages, digital signatures should be used. Also, to ensure the confidentiality of the packages during storage/transit, SSIS packages have to be encrypted

    Add digital signature to critical database securables

    Title Details
    Component Database
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References ADD SIGNATURE (Transact-SQL)
    Steps In cases where the integrity of a critical database securable has to be verified, digital signatures should be used. Database securables such as a stored procedure, function, assembly, or trigger can be digitally signed. Below is an example of when this can be useful: Let us say an ISV (Independent Software Vendor) has provided support to a software delivered to one of their customers. Before providing support, the ISV would want to ensure that a database securable in the software was not tampered either by mistake or by a malicious attempt. If the securable is digitally signed, the ISV can verify its digital signature and validate its integrity.

    Use SQL server EKM to protect encryption keys

    Title Details
    Component Database
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References SQL Server Extensible Key Management (EKM), Extensible Key Management Using Azure Key Vault (SQL Server)
    Steps SQL Server Extensible Key Management enables the encryption keys that protect the database files to be stored in an off-box device such as a smartcard, USB device, or EKM/HSM module. This also enables data protection from database administrators (except members of the sysadmin group). Data can be encrypted by using encryption keys that only the database user has access to on the external EKM/HSM module.

    Use AlwaysEncrypted feature if encryption keys should not be revealed to Database engine

    Title Details
    Component Database
    SDL Phase Build
    Applicable Technologies SQL Azure, OnPrem
    Attributes SQL Version - V12, MsSQL2016
    References Always Encrypted (Database Engine)
    Steps Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national/regional identification numbers (e.g. U.S. social security numbers), stored in Azure SQL Database or SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine (SQL Database or SQL Server). As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access)

    Store Cryptographic Keys securely on IoT Device

    Title Details
    Component IoT Device
    SDL Phase Build
    Applicable Technologies Generic
    Attributes Device OS - Windows IoT Core, Device Connectivity - Azure IoT device SDKs
    References TPM on Windows IoT Core, Set up TPM on Windows IoT Core, Azure IoT Device SDK TPM
    Steps Symmetric or Certificate Private keys securely in a hardware protected storage like TPM or Smart Card chips. Windows 10 IoT Core supports the user of a TPM and there are several compatible TPMs that can be used: Discrete TPM (dTPM). It is recommended to use a Firmware or Discrete TPM. A Software TPM should only be used for development and testing purposes. Once a TPM is available and the keys are provisioned in it, the code that generates the token should be written without hard coding any sensitive information in it.

    Example

    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);

    As can be seen, the device primary key is not present in the code. Instead, it is stored in the TPM at slot 0. TPM device generates a short-lived SAS token that is then used to connect to the IoT Hub.

    Generate a random symmetric key of sufficient length for authentication to IoT Hub

    Title Details
    Component IoT Cloud Gateway
    SDL Phase Build
    Applicable Technologies Generic
    Attributes Gateway choice - Azure IoT Hub
    References N/A
    Steps IoT Hub contains a device Identity Registry and while provisioning a device, automatically generates a random Symmetric key. It is recommended to use this feature of the Azure IoT Hub Identity Registry to generate the key used for authentication. IoT Hub also allows for a key to be specified while creating the device. If a key is generated outside of IoT Hub during device provisioning, it is recommended to create a random symmetric key or at least 256 bits.

    Ensure a device management policy is in place that requires a use PIN and allows remote wiping

    Title Details
    Component Dynamics CRM Mobile Client
    SDL Phase Deployment
    Applicable Technologies Generic
    Attributes N/A
    References N/A
    Steps Ensure a device management policy is in place that requires a use PIN and allows remote wiping

    Ensure a device management policy is in place that requires a PIN/password/auto lock and encrypts all data (e.g. BitLocker)

    Title Details
    Component Dynamics CRM Outlook Client
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References N/A
    Steps Ensure a device management policy is in place that requires a PIN/password/auto lock and encrypts all data (e.g. BitLocker)

    Ensure that signing keys are rolled over when using Identity Server

    Title Details
    Component Identity Server
    SDL Phase Deployment
    Applicable Technologies Generic
    Attributes N/A
    References Identity Server - Keys, Signatures and Cryptography
    Steps Ensure that signing keys are rolled over when using Identity Server. The link in the references section explains how this should be planned without causing outages to applications relying on Identity Server.

    Ensure that cryptographically strong client ID, client secret are used in Identity Server

    Title Details
    Component Identity Server
    SDL Phase Build
    Applicable Technologies Generic
    Attributes N/A
    References N/A
    Steps

    Ensure that cryptographically strong client ID, client secret are used in Identity Server. The following guidelines should be used while generating a client ID and secret:

    • Generate a random GUID as the client ID
    • Generate a cryptographically random 256-bit key as the secret