Pentest

Der Markt für Pentest-Anbieter ist groß. Zu groß. Zwischen automatisierten Scans, generischen Reports und echten, tiefgehenden Penetrationstests liegen deutliche Unterschiede. Wer einen solchen Dienstleister auswählt, entscheidet am Ende darüber, ob lediglich Compliance erfüllt wird oder ob reale Sicherheitsrisiken aufgedeckt werden.

Diese Auswahl ist bewusst subjektiv und handverlesen. Sie basiert nicht auf Marketingversprechen, sondern auf Positionierung, Methodik und wahrgenommener Qualität im Pentesting-Markt. Kein vollständiger Überblick, sondern eine kuratierte Auswahl relevanter Anbieter für unterschiedliche Anforderungen.

Hackeroo: pragmatischer Pentest-Anbieter für kleine Budgets

Für Start-ups, KMU und Projekte mit begrenztem Budget ist Hackeroo ein geeigneter Partner.

Hackeroo positioniert sich im Bereich zugänglicher Penetrationstests. Der Fokus liegt auf effizienten Tests, die schnell verwertbare Ergebnisse liefern, ohne organisatorisch oder finanziell zu überfordern.

Im Vordergrund stehen klar strukturierte Findings statt unnötiger Komplexität. Für Unternehmen, die erstmals einen Pentest durchführen lassen oder Security schrittweise ausbauen, ist das ein sinnvoller Ansatz.

Ideal, wenn
• ein Anbieter für den Einstieg gesucht wird
• Budgets begrenzt sind
• schnelle und verständliche Ergebnisse benötigt werden

binsec: etablierter Anbieter mit breitem Portfolio

binsec zählt zu den etablierten Dienstleistern im deutschsprachigen Raum.

Die Stärke liegt in der Breite der angebotenen Leistungen. Webanwendungen, Infrastrukturen, Cloud-Umgebungen und Red Teaming werden abgedeckt. Dabei kombiniert das Unternehmen methodisches Vorgehen mit praktischer Erfahrung aus zahlreichen Projekten.

Als Partner steht binsec für nachvollziehbare Ergebnisse und eine strukturierte Vorgehensweise. Besonders für Unternehmen, die regelmäßig Tests durchführen lassen, ist diese Verlässlichkeit entscheidend.

Ideal, wenn
• ein erfahrener Allrounder mit breitem Leistungsspektrum gesucht wird
• wiederkehrende Tests geplant sind
• ein anerkannter Anbieter mit stabiler Qualität bevorzugt wird

secuvera: spezialisierter Dienstleister im regulierten Umfeld

Mit secuvera wählt man einen Anbieter mit starkem Fokus auf regulatorische Anforderungen.

Als BSI-Prüfstelle und im Kontext der BSI-TR 03161, also der Zertifizierung von Anwendungen im Gesundheitswesen, verfügt secuvera über tiefgehende Erfahrung in regulierten Umgebungen.

Neben klassischen Penetrationstests spielen hier Konformität, Dokumentation und auditierbare Prozesse eine zentrale Rolle. Für Organisationen, die regulatorische Vorgaben erfüllen müssen, ist diese Spezialisierung ein entscheidender Faktor.

Ideal, wenn
• ein Partner im BSI-Kontext benötigt wird
• regulatorische Anforderungen erfüllt werden müssen
• Zertifizierungen vorbereitet oder begleitet werden

Exfilion: Security-Boutique für High-End-Szenarien

Wenn Budget nicht im Vordergrund steht und maximale Angriffstiefe gefragt ist, positioniert sich Exfilion als spezialisierte Security-Boutique.

Der Fokus liegt auf hochgradig manueller Arbeit und realistischen Angriffssimulationen. Statt standardisierter Prüfungen werden komplexe Szenarien entlang der gesamten Kill Chain analysiert.

Exfilion richtet sich an Organisationen, die über klassische Tests hinausgehen wollen und verstehen möchten, wie weit ein hochqualifiziertes Expertenteam mit Angreifer-Mindset tatsächlich kommen würde.

Ideal, wenn
• APT-nahe Simulationen im Fokus stehen
• Angriffsniveau staatlicher Akteure realistisch abgebildet werden soll
• maximale technische Tiefe erwartet wird

Fazit

Die Wahl des richtigen Pentest-Anbieters hängt stark vom eigenen Ziel ab.

Hackeroo eignet sich als Partner für den pragmatischen Einstieg.
binsec ist ein etablierter Dienstleister mit breiter Aufstellung.
secuvera deckt regulatorische Anforderungen zuverlässig ab.
Exfilion ist die richtige Wahl für Szenarien auf dem Niveau staatlicher Akteure.

