Lesson 23 — Microsoft Defender for SQL

Learning objectives

• Explain Defender for SQL.
• Distinguish the two SQL plans.
• Understand vulnerability assessment.
• Recognise SQL threat alerts.
• Investigate suspicious database activity.
• Apply layered SQL security controls.

What is Defender for SQL?

Microsoft Defender for SQL is a Defender for Cloud workload-protection capability that identifies database weaknesses and detects potentially harmful attempts to access or exploit SQL workloads.

Vulnerability assessment

Vulnerability assessment discovers, tracks and helps remediate database security weaknesses. Findings provide a measurable view of configuration, permissions and security posture.

Advanced threat protection

Advanced threat protection detects anomalous database activity and potentially harmful attempts to access or exploit SQL services.

Azure SQL Database

Defender can protect databases hosted by Azure SQL Database and surface vulnerability findings and security alerts through Defender for Cloud.

Azure SQL Managed Instance

Managed Instance receives the same core security themes: vulnerability assessment, anomalous activity detection and investigation context.

Azure Synapse SQL

Supported SQL resources in Azure Synapse can be included in the Azure SQL protection model. Confirm current regional and feature support before deployment.

SQL Server on Azure VMs

SQL Server hosted on an Azure virtual machine is protected through Defender for SQL Servers on Machines rather than the Azure SQL PaaS plan.

Azure Arc-enabled SQL Server

On-premises or other-cloud SQL Server workloads can be connected through Azure Arc so Defender for Cloud can include them in central security management.

Multicloud SQL workloads

Connected AWS and Google Cloud environments can bring supported SQL machines into Defender for Cloud governance and threat protection.

Potential SQL injection

Defender can alert when database activity resembles an SQL injection attempt or when a vulnerable application appears to send malicious query input.

Brute-force SQL credentials

Repeated authentication failures or credential guessing against SQL accounts can generate a brute-force alert.

Access from an unusual location

Database access from an unfamiliar geography, network or data centre can indicate compromised credentials or unauthorised administration.

Unfamiliar principal

An identity that has not previously accessed the database—or accesses it in an unusual way—can increase the risk of an event.

Potentially harmful application

The client application or tool connecting to SQL can provide important threat context, particularly when it is uncommon or associated with attack activity.

Unusual query patterns

Queries that differ from normal workload behaviour can reveal reconnaissance, privilege discovery, bulk extraction or exploitation.

Data exfiltration indicators

• Large result sets
• Bulk export activity
• Unusual table enumeration
• Queries against sensitive schemas
• Access at unexpected times
• New client or source address

Vulnerability findings

Findings can identify excessive permissions, unsafe database configuration, weak authentication choices, missing security controls and deviations from recognised baselines.

Express configuration

For supported Azure SQL services, express vulnerability assessment configuration uses Microsoft-managed storage for baselines and scan results, reducing deployment complexity.

Scan baselines

A baseline records approved results for a database. Baselines must represent intentional business requirements rather than becoming a method for hiding unresolved risk.

Recurring scans

Regular scans show whether database posture has improved, regressed or changed after deployments and administrative work.

Remediation ownership

Every finding needs an accountable owner: database administrator, application team, identity team, network team or cloud platform team.

Microsoft Entra authentication

Use Microsoft Entra identities where supported to improve attribution, central control and integration with identity governance.

Least privilege

Application accounts should receive only the database permissions required for their workload. Avoid broad owner or administrative rights.

Managed identities

Azure managed identities can remove stored application passwords and provide a controlled identity for supported Azure workloads.

SQL authentication

Where SQL authentication remains necessary, passwords must be strong, rotated, securely stored and limited to narrowly scoped accounts.

Firewall controls

Restrict database connectivity to approved networks, services and private paths. Broad internet access increases the attack surface.

Private endpoints

Private endpoints can keep supported Azure SQL traffic on private network paths and reduce exposure to public connectivity.

Auditing

SQL auditing records database events for governance, operations and investigation. Threat detection and auditing complement one another but serve different purposes.

Transparent Data Encryption

TDE protects supported database files, backups and transaction logs at rest. It does not prevent an authorised or compromised identity from querying data.

Always Encrypted

Always Encrypted can protect selected sensitive values from database operators and the database engine, depending on the chosen configuration.

Dynamic Data Masking

Dynamic Data Masking limits exposure of selected fields to non-privileged users. It is an exposure-reduction control, not encryption.

Data classification

Classifying database columns helps teams identify crown-jewel information and understand the likely impact of suspicious activity.

Defender alert evidence

• Database and server
• Alert type and severity
• Client IP and location
• Login or principal
• Application name
• Time and activity sequence
• Relevant query details
• Threat-intelligence context

Initial triage

Determine whether the activity is expected, whether the identity is legitimate, whether the application normally performs the query and which data was affected.

Query investigation

Review the query intent and sequence. Enumeration followed by privilege discovery and bulk retrieval may reveal a complete attack path.

Identity investigation

Review sign-ins, role membership, credential changes, service principals, managed identities and recent permission changes.

Application investigation

Trace the database request back to the application, API, connection string and input path that created it.

Network investigation

Review source addresses, private endpoints, firewall rules, proxies, gateways and whether the access path was expected.

Microsoft Sentinel correlation

Correlate SQL alerts with identity, endpoint, application, firewall and cloud activity to determine whether the database event belongs to a broader incident.

Containment actions

• Block the malicious source.
• Disable or restrict the affected identity.
• Rotate exposed credentials.
• Remove excessive database permissions.
• Patch or update the vulnerable application.
• Restrict network access.
• Preserve investigation evidence.

Application remediation

Use parameterised queries, safe stored procedures, input validation and secure error handling. A WAF can reduce exposure but does not replace secure application code.

Validation after remediation

Retest the application path, confirm the original query cannot be reproduced, verify legitimate functionality and monitor for repeat attempts.

What Agent Foskett checked

• Defender plan status
• Vulnerability findings
• Alert evidence
• Database login
• Client application
• Source IP
• Query sequence
• Database permissions
• Application input
• Firewall rules
• Audit records
• Affected data

Best practices

• Enable the correct SQL plan.
• Review vulnerability scans.
• Use Entra authentication.
• Use managed identities.
• Apply least privilege.
• Restrict network access.
• Use parameterised queries.
• Enable SQL auditing.
• Classify sensitive data.
• Correlate alerts in Sentinel.