Pentest

Die österreichische Sicherheits-ÖNORM A 7700 für Webapplikationen

Leave a Comment

Manche Normen können überraschen, sogar positiv. Die österreichische ÖNORM A7700 stellt Sicherheitsanforderungen an Webapplikationen. Obwohl die A7700 in Deutschland weitestgehend unbekannt ist, lohnt es sich dennoch einen Blick auf die Norm der Republik Österreich zu werfen.

Die Vorversion der ÖNORM A7700 wurde als ONR 17700 zwischen 2004 und 2005 entwickelt. Seit 2008 ist sie als ÖNORM der definierte Stand der Technik für die Beschaffung und Entwicklung von sicheren Webapplikationen in Österreich. In 2019 wurde die Norm grundlegend überarbeitet und liegt unterteilt in 4 Teilen vor:

  • ÖNORM A 7700-1: Webapplikationen – Begriffe
  • ÖNORM A 7700-2: Webapplikationen – Anforderungen durch Datenschutz
  • ÖNORM A 7700-3: Webapplikationen – Sicherheitstechnische Anforderungen
  • ÖNORM A 7700-4: Webapplikationen – Anforderungen an den sicheren Betrieb

Den ersten Teil mit Begriffsdefinitionen kann sich der geneigte Leser direkt ersparen und der zweite Teil ist eher den typischen Datenschutzthemen zuzuordnen. Teil 3 und Teil 4 sind spannender.

ÖNORM A 7700-3: Webapplikationen Sicherheitstechnische Anforderungen

Die A 7700-3 ist erfrischend technisch konkret, soweit eine Norm das sein kann:

Die Sicherheitsanforderungen an Webapplikationen werden in der Regel aus einer generischen und aus einer technologieunabhängigen Sicht behandelt. Die einzelnen Anforderungen werden daher in dieser ÖNORM nicht auf spezifische technologische Lösungen abgebildet, wodurch ein entsprechend hoher Wissensstand beim Benutzer dieser ÖNORM vorausgesetzt wird. Ergänzende Informationen können aus der einschlägigen Fachliteratur bezogen werden. Als einschlägige Fachliteratur kann z. B. der OWASP Testing Guide in der jeweils aktuellen

ÖNORM A 7700-3:2019-10, Seite 5

Dabei werden in der A7700-3 folgende Themen behandelt:

  • Architektur der Webapplikation
  • Datenspeicherung und Datentransport
  • Konfigurationsdaten
  • Authentifizierung, Autorisierung und Sitzungen
  • Session-Riding
  • Click-Jacking
  • Behandlung von Eingaben
  • Datenverarbeitung (u.a. Injections)
  • Behandlung von Datenausgaben
  • Behandlung von Dateien
  • System- und Fehlermeldungen
  • Kryptographie
  • Protokollierung
  • Replay-Angriffe
  • Dokumentation

ÖNORM A 7700-4: Webapplikationen Anforderungen an den sicheren Betrieb

Die A7700-4 stellt Anforderungen an den Betrieb einer sicheren Webapplikation, wobei direkt am Anfang der Norm ein ISMS gefordert wird. Das ist relativ generisch und zwar auch wahr, wenn auch weniger hilfreich. Die nachfolgenden Punkte können eher als eine grundlegende Checkliste dienen:

  • Informationssicherheitsmanagementsystem
  • Einhaltung des Minimalprinzips
  • Verwendete Softwarekomponenten
  • Konfiguration der Komponenten
  • Behandlung von Daten (u.a. Verschlüsselung)
  • Konfiguration von HTTP-Header
  • Protokollierung

Penetrationstests beim MPA Content Security Program

Leave a Comment

Das Content Security Program der Motion Picture Association (MPA) legt in ihren Content Security Best Practices Common Guidelines (Version 4.10 vom 8. Februar 2022) Sicherheitsanforderungen in drei Bereichen fest:

  • Management System
  • Physical Security
  • Digital Security

