This article is contributed. See the original author and article here.
As enterprises are working to reduce their attack surface area, one area that is often overlooked is the potential database vulnerabilities and detection of anomalous activity that could indicate a sign of intrusion. In the series of blog post, we will walk you through different scenarios on, how Azure Security Center protects SQL server hosted on either Azure VMs, Azure Arc and On-prem.
Advanced Data Security (ADS) is one of many features that is included in Azure Security Center and falls under Cloud Workload Protection Platform (CWPP) capability (read this article to understand CWPP). Advanced data security for SQL machines is an extension of Azure Security Center’s advanced data security package that’s already available for Azure SQL Databases, Synapse, and SQL Managed Instances. This feature (by the time this blog was written it was in public preview) brings the same level of protection that were introduced for SQL servers on Azure VMs which includes SQL Injection vulnerabilities, brute-force against SQL credentials, and much more.
Cloud security posture management and proactive threat protection with Azure Security Center helps SOC (Security Operation Center) operators to get handle on threats and keep pace with attackers and Advanced Data Security (ADS) for SQL servers on Azure Virtual Machines, is a unified package for advanced SQL security capabilities which is in public preview at the time of this writing.
This public preview feature that was announced last year includes functionalities for identifying and mitigating potential database vulnerabilities and detecting anomalous activities that could indicate threats to your database:
Breakthroughs in big data and machine learning make it possible for Security Center to detect anomalous database access and query patterns, SQL injection attacks, and other threats targeting your SQL databases in Azure. With Azure Security Center you receive alerts on suspicious activity and recommended actions for investigating and mitigating these threats.
Advanced Data Security pricing aligns with Azure Security Center standard tier, where each protected server or managed instance is counted as one node. Newly protected resources qualify for a free trial of Security Center standard tier. For more information, see the Azure Security Center pricing page.
In this blog post, we will be covering how Azure Security Center protects SQL IaaS machines hosted on Azure.
1. SQL server on an Azure VM
SQL Server on Azure Virtual Machines enables you to use full versions of SQL Server in the cloud without having to manage any on-premises hardware. SQL Server virtual machines (VMs) also simplify licensing costs when you pay as you go. Refer this article for more understanding, plus instructions to spin the Azure SQL VM.
As a prerequisite, make sure the optional bundle (SQL servers on Machine) is enabled in Security Center’s pricing and settings page (Subscription) as shown in ‘Image 1’
Image 1: Pricing settings in Security Center
If you have Auto-provisioning turned on (Refer, Image 2), Azure Security Center will automatically provision the Log Analytics Agent on the Azure VMs.
Image 2 : Auto Provisioning
In an instance where you don’t have Auto-Provisioning turned on, you would have to manually install the agent. Refer this article for step-by-step process of the installation.
You may choose to collect the data in a default workspace that Azure Security Center creates or select your own workspace. Advanced Data Security for SQL servers on machines will be enabled on all SQL servers connected to the selected workspace. The protection will be fully active after the first restart of the SQL Server.
In this sample scenario, a SQL IaaS VM (sqlserver) was provisioned. Azure Security Center installed the Log Analytics agent and started gathering data to provide security recommendations for your SQL VM under Recommendations section (as shown in ‘Image 3’). Furthermore, you can select the security option at the left pane and view recommendations from Security Center and alternatively, you may navigate to Azure Security Center for more information on a recommendation. You can enable threat protection for Azure SQL Database SQL servers at either the subscription level or resource level.
Image 3: Recommendations
You can also filter just the SQL recommendations (Data & Storage hive) from Resource security hygiene section (as shown in the Image 4)
Image 4: Data & Storage
Make sure to address and review all security recommendations for the SQL databases. In my example, I have these unhealthy resources which is grouped beautifully by Severity.
1.1 Executing the Attack
Hackers are always trying to find workloads that are exposed to the Internet and databases that are very common target. As part of this type of attack, it is common to see scanning to discover public IP addresses that have SQL workloads running on it, and once they find that they will move forward to try to crack their password using different methods, such as brute force attack. “Brute Force”, which is a type of attack that attempts to calculate or guess valid username/password combinations to gain unauthorized access to a host. Oftentimes, the sheer amount of Brute Force attempts can effectively result in DDoS of the targeted system. In case threat actors can compromise the SQL database and gain access to it, they will likely find a wealth of valuable information that includes, personally identifiable information, credit card numbers, intellectual property, etc. Even if the database does not have much information, a successful attack on an insecurely configured SQL installation can be leveraged to get full system admin privileges.
For this example, a PowerShell script was utilized to simulate a SQL brute force attack against a SQL database that is connected to the Azure Security Center.
The brute force attempts occurred over TCP port 1433, which was exposed on a public facing interface. TCP port 1433 is the default port for SQL server.
Note: It is a very common recommendation to change the SQL default port 1433, this may impart a “false sensation of security”, because many port scanning tools can scan a “range” of network ports and eventually find SQL listening on ports other than 1433.
The PowerShell script used in this case is simulating the attack by trying to login with ‘sa’ account and trying with a list of commonly used password defined in the text file or the inline array of the script. (In a real-world scenario, once the attacker finds TCP/UDP ports open, it starts to brute force the login with the set of most common passwords used by database administrators to perform a successful attack)
Assuming the attack was successful, Azure Security Center was able to detect and report the attack under Security alerts dashboard as shown in the ‘Image 5’
Image 5 : Security Alerts
You can further investigate the alert to view more information of the affected VM name, activity name, Environment, state of alert and more. The first step is to click on the alert itself, and see how many instances does that alert has occurred, as show in the ‘Image 6’
Image 6 : Brute Force attempt alert
You can further select the attacked resource to understand the extent and the details of the attack. Alert details will give you more information that could help during investigation of a security alert, such as, IP addresses, related processes, user accounts and more. ‘Image 7’ below has an example of how this looks like:
Image 7 : Security Alert details
When you further navigate to the “Take action” tab in the right pane, you can benefit from information like, remediation steps for this alert to mitigate the threat, prevent future attacks by applying the security recommendations and increase security posture.
You can create a logic app defining a workflow automation so that, when an alert is created in Security Center and if it matches the evaluation criteria that you’ve configured in an automation, then the logic app triggers. For example, you might want your Logic App to run when a security alert that contains “SQL” is generated. You can also run Logic Apps manually when viewing a security alert or any recommendation that offers Quick Fix remediation.
You will also notice the option to Suppress the future alerts with similar characteristics if the alert is not relevant for your organization as highlighted below in ‘Image 8’
Image 8: Suppress Similar Alerts
It is recommended to configure Azure subscription(s) to receive future alerts and email notifications from Azure Security Center. Please refer to the article that explains how to configure the email settings. Below is an example of the email alert received from ASC when this SQL incident was detected:
Image 9: Email Notification
In the next blog posts, we will discuss on how you can leverage Azure Security Center to protect your SQL IaaS VMs hosted on Azure Arc and On-premises. Stay Tuned!!
Special thanks to:
Yuri Diogenes, Senior PM, CxE Security – ASC Team for reviewing this post.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments