Advanced Security Information Model with LogServ and Sentinel

Advanced Security Information Model with LogServ and Sentinel

| Hemanth Kusampudi | Manuel Hauch | Martin Pankraz |

RISE Security Sentinel

YouTube

Spotify

Apple

Episode #305

Introduction

In episode 305 of our SAP on Azure video podcast we talk about Activating Advanced Security Information Model with LogServ and Sentinel

A few weeks back we talked about LogServ and how customers running RISE with SAP can use this to get their logs in Sentinel. That was the first step! We have now updated the solution to bring additional details and information into Sentinel to provide even better insights on your security.

To give us an update here, I am glad to have Hemanth from SAP, Manuel from BlueVoyant and Martin with us.

Find all the links mentioned here: https://www.saponazurepodcast.de/episode305

Reach out to us for any feedback / questions:

#Microsoft #SAP #Azure #SAPonAzure #MicrosoftSentinel #SAPRISE #Security #ASIM

Summary created by AI

  • SAP LogServ Sentinel Integration:
  • Hemanth, Martin, and Manuel explained how the updated SAP LogServ connector gives RISE and ECS customers more actionable security visibility by routing SAP infrastructure logs into native Microsoft Sentinel tables and enabling existing detection content.
    • LogServ Purpose: Hemanth explained that RISE with SAP and ECS customers use dedicated Azure subscriptions for isolated ERP workloads, but customers can lose infrastructure-level visibility when SAP manages the underlying cloud environment. LogServ addresses this by collecting relevant workload and infrastructure logs and exposing them to customer security tools such as Microsoft Sentinel.
    • Raven Context: Hemanth distinguished LogServ from Raven: LogServ primarily provides collected log data, while Raven processes security telemetry, metrics, and use cases into a broader security overview before integration with a SIEM. Together, they support shared visibility and responsibility between SAP and customers.
    • Updated Routing: The previous connector placed diverse sources—including Windows events, Linux and HANA audit logs, network flows, Web Dispatcher, DNS, and SAP application logs—into the generic SAPLogServ_CL table. The updated connector parses and routes supported sources into native Sentinel tables such as SecurityEvent, WindowsEvent, Syslog, ASimDnsActivityLogs, ASimWebSessionLogs, and ASimNetworkSessionLogs, while retaining SAPLogServ_CL as a fallback for unsupported or newly added sources.
    • Co-Engineering Roles: Martin clarified that SAP owns and publishes the connector, while Blue Voyant helped prioritize routing choices based on customer needs, particularly Windows security events and web sessions. Hemanth’s team validated the resulting configuration and published the updated connector through the joint SAP, Microsoft, and Blue Voyant engineering effort.
  • Normalization And Detection Value:
  • Manuel described how Blue Voyant used Microsoft Sentinel’s Advanced Security Information Model to normalize SAP data, allowing standard security detections to operate on RISE telemetry and producing an actionable customer finding shortly after deployment.
    • ASIM Normalization: Manuel explained that different products can generate similar security information in different formats, making separate detection rules difficult to maintain across many customers and data sources. ASIM provides a normalized schema that abstracts the underlying product, allowing common detections to work across sources such as Azure Firewall, Palo Alto firewalls, Windows systems, and SAP components.
    • Detection Example: In a customer test environment, Blue Voyant’s existing use case BV-70310, which detects an anomalous volume of blocked requests by IP, triggered after SAP web-session data was normalized. The event identified SAP Internet Communication Manager as the underlying product and provided visibility into the source, web activity, and request-volume anomaly.
    • Customer Investigation: The anomalous activity originated from an internal IP and was not determined to be malicious; Manuel said it appeared related to an internal application generating invalid requests or using outdated credentials. The example demonstrated that the integration can surface unusual activity that had previously remained outside the customer’s standard detection coverage, enabling the customer to investigate and stop the behavior.
    • Structured Event Data: Before transformation, Windows security events and Web Dispatcher events were stored as raw strings in one generic table, requiring each detection to parse the relevant content manually. After transformation, fields such as Windows process-creation details, command lines, hostnames, URLs, HTTP methods, source addresses, and response information are structured, allowing existing Windows and web-session detections to run with little or no modification.
  • Connector Upgrade Process:
  • Martin outlined separate onboarding paths for new and existing customers: new customers deploy the connector normally, while existing customers upgrade the Sentinel solution and update their data-collection configuration to receive the new routing and parsing behavior.
    • New Deployments: New customers can deploy the current LogServ data connector from the Microsoft Sentinel data connector pane and complete the standard onboarding process; the updated experience is applied from the start.
    • Existing Deployments: Customers with an existing LogServ connector deployment on version 3.0.4 or earlier should first upgrade the LogServ solution in the Sentinel Content Hub to version 3.0.5 or later. The solution upgrade does not modify deployed data-collection rules, intentionally avoiding an unexpected ingestion disruption.
    • DCR Update: After upgrading the solution, customers must update their existing data-collection rule or redeploy the connector and provide the new configuration details to SAP. Updating the existing rule is preferred because it avoids another SAP integration cycle.
    • Validation Timing: The upgrade guidance recommends exporting or retrieving the current configuration as a working template, selectively adding the updated data flows, waiting approximately 15 minutes for the change to take effect, and then verifying that the new destination tables are receiving LogServ data.
  • Future Security Capabilities:
  • Martin and Hemanth described the next phase of the collaboration, combining deterministic parsing and normalization with dynamic threat-detection agents and expanding LogServ and Raven coverage for firewalls, vulnerabilities, cloud posture, and security events.
    • Dynamic Detection: Martin said traditional routing, parsing, and normalization remain important but may not scale to every new source or previously unknown pattern. Microsoft is also investing in dynamic threat-detection agents that can discover relationships and suspicious behavior without requiring every data format or detection pattern to be defined in advance.
    • Defender Integration: Martin showed how traditional detections populate incidents and attack graphs in Microsoft Defender, while dynamic detection agents can identify additional relationships or patterns that were not covered by predefined rules. He pointed viewers to the Perception Agent announcement for further information planned around Microsoft Ignite.
    • Firewall Logs: Hemanth explained that SAP’s private-cloud environment is isolated and traditionally uses network security group controls, but SAP is now offering a centralized Layer 4 firewall service. Logs from that service are being included so customers can review traffic patterns, routing activity, blocks, and related detections centrally.
    • Raven Security Events: The team is working to bring more event-driven security information from Raven into Sentinel, including cloud security posture, vulnerability-management, and other security findings. This will enable detections and prioritization tailored to RISE environments rather than relying only on raw logs.
    • Expanded Coverage: Hemanth said LogServ coverage will also be enhanced for additional applications and services, including Web Dispatcher and cloud connectors. The stated direction is to make RISE security telemetry less opaque and provide customers and their security teams with a broader, shared view of the environment.

Links

Video index

Based on and using Hugo Cookbook Theme, Font Awesome Icons and Bulma CSS. | Thanks to Recipes4AJ to get me started. | Contact me via | Imprint & Privacy | Cookie settings