Security Frame: Cryptography | Mitigation
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:
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)
Please note that none of these algorithms can be specified via the |
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.
|
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
|
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):
|
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:
|