Penetration Test Netzwerk

Was ist der Umfang des Pentests von AGIDAT?

Vier Elemente: Information Gathering,  CVE-Scan,  Service Brutforce,  Service Discovery

Der automatisierte Pentest von AGIDAT besteht aus vier Elementen:

  • Information Gathering: Durch Basis und Deep Scans erstellt die Pentest-Software ein Footprinting der Anwendungsumgebung.

  • CVE-Scan: Die ermittelten Anwendungen untersucht die Pentest-Software auf bekannte Sicherheitslücken.

  • Service Bruteforce: Durch das automatisierte ausprobieren von Benutzer-Passwort-Kombinationen werden unsichere Login-Daten aufgedeckt.

  • Service Discovery: Spezielle Checks z.B. der Verschlüsselung, Authentifizierung und Privilegien bestimmter Services decken sicherheitsrelevante Konfigurationsmängel auf.

AGIDAT ermittelt automatisiert, welche Tests für das jeweilige Zielsystem herangezogen werden müssen. Im Folgenden erfahren Sie im Detail, was die Pentest-Software prüfen kann.

Information Gathering

Ziel des Information Gatherings ist ein möglichst umfassendes Footprinting der untersuchten Systeme zu erstellen. Unter Footprinting wird das Sammeln von Informationen verstanden, die für die anschließenden Hackingattacken genutzt werden. Dieses Vorgehen nutzen auch echte Hacker, um abzuschätzen, welche Angriffsvektoren erfolgversprechend sind. Deshalb ist es aus Sicherheitsperspektive am Besten, möglichst wenig über verwendete Technologien nach außen preiszugeben.

Der AGIDAT die Pentest-Software setzt beim Footprinting auf verschiedene Ansätze. Einerseits die Basic Scans: Dabei werden Ports und HTTP-Header untersucht. Anderseits Deep Scans, wobei unter anderem die Webanwendung und SNMP unter die Lupe genommen wird.

Basic Scan

Service

Beschreibung

Ports

Offene Ports werden auf die dahinterliegende Anwendung untersucht und ob die verwendete Version preisgegeben wird.

HTTP-Header

In HTTP-Headern (insbesondere X-Mod-Pagespeed und Server) werden häufig vermeidbar Informationen zum System preisgegeben.

Deep Scan

Service

Beschreibung

Webanwendung

Mittels statistischer Verfahren werden Webanwendungen auf die verwendeten Technologien untersucht (z.B. CMS, Programmiersprachen und Libraries).

SNMP (Betriebssystem)

Über SNMP lässt sich gegebenenfalls das verwendete Betriebssystem aufdecken. Eine für Angreifer sehr wertvolle Information.

SNMP (installierte Pakete)

Über SNMP kann ein Zugriff auf die installierten Pakete möglich sein. Dabei handelt es sich um eine höchst sensible Information.

Erreichbarer Remote Control Service

Dienste, über die eine Fernwartung durchgeführt werden können, sind aus Sicherheitsperspektive kritisch zu betrachten.

CVE-Scan

Zusätzlich überprüft die Pentest-Software die zur Bereitstellung der Services verwendeten Softwareversionen auf CVEs. Es handelt sich dabei um einen netzwerkseitigen Flächenscan nach Sicherheitslücken.

Findet die Pentest-Software eine Sicherheitslücke (CVE), versucht er sie zu validieren. Das heißt, er prüft, ob die Sicherheitslücke bei dem entsprechenden Betriebssystem wirksam wird, sie also ausgenutzt werden kann. Ist dies der Fall, erhält die Sicherheitslücke die Kennzeichnung „validated“. Es kann vorkommen, dass es die Pentest-Software nicht möglich ist, das Betriebssystem zweifelsfrei festzustellen. Die Sicherheitslücke kann dann nicht validiert werden. Sie taucht trotzdem im Audit Report auf, erhält jedoch den Hinweis „invalidated“. In diesem Fall muss der Nutzer selbst nachprüfen, ob die Sicherheitslücke bei diesem System wirksam ist.

Service Bruteforce

Im Rahmen des Bruteforce-Angriffes, versucht der die Pentest-Software durch das massenhafte Ausprobieren von Passwörtern, Zugriff auf Ihr System zu erlangen.

Für folgende Services wird Bruteforce angeboten:

  • SSH

  • Telnet

  • FTP

  • MySQL

  • Mongo DB

  • MS SQL

  • Redis

  • Maria DB

  • Rabbit MQ

  • PostgreSQL

  • HTTP Basic Auth

  • SNMP

  • SMB

  • RDP

Passwortlisten

Sie haben die Wahl entweder auf Passwortlisten von AGIDAT zurückzugreifen und/oder individuelle Listen einzubinden. Darüber hinaus testet die Pentest-Software servicespezifische Standardauthentifizierungen.

Service Discovery

In der Discovery-Phase untersucht die Pentest-Software die detektierten Services auf spezifische, gängige Konfigurationsmängel. Er testet dabei unter anderem Authentifizierungs-Verfahren, Privilegien-Zuordnungen und Verschlüsselungs-Verfahren.

DNS (Domain Name System)

Titel

Beschreibung

Fehlende Kontaktadresse für DNS CAA

Für die Certification Authority Authorization (CAA), die das Zertifikat für die Domain ausgestellt hat, ist keine Kontaktadresse angegeben.

Fehlender CDNSKEY Rekord

CDNSKEY records werden im Rahmen von DNSSEC verwendet. Sie sind nützlich, wenn Veränderungen am DNSKEY vorgenommen werden.

Fehlender CDS Rekord

CDS records werden im Rahmen von DNSSEC verwendet. Sie sind nützlich, wenn Veränderungen am DNSKEY vorgenommen werden.

Fehlender DMARC Record

Domain-based Message Authentication, Reporting and Conformance (DMARC) baut auf SPF auf. Es erlaubt der Absender-Domain eine Spezifikaion festzulegen, wie bei einem Verstoß der Empfänger mit der E-Mail umgehen soll.

Fehlender DNS CAA Eintrag

DNS Certification Authority Authorization (CAA) Records dienen dazu, bestimmte Zerifizierungsstellen (CAs) zu berechtigen, ein Zertifikat für die Domain auszustellen. So kann verhindert werden, dass fälschlicherweise Zertifikate für eine Domain ausgestellt werden.

Fehlender DNSKEY Record

DNSKEY Records werden im Rahmen von DNSSEC verwendet, um den öffentlichen Schlüssel über einen öffentlich zugänglichen Server zugänglich zu machen.

Fehlender DS DNS Record

DS Records werden im Rahmen von DNSSEC verwendet, um eine Chain of Trust aufzubauen, die über einen einzigen öffentlichen Schlüssel validiert werden kann.

Fehlender NSEC Record

NSEC Records werden im Rahmen von DNSSEC verwendet, um alle vorhandenen Einträge in alphabetischer Reihenfolge zu verketten. So kann das Nicht-Vorhandensein von DNS-Einträgen verifiziert werden.

Fehlender NSEC3 Record

NSEC3 Records werden im Rahmen von DNSSEC verwendet. Sie bieten eine alternative Möglichkeit zu NSEC, um das Nicht-Vorhandensein von Einträgen zu verifizieren. Dabei setzt NSEC3 auf Hashwerte statt Klartext.

Fehlender RRSIG Record

RRSIG Records werden im Rahmen von DNSSEC verwendet. Sie enthalten die Signatur eines DNS-Resource-Record-Sets.

Fehlender SPF Record

Das SPF-Protokoll ermöglicht, IP-Adresse zur Versendung von E-Mails mit der Domain zu berechtigen. So kann Dritten untersagt werden, den Domainnamen missbräuchlich zu verwenden.

Fehlerhafte DKIM Syntax

DomainKeys Identified Mail (DKIM) ermöglicht die Erkennung gefälschter E-Mail-Absender.

Fehlerhafte SPF Syntax

Der Eintrag enthält unbekannte Einträge (bekannt sind: spf1, mx, ip4, ip6, exists, include, all, a, redirect, exp, ptr) und/oder unerlaubte Zeichen.

Keine Unterstützung für DNSSEC

Domain Name System Security Extensions (DNSSEC) ermöglicht durch Signaturen, die Authentizität und Integritert erhaltener Daten zu prüfen. So wird verhindert, dass Datem umgelenkt oder verändert werden können.

Mehrere SPF-Einträge vorhanden

Nutze niemals mehrere SPF-Einträge. Fasse stattdessen mehrere SPF in einem einzigen Eintrag zusammen.

SPF-Eintrag enthält Zeichen nach ALL

Nach dem fakultativen ALL-Eintrag dürfen keine weiteren Einträge folgen.

Ungültige DMARC Adresse für Report-Emails

Die Report-E-Mailadresse enthält ungültige Zeichen oder ein ungültiges E-Mail-Format (nicht abc@def.com)

Ungültige DMARC Policy

Die DMARC Policy (p) hat keinen gewöhnlichen Wert. Gewöhnliche Werte sind: none, quarantine und reject.

Ungültige DMARC Protokollversion

Die Version von DMARC (v) muss DMARC1 lauten.

Ungültige DMARC prozentuale Filterangabe

Mit der optionalen prozentualen Filterangabe (pct) kann festgelegt werden, wieviel Prozent der Nachrichten einer Filterung unterzogen werden. Der Wert muss daher zwischen 1 und 100 liegen.

Ungültige DMARC Subdomain Policy

Die DMARC Subdomain Policy (sp) hat keinen gewöhnlichen Wert. Gewöhnliche Werte sind: none, quarantine und reject.

Ungültige Kontaktadresse für DNS CAA

Die angegebene E-Mail-Adresse der Zertifizierungsstelle entspricht nicht dem gültigen E-Mail-Format (abc@xyz.com).

Ungültiger DMARC SPF Alignment Mode

Der Abgleichmodi besitzt nicht einen der gewöhnlichen Angaben strict (s) oder relaxed (r).