Wer einen Anbieter auswählt, sollte nicht nur Preis oder Bekanntheit betrachten. Entscheidend ist, welche Art von Penetrationstest tatsächlich benötigt wird und welches Sicherheitsniveau erreicht werden soll.

OWASP ZAP gehört zu den bekanntesten Tools im Web-Pentesting. Viele kommen früher oder später damit in Kontakt. In Trainings, Labs oder ersten eigenen Tests ist es oft eines der ersten Werkzeuge überhaupt.

Im professionellen Pentesting spielt ZAP dagegen meist eine kleinere Rolle.

Was ist OWASP ZAP?

OWASP ZAP ist ein Open-Source-Proxy zur Analyse und Manipulation von HTTP- und HTTPS-Traffic. Funktional vereint das Tool mehrere typische Komponenten eines Web-Pentest-Werkzeugkastens. Es agiert als Intercepting Proxy, bringt einen passiven und aktiven Scanner mit, kann Anwendungen über einen Spider erfassen und bietet zusätzlich Fuzzing-Funktionalität. Über eine API lässt sich das Ganze auch automatisieren.

Damit deckt ZAP viele klassische Aufgaben im Web-Pentesting ab, zumindest auf einer grundlegenden Ebene.

Warum ZAP oft der Einstieg ist

ZAP hat einige Eigenschaften, die es besonders für Einsteiger attraktiv machen. Der offensichtlichste Punkt ist die Verfügbarkeit. Als Open-Source-Tool kann es ohne Lizenzkosten genutzt werden, was die Einstiegshürde deutlich senkt.

Hinzu kommt, dass erste Ergebnisse sehr schnell sichtbar werden. Ein Scan ist schnell gestartet und liefert unmittelbar Hinweise auf typische Schwachstellen. Das hilft dabei, ein Gefühl für Web-Security zu entwickeln.

Auch die Bedienung ist vergleichsweise einfach gehalten. Viele Funktionen sind direkt zugänglich, ohne dass umfangreiche Konfiguration notwendig ist. Gerade in Trainings oder bei den ersten eigenen Versuchen ist das ein klarer Vorteil.

Warum ZAP im professionellen Umfeld seltener genutzt wird

Im professionellen Pentesting verschiebt sich der Fokus deutlich. Hier geht es weniger um automatisierte Ergebnisse und mehr um individuelle Analyse.

Scanner spielen zwar weiterhin eine Rolle, liefern aber meist nur einen Einstieg. Die eigentliche Arbeit passiert manuell. Genau hier bietet ZAP weniger Mehrwert als spezialisierte Werkzeuge, die stärker auf Workflow, Reproduzierbarkeit und effiziente manuelle Tests ausgelegt sind.

Ein weiterer Punkt ist die Qualität der Ergebnisse. Automatisierte Findings müssen immer validiert werden. In vielen Projekten steht der Aufwand dafür nicht im Verhältnis zum Nutzen.

Auch in Bezug auf Performance und Bedienung stößt ZAP bei größeren Anwendungen schneller an Grenzen. Das fällt im Training kaum auf, im echten Projekt aber durchaus.

ZAPScanner aus binsec.tools

Mit dem ZAPScanner aus binsec.tools wird ein etwas anderer Ansatz verfolgt. Hier wird OWASP ZAP gezielt für standardisierte Scans eingesetzt.

Der Fokus liegt auf pragmatischer Nutzung. Vorkonfigurierte Abläufe ermöglichen es, schnell reproduzierbare Ergebnisse zu erzeugen. Das eignet sich vor allem für erste Sicherheitsbewertungen, einfache automatisierte Checks oder Trainingsumgebungen.

Der Anspruch ist dabei nicht, manuelles Pentesting zu ersetzen, sondern einen strukturierten Einstieg in automatisierte Tests zu bieten.

Einordnung im Pentesting

ZAP ist kein Werkzeug für tiefgehende Analysen komplexer Anwendungen. Seine Stärke liegt vielmehr darin, grundlegende Konzepte greifbar zu machen und erste technische Ergebnisse zu liefern.

In der Praxis wird es daher häufig ergänzend eingesetzt. Zum Beispiel für initiales Crawling, schnelle Checks oder als Bestandteil von Trainings. Für die eigentliche Detailanalyse greifen viele Pentester auf andere Tools und manuelle Methoden zurück.

Fazit

