Asset Discovery und automatisierte Pentests auf neuem Level

Asset Discovery: Watchdog 3.0

Das beste IT-Security-Konzept taugt nichts, wenn kein Inventar aller Assets vorhanden ist, auf die es angewendet werden soll. Eine Übersicht über alle Assets durch eine Asset Discovery ist daher elementar. Sie bildet die Grundlage jeglicher Maßnahme zur Steigerung des Sicherheits-Niveaus.

Permanente Überwachung

Mit dem Watchdog 3.0 stellen wir den Modus der Asset Discovery auf eine permanente Überwachung um. Der neue Watchdog untersucht dauerhaft den Netzwerktraffic nach neuen Assets und sendet alle fünf Minuten seine Ergebnisse an die Enginsight Plattform. Um alle Assets zu erfassen, startet Watchdog in regelmäßigen Abständen einen aktiven Netzwerkscan. Mit einem Funkfeuer (Pings, Port-Scans etc.) provoziert der Watchdog Traffic und findet so auch Assets, die von sich aus keinen Traffic erzeugt haben. Wie häufig ein aktiver Netzwerkscan durchgeführt wird, legen Sie fest.

Sie erhalten einen Wachhund, der niemals schläft und Ihr Inventar ist immer auf dem aktuellen Stand. Wie lange vom Watchdog aufgespürte Assets im Inventar verbleiben, liegt ganz bei Ihnen. Sie können die Assets dauerhaft speichern oder eine aktive Inventarbereinigung durchführen. Das heißt, Sie können eine Anzahl an Tagen festlegen, nach der die Einträge aus dem Inventar gelöscht werden, sollte ein Asset in dieser Zeit nicht mehr erreichbar gewesen sein. Wollen Sie alle Inventareinträge eines Watchdogs löschen, steht Ihnen in den jeweiligen Watchdog-Einstellungen die Option „Inventar bereinigen“ zu Verfügung.

Aktivieren Sie bei Ihren bestehenden Watchdogs einfach die permanente Überwachung und Sie erhalten ein stets aktuelles Inventar. Nicht vergessen: Auf die gefundenen Assets können Sie mit wenigen Klicks eine Überwachung auf Verfügbarkeit und Gesundheitszustand hinzufügen. Nutzen Sie dafür die Möglichkeit von Ping- wie Portmonitoring und SNMP.

Über Subnetze hinweg scannen

Wie viele Watchdogs Sie in Ihrem Unternehmensnetzwerk platzieren, ist ihre eigene Entscheidung. Bisher hatte ein Watchdog immer Zugriff auf das entsprechende Netzsegment, in dem er sich befunden hat. Indem Sie den Watchdog entsprechend im Netzwerk platzieren und in Enginsight die Subnetze eintragen, können Sie nun auch über das einzelne Segment hinaus eine Asset Discovery durchführen.

Asset Map

Alle vom Watchdog gefundenen Assets finden Sie als unter „Inventar“ als Liste. Sollten Sie eine grafische Darstellung bevorzugen, können Sie sich die Assets auch in der Asset Map anzeigen lassen. Vergeben Sie für die Subnetze unterschiedliche Farben und erhalten Sie eine intuitive Übersicht über Ihre IT-Infrastruktur.

Automatisierte Pentests

Mit unserer Pentest-Komponente Hacktor können Sie ganze Netzwerksegmente einen Härtetest unterziehen. Dabei geht Enginsight in drei Schritten vor:

1. Mit einer erweiterten Bruteforce-Attacke versucht Hacktor durch das Ausprobieren von Benutzernamen/Passwort-Kombinationen in die Systeme einzudringen.
2. Der CVE-Scan prüft die Systeme auf Sicherheitslücken und validiert diese.
3. Schließlich wird in der Discovery auf falsche Konfigurationen getestet.

Eine Übersicht über alle Tests, Attacken und unterstützten Services erhalten Sie in der Dokumentation.

Hacktor 3.0

Unter der Haube haben wir unserer Pentest-Komponente Hacktor eine Frischzellenkur verpasst. Wir haben die Stabilität auf ein neues Niveau gehoben und Vorbereitungen getroffen, um die Funktionalität in Zukunft weiter auszubauen.

Die Version Ihres Hacktors müssen Sie stets auf dem neusten Stand halten, damit Sie eine Asset Penetration durchführen können. Updaten Sie also unmittelbar alle Ihre Hacktoren.

Validated CVEs

Der netzwerkseitige Flächenscan nach Sicherheitslücken (CVEs) ist ein Teil unserer Pentest-Komponente Hacktor. Die Ergebnisse des CVE-Scans sind nun aussagekräftiger.

Wird das Betriebssystem erkannt, prüft Enginsight, ob die vorgefundenen Sicherheitslücken (CVEs) bei dem entsprechenden Betriebssystem wirksam wird. Das heißt, es besteht eine Möglichkeit, die Sicherheitslücke auszunutzen. Ist dies der Fall, kennzeichnen wir die gefundenen CVEs als „validated“. Kann das Betriebssystem nicht zweifelsfrei erkannt werden, fügen wir dem Eintrag den Hinweis „invalidated“ hinzu. Hier muss der Nutzer selbst nachprüfen, ob die Sicherheitslücke bei diesem System wirksam ist. So erhalten Sie einen aussagekräftigen Indikator, ob es sich um einen False Positive handeln könnte.

CVE Score Ausgabe in Audit Reports und PDF-Berichten

Der CVE-Score von aufgedeckten Sicherheitslücken wird nun direkt im Audit Report sowie den PDF-Berichten angezeigt.

Enumeration

