AzPolicyAdvertizer

last sync: 2024-Apr-25 17:46:59 UTC

Remediate information system flaws | Regulatory Compliance - Operational

Azure BuiltIn Policy definition

Source Azure Portal
Display name Remediate information system flaws
Id be38a620-000b-21cf-3cb3-ea151b704c3b
Version 1.1.0
Details on versioning
Category Regulatory Compliance
Microsoft Learn
Description CMA_0427 - Remediate information system flaws
Additional metadata Name/Id: CMA_0427 / CMA_0427
Category: Operational
Title: Remediate information system flaws
Ownership: Customer
Description: Microsoft recommends that your organization create System and Information Integrity policies and standard operating procedures that include identifying, reporting, and correcting information system flaws for all information systems under your organization's control. It is recommended to measure and monitor the time between flaw identification and flaw remediation, and to establish benchmarks for taking corrective actions on such flaws. We recommend that your organization apply patches and software updates in a timely manner using an organization defined tool. It is also recommended for the organization to ensure vendor support to minimize the occurrence of known technical vulnerabilities. Your organization is recommended to remove previous versions of software and firmware components after installing updated versions. We recommend that the organization identify missing patches on the endpoints and servers and maintain a patch management plan that includes the following: - Process for testing for critical patches and updates prior to installation - Turnaround time for patch deployment - Approval, monitoring, and tracking of patching activity - Roles and responsibilities for patch installations - Process for maintaining an up-to-date inventory of hardware and software platforms used - Prioritization for updating patches based on security impact analysis and - Mechanism to patch operating system and application updates of all mobile devices at given intervals Microsoft suggests that your organization implement the patches of security vulnerabilities on critical systems within a reasonable time frame, pertinent to the level of risk entailed, and review the patch management plan and procedures at least every 12 months or whenever there are major changes and update accordingly. It is also recommended that your organization document, track, report, and remediate deviations from security policies and standards and implement mitigating controls to reduce the risks. We recommend that outstanding deviations are reviewed at least every 12 months. It is also advised that your organization implement a File Integrity Monitoring (FIM) process to detect unauthorized changes to databases, files, programs, and system configurations. Microsoft recommends that your organization document End of Life/End of Support (EOL/EOS) for software and hardware products. It is recommended to identify, assess, and mitigate risk posed by the EOL technology systems, and to develop a refresh plan for the replacement of hardware and software before they reach EOS. If your organization has decided to keep software and hardware that are not capable of automatic updates, it is recommended that your organization implement a business process to apply manual updates regularly. Your organization should consider ensuring that secure web browsers are used across the organization and that individuals use properly patched workstations and clients to access all information systems. It is advised that your organization deploy a file integrity check process to detect unauthorized changes to databases, files, programs, and system configuration etc. Microsoft suggests that your organization promptly remediate issues and perform validation before identifying gaps as resolved. Further, it is recommended to document procedures for fixing flaws and review them whenever there are changes and at least every 12 months. Microsoft recommends that your organization maintain a register of known vulnerability that can affect your organization. It is recommended for cloud service providers to provide this information to customers so that customer is have the appropriate information on software updates aimed at fixing known vulnerabilities. NIST 800-53 recommends replacing system components when support for the components is no longer available from the developer, vendor, or manufacturer, or to provide continued support in-house or using a third-party vendor.
Requirements: The customer is responsible for implementing this recommendation.
Mode All
Type BuiltIn
Preview False
Deprecated False
Effect Default
Manual
Allowed
Manual, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types IF (1)
Microsoft.Resources/subscriptions
Compliance
The following 124 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 21
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 19
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 21
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 19
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. 18
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 19
ISO27001-2013 A.12.6.1 ISO27001-2013_A.12.6.1 ISO 27001:2013 A.12.6.1 Operations Security Management of technical vulnerabilities Shared n/a Information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risk. link 13
ISO27001-2013 A.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 19
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
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 22
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 21
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 23
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 21
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 19
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 21
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 19
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
PCI_DSS_v4.0 11.3.1 PCI_DSS_v4.0_11.3.1 PCI DSS v4.0 11.3.1 Requirement 11: Test Security of Systems and Networks Regularly External and internal vulnerabilities are regularly identified, prioritized, and addressed Shared n/a Internal vulnerability scans are performed as follows: • At least once every three months. • High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved. • Rescans are performed that confirm all high-risk and critical vulnerabilities as noted above) have been resolved. • Scan tool is kept up to date with latest vulnerability information. • Scans are performed by qualified personnel and organizational independence of the tester exists. link 7
PCI_DSS_v4.0 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 7
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 17
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 16
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 31
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 52
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
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v2.0.0 06f19060-9e68-4070-92ca-f15cc126059e Regulatory Compliance GA BuiltIn
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
NIST SP 800-171 Rev. 2 03055927-78bd-4236-86c0-f36125a10dc9 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
PCI DSS v4 c676748e-3af9-4e22-bc28-50feed564afb Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-09-27 16:35:32 change Minor (1.0.0 > 1.1.0)
2022-09-02 16:33:37 add be38a620-000b-21cf-3cb3-ea151b704c3b
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC