FAQ - Frequently Asked Questions

Ein Penetrationtest oder Pentest ist ein umfassender Sicherheitstest eines Systems (Server, Webanwendung, Netzwerk, Gebäude etc.). Das Besondere daran ist, dass ein Pentest keine theoretische Überprüfung darstellt sondern einem tatsächlichen Angriff ziemlich nahekommt. Allerdings mit dem kleinen aber feinen Unterschied, dass erbeutete Daten oder Zugänge nicht gegen das Unternehmen eingesetzt werden. Ein Penetrationtest ermöglicht auf diese Weise ein akkurates Bild der Effektivität der Sicherheit eines Systems, zeigt auf wo diese noch verbesserungswürdig ist und hilft dadurch dabei, die Systemsicherheit zu verbessern.

Bei einem Whitebox Penetrationtest bekommt der Tester umfangreiche Informationen über das zu testende System, beispielsweise Accounts in verschiedenen Berechtigungsstufen oder Zugriff auf den Sourcecode einer Webanwendung. Der Vorteil dieser Art von Test ist, dass der Tester nicht bei 0 anfangen muss, sondern man beispielsweise gezielt testen kann was möglich wäre wenn sich Angreifer erst einmal einen Zugriff auf das System verschafft hat. Bei einem Blackbox Test erhält der Tester dagegen sehr viel weniger Informationen, in der Regel lediglich die Adressen (IP bzw. URL) der zu testenden Systeme. Der Vorteil dieses Tests ist, dass der Tester genauso vorgeht wie es auch ein Angreifer machen würde, ohne den Vorteil zusätzlichen Wissens. Ein Blackbox Test zeichnet deshalb typischerweise ein akkurateres Bild, ist dafür aber auch aufwendiger und dauert in der Regel länger.

Bei einem Greybox Pentest verschwimmen die Grenzen zwischen Blackbox und Whitebox. So bekommt der Pentester beispielsweise mehr Informationen zur Verfügung gestellt als bei einem Blackbox Test (z.B. einen User Account zum Testen) aber nicht so viele Informationen wie bei einem Whitebox Test (z.B. keine Informationen über verwendete Abwehrmechanismen wie IDS/IPS).

Im Leistungsschein werden die Parameter des Penetrationtest festgelegt. Beispielsweise ob der Penetrationtest eher passiv und vorsichtig durchgeführt werden soll oder mit hoher Aggressivität. Zudem können Sie sich hier für bestimmte Zusatzleistungen (z.B. Social Engineering Angriffe) entscheiden. Außerdem werden im Leistungsschein die zu testenden Systeme festgelegt und festgehalten ob es irgendwelche Einschränkungen gibt (z.B. rechtlicher Art oder Tests nur innerhalb bestimmter Uhrzeiten).

Ein Proof of Concept ist ein Beweis, dass eine Schwachstelle existiert. Jede in unseren Reports dokumentierte Schwachstelle verfügt über einen Proof of Concept. Dabei zeigen wir mittels Screenshots welche Schritte wir unternommen haben und zu welchem Ergebnis wir dabei gekommen sind (z.B. wir haben mit Tool A diese Schwachstelle identifiziert, dann mit Tool B die Schwachstelle ausgenutzt und konnten dann auf die Daten von Kunde X zugreifen). Auf diese Weise können Sie sicher sein, dass eine Schwachstelle tatsächlich ein Problem darstellt und nicht nur in der Theorie existiert. Zudem helfen die einzelnen Schritte Ihren Entwicklern oder IT-Dienstleistern dabei das Problem gegebenenfalls nachzuvollziehen.

OSINT steht für Open Source Intelligence. Dabei untersuchen wir öffentlich verfügbare Informationen aus diversen Quellen auf mögliche Angriffsvektoren. Wer beispielsweise öfters Bilder aus dem Home-Office bei Instagram postet vergisst dabei vielleicht, dass in einigen Fällen Dinge auf dem Bildschirm zu sehen sind (Emailadressen, Post Its mit Passwörter, verwendete Software), die besser nicht sichtbar wären. Im Rahmen von OSINT Maßnahmen untersuchen wir diverse Quellen wie soziale Netzwerke, Karrierenetzwerke, Unternehmensdatenbanken, Zeitungsberichte, Domaininformationen etc. auf mögliche Angriffsvektoren gegenüber Ihrem Unternehmen.

Im Scope wird definiert welche Systeme im Rahmen des Penetrationtest getestet werden. Beispielsweise können Sie sich entschließen bestimmte Systeme vom Penetrationtest auszuschließen. Etwa weil diese bekannte Schwachstellen aufweisen und hier keine Zeit vergeudet werden soll.

Für die Tests von Webanwendungen und Servern verwenden wir in der Regel lediglich Software. Im Bereich WLAN, Physische Penetrationtest und Social Engineering kann aber auch spezielle Hardware zum Einsatz kommen.

Ja, falls Sie das wünschen können wir im Rahmen eines Penetrationtest auch Social Engineering Angriffe verwenden. Zusätzlich haben Sie auch unabhängig von einem Penetrationtest die Möglichkeit bei uns verschiedene Sensibilisierungsmaßnahmen für Ihre Mitarbeiter zu buchen, etwa simulierte Phishing Kampagnen.

Ein Penetrationtest ist dann sinnvoll, wenn Sie bereits erste IT-Sicherheitsmaßnahmen implementiert haben und sich nun von deren Wirksamkeit überzeugen möchten. Haben Sie noch keine Anstrengungen unternommen in Bezug auf IT-Sicherheit unternommen, ist ein Penetrationtest in der Regel nicht zielführen. In diesem Fall können wir Sie aber gerne dabei beraten welche Maßnahmen Sie am besten durchführen sollten.

Das hängt ganz davon ab für welche Art Penetrationtest Sie sich entschieden haben. Bei einem eher passiven Test kann an dieser Stelle einfach die Schwachstelle dokumentiert und mit dem Test fortgefahren werden. Bei einem aggressiveren Test können wir beispielsweise versuchen uns im Anschluss höhere Rechte zu verschaffen oder uns weiter im Netzwerk auszubreiten.

Grundsätzlich kann ein Penetrationtest in vier Phasen unterteilt werden: In der Reconnaissance Phase sammeln wir so viele Informationen wie möglich, wir schauen uns etwa an welche Software verwendet wird, wie die Hierarchie der Firma aussieht und noch einiges mehr. In der Enumerations Phase wird das Sammeln von Informationen dann konkretisiert: wir schauen uns an wo Ihr System Schwachstellen aufweist. Das können technische Schwachstellen (wie der Einsatz veralteter Software) oder auch menschliche Schwachstellen sein (Angestellte die für Phishing Mails empfänglich sind). In der Exploitation Phase nutzen wir die identifizierten Schwachstellen dann aus, beispielsweise indem wir uns Zugriff auf das Netzwerk verschaffen. Die letzte Phase stellt dann die Dokumentation der Ergebnisse dar, nach Abschluss des Pentests erhalten Sie von uns einen Report in dem alle Schwachstellen nach ihrer Kritikalität geordnet aufgeführt sind. Zudem geben wir Empfehlungen zu nötigen Gegenmaßnahmen ab um Ihnen die Beseitigung der Schwachstelle zu erleichtern.

Viele der Tools die wir verwenden sind in der Linux Distribution Kali enthalten, etwa der Portscanner Nmap oder das Exploit Framework Metasploit. Zusätzlich kommen auch kostenpflichtige Tools wie Burp Suite Pro zum Einsatz und wenn der Zweck es erfordert, programmieren wir auch eigene Software, in der Regel mit Python. Vor allem im Rahmen von OSINT arbeiten wir zudem auch mit diversen Webservices.

Das hängt ganz davon ab was getestet werden soll und welche Tiefe der Penetrationtest aufweisen soll. Eine oberflächliche Überprüfung einer einzigen Webseite ist in ein oder zwei Tagen durchaus machbar. Für ein komplexes Firmennetzwerk können dagegen auch mehrere Wochen schon knapp bemessen sein. Sprechen Sie uns am besten an und wir schauen welcher Zeitraum für Ihre Bedürfnisse angemessen ist.

Wenn Sie möchten können wir Ihre Systeme auch auf Denial of Service Schwachstellen testen. Die meisten Kunden entschließen sich allerdings gegen diese Art von Tests, in diesem Fall dokumentieren wir mögliche DoS Schwachstellen lediglich ohne sie aktiv auszunutzen.

Ja, wir testen gerne auch Anwendungen die Sie bei Cloudanbietern wie Amazon AWS, Microsoft Azure oder Google Cloud gehostet haben.

Ja, auch das Testen von APIs gehört zu unserem Repertoire. Insbesondere dann, wenn Ihre Webseite eine API zur Verfügung stellt, macht es durchaus auch Sinn diese in den Penetrationtest einzubeziehen.

Ein Schwachstellenscan ist eine automatische Analyse. Dabei werden häufig viele False Positives gefunden, komplexere Probleme bleiben dagegen häufig verborgen. Aus diesem Grund kann ein Schwachstellenscan zwar Teil eines Penetrationtests sein (um sich einen ersten Überblick über mögliche Probleme zu verschaffen) sollte aber nicht als Ersatz genutzt werden, da er sehr viel oberflächlicher ist.

Bei einem Penetrationtest denkt man oft instinktiv an das Hacken von Webseiten oder Netzwerken. Doch wozu das alles wenn jeder einfach in das Büro spazieren kann, sich einen Ordner mit sensiblen Daten greift und wieder verschwindet? Bei einem physischen Penetrationtest überprüfen wir deshalb wie es um die Sicherheit Ihrer Firmengebäude bestellt ist: Welche Arten von Zugangskontrollen gibt es, welche Schwächen weisen diese auf, sind Räume von besonderem Interesse (z.B. Serverraum) zusätzlich gesichert etc.

Bei einem Web Penetrationtest testen wir eine Webanwendung auf ihre Sicherheit. Dabei spielt es keine Rolle ob es sich um eine selbstprogrammierte Webseite handelt oder ein Content Management System (CMS). Beide Varianten weisen charakteristische Schwächen auf.

Eine Perimeteranalyse ist eine Überprüfung des Sicherheitsstatus eines Netzwerks: funktioniert die Firewall zuverlässig? Welche Ports sind am Server offen? Etc. Im Gegensatz zu einem Penetrationtest ist die Perimeteranalyse also eher passiver angelegt, dafür aber auch weniger zeitintensiv.

Unter Phishing versteht man das Versenden bösartiger Emails mit dem Ziel Zugangsdaten wie Usernamen und Passwörter zu erbeuten oder das Opfer zu einer Aktion wie einem Download zu bewegen. Phishing stellt einen häufigen ersten Angriff dar, mit dem sich ein Angreifer eine Basis für sein weiteres Vorgehen schaffen kann.

Social Engineering ist das Hacken von Menschen. Das klassische Beispiel ist ein Angreifer der sich als Mitarbeiter der IT-Abteilung ausgibt und nach den Zugangsdaten für den Account des jeweiligen Mitarbeiters fragt, weil er dort etwas zurücksetzen/updaten/neu aufsetzen muss. Wenn Sie möchten verwenden wir auch bei unseren Penetrationtest Social Engineering Methoden.

Im Rahmen des bayerischen Digitalbonus sind Maßnahmen zur Verbesserung der IT-Sicherheit mit bis zu 10.000 Euro förderfähig.

Ein Penetrationtest ist zwar nicht ganz billig, allerdings relativieren sich diese Kosten schnell, wenn man sie mit dem möglichen Schaden eines Hackerangriffs vergleicht. Bei B2C Unternehmen dauert es oft Monate, teilweise sogar Jahre um die Reputation wiederherzustellen, die verloren geht, wenn Hacker Kundendaten erbeuten. Fragen Sie sich selbst: würden Sie noch guten Gewissens bei einem Onlineshop bestellen der dafür verantwortlich war, dass Ihre Kreditkarteninformationen gestohlen wurden? Bei B2B Unternehmen bestehen die möglichen Schäden weniger im Verlust von Reputation, sondern eher im Verlust geschäftsrelevanter Daten. Stellen Sie sich vor jemand erbeutet Kundendaten oder Informationen zu Ihren neuesten Technischen Entwicklungen. Was sind diese Daten Wert? Der potenzielle Schaden geht hier schnell in die Millionen.

Das lässt sich nicht pauschal beantworten. Grundsätzlich hängen die Kosten eines Pentests aber davon ab wie lange dieser dauert und welchen Umfang (passiver Scan vs. Tiefgehende Untersuchung eines Systems) dieser hat. Sprechen Sie uns doch gerne an und wir erstellen unverbindlich ein individuelles Angebot für sie.

Sie können im Leistungsschein auswählen wie aggressiv der Pentest ablaufen soll. Wenn Sie sich etwa für eine passive Überprüfung entscheiden, ist die Stabilität Ihres Systems in der Regel nicht beeinträchtigt. Wenn Sie dagegen auch auf Denial of Service Schwachstellen testen wollen, kann eine Beeinträchtigung des Systems durchaus vorkommen.

Wenn Sie möchten können Sie uns im Rahmen eines Whitebox Tests auch den Sourcecode einer Anwendung zur Verfügung stellen. Dies ist allerdings kein Muss.

Definitiv. Aber auch wenn Sie sich gegen einen Pentest entscheiden sollten Sie regemäßig Backups Ihrer relevanten Daten anfertigen und diese auch auf Ihre Funktionalität testen.

Alle Schwachstellen zu finden ist vermutlich nicht möglich bzw. selbst wenn ist dieser Zustand dann nur von kurzer Dauer da die meiste Software regelmäßig geupdatet wird, wodurch zwar ältere Schwachstellen beseitigt werden, aber auch immer die Möglichkeit besteht, dass neue geschaffen werden.

Eindeutig ja. Es ist sogar so, dass ein Pentest wenig Sinn macht, wenn noch keinerlei Sicherheitsmechanismen implementiert sind. Falls Sie also noch keine Firewall, kein Intrusion Detection System o.ä. haben, dann macht ein Pentest noch nicht viel Sinn. Wenn Sie allerdings bereits Maßnahmen umgesetzt haben, dann ist ein Pentest sinnvoll um zu testen wie wirksam diese sind und wo vielleicht noch Lücken zu finden sind bzw. welches Verbesserungspotenzial es noch gibt.

Wenn Sie bereits wissen, dass eines Ihrer Systeme verwundbar ist (etwa ältere Software in Produktionsumgebungen die nur auf veralteten Betriebssystemen läuft), können Sie diese Systeme in der Scope Definition explizit ausschließen. Das hat den Vorteil, dass wir unsere Zeit und Ressourcen nicht dafür verwenden Ihnen am Ende etwas mitzuteilen, dass Sie bereits wissen.

Zum einen weil externe Pentester sich tagtäglich mit IT-Sicherheit beschäftigen. Ein Softwareentwickler hat dagegen im Rahmen seines Studiums gewisse Grundlagen der IT-Sicherheit gelernt, wenn er diese allerdings nicht täglich anwendet und sich über neue Angriffsmethoden auf dem Laufenden hält, ist dieses Wissen bald veraltet. Zum anderen besteht bei internen Tests auch ein gewisses Risiko, dass unerfreuliche Ergebnisse unter den Teppich gekehrt werden, weil niemand dumm dastehen möchte. Wenn ein Systemadministrator etwa die Wirksamkeit der Firewall testet und dabei feststellt, dass diese diverse Sicherheitslücken aufweist, wird er vermutlich nicht unbedingt zu seinem Chef gehen und ihm mitteilen, was er verbockt hat sondern eher die Einstellungen auf eigene Faust ändern. Bei einem externen Test besteht dagegen eine deutlich größere Transparenz, da der Tester alle gefundenen Schwachstellen auch melden kann.

Ein Pentest ermöglicht Ihnen eine Sicht auf Ihre Systeme und Sicherheitsmaßnahmen aus der Sicht eines Angreifers. Auf diese Weise lässt sich feststellen wo noch Sicherheitslücken existieren und welche Auswirkungen diese potenziell haben könnten.

Falls Sie sich für einen Whitebox Test entschieden haben, benötigen wie mindestens zwei Accounts um die Anwendung zu testen. Zudem können Sie uns gerne auch noch weitere Informationen bereitstellen, je nachdem wie umfangreich wir Ihre Systeme testen sollen.

Wenn wir gravierende Schwachstellen finden, informieren wir Sie sofort darüber. Unabhängig von möglicherweise vereinbarten Zwischenterminen. Wenn wir Anzeichen eines echten Angreifers in Ihrem System finden, informieren wir Sie ebenfalls darüber, in diesem Fall ist eventuell eine zusätzliche forensische Analyse notwendig um herauszufinden, was der Angreifer in Ihrem System gemacht hat und ob er möglicherweise immer noch einen Zugang hat. Wenn im Rahmen des Penetrationtest eines ihrer Systeme in seiner Funktionalität beeinträchtigt wird, müssen Sie es gegebenenfalls mittels Ihrer Backups wieder neu aufsetzen.

