Monitoring custom software with Microsoft Sentinel

Last updated on October 20, 2025

Sometimes people think that going live is the end of a software development project and that nothing of importance really happens after that. Or people might know that sure, software should be maintained throughout its entire lifespan, until it is decommissioned. But did you know your software should also be monitored? Because how else do you know what’s really going on; how are people using your application? Is everything going as expected, or are there perhaps some people who are using the application in unintended ways and taking advantage of its shortcomings, possibly for extremely malicious purposes?

Today, we need to be aware of a lot of different threats that can target the applications that we develop. And ideally, if a security breach occurs, we are notified about it and can respond to it immediately to control the damage. Instead of finding out about it six months after the effect when the hacker has already stolen our data and sold it forward to a criminal organization.

Of course, you might think that “Oh, I wrote such perfect code that there are no security issues and hence no need for monitoring”. But even though we aim to develop secure software, there’s always a chance a security vulnerability exists somewhere—just like there can be a bug before it’s noticed and fixed. And that is why monitoring is important—it alerts us of possible problems we didn’t know we had, so we can act on them.

Now you are probably thinking, isn’t reacting to monitoring alerts an operations problem? We have a SOC team who keeps an eye on Sentinel, how does this concern us developers? Well, the thing is, those incidents don’t just get created out of thin air. They require us developers to take proper actions first. Because at the end of the day, what those incidents depend on is quality logging.

Even the OWASP Top 10 that represents the most critical web application security risks has Security Logging and Monitoring Failures as one of the most critical vulnerability categories. According to it, an application is considered to have a logging and/or monitoring failure vulnerability if at least one of the following is true:

• Logs are only stored locally.
• Logs of applications and APIs are not monitored for suspicious activity.
• Appropriate alerting thresholds and response escalation processes are not in place or effective.
• The application cannot detect, escalate, or alert for active attacks in real-time or near real-time.

Like any other type of security, application security is about having multiple layers of security measures, so we have many points where we can notice and counter threats. Of course, we ideally detect and fix a security issue as early in the software development lifecycle as possible, but having our software monitored by an SIEM/SOAR system, in our case, Microsoft Sentinel, is one of these crucial layers just in case a security issue ever manages to make its way to production.

All of the security issues listed above can be remediated by using Microsoft Sentinel. Sentinel can alert us to these potential vulnerabilities so we can act before they become breaches. In this post, I’ll tell to you how Microsoft Sentinel can help us eliminate these web application security vulnerabilities.

Table of Contents

1. What is Microsoft Sentinel
2. It all starts with logging
   1. Which events to log?
   2. What information to log?
   3. Log entry format
3. Adding the logs to Microsoft Sentinel
   1. The quick and dirty method
   2. The best practice
   3. Using the Azure Monitor API
4. Surfacing alerts and taking actions based on the log data

What is Microsoft Sentinel

Microsoft Sentinel is a security information and event management (SIEM) solution that monitors IT systems and raises incidents if suspicious activity is detected. It can also monitor custom software, whether the application runs on Azure or not.

The service relies on an Azure Monitor Log Analytics workspace that contains log information from the monitored applications. When it notices suspicious log entries, it raises an alert in the Sentinel interface, which a SOC team can investigate. How Sentinel works is relatively straightforward, but there are a few key pieces that must come together to get the most out of the service.

1. The application code must log security-related entries whenever something suspicious happens.
2. The log entries must be written to a log analytics workspace connected to a Microsoft Sentinel instance.
3. Rules must be configured on Microsoft Sentinel that detail what kind of log entries it should monitor.
4. Actions must be configured to define further what steps are taken when such log entries are found.

It all starts with logging

The most crucial step is to ensure your application recognizes and logs security events in its code. Alerting on Microsoft Sentinel depends entirely on the application logs. If not done, Sentinel can’t pick up anything because it raises alerts based on the detected log entries. Hence, our application needs to implement high-quality logging so that the log events can be used to generate alerts if something suspicious is going on. Also, if sufficient information is not recorded, there will be no trail for forensic analysis to investigate the cause of problems or the source of the attack later.

