last sync: 2023-Feb-06 18:40:05 UTC

Azure Policy definition

Function apps should have 'Client Certificates (Incoming client certificates)' enabled

Name Function apps should have 'Client Certificates (Incoming client certificates)' enabled
Azure Portal
Id eaebaea7-8013-4ceb-9d14-7eb32271373c
Version 3.0.0
details on versioning
Category App Service
Microsoft docs
Description Client certificates allow for the app to request a certificate for incoming requests. Only clients with valid certificates will be able to reach the app.
Mode Indexed
Type BuiltIn
Preview FALSE
Deprecated FALSE
Effect Default
Audit
Allowed
Audit, Disabled
RBAC
Role(s)
none
Rule
Aliases
IF (1)
Alias Namespace ResourceType DefaultPath Modifiable
Microsoft.Web/sites/clientCertEnabled Microsoft.Web sites properties.clientCertEnabled false
Rule
ResourceTypes
IF (1)
Microsoft.Web/sites
Compliance The following 20 compliance controls are associated with this Policy definition 'Function apps should have 'Client Certificates (Incoming client certificates)' enabled' (eaebaea7-8013-4ceb-9d14-7eb32271373c)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v2.0 PV-2 Azure_Security_Benchmark_v2.0_PV-2 Azure Security Benchmark PV-2 Posture and Vulnerability Management Sustain secure configurations for Azure services Customer Use Azure Security Center to monitor your configuration baseline and use Azure Policy [deny] and [deploy if not exist] rule to enforce secure configuration across Azure compute resources, including VMs, containers, and others. Understand Azure Policy effects: https://docs.microsoft.com/azure/governance/policy/concepts/effects Create and manage policies to enforce compliance: https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage n/a link 19
Azure_Security_Benchmark_v3.0 PV-2 Azure_Security_Benchmark_v3.0_PV-2 Azure Security Benchmark PV-2 Posture and Vulnerability Management Audit and enforce secure configurations Shared **Security Principle:** Continuously monitor and alert when there is a deviation from the defined configuration baseline. Enforce the desired configuration according to the baseline configuration by denying the non-compliant configuration or deploy a configuration. **Azure Guidance:** Use Microsoft Defender for Cloud to configure Azure Policy to audit and enforce configurations of your Azure resources. Use Azure Monitor to create alerts when there is a configuration deviation detected on the resources. Use Azure Policy [deny] and [deploy if not exist] rule to enforce secure configuration across Azure resources. For resource configuration audit and enforcement not supported by Azure Policy, you may need to write your own scripts or use third-party tooling to implement the configuration audit and enforcement. **Implementation and additional context:** Understand Azure Policy effects: https://docs.microsoft.com/azure/governance/policy/concepts/effects Create and manage policies to enforce compliance: https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage Get compliance data of Azure resources: https://docs.microsoft.com/azure/governance/policy/how-to/get-compliance-data n/a link 24
CIS_Azure_1.1.0 9.4 CIS_Azure_1.1.0_9.4 CIS Microsoft Azure Foundations Benchmark recommendation 9.4 9 AppService Ensure the web app has 'Client Certificates (Incoming client certificates)' set to 'On' Shared The customer is responsible for implementing this recommendation. Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app. link 3
CIS_Azure_1.3.0 9.4 CIS_Azure_1.3.0_9.4 CIS Microsoft Azure Foundations Benchmark recommendation 9.4 9 AppService Ensure the web app has 'Client Certificates (Incoming client certificates)' set to 'On' Shared The customer is responsible for implementing this recommendation. Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app. link 3
CIS_Azure_1.4.0 9.4 CIS_Azure_1.4.0_9.4 CIS Microsoft Azure Foundations Benchmark recommendation 9.4 9 AppService Ensure the web app has 'Client Certificates (Incoming client certificates)' set to 'On' Shared The customer is responsible for implementing this recommendation. Client certificates allow for the app to request a certificate for incoming requests. Only clients that have a valid certificate will be able to reach the app. link 3
CMMC_2.0_L2 CM.L2-3.4.1 CMMC_2.0_L2_CM.L2-3.4.1 404 not found n/a n/a 25
CMMC_2.0_L2 CM.L2-3.4.2 CMMC_2.0_L2_CM.L2-3.4.2 404 not found n/a n/a 27
FedRAMP_High_R4 CM-6 FedRAMP_High_R4_CM-6 FedRAMP High CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
FedRAMP_Moderate_R4 CM-6 FedRAMP_Moderate_R4_CM-6 FedRAMP Moderate CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
NIST_SP_800-171_R2_3 .4.1 NIST_SP_800-171_R2_3.4.1 NIST SP 800-171 R2 3.4.1 Configuration Management Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. Shared Microsoft and the customer share responsibilities for implementing this requirement. Baseline configurations are documented, formally reviewed, and agreed-upon specifications for systems or configuration items within those systems. Baseline configurations serve as a basis for future builds, releases, and changes to systems. Baseline configurations include information about system components (e.g., standard software packages installed on workstations, notebook computers, servers, network components, or mobile devices; current version numbers and update and patch information on operating systems and applications; and configuration settings and parameters), network topology, and the logical placement of those components within the system architecture. Baseline configurations of systems also reflect the current enterprise architecture. Maintaining effective baseline configurations requires creating new baselines as organizational systems change over time. Baseline configuration maintenance includes reviewing and updating the baseline configuration when changes are made based on security risks and deviations from the established baseline configuration. Organizations can implement centralized system component inventories that include components from multiple organizational systems. In such situations, organizations ensure that the resulting inventories include system-specific information required for proper component accountability (e.g., system association, system owner). Information deemed necessary for effective accountability of system components includes hardware inventory specifications, software license information, software version numbers, component owners, and for networked components or devices, machine names and network addresses. Inventory specifications include manufacturer, device type, model, serial number, and physical location. [SP 800-128] provides guidance on security-focused configuration management. link 31
NIST_SP_800-171_R2_3 .4.2 NIST_SP_800-171_R2_3.4.2 NIST SP 800-171 R2 3.4.2 Configuration Management Establish and enforce security configuration settings for information technology products employed in organizational systems. Shared Microsoft and the customer share responsibilities for implementing this requirement. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture or functionality of the system. Information technology products for which security-related configuration settings can be defined include mainframe computers, servers, workstations, input and output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security parameters are those parameters impacting the security state of systems including the parameters required to satisfy other security requirements. Security parameters include: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. [SP 800-70] and [SP 800-128] provide guidance on security configuration settings. link 25
NIST_SP_800-53_R4 CM-6 NIST_SP_800-53_R4_CM-6 NIST SP 800-53 Rev. 4 CM-6 Configuration Management Configuration Settings Shared n/a The organization: a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements; b. Implements the configuration settings; c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4. References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. link 23
NIST_SP_800-53_R5 CM-6 NIST_SP_800-53_R5_CM-6 NIST SP 800-53 Rev. 5 CM-6 Configuration Management Configuration Settings Shared n/a a. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations]; b. Implement the configuration settings; c. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components] based on [Assignment: organization-defined operational requirements]; and d. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures. link 23
NZ_ISM_v3.5 SS-9 NZ_ISM_v3.5_SS-9 NZISM Security Benchmark SS-9 Software security 14.5.8 Web applications Customer n/a The Open Web Application Security Project guide provides a comprehensive resource to consult when developing Web applications. link 17
RBI_CSF_Banks_v2016 13.1 RBI_CSF_Banks_v2016_13.1 Advanced Real-Timethreat Defenceand Management Advanced Real-Timethreat Defenceand Management-13.1 n/a Build a robust defence against the installation, spread, and execution of malicious code at multiple points in the enterprise. 27
RBI_ITF_NBFC_v2017 3.1.b RBI_ITF_NBFC_v2017_3.1.b RBI IT Framework 3.1.b Information and Cyber Security Segregation of Functions-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Segregation of functions: There should be segregation of the duties of the Security Officer/Group (both physical security as well as cyber security) dealing exclusively with information systems security and the Information Technology division which actually implements the computer systems. The information security function should be adequately resourced in terms of the number of staff, level of skill and tools or techniques like risk assessment, security architecture, vulnerability assessment, forensic assessment, etc. Further, there should be a clear segregation of responsibilities relating to system administration, database administration and transaction processing. link 6
RBI_ITF_NBFC_v2017 3.8 RBI_ITF_NBFC_v2017_3.8 RBI IT Framework 3.8 Information and Cyber Security Digital Signatures-3.8 n/a A Digital Signature Certificate authenticates entity???s identity electronically. It also provides a high level of security for online transactions by ensuring absolute privacy of the information exchanged using a Digital Signature Certificate. NBFCs may consider use of Digital signatures to protect the authenticity and integrity of important electronic documents and also for high value fund transfer. link 7
RMiT_v1.0 10.20 RMiT_v1.0_10.20 RMiT 10.20 Cryptography Cryptography - 10.20 Shared n/a A financial institution shall store public cryptographic keys in a certificate issued by a certificate authority as appropriate to the level of risk. Such certificates associated with customers shall be issued by recognised certificate authorities. The financial institution must ensure that the implementation of authentication and signature protocols using such certificates are subject to strong protection to ensure that the use of private cryptographic keys corresponding to the user certificates are legally binding and irrefutable. The initial issuance and subsequent renewal of such certificates must be consistent with industry best practices and applicable legal/regulatory specifications. link 2
SOC_2 CC6.8 SOC_2_CC6.8 SOC 2 Type 2 CC6.8 Logical and Physical Access Controls Prevent or detect against unauthorized or malicious software Shared The customer is responsible for implementing this recommendation. Restricts Application and Software Installation — The ability to install applications and software is restricted to authorized individuals. • Detects Unauthorized Changes to Software and Configuration Parameters — Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software. • Uses a Defined Change Control Process — A management-defined change control process is used for the implementation of software. • Uses Antivirus and Anti-Malware Software — Antivirus and anti-malware software is implemented and maintained to provide for the interception or detection and remediation of malware. • Scans Information Assets from Outside the Entity for Malware and Other Unauthorized Software — Procedures are in place to scan information assets that have been transferred or returned to the entity’s custody for malware and other unauthorized software and to remove any items detected prior to its implementation on the network. 54
SOC_2 CC8.1 SOC_2_CC8.1 SOC 2 Type 2 CC8.1 Change Management Changes to infrastructure, data, and software Shared The customer is responsible for implementing this recommendation. Manages Changes Throughout the System Life Cycle — A process for managing system changes throughout the life cycle of the system and its components (infrastructure, data, software, and procedures) is used to support system availability and processing integrity. • Authorizes Changes — A process is in place to authorize system changes prior to development. • Designs and Develops Changes — A process is in place to design and develop system changes. • Documents Changes — A process is in place to document system changes to support ongoing maintenance of the system and to support system users in performing their responsibilities. • Tracks System Changes — A process is in place to track system changes prior to implementation. • Configures Software — A process is in place to select and implement the configuration parameters used to control the functionality of software. • Tests System Changes — A process is in place to test system changes prior to implementation. • Approves System Changes — A process is in place to approve system changes prior to implementation. • Deploys System Changes — A process is in place to implement system changes. • Identifies and Evaluates System Changes — Objectives affected by system changes are identified and the ability of the modified system to meet the objectives is evaluated throughout the system development life cycle. • Identifies Changes in Infrastructure, Data, Software, and Procedures Required to Remediate Incidents — Changes in infrastructure, data, software, and procedures required to remediate incidents to continue to meet objectives are identified and the change process is initiated upon identification. • Creates Baseline Configuration of IT Technology — A baseline configuration of IT and control systems is created and maintained. • Provides for Changes Necessary in Emergency Situations — A process is in place for authorizing, designing, testing, approving, and implementing changes necessary in emergency situations (that is, changes that need to be implemented in an urgent time frame). Additional points of focus that apply only in an engagement using the trust services criteria for confidentiality: • Protects Confidential Information — The entity protects confidential information during system design, development, testing, implementation, and change processes to meet the entity’s objectives related to confidentiality. Additional points of focus that apply only in an engagement using the trust services criteria for privacy: • Protects Personal Information — The entity protects personal information during system design, development, testing, implementation, and change processes to meet the entity’s objectives related to privacy. 53
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-09-19 17:41:40 change Major (2.0.0 > 3.0.0)
2022-07-01 16:32:34 change Major (1.0.1 > 2.0.0)
2020-12-11 15:42:52 change Patch (1.0.0 > 1.0.1) *changes on text case sensitivity are not tracked
2019-11-12 19:11:12 add eaebaea7-8013-4ceb-9d14-7eb32271373c
Initiatives
usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Deprecated]: Azure Security Benchmark v2 bb522ac1-bc39-4957-b194-429bcd3bcb0b Regulatory Compliance Deprecated BuiltIn
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for Banks d0d5578d-cc08-2b22-31e3-f525374f235a Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for NBFC 7f89f09c-48c1-f28d-1bd5-84f3fb22f86c Regulatory Compliance Preview BuiltIn
Azure Security Benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
RMIT Malaysia 97a6d4f1-3bed-4cf4-ac5b-0e444c0408d6 Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
JSON
changes

JSON