Ungültiger Inhalt des DMARC Records

Der Inhalt des DMARC Records ist nicht gültig, da ein oder mehrere Tags in der DMARC Record nicht gesetzt sind.

Unkonventionelle Zertifizierungsstelle

Die verwendete Zertifizierungsstelle (issue, wildissue) befindet sich nicht auf unserer Whitelist.

Veraltete SPF-Version

Check der verwendeten SPF-Version (v), momentan existiert lediglich SPF1.

FTP (File Transfer Protocol)

Titel

Beschreibung

Anonyme FTP-Session

Anonymous FTP erlaubt einen freien Zugriff für alle Besucher auf die FTP-Verzeichnisse. Prüfe, ob das notwendig ist und die Lese- und Schreibrechte korrekt konfiguriert sind.

Anonymer Zugang zum root (/) Verzeichnis

Das root-Verzeichnis ist Teil des Backends und ein Zugriff via FTP sollte nur autorisierten Benutzern mit entsprechenden Zugangsdaten gewährt werden.

Change Working Directory (cwd) Zugang für anonynme Nutzer

Der Befehl CWD erlaubt das Wechseln des aktiven Verzeichnisses auf dem FTP-Server. Diese Möglichkeit sollte anonymen Nutzern nicht gestatt sein.

Löschrechte für anonyme Nutzer

Achte darauf, Lese- und Schreibrechte richtig zu konfigurieren. Anonymen Nutzern sollten niemals in der Lage sein, Dateien zu löschen.

Schreibrechte für anonyme Nutzer

Achte darauf, Lese- und Schreibrechte richtig zu konfigurieren. Anonymen Nutzern sollten niemals über Schreibrechte verfügen.

HTTP (Hypertext Transfer Protocol)

Titel

Beschreibung

Common Source Leak

Dateien, die versteckt sein sollten, sind öffentlich zugänglich. Sie geben möglicherweise wichtige Informationen preis, die das Ziel potenziell angreifer machen.

Cross Site Scripting (XSS)

Bei Cross Site Scripting (XSS) wird HTML/JavaScript/CSS unvalidiert in eine Webseite eingebettet, um bspw. Nutzersessions abzufischen.

Directory Listing ist aktiviert

Directory Listing ist eine Webserver-Funktion, die den Inhalt eines Verzeichnisses offenbart, das keine Indexdatei hat. Ein Angreifer kann sich leicht Zugang zu privaten Inhalten auf dem Webserver verschaffen.

E-Mail Harvesting

Der Host ist anfällig für das Harvesting von E-Mail-Adressen. Böswillige Bots können diese Kontakte von der Website ermitteln und für die spätere Verwendung wie illegitime Massen-Betrüger-Mails, d.h. Phishing-Betrügereien, speichern.

Erlaubt Offene Umleitung

Der Host ermöglicht die Integration von benutzerdefinierten Daten in Umleitungsziele. Ein Angreifer kann so Benutzer auf eine beliebige externe Domäne umleiten. Dadurch wird er anfällig für Phishing-Angriffe gegen Benutzer.

Erlaubt Zugang zum Berechtigungsnachweis-Speicher

Dateien, die sensible Dateien beinhalten (bspw. Passwörter) sind öffentlich über http zugänglich.

Erlaubt Zugriff auf Datenbank-Dump

Teilweise oder ganze Auszüge von Datenbanken, die für die Datensicherung oder Portierung erstellt wurden (Dantenbankdump), sollten nicht öffentlich erreichbar sein.

Ermöglicht ungültige Umleitung

Die Webanwendung akzeptiert nicht vertrauenswürdige Eingaben. Das kann ein Angreifer nutzen, um auf eine nicht vertrauenswürdige URL weiterzuleiten.

Fehlende HTTPS-Umleitung

Es fehlt eine Weiterleitung auf die HTTPS-Seite, sofern eine HTTP-Seite aufgerufen wird.

Gemischter HTTP-Inhalt gefunden

Auf die Webseite wird sicher über HTTPS zugegriffen, aber der Inhalt besteht aus Links, die über unsicheres HTTP aufgerufen werden.

Öffentlich erreichbares Backend

Das Backend ist öffentlich erreichbar. Schränke den Zugriff ein, z.B. mit einem VPN.

SQL Injection

Bei einer SQL Injection versucht ein Angreifer eigene Datenbankbefehle in eine SQL-Datenbank einzuschleusen, um Daten auszuspähen oder die Kontrolle über das System zu erlangen.

Unterstützt Command Injection

Ziel von Command Injection ist das Ausführen von Befehlen auf dem Host-Server der Website. Sie ist möglich, wenn eine Anwendung vom Benutzer bereitgestellte Daten an eine System-Shell weitergibt. Durch unvalidierte Parameter können beliebige Befehle auf dem Host-System ausgeführt werden.

Unterstützt File Inclusion

File Inclusion ist das Einschleusen von Dateien und Code durch eine Sicherheitslücke in der Webanwendungen.