Which events to log?

What events to log exactly depends on your application’s nature. Threat modeling is an excellent tool for identifying events that are important to log for your specific application and its business case. Still, below is a list of security events that most web applications should log. Azure and Entra ID also automatically log some of the events if your application uses them.

Authentication Events

• Successful user logins, including user ID and source IP.
• Failed login attempts, including reasons (e.g., incorrect password, locked account).
• Multi-factor authentication (MFA) successes and failures.
• Password reset requests and completions.
• Account lockouts due to repeated failed login attempts.
• Suspicious login attempts (e.g., from unusual locations or devices).
• Use of default, shared, or “break-glass” accounts.

Authorization Failures

• Authorization failures (e.g., access denied to a resource).
• Privileged access attempts (e.g., admin-only actions by non-admin users).

Session Management Failures

• Suspicious session activities (e.g., session hijacking attempts).
• Invalid session token or cookie usage.
• JWT validation failures (e.g., signature mismatch, expired token).

Input Validation Failures

• Input validation failures (e.g., unacceptable encodings, invalid parameter names or values).
• Protocol violations or malformed requests.
• Suspicious or unexpected input patterns (e.g., SQL injection attempts, XSS payloads).
• Excessive or repeated invalid inputs (e.g., brute force attacks on input fields).
• Unexpected responses from external APIs or services.

Output Validation Failures

• Output validation failures (e.g., invalid data encoding, database record mismatches).

Deserialization Failures

• Deserialization failures (e.g., invalid or unexpected serialized data).

Administrative Actions

You should log all actions that require administrative privileges. Below are some examples.

• Reading data only administrators can access.
• User account creation, deletion, or modification.
• Changes to user privileges or roles.
• Assignment or revocation of tokens or credentials.
• Configuration changes (e.g., system admin settings).

Sensitive Data Access and Changes

• Access to sensitive data (e.g., PII, payment card data).
• Creation, modification, or deletion of sensitive data.
• Data export or import activities (e.g., reports, backups).

Cryptographic Events

• Encryption or decryption activities.
• Cryptographic key generation, rotation, or deletion.
• Certificate validation successes and failures.

User-Generated Content Events

• Submission of user-generated content (e.g., comments, reviews).
• Validation or moderation results for user content.
• Rejection of inappropriate or malicious content.

File Upload and Processing Events

• File upload successes and failures.
• File validation results (e.g., virus scans, file type checks).
• File storage or deletion events.
• Suspicious file upload patterns (e.g., large numbers of uploads in a short time).

Legal and Compliance Events

• User consent for terms of use, privacy policies, or marketing communications.
• Opt-ins or opt-outs for legal agreements or permissions.
• Changes to user consent or preferences.

Suspicious and Malicious Activities

• Requests with unexpected HTTP methods or headers.
• Excessive 404 errors (e.g., potential scanning or enumeration attempts).
• CORS violations (e.g., unauthorized cross-origin requests).
• Use of known attack tools (e.g., detected by user agent).
• Path traversal attempts (e.g., accessing unauthorized file paths).
• Insecure direct object reference (IDOR) attempts.
• Sequencing failures (e.g., actions performed out of order).
• Attempts to bypass flow control or business rules.
• Actions that exceed predefined limits (e.g., rate limits, transaction limits).
• Suspicious or nonsensical actions in the business context.
• Suspicious transaction patterns (e.g., multiple high-value transactions in a short time).
• Fraudulent activities (e.g., fake account creation).
• Rate limit violations (e.g., excessive requests from a single IP).
• Abuse of system resources (e.g., excessive API calls, server resource exhaustion).

Optional Events (Based on Business Needs)

Use threat modeling to identify what events to log for your specific application and business case.