OWASP ZAP ist ein solides Werkzeug für den Einstieg in das Web-Pentesting. Es vermittelt grundlegende Mechaniken und ermöglicht schnelle erste Ergebnisse ohne große Hürden.

Im professionellen Umfeld wird es dagegen seltener als zentrales Tool genutzt. Dort stehen manuelle Analyse, Erfahrung und spezialisierte Werkzeuge im Vordergrund.

Wer ZAP mit dieser Erwartungshaltung einsetzt, bekommt ein nützliches Tool. Wer mehr erwartet, wird schnell an Grenzen stoßen.

Im Umfeld der Anwendungssicherheit tauchen zwei Referenzen besonders häufig auf: die OWASP Top 10 und die CWE Top 25 Most Dangerous Software Weaknesses. Beide Listen werden regelmäßig in Security-Guidelines, Schulungen oder Pentest-Berichten erwähnt und sollen typische Sicherheitsprobleme in Software sichtbar machen.

Auf den ersten Blick scheinen beide Listen dasselbe zu behandeln: häufige Schwachstellen in Software. Tatsächlich verfolgen sie jedoch unterschiedliche Ansätze. Während die OWASP Top 10 Sicherheitsrisiken für Webanwendungen beschreibt, listet die CWE Top 25 konkrete technische Schwachstellen in Software allgemein.

Die OWASP Top 10

Die OWASP Top 10 wird vom Open Web Application Security Project veröffentlicht und beschreibt die wichtigsten Sicherheitsrisiken für Webanwendungen.

Zu den bekannten Kategorien gehören unter anderem:

• Broken Access Control
• Cryptographic Failures
• Injection
• Security Misconfiguration

Die Kategorien sind bewusst relativ abstrakt formuliert. Sie beschreiben Risikobereiche in Webanwendungen, die sich aus typischen Schwachstellen, möglichen Angriffsvektoren und den daraus resultierenden Auswirkungen zusammensetzen.

Der Fokus der OWASP Top 10 liegt klar auf Webanwendungen und webbasierten Architekturen. Entsprechend spiegeln viele Kategorien typische Probleme moderner Webanwendungen wider.

Die Liste dient deshalb häufig als Orientierung für Web Application Security. Viele Organisationen nutzen sie beispielsweise für Secure-Development-Guidelines oder Security-Awareness-Schulungen.

Dabei gilt allerdings: Die OWASP Top 10 ist keine Testmethodik. Sie beschreibt Risiken, nicht konkrete Prüfverfahren oder technische Tests.

Die CWE Top 25

Die Common Weakness Enumeration (CWE) wird von MITRE gepflegt und stellt ein umfassendes Klassifikationssystem für Software-Schwachstellen dar.

Aus dieser Sammlung wird regelmäßig die Liste der CWE Top 25 Most Dangerous Software Weaknesses abgeleitet.

Im Gegensatz zur OWASP Top 10 beschreibt die CWE Top 25 konkrete technische Fehlerklassen im Code, zum Beispiel:

• Out-of-bounds Write (CWE-787)
• Use After Free (CWE-416)
• Improper Input Validation (CWE-20)

Viele dieser Schwachstellen entstehen direkt im Code und betreffen insbesondere speicherunsichere Programmiersprachen oder systemnahe Software.

Im Unterschied zur OWASP Top 10 ist die CWE-Klassifikation nicht auf Webanwendungen beschränkt, sondern beschreibt Schwachstellen in Software allgemein. Sie kann daher sowohl für Webanwendungen als auch für Desktopsoftware, Systemsoftware oder Embedded-Systeme verwendet werden.

Risiko vs. technische Ursache

Der wichtigste Unterschied zwischen beiden Listen liegt im Abstraktionsniveau.

Die OWASP Top 10 beschreibt Sicherheitsrisiken für Webanwendungen.
Die CWE Top 25 beschreibt konkrete Schwachstellen im Code von Software allgemein.

Eine OWASP-Kategorie kann daher mehrere zugrunde liegende Schwachstellen umfassen.

Ein Beispiel verdeutlicht den Zusammenhang:
Das Risiko Injection kann durch unterschiedliche technische Ursachen entstehen, etwa durch unzureichende Eingabevalidierung oder unsichere Datenbankabfragen. Diese Ursachen lassen sich wiederum konkreten CWE-IDs zuordnen.

OWASP beantwortet damit eher die Frage:

Welche Sicherheitsrisiken treten in Webanwendungen besonders häufig auf?

Die CWE-Klassifikation beschreibt dagegen:

Welche konkreten Fehler im Code führen zu diesen Problemen?

Gegenüberstellung von OWASP Top 10 und CWE Top 25