HTTP-Header

Titel

Beschreibung

Fehlender Content-Security-Policy Header

Die HTTP Content-Security-Policy regelt welche Ressourcen in einer bestimmten Art und Weise im Browser geladen bzw. ausgeführt werden können.

Fehlender Feature-Policy Header

Die Feature-Policy bestimmt, welche Funktionen oder APIs eines Browsers verwendet werden dürfen.

Fehlender HTTP-Header Flag „secure“

Bei der Verwendung von HTTPS sollten alle Cookies mit \“secure\“-Flag versehen werden. Dies verhindert ein ungewolltes Mitlesen im Netzwerk, wenn der Cookie unverschlüsselt versendet wird.

Fehlender Referrer-Policy Header

Die Referrer-Policy stellt sicher, dass Referrer Informationen nur unter bestimmten Bedingungen gesendet werden dürfen.

Fehlender Strict-Transport-Security Header

Die HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus für HTTPS-Verbindungen, der sowohl vor Aushebelung der Verbindungsverschlüsselung als auch vor Session Hijacking schützt.

Fehlender X-Content-Type-Options Header

Der einzige definierte Wert „nosniff“ untersagt dem Internet Explorer durch MIME-Sniffing einen anderen als den deklarierten Inhaltstyp zu bestimmen und anzuwenden.

Fehlender X-Frame-Options Header

Die X-Frame-Options können verwendet werden, um zu bestimmen, ob ein aufrufender Browser die Zielseite in einem <frame>, <iframe> oder <object> rendern also einbetten darf.

Fehlender X-XSS-Protection Header

Die X-XSS-Protection kann Browsern untersagen eine Zielseite zu laden, sofern eine Cross-Site Scripting (XSS) Attacke erkannt wird.

Ungewöhnliche HTTP Header

Es wurde ein unbekannter HTTP-Header erkannt, der potenziell Informationen preisgibt. Bitte überprüfe die Notwendigkeit des HTTP-Headers und entferne diesen.

Unsicherer Set-Cookie

Der Set-Cookie HTTP-Header wird verwendet, um Cookies vom Server zum Browser zu übertragen.

Vermeidbarer X-Mod-Pagespeed Header

Der X-Mod-Pagespeed Header sollte deaktiviert sein, um keine unnötigen Informationen preiszugeben.

Vermeidbarer X-Powered-By Header

Viele Server sind in ihrer Standard Konfiguration sehr freizügig mit der Bekanntgabe von Informationen. Dies betrifft vor allem den X-Powered-By und Server-Header. Diese sollten aus Sicherheitsgründen immer deaktiviert werden.

MongoDB

Titel

Beschreibung

Erlaubt das Löschen von Sammlungen

Das Löschen von Sammlungen sollte nur entsprechend authentifizierten Nutzern erlaubt sein.

Erlaubt Hinzufügen von Sammlungen

Das Hinzufügen von Sammlungen sollte nur entsprechend authentifizierten Nutzern erlaubt sein.

Erlaubt Zugriff auf Admin-DB

Der Hauptzweck der Admin Database ist das Aufbewahren von system collections, authentication und authorization data, was Benutzernamen und Passwörter beinhaltet. Auf diese sensiblen Informationen sollte nur der Administrator Zugriff haben.

Erlaubt Zugriff auf die Config-DB

In der Congig DB liegen Daten zur Verwaltung und dem Zugriffsmanagement der Datenbank. Auf diese Daten sollte kein Zugriff möglich sein.

Erlaubt Zugriff auf Lokale DB

In der Local DB liegen Daten zur Verwaltung und dem Zugriffsmanagement der Datenbank. Auf diese Daten sollte kein Zugriff möglich sein.

Ermöglicht anonyme Anmeldung

Wenn eine MongoDB erstellt wird, sind keine Authentifizierungs-Mechanismen aktiv und der Nutzer hat alle Privilegien. Um die Sicherheit der mongodb zu erhöhen, sollte ein anonymer Zugang deaktiviert sein.

Ermöglicht den Zugriff auf verschiedene DBs

In den Sammlungen, die nicht nicht zur standard collection (Admin/Local/Config) gehören, liegen die spezifischen Daten der Datenbank. Auf sie sollte kein Zugriff möglich sein.

MySQL

Titel

Beschreibung

Anonyme Verbindung vom Root-Benutzer

Eine nicht passwortgeschützte Verbindung als Administrator (mit Root-Rechten) ist möglich.

Anonymer Benutzer gefunden

Beim Einrichten der MySQL-Instanz wird ein anonymer Benutzer erstellt, der es jedem ermöglicht, sich bei der Datenbank anzumelden, ohne ein Benutzerkonto eingerichtet zu haben. Er ist nur für Testzwecke gedacht und sollte vor der Produktivsetzung entfernt werden.

Benutzer mit Fernzugriff von einem beliebigen Host gefunden

