For those of you who swear by Veeam for backups and disaster recovery but want to supercharge your security game, then I've got some news for you: it's time to call in Microsoft Azure Sentinel to analyze Veeam syslog, which is now an included feature in VBR 12.1.

What’s Sentinel?

If you’re new to the Azure Sentinel, think of it as AI-backed SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation, and Response), enabling holistic security operations for your enterprise. It's like the Swiss Army knife of threat hunting—detecting, investigating, and responding to attacks to minimize "security breach."

Maximizing Security with Veeam Syslog and Azure Sentinel

• Unified data and real-time insights through Azure Sentinel's integration of Veeam syslog

• Automated playbooks for proactive defense and quick incident investigation

• Built-in analytics for smarter alerts using machine learning

• Scalability and integration with other security tools

• Creation of an ecosystem that covers all backup bases

Get ready to supercharge your data protection game with Veeam syslog and Azure Sentinel!.

Maximizing Data Protection with Azure Sentinel and Veeam Syslog

• Set up Log Analytics Workspace

• Enable Syslog Connector. In my lab this consisted of a Linux VM in my vSphere lab.

• Configure Veeam Syslog Settings. A feature included in VBR 12.1. Find more on that here

• Map log data to Sentinel for hunting, alerting, and visualization

What is KQL?

Kusto Query Language (KQL) is a powerful, read-only language designed to query structured, semi-structured, and unstructured data. It is primarily used with Azure Data Explorer for swift and interactive analysis of vast data sets.

Why Use KQL?

KQL is optimized for efficiently handling massive volumes of data, making it suitable for tasks like log analysis, telemetry data crunching, and monitoring for applications and infrastructure. It also adds deep integration with various Microsoft services like Azure Monitor, Azure Log Analytics, and Application Insights.

The Syntax

KQL's syntax is easy to pick up, especially for those familiar with SQL. It includes familiar clauses such as Where, Summarize, Project, and Join, making it relatively straightforward to learn. Here's an example I pulled from the Microsoft Training on the subject. .

// Retrieve rows from the 'Logs' table where the 'Level' is 'Error'

Logs

| where Level == "Error"

| project TimeGenerated, Message, Computer

| order by TimeGenerated desc

We see here the query retrieves records from the table name Logs. Then filters those logs to ones including the statement "Error".  Then sorting them by ‘TimeGenerated’ for display. Making sense of the large collection of Syslog. Now let's examine this with events with more specific Syslog generated by VBR.

Veeam SysLog

As mentioned above, KQL is used in conjunction with Azure Data Explorer, or to create queries that trigger incident response. In this example I will simply demonstrate the use of KQL under Analytics in my Sentinel Workspace.

Utilizing the Event codes listed in Veeam Help Center to create a specific query, which find events documenting the removal of restore points. An event that doesn't necessarily mean anything malicious as this happens daily as retention limits are met. But an event of interest nonetheless.

But these logs don't yet tell us much. Let's sort them a little further, and parse these logs a bit further and see if we can't sort them in a way to make them more actionable. The 'SyslogMessage' field contains specific data that can help locate potentially malicious events. Avoiding  manually opening every log to find non-system generated events I  sorted  the logs to those that might contain potential malicious events.

In order to extract information from the Syslog Message, I will parse out the DateTime, VmName (or job name), and the Description. This will provide per-tenant information on each event. The results display a clearer view of the time of the event, the backup job name, and a brief description of the action. However, manually going through the list still poses the risk of missing events of real interest.

I need to sort out those  logs that are not relevant, specifically, events not associated with a particular user account. Focusing on identifying any authorized or compromised account that has deleted a restore point manually. Using an additional WHERE statement of 'by user' I can now track manual deletion of restore points. Focusing on those logs  that can help in identifying unauthorized or compromised actions within the system.

Now, I can see all Restore Point Removed events that were done manually, and by what account. There may be a valid reason for this removal, but I still want to know about it. And there should be a documented reason for this action. Perhaps, if a specific user, such as 'zallyn' above, removes a point, it is a normal event. And I can follow up or look for a change notification.

But it might be cause for alarm if an administrator account, which has no business logging into a VBR server, is involved. I can further use this for more in depth  threat hunting. Correlating  with other security events from VBR or other collectors in my environment.

Now, you can begin to see how valuable this information can be in an organization security posture. Look for future blogs where I examine long-term storage and use of Azure Data Explorer, trigger incidents and more advanced features of Microsoft Sentinel.