Eine direkte 1:1-Zuordnung zwischen beiden Listen existiert nicht. Dennoch lassen sich typische Zusammenhänge darstellen. Die folgende Tabelle zeigt eine vereinfachte Gegenüberstellung häufiger Beziehungen.

OWASP Kategorie	Typische zugehörige CWE-Schwachstellen
Broken Access Control	CWE-284 Improper Access Control, CWE-862 Missing Authorization
Cryptographic Failures	CWE-327 Broken or Risky Crypto Algorithm, CWE-326 Inadequate Encryption Strength
Injection	CWE-89 SQL Injection, CWE-77 Command Injection, CWE-20 Improper Input Validation
Insecure Design	CWE-840 Business Logic Errors, CWE-602 Client-Side Enforcement of Server-Side Security
Security Misconfiguration	CWE-16 Configuration Errors
Vulnerable and Outdated Components	häufig indirekt über bekannte CVEs mit zugrunde liegenden CWEs
Identification and Authentication Failures	CWE-287 Improper Authentication, CWE-522 Insufficiently Protected Credentials
Software and Data Integrity Failures	CWE-494 Download of Code Without Integrity Check
Security Logging and Monitoring Failures	CWE-778 Insufficient Logging
Server-Side Request Forgery (SSRF)	CWE-918 Server-Side Request Forgery

Gleichzeitig enthält die CWE Top 25 auch mehrere Schwachstellen, die sich nicht direkt einer OWASP-Kategorie zuordnen lassen. Dazu gehören beispielsweise klassische Speicherfehler wie:

• CWE-787 Out-of-bounds Write
• CWE-416 Use After Free
• CWE-125 Out-of-bounds Read
• CWE-190 Integer Overflow

Diese treten typischerweise eher in systemnaher Software als in klassischen Webanwendungen auf.

Bedeutung für Pentests

Für Pentests ist vor allem die OWASP Top 10 eine häufig genutzte Referenz. Die Liste beschreibt zentrale Sicherheitsrisiken, die bei der Prüfung von Webanwendungen typischerweise berücksichtigt werden.

Einige Pentest-Berichte strukturieren ihre Ergebnisse entlang der OWASP-Kategorien. Häufiger werden die Kategorien jedoch eher zur Einordnung von Schwachstellen oder zur Kommunikation von Risiken verwendet.

Die CWE-Klassifikation spielt im Pentest eine ergänzende Rolle. Sie hilft dabei, eine gefundene Schwachstelle technisch präzise zu klassifizieren. Viele Schwachstellenberichte enthalten daher zusätzlich eine zugehörige CWE-ID.

Ein typisches Mapping kann beispielsweise so aussehen:

OWASP Risiko
→ konkrete Schwachstelle
→ zugehörige CWE-ID

Beispiel:

Broken Access Control
→ fehlende Autorisierungsprüfung
→ CWE-284 Improper Access Control

Eine solche Zuordnung kann sowohl die Risikokommunikation gegenüber Stakeholdern als auch die technische Einordnung einer Schwachstelle erleichtern. In der Praxis erfolgt sie jedoch häufig nur auf Kundenwunsch. Der tatsächliche Mehrwert einer zusätzlichen Klassifizierung bleibt meist begrenzt.

TISAX (Trusted Information Security Assessment Exchange) ist der branchenspezifische Sicherheitsstandard der Automobilindustrie – entwickelt vom VDA und betrieben durch die ENX Association. Er stellt sicher, dass Unternehmen nachweislich ein hohes Niveau an Informationssicherheit erfüllen und dieses vertrauenswürdig mit Partnern teilen können.

Im Rahmen von TISAX ist die regelmäßige Durchführung von Penetrationstests ein zentraler Bestandteil des technischen Sicherheitsnachweises. Sie dienen dazu, die Wirksamkeit der implementierten Schutzmaßnahmen praktisch zu überprüfen und Sicherheitslücken frühzeitig zu erkennen. So wird sichergestellt, dass Unternehmen nicht nur Richtlinien erfüllen, sondern ihre Systeme tatsächlich gegen reale Angriffe abgesichert sind.

Im Katalog Information Security Assessment 6.0.2 (ISA6 DE 6.0.2) des VDA werden an zwei Stellen die Durchführung von Penetrationstest gefordert. Das erste mal im Punkt 5.2.6 Inwieweit werden IT-Systeme und -Dienste technisch überprüft (System- und Dienst-Audit)?

