Databases contain some of your most sensitive data, which makes them an obvious target for attackers. Most attackers are usually looking for data, whether it is to acquire sensitive data for their own use (to sell), to encrypt it (to sell back to you), or to destroy it (to cause you reputational and operational harm). Databases have an extended attack surface and are often misconfigured which can lead to an attacker gaining access, elevating permissions, and wreaking havoc.
This recommendation is generated by Defender for SQL on machines Vulnerability Assessment. The rules that we check for are a set of possible misconfigurations that should be addressed. When you have findings for this recommendation, you have four options on how to handle it. We’ll go into depth on each of them in this blog.
You can exempt a recommendation from any scope so that it doesn’t affect your secure score. We will still conduct the VA scan and report the results, however; the resources’ status will change to ‘Not Applicable’ in the recommendation. Exemptions can be made via the portal, or programmatically.
IMPORTANT NOTE: This recommendation is included in multiple policy initiatives, creating an exemption in the portal will create an exemption for each initiative.
Open the Microsoft Defender for Cloud Recommendations blade and navigate to ‘SQL servers on machines should have vulnerability findings resolved’.
Because all the Azure recommendations are powered by Azure Policy, if we want to programmatically create an exception on a recommendation, the easiest way to do so is through PowerShell.
$Subscription = Get-AzSubscription
$ASCDefault = Get-AzPolicyAssignment -Id /subscriptions/$($Subscription.Id)/providers/Microsoft.Authorization/policyAssigments/SecurityCenterBuiltIn
New-AzPolicyExemption -Name '<Detailed-Name>' -ExemptionCategory Waiver -PolicyAssignment $ASCDefault -Scope "/subcriptions/$($Subscription.Id)" -PolicyDefinitionReferenceId serverSqlDbVulnerabilityAssessmentMonitoring
When you go the programmatic route, Azure will not assume that you want to exempt this recommendation from every policy initiative. You will need to repeat steps two and three for each initiative this definition is associated with.
Disabling a rule is similar to exempting a resource in that it will cease to impact your secure score, however; when you disable a rule, you disable that rule for all resources underneath that scope (either Management Group or Subscription).
As you review your assessment results, you can mark specific results as being an acceptable baseline in your environment. Each baseline is essentially a customization of how the results are reported. In subsequent scans, results that match the baseline are considered as ‘Passed’. After you’ve established your baseline security state, vulnerability assessments only report on deviations from the baseline, freeing you up to focus your attention on other relevant issues.
To accept findings in a baseline, we’ll walk through an example, starting again on the recommendation ‘SQL servers on machines should have vulnerability findings resolved’.
Any deviation from the defined baseline will result in a mismatch and the check will become a finding again.
Working in the portal is great when you are focused on either a small set of subscriptions or database servers. In order to do things at scale, it is best if we do these actions programmatically. Below are some examples of how to do this. You will need to tailor these commands to suite your needs.
Once you have reviewed all the findings for a specific database you can choose to add them to the baseline. The easiest way to do this programmatically is through PowerShell.
$workspaceId = '<YourWorkspaceId>' # This is the Log Analytics workspace that is used by the Defender plan.
$resourceId = '/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Compute/virtualMachines/<SQLServerName>'
$Server = '<SQLServerInstanceName>'
$Database = '<DatabaseName>' # You will have multiple databases, if you have a similar finding across the databases, you will need to change the variables and re run the command below.
Set-AzSecuritySqlVulnerabilityAssessmentBaseline -ResourceId $ResourceId `
-WorkspaceId $WorkspaceId `
-Server $Server `
-Database $Database
For more information about the command used, please check out the documentation here: Set-AzSecuritySqlVulnerabilityAssessmentBaseline (Az.Security) | Microsoft Learn
For some organizations, it is best to work on one databases configuration and use that as a baseline for others. In these scenarios, we want to be able to copy a baseline from Database $A and apply it to Database $B.
$workspaceId = '<YourWorkspaceId>'
$fromResourceId = '/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Compute/virtualMachines/<SourceSQLVirtualMachineName>'
$toResourceId = '/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Compute/virtualMachines/<TargetSQLVirtualMachineName>'
$Server = '<ServerInstanceName>'
$Database = '<DatabaseName>'
Get-AzSecuritySqlVulnerabilityAssessmentBaseline -WorkspaceId $workspaceId ` #Fetch the baseline from the source database we want to utilize
-ResourceId $fromResourceId `
-Server $Server `
-Database $Database | `
Set-AzSecuritySqlVulnerabilityAssessmentBaseline -WorkspaceId $workspaceId ` #We pipe the results to the cmdlet to set the baseline for our target database
-ResourceId $toResourceId `
-Server $Server `
-Database $Database
If your source database does not have a baseline already set, PowerShell will throw an error.
Sometimes you’ll review your baseline and want to add certain findings into the baseline, but don’t want to add every result. In this scenario, you must do this programmatically.
$workspaceId = '<WorkspaceId>'
$resourceId = '/subscriptions/<SubscriptionId>/resourceGroups/<ResourceGroupName>/providers/Microsoft.Compute/virtualMachines/<SQLVMName>'
$Server = '<ServerInstanceName>'
$Database = '<DatabaseName>'
Set-AzSecuritySqlVulnerabilityAssessmentBaseline -WorkspaceId $workspaceId `
-ResourceId $ResourceId `
-Server $Server `
-Database $Database `
-BaselineSet @{VA1258 = @(, @("WideWorldImportersDW", "SQL2022CRM\datasecuritysa"))}
Here we specifically added one finding into the baseline for VA1258 - Database owners are as expected.
Each finding in a vulnerability assessment scan contains a remediation step(s) that your database administrators would need to act on.
While our recommendations are based on the settings required in the database, do exercise caution and evaluate whether or not this is the right choice for your organization.
Taking a good hard look at the configurations of your databases will help you reduce your overall risk. While this article was written specifically with regards to managing vulnerability assessments for SQL Virtual Machines, the concepts are relevant to Azure SQL databases as well (although the programmatic references are different).
Rules reference: SQL vulnerability assessment rules reference for Microsoft Defender for Cloud | Microsoft Learn
Rules changelog: SQL vulnerability assessment rules changelog for Microsoft Defender for Cloud | Microsoft Learn
Acknowledgements
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.