Standardmäßig ist ein öffentlicher Remote Zugriff auf MySQL aus Sicherheitsgründen deaktiviert. Falls nötig, kannst du einen Remote Zugriff einrichten. Diesen sollte jedoch auf bestimmte IP-Adressen eingeschränkt sein.

Benutzer ohne Passwort gefunden

Für jeden Benutzer der MySQL-Datenbank sollte ein sicheres Passwort festgelegt werden.

Möglichkeit Benutzer-Privilegien zu ändern

Die Rolle von Nutzern kann geändert werden, zum Beispiel zu einem Nutzer mit Administrator-Rechten. So können unberechtigte Zugriffe ermöglicht werden.

Möglichkeit neuen Benutzer zu erstellen

Ihre MySQL-Datenbank sollte so konfiguriert sein, dass es für Unbefugte nicht möglich ist, einen neuen Nutzer anzulegen.

Test-DB gefunden

Einige MySQL-Server erstellen bei der Installation eine Datenbank mit dem Namen „test“, die für alle Nutzer zugänglich ist. Diese Einstellungen werden auf alle Datenbanken, deren Bezeichnung mit test_ beginnt übertragen. Die Test-Datenbank sollte daher prinzipiell entfernt werden.

Zugriff performance_schema DB

Das MySQL Performance Schema ist eine Funktion zur Überwachung der MySQL-Ausführungen. Diese Informationen sollten nicht öffentlich zugänglich sein.

SMB (Server Message Block: microsoft-ds und netbios-ssn*)

Titel

Beschreibung

Vorhandene Open Network Shares

Es existiert eine Freigabe, die nicht unter die Standard-Freigaben fällt.

Erlaubt Gastzugriff

Bei fehlerhaftem Login wird automatisch ein Gastzugriff erteilt, der möglicherweise Zugriffsrechte besitzt.

Erlaubt Lesezugriff

Ein Lesezugriff auf freigegebene Ordner ist via SMB möglich.

Erlaubt Schreibzugriff

Ein Schreibzugriff auf freigegebene Ordner, die nicht standardmäßig eingestellt sind, ist via SMB möglich.

* Netbios-SSN wird momentan lediglich für Linux und nicht für Windows unterstützt.

SNMP (Simple Network Management Protocol)

Titel

Beschreibung

Verwendet gewöhnlichen Community String

Für SNMP werden eine oder mehrere Community Strings zur Nutzerauthentifizierung verwendet, die häufig verwendet werden und daher besonders unsicher sind.

Erlaubt Lesezugriff

Ein Lesezugriff auf Object Identifier (OID) ist via SNMP möglich.

Erlaubt Schreibzugriff

Ein Schreibzugriff auf Object Identifier (OID) ist via SNMP möglich.

SSH (Secure Shell)

Titel

Beschreibung

Keine Unterstützung für SSH-Authentifizierung mit öffentlichem Schlüssel

Der Client sollte sich gegenüber dem Server mittels Public Key authentifizieren müssen, da Passwörter unsicher sein können und somit für Bruteforce anfällig sind.

Unsichere Mac Algorithmen

Der Message Authentication Code (MAC) dient dazu, Gewissheit über den Ursprung von Daten zu erhalten und sie auf Integrität zu überprüfen. Mittels Keyed-Hash Message Authentication Code (HMAC) wird diese Überprüfung abgesichert. Dabei sollte ein sicheres Verfahren zum Einsatz kommen.

Unsichere Schlüsselaustausch-Algorithmen

Im Rahmen des SSH-Verbindungsaufbaus findet ein Schlüsselaustausch (Key Exchange) statt. Der gemeinsame Sitzungsschlüssel wird für die Authentifizierung und Verschlüsselung der Sitzung genutzt. Wird eine unsichere Schlüsseltausch-Methode verwendet, ist die Absicherung der Verbindung gefährdet.

Unsichere Server-Host-Schlüsselalgorithmen

Im Rahmen des SSH-Verbindungsaufbaus findet ein Schlüsselaustausch (Key Exchange) statt. Währenddessen einigen sich Client und Server auf einen gemeinsamen Verschlüsselungs-Schlüssel. Dabei sollte ein sicheres Verschlüsselungsverfahren gewählt werden.

Unsichere SSH-Version

Im Jahr 2006 wurde SSH-1 durch die überarbeitete Version Netzwerkprotokolls (SSH-2) abgelöst. SSH-1 gilt aufgrund kryptografischer Schwächen als nicht mehr sicher und sollte daher nicht verwendet werden.

Unsichere Verschlüsselungsalgorithmen

Im Rahmen des SSH-Verbindungsaufbaus finden ein Schlüsselaustausch (Key Exchange) statt. Währenddessen einigen sich Client und Server auf einen gemeinsamen Verschlüsselungs-Algorithmus. Dabei sollte ein sicheres Verschlüsselungsverfahren gewählt werden.

Unsicherer öffentlicher Schlüssel

Der Server authentifiziert sich gegenüber seinem Client. Exchange-Nachrichten des Servers erhalten einen Public Key, den der Client nutzen kann, um die Authentiziztät zu prüfen. Dabei sollte ein sicheres Verfahren zum Einsatz kommen.

