compliance controls are associated with this Policy definition 'Remediate information system flaws' (be38a620-000b-21cf-3cb3-ea151b704c3b)
Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
CIS_Azure_1.1.0 |
2.3 |
CIS_Azure_1.1.0_2.3 |
CIS Microsoft Azure Foundations Benchmark recommendation 2.3 |
2 Security Center |
Ensure ASC Default policy setting "Monitor System Updates" is not "Disabled" |
Shared |
The customer is responsible for implementing this recommendation. |
Enable system updates recommendations for virtual machines. |
link |
2 |
CIS_Azure_1.1.0 |
2.4 |
CIS_Azure_1.1.0_2.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 2.4 |
2 Security Center |
Ensure ASC Default policy setting "Monitor OS Vulnerabilities" is not "Disabled" |
Shared |
The customer is responsible for implementing this recommendation. |
Enable Monitor OS vulnerability recommendations for virtual machines. |
link |
3 |
CIS_Azure_1.1.0 |
7.5 |
CIS_Azure_1.1.0_7.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 7.5 |
7 Virtual Machines |
Ensure that the latest OS Patches for all Virtual Machines are applied |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that the latest OS patches for all virtual machines are applied. |
link |
2 |
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.1.0 |
9.6 |
CIS_Azure_1.1.0_9.6 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.6 |
9 AppService |
Ensure that '.Net Framework' version is the latest, if used as a part of the web app |
Shared |
The customer is responsible for implementing this recommendation. |
Periodically, newer versions are released for .Net Framework software either due to security flaws or to include additional functionality. Using the latest .Net framework version for web apps is recommended in order to to take advantage of security fixes, if any, and/or new functionalities of the latest version. |
link |
1 |
CIS_Azure_1.1.0 |
9.7 |
CIS_Azure_1.1.0_9.7 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.7 |
9 AppService |
Ensure that 'PHP 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 PHP software either due to security flaws or to include additional functionality. Using the latest PHP version for web apps is recommended in order to take advantage of security fixes, if any, and/or additional functionalities of the newer version. |
link |
1 |
CIS_Azure_1.1.0 |
9.8 |
CIS_Azure_1.1.0_9.8 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.8 |
9 AppService |
Ensure that 'Python 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 Python software either due to security flaws or to include additional functionality. Using the latest Python version for web apps is recommended in order to take advantage of security fixes, if any, and/or additional functionalities of the newer version. |
link |
1 |
CIS_Azure_1.1.0 |
9.9 |
CIS_Azure_1.1.0_9.9 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.9 |
9 AppService |
Ensure that 'Java 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 Java software either due to security flaws or to include additional functionality. Using the latest Java version for web apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the newer version. |
link |
1 |
CIS_Azure_1.3.0 |
4.2.2 |
CIS_Azure_1.3.0_4.2.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.2 |
4 Database Services |
Ensure that Vulnerability Assessment (VA) is enabled on a SQL server by setting a Storage Account |
Shared |
The customer is responsible for implementing this recommendation. |
Enable Vulnerability Assessment (VA) service scans for critical SQL servers and corresponding SQL databases. |
link |
4 |
CIS_Azure_1.3.0 |
4.2.3 |
CIS_Azure_1.3.0_4.2.3 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.3 |
4 Database Services |
Ensure that VA setting Periodic Recurring Scans is enabled on a SQL server |
Shared |
The customer is responsible for implementing this recommendation. |
Enable Vulnerability Assessment (VA) Periodic recurring scans for critical SQL servers and corresponding SQL databases. |
link |
2 |
CIS_Azure_1.3.0 |
4.2.4 |
CIS_Azure_1.3.0_4.2.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.4 |
4 Database Services |
Ensure that VA setting Send scan reports to is configured for a SQL server |
Shared |
The customer is responsible for implementing this recommendation. |
Configure 'Send scan reports to' with email ids of concerned data owners/stakeholders for a critical SQL servers. |
link |
3 |
CIS_Azure_1.3.0 |
4.2.5 |
CIS_Azure_1.3.0_4.2.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.5 |
4 Database Services |
Ensure that VA setting 'Also send email notifications to admins and subscription owners' is set for a SQL server |
Shared |
The customer is responsible for implementing this recommendation. |
Enable Vulnerability Assessment (VA) setting 'Also send email notifications to admins and subscription owners'. |
link |
3 |
CIS_Azure_1.3.0 |
7.5 |
CIS_Azure_1.3.0_7.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 7.5 |
7 Virtual Machines |
Ensure that the latest OS Patches for all Virtual Machines are applied |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that the latest OS patches for all virtual machines are applied. |
link |
2 |
CIS_Azure_1.3.0 |
9.6 |
CIS_Azure_1.3.0_9.6 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.6 |
9 AppService |
Ensure that 'PHP 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 PHP software either due to security flaws or to include additional functionality. Using the latest PHP version for web apps is recommended in order to take advantage of security fixes, if any, and/or additional functionalities of the newer version. |
link |
1 |
CIS_Azure_1.3.0 |
9.7 |
CIS_Azure_1.3.0_9.7 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.7 |
9 AppService |
Ensure that 'Python 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 Python software either due to security flaws or to include additional functionality. Using the latest Python version for web apps is recommended in order to take advantage of security fixes, if any, and/or additional functionalities of the newer version. |
link |
1 |
CIS_Azure_1.3.0 |
9.8 |
CIS_Azure_1.3.0_9.8 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.8 |
9 AppService |
Ensure that 'Java 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 Java software either due to security flaws or to include additional functionality. Using the latest Java version for web apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the newer version. |
link |
1 |
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 |
4.2.2 |
CIS_Azure_1.4.0_4.2.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.2 |
4 Database Services |
Ensure that Vulnerability Assessment (VA) is enabled on a SQL server by setting a Storage Account |
Shared |
The customer is responsible for implementing this recommendation. |
Enable Vulnerability Assessment (VA) service scans for critical SQL servers and corresponding SQL databases. |
link |
4 |
CIS_Azure_1.4.0 |
4.2.3 |
CIS_Azure_1.4.0_4.2.3 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.3 |
4 Database Services |
Ensure that VA setting 'Periodic recurring scans' to 'on' for each SQL server |
Shared |
The customer is responsible for implementing this recommendation. |
Enable Vulnerability Assessment (VA) Periodic recurring scans for critical SQL servers and corresponding SQL databases. |
link |
2 |
CIS_Azure_1.4.0 |
4.2.4 |
CIS_Azure_1.4.0_4.2.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.4 |
4 Database Services |
Ensure that VA setting 'Send scan reports to' is configured for a SQL server |
Shared |
The customer is responsible for implementing this recommendation. |
Configure 'Send scan reports to' with email ids of concerned data owners/stakeholders for a critical SQL servers. |
link |
3 |
CIS_Azure_1.4.0 |
4.2.5 |
CIS_Azure_1.4.0_4.2.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.5 |
4 Database Services |
Ensure that Vulnerability Assessment Setting 'Also send email notifications to admins and subscription owners' is Set for Each SQL Server |
Shared |
The customer is responsible for implementing this recommendation. |
Enable Vulnerability Assessment (VA) setting 'Also send email notifications to admins and subscription owners'. |
link |
3 |
CIS_Azure_1.4.0 |
7.5 |
CIS_Azure_1.4.0_7.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 7.5 |
7 Virtual Machines |
Ensure that the latest OS Patches for all Virtual Machines are applied |
Shared |
The customer is responsible for implementing this recommendation. |
Ensure that the latest OS patches for all virtual machines are applied. |
link |
2 |
CIS_Azure_1.4.0 |
9.6 |
CIS_Azure_1.4.0_9.6 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.6 |
9 AppService |
Ensure That 'PHP 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 PHP software either due to security flaws or to include additional functionality. Using the latest PHP version for web apps is recommended in order to take advantage of security fixes, if any, and/or additional functionalities of the newer version. |
link |
1 |
CIS_Azure_1.4.0 |
9.7 |
CIS_Azure_1.4.0_9.7 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.7 |
9 AppService |
Ensure that 'Python version' is the Latest Stable Version, if Used to Run the Web App |
Shared |
The customer is responsible for implementing this recommendation. |
Periodically, newer versions are released for Python software either due to security flaws or to include additional functionality. Using the latest full Python version for web apps is recommended in order to take advantage of security fixes, if any, and/or additional functionalities of the newer version. |
link |
1 |
CIS_Azure_1.4.0 |
9.8 |
CIS_Azure_1.4.0_9.8 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.8 |
9 AppService |
Ensure that 'Java 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 Java software either due to security flaws or to include additional functionality. Using the latest Java version for web apps is recommended in order to take advantage of security fixes, if any, and/or new functionalities of the newer version. |
link |
1 |
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 |
4.2.2 |
CIS_Azure_2.0.0_4.2.2 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.2 |
4.2 |
Ensure that Vulnerability Assessment (VA) is enabled on a SQL server by setting a Storage Account |
Shared |
Enabling the `Microsoft Defender for SQL` features will incur additional costs for each SQL server. |
Enable Vulnerability Assessment (VA) service scans for critical SQL servers and corresponding SQL databases.
Enabling Microsoft Defender for SQL server does not enables Vulnerability Assessment capability for individual SQL databases unless storage account is set to store the scanning data and reports.
The Vulnerability Assessment service scans databases for known security vulnerabilities and highlights deviations from best practices, such as misconfigurations, excessive permissions, and unprotected sensitive data.
Results of the scan include actionable steps to resolve each issue and provide customized remediation scripts where applicable. Additionally, an assessment report can be customized by setting an acceptable baseline for permission configurations, feature configurations, and database settings. |
link |
4 |
CIS_Azure_2.0.0 |
4.2.3 |
CIS_Azure_2.0.0_4.2.3 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.3 |
4.2 |
Ensure that Vulnerability Assessment (VA) setting 'Periodic recurring scans' is set to 'on' for each SQL server |
Shared |
Enabling the `Azure Defender for SQL` feature will incur additional costs for each SQL server. |
Enable Vulnerability Assessment (VA) Periodic recurring scans for critical SQL servers and corresponding SQL databases.
VA setting 'Periodic recurring scans' schedules periodic (weekly) vulnerability scanning for the SQL server and corresponding Databases.
Periodic and regular vulnerability scanning provides risk visibility based on updated known vulnerability signatures and best practices. |
link |
3 |
CIS_Azure_2.0.0 |
4.2.4 |
CIS_Azure_2.0.0_4.2.4 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.4 |
4.2 |
Ensure that Vulnerability Assessment (VA) setting 'Send scan reports to' is configured for a SQL server |
Shared |
Enabling the `Microsoft Defender for SQL` features will incur additional costs for each SQL server. |
Configure 'Send scan reports to' with email addresses of concerned data owners/stakeholders for a critical SQL servers.
Vulnerability Assessment (VA) scan reports and alerts will be sent to email addresses configured at 'Send scan reports to'. This may help in reducing time required for identifying risks and taking corrective measures. |
link |
4 |
CIS_Azure_2.0.0 |
4.2.5 |
CIS_Azure_2.0.0_4.2.5 |
CIS Microsoft Azure Foundations Benchmark recommendation 4.2.5 |
4.2 |
Ensure that Vulnerability Assessment (VA) setting 'Also send email notifications to admins and subscription owners' is set for each SQL Server |
Shared |
Enabling the `Microsoft Defender for SQL` features will incur additional costs for each SQL server. |
Enable Vulnerability Assessment (VA) setting 'Also send email notifications to admins and subscription owners'.
VA scan reports and alerts will be sent to admins and subscription owners by enabling setting 'Also send email notifications to admins and subscription owners'. This may help in reducing time required for identifying risks and taking corrective measures. |
link |
5 |
CIS_Azure_2.0.0 |
9.6 |
CIS_Azure_2.0.0_9.6 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.6 |
9 |
Ensure That 'PHP version' is the Latest, If Used to Run the Web App |
Shared |
If your app is written using version-dependent features or libraries, they may not be available on the latest version. If you wish to upgrade, research the impact thoroughly. Upgrading may have unforeseen consequences that could result in downtime. |
Periodically newer versions are released for PHP software either due to security flaws or to include additional functionality. Using the latest PHP version for web apps is recommended in order to take advantage of security fixes, if any, and/or additional functionalities of the newer version.
Newer versions may contain security enhancements and additional functionality. Using the latest software 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. |
link |
3 |
CIS_Azure_2.0.0 |
9.7 |
CIS_Azure_2.0.0_9.7 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.7 |
9 |
Ensure that 'Python version' is the Latest Stable Version, if Used to Run the Web App |
Shared |
If your app is written using version-dependent features or libraries, they may not be available on the latest version. If you wish to upgrade, research the impact thoroughly. Upgrading may have unforeseen consequences that could result in downtime. |
Periodically, newer versions are released for Python software either due to security flaws or to include additional functionality. Using the latest full Python version for web apps is recommended in order to take advantage of security fixes, if any, and/or additional functionalities of the newer version.
Newer versions may contain security enhancements and additional functionality. Using the latest software 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. Using the latest full version will keep your stack secure to vulnerabilities and exploits. |
link |
3 |
CIS_Azure_2.0.0 |
9.8 |
CIS_Azure_2.0.0_9.8 |
CIS Microsoft Azure Foundations Benchmark recommendation 9.8 |
9 |
Ensure that 'Java version' is the latest, if used to run the Web App |
Shared |
If your app is written using version-dependent features or libraries, they may not be available on the latest version. If you wish to upgrade, research the impact thoroughly. Upgrading may have unforeseen consequences that could result in downtime. |
Periodically, newer versions are released for Java software either due to security flaws or to include additional functionality. Using the latest Java version for web apps is recommended in order 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 software 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. |
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 |
FedRAMP_High_R4 |
CM-6 |
FedRAMP_High_R4_CM-6 |
FedRAMP High CM-6 |
Configuration Management |
Configuration Settings |
Shared |
n/a |
The organization:
a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;
b. Implements the configuration settings;
c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and
d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.
Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline.
Common secure configurations (also referred to as security configuration checklists, lockdown
and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4.
References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. |
link |
23 |
FedRAMP_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 |
19 |
FedRAMP_High_R4 |
RA-5(1) |
FedRAMP_High_R4_RA-5(1) |
FedRAMP High RA-5 (1) |
Risk Assessment |
Update Tool Capability |
Shared |
n/a |
The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned.
Supplemental Guidance: The vulnerabilities to be scanned need to be readily updated as new vulnerabilities are discovered, announced, and scanning methods developed. This updating process helps to ensure that potential vulnerabilities in the information system are identified and addressed as quickly as possible. Related controls: SI-3, SI-7. |
link |
2 |
FedRAMP_High_R4 |
RA-5(2) |
FedRAMP_High_R4_RA-5(2) |
FedRAMP High RA-5 (2) |
Risk Assessment |
Update By Frequency / Prior To New Scan / When Identified |
Shared |
n/a |
The organization updates the information system vulnerabilities scanned [Selection (one or more): [Assignment: organization-defined frequency]; prior to a new scan; when new vulnerabilities are identified and reported].
Supplemental Guidance: Related controls: SI-3, SI-5. |
link |
2 |
FedRAMP_High_R4 |
RA-5(3) |
FedRAMP_High_R4_RA-5(3) |
FedRAMP High RA-5 (3) |
Risk Assessment |
Breadth / Depth Of Coverage |
Shared |
n/a |
The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked). |
link |
2 |
FedRAMP_High_R4 |
RA-5(6) |
FedRAMP_High_R4_RA-5(6) |
FedRAMP High RA-5 (6) |
Risk Assessment |
Automated Trend Analyses |
Shared |
n/a |
The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities.
Supplemental Guidance: Related controls: IR-4, IR-5, SI-4. |
link |
5 |
FedRAMP_High_R4 |
SA-10 |
FedRAMP_High_R4_SA-10 |
FedRAMP High SA-10 |
System And Services Acquisition |
Developer Configuration Management |
Shared |
n/a |
The organization requires the developer of the information system, system component, or information system service to:
a. Perform configuration management during system, component, or service [Selection (one or more): design; development; implementation; operation];
b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items under configuration management];
c. Implement only organization-approved changes to the system, component, or service;
d. Document approved changes to the system, component, or service and the potential security impacts of such changes; and
e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel].
Supplemental Guidance: This control also applies to organizations conducting internal information systems development and integration. Organizations consider the quality and completeness of the configuration management activities conducted by developers as evidence of applying effective security safeguards. Safeguards include, for example, protecting from unauthorized modification or destruction, the master copies of all material used to generate security-relevant portions of the system hardware, software, and firmware. Maintaining the integrity of changes to the information system, information system component, or information system service requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes. Configuration items that are placed under configuration management (if existence/use is required by other security controls) include: the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and software/firmware source code with previous versions; and test fixtures and documentation. Depending on the mission/business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance phases of the life cycle. Related controls: CM-3, CM-4, CM-9, SA-12, SI-2.
References: NIST Special Publication 800-128. |
link |
9 |
FedRAMP_High_R4 |
SA-11 |
FedRAMP_High_R4_SA-11 |
FedRAMP High SA-11 |
System And Services Acquisition |
Developer Security Testing And Evaluation |
Shared |
n/a |
The organization requires the developer of the information system, system component, or information system service to:
a. Create and implement a security assessment plan;
b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage];
c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation;
d. Implement a verifiable flaw remediation process; and
e. Correct flaws identified during security testing/evaluation.
Supplemental Guidance: Developmental security testing/evaluation occurs at all post‐design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers 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. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2.
References: ISO/IEC 15408; NIST Special Publication 800-53A; Web: http://nvd.nist.gov, http://cwe.mitre.org, http://cve.mitre.org, http://capec.mitre.org. |
link |
3 |
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 |
18 |
FedRAMP_High_R4 |
SI-2(2) |
FedRAMP_High_R4_SI-2(2) |
FedRAMP High SI-2 (2) |
System And Information Integrity |
Automated Flaw Remediation Status |
Shared |
n/a |
The organization employs automated mechanisms [Assignment: organization-defined frequency] to determine the state of information system components with regard to flaw remediation.
Supplemental Guidance: Related controls: CM-6, SI-4. |
link |
2 |
FedRAMP_Moderate_R4 |
CM-6 |
FedRAMP_Moderate_R4_CM-6 |
FedRAMP Moderate CM-6 |
Configuration Management |
Configuration Settings |
Shared |
n/a |
The organization:
a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;
b. Implements the configuration settings;
c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and
d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.
Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline.
Common secure configurations (also referred to as security configuration checklists, lockdown
and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4.
References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. |
link |
23 |
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 |
19 |
FedRAMP_Moderate_R4 |
RA-5(1) |
FedRAMP_Moderate_R4_RA-5(1) |
FedRAMP Moderate RA-5 (1) |
Risk Assessment |
Update Tool Capability |
Shared |
n/a |
The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned.
Supplemental Guidance: The vulnerabilities to be scanned need to be readily updated as new vulnerabilities are discovered, announced, and scanning methods developed. This updating process helps to ensure that potential vulnerabilities in the information system are identified and addressed as quickly as possible. Related controls: SI-3, SI-7. |
link |
2 |
FedRAMP_Moderate_R4 |
RA-5(2) |
FedRAMP_Moderate_R4_RA-5(2) |
FedRAMP Moderate RA-5 (2) |
Risk Assessment |
Update By Frequency / Prior To New Scan / When Identified |
Shared |
n/a |
The organization updates the information system vulnerabilities scanned [Selection (one or more): [Assignment: organization-defined frequency]; prior to a new scan; when new vulnerabilities are identified and reported].
Supplemental Guidance: Related controls: SI-3, SI-5. |
link |
2 |
FedRAMP_Moderate_R4 |
RA-5(3) |
FedRAMP_Moderate_R4_RA-5(3) |
FedRAMP Moderate RA-5 (3) |
Risk Assessment |
Breadth / Depth Of Coverage |
Shared |
n/a |
The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked). |
link |
2 |
FedRAMP_Moderate_R4 |
RA-5(6) |
FedRAMP_Moderate_R4_RA-5(6) |
FedRAMP Moderate RA-5 (6) |
Risk Assessment |
Automated Trend Analyses |
Shared |
n/a |
The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities.
Supplemental Guidance: Related controls: IR-4, IR-5, SI-4. |
link |
5 |
FedRAMP_Moderate_R4 |
SA-10 |
FedRAMP_Moderate_R4_SA-10 |
FedRAMP Moderate SA-10 |
System And Services Acquisition |
Developer Configuration Management |
Shared |
n/a |
The organization requires the developer of the information system, system component, or information system service to:
a. Perform configuration management during system, component, or service [Selection (one or more): design; development; implementation; operation];
b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items under configuration management];
c. Implement only organization-approved changes to the system, component, or service;
d. Document approved changes to the system, component, or service and the potential security impacts of such changes; and
e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel].
Supplemental Guidance: This control also applies to organizations conducting internal information systems development and integration. Organizations consider the quality and completeness of the configuration management activities conducted by developers as evidence of applying effective security safeguards. Safeguards include, for example, protecting from unauthorized modification or destruction, the master copies of all material used to generate security-relevant portions of the system hardware, software, and firmware. Maintaining the integrity of changes to the information system, information system component, or information system service requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes. Configuration items that are placed under configuration management (if existence/use is required by other security controls) include: the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and software/firmware source code with previous versions; and test fixtures and documentation. Depending on the mission/business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance phases of the life cycle. Related controls: CM-3, CM-4, CM-9, SA-12, SI-2.
References: NIST Special Publication 800-128. |
link |
9 |
FedRAMP_Moderate_R4 |
SA-11 |
FedRAMP_Moderate_R4_SA-11 |
FedRAMP Moderate SA-11 |
System And Services Acquisition |
Developer Security Testing And Evaluation |
Shared |
n/a |
The organization requires the developer of the information system, system component, or information system service to:
a. Create and implement a security assessment plan;
b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage];
c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation;
d. Implement a verifiable flaw remediation process; and
e. Correct flaws identified during security testing/evaluation.
Supplemental Guidance: Developmental security testing/evaluation occurs at all post‐design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers 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. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2.
References: ISO/IEC 15408; NIST Special Publication 800-53A; Web: http://nvd.nist.gov, http://cwe.mitre.org, http://cve.mitre.org, http://capec.mitre.org. |
link |
3 |
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 |
18 |
FedRAMP_Moderate_R4 |
SI-2(2) |
FedRAMP_Moderate_R4_SI-2(2) |
FedRAMP Moderate SI-2 (2) |
System And Information Integrity |
Automated Flaw Remediation Status |
Shared |
n/a |
The organization employs automated mechanisms [Assignment: organization-defined frequency] to determine the state of information system components with regard to flaw remediation.
Supplemental Guidance: Related controls: CM-6, SI-4. |
link |
2 |
hipaa |
0201.09j1Organizational.124-09.j |
hipaa-0201.09j1Organizational.124-09.j |
0201.09j1Organizational.124-09.j |
02 Endpoint Protection |
0201.09j1Organizational.124-09.j 09.04 Protection Against Malicious and Mobile Code |
Shared |
n/a |
Anti-virus and anti-spyware are installed, operating and updated on all end-user devices to conduct periodic scans of the systems to identify and remove unauthorized software. Server environments for which the server software developer specifically recommends not installing host-based anti-virus and anti-spyware software are addressed via a network-based malware detection (NBMD) solution. |
|
15 |
hipaa |
0216.09j2Organizational.9-09.j |
hipaa-0216.09j2Organizational.9-09.j |
0216.09j2Organizational.9-09.j |
02 Endpoint Protection |
0216.09j2Organizational.9-09.j 09.04 Protection Against Malicious and Mobile Code |
Shared |
n/a |
For systems considered not commonly affected by malicious software, the organization performs periodic assessments to identify and evaluate evolving malware threats to confirm whether such systems continue to not require anti-virus software. |
|
13 |
hipaa |
0217.09j2Organizational.10-09.j |
hipaa-0217.09j2Organizational.10-09.j |
0217.09j2Organizational.10-09.j |
02 Endpoint Protection |
0217.09j2Organizational.10-09.j 09.04 Protection Against Malicious and Mobile Code |
Shared |
n/a |
The organization configures malicious code and spam protection mechanisms to (i) perform periodic scans of the information system according to organization guidelines; (ii) perform real-time scans of files from external sources at endpoints and network entry/exit points as the files are downloaded, opened, or executed in accordance with organizational security policy; and, (iii) block malicious code, quarantine malicious code, or send an alert to the administrator in response to malicious code detection. |
|
25 |
hipaa |
0228.09k2Organizational.3-09.k |
hipaa-0228.09k2Organizational.3-09.k |
0228.09k2Organizational.3-09.k |
02 Endpoint Protection |
0228.09k2Organizational.3-09.k 09.04 Protection Against Malicious and Mobile Code |
Shared |
n/a |
Rules for the migration of software from development to operational status are defined and documented by the organization hosting the affected application(s), including that development, test, and operational systems are separated (physically or virtually) to reduce the risks of unauthorized access or changes to the operational system. |
|
11 |
hipaa |
0603.06g2Organizational.1-06.g |
hipaa-0603.06g2Organizational.1-06.g |
0603.06g2Organizational.1-06.g |
06 Configuration Management |
0603.06g2Organizational.1-06.g 06.02 Compliance with Security Policies and Standards, and Technical Compliance |
Shared |
n/a |
Automated compliance tools are used when possible. |
|
6 |
hipaa |
0613.06h1Organizational.12-06.h |
hipaa-0613.06h1Organizational.12-06.h |
0613.06h1Organizational.12-06.h |
06 Configuration Management |
0613.06h1Organizational.12-06.h 06.02 Compliance with Security Policies and Standards, and Technical Compliance |
Shared |
n/a |
The organization performs annual checks on the technical security configuration of systems, either manually by an individual with experience with the systems and/or with the assistance of automated software tools, and takes appropriate action if non-compliance is found. |
|
2 |
hipaa |
0614.06h2Organizational.12-06.h |
hipaa-0614.06h2Organizational.12-06.h |
0614.06h2Organizational.12-06.h |
06 Configuration Management |
0614.06h2Organizational.12-06.h 06.02 Compliance with Security Policies and Standards, and Technical Compliance |
Shared |
n/a |
Technical compliance checks are performed by an experienced specialist with the assistance of industry standard automated tools, which generate a technical report for subsequent interpretation. These checks are performed annually, but more frequently where needed, based on risk as part of an official risk assessment process. |
|
6 |
hipaa |
0615.06h2Organizational.3-06.h |
hipaa-0615.06h2Organizational.3-06.h |
0615.06h2Organizational.3-06.h |
06 Configuration Management |
0615.06h2Organizational.3-06.h 06.02 Compliance with Security Policies and Standards, and Technical Compliance |
Shared |
n/a |
Technical compliance checks are used to help support technical interoperability. |
|
1 |
hipaa |
0628.10h1System.6-10.h |
hipaa-0628.10h1System.6-10.h |
0628.10h1System.6-10.h |
06 Configuration Management |
0628.10h1System.6-10.h 10.04 Security of System Files |
Shared |
n/a |
If systems or system components in production are no longer supported by the developer, vendor, or manufacturer, the organization is able to provide evidence of a formal migration plan approved by management to replace the system or system components. |
|
4 |
hipaa |
0635.10k1Organizational.12-10.k |
hipaa-0635.10k1Organizational.12-10.k |
0635.10k1Organizational.12-10.k |
06 Configuration Management |
0635.10k1Organizational.12-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
Managers responsible for application systems are also responsible for the strict control (security) of the project or support environment and ensure that all proposed system changes are reviewed to check that they do not compromise the security of either the system or the operating environment. |
|
9 |
hipaa |
0639.10k2Organizational.78-10.k |
hipaa-0639.10k2Organizational.78-10.k |
0639.10k2Organizational.78-10.k |
06 Configuration Management |
0639.10k2Organizational.78-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
Installation checklists and vulnerability scans are used to validate the configuration of servers, workstations, devices, and appliances, and ensure the configuration meets minimum standards. |
|
8 |
hipaa |
0640.10k2Organizational.1012-10.k |
hipaa-0640.10k2Organizational.1012-10.k |
0640.10k2Organizational.1012-10.k |
06 Configuration Management |
0640.10k2Organizational.1012-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
Where development is outsourced, change control procedures to address security are included in the contract(s) and specifically require the developer to track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel or roles. |
|
22 |
hipaa |
0643.10k3Organizational.3-10.k |
hipaa-0643.10k3Organizational.3-10.k |
0643.10k3Organizational.3-10.k |
06 Configuration Management |
0643.10k3Organizational.3-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
The organization (i) establishes and documents mandatory configuration settings for information technology products employed within the information system using the latest security configuration baselines; (ii) identifies, documents, and approves exceptions from the mandatory established configuration settings for individual components based on explicit operational requirements; and, (iii) monitors and controls changes to the configuration settings in accordance with organizational policies and procedures. |
|
17 |
hipaa |
0644.10k3Organizational.4-10.k |
hipaa-0644.10k3Organizational.4-10.k |
0644.10k3Organizational.4-10.k |
06 Configuration Management |
0644.10k3Organizational.4-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
The organization employs automated mechanisms to (i) centrally manage, apply, and verify configuration settings; (ii) respond to unauthorized changes to network and system security-related configuration settings; and, (iii) enforce access restrictions and auditing of the enforcement actions. |
|
20 |
hipaa |
0663.10h1System.7-10.h |
hipaa-0663.10h1System.7-10.h |
0663.10h1System.7-10.h |
06 Configuration Management |
0663.10h1System.7-10.h 10.04 Security of System Files |
Shared |
n/a |
The operating system has in place supporting technical controls such as antivirus, file integrity monitoring, host-based (personal) firewalls or port filtering tools, and logging as part of its baseline. |
|
16 |
hipaa |
0671.10k1System.1-10.k |
hipaa-0671.10k1System.1-10.k |
0671.10k1System.1-10.k |
06 Configuration Management |
0671.10k1System.1-10.k 10.05 Security In Development and Support Processes |
Shared |
n/a |
The organization manages changes to mobile device operating systems, patch levels, and/or applications through a formal change management process. |
|
16 |
ISO27001-2013 |
A.12.1.2 |
ISO27001-2013_A.12.1.2 |
ISO 27001:2013 A.12.1.2 |
Operations Security |
Change management |
Shared |
n/a |
Changes to organization, business processes, information processing facilities and systems that affect information security shall be controlled. |
link |
27 |
ISO27001-2013 |
A.12.1.4 |
ISO27001-2013_A.12.1.4 |
ISO 27001:2013 A.12.1.4 |
Operations Security |
Separation of development, testing and operational environments |
Shared |
n/a |
Development, testing, and operational environments shall be separated to reduce the risks of unauthorized access or changes to the operational environment. |
link |
10 |
ISO27001-2013 |
A.12.5.1 |
ISO27001-2013_A.12.5.1 |
ISO 27001:2013 A.12.5.1 |
Operations Security |
Installation of software on operational systems |
Shared |
n/a |
Procedures shall be implemented to control the installation of software on operational systems. |
link |
18 |
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 |
12 |
ISO27001-2013 |
A.12.6.2 |
ISO27001-2013_A.12.6.2 |
ISO 27001:2013 A.12.6.2 |
Operations Security |
Restrictions on software installation |
Shared |
n/a |
Rules governing the installation of software by users shall be established and implemented. |
link |
18 |
ISO27001-2013 |
A.14.2.2 |
ISO27001-2013_A.14.2.2 |
ISO 27001:2013 A.14.2.2 |
System Acquisition, Development And Maintenance |
System change control procedures |
Shared |
n/a |
Changes to systems within the development lifecycle shall be controlled by the use of formal change control procedures. |
link |
25 |
ISO27001-2013 |
A.14.2.3 |
ISO27001-2013_A.14.2.3 |
ISO 27001:2013 A.14.2.3 |
System Acquisition, Development And Maintenance |
Technical review of applications after operating platform changes |
Shared |
n/a |
When operating platforms are changed, business critical applications shall be reviewed and tested to ensure there is no adverse impact on organizational operations or security. |
link |
18 |
ISO27001-2013 |
A.14.2.4 |
ISO27001-2013_A.14.2.4 |
ISO 27001:2013 A.14.2.4 |
System Acquisition, Development And Maintenance |
Restrictions on changes to software packages |
Shared |
n/a |
Modifications to software packages shall be discouraged, limited to necessary changes and all changes shall be strictly controlled. |
link |
24 |
ISO27001-2013 |
A.14.2.6 |
ISO27001-2013_A.14.2.6 |
ISO 27001:2013 A.14.2.6 |
System Acquisition, Development And Maintenance |
Secure development environment |
Shared |
n/a |
Organizations shall establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development lifecycle. |
link |
10 |
ISO27001-2013 |
A.14.2.7 |
ISO27001-2013_A.14.2.7 |
ISO 27001:2013 A.14.2.7 |
System Acquisition, Development And Maintenance |
Outsourced development |
Shared |
n/a |
The organization shall supervise and monitor the activity of outsourced system development. |
link |
28 |
ISO27001-2013 |
A.14.2.8 |
ISO27001-2013_A.14.2.8 |
ISO 27001:2013 A.14.2.8 |
System Acquisition, Development And Maintenance |
System security testing |
Shared |
n/a |
Testing of security functionality shall be carried out during development. |
link |
8 |
ISO27001-2013 |
A.14.3.1 |
ISO27001-2013_A.14.3.1 |
ISO 27001:2013 A.14.3.1 |
System Acquisition, Development And Maintenance |
Protection of test data |
Shared |
n/a |
Test data shall be selected carefully, protected and controlled. |
link |
11 |
ISO27001-2013 |
A.16.1.3 |
ISO27001-2013_A.16.1.3 |
ISO 27001:2013 A.16.1.3 |
Information Security Incident Management |
Reporting information security weaknesses |
Shared |
n/a |
Employees and contractors using the organization's information systems and services shall be required to note and report any observed or suspected information security weaknesses in systems or services. |
link |
4 |
ISO27001-2013 |
C.8.1 |
ISO27001-2013_C.8.1 |
ISO 27001:2013 C.8.1 |
Operation |
Operational planning and control |
Shared |
n/a |
The organization shall plan, implement and control the processes needed to meet information security
requirements, and to implement the actions determined in 6.1. The organization shall also implement
plans to achieve information security objectives determined in 6.2.
The organization shall keep documented information to the extent necessary to have confidence that
the processes have been carried out as planned.
The organization shall control planned changes and review the consequences of unintended changes,
taking action to mitigate any adverse effects, as necessary.
The organization shall ensure that outsourced processes are determined and controlled. |
link |
21 |
|
mp.eq.2 User session lockout |
mp.eq.2 User session lockout |
404 not found |
|
|
|
n/a |
n/a |
|
29 |
|
mp.sw.1 IT Aplications development |
mp.sw.1 IT Aplications development |
404 not found |
|
|
|
n/a |
n/a |
|
51 |
|
mp.sw.2 Acceptance and commissioning |
mp.sw.2 Acceptance and commissioning |
404 not found |
|
|
|
n/a |
n/a |
|
60 |
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 |
20 |
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 |
19 |
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 |
20 |
NIST_SP_800-171_R2_3 |
.4.2 |
NIST_SP_800-171_R2_3.4.2 |
NIST SP 800-171 R2 3.4.2 |
Configuration Management |
Establish and enforce security configuration settings for information technology products employed in organizational systems. |
Shared |
Microsoft and the customer share responsibilities for implementing this requirement. |
Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture or functionality of the system. Information technology products for which security-related configuration settings can be defined include mainframe computers, servers, workstations, input and output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security parameters are those parameters impacting the security state of systems including the parameters required to satisfy other security requirements. Security parameters include: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific configuration settings for systems. The established settings become part of the systems configuration baseline. Common secure configurations (also referred to as security configuration checklists, lockdown and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. [SP 800-70] and [SP 800-128] provide guidance on security configuration settings. |
link |
25 |
NIST_SP_800-53_R4 |
CM-6 |
NIST_SP_800-53_R4_CM-6 |
NIST SP 800-53 Rev. 4 CM-6 |
Configuration Management |
Configuration Settings |
Shared |
n/a |
The organization:
a. Establishes and documents configuration settings for information technology products employed within the information system using [Assignment: organization-defined security configuration checklists] that reflect the most restrictive mode consistent with operational requirements;
b. Implements the configuration settings;
c. Identifies, documents, and approves any deviations from established configuration settings for [Assignment: organization-defined information system components] based on [Assignment: organization-defined operational requirements]; and
d. Monitors and controls changes to the configuration settings in accordance with organizational policies and procedures.
Supplemental Guidance: Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the information system that affect the security posture and/or functionality of the system. Information technology products for which security- related configuration settings can be defined include, for example, mainframe computers, servers (e.g., database, electronic mail, authentication, web, proxy, file, domain name), workstations, input/output devices (e.g., scanners, copiers, and printers), network components (e.g., firewalls, routers, gateways, voice and data switches, wireless access points, network appliances, sensors), operating systems, middleware, and applications. Security-related parameters are those parameters impacting the security state of information systems including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: (i) registry settings; (ii) account, file, directory permission settings; and (iii) settings for functions, ports, protocols, services, and remote connections. Organizations establish organization-wide configuration settings and subsequently derive specific settings for information systems. The established settings become part of the systems configuration baseline.
Common secure configurations (also referred to as security configuration checklists, lockdown
and hardening guides, security reference guides, security technical implementation guides) provide recognized, standardized, and established benchmarks that stipulate secure configuration settings for specific information technology platforms/products and instructions for configuring those information system components to meet operational requirements. Common secure configurations can be developed by a variety of organizations including, for example, information technology product developers, manufacturers, vendors, consortia, academia, industry, federal agencies, and other organizations in the public and private sectors. Common secure configurations include the United States Government Configuration Baseline (USGCB) which affects the implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation Protocol (SCAP) and the defined standards within the protocol (e.g., Common Configuration Enumeration) provide an effective method to uniquely identify, track, and control configuration settings. OMB establishes federal policy on configuration requirements for federal information systems. Related controls: AC-19, CM-2, CM-3, CM-7, SI-4.
References: OMB Memoranda 07-11, 07-18, 08-22; NIST Special Publications 800-70, 800-128; Web: http://nvd.nist.gov, http://checklists.nist.gov, http://www.nsa.gov. |
link |
23 |
NIST_SP_800-53_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 |
19 |
NIST_SP_800-53_R4 |
RA-5(1) |
NIST_SP_800-53_R4_RA-5(1) |
NIST SP 800-53 Rev. 4 RA-5 (1) |
Risk Assessment |
Update Tool Capability |
Shared |
n/a |
The organization employs vulnerability scanning tools that include the capability to readily update the information system vulnerabilities to be scanned.
Supplemental Guidance: The vulnerabilities to be scanned need to be readily updated as new vulnerabilities are discovered, announced, and scanning methods developed. This updating process helps to ensure that potential vulnerabilities in the information system are identified and addressed as quickly as possible. Related controls: SI-3, SI-7. |
link |
2 |
NIST_SP_800-53_R4 |
RA-5(2) |
NIST_SP_800-53_R4_RA-5(2) |
NIST SP 800-53 Rev. 4 RA-5 (2) |
Risk Assessment |
Update By Frequency / Prior To New Scan / When Identified |
Shared |
n/a |
The organization updates the information system vulnerabilities scanned [Selection (one or more): [Assignment: organization-defined frequency]; prior to a new scan; when new vulnerabilities are identified and reported].
Supplemental Guidance: Related controls: SI-3, SI-5. |
link |
2 |
NIST_SP_800-53_R4 |
RA-5(3) |
NIST_SP_800-53_R4_RA-5(3) |
NIST SP 800-53 Rev. 4 RA-5 (3) |
Risk Assessment |
Breadth / Depth Of Coverage |
Shared |
n/a |
The organization employs vulnerability scanning procedures that can identify the breadth and depth of coverage (i.e., information system components scanned and vulnerabilities checked). |
link |
2 |
NIST_SP_800-53_R4 |
RA-5(6) |
NIST_SP_800-53_R4_RA-5(6) |
NIST SP 800-53 Rev. 4 RA-5 (6) |
Risk Assessment |
Automated Trend Analyses |
Shared |
n/a |
The organization employs automated mechanisms to compare the results of vulnerability scans over time to determine trends in information system vulnerabilities.
Supplemental Guidance: Related controls: IR-4, IR-5, SI-4. |
link |
5 |
NIST_SP_800-53_R4 |
SA-10 |
NIST_SP_800-53_R4_SA-10 |
NIST SP 800-53 Rev. 4 SA-10 |
System And Services Acquisition |
Developer Configuration Management |
Shared |
n/a |
The organization requires the developer of the information system, system component, or information system service to:
a. Perform configuration management during system, component, or service [Selection (one or more): design; development; implementation; operation];
b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items under configuration management];
c. Implement only organization-approved changes to the system, component, or service;
d. Document approved changes to the system, component, or service and the potential security impacts of such changes; and
e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel].
Supplemental Guidance: This control also applies to organizations conducting internal information systems development and integration. Organizations consider the quality and completeness of the configuration management activities conducted by developers as evidence of applying effective security safeguards. Safeguards include, for example, protecting from unauthorized modification or destruction, the master copies of all material used to generate security-relevant portions of the system hardware, software, and firmware. Maintaining the integrity of changes to the information system, information system component, or information system service requires configuration control throughout the system development life cycle to track authorized changes and prevent unauthorized changes. Configuration items that are placed under configuration management (if existence/use is required by other security controls) include: the formal model; the functional, high-level, and low-level design specifications; other design data; implementation documentation; source code and hardware schematics; the running version of the object code; tools for comparing new versions of security-relevant hardware descriptions and software/firmware source code with previous versions; and test fixtures and documentation. Depending on the mission/business needs of organizations and the nature of the contractual relationships in place, developers may provide configuration management support during the operations and maintenance phases of the life cycle. Related controls: CM-3, CM-4, CM-9, SA-12, SI-2.
References: NIST Special Publication 800-128. |
link |
9 |
NIST_SP_800-53_R4 |
SA-11 |
NIST_SP_800-53_R4_SA-11 |
NIST SP 800-53 Rev. 4 SA-11 |
System And Services Acquisition |
Developer Security Testing And Evaluation |
Shared |
n/a |
The organization requires the developer of the information system, system component, or information system service to:
a. Create and implement a security assessment plan;
b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage];
c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation;
d. Implement a verifiable flaw remediation process; and
e. Correct flaws identified during security testing/evaluation.
Supplemental Guidance: Developmental security testing/evaluation occurs at all post‐design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers 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. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2.
References: ISO/IEC 15408; NIST Special Publication 800-53A; Web: http://nvd.nist.gov, http://cwe.mitre.org, http://cve.mitre.org, http://capec.mitre.org. |
link |
3 |
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 |
18 |
NIST_SP_800-53_R4 |
SI-2(2) |
NIST_SP_800-53_R4_SI-2(2) |
NIST SP 800-53 Rev. 4 SI-2 (2) |
System And Information Integrity |
Automated Flaw Remediation Status |
Shared |
n/a |
The organization employs automated mechanisms [Assignment: organization-defined frequency] to determine the state of information system components with regard to flaw remediation.
Supplemental Guidance: Related controls: CM-6, SI-4. |
link |
2 |
NIST_SP_800-53_R5 |
CM-6 |
NIST_SP_800-53_R5_CM-6 |
NIST SP 800-53 Rev. 5 CM-6 |
Configuration Management |
Configuration Settings |
Shared |
n/a |
a. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations];
b. Implement the configuration settings;
c. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components] based on [Assignment: organization-defined operational requirements]; and
d. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures. |
link |
23 |
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 |
19 |
NIST_SP_800-53_R5 |
RA-5(2) |
NIST_SP_800-53_R5_RA-5(2) |
NIST SP 800-53 Rev. 5 RA-5 (2) |
Risk Assessment |
Update Vulnerabilities to Be Scanned |
Shared |
n/a |
Update the system vulnerabilities to be scanned [Selection (OneOrMore): [Assignment: organization-defined frequency] ;prior to a new scan;when new vulnerabilities are identified and reported] . |
link |
2 |
NIST_SP_800-53_R5 |
RA-5(3) |
NIST_SP_800-53_R5_RA-5(3) |
NIST SP 800-53 Rev. 5 RA-5 (3) |
Risk Assessment |
Breadth and Depth of Coverage |
Shared |
n/a |
Define the breadth and depth of vulnerability scanning coverage. |
link |
2 |
NIST_SP_800-53_R5 |
RA-5(6) |
NIST_SP_800-53_R5_RA-5(6) |
NIST SP 800-53 Rev. 5 RA-5 (6) |
Risk Assessment |
Automated Trend Analyses |
Shared |
n/a |
Compare the results of multiple vulnerability scans using [Assignment: organization-defined automated mechanisms]. |
link |
5 |
NIST_SP_800-53_R5 |
SA-10 |
NIST_SP_800-53_R5_SA-10 |
NIST SP 800-53 Rev. 5 SA-10 |
System and Services Acquisition |
Developer Configuration Management |
Shared |
n/a |
Require the developer of the system, system component, or system service to:
a. Perform configuration management during system, component, or service [Selection (OneOrMore): design;development;implementation;operation;disposal] ;
b. Document, manage, and control the integrity of changes to [Assignment: organization-defined configuration items under configuration management];
c. Implement only organization-approved changes to the system, component, or service;
d. Document approved changes to the system, component, or service and the potential security and privacy impacts of such changes; and
e. Track security flaws and flaw resolution within the system, component, or service and report findings to [Assignment: organization-defined personnel]. |
link |
9 |
NIST_SP_800-53_R5 |
SA-11 |
NIST_SP_800-53_R5_SA-11 |
NIST SP 800-53 Rev. 5 SA-11 |
System and Services Acquisition |
Developer Testing and Evaluation |
Shared |
n/a |
Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to:
a. Develop and implement a plan for ongoing security and privacy control assessments;
b. Perform [Selection (OneOrMore): unit;integration;system;regression] testing/evaluation [Assignment: organization-defined frequency] at [Assignment: organization-defined depth and coverage];
c. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation;
d. Implement a verifiable flaw remediation process; and
e. Correct flaws identified during testing and evaluation. |
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 |
18 |
NIST_SP_800-53_R5 |
SI-2(2) |
NIST_SP_800-53_R5_SI-2(2) |
NIST SP 800-53 Rev. 5 SI-2 (2) |
System and Information Integrity |
Automated Flaw Remediation Status |
Shared |
n/a |
Determine if system components have applicable security-relevant software and firmware updates installed using [Assignment: organization-defined automated mechanisms] [Assignment: organization-defined frequency]. |
link |
2 |
|
op.exp.4 Security maintenance and updates |
op.exp.4 Security maintenance and updates |
404 not found |
|
|
|
n/a |
n/a |
|
78 |
|
op.exp.5 Change management |
op.exp.5 Change management |
404 not found |
|
|
|
n/a |
n/a |
|
71 |
|
op.exp.7 Incident management |
op.exp.7 Incident management |
404 not found |
|
|
|
n/a |
n/a |
|
103 |
|
org.2 Security regulations |
org.2 Security regulations |
404 not found |
|
|
|
n/a |
n/a |
|
100 |
|
org.4 Authorization process |
org.4 Authorization process |
404 not found |
|
|
|
n/a |
n/a |
|
126 |
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 |
6 |
PCI_DSS_v4.0 |
11.3.1.1 |
PCI_DSS_v4.0_11.3.1.1 |
PCI DSS v4.0 11.3.1.1 |
Requirement 11: Test Security of Systems and Networks Regularly |
External and internal vulnerabilities are regularly identified, prioritized, and addressed |
Shared |
n/a |
All other applicable vulnerabilities (those not ranked as high-risk or critical (per the entity’s vulnerability risk rankings defined at Requirement
6.3.1) are managed as follows:
• Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
• Rescans are conducted as needed. |
link |
2 |
PCI_DSS_v4.0 |
11.3.1.3 |
PCI_DSS_v4.0_11.3.1.3 |
PCI DSS v4.0 11.3.1.3 |
Requirement 11: Test Security of Systems and Networks Regularly |
External and internal vulnerabilities are regularly identified, prioritized, and addressed |
Shared |
n/a |
Internal scans are performed after any significant change as follows:
• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.
• Rescans are conducted as needed.
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV). |
link |
2 |
PCI_DSS_v4.0 |
11.3.2 |
PCI_DSS_v4.0_11.3.2 |
PCI DSS v4.0 11.3.2 |
Requirement 11: Test Security of Systems and Networks Regularly |
External and internal vulnerabilities are regularly identified, prioritized, and addressed |
Shared |
n/a |
External vulnerability scans are performed as follows:
• At least once every three months.
• By PCI SSC Approved Scanning Vendor (ASV).
• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.
• Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan. |
link |
2 |
PCI_DSS_v4.0 |
11.3.2.1 |
PCI_DSS_v4.0_11.3.2.1 |
PCI DSS v4.0 11.3.2.1 |
Requirement 11: Test Security of Systems and Networks Regularly |
External and internal vulnerabilities are regularly identified, prioritized, and addressed |
Shared |
n/a |
External scans are performed after any significant change as follows:
• Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.
• Rescans are conducted as needed.
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV). |
link |
2 |
PCI_DSS_v4.0 |
12.3.4 |
PCI_DSS_v4.0_12.3.4 |
PCI DSS v4.0 12.3.4 |
Requirement 12: Support Information Security with Organizational Policies and Programs |
Risks to the cardholder data environment are formally identified, evaluated, and managed |
Shared |
n/a |
Hardware and software technologies in use are reviewed at least once every 12 months, including at least the following:
• Analysis that the technologies continue to receive security fixes from vendors promptly.
• Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance.
• Documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a technology.
• Documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced “end of life” plans. |
link |
3 |
PCI_DSS_v4.0 |
2.2.5 |
PCI_DSS_v4.0_2.2.5 |
PCI DSS v4.0 2.2.5 |
Requirement 02: Apply Secure Configurations to All System Components |
System components are configured and managed securely |
Shared |
n/a |
If any insecure services, protocols, or daemons are present:
• Business justification is documented.
• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons. |
link |
2 |
PCI_DSS_v4.0 |
6.3.1 |
PCI_DSS_v4.0_6.3.1 |
PCI DSS v4.0 6.3.1 |
Requirement 06: Develop and Maintain Secure Systems and Software |
Security vulnerabilities are identified and addressed |
Shared |
n/a |
Security vulnerabilities are identified and managed as follows:
• New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).
• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
• Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.
• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered. |
link |
4 |
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 |
6 |
SOC_2 |
CC3.2 |
SOC_2_CC3.2 |
SOC 2 Type 2 CC3.2 |
Risk Assessment |
COSO Principle 7 |
Shared |
The customer is responsible for implementing this recommendation. |
Points of focus specified in the COSO framework:
• Includes Entity, Subsidiary, Division, Operating Unit, and Functional Levels — The
entity identifies and assesses risk at the entity, subsidiary, division, operating unit,
and functional levels relevant to the achievement of objectives.
• Analyzes Internal and External Factors — Risk identification considers both internal
and external factors and their impact on the achievement of objectives.
• Involves Appropriate Levels of Management — The entity puts into place effective risk assessment mechanisms that involve appropriate levels of management.
• Estimates Significance of Risks Identified — Identified risks are analyzed through a
process that includes estimating the potential significance of the risk.
• Determines How to Respond to Risks — Risk assessment includes considering how
the risk should be managed and whether to accept, avoid, reduce, or share the risk.
Additional points of focus specifically related to all engagements using the trust services criteria:
• Identifies and Assesses Criticality of Information Assets and Identifies Threats and
Vulnerabilities — The entity's risk identification and assessment process includes
(1) identifying information assets, including physical devices and systems, virtual
devices, software, data and data flows, external information systems, and organizational roles; (2) assessing the criticality of those information assets; (3) identifying
the threats to the assets from intentional (including malicious) and unintentional
acts and environmental events; and (4) identifying the vulnerabilities of the identified assets.
• Analyzes Threats and Vulnerabilities From Vendors, Business Partners, and Other
Parties — The entity's risk assessment process includes the analysis of potential
threats and vulnerabilities arising from vendors providing goods and services, as
well as threats and vulnerabilities arising from business partners, customers, and
others with access to the entity's information systems.
• Considers the Significance of the Risk — The entity’s consideration of the potential
significance of the identified risks includes (1) determining the criticality of identified assets in meeting objectives; (2) assessing the impact of identified threats and
vulnerabilities in meeting objectives; (3) assessing the likelihood of identified
threats; and (4) determining the risk associated with assets based on asset criticality, threat impact, and likelihood. |
|
11 |
SOC_2 |
CC7.1 |
SOC_2_CC7.1 |
SOC 2 Type 2 CC7.1 |
System Operations |
Detection and monitoring of new vulnerabilities |
Shared |
The customer is responsible for implementing this recommendation. |
• Uses Defined Configuration Standards — Management has defined configuration
standards.
• Monitors Infrastructure and Software — The entity monitors infrastructure and
software for noncompliance with the standards, which could threaten the achievement of the entity's objectives.
• Implements Change-Detection Mechanisms — The IT system includes a changedetection mechanism (for example, file integrity monitoring tools) to alert personnel
to unauthorized modifications of critical system files, configuration files, or content
files.
• Detects Unknown or Unauthorized Components — Procedures are in place to detect the introduction of unknown or unauthorized components.
• Conducts Vulnerability Scans — The entity conducts vulnerability scans designed to
identify potential vulnerabilities or misconfigurations on a periodic basis and after
any significant change in the environment and takes action to remediate identified
deficiencies on a timely basis |
|
15 |
SWIFT_CSCF_v2022 |
2.1 |
SWIFT_CSCF_v2022_2.1 |
SWIFT CSCF v2022 2.1 |
2. Reduce Attack Surface and Vulnerabilities |
Ensure the confidentiality, integrity, and authenticity of application data flows between local SWIFT-related components. |
Shared |
n/a |
Confidentiality, integrity, and authentication mechanisms are implemented to protect SWIFT-related component-to-component or system-to-system data flows. |
link |
36 |
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 |
SWIFT_CSCF_v2022 |
2.7 |
SWIFT_CSCF_v2022_2.7 |
SWIFT CSCF v2022 2.7 |
2. Reduce Attack Surface and Vulnerabilities |
Identify known vulnerabilities within the local SWIFT environment by implementing a regular vulnerability scanning process and act upon results. |
Shared |
n/a |
Secure zone (including dedicated operator PC) systems are scanned for vulnerabilities using an up-to-date, reputable scanning tool and results are considered for appropriate resolving actions. |
link |
14 |
SWIFT_CSCF_v2022 |
6.1 |
SWIFT_CSCF_v2022_6.1 |
SWIFT CSCF v2022 6.1 |
6. Detect Anomalous Activity to Systems or Transaction Records |
Ensure that local SWIFT infrastructure is protected against malware and act upon results. |
Shared |
n/a |
Anti-malware software from a reputable vendor is installed, kept up-to-date on all systems, and results are considered for appropriate resolving actions. |
link |
29 |
SWIFT_CSCF_v2022 |
6.4 |
SWIFT_CSCF_v2022_6.4 |
SWIFT CSCF v2022 6.4 |
6. Detect Anomalous Activity to Systems or Transaction Records |
Record security events and detect anomalous actions and operations within the local SWIFT environment. |
Shared |
n/a |
Capabilities to detect anomalous activity are implemented, and a process or tool is in place to keep and review logs. |
link |
51 |
SWIFT_CSCF_v2022 |
8.5 |
SWIFT_CSCF_v2022_8.5 |
SWIFT CSCF v2022 8.5 |
8. Set and Monitor Performance |
Ensure early availability of SWIFTNet releases and of the FIN standards for proper testing by the customer before going live. |
Shared |
n/a |
Ensure early availability of SWIFTNet releases and of the FIN standards for proper testing by the customer before going live. |
link |
11 |