Selbstverständlich verwenden wir etwaige erbeutete Daten (Kundendaten, Mitarbeiterinformationen, Passwörter etc.) nicht um Ihnen zu schaden, sondern lediglich im Rahmen des Reports als Proof of Concept um deutlich zu machen, welche Auswirkung eine Schwachstelle hat. Mit Abschluss des Pentests werden alle Daten gelöscht.

Zunächst sollten Sie Backups anlegen und auch testen ob diese funktioniere d.h. ob sich alle relevanten Daten wiederherstellen lassen. Selbstverständlich sollte das sowieso regelmäßig erledigt werden, unabhängig davon ob ein Pentest ansteht. Da bei einem Pentest aber ein gewisses Risiko besteht, dass Daten oder Systeme beschädigt werden, sollte Ihr Backup zum Zeitpunkt des Pentests möglichst aktuell sein. Zudem sollten Sie Ihren Hostinganbieter darüber informieren, dass Sie einen Pentest durchführen lassen.

Das hängt ganz von unserer aktuellen Auftragslage ab. Falls Sie regelmäßige Pentests benötigen (beispielsweise jedes Jahr) können Sie diese natürlich auf einen bestimmten Zeitraum festlegen lassen.

Auf unserer Webseite finden Sie eine kleine Auswahl unserer Kunden. Beachten Sie allerdings, dass diese Liste nicht vollständig ist, da es viele Kunden vorziehen das Thema IT-Sicherheit diskret zu behandeln.

Das hängt ganz von Ihnen ab. Wenn Sie sich für einen Blackbox Test entscheiden, benötigen wir lediglich die URL bzw. IP-Adresse der zu testenden Webseiten bzw. Server. Im Falle eines Whitebox Tests sind die Grenzen nach oben dagegen offen, so können Sie sich beispielsweise auch dafür entscheiden uns den Sourcecode einer Anwendung zur Verfügung zu stellen, das ist aber natürlich kein Muss.

Um Sie bei der Beseitigung der Sicherheitslücken zu unterstützen, erhalten Sie von uns auch eine zusätzliche Excel Datei in der alle Schwachstellen in Kurzform aufgeführt sind. In diese Datei können Sie dann anschließend die Ansprechpartner eintragen die für die Behebung der Probleme zuständig sind, zudem kann eine Schwachstelle mittels Dropdown Menü als behoben markiert werden. Auf diese Weise haben Sie immer einen Überblick über den aktuellen Stand.

Wenn Sie möchten können wir Sie gerne mittels Zwischenberichten über den aktuellen Stand des Penetrationtest informieren. Beispielsweise können wir Ihnen nach der Hälfte der Zeit, oder bei längeren Tests jeweils an einem bestimmten Wochentag, mitteilen, was wir zum aktuellen Zeitpunkt gefunden haben. Falls wir wirklich kritische Schwachstellen finden (Root Zugriff auf Server, Einsicht in Kundendaten o.ä.) informieren wir Sie aber auch unabhängig von vereinbarten Zwischenterminen so schnell wie möglich, damit Sie die Schwachstelle schnellstmöglich schließen können.

Auf dieser Seite finden Sie einen Beispiel Report, den Sie gerne auch herunterladen können. Sollten Sie darüber hinaus noch Fragen haben oder einen alternativen Aufbau des Reports wünschen, kontaktieren Sie uns bitte.

Gerne können wir Ihnen die Ergebnisse des Penetrationtests in einem separaten Termin auch präsentieren. Sollten Sie dies wünschen, kreuzen Sie bitte im Leistungsschein „Präsentation der Ergebnisse in einem separaten Termin“ an.

Jeder Report enthält auch einen Anhang, in diesem führen wir vor allem auf, welche Tools und Webservices wir benutzt haben um den Penetrationtest durchzuführen. Auf diese Weise sind die Ergebnisse zu 100% transparent und können von Ihnen leicht nachvollzogen werden.

Mit welchen Mitarbeitern Sie den fertigen Report teilen hängt letztlich von Ihnen ab. Da die enthaltenen Informationen allerdings in höchstem Maße vertraulich sein können, würden wir empfehlen den Kreis der Leser klein zu halten. Mitarbeiter die Schwachstellen beseitigen sollen (etwa Softwareentwickler oder IT-Admins) benötigen natürlich Zugriff auf die Dokumentation der jeweiligen Schwachstelle, allerdings nicht auf die OSINT Informationen zu Geschäftsleitung. Wir würden deshalb empfehlen die entsprechenden Schwachstellen als Tickets aufzunehmen, sodass auch Ihre Behebung entsprechend dokumentiert werden kann.

Im Rahmen einer kurzen Zusammenfassung erfahren Sie zunächst wie es um den Gesamtzustand des untersuchten Systems bestellt ist. Anschließend folgen einige Formalien, etwa von welchen Mitarbeitern der Penetrationtest durchgeführt wurde, in welchem Zeitraum etc. Anschließend sind die Schwachstellen nach ihrer Kritikalität geordnet aufgeführt. Für jede Schwachstelle ist dabei angegeben wo sie sich befindet (z.B. eine bestimmte URL oder IP-Adresse), worin die Schwachstelle genau besteht, welche Maßnahmen getroffen werden sollten um das Risiko zu minimieren, sowie ein Proof of Concept der die Ausnutzung der Schwachstelle anhand von Screenshots zeigt. Im Anhang des Reports finden Sie zudem eine Übersicht aller verwendeter Tools und Webservices.

