Heutige IT-Systeme und -Infrastrukturen bieten aufgrund ihrer kaum noch überschaubaren Komplexität mehr Angriffsflächen für Hacker denn je. Vor diesem Hintergrund steigt die Bedeutung von Security Assessments. Doch Penetration Testing muss heute auch die moderne Softwareentwicklung und die Cloud berücksichtigen, um Angriffsrisiken zu minimieren.

Ein wichtiges Verfahren zur Abwehr von IT-Sicherheitsgefahren ist das Penetration Testing, kurz Pentest: Im Unternehmen etablierte oder von externer Seite gebuchte „Red Teams“ nutzen die gleichen Techniken und Tools wie Kriminelle, um in unternehmenseigene IT-Infrastrukturen einzudringen. Ziel ist es, Schwachstellen in IT-Systemen, Netzwerk und Anwendungen aufzudecken und zu beseitigen, bevor echte Angreifer sie ausbeuten können. Der mit dieser Aufgabe betraute Sicherheitsexperte lässt im Rahmen einer simulierten Attacke verschiedenste Tests durchführen, um potenzielle Einfallstore für Angreifer und Malware aufzudecken.

Risikoeinschätzung

Auf der Management-Ebene gewinnt die Risikoabwägung an Bedeutung, gilt es doch, finanzielle Auswirkungen von Cyberangriffen einzukalkulieren. Allerdings ist gerade auf dieser Ebene ein Bewusstsein dafür zu schaffen, dass Pentests lediglich dabei helfen, die Sicherheitslage der IT-Umgebung zu verstehen. Denn die Schwachstellenanalyse kann nie zu einem gänzlichen Ausschalten von Vorfällen führen – zu viel Bewegung ist in diesem Katz-und-Maus-Spiel von Angriff und Verteidigung. Die Sicherheitsexperten von Unternehmen können durch die gewonnenen Erkenntnisse jedoch Entscheidungen im spezifischen Kontext besser abwägen.

Zwei Paradigmenwechsel in der IT tragen allerdings zu einer Einschränkung der so wichtigen Sicherheitsvorhersagen bei: die agile Softwareentwicklung und das Cloud Computing. Dies bedeutet, dass das Hauptaugenmerk beim Pentesting vom Gesamtsystem abrücken und bereits früher und flexibler im Entwicklungsprozess ansetzen muss, um der Versicherungsfunktion wieder gerecht zu werden.

Agilität und Flexibilität

Eine der verbreitetsten Vorgehensweisen für das klassische Pentesting beruht auf dem Information System Security Assessment Framework (ISSAF) mit seinen drei Phasen (Bild). Nach Durchführung des Pentests erhält das Unternehmen einen Testbericht mit den aufgedeckten Schwachstellen und deren Schadpotenzial, sodass das Unternehmen aktiv werden und die Schwachstellen beseitigen kann.

Dieses Prozedere hat nach wie vor seine Gültigkeit für Pentests von IT-Infrastrukturen, deren Weiterentwicklung nach dem klassischen Wasserfallprinzip erfolgt. Das Testen orientiert sich dabei an Projektmeilensteinen, die durch einen eng gesteckten und damit unflexiblen Rahmen vorgeben sind. Ein solches Modell ist schwer mit den heutigen Projektlebenszyklen der Softwareentwicklung in Einklang zu bringen, die von steigender Geschwindigkeit und höherem Druck einer schnellen Marktreife geprägt sind. In einer schnelllebigen Entwicklungswelt erhalten die Sicherheitsexperten nicht mehr ihr Zeitfenster für die erforderlichen Tests am Projektende.

Information System Security Assessment Framework (ISSAF) für Pentests. Bild: Zscaler/LANline

Im agilen Entwicklungsprozess laufen die Entwicklungsschritte und kürzeren Zyklen (nicht umsonst „Sprints“ genannt) und häufig auch parallel nebeneinander ab: Die Häufigkeit der Releases steigt, sodass Organisationen wesentlich öfter neue Softwareversionen auf ihren Systemen implementieren müssen. Damit in einer solch agilen Welt Sicherheit angemessene Berücksichtigung findet, muss das Testen zum Teil des Planungsprozesses werden. Die Einbettung der Sicherheitsexperten mit deren Beratungsfunktion in teamübergreifende Entwicklungsressourcen ist die notwendige Folge: Die Tester müssen sich vom Gatekeeper vor der Einführung einer Lösung zum Berater wandeln, der frühzeitig im Entwicklungsprozess involviert ist. Je früher die Sicherheitstests stattfinden, desto schneller und kosteneffizienter lassen sich Schwachstellen beheben.

Im Zuge der agilen Entwicklung kommt für den Applikationstest automatisiertes Code-Scanning zum Einsatz, das bereits im Entwicklungs- und Planungsprozess eingebettet sein sollte. Ein typischer Arbeitsablauf im agilen Development sieht am Ende eines Entwicklungstages automatisierte Testläufe zum Code-Check vor. Für die Behebung entdeckter Schwachstellen ist dementsprechend Zeit einzuräumen. Darüber hinaus sind nicht nur Code-Tests, sondern auch ein Review der Releases in der Infrastruktur erforderlich. Dadurch entsteht die Anforderung nach der sofortigen Verfügbarkeit entsprechender Infrastruktur, die der Verantwortliche bereitstellen muss.

