| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| AU_ISM |
1144 |
AU_ISM_1144 |
AU ISM 1144 |
Guidelines for System Management - System patching |
When to patch security vulnerabilities - 1144 |
|
n/a |
Security vulnerabilities in applications and drivers assessed as extreme risk are patched, updated or mitigated within 48 hours of the security vulnerabilities being identified by vendors, independent third parties, system managers or users. |
link |
7 |
| AU_ISM |
1472 |
AU_ISM_1472 |
AU ISM 1472 |
Guidelines for System Management - System patching |
When to patch security vulnerabilities - 1472 |
|
n/a |
Security vulnerabilities in applications and drivers assessed as moderate or low risk are patched, updated or mitigated within one month of the security vulnerability being identified by vendors, independent third parties, system managers or users. |
link |
7 |
| AU_ISM |
1494 |
AU_ISM_1494 |
AU ISM 1494 |
Guidelines for System Management - System patching |
When to patch security vulnerabilities - 1494 |
|
n/a |
Security vulnerabilities in operating systems and firmware assessed as extreme risk are patched, updated or mitigated within 48 hours of the security vulnerabilities being identified by vendors, independent third parties, system managers or users. |
link |
7 |
| AU_ISM |
1495 |
AU_ISM_1495 |
AU ISM 1495 |
Guidelines for System Management - System patching |
When to patch security vulnerabilities - 1495 |
|
n/a |
Security vulnerabilities in operating systems and firmware assessed as high risk are patched, updated or mitigated within two weeks of the security vulnerability being identified by vendors, independent third parties, system managers or users. |
link |
7 |
| AU_ISM |
1496 |
AU_ISM_1496 |
AU ISM 1496 |
Guidelines for System Management - System patching |
When to patch security vulnerabilities - 1496 |
|
n/a |
Security vulnerabilities in operating systems and firmware assessed as moderate or low risk are patched, updated or mitigated within one month of the security vulnerability being identified by vendors, independent third parties, system managers or users. |
link |
7 |
| AU_ISM |
940 |
AU_ISM_940 |
AU ISM 940 |
Guidelines for System Management - System patching |
When to patch security vulnerabilities - 940 |
|
n/a |
Security vulnerabilities in applications and drivers assessed as high risk are patched, updated or mitigated within two weeks of the security vulnerability being identified by vendors, independent third parties, system managers or users. |
link |
7 |
| Azure_Security_Benchmark_v1.0 |
5.5 |
Azure_Security_Benchmark_v1.0_5.5 |
Azure Security Benchmark 5.5 |
Vulnerability Management |
Use a risk-rating process to prioritize the remediation of discovered vulnerabilities |
Customer |
Use a common risk scoring program (for example, Common Vulnerability Scoring System) or the default risk ratings provided by your third-party scanning tool. |
n/a |
link |
4 |
| Azure_Security_Benchmark_v2.0 |
PV-6 |
Azure_Security_Benchmark_v2.0_PV-6 |
Azure Security Benchmark PV-6 |
Posture and Vulnerability Management |
Perform software vulnerability assessments |
Customer |
Follow recommendations from Azure Security Center for performing vulnerability assessments on your Azure virtual machines, container images, and SQL servers. Azure Security Center has a built-in vulnerability scanner for virtual machine scan.
Use a third-party solution for performing vulnerability assessments on network devices and web applications. When conducting remote scans, do not use a single, perpetual, administrative account. Consider implementing JIT (Just In Time) provisioning methodology for the scan account. Credentials for the scan account should be protected, monitored, and used only for vulnerability scanning.
Export scan results at consistent intervals and compare the results with previous scans to verify that vulnerabilities have been remediated. When using vulnerability management recommendations suggested by Azure Security Center, you can pivot into the selected scan solution's portal to view historical scan data.
How to implement Azure Security Center vulnerability assessment recommendations: https://docs.microsoft.com/azure/security-center/security-center-vulnerability-assessment-recommendations
Integrated vulnerability scanner for virtual machines: https://docs.microsoft.com/azure/security-center/built-in-vulnerability-assessment
SQL vulnerability assessment: https://docs.microsoft.com/azure/azure-sql/database/sql-vulnerability-assessment
Exporting Azure Security Center vulnerability scan results: https://docs.microsoft.com/azure/security-center/built-in-vulnerability-assessment#exporting-results |
n/a |
link |
5 |
| Azure_Security_Benchmark_v3.0 |
PV-6 |
Azure_Security_Benchmark_v3.0_PV-6 |
Azure 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 |
16 |
| CCCS |
RA-5 |
CCCS_RA-5 |
CCCS RA-5 |
Risk Assessment |
Vulnerability Scanning |
|
n/a |
(A) The organization scans for vulnerabilities in the information system and hosted applications monthly for operating systems/infrastructure, web applications, and database management systems and when new vulnerabilities potentially affecting the system/applications are identified and reported.
(B) The organization employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
(a) Enumerating platforms, software flaws, and improper configurations;
(b) Formatting checklists and test procedures; and
(c) Measuring vulnerability impact.
(C) The organization analyzes vulnerability scan reports and results from security control assessments.
(D) The organization remediates legitimate vulnerabilities within 30 days for high-risk vulnerabilities and 90 days for moderate-risk vulnerabilities from the date of discovery in accordance with an organizational assessment of risk.
(E) The organization shares information obtained from the vulnerability scanning process and security control assessments with organization-defined personnel or roles to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies). |
link |
6 |
| 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 |
RA.L2-3.11.2 |
CMMC_2.0_L2_RA.L2-3.11.2 |
404 not found |
|
|
|
n/a |
n/a |
|
21 |
| CMMC_2.0_L2 |
RA.L2-3.11.3 |
CMMC_2.0_L2_RA.L2-3.11.3 |
404 not found |
|
|
|
n/a |
n/a |
|
21 |
| 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 |
|
26 |
| CMMC_L3 |
RM.2.143 |
CMMC_L3_RM.2.143 |
CMMC L3 RM.2.143 |
Risk Assessment |
Remediate vulnerabilities in accordance with risk assessments. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Vulnerabilities discovered, for example, via the scanning conducted in response to RM.2.142, are remediated with consideration of the related assessment of risk. The consideration of risk influences the prioritization of remediation efforts and the level of effort to be expended in the remediation for specific vulnerabilities. |
link |
19 |
| 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 |
16 |
| FedRAMP_High_R4 |
RA-5 |
FedRAMP_High_R4_RA-5 |
FedRAMP High RA-5 |
Risk Assessment |
Vulnerability Scanning |
Shared |
n/a |
The organization:
a. Scans for vulnerabilities in the information system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system/applications are identified and reported;
b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
1. Enumerating platforms, software flaws, and improper configurations;
2. Formatting checklists and test procedures; and
3. Measuring vulnerability impact;
c. Analyzes vulnerability scan reports and results from security control assessments;
d. Remediates legitimate vulnerabilities [Assignment: organization-defined response times], in accordance with an organizational assessment of risk; and
e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).
Supplemental Guidance: Security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. Organizations determine the required vulnerability scanning for all information system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Vulnerability scanning includes, for example: (i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms. Organizations consider using tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability Assessment Language (OVAL) to determine/test for the presence of vulnerabilities. Suggested sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). In addition, security control assessments such as red team exercises provide other sources of potential vulnerabilities for which to scan. Organizations also consider using tools that express vulnerability impact by the
Common Vulnerability Scoring System (CVSS). Related controls: CA-2, CA-7, CM-4, CM-6, RA-2, RA-3, SA-11, SI-2.
References: NIST Special Publications 800-40, 800-70, 800-115; Web: http://cwe.mitre.org, http://nvd.nist.gov. |
link |
23 |
| 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 |
25 |
| FedRAMP_Moderate_R4 |
RA-5 |
FedRAMP_Moderate_R4_RA-5 |
FedRAMP Moderate RA-5 |
Risk Assessment |
Vulnerability Scanning |
Shared |
n/a |
The organization:
a. Scans for vulnerabilities in the information system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system/applications are identified and reported;
b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
1. Enumerating platforms, software flaws, and improper configurations;
2. Formatting checklists and test procedures; and
3. Measuring vulnerability impact;
c. Analyzes vulnerability scan reports and results from security control assessments;
d. Remediates legitimate vulnerabilities [Assignment: organization-defined response times], in accordance with an organizational assessment of risk; and
e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).
Supplemental Guidance: Security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. Organizations determine the required vulnerability scanning for all information system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Vulnerability scanning includes, for example: (i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms. Organizations consider using tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability Assessment Language (OVAL) to determine/test for the presence of vulnerabilities. Suggested sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). In addition, security control assessments such as red team exercises provide other sources of potential vulnerabilities for which to scan. Organizations also consider using tools that express vulnerability impact by the
Common Vulnerability Scoring System (CVSS). Related controls: CA-2, CA-7, CM-4, CM-6, RA-2, RA-3, SA-11, SI-2.
References: NIST Special Publications 800-40, 800-70, 800-115; Web: http://cwe.mitre.org, http://nvd.nist.gov. |
link |
23 |
| 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 |
25 |
| hipaa |
0709.10m1Organizational.1-10.m |
hipaa-0709.10m1Organizational.1-10.m |
0709.10m1Organizational.1-10.m |
07 Vulnerability Management |
0709.10m1Organizational.1-10.m 10.06 Technical Vulnerability Management |
Shared |
n/a |
Technical vulnerabilities are identified, evaluated for risk, and corrected in a timely manner. |
|
13 |
| hipaa |
0716.10m3Organizational.1-10.m |
hipaa-0716.10m3Organizational.1-10.m |
0716.10m3Organizational.1-10.m |
07 Vulnerability Management |
0716.10m3Organizational.1-10.m 10.06 Technical Vulnerability Management |
Shared |
n/a |
The organization conducts an enterprise security posture review as needed but no less than once within every 365 days, in accordance with organizational information security procedures. |
|
5 |
| IRS_1075_9.3 |
.14.3 |
IRS_1075_9.3.14.3 |
IRS 1075 9.3.14.3 |
Risk Assessment |
Vulnerability Scanning (RA-5) |
|
n/a |
The agency must:
a. Scan for vulnerabilities in the information system and hosted applications at a minimum of monthly for all systems and when new vulnerabilities potentially affecting the system/applications are identified and reported
b. Employ vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
1. Enumerating platforms, software flaws, and improper configurations
2. Formatting checklists and test procedures
3. Measuring vulnerability impact
c. Analyze vulnerability scan reports and results from security control assessments
d. Remediate legitimate vulnerabilities in accordance with an assessment of risk
e. Share information obtained from the vulnerability scanning process and security control assessments with designated agency officials to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies)
f. Employ vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned (CE1) |
link |
6 |
| 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 |
| ISO27001-2013 |
A.12.6.1 |
ISO27001-2013_A.12.6.1 |
ISO 27001:2013 A.12.6.1 |
Operations Security |
Management of technical vulnerabilities |
Shared |
n/a |
Information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk. |
link |
13 |
| ISO27001-2013 |
A.8.2.1 |
ISO27001-2013_A.8.2.1 |
ISO 27001:2013 A.8.2.1 |
Asset Management |
Classification of information |
Shared |
n/a |
Information shall be classified in terms of legal requirements, value, criticality and sensitivity to unauthorized disclosure or modification. |
link |
5 |
| NIST_SP_800-171_R2_3 |
.11.2 |
NIST_SP_800-171_R2_3.11.2 |
NIST SP 800-171 R2 3.11.2 |
Risk Assessment |
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Organizations determine the required vulnerability scanning for all system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. The vulnerabilities to be scanned are readily updated as new vulnerabilities are discovered, announced, and scanning methods developed. This process ensures that potential vulnerabilities in the system are identified and addressed as quickly as possible. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in source code reviews and in a variety of tools (e.g., static analysis tools, web-based application scanners, binary analyzers) and in source code reviews. Vulnerability scanning includes: scanning for patch levels; scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and scanning for improperly configured or incorrectly operating information flow control mechanisms. To facilitate interoperability, organizations consider using products that are Security Content Automated Protocol (SCAP)-validated, scanning tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention, and that employ the Open Vulnerability Assessment Language (OVAL) to determine the presence of system vulnerabilities. Sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). Security assessments, such as red team exercises, provide additional sources of potential vulnerabilities for which to scan. Organizations also consider using scanning tools that express vulnerability impact by the Common Vulnerability Scoring System (CVSS). In certain situations, the nature of the vulnerability scanning may be more intrusive or the system component that is the subject of the scanning may contain highly sensitive information. Privileged access authorization to selected system components facilitates thorough vulnerability scanning and protects the sensitive nature of such scanning. [SP 800-40] provides guidance on vulnerability management. |
link |
24 |
| NIST_SP_800-171_R2_3 |
.11.3 |
NIST_SP_800-171_R2_3.11.3 |
NIST SP 800-171 R2 3.11.3 |
Risk Assessment |
Remediate vulnerabilities in accordance with risk assessments. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Vulnerabilities discovered, for example, via the scanning conducted in response to 3.11.2, are remediated with consideration of the related assessment of risk. The consideration of risk influences the prioritization of remediation efforts and the level of effort to be expended in the remediation for specific vulnerabilities. |
link |
23 |
| 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 |
29 |
| NIST_SP_800-53_R4 |
RA-5 |
NIST_SP_800-53_R4_RA-5 |
NIST SP 800-53 Rev. 4 RA-5 |
Risk Assessment |
Vulnerability Scanning |
Shared |
n/a |
The organization:
a. Scans for vulnerabilities in the information system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system/applications are identified and reported;
b. Employs vulnerability scanning tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
1. Enumerating platforms, software flaws, and improper configurations;
2. Formatting checklists and test procedures; and
3. Measuring vulnerability impact;
c. Analyzes vulnerability scan reports and results from security control assessments;
d. Remediates legitimate vulnerabilities [Assignment: organization-defined response times], in accordance with an organizational assessment of risk; and
e. Shares information obtained from the vulnerability scanning process and security control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).
Supplemental Guidance: Security categorization of information systems guides the frequency and comprehensiveness of vulnerability scans. Organizations determine the required vulnerability scanning for all information system components, ensuring that potential sources of vulnerabilities such as networked printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software applications may require additional approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Organizations can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Vulnerability scanning includes, for example: (i) scanning for patch levels; (ii) scanning for functions, ports, protocols, and services that should not be accessible to users or devices; and (iii) scanning for improperly configured or incorrectly operating information flow control mechanisms. Organizations consider using tools that express vulnerabilities in the Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability Assessment Language (OVAL) to determine/test for the presence of vulnerabilities. Suggested sources for vulnerability information include the Common Weakness Enumeration (CWE) listing and the National Vulnerability Database (NVD). In addition, security control assessments such as red team exercises provide other sources of potential vulnerabilities for which to scan. Organizations also consider using tools that express vulnerability impact by the
Common Vulnerability Scoring System (CVSS). Related controls: CA-2, CA-7, CM-4, CM-6, RA-2, RA-3, SA-11, SI-2.
References: NIST Special Publications 800-40, 800-70, 800-115; Web: http://cwe.mitre.org, http://nvd.nist.gov. |
link |
23 |
| 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 |
25 |
| NIST_SP_800-53_R5 |
RA-5 |
NIST_SP_800-53_R5_RA-5 |
NIST SP 800-53 Rev. 5 RA-5 |
Risk Assessment |
Vulnerability Monitoring and Scanning |
Shared |
n/a |
a. Monitor and scan for vulnerabilities in the system and hosted applications [Assignment: organization-defined frequency and/or randomly in accordance with organization-defined process] and when new vulnerabilities potentially affecting the system are identified and reported;
b. Employ vulnerability monitoring tools and techniques that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for:
1. Enumerating platforms, software flaws, and improper configurations;
2. Formatting checklists and test procedures; and
3. Measuring vulnerability impact;
c. Analyze vulnerability scan reports and results from vulnerability monitoring;
d. Remediate legitimate vulnerabilities [Assignment: organization-defined response times] in accordance with an organizational assessment of risk;
e. Share information obtained from the vulnerability monitoring process and control assessments with [Assignment: organization-defined personnel or roles] to help eliminate similar vulnerabilities in other systems; and
f. Employ vulnerability monitoring tools that include the capability to readily update the vulnerabilities to be scanned. |
link |
23 |
| 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 |
25 |
| NZ_ISM_v3.5 |
ISM-4 |
NZ_ISM_v3.5_ISM-4 |
NZISM Security Benchmark ISM-4 |
Information security monitoring |
6.2.6 Resolving vulnerabilities |
Customer |
n/a |
Vulnerabilities may occur as a result of poorly designed or implemented information security practices, accidental activities or malicious activities, and not just as the result of a technical issue. |
link |
11 |
| NZISM_Security_Benchmark_v1.1 |
ISM-4 |
NZISM_Security_Benchmark_v1.1_ISM-4 |
NZISM Security Benchmark ISM-4 |
Information security monitoring |
6.2.6 Resolving vulnerabilities |
Customer |
Agencies SHOULD analyse and treat all vulnerabilities and subsequent security risks to their systems identified during a vulnerability assessment. |
Vulnerabilities may occur as a result of poorly designed or implemented information security practices, accidental activities or malicious activities, and not just as the result of a technical issue. |
link |
6 |
| PCI_DSS_V3.2.1 |
11.2.1 |
PCI_DSS_v3.2.1_11.2.1 |
PCI DSS v3.2.1 11.2.1 |
Requirement 11 |
PCI DSS requirement 11.2.1 |
shared |
n/a |
n/a |
link |
5 |
| PCI_DSS_V3.2.1 |
5.1 |
PCI_DSS_v3.2.1_5.1 |
PCI DSS v3.2.1 5.1 |
Requirement 5 |
PCI DSS requirement 5.1 |
shared |
n/a |
n/a |
link |
5 |
| PCI_DSS_V3.2.1 |
6.2 |
PCI_DSS_v3.2.1_6.2 |
PCI DSS v3.2.1 6.2 |
Requirement 6 |
PCI DSS requirement 6.2 |
shared |
n/a |
n/a |
link |
5 |
| PCI_DSS_V3.2.1 |
6.6 |
PCI_DSS_v3.2.1_6.6 |
PCI DSS v3.2.1 6.6 |
Requirement 6 |
PCI DSS requirement 6.6 |
shared |
n/a |
n/a |
link |
5 |
| PCI_DSS_v4.0 |
11.3.1 |
PCI_DSS_v4.0_11.3.1 |
PCI DSS v4.0 11.3.1 |
Requirement 11: Test Security of Systems and Networks Regularly |
External and internal vulnerabilities are regularly identified, prioritized, and addressed |
Shared |
n/a |
Internal vulnerability scans are performed as follows:
• At least once every three months.
• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
• Rescans are performed that confirm all high-risk and critical vulnerabilities as noted above) have been resolved.
• Scan tool is kept up to date with latest vulnerability information.
• Scans are performed by qualified personnel and organizational independence of the tester exists. |
link |
7 |
| PCI_DSS_v4.0 |
5.2.1 |
PCI_DSS_v4.0_5.2.1 |
PCI DSS v4.0 5.2.1 |
Requirement 05: Protect All Systems and Networks from Malicious Software |
Malicious software (malware) is prevented, or detected and addressed |
Shared |
n/a |
An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware. |
link |
12 |
| PCI_DSS_v4.0 |
5.2.2 |
PCI_DSS_v4.0_5.2.2 |
PCI DSS v4.0 5.2.2 |
Requirement 05: Protect All Systems and Networks from Malicious Software |
Malicious software (malware) is prevented, or detected and addressed |
Shared |
n/a |
The deployed anti-malware solution(s):
• Detects all known types of malware.
• Removes, blocks, or contains all known types of malware. |
link |
12 |
| PCI_DSS_v4.0 |
5.2.3 |
PCI_DSS_v4.0_5.2.3 |
PCI DSS v4.0 5.2.3 |
Requirement 05: Protect All Systems and Networks from Malicious Software |
Malicious software (malware) is prevented, or detected and addressed |
Shared |
n/a |
Any system components that are not at risk for malware are evaluated periodically to include the following:
• A documented list of all system components not at risk for malware.
• Identification and evaluation of evolving malware threats for those system components.
• Confirmation whether such system components continue to not require anti-malware protection. |
link |
12 |
| PCI_DSS_v4.0 |
6.3.3 |
PCI_DSS_v4.0_6.3.3 |
PCI DSS v4.0 6.3.3 |
Requirement 06: Develop and Maintain Secure Systems and Software |
Security vulnerabilities are identified and addressed |
Shared |
n/a |
All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
• Critical or high-security patches/updates are identified according to the risk ranking process at Requirement 6.3.1.
• Critical or high-security patches/updates are installed within one month of release.
• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release). |
link |
5 |
| PCI_DSS_v4.0 |
6.4.1 |
PCI_DSS_v4.0_6.4.1 |
PCI DSS v4.0 6.4.1 |
Requirement 06: Develop and Maintain Secure Systems and Software |
Public-facing web applications are protected against attacks |
Shared |
n/a |
For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:
• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows:
– At least once every 12 months and after significant changes.
– By an entity that specializes in application security.
– Including, at a minimum, all common software attacks in Requirement 6.3.6.
– All vulnerabilities are ranked in accordance with requirement 6.2.1.
– All vulnerabilities are corrected.
– The application is re-evaluated after the corrections
OR
• Installing an automated technical solution(s) that continually detects and prevents web-based
attacks as follows:
– Installed in front of public-facing web applications to detect and prevent webbased attacks.
– Actively running and up to date as applicable.
– Generating audit logs.
– Configured to either block web-based attacks or generate an alert that is immediately investigated. |
link |
7 |
| RBI_CSF_Banks_v2016 |
18.2 |
RBI_CSF_Banks_v2016_18.2 |
|
Vulnerability Assessment And Penetration Test And Red Team Exercises |
Vulnerability Assessment And Penetration Test And Red Team Exercises-18.2 |
|
n/a |
The vulnerabilities detected are to be remedied promptly in terms of the bank???s risk management/treatment framework so asto avoid exploitation of such vulnerabilities. |
|
4 |
| RBI_CSF_Banks_v2016 |
18.4 |
RBI_CSF_Banks_v2016_18.4 |
|
Vulnerability Assessment And Penetration Test And Red Team Exercises |
Vulnerability Assessment And Penetration Test And Red Team Exercises-18.4 |
|
n/a |
Findings of VA/PT and the follow up actions necessitated are to be monitored closely by the Information Security/Information Technology Audit team as well as Senior/Top Management. |
|
6 |
| 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. |
|
14 |
| 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. |
|
17 |
| 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. |
|
17 |
| 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. |
|
26 |
| 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 |
20 |
| 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 |
19 |
| SWIFT_CSCF_v2021 |
2.7 |
SWIFT_CSCF_v2021_2.7 |
SWIFT CSCF v2021 2.7 |
Reduce Attack Surface and Vulnerabilities |
Vulnerability Scanning |
|
n/a |
Identify known vulnerabilities within the local SWIFT environment by implementing a regular vulnerability scanning process and act upon results. |
link |
12 |
| 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 |