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. 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.
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:
In einem IoT, IIoT oder OT Penetration Test wird die Sicherheit vernetzter Geräte, industrieller Steuerungen und eingebetteter Systeme ganzheitlich überprüft. Ziel ist es, Schwachstellen in Hardware, Firmware und Kommunikation aufzudecken, die zu einer Kompromittierung des Geräts, der Infrastruktur oder der verarbeiteten Daten führen können.
Zu Beginn werden die Hardwarekomponenten des Geräts identifiziert und analysiert. Dazu zählen unter anderem Prozessoren, Speicherbausteine, Debug-Schnittstellen (z. B. JTAG, UART, SWD) sowie zusätzliche Kommunikationsmodule. Anschliessend wird geprüft, ob vorhandene Sicherheitsmechanismen wie Secure Boot, Debug-Sperren, Speicherabsicherung oder physische Schutzmassnahmen umgangen werden können. Eine erfolgreiche Umgehung kann unter anderem zur Extraktion oder Manipulation der Firmware, sensibler Konfigurationsdaten oder kryptografischen Schlüsselmaterials führen.
Abhängig von der Funktionalität des Geräts und den verfügbaren Schnittstellen werden weiterführende Tests durchgeführt. Diese umfassen unter anderem:
Bei Bedarf wird die Firmware des Geräts zusätzlich nach der OWASP Firmware Security Testing Methodology untersucht. Dabei erfolgt sowohl eine statische Analyse des Firmware-Images (z. B. Dateisysteme, Konfigurationsdateien, Hardcoded Secrets, bekannte Schwachstellen in Bibliotheken) als auch eine dynamische Analyse durch Emulation oder Laufzeitanalyse der Firmware. Dies ermöglicht es, das tatsächliche Verhalten des Systems unter Angriffsbedingungen zu bewerten.
Zur strukturierten Bewertung der Sicherheit orientiert sich der Test an etablierten Best Practices und Standards, unter anderem:
In einem AI & LLM Application Penetration Test wird eine KI und LLM basierte Applikation auf vorhandene Sicherheitslücken und fehlende Härtungsmassnahmen geprüft. Im Fokus stehen Risiken, die durch natürliche Sprache als Eingabe, Retrieval wie zum Beispiel RAG, System Prompts, Meta Prompts sowie Tool und API Integrationen entstehen. Diese Angriffsflächen werden mit klassischen Web oder API Penetration Tests oft nur teilweise abgedeckt.
Als Referenzrahmen verwenden wir die OWASP Top 10 for Large Language Model Applications. Diese bietet eine strukturierte Übersicht der wichtigsten Risikoklassen für LLM Anwendungen.
Zusätzlich nutzen wir den OWASP Large Language Model Security Verification Standard, kurz LLMSVS, als Standard für Sicherheitsanforderungen an LLM gestützte Applikationen.
Ergänzend ziehen wir MITRE ATLAS als Knowledge Base heran, um Angreifer Taktiken und Techniken gegen AI und ML Systeme in praxisnahe Testszenarien zu überführen.
Der LLMSVS ist ein OWASP Projekt mit dem Ziel, einen offenen Sicherheitsstandard für Systeme zu schaffen, die künstliche Intelligenz und Large Language Models einsetzen. Er bietet eine Basis für das Design, den Bau und das Testen robuster LLM Applikationen und adressiert unter anderem Architektur, Model Lifecycle, Training, Betrieb und Integration, Storage sowie Monitoring.
Die Anforderungen des LLMSVS wurden mit den folgenden Zielsetzungen entwickelt:
Der genaue Umfang wird je nach Kunde und Applikation im Scoping festgelegt. Dazu gehören zum Beispiel die Chat oder Assistenz Funktion, RAG Datenquellen, Rollen und Berechtigungen, Guardrails, Tool und API Zugriffe, gewünschte Testtiefe sowie Testszenarien.
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.
