compliance controls are associated with this Policy definition 'System updates on virtual machine scale sets should be installed' (c3f317a7-a95c-4547-b7e7-11017ebdf2fe)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| AU_ISM |
1407 |
AU_ISM_1407 |
AU ISM 1407 |
Guidelines for System Hardening - Operating system hardening |
Operating system versions - 1407 |
|
n/a |
The latest version (N), or N-1 version, of an operating system is used for SOEs. |
link |
2 |
| Azure_Security_Benchmark_v1.0 |
5.2 |
Azure_Security_Benchmark_v1.0_5.2 |
Azure Security Benchmark 5.2 |
Vulnerability Management |
Deploy automated operating system patch management solution |
Customer |
Use Azure "Update Management" to ensure the most recent security updates are installed on your Windows and Linux VMs. For Windows VMs, ensure Windows Update has been enabled and set to update automatically.
How to configure Update Management for virtual machines in Azure:
https://docs.microsoft.com/azure/automation/automation-update-management
Understand Azure security policies monitored by Security Center:
https://docs.microsoft.com/azure/security-center/security-center-policy-definitions |
n/a |
link |
2 |
| Azure_Security_Benchmark_v2.0 |
PV-7 |
Azure_Security_Benchmark_v2.0_PV-7 |
Azure Security Benchmark PV-7 |
Posture and Vulnerability Management |
Rapidly and automatically remediate software vulnerabilities |
Customer |
Rapidly deploy software updates to remediate software vulnerabilities in operating systems and applications.
Use a common risk scoring program (for example, Common Vulnerability Scoring System) or the default risk ratings provided by your third-party scanning tool and tailor to your environment, taking into account which applications present a high security risk and which ones require high uptime.
Use Azure Automation Update Management or a third-party solution to ensure that the most recent security updates are installed on your Windows and Linux VMs. For Windows VMs, ensure Windows Update has been enabled and set to update automatically.
For third-party software, use a third-party patch management solution or System Center Updates Publisher for Configuration Manager.
How to configure Update Management for virtual machines in Azure: https://docs.microsoft.com/azure/automation/automation-update-management
Manage updates and patches for your Azure VMs: https://docs.microsoft.com/azure/automation/automation-tutorial-update-management |
n/a |
link |
3 |
| Azure_Security_Benchmark_v3.0 |
PV-6 |
Azure_Security_Benchmark_v3.0_PV-6 |
Microsoft cloud security benchmark PV-6 |
Posture and Vulnerability Management |
Rapidly and automatically remediate vulnerabilities |
Shared |
**Security Principle:**
Rapidly and automatically deploy patches and updates to remediate vulnerabilities in your cloud resources. Use the appropriate risk-based approach to prioritize the remediation of the vulnerabilities. For example, more severe vulnerabilities in a higher value asset should be addressed as a higher priority.
**Azure Guidance:**
Use Azure Automation Update Management or a third-party solution to ensure that the most recent security updates are installed on your Windows and Linux VMs. For Windows VMs, ensure Windows Update has been enabled and set to update automatically.
For third-party software, use a third-party patch management solution or System Center Updates Publisher for Configuration Manager.
Prioritize which updates to deploy first using a common risk scoring program (such as Common Vulnerability Scoring System) or the default risk ratings provided by your third-party scanning tool and tailor to your environment. You should also consider which applications present a high security risk and which ones require high uptime.
**Implementation and additional context:**
How to configure Update Management for virtual machines in Azure:
https://docs.microsoft.com/azure/automation/update-management/overview
Manage updates and patches for your Azure VMs:
https://docs.microsoft.com/azure/automation/update-management/manage-updates-for-vm |
n/a |
link |
13 |
|
C.04.3 - Timelines |
C.04.3 - Timelines |
404 not found |
|
|
|
n/a |
n/a |
|
29 |
|
C.04.6 - Timelines |
C.04.6 - Timelines |
404 not found |
|
|
|
n/a |
n/a |
|
29 |
|
C.04.7 - Evaluated |
C.04.7 - Evaluated |
404 not found |
|
|
|
n/a |
n/a |
|
48 |
| CCCS |
SI-2 |
CCCS_SI-2 |
CCCS SI-2 |
System and Information Integrity |
Flaw Remediation |
|
n/a |
(A) The organization identifies, reports, and corrects information system flaws.
(B) The organization tests software and firmware updates related to flaw remediation for effectiveness and potential side effects before installation.
(C) The organization installs security-relevant software and firmware updates within 30 days of release of the release of the updates.
(D) The organization incorporates flaw remediation into the organizational configuration management process. |
link |
5 |
| 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 |
|
21 |
| 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 |
11 |
| 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 |
20 |
| 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 |
20 |
| hipaa |
1202.09aa1System.1-09.aa |
hipaa-1202.09aa1System.1-09.aa |
1202.09aa1System.1-09.aa |
12 Audit Logging & Monitoring |
1202.09aa1System.1-09.aa 09.10 Monitoring |
Shared |
n/a |
A secure audit record is created for all activities on the system (create, read, update, delete) involving covered information. |
|
5 |
| IRS_1075_9.3 |
.17.2 |
IRS_1075_9.3.17.2 |
IRS 1075 9.3.17.2 |
System and Information Integrity |
Flaw Remediation (SI-2) |
|
n/a |
The agency must:
a. Identify, report, and correct information 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 based on severity and associated risk to the confidentiality of FTI
d. Incorporate flaw remediation into the agency configuration management process
e. Centrally manage the flaw remediation process (CE1)
Security-relevant software updates include, for example, patches, service packs, hot fixes, and antivirus signatures. |
link |
6 |
| 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 |
24 |
| 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 |
20 |
| 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 |
20 |
| NZ_ISM_v3.5 |
PRS-5 |
NZ_ISM_v3.5_PRS-5 |
NZISM Security Benchmark PRS-5 |
Product Security |
12.4.4 Patching vulnerabilities in products |
Customer |
n/a |
The assurance provided by an evaluation is related to the date at which the results were issued. Over the course of a normal product lifecycle, patches are released to address known security vulnerabilities. Applying these patches should be considered as part of an agency???s overall risk management strategy.
Given the potential threat vectors and the value of the classified information being protected, high assurance products MUST NOT be patched by an agency without specific direction from the GCSB. If a patch is released for a high assurance product, the GCSB will conduct an assessment of the patch and might revise the product???s usage guidance. Likewise, for patches released for HGCE, the GCSB will subsequently conduct an assessment of the cryptographic vulnerability and might revise usage guidance in the consumer guide for the product. |
link |
2 |
| NZISM_Security_Benchmark_v1.1 |
PRS-5 |
NZISM_Security_Benchmark_v1.1_PRS-5 |
NZISM Security Benchmark PRS-5 |
Product Security |
12.4.4 Patching vulnerabilities in products |
Customer |
Agencies SHOULD ensure that security patches are applied through a vendor recommended patch or upgrade process. |
The assurance provided by an evaluation is related to the date at which the results were issued. Over the course of a normal product lifecycle, patches are released to address known security vulnerabilities. Applying these patches should be considered as part of an agency’s overall risk management strategy.
Given the potential threat vectors and the value of the classified information being protected, high assurance products MUST NOT be patched by an agency without specific direction from the GCSB. If a patch is released for a high assurance product, the GCSB will conduct an assessment of the patch and might revise the product’s usage guidance. Likewise, for patches released for HGCE, the GCSB will subsequently conduct an assessment of the cryptographic vulnerability and might revise usage guidance in the consumer guide for the product. |
link |
2 |
| RBI_CSF_Banks_v2016 |
2.3 |
RBI_CSF_Banks_v2016_2.3 |
|
Preventing Execution Of Unauthorised Software |
Security Update Management-2.3 |
|
n/a |
Continuously monitor the release of patches by various vendors / OEMs, advisories issued by CERT-in and other similar agencies and expeditiously apply the security patches as per the patch management policy of the bank. If a patch/series of patches is/are released by the OEM/manufacturer/vendor for protection against wellknown/well publicised/reported attacks exploiting the vulnerability patched, the banks must have a mechanism to apply them expeditiously following an emergency patch management process. |
|
9 |
| RBI_CSF_Banks_v2016 |
7.1 |
RBI_CSF_Banks_v2016_7.1 |
|
Patch/Vulnerability & Change Management |
Patch/Vulnerability & Change Management-7.1 |
|
n/a |
Follow a documented risk-based strategy for inventorying IT components that
need to be patched, identification of patches and applying patches so as to minimize
the number of vulnerable systems and the time window of vulnerability/exposure. |
|
12 |
| RBI_CSF_Banks_v2016 |
7.2 |
RBI_CSF_Banks_v2016_7.2 |
|
Patch/Vulnerability & Change Management |
Patch/Vulnerability & Change Management-7.2 |
|
n/a |
Put in place systems and processes to identify, track, manage and monitor the
status of patches to operating system and application software running at end-user
devices directly connected to the internet and in respect of Server operating
Systems/Databases/Applications/ Middleware, etc. |
|
12 |
| RBI_CSF_Banks_v2016 |
7.6 |
RBI_CSF_Banks_v2016_7.6 |
|
Patch/Vulnerability & Change Management |
Patch/Vulnerability & Change Management-7.6 |
|
n/a |
As a threat mitigation strategy, identify the root cause of incident and apply
necessary patches to plug the vulnerabilities. |
|
21 |
| RBI_ITF_NBFC_v2017 |
1 |
RBI_ITF_NBFC_v2017_1 |
RBI IT Framework 1 |
IT Governance |
IT Governance-1 |
|
n/a |
IT Governance is an integral part of corporate governance. It involves leadership support, organizational structure and processes to ensure that the NBFC???s IT sustains and extends business strategies and objectives. Effective IT Governance is the responsibility of the Board of Directors and Executive Management.
Well-defined roles and responsibilities of Board and Senior Management are critical, while implementing IT Governance. Clearly-defined roles enable effective project control. People, when they are aware of others' expectations from them, are able to complete work on time, within budget and to the expected level of quality. IT Governance Stakeholders include: Board of Directors, IT Strategy Committees, CEOs, Business Executives, Chief Information Officers (CIOs), Chief Technology Officers (CTOs), IT Steering Committees (operating at an executive level and focusing on priority setting, resource allocation and project tracking), Chief Risk Officer and Risk Committees.
The basic principles of value delivery, IT Risk Management, IT resource management and performance management must form the basis of governance framework. IT Governance has a continuous life-cycle. It's a process in which IT strategy drives the processes, using resources necessary to execute responsibilities. Given the criticality of the IT, NBFCs may follow relevant aspects of such prudential governance standards that have found acceptability in the finance industry. |
link |
15 |
| RBI_ITF_NBFC_v2017 |
3.3 |
RBI_ITF_NBFC_v2017_3.3 |
RBI IT Framework 3.3 |
Information and Cyber Security |
Vulnerability Management-3.3 |
|
n/a |
A vulnerability can be defined as an inherent configuration flaw in an organization???s information technology base, whether hardware or software, which can be exploited by a third party to gather sensitive information regarding the organization. Vulnerability management is an ongoing process to determine the process of eliminating or mitigating vulnerabilities based upon the risk and cost associated with the vulnerabilities. NBFCs may devise a strategy for managing and eliminating vulnerabilities and such strategy may clearly be communicated in the Cyber Security policy |
link |
14 |
| RMiT_v1.0 |
10.63 |
RMiT_v1.0_10.63 |
RMiT 10.63 |
Patch and End-of-Life System Management |
Patch and End-of-Life System Management - 10.63 |
Shared |
n/a |
A financial institution must ensure that critical systems are not running on outdated systems with known security vulnerabilities or end-of-life (EOL) technology systems. In this regard, a financial institution must clearly assign responsibilities to identified functions:
(a) to continuously monitor and implement latest patch releases in a timely manner; and
(b) identify critical technology systems that are approaching EOL for further remedial action. |
link |
2 |
| SWIFT_CSCF_v2021 |
2.2 |
SWIFT_CSCF_v2021_2.2 |
SWIFT CSCF v2021 2.2 |
Reduce Attack Surface and Vulnerabilities |
Security Updates |
|
n/a |
Minimise the occurrence of known technical vulnerabilities on operator PCs and within the local SWIFT infrastructure by ensuring vendor support, applying mandatory software updates, and applying timely security updates aligned to the assessed risk. |
link |
3 |
| SWIFT_CSCF_v2022 |
2.2 |
SWIFT_CSCF_v2022_2.2 |
SWIFT CSCF v2022 2.2 |
2. Reduce Attack Surface and Vulnerabilities |
Minimise the occurrence of known technical vulnerabilities on operator PCs and within the local SWIFT infrastructure by ensuring vendor support, applying mandatory software updates, and applying timely security updates aligned to the assessed risk. |
Shared |
n/a |
All hardware and software inside the secure zone and on operator PCs are within the support life cycle of the vendor, have been upgraded with mandatory software updates, and have had security updates promptly applied. |
link |
11 |
|
U.09.3 - Detection, prevention and recovery |
U.09.3 - Detection, prevention and recovery |
404 not found |
|
|
|
n/a |
n/a |
|
32 |
| UK_NCSC_CSP |
5.2 |
UK_NCSC_CSP_5.2 |
UK NCSC CSP 5.2 |
Operational security |
Vulnerability management |
Shared |
n/a |
Service providers should have a management processes in place to identify, triage and mitigate vulnerabilities. Services which don’t, will quickly become vulnerable to attack using publicly known methods and tools. |
link |
11 |