Unterstützt SSH-Passwort-Authentifizierung

Eine auf asymetrischen Schlüsseln basierende Authentifizierung gilt als sicherer denn über ein Passwort. Deshalb sollte die Option einer Authentifizierung via Passwort in der Regel deaktiviert sein.

SSL/TLS (Secure Sockets Layer/Transport Layer Security)

Titel

Beschreibung

Abgelaufenes Zertifikat

Wenn das Zertifikat abgelaufen ist, wird es ungültig und du kannst keine sicheren Transaktionen mehr durchführen.

Ablauf der Gültigkeit der CRL (Certificate Revokation List)

Der Gültigkeitszeitraum der verwendeten Zertifikatsperrliste ist abgelaufen.

Abweichung zwischen Zertifizierungsstelle und Aussteller

Zertifizierungsstelle und Aussteller passen nicht zusammen.

Abweichung zwischen Zertifizierungsstelle und Seriennummer des Ausstellers

Zertifizierungsstelle und Seriennummer des Ausstellers passen nicht zusammen.

Anfällig für DROWN

Mit Hilfe des veralteten SSLv2 lässt sich aufgezeichneter TLS-Traffic knacken.

Anfällig für FREAK

Bei einer FREAK-Attacke werden die Kommunikationspartner dazu gebracht, sich auf eine unsichere Verschlüsselungsmethode zu einigen, obwohl sichere Verfahren zu Verfügung stehen.

Anfällig für Logjam Attacken

Indem eine Schwachstelle im Diffie-Hellman-Schlüsselaustausch ausgenutzt wird, kommen Angreifer an die geheimen Schlüssel.

Anfällig für NULL Pointer Dereference

Durch das Versenden eines bösartigen Zertifikats kann ein Angreifer einen Denial-of-Service-Zustand verursachen.

Anfällig für SLOTH Attacke

Schwache Hashfunktionen (MD5, SHA-1) erlauben eine SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes) Attacke.

Anfällig für Sweet32 Attacken

Die Stream-Chiffre RC4 macht die Verbindung anfällig für Sweet32 Attacken.

Anfällig nach Maßgabe der Datenschutzgrundverordnung (DSGVO)

Die SSL/TLS-Verschlüsselung widerspricht dem aktuellen Stand der Technik und verstößt daher gegen Art. 32 DSVGO.

Anfällig nach Maßgabe des BSI (Bundesamt für Sicherheit in der Informationstechnik)

Die SSL/TLS-Verschlüsselung entspricht nicht den Maßgaben des BSI.

Chiffre unterstützt MD5

MD5 gilt nicht mehr als ausreichend sicher und sollte daher nicht verwendet werden.

CRL Signatur nicht entschlüsselbar

Die Schlüsselverwendung berücksichtigt nicht das Signieren von Zertifikaten

Die Zertifikatskette konnte nicht verifiziert werden

Formatfehler im Feld lastupdate von crl

Das lastupdate-Feld enhält eine ungültige Zeit.

Formatfehler im Feld nextupdate von crl

Das nextupdate-Feld enhält eine ungültige Zeit.

Formatfehler im notafter Feld des Zertifikats

Das notafter-Feld enhält eine ungültige Zeit.

Formatfehler im notbefore Feld des Zertifikats

Das notbefore-Feld enhält eine ungültige Zeit.

Kein Zertifikatsaussteller ermittelbar

SSL/TLS-Zertifikate werden von Certification Authoritys (CA) herausgegeben. Der Herausgeber muss ermittelbar sein.

Keine Unterstütztung für Perfect Forward Secrecy (PFS)

Perfect Forward Secrecy stellt sicher, dass der jeweils neu ausgehandelte Sitzungsschlüssel nicht aus dem Langzeitschlüssel rekonstruiert werden kann.

Keine Unterstützung für Authenticated Encryption (AEAD) Chiffren

Authenticated Encryption vereinfacht die Realisierung von Vertraulichkeit und Authentitizität und wird daher empfohlen.

Keine Unterstützung für Secure Renegotiation

Secure Renegotiation stellt sicher, dass keine Überlastung möglich ist, wenn ein Client ständig neue Schlüssel anfordert. Anfragen werden dann geblockt und eine DDos-Attacke verhindert.

Lokales Aussteller-Zertifikat nicht verfügbar

Nicht unterstützter Zertifikatszweck

Öffentlicher Schlüssel nicht dekodierbar

Der öffentliche Schlüssel (public key) dient dazu, einen sicheren Schlüsselaustausch zu ermöglichen. Er sollte daher dekodierbar sein.

Pfadlängenbeschränkung überschritten

Schwacher Diffie-Hellman Parameter

Ein schwacher Diffie-Hellman Parameter macht die den Schlüsseltausch anfällig für Attacken.

Selbstsigniertes Zertifikat

Selbst signierte Zertifikate sind nicht in der Lage die Authentizität zu bestätigen und daher nicht zu empfehlen.

Selbstsigniertes Zertifikat in der Zertifikatskette

