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.
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.
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. |
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. |
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.
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
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.
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.
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. |
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. |
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. |
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. |
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. |
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. |
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.
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. |
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. |
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. |
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
1. Vorbereitung
Ziel und Umfang des Audits werden festgelegt, Mitwirkende bestimmt, Terminabsprachen durchgeführt und die Informationen an alle Beteiligten gesendet.
2. Prüfung von Dokumenten
Prüfen, welche Dokumente und Prozessbeschreibungen vorhanden sind. Inwieweit entsprechen diese den Anforderungen?
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.
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.
FAQ - Fragen und Antworten
Was ist ein Datenschutz-Audit?
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?
- 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?
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.