Vorgefertigte, automatisierte Systemkonfigurationen sind ein Muss, um den Anforderungen an schnelle Verfügbarkeit für das Testing Rechnung zu tragen. Dabei werden die Pentester im Vorfeld aktiv und stellen geprüfte Builds zur Durchführung der Tests bereit.

Infrastruktur-Pentests für die Cloud

Auch mit der Einführung der Cloud gehen neue Anforderungen an IT-Systeme und deren Sicherheitsevaluierung einher. Wenn Daten nicht mehr intern vorliegen, sondern zu einem CSP (Cloud-Service-Provider) wandern, rückt das Prinzip „Trust but Verify“ in den Vordergrund. Das klingt paradox in einer Welt mit einer Sicherheitsorientierung, die nach „Zero Trust“ verlangt. Diese Aussage trifft vor allem auf „Software as a Service“-Modelle zu, in der Infrastruktur- und Applikationstests nicht durchgängig (Ende zu Ende) möglich sind. Jahrelang untersuchten Spezialisten mittels Pentesting die verschiedenen Schichten einer N-Tier-Architektur mittels verschiedenster Exploit-Szenarien, wobei der Kunde den Zeitrahmen vorgeben konnte. Doch Infrastruktur-Testing wird komplizierter in einer Welt, die multimandantenfähige Systeme und geteilte Ressourcen berücksichtigen muss.

Ausgangspunkt ist hier die Frage der Besitzverhältnisse: Der Kunde eines Pentesters ist der Lizenznehmer, der für die Nutzung des Services zahlt. Die Infrastruktur an Servern, Kabeln etc. sind Eigentum des Service-Providers. Die Komplexität des Prozederes steigt, wenn diese angemieteten Strukturen zu berücksichtigen sind. Dann muss der Pentester den Provider mit einbeziehen, wenn es beispielsweise um den Test von IP-Adressen geht oder die gegebenenfalls ausgelösten Alerts Erklärungsbedarf hervorrufen.

Cloud-Mythen

Noch ranken sich Mythen um das Pentesting der Cloud. Eine Sichtweise geht davon aus, dass die Cloud mit einer Black Box gleichzusetzen ist, andere stehen auf dem Standpunkt, dass die Cloud Steuerungs- und Sicherungsmöglichkeiten reduziert. Ein weiterer Ansatz berücksichtigt den Ausbau des Vertrauensverhältnisses mit dem CSP durch regelmäßige Checks und Reevaluierung. Um heutige Sicherheitsanforderungen zu erfüllen, gilt es, alle Umgebungen – unabhängig davon, ob diese intern oder extern vorgehalten werden – in die Sicherheitsanalysen einzubeziehen. Der Standort der Daten darf dabei keine Rolle spielen.

Grundvoraussetzung für Unternehmen sollte sein, dass sie die Daten, die sie in die Cloud schicken, klassifiziert haben und angemessene Sicherheitsmaßnahmen für diese Daten existieren. Unternehmen müssen evaluieren, ob sicherheitsspezifische Vorkehrungen getroffen wurden, die das Risiko von Datenverlusten minimieren. Grundsätzlich sollten auch Cloud-Service-Provider Tests der Infrastruktur nicht kategorisch ablehnen, sondern diese in einer speziellen Umgebung und mit einer Koordination zwischen CSP und beauftragtem Pentest-Unternehmen ermöglichen. Ist der Test einer Infrastruktur nicht möglich, so lässt sich die Infrastruktur mittels standardisierter Cloud-Security-Assessment-Fragebögen validieren, herausgegeben beispielsweise von der Cloud Security Alliance (CSA). Weitere Kriterien können eine Zertifizierung nach ISO 27001 oder die Einhaltung der rechtlichen Vorschriften durch den Datenschutzbeauftragten sein. Nicht zuletzt sollte ein Unternehmen einen Vertrag zur Auftragsdatenverarbeitung einfordern, was nach deutschem Recht sogar zwingend vorgeschrieben ist.

Perspektivwechsel

Pentesting ist aufgrund der digitalen Transformation und agileren Entwicklungszyklen einem Wandel unterworfen. Auch wenn ein Test mit wehenden Fahnen bestanden wurde, bedeutet das nicht notwendigerweise, dass das Gesamtsystem sicher ist. Unternehmen tun gut daran, im Zuge ihrer Testverfahren ihren Blickwinkel zu verändern: Wenn sie von der klassischen Verteidigungshaltung abrücken und Angriffe nach dem Red-Teaming-Prinzip im realitätsnahen Szenario durchführen lassen, bringt das oftmals neue Einblicke.

Chris Hodson ist Director of Information Security EMEA bei Zscaler ().