AzPolicyAdvertizer

last sync: 2025-Apr-29 17:16:02 UTC

Microsoft Managed Control 1640 - Transmission Confidentiality And Integrity | Regulatory Compliance - System and Communications Protection

Azure BuiltIn Policy definition

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
Cloud environments AzureCloud = true
AzureUSGovernment = true
AzureChinaCloud = unknown
Available in AzUSGov The Policy is available in AzureUSGovernment cloud. Version: '1.0.0'
Repository: Azure-Policy 05a289ce-6a20-4b75-a0f3-dc8601b6acd0
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)
Compliance
The following 2 compliance controls are associated with this Policy definition 'Microsoft Managed Control 1640 - Transmission Confidentiality And Integrity' (05a289ce-6a20-4b75-a0f3-dc8601b6acd0)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
NIS2 AM._Asset_Management_9 NIS2_AM._Asset_Management_9 NIS2_AM._Asset_Management_9 AM. Asset Management Human resources security, access control policies and asset management n/a The cybersecurity risk-management measures should therefore also address the physical and environmental security of network and information systems by including measures to protect such systems from system failures, human error, malicious acts or natural phenomena, in line with European and international standards, such as those included in the ISO/IEC 27000 series. In that regard, essential and important entities should, as part of their cybersecurity risk-management measures, also address human resources security and have in place appropriate access control policies. Those measures should be consistent with Directive (EU) 2022/2557. 28
NIS2 DP._Data_Protection_8 NIS2_DP._Data_Protection_8 NIS2_DP._Data_Protection_8 DP. Data Protection Policies and procedures regarding the use of cryptography and, where appropriate, encryption n/a In order to safeguard the security of public electronic communications networks and publicly available electronic communications services, the use of encryption technologies, in particular end-to-end encryption as well as data-centric security concepts, such as cartography, segmentation, tagging, access policy and access management, and automated access decisions, should be promoted. Where necessary, the use of encryption, in particular end-to-end encryption should be mandatory for providers of public electronic communications networks or of publicly available electronic communications services in accordance with the principles of security and privacy by default and by design for the purposes of this Directive. The use of end-to-end encryption should be reconciled with the Member States’ powers to ensure the protection of their essential security interests and public security, and to allow for the prevention, investigation, detection and prosecution of criminal offences in accordance with Union law. However, this should not weaken end-to-end encryption, which is a critical technology for the effective protection of data and privacy and the security of communications. 32
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type polSet in AzUSGov
[Preview]: NIS2 32ff9e30-4725-4ca7-ba3a-904a7721ee87 Regulatory Compliance Preview BuiltIn unknown
History none
JSON compare n/a
JSON
api-version=2021-06-01
EPAC