Unser Markenzeichen ist, dass wir die gefundenen Schwachstellen zügig in schriftliche Form bringen und Ihnen zukommen lassen, sodass Sie sich schnellstmöglich an die Behebung der Schwachstellen machen können. In der Regel dauert es etwa eine Woche bis der Report in der ersten Fassung vorliegt. Anschließend findet eine Qualitätskontrolle und gegebenenfalls eine Überarbeitung des Reports statt, dies nimmt in der Regel ein bis zwei Tage in Anspruch. Im Anschluss daran ist der Report freigegeben und Sie können damit arbeiten.

Das hängt natürlich von der Länge und vom Umfang des Penetrationtest ab, in der Regel erhalten Sie aber einen Report mit 30-80 Seiten (inklusive Anhang).

Jede gefundene Schwachstelle ist mit einer Tachonadel visualisiert, sodass Sie sofort sehen, ob sich das Risiko in einem mäßigen, mittleren oder kritischen Bereich befindet. Zudem geben wir eine Einschätzung darüber ab, wie aufwendig es ist die Schwachstelle auszunutzen und welche Aktionen einem Angreifer im Anschluss möglich wären.

Jede Schwachstelle die im Report aufgeführt wird, ist mit einem Proof of Concept versehen. In diesem zeigen wir mittels Screenshots was wir genau gemacht haben um die Schwachstelle auszunutzen und welche Aktionen uns dadurch möglich waren. Dadurch haben Sie den Beweis, dass diese Schwachstelle tatsächlich ein Sicherheitsproblem darstellt. Zudem kann der Proof of Concept von Ihren Entwicklern oder IT-Dienstleistern genutzt werden, um das Ergebnis zu reproduzieren.

Wenn sich Ihre Systeme noch in der Entwicklung befinden können wir Ihnen gerne von Anfang an dabei behilflich sein, IT-Sicherheitsanforderungen in den Entwicklungsprozess zu integrieren. Auf diese Weise entwickelte Systeme haben den Vorteil, dass sie meist deutlich robuster gegenüber Systemen mit nachträglich implementierten Sicherheitslösungen sind.

Die aktive Mitarbeit an der Beseitigung von Schwachstellen zählt momentan nicht zu unserem Leistungsportfolio. Gerne empfehlen wir Ihnen aber einen IT-Dienstleister der Sie bei der Beseitigung der Schwachstellen unterstützen kann.

Selbstverständlich können Sie auch die Entscheidung treffen einzelne Schwachstellen nicht zu beseitigen, sondern mit dem Risiko zu leben. Das kann etwa dann sinnvoll sein, wenn die Kosten die bei einer Beseitigung anfallen würden, den möglichen finanziellen Schaden deutlich übersteigen oder wenn das Risiko einer erfolgreichen Ausnutzung der Schwachstelle extrem gering ist. Um Sie bei dieser Entscheidung zu unterstützen, enthält unser Report Einschätzungen über die Kritikalität einer Schwachstelle.

Ein Retest ist ein erneuter Penetrationtest bei dem überprüft wird, wie wirksam die von Ihnen implementierten Lösungen für die im ersten Test gefundene Schwachstellen sind. Dadurch wird einerseits die Wirksamkeit der Lösung getestet und andererseits auch mögliche Probleme aufgedeckt die durch die Implementierung der Lösung neu entstanden sein könnten. Ein Retest hat dabei typischerweise einen etwas geringeren Umfang als ein regulärer Penetrationtest und sollte durchgeführt werden, sobald alle Schwachstellen die sich im ersten Penetrationtest ergeben haben beseitigt wurden.

Der Aufwand zur Absicherung von Schwachstellen kann sehr unterschiedlich ausfallen. Oftmals sind nur bestimmte Software Versionen von einer Schwachstelle betroffen, sodass schon ein Update auf eine aktuellere Version ausreicht, um die Sicherheitslücke zu schließen. Kleinere Schwachstellen auf Server Seite lassen sich zudem in vielen Fällen durch Änderungen in den Konfigurationsdateien beheben. Anders sieht es bei selbstprogrammierter Software aus. Wenn dort Fehler gemacht werden, ziehen sie sich oft durch die gesamte Anwendung und machen umfangreiche Änderungen notwendig. Ein klassisches Beispiel dafür ist die ungenügende Validierung von User Input durch die diverse Angriffe wie Cross Site Scripting oder SQL Injection möglich sind.

Ein Pentest sollte etwa einmal im Jahr stattfinden. Denn auch wenn Sie alles richtig machen (Schwachstellen aus vorherigen Pentests beseitigen, alle Systeme regelmäßig updaten, Mitarbeiter in Bezug auf Social Engineering schulen), gibt es Dinge die nicht in Ihrer Macht stehen, etwa neu entdeckte Sicherheitslücken und Angriffsvektoren.

Nein, für den IS-Webcheck muss dem Prüfer ein direkter Weg zur Anwendung freigegeben werden. Das Sicherheitsgateway wird nur im Rahmen des IS-Penetrationtests getestet. Das bedeutet NICHT dass das Sicherheitsgateway zwangsläufig komplett deaktiviert werden muss. Stattdessen können für den Zeitraum des Tests auch spezifische Freigaben für den Prüfer eingerichtet werden.

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

BSI Praxisleitfaden IS-Webcheck (Seite 2)

Nein, wenn keine Schnittstellen zum bzw. ins Internet vorhanden sind, kann bei i-KFZ Anwendungen auf den IS-Webcheck verzichtet werden. Dies muss schriftlich im Testbericht festgehalten werden.

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 36)

Inhalt des IS-Webchecks sind die OWASP Top 10 sowie die folgenden Module:

