Netwrix Enterprise Auditor (formerly StealthAUDIT) 11.6 has been released LEARN MORE
Stealthbits

Advanced Data Security Features for Azure SQL- Part 2: Vulnerability Assessment

Blog >Advanced Data Security Features for Azure SQL- Part 2: Vulnerability Assessment
Advanced Data Security Features for Azure SQL- Part 2 Vulnerability Assessment
| Farrah Gamboa | | Leave a Comment

In my last blog post, we took a look at the Data Discovery & Classification features within the Advanced Data Security (ADS) offering for Azure SQL. In this blog post, we will take a deep dive into the Vulnerability assessment.

The SQL Vulnerability assessment provides administrators with a streamlined approach to identify and even remediate potential security misconfigurations or vulnerabilities within their Azure SQL databases. The Vulnerability Assessment is a scanning service that contains a set of built-in rules based off of Microsoft’s best practices with security being the focal point.

Each scanned database will be compared against each security check to highlight areas where your databases deviate from the aforementioned best practice.  The scan contains 47 total security checks and will apply a risk-based on the individual check.

ID Applies to Security Check Risk Category Benchmark References
VA1223 server Certificate keys should use at least 2048 bits High Data Protection FedRAMP
VA2060 server SQL Threat Detection should be enabled at the server level Medium Data Protection  
VA2061 server Auditing should be enabled at the server level High Auditing & Logging FedRAMP
VA2062 server Database-level firewall rules should not grant excessive access High Surface Area Reduction  
VA2063 server Server-level firewall rules should not grant excessive access High Surface Area Reduction  
VA2064 server Database-level firewall rules should be tracked and maintained at a strict minimum High Surface Area Reduction  
VA2065 server Server-level firewall rules should be tracked and maintained at a strict minimum High Surface Area Reduction  
VA2107 server Minimal set of principals should be members of fixed Azure SQL DB master database roles High Authentication & Authorization FedRAMP
VA1020 database Database user GUEST should not be a member of any role High Authentication & Authorization FedRAMP
VA1054 database Excessive permissions should not be granted to PUBLIC role on objects or columns Low Authentication & Authorization FedRAMP
VA1095 database Excessive permissions should not be granted to PUBLIC role Medium Authentication & Authorization FedRAMP
VA1096 database Principal GUEST should not be granted permissions in the database Low Authentication & Authorization FedRAMP
VA1097 database Principal GUEST should not be granted permissions on objects or columns Low Authentication & Authorization FedRAMP
VA1099 database GUEST user should not be granted permissions on database securables Low Authentication & Authorization FedRAMP
VA1143 database ‘dbo’ user should not be used for normal service operation Medium Surface Area Reduction FedRAMP
VA1219 database Transparent data encryption should be enabled Medium Data Protection FedRAMP
VA1221 database Database Encryption Symmetric Keys should use AES algorithm High Data Protection FedRAMP
VA1223 database Certificate keys should use at least 2048 bits High Data Protection FedRAMP
VA1224 database Asymmetric keys’ length should be at least 2048 bits High Data Protection CIS v1.0.0-08-11-2017:7.2
FedRAMP
VA1246 database Application roles should not be used Low Authentication & Authorization FedRAMP
VA1248 database User-defined database roles should not be members of fixed roles Medium Authentication & Authorization FedRAMP
VA1258 database Database owners are as expected High Auditing & Logging FedRAMP
VA1281 database All memberships for user-defined roles should be intended Medium Auditing & Logging FedRAMP
VA1282 database Orphan roles should be removed Low Authentication & Authorization FedRAMP
VA1288 database Sensitive data columns should be classified Medium Data Protection  
VA2000 database Minimal set of principals should be granted high impact database-scoped permissions High Authentication & Authorization FedRAMP
VA2001 database Minimal set of principals should be granted high impact database-scoped permissions on objects or columns High Authentication & Authorization FedRAMP
VA2002 database Minimal set of principals should be granted high impact database-scoped permissions on various securables High Authentication & Authorization FedRAMP
VA2010 database Minimal set of principals should be granted medium impact database-scoped permissions Medium Authentication & Authorization FedRAMP
VA2020 database Minimal set of principals should be granted ALTER or ALTER ANY USER database-scoped permissions High Authentication & Authorization FedRAMP
VA2021 database Minimal set of principals should be granted database-scoped ALTER permissions on objects or columns High Authentication & Authorization FedRAMP
VA2022 database Minimal set of principals should be granted database-scoped ALTER permission on various securables High Authentication & Authorization FedRAMP
VA2030 database Minimal set of principals should be granted database-scoped SELECT or EXECUTE permissions Low Authentication & Authorization FedRAMP
VA2031 database Minimal set of principals should be granted database-scoped SELECT permission on objects or columns Low Authentication & Authorization FedRAMP
VA2032 database Minimal set of principals should be granted database-scoped SELECT or EXECUTE permissions on schema Low Authentication & Authorization FedRAMP
VA2033 database Minimal set of principals should be granted database-scoped EXECUTE permission on objects or columns Low Authentication & Authorization FedRAMP
VA2034 database Minimal set of principals should be granted database-scoped EXECUTE permission on XML Schema Collection Low Authentication & Authorization FedRAMP
VA2040 database Minimal set of principals should be granted low impact database-scoped permissions Low Authentication & Authorization FedRAMP
VA2041 database Minimal set of principals should be granted low impact database-scoped permissions on objects or columns Low Authentication & Authorization FedRAMP
VA2042 database Minimal set of principals should be granted low impact database-scoped permissions on schema Low Authentication & Authorization FedRAMP
VA2050 database Minimal set of principals should be granted database-scoped VIEW DEFINITION permissions Medium Authentication & Authorization FedRAMP
VA2051 database Minimal set of principals should be granted database-scoped VIEW DEFINITION permissions on objects or columns Medium Authentication & Authorization FedRAMP
VA2052 database Minimal set of principals should be granted database-scoped VIEW DEFINITION permission on various securables Medium Authentication & Authorization FedRAMP
VA2062 database Database-level firewall rules should not grant excessive access High Surface Area Reduction  
VA2064 database Database-level firewall rules should be tracked and maintained at a strict minimum High Surface Area Reduction  
VA2108 database Minimal set of principals should be members of fixed high impact database roles High Authentication & Authorization FedRAMP
VA2109 database Minimal set of principals should be members of fixed low impact database roles Low Authentication & Authorization FedRAMP