Mit „Enumeration“ ist eine neue Test-Kategorie zu unserem Pentest hinzugekommen. Hier sammelt Hacktor alle Informationen, die auch Hacker mit schlechten Absichten in massenhaften Scans sammeln, um mögliche Einstiegspunkte zu finden. Dabei werden Systeme und ihre geöffneten Ports gezielt angesprochen.

Hacktor prüft im Rahmen der Enumeration die Ports

• auf veraltete Softwareversionen der Dienste, welche die Ports geöffnet haben („Exposed Software Version“).

• ob ein Dienst vorhanden ist, über den eine Fernwartung durchgeführt werden kann („Exposed Remote Control Service“).

In Kürze werden weitere Prüfszenarien für Ports hinzukommen, etwa ob sie unnötig geöffnet sind oder auf offene Windows-Netzwerkshares.

Des Weiteren wird im Rahmen der Enumeration-Phase das Domain Name System (DNS) analysiert.

Domain Name System (DNS)

Das Domain Name System (DNS) dient dazu, einer Domain die passende IP-Adresse zuzuordnen. Es fungiert dabei wie eine Telefonauskunft. Der Dienst ist damit einer der wichtigsten Bausteine des Internets. Trotzdem besitzt er große Schwachstellen, die sich Hacker zu Nutze machen können, um Man-in-the-middle-Attacken auszuführen. Nachhaltigen Schutz gegen Angriffe kann aber die Implementierung der Domain Name System Security Extensions (DNSSEC) geben.

Hacktor prüft daher auf eine valide DNS-Zertifizierung und ob die wichtigen DNSSEC-Maßnahmen ergriffen wurden. Im Detail testet er:

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

Missing Contact Address for DNS CAA: Für die Certification Authority Authorization (CAA), die das Zertifikat für die Domain ausgestellt hat, ist keine Kontaktadresse angegeben.

Invalid Contact Address for DNS CAA: Die angegebene E-Mail-Adresse der Zertifizierungsstelle entspricht nicht dem gültigen E-Mail-Format (abc@xyz.com).

Uncommon Certification Authority: Die Certification Authority Authorization (CAA), die das Zertifikat für die Domain ausgestellt hat, ist ungewöhnlich.

Missing SPF record: Das Sender Policy Framework (kurz SPF) ist eine Methode, die das Fälschen des Absenders einer E-Mail erschweren soll. Dazu wird überprüft, ob der Server des Absenders über die Rechte für den E-Mail-Versand verfügt.

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

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

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

Missing 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.
Missing RRSIG record RRSIG Records werden im Rahmen von DNSSEC verwendet. Sie enthalten die Signatur eines DNS-Resource-Record-Sets.

Missing DS 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.
Missing 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.

Missing 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.

Missing CDNSKEY record: CDNSKEY records werden im Rahmen von DNSSEC verwendet. Sie sind nützlich, wenn Veränderungen an DNSKEYs vorgenommen werden.
Missing CDS record CDS records werden im Rahmen von DNSSEC verwendet. Sie sind nützlich, wenn Veränderungen an DNSKEYs vorgenommen werden.

Neue Checks für HTTP-Header

Hacktor hat bereits die korrekte Konfiguration vieler http-Header geprüft. Mit der neuen Version kommen zwei neue hinzu:

X-Mod-Pagespeed und X-Powered-By: Der X-Mod-Pagespeed und X-Powered-By Header sollten aus Sicherheitsgründen entfernt werden. Die Ausgabe dieser Informationen über das System ist in der Regel nicht notwendig und gibt Hackern Informationen preis, die sie für Angriffe nutzen können.

Neue Tests der SSL/TLS-Verschlüsselung

Die Verschlüsselung via SSL/TLS wird nun durch zwei weitere Checks geprüft:

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

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

Neuer Status: Filtered

Sollte der Versuch einer Asset Penetration durch eine Firewall geblockt werden, erhält das Target beziehungsweise der Audit Report nun den Status „filtered“.

Searchbar in War Room

Die bereits an vielen Punkten in der Plattform eingeführte Searchbar haben wir in die Audit Reports integriert. So haben sie weiterhin die Möglichkeit die Ergebnisse nach Status, Port, Kategorie, Dringlichkeit, Beschreibung und Bereich zu filtern. Darüber hinaus können Sie jedoch auch per Custom Search die Ergebnisse mit Freitext durchsuchen.

Übersicht aller generierten Berichte

Unter Berichte erhalten Sie nun alle von Ihnen erstellten PDF-Reports von durchgeführten Pentests in einer gemeinsamen Übersicht.

Zeitzonen für geplante Plugins

Plugins helfen Ihnen dabei die Automatisierung in der Administration Ihrer IT voranzutreiben. Sie eröffnen unendliche Möglichkeiten, um Sie von Routineaufgaben zu entlasten. Plugins lassen sich entweder als Reaktion auf ein Systemereignis ausführen oder regelmäßig zu einem bestimmten Zeitpunkt via Cronjob.

Für die geplante Ausführung lässt sich nun die gewünschte Zeitzone auswählen. Das ermöglicht Ihnen eine stets genaue Terminierung ihrer Plugins.

Installation des Pulsar Agent

Der Installationsprozess des Pulsar Agent ist jetzt unter Linux in der Konsole besser verständlich.

Mit „No Proxy“ ist eine neue Installer Option dazugekommen. Sie ermöglicht individuelle Proxyeinstellungen für den Agent, ohne die Proxyeinstellungen des Hosts anpassen zu müssen. Relevant ist diese Option z.B. in Fällen, in denen Sie Enginsight OnPremises nutzen und die IP-Adressen der Instanz nicht überall in der NO_PROXY Konfiguration des Betriebssystems hinterlegen können. IP-Ranges oder Wildcards werden bei der nicht akzeptiert.