• Modul 1 (Schwachstellensuche)
  • Korrektes Verhalten der Webanwendung
  • Aktualität der Patchstände und der eingesetzten Softwareversionen
  • Verschlüsselung entsprechend der aktuellen Sicherheitsanforderungen
  • Unerwünschte Informationspreisgabe
  • Eingabe und Interaktionsmöglichkeiten
• Modul 2 (Schwachstellentest)
  • Eingabevalidierung
  • Session Handling
  • Zugriffskontrolle
  • Verschlüsselung
  • Fehlerhandling
  • Absicherung der beteiligten Datenbanken und Anwendungen
  • Absicherung von Dateiuploadmöglichkeiten und weiteren Interaktionsmöglichkeiten
  • Versteckte Parameter/Verzeichnisse
• Modul 3 (Logische Fehler/Konfigurationsfehler)
  • Fehler beim Aufbau oder Konfiguration z. B. des http-Protokolls
  • Mögliche Seiteneffekte
• Modul 4 (Exploits (optional))

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

Der IS-Webcheck wird in der Regel als Nicht invasiver Schwachstellenscan durchgeführt. Das bedeutet, erkannte Schwachstellen werden nicht aktiv ausgenutzt. Da bestimmte Schwachstellen rein passiv nicht erkannt werden können (z.B. Schwachstellen in Eingabeformularen), ist hier eine Ausnutzung nötig, die Schwachstelle soll durch den Prüfer aber auf möglichst harmlose Weise ausgenutzt werden. Bei einer XSS Schwachstelle kann dies beispielsweise durch das Anzeigen eines Alert Popups geschehen.

 Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

Der Ablauf eines IS-Webchecks sieht wie folgt aus:

• Einarbeitung des Prüfers
• Test des Prüfobjekts
• Anfangsgespräch
• Einrichtung der Arbeitsumgebung
• Praktische Prüfung
• Schwachstellensuche
• Schwachstellentest
• Logische Fehler/Konfigurationsfehler
• Exploits (Optional)
• Abschlussgespräch
• Abschlussbericht

Dieser Ablauf entspricht dem Praxis Leitfaden des BSI (BSI-LF-WEBCHECK)

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

Der IS-Webcheck wird grundsätzlich über das Internet (remote) durchgeführt. Eine Anwesenheit des Prüfers bei der Zulassungsbehörde oder beim Portalbetreiber ist daher nicht erforderlich. Ausnahme sind Anwendungen die nicht über das Internet erreichbar sind. In diesen Fällen kann der Test nach Absprache auch beim Auftraggeber vor Ort stattfinden.

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

Da die meisten Webanwendungen sehr umfangreich sind, kommen bei einem IS-Webcheck vor allem automatisierte Tools zum Einsatz. Stichprobenartig werden aber auch manuelle Tests durchgeführt, da bestimmte Schwachstellen ohne manuelle Interaktion nicht erkannt werden können. Zudem werden die durch die Tools gefundenen Schwachstellen manuell verifiziert um False Positives auszuschließen.

Quelle: BSI Praixleitenfaden IS-Webcheck (Seite 11)

Nein, im Rahmen eines IS-Webchecks werden standardmäßig keinerlei Social Engineering Maßnahmen wie Phishing oder Vishing durchgeführt.

Bei der Inmodis GmbH können Sie diverse Dienstleistungen aus dem Bereich Social Engineering aber separat dazu buchen.

Quelle: BSI Praxisleitfaden IS-Webcheck (Seite 12)

Nein, für den IS-Webcheck muss dem Prüfer ein direkter Weg zur Anwendung freigegeben werden. Das Sicherheitsgateway wird nur im Rahmen des IS-Penetrationtests getestet. Das bedeutet NICHT dass das Sicherheitsgateway zwangsläufig komplett deaktiviert werden muss. Stattdessen können für den Zeitraum des Tests auch spezifische Freigaben für den Prüfer eingerichtet werden.

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

BSI Praxisleitfaden IS-Webcheck (Seite 2)

Grundsätzlich können auch interne (d.h. zugriffsgeschützte) Bereiche einer Webanwendung im Rahmen des IS-Webchecks überprüft werden. Dies muss aber vorher zwischen Auftraggeber und Prüfer abgesprochen und vertraglich festgelegt werden. Zudem müssen dem Prüfen in diesem Fall Zugangsdaten (Passwort, Token, Key etc.) für den jeweiligen Bereich zur Verfügung gestellt werden.

Quelle: BSI Praxisleitfaden IS-Webcheck (Seite 22)

Neben den fachlichen Fähigkeiten sind auch die folgenden Soft Skills für eine erfolgreiche Zusammenarbeit von Bedeutung:

• Organisatorische Fähigkeiten
• Zielorientiertes Denken und Handeln
• Überzeugungsfähigkeit
• Schnelle Auffassungsgabe
• Gesundes Urteilsvermögen
• Analytische Fähigkeiten
• Teamfähigkeit
• Belastbarkeit
• Sachlichkeit insbesondere bei heiklen Sachverhalten

Da sich diese Fähigkeiten nur schwer im Vorfeld überprüfen lassen, können Referenzen von bisherigen Kunden als Anhaltspunkt verwendet werden, um zu sehen, ob der Prüfer bereits erfolgreich mit ähnlichen Unternehmen zusammengearbeitet hat.

Übrigens: auf unserer Startseite finden Sie einige unserer Referenzen. Auf Anfrage stellen wir Ihnen zudem gerne eine (anonymisierte!) umfassende Liste zusammen.

Quelle: BSI Praxisleitfaden IS-Webcheck (Seite 18)

