Merge pull request #222401 from bmansheim/fix-sql-va-links

Fix broken SQL VA links

Author: prmerger-automator[bot]

articles/defender-for-cloud/sql-azure-vulnerability-assessment-rules.md

@@ -91,7 +91,7 @@ SQL vulnerability assessment rules have five categories, which are in the follow
 |VA1265     |Auditing of both successful and failed login attempts for contained DB authentication should be enabled          |Medium         |SQL Server auditing configuration enables administrators to track users logging to SQL Server instances that they're responsible for. This rule checks that auditing is enabled for both successful and failed login attempts for contained DB authentication.         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance         |
 |VA1281     |All memberships for user-defined roles should be intended          |Medium         |User-defined roles are security principals defined by the user to group principals to easily manage permissions. Monitoring these roles is important to avoid having excessive permissions. Create a baseline that defines expected membership for each user-defined role. This rule checks whether all memberships for user-defined roles are as defined in the baseline.         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance<br/><br/>SQL Database<br/><br/>Azure Synapse         |
 |VA1283     |There should be at least 1 active audit in the system          |Low         |Auditing an instance of the SQL Server Database Engine or an individual database involves tracking and logging events that occur on the Database Engine. The SQL Server Audit object collects a single instance of server or database-level actions and groups of actions to monitor. This rule checks that there is at least one active audit in the system.         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance         |
-|VA2061     |Auditing should be enabled at the server level          |High         |Azure SQL Database Auditing tracks database events and writes them to an audit log in your Azure storage account. Auditing helps you understand database activity and gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violations as well as helps you meet regulatory compliance. For more information, see [Azure SQL Auditing](/azure/azure-sql/database/auditing-overview.md). This rule checks that auditing is enabled.         |<nobr/>SQL Database<br/><br/>Azure Synapse          |
+|VA2061     |Auditing should be enabled at the server level          |High         |Azure SQL Database Auditing tracks database events and writes them to an audit log in your Azure storage account. Auditing helps you understand database activity and gain insight into discrepancies and anomalies that could indicate business concerns or suspected security violations as well as helps you meet regulatory compliance. For more information, see [Azure SQL Auditing](/azure/azure-sql/database/auditing-overview). This rule checks that auditing is enabled.         |<nobr/>SQL Database<br/><br/>Azure Synapse          |
 
 ## Data Protection
 
@@ -105,14 +105,14 @@ SQL vulnerability assessment rules have five categories, which are in the follow
 |VA1223     |Certificate keys should use at least 2048 bits          |High         |Certificate keys are used in RSA and other encryption algorithms to protect data. These keys need to be of enough length to secure the user's data. This rule checks that the key's length is at least 2048 bits for all certificates.         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance<br/><br/>SQL Database<br/><br/>Azure Synapse         |
 |VA1224     |Asymmetric keys' length should be at least 2048 bits          |High         |Database asymmetric keys are used in many encryption algorithms these keys need to be of enough length to secure the encrypted data this rule checks that all asymmetric keys stored in the database are of length of at least 2048 bits         |<nobr>SQL Server 2012<nobr/><br/><br/><nobr>SQL Server 2014<nobr/><br/><br/>SQL Database         |
 |VA1279     |Force encryption should be enabled for TDS          |High         |When the Force Encryption option for the Database Engine is enabled all communications between client and server is encrypted regardless of whether the 'Encrypt connection' option (such as from SSMS) is checked or not. This rule checks that Force Encryption option is enabled.         |<nobr>SQL Server 2012+<nobr/>         |
-|VA2060     |SQL Threat Detection should be enabled at the server level          |Medium         |SQL Threat Detection provides a layer of security that detects potential vulnerabilities and anomalous activity in databases such as SQL injection attacks and unusual behavior patterns. When a potential threat is detected Threat Detection sends an actionable real-time alert by email and in Microsoft Defender for Cloud, which includes clear investigation and remediation steps for the specific threat. For more information, please see [Configure threat detection](/azure/azure-sql/database/threat-detection-configure.md). This check verifies that SQL Threat Detection is enabled         |<nobr/><br/>SQL Managed Instance<br/><br/>SQL Database<br/><br/>Azure Synapse         |
+|VA2060     |SQL Threat Detection should be enabled at the server level          |Medium         |SQL Threat Detection provides a layer of security that detects potential vulnerabilities and anomalous activity in databases such as SQL injection attacks and unusual behavior patterns. When a potential threat is detected Threat Detection sends an actionable real-time alert by email and in Microsoft Defender for Cloud, which includes clear investigation and remediation steps for the specific threat. For more information, please see [Configure threat detection](/azure/azure-sql/database/threat-detection-configure). This check verifies that SQL Threat Detection is enabled         |<nobr/><br/>SQL Managed Instance<br/><br/>SQL Database<br/><br/>Azure Synapse         |
 
 ## Installation Updates and Patches
 
 |Rule ID  |Rule Title  |Rule Severity  |Rule Description  |Platform  |
 |---------|---------|---------|---------|---------|
 | VA1018     |Latest updates should be installed          |High         |Microsoft periodically releases Cumulative Updates (CUs) for each version of SQL Server. This rule checks whether the latest CU has been installed for the particular version of SQL Server being used, by passing in a string for execution. This rule checks that all users (except dbo) do not have permission to execute the xp_cmdshell extended stored procedure. |<nobr>SQL Server 2005<nobr/><br/><br/><nobr>SQL Server 2008<nobr/><br/><br/><nobr>SQL Server 2008<nobr/><br/><br/><nobr>SQL Server 2012<nobr/><br/><br/><nobr>SQL Server 2014<nobr/><br/><br/><nobr>SQL Server 2016<nobr/><br/><br/>SQL Server 2017<br/>|