These security checks will focus on areas such as misconfigurations at the database and server level, least privilege access considerations, and surface-level checks for sensitive data classification and auditing. While some of these checks are very specific such as “Transparent data encryption should be enabled”, others are very vague and are left to the admins to determine whether the current configuration is acceptable.

This assessment should be used as a starting point, and should not be the only security measure that is being taken or reviewed. For example, while the vulnerability assessment checks whether sensitive columns are being classified, it is only indicating that the recommendations made in Discovery and Classification feature are being used to classify columns and does not go any further. Similarly, while the assessment checks that auditing and advanced threat detection are enabled, it does not indicate whether identified threats are being remediated.

Vulnerability Assessment Settings

In order to run the Vulnerability Assessment, ADS must be enabled. Refer to my previous blog post for detailed instructions on enabling ADS for your Azure SQL Database. Once enabled, you will have to provide additional information to configure the specific settings for the assessment. This includes:

  • The specific Azure subscription
  • The storage account that will be used to store the results of the scans
  • Determining whether to enable periodic recurring scans
  • An email address for the reports to be sent to, along with the ability to email notifications to administrators and subscription owners

Getting Started

To get started, click on the Vulnerability Assessment card under the Settings > Advanced Data Security page for your SQL database:

The landing page will provide a summary of the Total Failing and Total Passing checks, with a breakdown of the risk summary based on High Risk, Medium, or Low Risk. It will also present you with the date and time of the last scan. Run a scan by clicking Scan at the top of the page:

Analyze Results and Resolve Issues

Once a scan Is run, the results are automatically displayed within the Azure portal. The report will present an overview of your security state with a breakdown of how many of the checks have passed or failed, with a corresponding risk level. you can dive into the Failed and Passed results individually:

At this point, you can review your results and determine whether the failed checks present actual security issues within your environment. Clicking on an individual security check will provide additional details and remediation steps that should be taken:

Here, you will be able to decide whether the result is an acceptable baseline within your environment, or whether remediation is required. If the result is acceptable, you can click the ‘Approve as Baseline’ button at the top of the window:

Setting a baseline for a given security check customizes results reporting for future scans, resulting in a pass versus a failure when a baseline is met. Once all baselines are set, the Vulnerability assessment will only report failures as deviations from the baseline allowing administrators to focus their efforts on the specific areas that present issues within their environment. If the failed check is not considered a suitable baseline within your environment, administrators can remediate the issue following the remediation results provided:

Once you’ve set your baselines and resolved all remaining issues, you can rerun the scan to provide the results of the customized report:

You can easily export a copy of the report by clicking the ‘Export Scan Results’ button at the top of the page, which will provide a downloaded except report including both summary and detailed report results:

You can also manage your Vulnerability Assessments at scale by leveraging the Azure PowerShell cmdlets. Refer to this MSDN blog for script examples. 

Next Steps

With periodic scanning enabled for the Azure SQL Vulnerability Assessments, administrators can easily maintain consistent visibility over security issues within their Azure SQL databases and be provided with the necessary remediation steps to address these issues as they arise. This alleviates the never-ending headache for DBA’s who have historically needed to run these checks manually using a variety of methods and tools. In my next blog post, we will take a deep dive into the Advanced Threat Protection feature which is the final piece of the Advanced Data Security portfolio.

Featured Asset

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe

DON’T MISS A POST. SUBSCRIBE TO THE BLOG!


Loading

© 2022 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.

FREE TRIAL