Der IS-Webcheck wird in der Regel als Whitebox Test durchgeführt. Das bedeutet, dem Prüfer werden diverse Informationen (z.B. Dokumentation der Anwendung, Netzplan etc.) bereitgestellt. Dementsprechend wird weniger Zeit für eine Enumerierung der Anwendung benötigt, was den Test kosteneffizienter macht.

Dem Prüfer muss daher folgendes (sofern vorhanden) bereitgestellt werden:

• Zieladresse der Anwendung (URL und IP)
• Zugangsdaten (optional, für interne Tests)
• Dokumentation der Anwendung (zur Einarbeitung des Prüfers)
• Liste beteiligter IT-Systeme (Server, Datenbanken, andere Webanwendungen)
• Dokumentation von Kommunikationsverbindungen (z.B. als Netzplan)

Je nach Art der Anwendung können auch noch weitere Informationen bereitgestellt werden, dies kann individuell zwischen Auftraggeber und Prüfer vereinbart werden.

Quelle: BSI Praxisleitfaden IS-Webcheck (Seite 24-25)

Inhalt des IS-Webchecks sind die OWASP Top 10 sowie die folgenden Module:

• Modul 1 (Schwachstellensuche)
  • Korrektes Verhalten der Webanwendung
  • Aktualität der Patchstände und der eingesetzten Softwareversionen
  • Verschlüsselung entsprechend der aktuellen Sicherheitsanforderungen
  • Unerwünschte Informationspreisgabe
  • Eingabe und Interaktionsmöglichkeiten
• Modul 2 (Schwachstellentest)
  • Eingabevalidierung
  • Session Handling
  • Zugriffskontrolle
  • Verschlüsselung
  • Fehlerhandling
  • Absicherung der beteiligten Datenbanken und Anwendungen
  • Absicherung von Dateiuploadmöglichkeiten und weiteren Interaktionsmöglichkeiten
  • Versteckte Parameter/Verzeichnisse
• Modul 3 (Logische Fehler/Konfigurationsfehler)
  • Fehler beim Aufbau oder Konfiguration z. B. des http-Protokolls
  • Mögliche Seiteneffekte
• Modul 4 (Exploits (optional))

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

Die folgenden Themenbereiche sollten von den Prüfern beherrscht werden:

• Allgemeine Prinzipien der Webentwicklung
• Häufig verwendete Content-Management-Systeme (CMS) und Webanwendungsframeworks, Datenbanken, Webservices
• Gängige in der Webentwicklung verwendete Programmier- und Skriptsprachen sowie Plugins
• Internetprotokolle und im Internet verwendete Kommunikationsstandards
• Webserver und häufig verwendete Webservermodule
• Spezielle IT-Sicherheits- und Lastverteilungsprodukte für Webauftritte (Web Application Firewalls, Reverse Proxy, Loadbalancer)

Hilfreich ist es zudem, wenn der Prüfer bereits selbst im Bereich Webentwicklung oder Administration gearbeitet hat, da dann Erfahrung mit möglichen Fehlerquellen aus erster Hand vorhanden ist.

Für IS-Webchecks bei Unternehmen der kritischen Infrastruktur (KRITIS) sollte der Prüfer über weitreichende Kenntnisse im jeweiligen Sektor verfügen um die Kritikalität entsprechend bewerten zu können.

Quelle: BSI Praxisleitfaden IS-Webcheck (Seite 17)

Der IS-Webcheck wird in der Regel als Nicht invasiver Schwachstellenscan durchgeführt. Das bedeutet, erkannte Schwachstellen werden nicht aktiv ausgenutzt. Da bestimmte Schwachstellen rein passiv nicht erkannt werden können (z.B. Schwachstellen in Eingabeformularen), ist hier eine Ausnutzung nötig, die Schwachstelle soll durch den Prüfer aber auf möglichst harmlose Weise ausgenutzt werden. Bei einer XSS Schwachstelle kann dies beispielsweise durch das Anzeigen eines Alert Popups geschehen.

 Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

Mit dem IS-Webcheck werden die Sicherheitsstandards einer Internetpräsenz überprüft. Das bedeutet nicht nur die Webanwendung wird getestet, sondern auch Webserver und Datenbanken. Im Endeffekt ergibt sich somit ein umfassendes Bild des aktuellen Sicherheitsstatus.

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 45)

BSI Praxisleitfaden IS-Webcheck (Seite 9)

Nein, aus diversen Gründen ist es unwahrscheinlich, dass ein IS-Webcheck zu lückenloser Sicherheit führt:

• Ein IS-Webcheck stellt immer nur eine Momentaufnahme dar. Da aber täglich neue Schwachstellen bekannt werden, ist ein heute durchgeführter IS-Webcheck keine Garantie dafür, dass die Webpräsenz auch morgen noch sicher ist. Aus diesem Grund empfiehlt es sich, den IS-Webcheck in regelmäßigen Abständen (mindestens alle drei Jahre) zu wiederholen.
• Da bei einem IS-Webcheck das Sicherheitsgateway außen vor bleibt, ist der Test natürlich kosteneffizienter, gleichzeitig aber natürlich auch nicht so umfassend wie ein IS-Penetrationtests. Schwachstellen die das Sicherheitsgateway selbst betreffen, bleiben somit möglicherweise unentdeckt.

Trotz dieser Einschränkungen kann durch den IS-Webcheck in der Regel ein hohes Maß an zusätzlicher Sicherheit für eine Webanwendung erreicht werden.

Quelle: BSI Praxisleitfaden IS-Webchecks (Seite 4)

Hinsichtlich der Dauer gibt es vom BSI keine Vorgabe. Das liegt daran, dass sich Webanwendungen in ihrem Umfang und ihrer Komplexität stark unterscheiden und somit kein „Standardprogramm“ mit einem festgelegten Umfang möglich ist.