-|VA2128     |Vulnerability assessment is not supported for SQL Server versions lower than SQL Server 2012          |High         |To run a vulnerability assessment scan on your SQL Server the server needs to be upgraded to SQL Server 2012 or higher, SQL Server 2008 R2 and below are no longer supported by Microsoft. For more information, [see](/azure/virtual-machines/windows/sql-server-extend-end-of-support.md)         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance<br/><br/>SQL Database<br/><br/>Azure Synapse         |
+|VA2128     |Vulnerability assessment is not supported for SQL Server versions lower than SQL Server 2012          |High         |To run a vulnerability assessment scan on your SQL Server the server needs to be upgraded to SQL Server 2012 or higher, SQL Server 2008 R2 and below are no longer supported by Microsoft. For more information, [see](/azure/virtual-machines/windows/sql-server-extend-end-of-support)         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance<br/><br/>SQL Database<br/><br/>Azure Synapse         |
 
 ## Surface Area Reduction
 
@@ -138,10 +138,10 @@ SQL vulnerability assessment rules have five categories, which are in the follow
 |VA1256     |User CLR assemblies should not be defined in the database          |High         |CLR assemblies can be used to execute arbitrary code on SQL Server process. This rule checks that there are no user-defined CLR assemblies in the database.         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance         |
 |VA1277     |Polybase network encryption should be enabled          |High         |PolyBase is a technology that accesses and combines both non-relational and relational data all from within SQL Server. Polybase network encryption option configures SQL Server to encrypt control and data channels when using Polybase. This rule verifies that this option is enabled.         |<nobr>SQL Server 2016+<nobr/>         |
 |VA1278     |Create a baseline of External Key Management Providers          |Medium         |The SQL Server Extensible Key Management (EKM) enables third-party EKM / Hardware Security Modules (HSM) vendors to register their modules in SQL Server. When registered SQL Server users can use the encryption keys stored on EKM modules,this rule displays a list of EKM providers being used in the system.         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance         |
