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||
|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.
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:
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:
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.
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.
Farrah Gamboa is a Director of Technical Product Management at Stealthbits – now part of Netwrix. She is responsible for building and delivering on the roadmap of Stealthbits products and solutions.
Since joining Stealthbits in 2012, Farrah has held multiple technical roles, including Scrum Master and Quality Assurance Manager. Farrah holds a Bachelor of Science degree in Industrial Engineering from Rutgers University
Proper data security begins with a strong foundation. Find out what you're standing on with a free deep-dive into the security of your Structured and Unstructured Data, Active Directory, and Windows infrastructure.Read more
Start a Free Stealthbits Trial!
No risk. No obligation.