Da die Testdauer (bzw. die damit verbundenen Kosten) für den Auftraggeber aber von großem Interesse sind, erstellen wir bei der Inmodis GmbH für Sie eine kostenlose Aufwandsschätzung.

In dieser legen wir da, wie viel Zeit für die einzelnen Komponenten Ihrer Webanwendung einplanen.

Das Abschlussgespräch am Ende des Tests findet in der Regel per Telefon- oder Videokonferenz statt. In diesem Gespräch informiert der Prüfer über den Verlauf des Tests, sowie einige bedeutende Ergebnisse. Die vollständige Dokumentation aller gefundenen Schwachstellen erfolgt im Abschlussbericht.

Übrigens: bei der Inmodis GmbH erhalten Sie den Abschlussbericht bereits ca. 1-2 Wochen nach Ende des Tests.

Quelle: BSI Praxisleitfaden IS-Webcheck (Seite 33)

Der Ablauf eines IS-Webchecks sieht wie folgt aus:

• Einarbeitung des Prüfers
• Test des Prüfobjekts
• Anfangsgespräch
• Einrichtung der Arbeitsumgebung
• Praktische Prüfung
• Schwachstellensuche
• Schwachstellentest
• Logische Fehler/Konfigurationsfehler
• Exploits (Optional)
• Abschlussgespräch
• Abschlussbericht

Dieser Ablauf entspricht dem Praxis Leitfaden des BSI (BSI-LF-WEBCHECK)

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)

Das BSI empfiehlt in seinem Leitfaden den Test regelmäßig, mindestens aber alle drei Jahre, zu wiederholen um auf sich verändernde Gegebenheiten reagieren zu können.

Für Betreiber von kritischer Infrastruktur (KRITIS) wird ein Zeitraum von zwei Jahren empfohlen.

Zusätzlich sollten außerplanmäßige IS-Webchecks durchgeführt werden, wenn es zu größeren Änderungen an der Webanwendung oder der IT-Infrastruktur gekommen ist. Beispiele dafür sind etwa ein Wechsel des CMS oder die Integration neuer Funktionalitäten in die Webanwendung.

Quelle: BSI Praxisleitfaden IS-Webchecks (Seite 8)

Der Prüfumfang wird grundsätzlich zwischen Auftraggeber und Prüfer vertraglich vereinbart. Die folgenden Punkte sind dabei von Bedeutung:

• Prüftiefe (Wie aggressiv wird getestet?)
  • Für den IS-Webcheck gibt es hier zwei Möglichkeiten: den nicht invasiven Schwachstellenscan (bei dem hauptsächlich mit automatisierten Tools nach Schwachstellen gescannt wird und vereinzelt manuelle Interaktionen stattfinden, bei denen aber nach Möglichkeit nur harmlose Testpayloads verwendet werden) und den invasiven Schwachstellenscan bei dem zusätzlich auch Exploits zum Einsatz kommen.
  • Entsprechend ergibt sich aus dem invasiven Schwachstellenscan ein höheres Risiko für die Anwendung, weshalb hier funktionsfähige Backups sowie ein Change Management zwingend erforderlich sind.
• Prüfort (Wo wird getestet?)
  • Bei einem IS-Webcheck erfolgt der Test in der Regel über das Internet. Eine physische Anwesenheit des Prüfers in der Organisation ist daher nicht erforderlich. Anders sieht es aus, wenn die zu testende Webanwendung nicht über das Internet erreichbar ist. In diesem Fall kann ein Test nach Absprache auch vor Ort stattfinden.
• Prüfzeitraum (Wann wird getestet?)
  • Für den Test sollte sowohl ausreichend Einarbeitungszeit, Zeit für den eigentlichen Test, als auch für die Erstellung des Berichts eingeplant werden.
• Prüfbedingungen (Unter welchen Voraussetzungen wird getestet?)
  • Da das Sicherheitsgateway nicht Teil eines IS-Webchecks ist, müssen für den Prüfer entsprechende Freigaben eingerichtet werden. Findet der IS-Webcheck auf einem Testsystem statt, so ist durch den Auftraggeber sicherzustellen, dass dieses dem Originalsystem soweit wie möglich entspricht. Falls auch interne Bereiche einer Anwendung getestet werden sollen, müssen dem Prüfer entsprechende Zugangsdaten bereitgestellt werden.

Quelle: BSI Praxisleitfaden IS-Webcheck (Seite 22-24)

Das BSI empfiehlt ein Team aus zwei Personen, damit das Vier-Augen Prinzip gewahrt bleibt. Insbesondere bei kleineren Projekten muss die Anzahl der zu beauftragenden Prüfer aber auch unter dem Kosten/Nutzen Aspekt gesehen werden.

Übrigens: bei der Inmodis GmbH profitieren Sie bereits standardmäßig von unserem internen Vier-Augen Prinzip. Sowohl die Schwachstellen als auch der Abschlussbericht werden einem internen Review unterzogen, um Probleme rechtzeitig zu erkennen.

Quelle: BSI Praxisleitfaden IS-Webcheck (Seite 19)

Der IS-Webcheck wird grundsätzlich über das Internet (remote) durchgeführt. Eine Anwesenheit des Prüfers bei der Zulassungsbehörde oder beim Portalbetreiber ist daher nicht erforderlich. Ausnahme sind Anwendungen die nicht über das Internet erreichbar sind. In diesen Fällen kann der Test nach Absprache auch beim Auftraggeber vor Ort stattfinden.

Quelle: Kraftfahrt-Bundesamt: Bekanntmachung „Internetbasierte Fahrzeugzulassung (i-Kfz)– Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ Vom 17. Juni 2021 (Seite 46)