19
10/2017 ·
MIDRANGE
MAGAZIN
Server-Dienste – der Schutz vor Schad-
software, die Passwort- und Benutzer-
sicherheit oder Konfigurations- und
Administrationsfehler im Vordergrund.
Die Zielsysteme werden auf Schwach-
stellen geprüft, die sich durch unsiche-
re Architekturentscheidungen, unsi-
chere Konfigurationen und unsichere
Codes ergeben.
Um mögliche sicherheitsrelevante
Schwachstellen zu ermitteln, wird in
der Regel zunächst bei den Diensten
der Server-Plattform ein authentifizier-
ter Schwachstellen-Scan mit möglichst
hohen Berechtigungen vorgenommen.
Eine weitere Maßnahme ist der authen-
tifizierte Schwachstellen-Scan des SAP-
Applikationsservers über RFC.
Die Analyse erfolgt auf den Ebenen
der Systemhärtung, Anmeldesicher-
heit, SAP-Basisberechtigungen, Patch-
Level, Sicherheit der RFC-Schnittstel-
len, Betriebssystemsicherheit, Log-
Analyse und des Quellcodes im Kun-
dennamensbereich. Den eigentlichen
Penetrationstest der Systeme führen
Security Analysts manuell durch – das
ist der eigentliche Mehrwert, denn nur
menschliche Security Analysts (im
Gegensatz zu automatisierten Tools)
können die im Rahmen von Vulnera-
bility Scans ermittelten Informationen
im Kontext des Kundensystems und auf
Basis der bisherigen Projekterfahrung
wirklich bewerten. Gleiches gilt für
den ABAP Code Review: Hier liegt der
Fokus auf der manuellen Analyse und
Bewertung auffälliger Codestellen.
Der Penetrationstest sowie die au-
thentifizierten Schwachstellen-Scans
werden meist ohne gültige Benutzer-
kennung ausgehend vom internen Bü-
ronetzwerk durchgeführt. Zur Durch-
führung werden virtuelle Systeme ge-
nutzt, die auf Standard-Client-Systeme
kopiert und dort gestartet werden.
Dieses Vorgehen hat den Vorteil, dass
so nur auf Kundenrechnern gearbeitet
wird und während des Tests anfallen-
de Daten nicht das Unternehmens-
netzwerk bzw. Unternehmenssysteme
verlassen. Technische Voraussetzung
dafür ist genügend Arbeitsspeicher,
ausreichender Plattenplatz und BIOS-
Einstellungen, die die Virtualisierung
erlauben. Jedoch werden die virtuellen
Systeme durch den Auftragnehmer be-
reitgestellt und vor ihrem Einsatz noch-
mals auf Malware gescannt.
Die Ergebnisse werden zuvor defi-
nierten Risikoklassen zugeordnet und
ihre Bewertung erfolgt ausschließlich
aus der Perspektive der IT-Sicherheit –
mit Blick auf Systeme und Daten im
Geltungsbereich. Risiken bezogen auf
Geschäftsprozesse des Unternehmens
sind daraus nicht direkt ableitbar.
Angesichts der Abhängigkeit der Ge-
schäftsprozesse von der IT sollte hier
allerdings eine enge Abstimmung zwi-
schen den Abteilungen Risikomanage-
ment und Interne IT erfolgen.
Die Bewertung der Kritikalität ori-
entiert sich daran, welche Auswirkun-
gen die ermittelten Schwachstellen
auf die IT-Sicherheit der Systeme oder
Daten haben können, inwieweit die Fin-
dings von Best Practices der IT-Sicher-
heit abweichen und inwiefern es sich
um Vorbedingungen für eine Cyber-
Attacke handeln könnte.
Das SAP-Audit legt offen, inwieweit
Angreifer in die Infrastruktur vordrin-
gen und in welchem Ausmaß sie die
Organisation schädigen können. Es
ist auch das Mittel der Wahl, wenn es
darum geht, das Sicherheitsbewusst-
sein innerhalb der Organisation zu
steigern oder dem Management einen
tieferen Einblick in die tatsächlichen
Risiken des Unternehmens zu geben.
Das SAP-Audit bildet somit den aktu-
ellen Zustand der SAP-Systeme ab und
ist eine gute Grundlage, um die SAP-
Security mit dem Risikomanagement
zu vereinen. Die Ergebnisse werden
von den Security Analysts in einem Be-
richt zusammengefasst, der kritische
Gefährdungen durch Berechtigungen,
Kommunikationsschnittstellen, Cus-
tom-ABAP-Code, bekannte SAP-Soft-
warefehler oder Fehlkonfigurationen
enthält. Daneben beinhaltet er „Proofs
of Concept“ für die Ausnutzbarkeit der
kritischen Gefährdungen und emp-
fiehlt Maßnahmen zur Schließung der
relevanten Sicherheitslücken.
Der eigentliche Mehrwert der Ana-
lyse besteht also darin, aus den Ergeb-
nissen wirksame Gegenmaßnahmen
ableiten zu können, um die Sicherheit
der Organisation dauerhaft zu steigern.
Dabei stehen kritische Risiken und
Quick Wins im Vordergrund. Auftrag-
geber sollten sich daher nicht mit einer
Auflistung rein technischer Findings
zufriedengeben, sondern Wert darauf
legen, dass der Tester mögliche struk-
turelle Ursachen aufzeigt, wie etwa feh-
lende oder inkonsistente Prozesse und
Verantwortlichkeiten, und darüber hin-
aus Empfehlungen abgibt, wie sich die
Sicherheitsprobleme lösen lassen.
Es hat sich bewährt, die Ergebnis-
se im Rahmen eines Workshops zu be-
sprechen. Hier lassen sich Fragen zu
Kritikalität, Risikobewertung und zur
Priorisierung klären und Empfehlun-
gen des Dienstleisters für wirksame
Gegenmaßnahmen eingehend erörtern.
Externe Anbieter können wertvolle
Unterstützung leisten, wenn es darum
geht, Maßnahmen und Risiken auf Ba-
sis der Findings detailliert zu begrün-
den und diese in einen größeren Bedro-
hungszusammenhang einzuordnen.
Wichtig: Sicherheitsprüfungen wie
SAP-Audits sind immer eine Moment-
aufnahme. Sowohl die Angriffe als auch
die getestete Infrastruktur oder Anwen-
dung entwickeln sich weiter, so dass
die Ergebnisse eines Audits mit der Zeit
an Wert verlieren. Daher sollten solche
Tests regelmäßig durchgeführt werden,
wobei nicht immer alle Aspekte getes-
tet werden müssen, sondern man sich
eventuell auf die Änderungen fokussie-
ren kann. Nach spätestens zwei Jahren
sollte aber in der Regel ein kompletter
Retest durchgeführt werden.
Otto von Natzmer
ó
Û
