SAP BTP neu, M365 mit weniger Fehlalarmen

SAP BTP war bisher einer dieser Bereiche, in die Security-Teams kaum Einblick hatten. Mit dem Mai-Release von Falcon Shield ändert sich das: BTP bekommt eigene Posture-Checks. Bei M365 hat CrowdStrike vor allem bei dem Alert-Volumen nachgebessert.

SAP BTP: Mehr Transparenz für das SOC

BTP ist bei vielen Unternehmen der Bereich, in dem die Custom-Apps, Integrationen und Erweiterungen liegen, aufgesetzt vom SAP-Team, mit wenig Transparenz für das SOC.

Falcon Shield deckt das jetzt auf drei Ebenen ab: Posture-Checks, User-Inventar und Event-Monitoring. Die Anbindung läuft komplett read-only über drei OAuth-Service-Instanzen, es werden also keine Einstellungen verändert. Die Einrichtung ist etwas aufwändiger als bei anderen SaaS-Diensten, weil im BTP-Cockpit drei Service-Instanzen samt Service Keys anlegen werden müssen.

Nach der Einrichtung erfolgen dann die folgenden Checks:

• Default IdP statt Custom IdP: Der Check prüft, ob Plattform-User über einen eigenen Identity Provider laufen statt über den voreingestellten SAP ID Service.
• Default-IdP-User mit Admin- oder Viewer-Rechten: Zwei Checks fahnden nach Usern aus dem Default-IdP mit externer Mail-Domain, die Admin- oder Viewer-Rechte tragen.
• Subaccount-Administrator-Rolle: Der vierte Check prüft, an wie viele Personen die Subaccount-Administrator-Rolle vergeben ist. Je weniger, desto besser, denn die Rolle wird erfahrungsgemäß zu großzügig verteilt.

Außerdem unterstützt die Anbindung auch das User-Inventar und Event Montioring. Das User-Inventar zeigt alle Accounts der BTP-Umgebung in der Falcon Shield Oberfläche. Damit ist ohne Rückfrage beim SAP-Team sichtbar, wer dort überhaupt Zugriff hat.

Dazu kommt das Event-Monitoring mit zwei Quellen, die sich getrennt zuschalten lassen:

• Audit-Logs aus dem Audit Log Management Service: Logins und Logouts, Änderungen an Security-Konfigurationen, Zugriffe auf und Änderungen an Daten.
• Administrative Lifecycle-Events aus dem Cloud Management Service: angelegte oder gelöschte Subaccounts, geänderte Entitlements, neue App-Subscriptions.

M365: weniger Fehlalarme, einige neue Detections

Bei M365 ist nichts grundlegend neu, dafür wird einiges leiser. Am meisten Wirkung hat eine ganze Reihe von Entra-ID-Checks rund um Service Principals (abgelaufene, langlebige und bald ablaufende Zertifikate und Secrets): Sie ignorieren jetzt Managed-Identity-Service-Principals. Deren Credentials rotiert der Anbieter, man kommt an sie ohnehin nicht heran, und sie zu melden war reines Rauschen. Dazu kommt ein „Root domains only”-Schalter beim DMARC-Check für Exchange. Wer auf DMARC-Vererbung setzt, bekommt nun nicht mehr zu jeder Subdomain einen Alert.

Neu sind ein paar Threat-Detections, die zu handfesten Angriffsmustern passen. CAP Bypass via Device Spoofing fängt den Versuch ab, Conditional-Access-Policies über gefälschte Geräteattribute auszuhebeln. Passkey Registration from an Untrustworthy ASN schlägt an, wenn ein Passkey aus einem nicht vertrauenswürdigen Netz registriert wird, ein typisches Verhalten für Account-Takeover-Persistenz. Dazu kommen User Enumeration, anomaler Gerätezugriff über die Mobile App und eine erkannte Kampagne (AST51).