Selbst signierte Zertifikate sind nicht in der Lage die Authentizität zu bestätigen und daher nicht zu empfehlen.

Ungültige CRL (Certificate Revokation List)

Die verwendete Zertifikatsperrliste ist ungültig.

Ungültige CRL (Certificate Revokation List) signature

Ungültige Zertifikatssignatur

Ungültiger Hostname

Das Zertifikat enthält nicht den Hostnamen des Zielsystems.

Ungültiges Ablaufdatum des Zertifikats

Das Ablaufdatum des verwendeten Zertifikats ist nicht korrekt.

Ungültiges CA-Zertifikat

Das von der Zertifizierungsstelle (Certificate Authority) ausgegebene Zertifikat ist ungültig.

Ungültiges Zertifikat

Ungültigen Zertifikaten wurde das Vertrauen entzogen. Sie sollten nicht mehr verwendet werden.

Unsicheres SSL/TLS Protokoll

Es sollten nur sichere Protokolle zur Verschlüsselung angeboten werden.

Unterstützt anonyme Chiffren

Anonyme Chiffren sind unsicher und sollten nicht verwendet werden.

Unterstützt für Poodle-Attacken anfällige Chiffren

Poodle-Attacken nutzen eine Sicherheitslücke in SSL 3.0, sodass verschlüsselte Informationen einer SSL 3.0 Verbindung offen gelegt werden können.

Unterstützt gefährdete Chiffren

Chiffren, die unsichere kryptographischer Verfahren beinhalten, sollten nicht angeboten werden.

Unterstützt nicht das neuste Protokoll (TLSv1.3)

Das neuste und sicherste Protokoll TLSv1.3 wird nicht unterstützt.

Unterstützt Null-Chiffren-Verschlüsselung

Eine Null-Chiffre bedeutet, es wird gar keine Verschlüsselung verwendet. Dies ist jenseits von Testzwecken niemals zu empfehlen.

Unterstützt RC4 Chiffren

RC4 gilt nicht mehr als ausreichend sicher und sollte daher nicht verwendet werden.

Unterstützt schwache Protokolle

Schwache, veraltete Protokolle gefährden die Sicherheit der SSL/TLS-Verbindung.

Unterstützt schwache SSL/TLS Chiffre (Algorithmus)

SSL/TLS-Chiffren legen fest, mit welchen Verschlüsselungsalgorithmen Schlüssel getauscht werden und wie die Kommunikation abgesichert wird. Werden unsichere SSL/TLS-Chiffren angeboten, ist die hergestellte Verbindung nicht mehr sicher.

Unterstützt schwache SSL/TLS Chiffre (Parameter)

SSL/TLS-Chiffren legen fest, mit welchen Verschlüsselungsalgorithmen Schlüssel getauscht werden und wie die Kommunikation abgesichert wird. Werden unsichere SSL/TLS-Chiffren angeboten, ist die hergestellte Verbindung nicht mehr sicher.

Unterstützt SSL/TLS Kompression

Von der Verwendung der Kompression wird abgeraten, da sie SSL/TLS angreifbar macht (insbesondere für CRIME, Compression Ratio Info-leak Made Easy).

Verwendet bekannte Diffie-Hellman Primzahl

Die Verwendung einer unsicheren Diffie-Hellman Primzahl gefährdet die Verschlüsselung.

Zertifikat abgelehnt

Das verwendete Zertifikat verursacht Probleme und wird daher abgelehnt.

Zertifikat CRL nicht erreichbar

Zertifikat ist nicht vertrauenswürdig

Das verwendete Zertifikat wird als nicht vertrauenswürdig angesehen.

Zertifikat widerrufen

Das verwendete Zertifikat wurde widerrufen und sollte nicht mehr verwendet warden.

Zertifikatskette zu lang

Zertifikatssignatur nicht entschlüsselbar

Die Signatur eines Zertifikats ermöglicht es einem Dritten die Identität des Zertifikatsbesitzers zu bestätigen. Sie sollte daher lesbar sein.

Telnet

Titel

Beschreibung

Keine Authentifizierung erforderlich

Telnet ist aufgrund seiner fehlenden Verschlüsselung nicht mehr zeitgemäß und sollte möglichst nicht mehr verwendet werden. Solltest du Telnet dennoch einsetzen, muss in jedem Fall eine Authenfizierungs-Methode genutzt werden.

Standardbenutzer mit Adminrechten

Ein Standardbenutzer sollte aus Sicherheitsgründen über keine Adminstrationsrechte verfügen.

Sicherheit der Verarbeitung: Artikel 32 DSGVO umsetzen

Datenschutz-Audit:  Wissen, wo mein Unternehmen steht.

In 4 Schritten zum Ergebnis

Vorbereitung

1. Vorbereitung

Ziel und Umfang des Audits werden festgelegt, Mitwirkende bestimmt, Terminabsprachen durchgeführt und die Informationen an alle Beteiligten gesendet. 

Dokumentenprüfung

2. Prüfung von Dokumenten 

