| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1640 - Transmission Confidentiality And Integrity | ||
| Id | 05a289ce-6a20-4b75-a0f3-dc8601b6acd0 | ||
| Version | 1.0.0 Details on versioning |
||
| Versioning |
Versions supported for Versioning: 0 Built-in Versioning [Preview] |
||
| Category | Regulatory Compliance Microsoft Learn |
||
| Description | Microsoft implements this System and Communications Protection control | ||
| Additional metadata |
Name/Id: ACF1640 / Microsoft Managed Control 1640 Category: System and Communications Protection Title: Transmission Confidentiality And Integrity Ownership: Customer, Microsoft Description: The information system protects the Confidentiality and integrity of transmitted information. Requirements: Azure services always use secure transport such as TLS or HTTPS. Encryption in transport is addressed by the transport protocol. Azure implements the transmission integrity and confidentiality control by ensuring that cryptography is implemented through a hybrid model. The following is a high-level list of the symmetric and asymmetric keys used for encrypting and protecting confidentiality of data. * AES for symmetric encryption/decryption * 128-bit or better symmetric keys * RSA for asymmetric encryption/decryption and signatures * 2048-bit or better RSA keys * SHA-256 or better (SHA-384, SHA-512) for hashing and message-authentication codes Azure implements cryptography in numerous ways. Communications between the Azure service and the Azure Management Portal are configured to accept FIPS 140-2 validated encryption. Azure enforces communications between Azure internal components to be protected with self-signed SSL certificates. Hardware Security Modules used by Azure Key Vault employ FIPS 140-2 validated encryption. Azure requires that data is classified according to sensitivity (LBI, MBI, or HBI), and the owner of the data is responsible for following the Asset Classification Standard and Asset Protection Standard for encrypting data according to its classification. Secrets are communicated through the Azure Management Portal and API over a secure TLS 1.2 channel. Both the SMAPI and the Azure Management Portal are only accessible over HTTPS. Service certificates, RDP passwords, and Storage Account Keys (SAKs) are stored in an encrypted format. Azure utilizes FIPS 140-2 Cryptographic Module Verification Program (CMVP) validated modules for areas requiring encryption. HMAC is keyed hash function for message authentication (RFC 2104). It makes use of an underlying hash function (MD5, SHA-1 or SHA-2) and a secret key of a specified length. The strength of an HMAC relies on the strength of the underlying hash function, and the length of the secret. * A SHA-2 hash is required for new code. * SHA-1 is permissible in existing code only for backwards compatibility and after review by the Crypto Board. * MAC3DES is permissible for managed code only since this is the only FIPS-compliant keyed hash algorithm for .NET currently available. A Crypto Board review is required for such usage. * Other hash functions, including MD2, MD4 or MD5 are not permitted, and must be replaced in existing code. All approved keyed hash algorithms are members of the HMAC family. HMAC is a mechanism for constructing a keyed hash algorithm using an underlying hash algorithm. For projects utilizing keyed hash algorithms, the following hash functions must be used within the HMAC mechanism. Note that hash function agility (the ability to switch to another hash function without patching the code) is part of the “Implement Crypto Agility” requirement. No new code should use the MD4 or MD5 hash algorithms as hash collisions have been demonstrated for both algorithms. SHA1 is being deprecated. Continued use of SHA-1 is permissible in existing code only for backwards compatibility and, as described below, for new code running on certain down-level platforms. A SHA-2 hash is currently the only recommended hash function. The SHA-2 hash functions are available in managed code, and in unmanaged code targeting Windows Server 2003 SP1 and later versions of Windows. For new managed code, use of a SHA-2 hash function is required. SHA-1 is permissible in existing code only for backwards compatibility. Such usage requires Crypto Board review. All other hash functions, including MD2, MD4 or MD5 must not be used, and must be replaced in existing code. For unmanaged code, use of a SHA-2 hash function is required. In order to access the Azure environment via network connection, a user must authenticate with their Azure domain credentials. Azure provides access through smart-card-enabled Jumpboxesand SSL VPN servers when establishing access connections into the Azure environments. Users must have a valid smart card, and valid Azure domain accounts to establish a remote access session. Jumpboxesand SSL VPN servers are configured to use the FIPS 140-2 encryption setting, specifically TLS 1.2. The use of FIPS 140-2 validated cryptography is used by Azure to support compliance with federal laws, executive orders, directives, policies, regulations, standards, and guidance. FIPS 140-2 encryption is required for digital media physically transported, electronically transmitted over Azure via TLS, and for authentication for Windows-based authentication and SSH authentication to network devices. Encrypted data may transit across the Azure environment, but the network devices are agnostic as to the type of data being transmitted. Azure relies on extensive physical security to protect all the end to end communications inside datacenters. |
||
| Mode | Indexed | ||
| Type | Static | ||
| Preview | False | ||
| Deprecated | False | ||
| Effect | Fixed audit |
||
| RBAC role(s) | none | ||
| Rule aliases | none | ||
| Rule resource types | IF (2) Microsoft.Resources/subscriptions Microsoft.Resources/subscriptions/resourceGroups |
||
| Compliance | Not a Compliance control | ||
| Initiatives usage | none | ||
| History | none | ||
| JSON compare | n/a | ||
| JSON |
|