In den Anforderungen an das Management System wird in der Nummer MS-2.1 in der Kategorie Risk Management die Durchführung von Schwachstellen-Scans und externen Penetrationstests durchgeführt. Hierbei wird auf die Anfordeurngen DS-1.8 und DS-1.9 verwiesen.

In der Anforderung DS-1.9 (Firewall / WAN / Perimeter Security) wird die Durchführung jährlicher Penetrationstests aller externen IP-Adressen und Systemen verlangt. Die DS-1.8 verlangt zusätzlich die monatliche Durchführung von Schwachstellen-Scans.

Weiterhin findet man zusätzlich die Anforderung zur Durchführung von Webanwendungs-Penetrationstests (DS-15.9, Client Portal). Hier werden etwas detailreichere Anforderungen gestellt:

  • Der Pentest soll auch eventuelle APIs beinhalten.
  • Der Test soll sowohl mit als auch ohne valide Zugangsdaten durchgeführt werden.
  • Die typischen Guidlines wie z.B. die Veröffentlichungen von OWASP sollen beachtet werden, sodass auch XSS, SQL Injections, und CSRF gefunden werden kann.

Es wird dabei allgemein empfohlen, dass die Penetrationstests von einer unabhängigen dritten Stelle durchgeführt werden.

Common Vulnerability Scoring System (CVSS) – ein (subjektiv) einheitliches Bewertungsschema für Sicherheitslücken?

Leave a Comment

Es kann sehr fesselnd sein, in der Rolle eines Angreifers in fremde IT-Systeme einzudringen. Als Penetrationstester sollte dabei jedoch nie das eigentliche Ziel aus den Augen verloren werden: die Identifikation aller Einstiegspunkte bzw. Sicherheitslücken in einem Zielsystem. Die Liste von Schwachstellen kann sehr lang und unübersichtlich werden. Um einem Auftraggeber aber mitzuteilen, welche Schwachstellen zuerst adressiert bzw. behoben werden sollten, müssen die ermittelten Schwachstellen nach ihrem Risiko geordnet werden.

Grundsätzlich kann das Risiko einer Schwachstelle über zwei verschiedene Arten dargestellt werden. So kann entweder ein konkreter Zahlenwert ermittelt (bspw. 1.034,99 Euro) werden oder eine Aussage über die Schwere des Risikos getroffen (wie gering, mittel, hoch) werden. Der konkrete Zahlenwert ist das Ergebnis einer quantitativen Risikoanalyse. Diese eignet sich beispielsweise zur Bestimmung des Risikos eines Festplattenausfalls, da Festplatten einen konkreten Preis und eine durch­schnitt­liche Lebensdauer haben. Im Gegensatz dazu liegen einem Pentester bei Schwachstellen von IT-Systemen normalerweise nicht genug Informationen dieser Art vor, sodass diese Form der Risikoanalyse nicht empfehlenswert ist. Stattdessen kann aber eine qualitative Risikoanalyse vorgenommen werden, da immer Aussagen über die Eintrittswahrscheinlichkeit und das mögliche Schadensausmaß einer Schwachstelle getroffen und somit die Schwere des Risikos abgeschätzt werden kann. Wie bei einer Schätzung üblich, werden verschiedene Pentester zu unterschiedlichen Risikobewertungen gelangen, da ihre Wahrnehmung und Erfahrungen uneinheitlich sind – selbst, wenn sie sich auf dasselbe Bewertungsschema beziehen.