• High-value transactions (e.g., involves sensitive data or systems, cannot easily be undone or has significant consequences, likely targets in fraud).
• Data changes (e.g., updates to critical records).
• Excessive use of specific features or functions.
• Other suspicious or unexpected behavior not covered by the above categories.

What information to log?

Striking the right balance in what you log is important for achieving both high security and operational efficiency. If you log too little, you might not later have enough information to figure out what went wrong or who did what, which can make investigating security incidents really difficult. But if you log everything, you run the risk of accidentally capturing sensitive data. Logging a lot of information can also make it harder to find the useful stuff among all the not-so-relevant information. And let’s not forget that storing data costs money, so why would you unnecessarily pay for storing data you don’t need? The key is to log just enough: focus on what’s actually useful for troubleshooting, auditing, and security, and leave out anything you don’t truly need.

When (Time Information)

• Event Timestamp: The time the event occurred, which may differ from the log timestamp (delayed logging).
• Ensure all timestamps include the UTC offset for consistency (e.g.,2025-05-10T14:30:00Z).

Where (Location Information)

• Application Identifier: Name and version of the application generating the log (e.g.,myapp-v1.2.3).
• Application Address: Hostname, IPv4/IPv6 address, and port number of the application or server.
• Geolocation: Approximate location of the event (e.g., country, region).
• Code Location: Script name, module name, or function where the event was triggered.

Who (User or System Information)

• User Identity: A unique identifier for the user (e.g., user ID, username, or hashed reference ID). Avoid logging PII directly.
• User Type: Classification of the user (e.g., public, authenticated user, admin, search engine bot).
• Source Address: IP address or device identifier of the user (e.g.,192.168.1.1).
• User Agent: The HTTP user agent string (e.g., browser or device details).
• Session Identifier: A hashed or anonymized session ID for tracking user sessions.

What (Event Details)

• Event Type: A concise, consistent identifier for the event (e.g.,AUTHN_login_success,AUTHZ_fail).
• Event Severity: Severity level of the event (e.g.,INFO,WARN,ERROR,CRITICAL).
• Security Event Flag: If security and other application logs are stored in the same place, use flags to indicate whether the event is security-related or not.
• Event Description: A human-readable description of the event (e.g.,User login failed due to incorrect password).
• Action: The intended purpose of the request (e.g.,Log in,Update profile).
• Object: The affected resource or component (e.g.,user account,file,URL).
• Result Status: Outcome of the action (e.g.,Success,Fail,Defer).
• Reason: Explanation for the result status (e.g.,Incorrect credentials,Access denied).

How (Technical Details)

• Entry Point: URL, HTTP method, or page name where the event occurred (e.g.,/login,POST).
• Request Headers: Key HTTP headers (e.g.,User-Agent,Referer).
• Request Body: Sanitized and encoded request payload (if necessary).
• Protocol: Protocol used (e.g., HTTPS).
• Response Details: Status code, custom messages, or headers returned to the user.
• Interaction Identifier: A unique identifier for the interaction to link related events (e.g., correlation ID).

Data to Exclude or Handle Carefully

• Sensitive Data: Avoid logging sensitive personal data (e.g., passwords, PII, health data, payment information).
• Secrets: Do not log access tokens, encryption keys, or database connection strings.
• Session Identifiers: Replace with hashed values if needed for tracking.
• Internal Information: Mask or sanitize internal file paths, network names, and addresses.

Log entry format

To ensure logs are both secure and easily consumable by analysis tools, use a structured format such as JSON, which integrates well with platforms like Azure Sentinel. Maintaining a consistent schema across all log entries simplifies parsing, correlation, and automated processing.

It’s critical to validate and sanitize any data originating from clients before it is processed or written to logs to prevent injection attacks and maintain log integrity. Also, remember to always apply proper character encoding—preferably UTF-8—to avoid issues like log corruption or misinterpretation across systems.