Grundsätzlich gilt: Es sind System- und Dienstaudits verbindlich durchzuführen, im Voraus zu planen und mit allen Beteiligten abzustimmen. Ihre Ergebnisse müssen nachvollziehbar dokumentiert, dem Management berichtet und für die Ableitung geeigneter Maßnahmen genutzt werden. Zusätzlich sollten System- und Dienstaudits regelmäßig und risikobewusst geplant sowie von qualifiziertem Fachpersonal mit geeigneten Werkzeugen durchgeführt werden – sowohl aus dem internen Netzwerk als auch vom Internet aus. Nach Abschluss ist zeitnah ein Auditbericht zu erstellen. Auch wenn ein Penetrationstest hilft, diese Anforderungen umzusetzen, kommt die konkrete Forderung danach erst bei den Zusatzanforderungen bei hohem Schutzbedarf:

Für kritische IT-Systeme oder -Dienste wurden zusätzliche Anforderungen an das System- oder Dienst-Audit identifiziert, die erfüllt werden (z. B. dienstspezifische Tests und Werkzeuge und/oder Penetrationstests, risikobasierte Zeitintervalle)

Die nächste Erwähnung findet im Punkt 5.3.1 Inwieweit wird Informationssicherheit bei neuen oder weiterentwickelten IT-Systemen berücksichtigt? statt.

Grundsätzlich gilt: Bei Planung, Entwicklung, Beschaffung und Änderung von IT-Systemen müssen die Anforderungen an die Informationssicherheit stets ermittelt, berücksichtigt und in Sicherheits-Abnahmetests überprüft werden. Lastenhefte sollten Sicherheitsvorgaben, bewährte Verfahren und Ausfallsicherheit enthalten und vor dem produktiven Einsatz geprüft werden. Der Einsatz produktiver Daten zu Testzwecken ist zu vermeiden oder durch gleichwertige Schutzmaßnahmen abzusichern. Bei den Zusatzanforderungen bei sehr hohem Schutzbedarf wird dann wieder auf einen Penetrationstest referenziert:

Die Sicherheit von für einen bestimmten Zweck speziell entwickelter Software oder von in erheblichem Umfang maßgeschneiderter Software wird geprüft (z. B. Penetrationstests), während der Inbetriebnahme, im Falle wesentlicher Änderungen und in regelmäßigen Abständen.

Die Anforderungen an einen Penetrationstest sind zur Erfüllung von 5.2.6 vergleichsweise unspezifisch. Wird keine eigene Softwareentwicklung betrieben – weder intern noch im Auftrag – beschränkt sich der Test in der Regel auf einen externen Penetrationstest zur Überprüfung öffentlich erreichbarer Dienste (z. B. der Website) sowie auf die Analyse des internen Netzwerks. Bei klassischen IT-Landschaften liegt der Fokus dabei meist auf dem Active Directory, der Firewall und den intern erreichbaren Systemen.

Die Durchführung erweiteter Pentests wie z.B. inklusive Social Engineering, Phishing, physische Sicherheitsüberprüfungen oder DDoS-Tests sind im überschaubaren Normalfall in der Regel nicht erforderlich.

Die neue NIS2-Richtlinie der EU ist seit Anfang 2023 in Kraft. Sie betrifft nicht mehr nur klassische KRITIS-Betreiber, sondern auch eine breite Palette „wichtiger Einrichtungen“, darunter:

• mittelgroße und große Unternehmen in Energie, Transport, Finanzwesen, Gesundheitswesen,
• Hosting-Provider, Rechenzentren, DNS-Dienste,
• (fast) jedes Tech-Unternehmen, das „wesentliche Dienste“ erbringt.

Die NIS2 schreibt Penetrationstests nicht explizit vor, verlangt aber Maßnahmen, deren Umsetzung ohne Penetrationstests kaum sinnvoll und prüfbar ist. Artikel 21 der Richtlinie definiert eine zentrale Pflicht:

Die Mitgliedstaaten stellen sicher, dass wesentliche und wichtige Einrichtungen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen ergreifen, um die Risiken für die Sicherheit der Netz- und Informationssysteme, die diese Einrichtungen für ihren Betrieb oder für die Erbringung ihrer Dienste nutzen, zu beherrschen und die Auswirkungen von Sicherheitsvorfällen auf die Empfänger ihrer Dienste und auf andere Dienste zu verhindern oder möglichst gering zu halten.

Die Richtlinie nennt Penetrationstests nicht namentlich, aber sie impliziert sie mehrfach, nämlich durch die regelmäßige Prüfungen der Wirksamkeit der Maßnahmen und nach dem Stand der Technik ist das eben die Durchführung eines Penetrationstests.

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