Logging (not only) in Microsoft Azure: why, what, where and how to log?

Logging in is the collection of events (logs) from various systems and applications so that it is possible to work with them and evaluate them.  

Without answers to the above questions, support for the implementation of the logging system will be weak and the motivation of technical colleagues to use the system will be very low. No one is interested in another "box" that will be cared for but not actually used.  

Because pressure on logging from various regulations and rules will increase, this article aims to present the technical aspects of such a system. 

Why is logging important?  

There are three main reasons to log: 

1. Security  
   Logs allow us to detect potential problems and security gaps before they are misused (and in the case of misuse, we will detect it at the outset before irreversible damage is done). Typically this includes logs from various perimeter systems (FW, WAF), identity systems (Entra, Active Directory, ...), security platforms (antivirus, EDR, CSPM, ...) and audit logs. 

2. Optimization and troubleshooting 
   Every system or application occasionally has performance issues or simply "something doesn't work". In this case, it is difficult to blindly discover where the problem is, when it occurred and what is causing it. And just logs helps us to find out this information and solve the problems. 

3. Regulatory requirements 
   There are many regulations currently in place that require organisations to require logging of key or security systems. An example would be NIS2 (or its local implementation - the new Cyber Security Act), in banking DORA, for all then GDPR or the coming AI Act. 

So we know the answer to the first question: We need logging. Not just for the paperwork, but also from an operational and security perspective.  

We will answer further questions below. We will focus on logging in the Microsoft cloud environment, i.e. logging in Azure. 

Logging in Microsoft Azure 

For starters, it's good to understand how logging in the cloud differs from on-premise environments.  

In on-premise we solve logging at the syslog level (switches, firewalls, servers, ...) or with the help of an agentthat is installed on the servers (whether virtual or physical).  

In contrast. this scenario cannot be used in the cloud. Syslog is not available here and the agent can only be installed if we have an operating system layer (IaaS). We have to pull logs from these services in a different way and Microsoft has several options for us. 

Azure Monitor 

This is a native Microsoft solution, and a unique place to find logs and tools for analyzing and working with them. Essentially, Azure Monitor is a the center of the logging universe in Azure. 

Azure Monitor (Source: https://learn.microsoft.com/cs-cz/azure/azure-monitor/overview)

Which logs can we actually send to Azure Monitor? 

• Application logs
  We send application logs to Azure Monitor directly from our appeither by integrating with an Azure service (as an app service) or by using an SDK that we can integrate into our own code.  
  
  The advantage of such an app service (e.g. for an application written in .NET) is the possibility to collecting telemetry without the need for any modification. These logs (or metrics) provide us with information about individual requests (including return codes), from which we are able to detect performance issues, user experience or errors that occur in the application.  
  
  For this purpose we use the component Application Insightswhich collects and analyses logs and offers a range of predefined dashboards and workbooks (as well as creating your own). 
  
• OS logs  
  OS logs come from from inside the operating system. We can use them to monitor Linux and Windows, or other specially adapted systems.  
  Typically, this includes logs about logging on to the system, audit logs, and logs about applications running on the OS. The primary purpose of these logs is Azure Monitor agent (for both Azure VMs and non-Azure servers). 
  
• Azure resources  
  On Azure resources - which is the biggest difference from the on-premise world - agent cannot be installed. We can collect logs from them natively directly in Azure via the settings diagnostics settings. In this case we use resource logsthat show us information about the resources (access logs for WAF, logs for PaaS databases and much more). 
  
• Azure subscriptions  
  One of the things we definitely want to collect are logs from individual subscriptsso called activity logs. These are basically audit recordsthat tell us who created, changed or deleted the resource and when. Although they are collected by default, we will certainly be happy to have them available for more than 30 days. 
  
• Tenant  
  Just as we collect login logs from, for example, domain controllers, in the cloud world we want to collect logs of logins and actions taken by users from Tenant. 

I have already outlined some of the components and features of Azure Monitor. In addition to the mentioned agents, Application Insights and native connection to cloud resources, the tool also offers other functionalities and features that are inherently associated with logging.

• Log Analytics workspace
  It serves to collecting and analysing logs from all possible sourcesnot just from Azure services. You can explore logs using KQL (Kusto Query Language), which makes it easy to crawl and analyze data.
  
  The price of the service depends on on the volume of data (logs) and on the time for which the logs are stored (retention). Within Azure, it is possible to reserve a daily increment of logs; however, the minimum limit is 100 GB/day, which is difficult to achieve for most (at least Czech) companies.
  
• Alerting and automation
  With Azure Monitor, we can also set up alerts based on certain events or log occurrences. For example, if the threshold of unsuccessful login attempts that we have defined is exceeded, the system can immediately alert us.  
  If we want to go even further, we can use the Logic Apps platform. This allows us to handle notifications and integrations with different providers. This allows us to take alerting and automation to a whole new level.
  
• Visualization
  The logos themselves are useful, but often rather unclear. Moreover, exporting them to Excel and then creating your own filters and queries is not the best solution.
  
  Therefore, we have the already mentioned KQL language, with which it is possible to create custom workbooks with custom visualizations. In addition, we can use the connection to the Power BIwith which we can provide visualizations in a more readable and understandable form, for example, to business.

Now that I'm logging, what else?

In the previous sections we have explained what we can log, where, how and how we will pay for it. However, we are still missing perhaps the most important thing: what to do with the logs next? We have them stored, but we can draw some added value from the logs?

For now, we treat logos as separate pieces of the puzzle. They help us solve problems that have already occurred, but do not provide a complete picture of the environment and security. We have to go through them manually, define alerts and piece the information together, which is very time consuming.

So we'll go a little further, and that's to the system SIEM (Security Information and Event Management), which pieces together the whole picture without having to define every rule or examine and review logs.

SIEM (Source: https://www.hbs.net/blog/benefits-of-log-consolidation-in-a-siem-environment) 

SIEM: from fragments to the big picture 

SIEM system works with logs from different systems as a whole. It processes them using various analytical rules, machine learning, AI and other advanced functionalities. It then evaluates important events and informs us about them, or directly performs a specific action.

Imagine that we have hundreds of different logs from different systems - firewalls, servers, applications. There may be several related events that are not suspicious at first glance and which would be very difficult to detect manually.

SIEM can analyze these logs, detect anomalies among them, put them in context and, based on predefined security rules assess which events pose a relevant threat to your environment.

In this case, it can directly trigger actions that protect your environment - for example, blocking suspicious access or isolating the compromised system.

In the case of the Microsoft cloud world, the platform stands out Sentinelthat goes beyond Azure Monitor and offers many other features. Sentinel stands out above all because of its easy native integration not only with the cloud world, which gives it an advantage over other competitors and greatly simplifies the connection of cloud resources.

What if...

Don't want to use a cloud platform for logging? There may be several reasons: price, functionality, dependence on a given vendor or simply you already have your favorite product that you want to continue using.

Although it is Azure Monitor natural and to some extent the easiest way to log cloud resources, it is not the only one. Many of the larger vendors already count on the cloud world and can therefore work with logs from similar services. In addition, they often come with a SIEM component as well, and can therefore be an interesting alternative to a Sentinel.

One such product is the globally popular Elastic stack (ELK)which combines several roles together and offers interesting alternatives in terms of licensing and operation.