Microsoft Sentinel¶
Microsoft Azure Sentinel is a solution provided by Microsoft as part of its Azure cloud platform to help organizations monitor, detect, investigate, and respond to security threats and incidents across their entire cloud and on-premises environments. You can set up Wallarm to log events in Microsoft Sentinel.
Setting up integration¶
In the Microsoft UI:
-
Proceed to the Sentinel Workspace settings → Agents → Log Analytics agent instructions and copy the following data:
- Workspace ID
- Primary key
In the Wallarm Console UI:
-
Open the Integrations section.
-
Click the Microsoft Sentinel block or click the Add integration button and choose Microsoft Sentinel.
-
Enter an integration name.
-
Paste the copied Workspace ID and Primary key.
-
Optionally, specify the Azure Sentinel table for Wallarm events. If it does not exist, it will be auto-created.
Without a name, separate tables are created for each event type.
-
Choose event types to trigger notifications.
Details on available events:
-
Hits detected except for:
- Experimental hits detected based on the custom regular expression. Non-experimental hits trigger notifications.
- Hits not saved in the sample.
-
System related:
- User changes (newly created, deleted, role change)
- Integration changes (disabled, deleted)
- Application changes (newly created, deleted, name change)
- Vulnerabilities detected, all by default or only for the selected risk level(s) - high, medium or low.
- Rules and triggers changed (creating, updating, or deleting the rule or trigger)
- Scope (exposed assets) changed: updates in hosts, services, and domains
- On an hourly basis, you can get a notification with the number of requests processed during the previous hour
-
-
Click Test integration to check configuration correctness, availability of the Wallarm Cloud, and the notification format.
You can find Wallarm logs in your Microsoft Workspace → Logs → Custom Logs, e.g. the test
create_user_CL
log in Microsoft Sentinel looks as follows:Delay in sending data to new workspaces
Creating a Workspace on Sentinel for Wallarm integration can take up to 1 hour for all services to function. This delay can result in errors during integration testing and usage. If all integration settings are correct but errors continue to appear, please try again after 1 hour.
-
Click Add integration.
Types of Wallarm logs¶
Overall, Wallarm can log in Sentinel the records of the following types:
Event | Sentinel log type |
---|---|
New hit | new_hits_CL |
New user in a company account | create_user_CL |
Deletion of a user from a company account | delete_user_CL |
User role update | update_user_CL |
Deletion of an integration | delete_integration_CL |
Disabling an integration | disable_integration_CL or integration_broken_CL if it was disabled due to incorrect settings |
New application | create_application_CL |
Deletion of an application | delete_application_CL |
Application name update | update_application_CL |
New vulnerability of a high risk | vuln_high_CL |
New vulnerability of a medium risk | vuln_medium_CL |
New vulnerability of a low risk | vuln_low_CL |
New rule | rule_create_CL |
Deletion of a rule | rule_delete_CL |
Changes of an existing rule | rule_update_CL |
New trigger | trigger_create_CL |
Deletion of a trigger | trigger_delete_CL |
Changes of an existing trigger | trigger_update_CL |
Updates in hosts, services, and domains in exposed assets | scope_object_CL |
Changes in API inventory (if the corresponding trigger is active) | api_structure_changed_CL |
Amount of attacks exceeds the threshold (if the corresponding trigger is active) | attacks_exceeded_CL |
New denylisted IP (if the corresponding trigger is active) | ip_blocked_CL |
Disabling and deleting an integration¶
You can delete or temporarily disable the integration. While deleting stops sending notificatioins and completely deletes all configuration, disabling just stops sending notifications which you can at any moment re-enable with the same settings.
If for the integration the System related events are selected to trigger notifications, Wallarm will notify about both of these actions.
System unavailability and incorrect integration parameters¶
Notifications to the system are sent via requests. If the system is unavailable or integration parameters are configured incorrectly, the error code is returned in the response to the request.
If the system responds to Wallarm request with any code other than 2xx
, Wallarm resends the request with the interval until the 2xx
code is received:
-
The first cycle intervals: 1, 3, 5, 10, 10 seconds
-
The second cycle intervals: 0, 1, 3, 5, 30 seconds
-
The third cycle intervals: 1, 1, 3, 5, 10, 30 minutes
If the percentage of unsuccessful requests reaches 60% in 12 hours, the integration is automatically disabled. If you receive system notifications, you will get a message about automatically disabled integration.