compliance controls are associated with this Policy definition 'Function apps should use latest 'HTTP Version'' (e2c1c086-2d84-4019-bff3-c44ccd95113c)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
|
C.04.3 - Technical vulnerabilities |
C.04.3 - Technical vulnerabilities |
404 not found |
|
|
|
n/a |
n/a |
|
26 |
|
C.04.3 - Timelines |
C.04.3 - Timelines |
404 not found |
|
|
|
n/a |
n/a |
|
20 |
|
C.04.6 - Technical vulnerabilities |
C.04.6 - Technical vulnerabilities |
404 not found |
|
|
|
n/a |
n/a |
|
27 |
|
C.04.6 - Timelines |
C.04.6 - Timelines |
404 not found |
|
|
|
n/a |
n/a |
|
20 |
|
C.04.7 - Evaluated |
C.04.7 - Evaluated |
404 not found |
|
|
|
n/a |
n/a |
|
55 |
| CIS_Azure_1.1.0 |
9.10 |
CIS_Azure_1.1.0_9.10 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.10 |
9 AppService |
Ensure that 'HTTP Version' is the latest, if used to run the web app |
Shared |
The customer is responsible for implementing this recommendation. |
Periodically, newer versions are released for HTTP either due to security flaws or to include additional functionality. Using the latest HTTP version for web apps to take advantage of security fixes, if any, and/or new functionalities of the newer version. |
link |
3 |
| CIS_Azure_1.3.0 |
9.9 |
CIS_Azure_1.3.0_9.9 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.9 |
9 AppService |
Ensure that 'HTTP Version' is the latest, if used to run the web app |
Shared |
The customer is responsible for implementing this recommendation. |
Periodically, newer versions are released for HTTP either due to security flaws or to include additional functionality. Using the latest HTTP version for web apps to take advantage of security fixes, if any, and/or new functionalities of the newer version. |
link |
3 |
| CIS_Azure_1.4.0 |
9.9 |
CIS_Azure_1.4.0_9.9 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.9 |
9 AppService |
Ensure that 'HTTP Version' is the Latest, if Used to Run the Web App |
Shared |
The customer is responsible for implementing this recommendation. |
Periodically, newer versions are released for HTTP either due to security flaws or to include additional functionality. Using the latest HTTP version for web apps to take advantage of security fixes, if any, and/or new functionalities of the newer version. |
link |
3 |
| CIS_Azure_2.0.0 |
9.9 |
CIS_Azure_2.0.0_9.9 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.9 |
9 |
Ensure that 'HTTP Version' is the Latest, if Used to Run the Web App |
Shared |
n/a |
Periodically, newer versions are released for HTTP either due to security flaws or to include additional functionality. Using the latest HTTP version for web apps to take advantage of security fixes, if any, and/or new functionalities of the newer version.
Newer versions may contain security enhancements and additional functionality. Using the latest version is recommended in order to take advantage of enhancements and new capabilities. With each software installation, organizations need to determine if a given update meets their requirements. They must also verify the compatibility and support provided for any additional software against the update revision that is selected.
HTTP 2.0 has additional performance improvements on the head-of-line blocking problem of old HTTP version, header compression, and prioritization of requests. HTTP 2.0 no longer supports HTTP 1.1's chunked transfer encoding mechanism, as it provides its own, more efficient, mechanisms for data streaming. |
link |
3 |
| CIS_Azure_Foundations_v2.1.0 |
9.8 |
CIS_Azure_Foundations_v2.1.0_9.8 |
CIS Azure Foundations v2.1.0 9.8 |
AppService |
Ensure that 'HTTP Version' is the Latest, if Used to Run the Web App |
Shared |
n/a |
Ensure that 'HTTP Version' is the Latest, if Used to Run the Web App. |
|
2 |
| CIS_Azure_Foundations_v3.0.0 |
9.10 |
CIS_Azure_Foundations_v3.0.0_9.10 |
CIS Azure Foundations v3.0.0 9.10 |
9 |
Ensure that 'HTTP20enabled' is set to 'true' (if in use) |
Shared |
n/a |
Verify that the 'HTTP20enabled' setting is configured to 'true' for applicable Azure resources. This control is essential for ensuring that applications leverage the benefits of HTTP/2, including improved performance and security features. |
|
2 |
| CIS_Controls_v8.1 |
2.2 |
CIS_Controls_v8.1_2.2 |
CIS Controls v8.1 2.2 |
Inventory and Control of Software Assets |
Ensure authorized software is currently supported |
Shared |
1. Ensure that only currently supported software is designated as authorized in the software inventory for enterprise assets.
2. If software is unsupported, yet necessary for the fulfilment of the enterprise’s mission, document an exception detailing mitigating controls and residual risk acceptance.
3. For any unsupported software without an exception documentation, designate as unauthorized.
4. Review the software list to verify software support at least monthly, or more frequently. |
To ensure that only currently supported software is designated as authorized in the software inventory for enterprise assets. |
|
2 |
| CIS_Controls_v8.1 |
4.1 |
CIS_Controls_v8.1_4.1 |
CIS Controls v8.1 4.1 |
Secure Configuration of Enterprise Assets and Software |
Establish and maintain a secure configuration process. |
Shared |
1. Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile; non-computing/IoT devices; and servers) and software (operating systems and applications).
2. Review and update documentation annually, or when significant enterprise changes occur that could impact this safeguard. |
To ensure data integrity and safety of enterprise assets. |
|
44 |
| CMMC_2.0_L2 |
SI.L1-3.14.1 |
CMMC_2.0_L2_SI.L1-3.14.1 |
404 not found |
|
|
|
n/a |
n/a |
|
14 |
| CMMC_L3 |
SI.1.210 |
CMMC_L3_SI.1.210 |
CMMC L3 SI.1.210 |
System and Information Integrity |
Identify, report, and correct information and information system flaws in a timely manner. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Organizations identify systems that are affected by announced software and firmware flaws including potential vulnerabilities resulting from those flaws and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations can take advantage of available resources such as the Common Weakness Enumeration (CWE) database or Common Vulnerabilities and Exposures (CVE) database in remediating flaws discovered in organizational systems.
Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types of remediation. |
link |
7 |
| EU_GDPR_2016_679_Art. |
24 |
EU_GDPR_2016_679_Art._24 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 24 |
Chapter 4 - Controller and processor |
Responsibility of the controller |
Shared |
n/a |
n/a |
|
306 |
| EU_GDPR_2016_679_Art. |
25 |
EU_GDPR_2016_679_Art._25 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 25 |
Chapter 4 - Controller and processor |
Data protection by design and by default |
Shared |
n/a |
n/a |
|
306 |
| EU_GDPR_2016_679_Art. |
28 |
EU_GDPR_2016_679_Art._28 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 28 |
Chapter 4 - Controller and processor |
Processor |
Shared |
n/a |
n/a |
|
306 |
| EU_GDPR_2016_679_Art. |
32 |
EU_GDPR_2016_679_Art._32 |
EU General Data Protection Regulation (GDPR) 2016/679 Art. 32 |
Chapter 4 - Controller and processor |
Security of processing |
Shared |
n/a |
n/a |
|
306 |
| FedRAMP_High_R4 |
SI-2 |
FedRAMP_High_R4_SI-2 |
FedRAMP High SI-2 |
System And Information Integrity |
Flaw Remediation |
Shared |
n/a |
The organization:
a. Identifies, reports, and corrects information system flaws;
b. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
c. Installs security-relevant software and firmware updates within [Assignment: organization- defined time period] of the release of the updates; and
d. Incorporates flaw remediation into the organizational configuration management process.
Supplemental Guidance: Organizations identify information systems affected by announced software flaws including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security responsibilities. Security-relevant software updates include, for example, patches, service packs, hot fixes, and anti-virus signatures. Organizations also address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By incorporating flaw remediation into ongoing configuration management processes, required/anticipated remediation actions can be tracked and verified. Flaw remediation actions that can be tracked and verified include, for example, determining whether organizations follow US-CERT guidance and Information Assurance Vulnerability Alerts. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types. Organizations determine the degree and type of testing needed for the specific type of flaw remediation activity under consideration and also the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software and/or firmware updates is not necessary or practical,
for example, when implementing simple anti-virus signature updates. Organizations may also consider in testing decisions, whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. Related controls: CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11. |
link |
15 |
| FedRAMP_Moderate_R4 |
SI-2 |
FedRAMP_Moderate_R4_SI-2 |
FedRAMP Moderate SI-2 |
System And Information Integrity |
Flaw Remediation |
Shared |
n/a |
The organization:
a. Identifies, reports, and corrects information system flaws;
b. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
c. Installs security-relevant software and firmware updates within [Assignment: organization- defined time period] of the release of the updates; and
d. Incorporates flaw remediation into the organizational configuration management process.
Supplemental Guidance: Organizations identify information systems affected by announced software flaws including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security responsibilities. Security-relevant software updates include, for example, patches, service packs, hot fixes, and anti-virus signatures. Organizations also address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By incorporating flaw remediation into ongoing configuration management processes, required/anticipated remediation actions can be tracked and verified. Flaw remediation actions that can be tracked and verified include, for example, determining whether organizations follow US-CERT guidance and Information Assurance Vulnerability Alerts. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types. Organizations determine the degree and type of testing needed for the specific type of flaw remediation activity under consideration and also the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software and/or firmware updates is not necessary or practical,
for example, when implementing simple anti-virus signature updates. Organizations may also consider in testing decisions, whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. Related controls: CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11. |
link |
15 |
| K_ISMS_P_2018 |
2.10.1 |
K_ISMS_P_2018_2.10.1 |
K ISMS P 2018 2.10.1 |
2.10 |
Establish Procedures for Managing the Security of System Operations |
Shared |
n/a |
Establish and implement operating procedures for managing the security of system operations such as designating system administrators, updating policies, changing rulesets, monitoring events, managing policy implementations or exceptions. |
|
408 |
| K_ISMS_P_2018 |
2.10.2 |
K_ISMS_P_2018_2.10.2 |
K ISMS P 2018 2.10.2 |
2.10 |
Establish Protective Measures for Administrator Privileges and Security Configurations |
Shared |
n/a |
Establish and implement protective measures with regard to administrator privileges and security configurations to ensure that important information and personal information are not exposed as a result of unauthorized access by service type or misconfigurations. |
|
385 |
|
mp.s.3 Protection of web browsing |
mp.s.3 Protection of web browsing |
404 not found |
|
|
|
n/a |
n/a |
|
51 |
| New_Zealand_ISM |
14.5.8.C.01 |
New_Zealand_ISM_14.5.8.C.01 |
New_Zealand_ISM_14.5.8.C.01 |
14. Software security |
14.5.8.C.01 Web applications |
|
n/a |
Agencies SHOULD follow the documentation provided in the Open Web Application Security Project guide to building secure Web applications and Web services. |
|
18 |
| NIST_SP_800-171_R2_3 |
.14.1 |
NIST_SP_800-171_R2_3.14.1 |
NIST SP 800-171 R2 3.14.1 |
System and Information Integrity |
Identify, report, and correct system flaws in a timely manner. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Organizations identify systems that are affected by announced software and firmware flaws including potential vulnerabilities resulting from those flaws and report this information to designated personnel with information security responsibilities. Security-relevant updates include patches, service packs, hot fixes, and anti-virus signatures. Organizations address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations can take advantage of available resources such as the Common Weakness Enumeration (CWE) database or Common Vulnerabilities and Exposures (CVE) database in remediating flaws discovered in organizational systems. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types of remediation. [SP 800-40] provides guidance on patch management technologies. |
link |
17 |
| NIST_SP_800-53_R4 |
SI-2 |
NIST_SP_800-53_R4_SI-2 |
NIST SP 800-53 Rev. 4 SI-2 |
System And Information Integrity |
Flaw Remediation |
Shared |
n/a |
The organization:
a. Identifies, reports, and corrects information system flaws;
b. Tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
c. Installs security-relevant software and firmware updates within [Assignment: organization- defined time period] of the release of the updates; and
d. Incorporates flaw remediation into the organizational configuration management process.
Supplemental Guidance: Organizations identify information systems affected by announced software flaws including potential vulnerabilities resulting from those flaws, and report this information to designated organizational personnel with information security responsibilities. Security-relevant software updates include, for example, patches, service packs, hot fixes, and anti-virus signatures. Organizations also address flaws discovered during security assessments, continuous monitoring, incident response activities, and system error handling. Organizations take advantage of available resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By incorporating flaw remediation into ongoing configuration management processes, required/anticipated remediation actions can be tracked and verified. Flaw remediation actions that can be tracked and verified include, for example, determining whether organizations follow US-CERT guidance and Information Assurance Vulnerability Alerts. Organization-defined time periods for updating security-relevant software and firmware may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). Some types of flaw remediation may require more testing than other types. Organizations determine the degree and type of testing needed for the specific type of flaw remediation activity under consideration and also the types of changes that are to be configuration-managed. In some situations, organizations may determine that the testing of software and/or firmware updates is not necessary or practical,
for example, when implementing simple anti-virus signature updates. Organizations may also consider in testing decisions, whether security-relevant software or firmware updates are obtained from authorized sources with appropriate digital signatures. Related controls: CA-2, CA-7, CM-3, CM-5, CM-8, MA-2, IR-4, RA-5, SA-10, SA-11, SI-11. |
link |
15 |
| NIST_SP_800-53_R4 |
SI-2(6) |
NIST_SP_800-53_R4_SI-2(6) |
NIST SP 800-53 Rev. 4 SI-2 (6) |
System and Information Integrity |
Removal of Previous Versions of Software / Firmware |
Customer |
n/a |
The organization removes [Assignment: organization-defined software and firmware components] after updated versions have been installed. |
link |
3 |
| NIST_SP_800-53_R5 |
SI-2 |
NIST_SP_800-53_R5_SI-2 |
NIST SP 800-53 Rev. 5 SI-2 |
System and Information Integrity |
Flaw Remediation |
Shared |
n/a |
a. Identify, report, and correct system flaws;
b. Test software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation;
c. Install security-relevant software and firmware updates within [Assignment: organization-defined time period] of the release of the updates; and
d. Incorporate flaw remediation into the organizational configuration management process. |
link |
15 |
| NIST_SP_800-53_R5 |
SI-2(6) |
NIST_SP_800-53_R5_SI-2(6) |
NIST SP 800-53 Rev. 5 SI-2 (6) |
System and Information Integrity |
Removal of Previous Versions of Software and Firmware |
Customer |
n/a |
Remove previous versions of [Assignment: organization-defined software and firmware components] after updated versions have been installed. |
link |
3 |
| 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 |
12 |
| RMiT_v1.0 |
Appendix_5.3 |
RMiT_v1.0_Appendix_5.3 |
RMiT Appendix 5.3 |
Control Measures on Cybersecurity |
Control Measures on Cybersecurity - Appendix 5.3 |
Customer |
n/a |
Update security standards and protocols for web services encryption regularly. Disable support of weak ciphers and protocol in web-facing applications. |
link |
7 |
| 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. |
|
47 |
| 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. |
|
52 |
|
U.09.3 - Detection, prevention and recovery |
U.09.3 - Detection, prevention and recovery |
404 not found |
|
|
|
n/a |
n/a |
|
29 |