Jedoch benötigen gerade regulatorische Stellen wie das Regierungspräsidium Darmstadt ein einheitliches System, da sie konkrete Anforderungen und Maßnahmen definieren müssen. Infolgedessen fordern sie von Pentestern eine Risikobewertung nach dem Common Vulnerability Scoring System (CVSS) durchzuführen. Bei diesem handelt es sich um ein metrisches Bewertungsschema, welches einer Schwachstelle eine Punktzahl bzw. einen Score zwischen 0 und 10 zuweist – je höher der Score desto gravierender ist das Risiko einer Schwachstelle. Auch wenn das Risiko einer Schwachstelle beim CVSS anhand einer Vielzahl von Parametern berechnet wird (s. https://www.first.org/cvss/calculator/3.1), liegen Kenngrößen wie die Auswirkung einer erfolgreich ausgenutzten Schwachstelle auf die Integrität im Ermessen der Pentester. Somit können Risikoangaben wie der CVSS Score einem Auftraggeber zwar als Richtwert dienen, jedoch sollte intern immer eine eigene Schwachstellenbewertung vorgenommen werden.

Die Aussagekraft von Vulnerability-Scanner vs. Penetrationstests

1 Comment

It is worth mentioning that automated methods are much faster in performing the security analysis.

Alavi, Bessler und Massoth 2018

Die vorherige Anmerkung von Alavi, Bessler und Massoth schildert den ausschlaggebenden Beweggrund hinter den Einsatz von Vulnerability-Scanner bei der Durchführung von Penetrationstests: Zwar haben beide als Hauptaufgabe die Identifikation von Schwachstellen in IT-Systemen, jedoch geschieht dies bei Vulnerability-Scannern rein automatisiert, welche lediglich von einem Anwender konfiguriert und gestartet werden müssen. Wegen den geringeren personellen Ressourcen sollten Kunden beim Einkauf eines Pentests Acht geben, nicht mit einem aufbereiteten Vulnerability-Scan-Report „abgespeist“ zu werden.

Inwieweit die Ergebnisse eines Vulnerability-Scanners mit einem Penetrationstest verglichen werden können, haben zwei BACPPler – Saed Alavi und Niklas Bessler – in ihrem Paper „A Comparative Evaluation of Automated Vulnerability Scans Versus Manual Penetration Tests on False-negative Errors“ gezeigt. Für ihre Analyse haben sie sich die Frage gestellt, wie viele Schwachstellen von einem Vulnerability-Scanner und einem Penetrationstester nicht als solche identifiziert werden, obwohl die Lücken vorhanden sind? Im Wissenschaftsjargon ist hier die Rede von der False-Negative-Rate (FNR). Dazu haben sie eine mit Schwachstellen übersäte IT-Infrastruktur aufgebaut und diese sowohl einem Penetrationstest als auch einem Vulnscan unterzogen. Wie – zugegebenermaßen – zu erwarten war, kamen sie zu dem Schluss, dass Penetrationstests zwar Vulnerablity-Scans beinhalten können, aber mit ihren manuellen Prüfphasen weit darüber hinaus gehen:

„Most importantly, we have seen a remarkable higher false-negative rate in the vulnerability scan, which suggests that automated methods cannot replace manual penetration testing. However, the combination of both methods is a conceivable approach.“

Alavi, Bessler und Massoth 2018

Dennoch ist der Einsatz von Vulnerability-Scannern nicht obsolet: Auch wenn die Fülle an Informationen eines Vulnerability-Scanners erst überblickt, sortiert und ausgewertet werden muss – je nach Scanner kann dies leider selbst einen Fachmann benötigen -, sind sie ein Werkzeug um die eigene IT zu härten.

Best of Pentest-Akquise

Leave a Comment

Vertrieb, Sales, Akquise.. alles ein hartes Geschäft. Manchmal hat man Glück, meistens hat man Pech. Normales Business. Aber manchmal.. fehlen einem die Worte – Reaktion am Telefon (sinngemäß wiedergegeben):

„Also von Pentests halte ich nichts. Die kosten nur Geld. Dann werden irgendwelche Sicherheitslücken gefunden. Und dann muss man noch mehr Geld ausgeben, um die Lücken zu beheben. Das ist einfach zu teuer.“

TOP!

Blackbox-Pentests sind der falsche Ansatz

Leave a Comment

Whitebox-, Greybox- oder Blackbox-Pentests? Offen gesagt, sind meiner Meinung nach Blackbox-Pentests der falsche Ansatz. Während bei einem Whitebox- oder Greybox-Pentest dem Penetration Tester alle notwendigen oder zumindest alle hilfreichen Informationen zum Ziel vorliegen, liegen bei einem Blackbox-Pentest dem Penetration Tester gar keine Informationen vor. Er hat sozusagen die gleiche Sicht, wie es ein böswilliger externer Angreifer hätte. Die Aussagekraft eines Blackbox-Pentests ist somit klar: Wie viel Informationen kann ein Angreifer über ein Ziel sammeln, wie weit kann er vorgehen, wie weit kann er in ein Unternehmen oder in ein IT-System eindringen?

Sorry, aber das ist aus Kundensicht Geldverschwendung.

Erstens stimmt das mit der Aussagekraft nur bedingt: Während ein böswilliger Angreifer überhaupt keine Probleme hätte, eine spezifische Zielperson per Xing/LinkedIn ausfindig zu machen und ihr z.B. gezielten Schadcode am Virenscanner vorbei unterschiebt oder es ganz einfach mit Social Engineering versucht, wird diese Herangehensweise in den meisten Fällen – und aus guten Gründen – bei einem professionellen Pentest ausgeschlossen (der Betriebsfrieden lässt grüßen).

Zweitens kann es sein, dass ein Penetration Tester bei einem Blackbox-Pentest gar nicht in der Lage ist, alle notwendigen Prüfungen zu machen – entweder scheitert er an einer Loginmaske und kann gar keine Schwachstellen in der Anwendung dahinter sehen – oder trotz gutem Information Gathering werden gar nicht alle öffentlich erreichbaren Systeme identifiziert.

Drittens verbringt der Penetration Tester am Ende auch Zeit damit Sachen herauszufinden, die man ihm hätte auch einfach mitteilen können. Der Aufwand von Blackbox-Pentests ist sehr schwer zu kalkulieren und sind im Zweifel immer mehr Aufwand.

Insgesamt ist das Verhältnis zwischen Aussagekraft und Aufwand/Kosten nicht optimal. Ich rate stets davon ab.

Artikel in der iX 10/2016: Momentaufnahme – Was Penetrationstests erreichen können

Leave a Comment

In der Oktober-Ausgabe der iX aus dem Heise-Verlag ist mein erster Artikel im Print-Bereich erschienen:

Momentaufnahme – Was Penetrationstests erreichen können

Ein Penetrationstest kann zwar typische Schwachstellen im Firmennetz aufdecken, ist aber kein Allheilmittel. Welche Erkenntnisse diese Einbruchssimulationen wirklich bringen, hängt von verschiedenen Randbedingungen ab…

https://www.heise.de/select/ix/2016/10/1475741089664718

Übersicht Penetrationstest-Dienstleistungsunternehmen in Deutschland

Leave a Comment

Aus einer Marktanalyse heraus hatte ich eine Liste deutscher Dienstleistungsunternehmen für Penetrationstests bzw. IT-Sicherheitsanalysen zusammengestellt. Diese Liste der Pentest-Dienstleister ist das Ergebnis von persönlicher Erfahrung mit Anbietern, der geschalteten Anzeigen durch Google AdWords sowie normale Google-Suchergebnisse. Falls ein Unternehmen fehlt, das die unten genannten Kriterien erfüllt, nehme ich es gerne zusätzlich auf. An dieser Stelle möchte ich erwähnen, dass ich selbst Gesellschafter eines dieser Unternehmen bin, der binsec GmbH aus Frankfurt am Main. Die Liste in alphabetischer Reihenfolge ist:

  • binsec GmbH aus Frankfurt am Main
  • cirosec GmbH aus Heilbronn
  • it.sec GmbH & Co. KG aus Ulm
  • RedTeam Pentesting GmbH aus Aachen
  • Secorvo Security Consulting GmbH aus Karlsruhe
  • secuvera GmbH aus Gäufelden
  • SRC Security Research & Consulting GmbH aus Bonn
  • SySS GmbH aus Tübingen
  • usd AG aus Neu-Isenburg

Die Kriterien zur Auswahl waren:

  • Nur Unternehmen mit Stammsitz in Deutschland.
  • Nur Unternehmen, die speziell auf Informations- oder IT-Sicherheit spezialisiert sind.
  • Nur Unternehmen, mit einem expliziten Fokus auf Penetration Testing.
  • Keine Freelancer sowie keine Ein-Personen-GmbHs.

Aussagekraft und Grenzen von Penetrationstests

Leave a Comment

Vor kurzem wurde mir in einem Beratungsgespräch die Frage gestellt, ob man nach einem Penetrationstest eine Garantie bekommt, dass eine geprüfte Anwendung absolut sicher ist. Die Frage ist natürlich aus der Sicht eines Kunden verständlich. Wer je nach Aufwand vielleicht mehrere Tausend Euro für eine Sicherheitsanalyse ausgibt, erwartet zumindest unterschwellig, dass alle möglichen Schwachstellen identifiziert wurden und eine geprüfte Anwendung 100% sicher ist. Die unbequeme Wahrheit ist leider, dass das nicht der Fall sein kann.

Grundsätzlich gilt, dass nahezu alle durchgeführten Penetrationstests ein Kompromiss aus Testaufwand und Aussagekraft sind. Bei professionellen Pentest-Dienstleistern beinhaltet ein Test mindestens,

  • die Prüfung nach einer standardisierten Vorgehensweise, die sich an den Best Practices orientiert
  • die Verwendung eines Tool-Sets, um automatisiert auf typische Schwachstellen prüfen zu können
  • zusätzlich umfangreiche manuelle Prüfungen
  • den Einsatz von zertifizierten Penetrationstestern (eher OSCP & OSCE weniger CISSP / CEH & Co)
  • die Durchführung einer Qualitätssicherung
  • die Abgabe eines detaillierten Berichts

Sind die genannten Kriterien bei einem Test erfüllt, werden mit ziemlicher Sicherheit:

  • alle einfach zu entdeckenden Schwachstellen (low hanging fruits) gefunden
  • mindestens allen Angreifern auf dem Niveau Script Kiddy keine Chance mehr gelassen
  • mindestens alle unspezifischen automatisierten Angriffe die Grundlage entzogen
  • den Aufwand für einen Angreifer auf mindestens den Aufwand erhöht, den der Penetrationstester investiert hat
  • eine absolut aussagekräftige Richtung gezeigt, ob ein Zielsystem bzw. eine Zielanwendung grundsätzlich auf professionellem Security-Niveau aufgesetzt bzw. entwickelt wurde

Das ehrliche Zugeständnis, dass unter Umständen ein Angreifer mit einem deutlich höheren Aufwand dennoch eine Schwachstelle finden könnte, ist leider nicht verkaufsfördernd.

Ein höheres Prüfungsniveau, wie z.B. die Entwicklung oder gar den Aufkauf von Zero Day Exploits ist in den allermeisten Fällen leider nicht realistisch. Die Durchführung eines APTs (advanced persistent threat) auf NSA & Co Niveau ist sehr, sehr aufwendig und würde die Kosten eines Penetrationstests in extreme Höhe treiben. Für einen Kunden wäre das ein enorm schlechtes Preis-/Leistungsverhältnis und die finanziellen Ressourcen ließen sich mit Sicherheit sinnvoller in die eigene Sicherheit investieren.

Aber nehmen wir einmal ein, als Pentest-Dienstleister würde man eine 100%-Sicherheitsgarantie geben: Was würde passieren, wenn ein System dennoch kompromittiert werden würde? Wie soll nachgewiesen werden, dass der Penetrationstester etwas übersehen hat? Wie soll nachgewiesen werden, dass der Kunde das System seitdem nicht verändert hat? Wie soll nachgewiesen werden, dass der Kunde eventuell nicht ein Sicherheitsupdate übersehen hat? Wie wird mit dem Problem von Sicherheitslücken in eingesetzten Frameworks oder Bibliotheken umgegangen? Ein einziger Penetrationstest mit einer 100%-Sicherheitsgarantie und man hat als Dienstleister für alle Ewigkeiten unkalkulierbare Rechtsrisiken. Selbst wenn man das Risiko grob abschätzt und im Durchschnitt auf alle Kunden umlegt, würde es die Kosten eines Penetrationstests unverhältnismäßig in die Höhe treiben. Kein Kunde würde das bezahlen wollen.  Eine 100%-Sicherheitsgarantie ist leider unrealistisch.

Nichtsdestotrotz werden in den meisten Penetrationstests Sicherheitslücken oder -schwachstellen identifiziert, die das Sicherheitsniveau transparenter machen und Potential zur Verbesserung aufzeigen. In der Praxis sind Pentestberichte mit exakt 0 Findings sehr selten und deuten auf ein extrem hohes Sicherheitsniveau hin. Letztendlich ist für den Kunden wichtig, die genannten Grenzen, aber auch die aufgezeigten Vorteile eines Penetrationsteste zu kennen um die für ihn richtige Entscheidung treffen zu können: Pentest ja oder nein?

Was kostet ein Penetration Test?

Leave a Comment

Die Kosten eines Penetrationstests sind primär von zwei Faktoren abhängig: Vom Aufwand und vom Tagessatz.

1. Der zeitliche Aufwand eines Penetration Tests

Die Dauer eines Penetrationstests ist abhängig von der Größe und Komplexität einer Anwendung oder einer IT-Infrastruktur. Grundsätzlich gibt es keine pauschalen Schätzwerte und es kommt immer auf den Einzelfall an. Angebote ohne vorherige Aufwandschätzung halte ich für grundsätzlich nicht seriös und rate davor ab.

Die grobe Richtung sieht aber wie folgt aus: Bei einer kleinen Webanwendung, also eine zweistellige Anzahl von Seiten mit ein paar Formularen und Parametern liegt man inklusive der Vorbesprechung, dem eigentlich Pentest und der Berichtserstellung bei etwa einem Tag. Der Aufwand wächst danach bei Webanwendungen weniger mit der Anzahl der Links, sondern eher mit einer steigenden Komplexität: Session Management, Rollen- und Benutzermanagement, AJAX usw. können schnell den notwendigen Aufwand erhöhen.

Den Aufwand eines IT-Infrastruktur-Penetrationstests pauschal zu beziffern ist noch schwieriger. Es hängt hier vom eigentlichen Ziel, der Anzahl der Hosts, der Anwendungen und Dienste ab. Manchmal macht es hier mehr Sinn, die eigentlichen Ziele des Tests zu konkretisieren und dann eine fixe Anzahl von Tagen dafür einzuplanen.

2. Der Tagessatz des Penetration Tester

Der Tagessatz im Penetration Testing ist auch hier von verschiedenen Faktoren abhängig: Zum Beispiel von der Erfahrung und Qualifikation vom Penetration Tester, von der dazugehörigen Unternehmensgröße, dem Unternehmensstandort, den Vertriebszielen usw.

Ist man auf der Suche nach einem qualifizierten Pentest-Freelancer landet man schnell bei Tagessätzen von 800€ und höher. Wobei alle Beispielpreise aus meinen Erfahrungen hier für Unternehmen netto wären. Beauftragt man ein Unternehmen mit ein paar Mitarbeitern mit einem Pentest liegt man anfänglich irgendwo bei 1.000€, man kann aber auch schnell 1.200€ bis 1.300€ pro Tag zahlen. Nach oben wie immer offen.