Prüfen, welche Dokumente und Prozessbeschreibungen vorhanden sind. Inwieweit entsprechen diese den Anforderungen? 

Prüfung Remote oder vor Ort

3. Prüfung vor Ort / Remote

Interviews und Aufnahme des aktuellen Zustandes vor Ort oder Remote. Prüfung von Prozessen, der Umsetzung von Maßnahmen und Nachweisen. 

Bericht

4. Audit-Bericht / Gespräch 

Die Ergebnisse des Audits sind in einem Bericht zusammengefasst. Unser Plus: Der Bericht enthält Handlungsempfehlungen und Prioritäten für die Planung, Abarbeitung und letztlich Risikominimierung. 

t

FAQ - Fragen und Antworten

Was ist ein Datenschutz-Audit?
Audit kommt von Anhören. Im Grunde besteht ein Datenschutz-Audit aus Abfragen, Anhören, Beobachten, Vergleichen, Sammeln, Strukturieren und Aufschreiben des Beobachteten. AGIDAT untersucht ob Prozesse, Anforderungen und Richtlinien der DSGVO, sowie interne Complience Vorgaben Ihres Unternehmens erfüllt sind.
Wer braucht ein Datenschutz-Audit?

Wer wissen möchte, wie der Stand zum Datenschutz im Unternehmen ist, braucht ein Datenschutz-Audit. Gründe für die Durchführung eines Datenschutz-Audits liegen meist in dem Wunsch zu wissen, ob gesetzliche oder selbst gegebene Vorgaben eingehalten werden.

Die Datenschutz-Grundverordnung nennt auch die Rechenschaftsplicht. Somit muss jeder Unternehmer wissen und auch belegen können, dass entsprechende Maßnahmen ergriffen wurden, um die gesetzlichen Vorgaben zu erfüllen.

Wie läuft ein Datenschutz-Audit ab?
Datenschutz-Audits laufen grundsätzlich immer nach dem gleichen Schema ab.

  • Vorbereitung
  • Prüfung von Dokumenten
  • Prüfung vor Ort / Remote
  • Audit Bericht / Gespräch

In der Vorbereitung werden zuerst Ziel und Umfang des Audits festgelegt. Ziele und Umfang des Audits richten sich nach dem Grund sowie der Größe und Art Ihres Unternehmens.

Was ist das Ergebnis eines Datenschutz-Audits?

Ein Auditbericht. In diesem stehen die Einzelergebnisse in Bezug auf das Audit-Ziel, der auditierten Standorte, Bereiche und Themen. Das Ergebnis des Datenschutz-Audits erhalten Sie in Form eines Audit Berichtes. In ihm werden protokollarisch Inhalt, Fortgang und Ergebnis des Audits dokumentiert.

Wie viel kostet ein Datenschutz-Audit?

Die Kosten hängen maßgeblich von Ziel, Umfang und Tiefe des Datenschutz-Audits ab.
AGIDAT hat vordefinierte Audit-Pakete, die vielleicht auch Ihren Bedürfnissen entsprechen. Senden Sie uns eine Anfrage und wir besprechen gemeinsam, welches Audit-Paket für Sie am besten passt.
Die Kostenspanne reicht von 250 Euro für ein Selbstbefragungs-Audit bis hin zu mehreren Tausend Euro für mehrere Tage dauernde Audits.

Wie lange dauert ein Datenschutz-Audit?

Die Dauer eines Datenschutz-Audits kann sich von 2 Stunden für ein Selbstbefragungs-Audit bis über mehrere Tage strecken und hängt maßgeblich von Ziel, Umfang und Tiefe des Datenschutz-Audits ab.

Hinzuzkommen die Zeiten für die Vorbereitung und Nachbereitung des Datenschutz-Audits, so dass die Zeitspanne von der Beauftragung bis zum Erhalt des Berichtes von einem Tag bei den Selbstbefragungs-Audits bis hin zu 4 – 6 Wochen betragen kann.

Wie schnell kann ein Datenschutz-Audit durchgeführt werden?
Ein einfaches Datenschutz-Audit auf Basis von Selbstbefragung kann an einem Tag abgeschlossen sein. Komplexe Audits, bei denen am Anfang noch die Findung von Ziel, Umfang und Tiefe steht, benötigen unter guten Voraussetzungen mindestens eine Woche von der Beauftragung bis zum Versenden des Berichtes.
Wer sollte ein Datenschutz-Audit durchführen?

Jeder mit dem entsprechenden Wissen und Kompetenzen kann ein Audit durchführen. Es spricht nichts dagegen, wenn in einem Unternehmen interne Audits selbst durchgeführt werden. Da der DSB auch eine Überwachungsaufgabe für die Durchführung nach DSGVO hat, sollte zumindestens in größeren Unternehmen der DSB das Audit nicht selbst durchführen.
Ein externes Datenschutz-Audit hat unter anderem den Vorteil der Unabhängigkeit und Neutralität und wird von Kunden, Partnern und Lieferanten häufig gefordert.