Bei einem Penetration Test wird eine Cyberattacke auf ein internes oder externes System, Netzwerk oder eine Web oder Mobile Applikation durchgeführt, um möglichst viele Risiken aufzudecken und messbar zu machen. Dies beinhaltet auch die Sicherheit der Cloud und Container. Ziel ist es, mögliche Angriffspfade zu validieren und die Angriffsfläche insgesamt durch Aufdecken der bestehenden Risiken zu reduzieren. Jeder Penetration Test wird individuell geplant und den Bedürfnissen mit dem Blick auf das grosse Ganze angepasst. Bei einem Penetration Test werden oft automatisierte Tools und manuelle Anfragen kombiniert. Effizienz steht dabei im Vordergrund und es wird im speziellen nicht das Blue Team und dessen Reaktion auf die Attacke überprüft. Falls dies gewünscht wird, sollte stattdessen ein Red Teaming durchgeführt werden.
Falls folgende Fragen in Ihrem Unternehmen noch offen sind, empfiehlt sich ein Penetration Test:
Sinn des Scoping-Meeting ist es, die Ziele des Penetration Tests zu definieren und genügend Wissen über die zu testenden Systeme zu transferieren, damit auf deren Basis dann die Offerte erstellt werden kann. Die Fragen drehen sich dabei meistens um die Anzahl Systeme, Funktionalitäten der Applikationen, unterschiedliche Rollen und Berechtigungen, Testtiefe und Testszenarien.
Auf Basis des Scoping-Meetings wird die Offerte erstellt. Nebst den Zielen, Methoden und Rahmenbedingungen enthält diese auch einen Durchführungsvorschlag. Dabei ist selbstverständlich nichts in Stein gemeisselt und die Offerte wird gerne den Bedürfnissen angepasst. Verrechnet wird grundsätzlich immer nach tatsächlichem Aufwand.
Im Kick-Off werden die Testdetails mit den verantwortlichen Personen besprochen. Hier sind insbesondere die Definition der genauen Zielsysteme und das Bereitstellen von allfälligen Accounts für den Test zentral. Auch die schnelle und reibungslose Kommunikation während des Tests wird in diesem Meeting sichergestellt.
Die Tests werden in enger Koordination mit der verantwortlichen Person durchgeführt, um sicherzustellen, dass umgehend auf Probleme reagiert werden kann. In der zur Verfügung stehenden Zeit werden dann möglichst viele Testdaten gesammelt und allfällige kritische Befunde umgehend kommuniziert.
Die gesammelten Daten werden ausgewertet und Massnahmen ausgearbeitet. Die besten Massnahmen nützen nichts, wenn diese nicht umsetzbar sind oder zu viele Ressourcen benötigen. Deshalb wird hier insbesondere die Umsetzbarkeit der Massnahmen in der getesteten Infrastruktur geprüft und allfällige Workarounds werden mit einkalkuliert.
Sämtliche Resultate werden zusammengefasst und ausgewertet. Für alle Risiken werden Massnahmen vorgeschlagen und deren Priorität festgehalten. Der Bericht enthält auch Informationen über die eingesetzten Tools und Methoden, so dass diese in Zukunft auch selbst eingesetzt werden könnten.
In einem Abschlussmeeting wird sichergestellt, dass die Resultate und Massnahmen aus dem Test verstanden werden und umgesetzt werden können. Da Fragen meistens erst bei der Behebung auftauchen, sind wir selbstverständlich für weitere Rückfragen stets erreichbar und geben gerne Auskunft.
Sämtliche Resultate werden in einem Schlussbericht (PDF, EXCEL und JSON) übermittelt und über die Plattform Mesher zur Verfügung gestellt. Hier beginnt die eigentliche Arbeit. Die Cyber Sicherheit kann nur erhöht werden, sofern auch Massnahmen umgesetzt werden. Deshalb ist es uns ein zentrales Anliegen, dass die Erkenntnisse aus dem Tests am richtigen Ort im richtigen Format ankommen und Medienbrüche eliminiert werden.
Alle Findings werden von uns gemäss ihrer Eintrittswahrscheinlichkeit und Auswirkung kategorisiert. Nach Bedarf kann auch für jede Schwachstelle zusätzlich der CVSS Score berechnet werden.
Jeder Bericht enthält ein Executive Summary, in welchem die Resultate und empfohlenen Massnahmen auf einer Seite zusammengefasst sind und in Diagrammen veranschaulicht werden.
Über Mesher wird Ihr aktueller Sicherheitslevel erfasst und Sie können den Return on Investment für die unterschiedlichen Massnahmen einsehen. Hier sind auch sämtliche Resultate visualisiert und können dank Integrationen mit bestehenden Tools verknüpft werden. Mit der Plattform können technische Massnahmen direkt mit Tasks den entsprechenden Personen zugeteilt werden und agiles Arbeiten ohne Medienbrüche wird ermöglicht.
Web Applikationen werden nach dem bewährten OWASP Application Security Verification Standard (ASVS) geprüft.Der ASVS ist eine von der Community gesteuerte Initiative, die Rahmenbedingungen für Sicherheitsanforderungen und -massnahmen auf Anwendungsebene schafft. Ihr Schwerpunkt liegt auf der Definition der funktionalen und nicht funktionalen Sicherheitsmassnahmen, die beim Entwerfen, Entwickeln und Testen moderner Webanwendungen und Webservices erforderlich sind.
Folgende ASVS Anforderungskapitel können in Rahmen eines Penetration Tests geprüft werden:
Durch die Überprüfung einer Web Applikation auf die ASVS-Anforderungen, sind automatisch auch die bekannten OWASP Top Ten abgedeckt. Die OWASP Top Ten wurden als Awareness-Dokument konzipiert, um auf die kritischsten Sicherheitslücken aufmerksam zu machen. Als solches beschreiben die OWASP Top Ten Risiken und nicht unbedingt testbare Anforderungen. Deshalb empfiehlt OWASP die Verwendung von ASVS für das Etablieren eines Sicherheitsstandards für Web Applikationen. Durch die ASVS Level und das Beschränken auf bestimmte Kapitel, kann dennoch die Testtiefe gut gesteuert werden.
Der praktische Web App Penetration Test kann in zwei Teilen betrachtet werden. Im ersten Teil werden Härtungsmassnahmen und Konfigurationen wie TLS-Konfiguration, Cookie-Attribute, HTTP-Headers, Sessionmanagement usw. geprüft. Dieser Teil kann abschliessend in einem vordefinierten Zeitrahmen beurteilt werden. Im zweiten Teil wird dann die Eingabeprüfung, die Bereinigung der Ausgabe, Zeichencodierung, Massnahmen zur Zugriffssteuerung usw. getestet. In diesem Teil werden auch mögliche Injection-Angriffe wie XSS, Template, SQL-Injection und andere Angriffe wie Remote Code Execution und Authentication-Bypasses geprüft. Je nach gebotenen Funktionalitäten und aufgrund der vielen Angriffsmöglichkeiten wird in diesem Teil auch vermehrt auf automatisierte Tools zurückgegriffen, damit die Applikation auch möglichst flächendeckend untersucht werden kann. Für den zweiten Teil wird am besten ein Zeitrahmen definiert, in welchem nach Best Effort Prinzip nach Schwachstellen gesucht wird. Somit kann für den zweiten Teil auch die Testtiefe gut gesteuert und sinnvoll gewählt werden.
In einem externen Penetration Test werden die externe (aus dem Internet) erreichbaren Systeme auf mögliche Angriffe untersucht. Dabei kann der Scope auf einige Systeme, oder auf ein ganzes Unternehmen als solches festgelegt werden. Im Unterschied zu einem Web Application Penetration Test wird dabei nicht jede Applikation tiefgehend und auf fehlende Härtungsmassnahmen geprüft, sondern der Fokus liegt auf praktikablen Angriffswegen, die einem realen Angreifer das Kompromittieren von Systemen und eine weitere Verbreitung auf interne Systeme ermöglichen würde.
Bei einem Penetration Test steht immer die Effizienz im Vordergrund und es ist das Ziel, auf schnellem Weg möglichst viele Angriffsmöglichkeiten aufzudecken. Entsprechend macht es wenig Sinn, gegen bestehende Verteidigungsmechanismen anzukämpfen. Sollte eine Überprüfung der bestehenden Verteidigungsmechanismen und die Reaktion auf Angriffe im Vordergrund stehen, handelts es sich eher um ein Red Teaming oder Purple Teaming. Die Grenzen sind dabei nicht immer strikt zu ziehen und gerne gehen wir auf Ihre individuellen Wünsche ein. Ein externer Penetration Test lässt sich auch gut mit einer Phishing-Awareness-Kampagne und Open Source Intelligence (OSINT) Gathering kombinieren, um ein möglichst umfassendes Bild über die externe Angriffsfläche zu erlangen.
In einem internen Penetration Test werden Angriffswege im internen Netzwerk eines Unternehmens untersucht. Die typische Frage, die hier beantwortet wird, ist:
«Was passiert nach einem erfolgreichen Angriff über Phishing oder externe Systeme?»
Dabei wird das Szenario so gewählt, dass von einem kompromittierten System ausgegangen wird (Assumed Breach) und mit denselben Methoden und Tools nach Angriffspfaden gesucht wird. Das Untersuchen und Bereinigen dieser Angriffsmöglichkeiten ist eine hervorragende Methode sich vor Ransomware zu schützen, da diese nach der initialen Kompromittierung dieselben Methoden anwenden, um maximalen Schaden anrichten zu können. Während beim Phishing-Awareness nur die Prozentrate gesenkt und somit die Wahrscheinlichkeit verringert werden kann, sind nicht vorhandene Verbreitungsmöglichkeiten ein echter Show-Stopper für Angreifer. Dies wird umso zentraler, da die Awareness und das Vulnerability- und Patch-Management noch so gut sein kann, die Phishing-Click-Rate wird wohl nie 0% erreichen und die Angreifer sind häufig schneller als das beste Patch-Management. Wie bei jedem Penetration Test steht Effizienz im Vordergrund und das Testen von Verteidigungsmechanismen und die Reaktion auf Angriffe sind nicht Teil des Tests. Dafür eignen sich Purple und Red Teamings besser.
In einem Mobile Application Penetration Test wird eine Mobile App auf vorhandenen Sicherheitslücken und fehlende Härtungsmassnahmen geprüft. Einerseits wird die Kommunikation mit dem Server geprüft, aber auch wie die Daten auf dem Gerät gesichert sind. Dazu wird der bewährte Mobile Application Security Verification Standard (MASVS) von OWASP verwendet.
Der MASVS ist ein Gemeinschaftsprojekt zur Schaffung eines Frameworks von Sicherheitsanforderungen, die für den Entwurf, der Entwicklung und den Test sicherer mobiler Applikationen für iOS und Android erforderlich sind. Der MASVS kann verwendet werden, um ein gewisses Mass an Vertrauen in die Sicherheit mobiler Anwendungen zu schaffen. Die Anforderungen wurden mit den folgenden Zielsetzungen entwickelt:
Die MASVS definiert zwei Sicherheitsüberprüfungsstufen (MASVS-L1 und MASVS-L2) sowie eine Reihe von Reverse-Engineering-Resilienzanforderungen (MASVS-R). MASVS-L1 enthält allgemeine Sicherheitsanforderungen, die für alle mobilen Anwendungen empfohlen werden, während MASVS-L2 auf Anwendungen angewendet werden sollte, die hochsensible Daten verarbeiten. MASVS-R umfasst zusätzliche Schutzmaßnahmen, die angewandt werden können, wenn die Verhinderung von Bedrohungen auf der Client-Seite ein Entwicklungsziel ist. Die Erfüllung der Anforderungen in MASVS-L1 führt zu einer sicheren App, die den Best Practices für Sicherheit folgt und nicht unter den üblichen Schwachstellen leidet. MASVS-L2 fügt zusätzliche Defense-in-Depth-Kontrollen hinzu, wie z. B. SSL-Pinning, was zu einer App führt, die gegen ausgefeiltere Angriffe widerstandsfähig ist - vorausgesetzt, die Sicherheitskontrollen des mobilen Betriebssystems sind intakt und der Endbenutzer wird nicht als potenzieller Angreifer betrachtet. Die Erfüllung aller oder eines Teils der Softwareschutzanforderungen in MASVS-R hilft dabei, spezifische clientseitige Bedrohungen zu verhindern, bei denen der Endnutzer böswillig ist und/oder das mobile Betriebssystem kompromittiert ist.
Folgende MASVS Anforderungskapitel können in Rahmen eines Mobile Application Penetration Tests geprüft werden:
Dank dem Shared Responsibility Model kann zumindest ein Teil der Verantwortung an den Provider abgetreten werden. Nach dem Motto Vertrauen ist gut, Kontrolle ist besser sollte aber auch hier regelmässig die vorhandene Angriffsfläche überprüft werden und verhindert werden, dass sich am Ende niemand verantwortlich sieht. Bei Hybrid-Lösungen, zum Beispiel bei einer Integration eines on-premise Active Directory mit einem Azure AD, können neue Möglichkeiten für Angreifer entstehen, welche verheerende Ausmasse annehmen können. Zusätzlich ist es für Angreifer häufig einfacher, gestohlene oder geleakte Credentials einzusetzen und die Zugriffe auf Ressourcen sollten so restriktiv wie möglich gehalten werden und regelmässig überprüft werden. Wir kennen die aktuellen Bedrohungen und helfen Ihnen, die Angriffsfläche trotz der Dynamik in diesem Gebiet möglichst klein zu halten.
Aufgrund ihrer Flexibilität werden Container in fast allen Stufen der Softwareentwicklung eingesetzt, sei es Development, Testing oder Deployment. Idealerweise wird in der CI/CD-Pipeline schon grosser Wert auf Cyber Security gelegt und als fester Bestandteil der Requirements und Tests angesehen. Aufgrund der Automatisierung und Flexibilität können kleine Fehler grosse Auswirkungen haben und eine regelmässige Überprüfung der Sicherheitsaspekte ist sehr zu empfehlen. Das Least-Privilege-Prinzip sollte rigoros durchgesetzt werden, da zu viele Berechtigungen im Ernstfall zu fatalem Schaden führen können. Genau diese Punkte schauen wir mit Ihnen gemeinsam an und liefern gerne auch bezüglich Cyber Security die geschätzte Flexibilität.