Below is an example of a log entry in JSON format.

Adding the logs to Microsoft Sentinel

When your application encounters the above kind of suspicious activity, it should, at the very least, log it as a high-severity issue. Ideally, suspicious activity is also automatically followed up by safety measures for countering the potential attack. For example, if someone repeatedly gets their password wrong when attempting to log in, it could be interpreted as a brute force attack, and their account should be automatically locked. Microsoft Sentinel can help automate these actions, but more on that later. For now, let’s focus on getting those security log entries to the Sentinel monitoring scope.

Microsoft Sentinel is always connected to a single Azure Log Analytics workspace. When setting up Microsoft Sentinel, one of the key decisions is whether to use a single workspace for all logs or to create multiple Sentinel instances, each connected to separate workspaces. Do you want to get alerts from all monitored systems to a single Sentinel instance so you can view them all at once, or do you want each system in a separate instance instead? Separation makes sense if you have different teams monitoring different systems. On the other hand, you start to get a discount if a single workspace ingests over 100 GB of data per day.

The quick and dirty method

The quickest way to get up and running with Sentinel regarding monitoring custom software running on Azure would be to connect Sentinel to the same log analytics workspace as the app’s Application Insights instance. Then, you would not need to implement any particular logic for logging; simply log the errors as usual. However, Microsoft Sentinel is billed for the volume of data analyzed in Microsoft Sentinel and stored in the Log Analytics workspace, which means that if you were to connect the Applications Insights log analytics workspace to Sentinel, you’d make it ingest a lot of unnecessary information, resulting in higher than required costs.

The best practice

To be cost-efficient, you should only log the security-related events you want Sentinel to analyze in the workspace connected to the Sentinel instance. All other logging that is unnecessary for Sentinel to analyze would be better kept in a separate log analytics workspace connected to an Application Insights instance for more general application monitoring and troubleshooting. In practice, you need to add extra code to your project to direct the security-related log entries to a different log analytics workspace from the default one.

Using the Azure Monitor API

So, how do we log only those security events into a separate log analytics workspace? By calling the Azure Monitor REST API.

I’ve created a sample application (Azure Function) to demonstrate how you can call the REST API to write entries into a log analytics workspace. You can find all of the required code in my FunctionApp.SentinelLogging GitHub repository. The README file contains the necessary steps for setting up the required Azure resources. Enjoy!

Surfacing alerts and taking actions based on the log data

Once your application’s security events are ingested into the log analytics workspace connected to the Microsoft Sentinel instance, Sentinel can be used for monitoring your custom application precisely the same way as any other service.

1. First, you need to write queries using the Kusto Query Language (KQL) that surface your application’s log entries from the log analytics workspace that indicate potential security threats.
2. Then, those queries can be configured into rules within Microsoft Sentinel, which will then trigger incidents when the log entries surfaced by the KQL queries are detected.
3. Microsoft Sentinel can be configured to take automatic actions when those incidents are triggered, resulting in immediately executed countermeasures when specific conditions are met.

And ta-da! By following the above steps, we have now fulfilled the requirements for countering the logging and monitoring failures described on the OWASP Top 10 list and can consider our application vulnerability-free—at least in that regard.

Afterword

Security monitoring isn’t just a nice thing to have; it’s an integral part of building secure software. Writing secure code is, of course, something we strive to do, but no matter how careful we are, vulnerabilities can still slip through. Monitoring is that extra layer of defense that helps us catch the unexpected before it turns into something serious.

I hope this post gave you clear and practical guidance for setting up security monitoring for your own applications. If you try it out or have experiences to share, I’d love to hear about them in the comments.

And if you’d like to get notified whenever I publish new posts, feel free to subscribe to my blog or follow me on LinkedIn. You’ll find buttons for both in the sidebar (or at the bottom if you’re on mobile).

Until next time! Keep your applications monitored and your log entries meaningful. 😉

Laura