-|VA2062     |Database-level firewall rules should not grant excessive access          |High         |The Azure SQL Database-level firewall helps protect your data by preventing all access to your database until you specify which IP addresses have permission. Database-level firewall rules grant access to the specific database based on the originating IP address of each request. Database-level firewall rules for master and user databases can only be created and managed through Transact-SQL (unlike server-level firewall rules, which can also be created and managed using the Azure portal or PowerShell). For more information, see [Azure SQL Database and Azure Synapse Analytics IP firewall rules](/azure/azure-sql/database/firewall-configure.md). This check verifies that database-level firewall rules do not grant access to more than 255 IP addresses.         |<nobr/>SQL Database<br/><br/>Azure Synapse         |
-|VA2063     |Server-level firewall rules should not grant excessive access          |High         |The Azure SQL server-level firewall helps protect your server by preventing all access to your databases until you specify which IP addresses have permission. Server-level firewall rules grant access to all databases that belong to the server based on the originating IP address of each request.  Server-level firewall rules can only be created and managed through Transact-SQL as well as through the Azure portal or PowerShell. For more information, see [Azure SQL Database and Azure Synapse Analytics IP firewall rules](/azure/azure-sql/database/firewall-configure.md). This check verifies that server-level firewall rules do not grant access to more than 255 IP addresses.         |<nobr/>SQL Database<br/><br/>Azure Synapse         |
-|VA2064     |Database-level firewall rules should be tracked and maintained at a strict minimum          |High         |The Azure SQL Database-level firewall helps protect your data by preventing all access to your database until you specify which IP addresses have permission. Database-level firewall rules grant access to the specific database based on the originating IP address of each request. Database-level firewall rules for master and user databases can only be created and managed through Transact-SQL (unlike server-level firewall rules, which can also be created and managed using the Azure portal or PowerShell). For more information, see [Azure SQL Database and Azure Synapse Analytics IP firewall rules](/azure/azure-sql/database/firewall-configure.md). This check enumerates all the database-level firewall rules so that any changes made to them can be identified and addressed.         |<nobr/>SQL Database<br/><br/>Azure Synapse         |
-|VA2065     |Server-level firewall rules should be tracked and maintained at a strict minimum          |High         |The Azure SQL server-level firewall helps protect your data by preventing all access to your databases until you specify which IP addresses have permission. Server-level firewall rules grant access to all databases that belong to the server based on the originating IP address of each request.  Server-level firewall rules can be created and managed through Transact-SQL as well as through the Azure portal or PowerShell. For more information, see [Azure SQL Database and Azure Synapse Analytics IP firewall rules](/azure/azure-sql/database/firewall-configure.md).  This check enumerates all the server-level firewall rules so that any changes made to them can be identified and addressed.         |<nobr/>SQL Database<br/><br/>Azure Synapse         |
+|VA2062     |Database-level firewall rules should not grant excessive access          |High         |The Azure SQL Database-level firewall helps protect your data by preventing all access to your database until you specify which IP addresses have permission. Database-level firewall rules grant access to the specific database based on the originating IP address of each request. Database-level firewall rules for master and user databases can only be created and managed through Transact-SQL (unlike server-level firewall rules, which can also be created and managed using the Azure portal or PowerShell). For more information, see [Azure SQL Database and Azure Synapse Analytics IP firewall rules](/azure/azure-sql/database/firewall-configure). This check verifies that database-level firewall rules do not grant access to more than 255 IP addresses.         |<nobr/>SQL Database<br/><br/>Azure Synapse         |
+|VA2063     |Server-level firewall rules should not grant excessive access          |High         |The Azure SQL server-level firewall helps protect your server by preventing all access to your databases until you specify which IP addresses have permission. Server-level firewall rules grant access to all databases that belong to the server based on the originating IP address of each request.  Server-level firewall rules can only be created and managed through Transact-SQL as well as through the Azure portal or PowerShell. For more information, see [Azure SQL Database and Azure Synapse Analytics IP firewall rules](/azure/azure-sql/database/firewall-configure). This check verifies that server-level firewall rules do not grant access to more than 255 IP addresses.         |<nobr/>SQL Database<br/><br/>Azure Synapse         |
+|VA2064     |Database-level firewall rules should be tracked and maintained at a strict minimum          |High         |The Azure SQL Database-level firewall helps protect your data by preventing all access to your database until you specify which IP addresses have permission. Database-level firewall rules grant access to the specific database based on the originating IP address of each request. Database-level firewall rules for master and user databases can only be created and managed through Transact-SQL (unlike server-level firewall rules, which can also be created and managed using the Azure portal or PowerShell). For more information, see [Azure SQL Database and Azure Synapse Analytics IP firewall rules](/azure/azure-sql/database/firewall-configure). This check enumerates all the database-level firewall rules so that any changes made to them can be identified and addressed.         |<nobr/>SQL Database<br/><br/>Azure Synapse         |
+|VA2065     |Server-level firewall rules should be tracked and maintained at a strict minimum          |High         |The Azure SQL server-level firewall helps protect your data by preventing all access to your databases until you specify which IP addresses have permission. Server-level firewall rules grant access to all databases that belong to the server based on the originating IP address of each request.  Server-level firewall rules can be created and managed through Transact-SQL as well as through the Azure portal or PowerShell. For more information, see [Azure SQL Database and Azure Synapse Analytics IP firewall rules](/azure/azure-sql/database/firewall-configure).  This check enumerates all the server-level firewall rules so that any changes made to them can be identified and addressed.         |<nobr/>SQL Database<br/><br/>Azure Synapse         |
 |VA2111     |Sample databases should be removed          |Low         |Microsoft SQL Server comes shipped with several sample databases. This rule checks whether the sample databases have been removed.         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance         |
 |VA2120     |Features that may affect security should be disabled          |High         |SQL Server is capable of providing a wide range of features and services. Some of the features and services provided by default may not be necessary and enabling them could adversely affect the security of the system. This rule checks that these features are disabled.         |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance         |
 |VA2121     | 'OLE Automation Procedures' feature should be disabled         |High         |SQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system. The OLE Automation Procedures option controls whether OLE Automation objects can be instantiated within Transact-SQL batches. These are extended stored procedures that allow SQL Server users to execute functions external to SQL Server. Regardless of its benefits it can also be used for exploits, and is known as a popular mechanism to plant files on the target machines. It is advised to use PowerShell as a replacement for this tool. This rule checks that 'OLE Automation Procedures' feature is disabled.          |<nobr>SQL Server 2012+<nobr/><br/><br/>SQL Managed Instance         |