Software Vulnerability Tool
Werbung
Software Vulnerability Tool Entwicklung einer Anwendung zur Analyse des CVE-Verzeichnisses Vergleichende Analyse der Standards CVE, CPE, CVSS und CWE Developement of an application for analyzing the CVE-dictionary Comparative analysis of the standards CVE, CPE, CVSS and CWE Matthias Scherf Bachelor-Abschlussarbeit Betreuer: Prof. Dr. Konstantin Knorr Trier, 15.12.2015 II Kurzfassung Im Rahmen dieser Arbeit wurde analysiert, ob die von den Standards CVE, CVSS, CWE und CPE bereitgestellten Informationen eine ausreichende Quantität und Qualität besitzen, um als Informationsbasis für eine Sicherheitsanalyse zu dienen. Um diese Überprüfung durchzuführen wurde eine 90 tägige Testphase definiert. In diesem Zeitraum sind 26 unterschiedliche und kostenlos erhältliche Softwareprodukte regelmäßig auf ihre Angreifbarkeit mit Hilfe der Sicherheitsanalyseanwendung Secunia PSI untersucht und aufgetretene Warnungen dokumentiert worden. Die detaillierten Informationen zu den aufgetretenen Warnungen, wie beispielsweise die zugeordneten CVE-IDs, sind auf der SecuniaWebseite hinterlegt und wurden ebenfalls herausgesucht und festgehalten. Während der Testphase wurde zeitgleich eine Anwendung namens Software-VulnerabilityTool entwickelt und implementiert. Diese importiert die öffentlich verfügbaren CVE- und CPE-Verzeichnisse in eine SQLite-Datenbank und stellt Funktionen zur Erzeugung von Statistiken und zur Durchsuchung der Datenbank bereit. Die entwickelte Anwendung bietet zusätzlich die Möglichkeit zur Erstellung eines CPE-Profils. Anhand dieses Profils kann das Software-Vulnerability-Tool die Datenbank nach zutreffenden CVE-Einträgen durchsuchen. Nachdem die Testphase endete, wurden mit dem Software-Vulnerability-Tool alle in der Datenbank vorhandenen CVE-Einträge, die den 26 Testanwendungen zugeordnet sind, gesucht und dokumentiert. Im Vergleich der Ergebnisse des Software-Vulnerability-Tools und des Secunis PSI wird deutlich, dass die von Standards CVE, CVSS, CWE und CPE bereitgestellten Informationen die notwendige Quantität und Qualität besitzen, um als Grundlage für die Entwicklung von Sicherheitsanalyseanwendungen zu dienen. So ist die Anzahl der mit der entwickelten Anwendung gefundenen CVEs höher als die von Secunia. Der Test zeigte jedoch auch, dass das Zusammenspiel der einzelnen Standards Raum für Verbesserungen bietet. Vor allem im Zusammenspiel von CVE und CPE sind viele Probleme festgestellt worden. Secunia PSI weist ebenfalls einige Probleme auf. So wurden bei Secunia falsch zugeordnete CVE-IDs und inkonsistente Bewertungen registriert. Trotz der Problematiken im Zusammenspiel der Standards ist es sinnvoll, das CVEVerzeichnis als Informationsgrundlage für Sicherheitsanwendungen bevorzugt in Betracht zu ziehen, da der CVE-Standard von vielen Herstellern genutzt wird, um ihre Sicherheitslücken eindeutig zu benennen. Dadurch bietet das öffentlich verfügbare CVE-Verzeichnis zurzeit eine der besten Möglichkeiten, kostenlos auf zuverlässige und gut strukturierte Informationen zu Sicherheitslücken zuzugreifen. III Inhaltsverzeichnis 1 Einleitung und Problemstellung ................................................................. 1 1.1 1.2 2 Standards....................................................................................................... 4 2.1 2.2 2.3 2.4 2.5 3 Common Vulnerabilities and Exposures ................................................................. 4 2.1.1 Allgemein .................................................................................................... 4 2.1.2 Unterscheidung Vulnerability und Exposure .............................................. 4 2.1.3 Aufbau ......................................................................................................... 5 2.1.4 Rollen und Aufgaben .................................................................................. 6 2.1.5 Erstellung von CVE Identifiers ................................................................... 7 Common Vulnerability Scoring System.................................................................. 7 2.2.1 Allgemein .................................................................................................... 7 2.2.2 Metriken ...................................................................................................... 8 2.2.3 Berechnung der CVSS Punktzahl ............................................................. 11 2.2.4 CVSS Vector-String .................................................................................. 15 Common Weakness Enumeration ......................................................................... 16 2.3.1 Allgemein .................................................................................................. 16 2.3.2 Unterscheidung Softwareschwachstellen und Softwarelücken ................. 16 2.3.3 Aufbau ....................................................................................................... 16 2.3.4 Entwicklung .............................................................................................. 19 Common Platform Enumeration ........................................................................... 19 2.4.1 Allgemein .................................................................................................. 19 2.4.2 Namensformatierung ................................................................................. 20 Zusammenhang der Standards............................................................................... 21 Testphase ..................................................................................................... 23 3.1 3.2 3.3 4 Zielsetzung .............................................................................................................. 1 Gliederung der Arbeit .............................................................................................. 2 Allgemein .............................................................................................................. 23 Definition der Testparameter................................................................................. 23 3.2.1 Softwareprofil ........................................................................................... 23 3.2.2 Zeitraum .................................................................................................... 27 3.2.3 Vergleichsprodukt ..................................................................................... 27 Ablauf der Testphase ............................................................................................. 30 Software-Vulnerability-Tool ..................................................................... 32 4.1 4.2 4.3 Ziel......................................................................................................................... 32 Anforderungen....................................................................................................... 33 Planung .................................................................................................................. 35 4.3.1 Datenbanktyp und Datenbankschema ....................................................... 35 IV 4.4 5 Ergebnisse ................................................................................................... 44 5.1 5.2 5.3 5.4 5.5 6 Ergebnisse des Secunia PSI................................................................................... 44 Ergebnisse des CVE-Tools .................................................................................... 47 Vergleich der beiden Ergebnisse ........................................................................... 54 5.3.1 Detaillierter Vergleich einzelner Softwareanwendungen ......................... 56 Allgemeine Statistiken zum gespeicherten CVE-Verzeichnis .............................. 61 Interpretation der Ergebnisse................................................................................. 64 Diskussion .................................................................................................... 65 6.1 6.2 6.3 6.4 6.5 6.6 7 4.3.2 CVE-Import-Tool – 1. Ausbaustufe.......................................................... 36 4.3.3 CVE-Research-Tool – 2. Ausbaustufe ...................................................... 38 4.3.4 Software-Vulnerability-Tool – 3. Ausbaustufe ......................................... 40 Entwicklung........................................................................................................... 43 Verwandte Arbeiten .............................................................................................. 65 6.1.1 vFeed ......................................................................................................... 65 6.1.2 CVE und CVSS ......................................................................................... 65 6.1.3 Reviewing the Secunia 2013 Vulnerability Review ................................. 66 6.1.4 Vulnerability management tools for COTS software - A comparison ...... 66 Feedback zu den Standards ................................................................................... 67 6.2.1 Feedback zu CVE...................................................................................... 67 6.2.2 Feedback zu CVSS.................................................................................... 69 6.2.3 Feedback zu CWE ..................................................................................... 69 6.2.4 Feedback zu CPE ...................................................................................... 70 Feedback zu Secunia ............................................................................................. 74 Feedback zur Implementierung des Tools............................................................. 76 6.4.1 Hinweise zur Verarbeitung des CVE-Verzeichnisses ............................... 76 6.4.2 Anmerkung zu Erstellung der Datenbankschemas ................................... 79 Feedback zur Testphase......................................................................................... 79 Erweiterungsmöglichkeiten ................................................................................... 79 6.6.1 Software zur Einstufung der Angreifbarkeit eines Systems ..................... 79 6.6.2 Nutzung eines Datenbankservers .............................................................. 80 6.6.3 Nutzung einer Host-Client Struktur .......................................................... 81 6.6.4 Definition des Temporal Scores und Environmental Scores .................... 82 6.6.5 Durchführung einer Testphase auf Basis anderer Testparameter ............. 82 Fazit.............................................................................................................. 83 Erklärung des Kandidaten ............................................................................... 88 9 Anhang......................................................................................................... 89 9.1 9.2 9.3 Detaillierte Informationen zu Ergebnissen von Secunia PSI ................................ 89 Lastenheft für das Software-Vulnerability-Tool ................................................... 97 9.2.1 Einleitung .................................................................................................. 97 9.2.2 Ziele .......................................................................................................... 97 9.2.3 Anforderungen .......................................................................................... 98 E-Mail-Korrespondenzen .................................................................................... 108 V Abbildungsverzeichnis Abbildung 1, Kapitelzuordnungsdiagramm ....................................................................... 2 Abbildung 2, Detailansicht des Kapitelzuordnungsdiagramms ......................................... 3 Abbildung 3, Vorgehen bei Bestimmung des CVSS-Score ............................................. 13 Abbildung 4, Beispiel für die Berechnung des Base-Score ............................................. 14 Abbildung 5, Beispiel für die Berechnung des Temporal-Score ..................................... 14 Abbildung 6, Beispiel für die Berechnung des Environmental-Score ............................. 15 Abbildung 7, Beispiel für grafische Darstellung einer CWE Liste ................................. 17 Abbildung 8, Beispiel für einen CWE Eintrag ................................................................ 18 Abbildung 9, Zusammenhang der Standards ................................................................... 22 Abbildung 10, Darstellung der Funktionsweise des Softwareprofils ............................... 23 Abbildung 11, Darstellung des Zeitraums der Testphase ................................................ 27 Abbildung 12, Darstellung des Ziels des Software-Vulnerability-Tools ......................... 32 Abbildung 13, Darstellung der verschiedenen Ausbaustufen .......................................... 35 Abbildung 14, Datenbankschema der SQLite Datenbank ............................................... 36 Abbildung 15, Darstellung der Funktionsweise des CVE-Import-Tools ......................... 36 Abbildung 16, Startbildschirm des CVE-Import-Tools ................................................... 37 Abbildung 17, Einstellungen des CVE-Import-Tools ...................................................... 37 Abbildung 18, Importvorgang des CVE-Import-Tools .................................................... 37 Abbildung 19, Darstellung der Funktionsweise des CVE-Research-Tools ..................... 38 Abbildung 20, Startbildschirm des CVE-Research-Tools ............................................... 39 Abbildung 21, Profilerstellung und –bearbeitung im CVE-Research-Tool ..................... 39 Abbildung 22, Detailansicht eines CVE-Eintrags im CVE-Research-Tool ..................... 40 Abbildung 23, Darstellung der Daten des Software-Vulnerability-Tools........................ 41 Abbildung 24, Startbildschirm des Software-Vulnerability-Tools .................................. 41 Abbildung 25, Überarbeitete Einstellungen des Software-Vulnerability-Tools .............. 42 Abbildung 26, Ansicht der inkonsistenten CVEs im Software-Vulnerability-Tool ........ 42 Abbildung 27, Detaillierte Informationen zur Warnung bezüglich .NET-Frameworks .. 45 Abbildung 28, Detaillierte Informationen zur Warnung bezüglich Windows 7 ............. 45 Abbildung 29, Detaillierte Informationen zur Warnung bezüglich Acrobat Reader ....... 46 Abbildung 30, Anteil der unterschiedlichen CPEs........................................................... 61 Abbildung 31, Balkendiagramm der pro Jahr veröffentlichten CVE-Einträge ................ 62 Abbildung 32, Balkendiagramm zu Verteilung des CVSS-Base-Scores ......................... 62 Abbildung 33, Veranschaulichung des Problems der inkonsistenten CVE-Einträge ...... 67 Abbildung 34, Ausschnitt der CPEs der CVE-2015-8480 von NVD-Webseite .............. 68 Abbildung 35, Ausschnitt der CPEs der CVE-2015-8480 aus der XML-Datei............... 68 Abbildung 36, Detailansicht der CVE-2015-8480 im Software-Vulnerability-Tool ....... 69 Abbildung 37, Beispiel für die Baumstruktur des CWE-Verzeichnis ............................. 70 Abbildung 38, Zusammenfassungsproblem unterschiedlicher Versionen zu einer CPE . 71 Abbildung 39, Ausschnitt einer Secunia PSI-Bewertung von einer Warnung ................ 75 Abbildung 40, Ausschnitt der Secunia-Webseite zur Bewertung einer Warnung ........... 75 VI Abbildung 41, Fehlermeldung bei Ausführung der entwickelten Tools .......................... 76 Abbildung 42, Eine reservierte CVE-ID im CVE-Verzeichnis ....................................... 77 Abbildung 43, „Null“-CPE in CVE-2014-4389 im CVE-Verzeichnis ............................ 77 Abbildung 44, CPE-Angabe in beiden XML-Tags identisch .......................................... 77 Abbildung 45, CPE-Angabe nur in XML-Tag „vulnerability-configuration“ ................. 78 Abbildung 46, CPEs in mehrere XML-Tags „vulnerability-configuration“ verteilt ....... 78 Abbildung 47, Erweiterungsmöglichkeit zur Angreifbarkeitseinstufung eines Systems . 80 Abbildung 48, Nutzung eines Datenbankservers anstelle lokaler SQLite-Datenbanken . 80 Abbildung 49, Erweiterungsmöglichkeit zur Einstufung mehrerer Rechner ................... 81 Abbildung 50, Datenbankstruktur zur Speicherung aller CVSS-Metriken ...................... 82 Abbildung 51, Detaillierte Informationen zur Warnung (Mozilla Firefox) ..................... 89 Abbildung 52, Detaillierte Informationen zur Warnung (.NET-Framework) .................. 89 Abbildung 53, Detaillierte Informationen zur Warnung (Internet Explorer) ................... 90 Abbildung 54, Detaillierte Informationen zur Warnung (Windows 7) ............................ 90 Abbildung 55, Detaillierte Informationen zur Warnung (Apple iTunes)......................... 91 Abbildung 56, Detaillierte Informationen zur Warnung (Acrobat Reader) ..................... 92 Abbildung 57, Detaillierte Informationen zur Warnung (Mozilla Firefox) ..................... 92 Abbildung 58, Detaillierte Informationen zur Warnung (JRE)........................................ 93 Abbildung 59, Detaillierte Informationen zur Warnung (Apple iTunes)......................... 93 Abbildung 60, Detaillierte Informationen zur Warnung (Apache OpenOffice) .............. 94 Abbildung 61, Detaillierte Informationen zur Warnung (PuTTY) .................................. 94 Abbildung 62, Detaillierte Informationen zur Warnung (Google Chrome)..................... 95 Abbildung 63, Detaillierte Informationen zur Warnung (Adobe Flash Players) ............. 95 Abbildung 64, Detaillierte Informationen zur Warnung (Windows 7) ............................ 96 Abbildung 65, Ausschnitt des Eintrags CVE-2015-8480 aus der NVD-Webseite ........ 109 VII Tabellenverzeichnis Tabelle 1, Metriken der Base Metric Group ...................................................................... 9 Tabelle 2, Metriken der Temporal Metric Group ............................................................. 10 Tabelle 3, Metriken der Environmental Metric Group .................................................... 11 Tabelle 4, Übersicht aller CVSS Metriken inklusive der numerischen Werte................. 12 Tabelle 5, Erläuterung der Eigenschaften des URI Bindings........................................... 20 Tabelle 6, Zusätzliche Eigenschaften des Formatted String Bindings ............................. 21 Tabelle 7, Zusammenfassung der Standards .................................................................... 22 Tabelle 8, Softwareprofil, welches als Grundlage für die Überprüfung dient ................. 25 Tabelle 9, Fünf Top-Downloadlisten ............................................................................... 26 Tabelle 10, Vergleichsmatrix der drei potentiellen Softwareanwendungen .................... 29 Tabelle 11, Angabe der installierten Version der Anwendungen des Softwareprofils .... 31 Tabelle 12, Von Secunia PSI gemeldete Sicherheitswarnungen...................................... 44 Tabelle 13, Gefundene Sicherheitslücken zum Softwareprofil, Teil 1 ............................ 47 Tabelle 14, Gefundene Sicherheitslücken zum Softwareprofil, Teil 2 ............................ 48 Tabelle 15, Übersicht über CVE-Ergebnisse des .NET-Frameworks 4.0 ........................ 49 Tabelle 16, Übersicht über CVE-Ergebnisse des .NET-Frameworks 4.5 ........................ 49 Tabelle 17, Übersicht über CVE-Ergebnisse des Adobe Flash Players 18.0.0.232 ......... 50 Tabelle 18, Übersicht über CVE-Ergebnisse des Adobe Flash Players 19.0.0.226 ......... 50 Tabelle 19, Übersicht über CVE-Ergebnisse des Acrobat Readers 2015.008.20082 ...... 50 Tabelle 20, Übersicht über CVE-Ergebnisse von Apache OpenOffice 4.1.1 .................. 51 Tabelle 21, Übersicht über CVE-Ergebnisse von Apple iTunes 12.2.2.25 ...................... 51 Tabelle 22, Übersicht über CVE-Ergebnisse von Apple iTunes 12.3.0.44 ...................... 51 Tabelle 23, Übersicht über CVE-Ergebnisse von Google Chrome 44.0.2403.X ............. 51 Tabelle 24, Übersicht über CVE-Ergebnisse von Google Chrome 45.0.2454.101.......... 51 Tabelle 25, Übersicht über CVE-Ergebnisse von Google Chrome 46.0.2490.80............ 51 Tabelle 26, Übersicht über CVE-Ergebnisse der JRE 1.8.0 Update 51 ........................... 52 Tabelle 27, Übersicht über CVE-Ergebnisse des Microsoft Internet Explorer 11.X ....... 52 Tabelle 28, Übersicht über CVE-Ergebnisse von Mozilla Firefox 40.0.2.X ................... 52 Tabelle 29, Übersicht über CVE-Ergebnisse von Mozilla Firefox 40.0.3.X ................... 52 Tabelle 30, Übersicht über CVE-Ergebnisse von Mozilla Firefox 41.0.1.X ................... 53 Tabelle 31, Übersicht über CVE-Ergebnisse von Mozilla Firefox 41.0.2.X ................... 53 Tabelle 32, Übersicht über CVE-Ergebnisse VLC Players 2.2.1..................................... 53 Tabelle 33, Übersicht über CVE-Ergebnisse Windows 7 ................................................ 53 Tabelle 34, Vergleich der Anzahl der gefundenen CVEs ................................................ 54 Tabelle 35, Vergleich der Ergebnisse .............................................................................. 55 Tabelle 36, Vergleich der Ergebnisse des Adobe Flash Player........................................ 56 Tabelle 37, Vergleich der Ergebnisse des Adobe Acrobat Readers ................................. 57 Tabelle 38, Vergleich der Ergebnisse von OpenOffice.................................................... 57 Tabelle 39, Vergleich der Ergebnisse von iTunes ........................................................... 58 Tabelle 40, Vergleich der Ergebnisse von Google Chrome ............................................. 59 VIII Tabelle 41, Vergleich der Ergebnisse der Java Runtime Environment............................ 59 Tabelle 42, Vergleich der Ergebnisse von Mozilla Firefox ............................................. 60 Tabelle 43, Vergleich der Ergebnisse von Windows 7 ................................................... 61 Tabelle 44, Darstellung der am häufigsten genutzten CWE-IDs ..................................... 63 Tabelle 45, Beispielhafte CPE-Erstellung für iTunes ...................................................... 72 Tabelle 46, Beispielhafte CPE-Erstellung für OpenOffice .............................................. 73 Tabelle 47, Beispielhafte CPE-Erstellung für Silverlight ................................................ 73 IX Abkürzungsverzeichnis API CCE CNA COTS-Software CPE CVE CVSS CWE DHS FIRST GAC HS SEDI ICU JSON MFC NCSD NIAC NIST NVD OS OVAL PLOVER PSI SAMATE SCAP SQL URI USM WFN WPF XML Application Programming Interface Common Configuration Enumeration CVE Numbering Authority Commercial off the shelf-Software Common Platform Enumeration Common Vulnerabilities and Exposures Common Vulnerability Scoring System Common Weakness Enumeration United States Department of Homeland Security Forum of Incident Response and Security Teams Global Assembly Cache Homeland Security Systems Engineering and Development Institute International Components for Unicode JavaScript Object Notation Microsoft Foundation Class National Cyber Security Division National Infrastructure Advisory Council U.S. National Institute of Technology National Vulnerability Database Operating System Open Vulnerability and Assessment Language Preliminary List Of Vulnerability Examples for Researchers Personal Software Inspector Software Assurance Metrics and Tool Evaluation Security Content Automation Protocol Structured Query Language Uniform Resource Identifier Unified Security Management well-formed CPE name Windows Presentation Foundation Extensible Markup Language Einleitung und Problemstellung 1 1 Einleitung und Problemstellung „Experten warnen: Adobe Flash Player sofort abschalten!“(Focus 2015), „Sicherheitslücke in Millionen Android Geräten“ (Kuri 2015). Solche Schlagzeilen über kritische Sicherheitslücken machen immer häufiger die Runde in den Nachrichten. Es vergeht kaum ein Tag, an dem nicht eine neue Sicherheitswarnung für ein Softwareprodukt veröffentlicht wird. Selbst für ITAdministratoren wird es dabei immer schwieriger, die Übersicht über die bekannten Sicherheitslücken zu behalten. Sie müssen einschätzen können, für welche auf den IT-Systemen des Unternehmens eingesetzten Anwendungen der Handlungsbedarf am größten ist, und entsprechend handeln. Diese Beurteilung wird aufgrund der Angreifbarkeit durch veröffentlichte Sicherheitslücken einer Softwareversion bestimmt, denn je gefährlicher eine solche Sicherheitslücke ist, umso dringender ist der Handlungsbedarf seitens eines Administrators. Es existieren verschiedene Tools zur Bestimmung der Angreifbarkeit von bestimmten Softwareversionen. Diese verwenden bei ihrer Bewertung unterschiedlichste Informationen zu den Softwareanwendungen. Eine Möglichkeit, mit der solche Tools sich ihre Informationsgrundlage beschaffen könnten, wäre die Nutzung der Standards Common Vulnerabilities and Exposures (CVE), Common Vulnerability Scoring System (CVSS), Common Weakness Enumeration (CWE) und Common Platform Enumeration (CPE), welche frei verfügbar sind. Diese Bachelor-Abschlussarbeit befasst sich mit den Standards und untersucht, ob und wie diese genutzt werden können, um die Angreifbarkeit von Softwareanwendungen anhand von veröffentlichten Softwaresicherheitslücken zu bestimmen. 1.1 Zielsetzung Ziel dieser Arbeit ist die Beantwortung der Frage, ob die frei verfügbaren Standards CVE, CVSS, CWE und CPE als Informationsgrundlage für die Entwicklung von Sicherheitsanalyseanwendungen dienen können. Um eine möglich realistische Beurteilung bezüglich der Qualität und der Quantität zu ermöglichen, sollen für eine Softwareanwendung zugeordnete CVEs mit den Ergebnissen einer bereits auf dem Markt befindlichen Sicherheitssoftware verglichen werden, um daraus aussagekräftige Rückschlüsse zu gewinnen Ein weiteres Ziel dieser Arbeit ist die Entwicklung und Implementierung einer Softwareanwendung, welche die Informationen des öffentlich verfügbaren CVE-Verzeichnisses in eine Datenbank importiert und es ermöglicht diese anhand unterschiedlicher Kriterien nach CVEEinträgen zu durchsuchen. Die Anwendung ermöglicht es des Weiteren CPE-Profile zu erstellen, zu speichern und die Datenbank anhand des Profils nach Sicherheitslücken zu überprüfen. Zusätzlich können verschiedene Statistiken zu allen gespeicherten Datensätzen und zu einem Profil, in Form von Diagrammen in Excel, erzeugt werden. Die zu entwickelnde Software hat den Namen „Software Vulnerability Monitor“ und ist für den Einsatz auf dem Betriebssystem Windows 7 ausgerichtet. Einleitung und Problemstellung 2 Ein weiteres Ziel ist die Dokumentation aller aufgetretenen Probleme und gesammelten Erfahrungen im Umgang mit den Standards. Dadurch sollen Informationen erfasst werden, die beschreiben, worauf bei der Nutzung der Standards geachtet werden muss und welche Lösungsmöglichkeiten es für bestehende Probleme gibt. 1.2 Gliederung der Arbeit Der erste Teil der Arbeit (Kapitel 2) erläutert detailliert die Standards CVE, CVSS, CWE und CPE. Im zweiten Teil (Kapitel 3) wird eine Testphase zur Überprüfung der Qualität und der Quantität der von den Standards verfügbaren Informationen festgelegt. In diesem Abschnitt werden das zu überprüfende Softwareprofil (Kapitel 3.2.1), der Zeitraum (Kapitel 3.2.2) und das Vergleichsprodukt (Kapitel 3.2.3) für die Testphase definiert. Im darauf folgenden Kapitel (Kapitel 4) sind die Ziele und Anforderungen für die Entwicklung eines Tools beschrieben, welches das CVE-Verzeichnis in einer Datenbank speichert und die Möglichkeit bietet die Datenbank anhand von Softwareproduktbezeichnungen nach CVE-Einträgen zu durchsuchen. Es werden außerdem verschiedene Konzepte und Entwicklungsentscheidungen erläutert. Der anschließende Abschnitt (Kapitel 5) enthält die dokumentierten Ergebnisse der Testphase. Dabei werden die Ergebnisse der Vergleichssoftware (Kapitel 5.1) zunächst getrennt von den Ergebnissen der CVE-Suche (Kapitel 5.2) mit Hilfe des entwickelten Tools betrachtet und später miteinander verglichen (Kapitel 5.3). Es werden außerdem auch allgemeinte Informationen, wie beispielsweise die Anzahl der in der Datenbank gespeicherten CVEs dokumentiert (Kapitel 5.4). Der vorletzte Abschnitt (Kapitel 6) erläutert aufgetretene Probleme, Entwicklungsmöglichkeiten und persönliche Erfahrungen im Umgang mit dem CVE-Verzeichnis. Zusätzlich werden verwandte Arbeiten aufgezeigt und gegenüber dieser Arbeit abgegrenzt (Kapitel 6.1). Als letzter Abschnitt dieser Bachelorarbeit (Kapitel 7) wird ein Fazit zu den gesammelten Ergebnissen, Erfahrungen und Problemen bezüglich des Umgangs mit den verschiedenen Standards gezogen. In den Abbildungen 1 und 2 ist der Zusammenhang der jeweiligen Kapitel dargestellt. Abbildung 1, Kapitelzuordnungsdiagramm Einleitung und Problemstellung Abbildung 2, Detailansicht des Kapitelzuordnungsdiagramms 3 Standards 4 2 Standards 2.1 Common Vulnerabilities and Exposures 2.1.1 Allgemein Common Vulnerabilities and Exposures, kurz CVE, ist ein Verzeichnis von Namen für öffentlich bekannte Sicherheitslücken (engl.: Vulnerabilities) und Sicherheitsrisiken (engl.: Exposures). Jeder dieser Namen ist eindeutig, was Rückschlüsse zu einem ganz bestimmten CyberSicherheitsproblem zulässt. Diese Namen werden als CVE Identifiers, CVE names, CVE numbers, CVE-IDs oder auch CVEs bezeichnet. Durch die CVE Identifiers können Daten zwischen verschiedenen Netzwerksicherheitsdatenbanken und –tools einfacher ausgetauscht werden, da alle die gleiche Formatierung, beziehungsweise Definition für Schwachstellen, nutzen. Durch diese Definition wird sichergestellt, dass die verschiedenen Quellen immer über die gleiche Schwachstelle kommunizieren und nicht jeder eine andere Schwachstelle mit einem bestimmten Namen verbindet. Somit besitzt eine Schwachstelle über alle Ressourcen hinweg den gleichen Namen (CVE Identifier) und kann immer als das eine CyberSicherheitsproblem identifiziert werden. Im Jahre 1999 wurde CVE erstmals eingeführt. Die MITRE Corporation 1 verwaltet CVE mit Hilfe der Finanzierung von der National Cyber Security Division. Diese ist eine Abteilung des United States Department of Homeland Security. Vor 1999 nutzte jedes Sicherheitstool eine eigene Datenbank mit eigenen Bezeichnungen und Definition für ein bestimmtes Cyber-Sicherheitsproblem. Dadurch konnten sich die verschiedenen Datenbanken der Sicherheitstools sich nicht untereinander austauschen und ihre Sicherheitsschwachstellen und Sicherheitslücken gegenseitig teilen und ergänzen. Durch die Einführung von CVE war es möglich diese Informationen auf einer definierten Ebene auszutauschen. (The MITRE Corporation 2015a) 2.1.2 Unterscheidung Vulnerability und Exposure Vulnerability In CVE ist ein Fehler in einer Software eine Sicherheitslücke (engl.: Vulnerability), wenn sie es Angreifern auf direktem Wege ermöglicht Zugriff zum System oder zum Netzwerk zu erlangen oder es Angreifern ermöglicht die Sicherheitsrichtlinien eines Systems zu verletzen. 1 Die MITRE Corporation ist durch die Abspaltung vom Massachusetts Institute of Technology (MIT) entstanden und ist eine Organisation zum Betrieb von Forschungsinstituten im Auftrag der Vereinigten Staaten (Wikipedia 2015b) Standards 5 In CVE beschreibt eine Sicherheitslücke somit den Zustand eines Systems oder mehrerer Systeme, wenn es dem Angreifer ermöglicht • • Befehle als ein anderer Benutzer auszuführen, auf Daten zuzugreifen, auf welche er durch die festgelegten Zugriffsbeschränkungen normalerweise nicht zugreifen dürfte, • sich als andere Einheit ausgeben, • einen Denial-Of-Service auszuführen. (The MITRE Corporation 2013a) Beispiel: In einem Rechnernetz ist es möglich gerichtete Broadcast-Anfragen aus dem Internet lokal weiterzuleiten. Dadurch besteht eine direkte Angriffsmöglichkeit auf eine Zieladresse bzw. Zielrechner. Der Angreifer sich kann diese Eigenschaft des Rechnernetzes zunutze machen und mit einem Smurf-Angriff einen Dinial-of-Service bei dem Empfänger auslösen. 2 Exposure In CVE wird ein Sicherheitsrisiko (engl.: Exposure) als ein Systemkonfigurationsproblem oder ein Fehler in einer Software, welches Angreifern Zugriff auf Informationen ermöglicht oder die Möglichkeit bietet in ein System oder Netzwerk einzudringen, angesehen. Diese Sicherheitsrisiken stellen keine direkte Gefährdung dar, können aber ein wichtiger Bestandteil einer erfolgreichen Attacke sein. Außerdem müssen Sicherheitsrisiken die festgelegten Sicherheitsrichtlinien verletzen. Somit beschreibt ein Sicherheitsrisiko den Zustand eines Rechners, welcher keine Sicherheitslücken besitzt, aber • • • es Angreifern ermöglicht informationsgewinnende Aktivitäten zu betreiben, es Angreifern ermöglicht Aktivitäten zu verbergen, ein primärer Einstiegspunkt für Angreifer sein kann, welche versuchen Zugriff zum System oder Daten zu erlangen, • als ein Problem aufgrund der Sicherheitsrichtlinien betrachtet wird. (The MITRE Corporation 2013a) Beispiel: Ein Benutzer nutzt eine Anwendung, welche eine DES-Verschlüsselung mit einem 56 Bit langem Schlüssel nutzt. Durch die Verschlüsselung sind die Informationen nicht direkt angreifbar, jedoch besteht ein sehr großes Sicherheitsrisiko da bereits 2008 DES mit dieser Schlüssellänge via Brute-Force-Angriff in unter 24 Stunden geknackt wurde. (Paar und Schimmler 2008) 2.1.3 Aufbau Jeder CVE-Eintrag ist eindeutig und bezieht sich auf eine bestimmte veröffentlichte CyberSicherheitslücke. Ein CVE Eintrag besteht aus mindestens folgenden Angaben: • • • einer CVE Identifier Nummer (zum Beispiel CVE-2015-0045), eine kurze Beschreibung der Sicherheitsschwachstelle oder Sicherheitslücke, einer oder mehrerer Referenz(en) zur Sicherheitsschwachstelle oder Sicherheitslücke, 2 Bei einem Smurf-Angriff sendet ein Angreifer Ping-Pakete an die gerichtete Broadcast-Adresse eines Netzwerkes. Als Absender wird die Adresse des anzugreifenden Rechners angegeben. Dadurch senden alle an dem Netzwerk angeschlossenen Rechner eine Antwort an den anzugreifenden Rechner, was zu einem Denial-OfService führen kann. (Wikipedia 2015a) Standards 6 Die CVE Identifier Nummer muss in einem festgelegten Format angegeben sein. Zu Beginn jeder Identifier Nummer wird der CVE Präfix angegeben (CVE). Es folgt das Jahr in dem die Sicherheitslücke oder Sicherheitsschwachstelle in das CVE-Verzeichnis aufgenommen wurde (im Beispiel: 2015). Der letzte Teil ist eine eindeutige, aber von den CVE Numbering Authorities, kurz CNA, wählbare, Ziffernfolge. Bis 2014 war diese Ziffernfolge auf genau 4 Stellen (im Beispiel: 0045) festgelegt, weshalb in einem Jahr maximal 9999 CyberSicherheitsprobleme veröffentlicht werden konnten. Doch im Jahre 2014 wurde eine neue Syntax eingeführt, die es falls nötig erlaubt, die Anzahl der Stellen der Ziffernfolge beliebig zu erhöhen. Es existiert seitdem keine Einschränkung der Anzahl der Stellen der Ziffernfolge, außer dass diese immer mindestens 4-stellig sein muss. Die jeweiligen Angaben der CVE Identifier Nummer werden durch einen Bindestrich voneinander getrennt. (The MITRE Corporation 2015d) 2.1.4 Rollen und Aufgaben CVE Numbering Authority CNAs sind unter anderem große Betriebssystemhersteller, wie Microsoft oder Apple, und Forschungsorganisationen. Sie verteilen CVE Identifier Nummern an Forscher und Softwarehersteller, damit bei einer Veröffentlichung einer neu entdeckten Sicherheitsschwachstelle oder – lücke die CVE Identifier Nummer mitangegeben werden kann. Die MITRE Corporation muss nicht direkt über die Details der Schwachstelle oder Lücke informiert werden. Sie versorgt die CNAs mit einem Vorrat an CVE Identifier Nummern, welche diese wiederum verteilen können. Die folgenden Organisationen und Unternehmen nehmen aktuell Rollen als CNAs ein (Stand: Juli 2015): Primary CNA • MITRE Corporation ([email protected]) Softwareanbieter • • • • • • • • • • • • • • • • • • Adobe Systems Incorporated (nur Adobe Probleme) Apple Inc. (nur Apple Probleme) Attachmate (nur Attachmate/Novell/SUSE/NetIQ Probleme) BlackBerry (nur BlackBerry Probleme) Cisco Systems, Inc. (nur Cisco Probleme) Debian GNU/Linux (nur Linux Probleme) EMC Corporation (nur EMC Probleme) FreeBSD (hauptsächlich FreeBSD Probleme) Google Inc. (nur Chrome, Chrome OS, and Android Open Source Project Probleme) Hewlett-Packard Development Company, L.P. (nur HP Probleme) IBM Corporation (nur IBM Probleme) Microsoft Corporation (nur Microsoft Probleme) Mozilla Corporation (nur Mozilla Probleme) Oracle (nur Oracle Probleme) Red Hat, Inc. (nur Linux Probleme) Silicon Graphics, Inc. (nur SGI Probleme) Symantec Corporation (nur Symantec Probleme) Ubuntu Linux (nur Linux Probleme) Standards 7 Third-Party Koordinatoren • CERT/CC • ICS-CERT • JPCERT/CC (The MITRE Corporation 2015b) CVE Editorial Board Im CVE Editorial Board arbeiten verschiedene Personen aus IT-Sicherheitsorganisationen. Diese sind Mitarbeiter von Softwareherstellern, welche kommerzielle ITSicherheitsprogramme von Forschungsinstituten oder von staatlichen Einrichtungen verkaufen. Des Weiteren können die Personen aus der akademischen Arbeitswelt stammen oder bekannte Sicherheitsexperten sein. Die Aufgabe des CVE Editorial Board ist die Überwachung und Überprüfung der Erstellung von neuen CVE-Einträgen. (The MITRE Corporation 2015e) CVE Editor Als CVE Editor fungiert die MITRE Corporation selbst. Die Kernfunktion des CVE Editors ist das Hinzufügen von neuen CVE Identifier zur CVE Liste und die Veröffentlichung der CVE Liste auf der CVE Webseite. (The MITRE Corporation 2015b) 2.1.5 Erstellung von CVE Identifiers Sobald eine neue potentielle Sicherheitslücke oder ein -risiko entdeckt wird, werden diese Informationen von einer CNA einem CVE Identifier zugeordnet. Anschließend fügt der CVE Editor diesen der CVE List (das Verzeichnis der gesamten Sicherheitsschwachstellen und Sicherheitslücken) hinzu. Die CVE List wird über die CVE Webseite veröffentlicht. Die MITRE Corporation fungiert dabei als CVE Editor und Primary CNA. Überwacht wird der gesamte Prozess von dem CVE Editorial Board. (The MITRE Corporation 2015c) 2.2 Common Vulnerability Scoring System 2.2.1 Allgemein 3 Das Common Vulnerability Scoring System, kurz CVSS, ist ein Industriestandard, der den Schweregrad einer Softwaresicherheitslücke oder eines -risikos, sowie die Priorität und Dringlichkeit einer entsprechenden Reaktion darauf, bestimmt. Dies wird durch eine numerische Punktzahl, von 0 [keine Bedrohung] bis 10 [sehr kritisch], widergespiegelt, welche anhand von definierten Kriterien (Metriken) berechnet wird. Die numerische Punktzahl kann in eine von vier qualitativen Darstellungen übersetzt werden. Diese sind: • • • • 3 geringer Schweregrad einer Software-Schwachstelle [offiziell vorgeschlagener CVSS Punktzahlbereich: 0.1 – 3.9] mittlerer Schweregrad einer Software-Schwachstelle [offiziell vorgeschlagener CVSS Punktzahlbereich: 4.0 – 6.9] hoher Schweregrad einer Software-Schwachstelle [offiziell vorgeschlagener CVSS Punktzahlbereich: 7.0 – 8.9] kritischer Schweregrad einer Software-Schwachstelle [offiziell vorgeschlagener CVSS Punktzahlbereich: 9.0 – 10.0] Es existieren drei Versionen von CVSS (Stand November 2015). Die in dieser Arbeit beschriebenen Informationen beziehen sich, falls nicht explizit angegeben, auf die CVSS Version 2. Standards 8 Die qualitativen Darstellungen sollen Unternehmen dabei helfen, ihre SchwachstellenManagement-Prozesse richtig einzuschätzen und priorisieren zu können. So besteht bei einem kritischen Schweregrad einer Software-Schwachstelle ein größerer und schnellerer Handlungsbedarf, als bei einem geringem Schweregrad. Durch CVSS ist es möglich, dass verschiedene, inkompatible Bewertungssysteme ihre Informationen miteinander teilen und austauschen. Das CVSS wurde 2004 von dem National Infrastructure Advisory Council, kurz NIAC, veröffentlicht. Zurzeit wird es von dem Forum of Incident Response and Security Teams, kurz FIRST, verwaltet. CVSS wird durch den gemeinsamen Aufwand von verschiedenen Organisationen wie beispielsweise CERT/CC, Cisco, Microsoft, eBay oder IBM Internet Security Systems weiterentwickelt und gepflegt. (FIRST) 2.2.2 Metriken In CVSS werden die verschiedenen Bewertungskriterien einer Schwachstelle in drei unterschiedliche Metrikgruppen eingeteilt. Diese enthalten jeweils weitere Metriken. Base Metric Group In der Basis-Metrikgruppe (engl.: Base Metric Group) werden die wesentlichen Merkmale einer Schwachstelle zusammengefasst, welche über einen Zeitraum und eine Benutzerumgebung hinweg konstant bleiben. Es existieren zwei Arten von Metriken in dieser Gruppe, die Ausnutzbarkeitsmetriken (engl.: Exploitability metrics) und die Auswirkungsmetriken (engl.: Impact metrics). Die Ausnutzbarkeitsmetriken spiegeln die Leichtigkeit und die benötigten technischen Mittel wieder, welche nötig waren um die Schwachstelle auszunutzen, wohingegen die Auswirkungsmetriken die direkten Konsequenzen einer erfolgreichen Ausnutzung der Schwachstelle repräsentieren. Standards 9 Die Metriken der Base Metric Group werden von Softwareanbietern und SchwachstellenAnalytiker spezifiziert, da diese im Normalfall die exaktesten Informationen über die Eigenschaften einer Schwachstelle besitzen. In Tabelle 1 sind alle Metriken der Base Metric Group mit möglichen Werten, sowie deren Abkürzung für den CVSS Vector-String dargestellt. (Mell et al.) Metrikgruppe Metrik Access Complexity (AC) Authentification (Au) Base High (H) Medium (M) Low (L) Multiple (M) Single (S) None (N) None (N) Partial (P) Complete (C) None (N) Integrity Impact (I) Partial (P) Complete (C) None (N) Availability Impact (A) Partial (P) Complete (C) Impact Metrics Confidentiality Impact (C) Abkürzung AV:L AV:A AV:N AC:H AC:M AC:L Au:M Au:S Au:N C:N C:P C:C I:N I:P I:C A:N A:P A:C Exploitability Metrics Access Vector (AV) Metrikwert Local (L) Adjacent(A) Network (N) Tabelle 1, Metriken der Base Metric Group Temporal Metric Group Die zeitliche Metrikgruppe (engl. Temporal Metric Group) repräsentiert die Merkmale einer Schwachstelle, die sich im Laufe der Zeit ändern können. Dadurch werden die zeitabhängigen Eigenschaften einer Schwachstelle widergespiegelt und die CVSS Punktzahl entsprechend der aktuellen Gefahr angepasst. Die Merkmale der Temporal Metric Group umfassen die Verfügbarkeit von Exploit-Kits oder -Techniken, den Fortschritt bei der Behebung der Schwachstelle und die Bestätigung der technischen Details der Schwachstelle. Die drei Metriken können die CVSS Punktzahl selbst im schlechtesten Fall (kein Exploit notwendig [E:H], keine Lösung zur Schwachstellenbehebung verfügbar [RL:U], Bestätigung der Schwachstelle [RC:C]) nicht erhöhen. So kann eine Veröffentlichung eines Patches die Gefahr, die von einer Schwachstelle ausgeht, verringern, was sich beispielsweise in einer Reduzierung der CVSS Punktzahl von 5,0 auf 4,7 auswirkt. Die Metriken der Temporal Metric Group werden, wie bei der Base Metric Group, von Softwareanbietern und Schwachstellen Analytikern spezifiziert. In Tabelle 2 sind die Metriken der Temporal Metric Group mit möglichen Werten, sowie deren Abkürzung für den CVSS Vector-String, dargestellt. (Mell et al.) Standards Metrikgruppe 10 Metrik Exploitability (E) Temporal Remediation Level (RL) Report Confidence (RC) Metrikwert Unproven (U) Proof-of-Concept (POC) Functional (F) High (H) Not Defined (ND) Official Fix (OF) Temporary Fix (TF) Workaround (W) Unavailable (U) Not Defined (ND) Unconfirmed (UC) Uncorroborated (UR) Confirmed (C) Not Defined (ND) Abkürzung E:U E:POC E:F E:H END RL:OF RL:TF RL:W RL:U RL:ND RC:UC RC:UR RC:C RC:ND Tabelle 2, Metriken der Temporal Metric Group Environmental Metric Group Die umweltbedingte Metrik-Gruppe (engl.: Environmental Metric Group) repräsentiert die Eigenschaften einer Schwachstelle, welche relevant für eine Benutzerumgebung sind. In dieser werden daher die Implementierungseigenschaften und die benutzerumgebungsabhängigen Eigenschaften einer Schwachstelle erfasst. Die Metriken der Environmental Metric Group erlauben einem Analysten Sicherheitskontrollen einzubinden, die verschiedene Konsequenzen mildern können, sowie eine Höher- oder Tieferstufung der Gewichtung eines verwundbaren Systems, abhängig vom Geschäftsrisiko. In der Environmental Metric Group existieren zwei Arten von Metriken, wovon sich eine mit der Benutzerumgebung und die andere mit Sicherheitsbedingungen (engl.: Security Requirements) befasst. Diese Metriken erlauben es Analysten die CVSS Punktzahl gezielt für bestimmte Benutzerumgebungen anzupassen. Wie stark diese Anpassung ausfällt, kann einerseits aufgrund der Wichtigkeit einer betroffenen IT für die Benutzer eines Unternehmens, gemessen in Vertraulichkeit (engl.: confidentiality), Integrität (engl.: integrity) und Verfügbarkeit (engl.: availability), zum anderen durch Bestimmung der Folgen einer erfolgreichen Ausnutzung der Schwachstelle, wie der Anteil der betroffenen PC-Arbeitsplätze und Potential eines Kollateralschadens, festgelegt werden. Erreicht wird dies unter anderem durch eine Neugewichtung der Impact Metrics aus der Base Metric Group. So beeinflusst beispielsweise die in der Environmental Metric Group bestimmte Integrity Requirement die Bewertung des Integrity Impacts der Base Metric Group. Die Metriken der Environmental Metric Group werden von IT-Experten, die für das entsprechende System zuständig sind, spezifiziert, weil diese am besten in der Lage sind die potentielle Auswirkung einer Schwachstelle in der eigenen IT-Infrastruktur zu beurteilen. In Tabelle 3 sind alle Metriken der Environmental Metric Group, mit möglichen Werten, sowie deren Abkürzung für den CVSS Vector-String, dargestellt. (Mell et al.) Standards Metrikgruppe 11 Metrik Collateral Damage Potential (CDP) Environmental Target Distribution (TD) Security Requirements (CR, IR, AR) Metrik-Wert None (N) Low (L) Low-Medium (LM) Medium-High (MH) High (H) Not Defined (ND) None (N) Low (L) Medium (M) High (H) Not Defined (ND) Low (L) Medium (M) High (H) Not Defined (ND) Abkürzung CDP:N CDP:L CDP:LM CDP:MH CDP:H CDP:ND TD:N TD:L TD:M TD:H TD:ND CR:L , IR: L , AR:L CR:M , IR:M , AR:M CR:H , IR:H , AR:H CR:ND , IR:ND , AR:ND Tabelle 3, Metriken der Environmental Metric Group 2.2.3 Berechnung der CVSS Punktzahl Die verschiedenen Metriken aus der Base Metric Group, der Temporal Metric Group und der Environmental Metric Group besitzen alle mehrere fest definierte Metrikwerte, die den ITExperten zur Auswahl stehen. Jeder dieser Metrikwerte besitzt zudem einen festgelegten numerischen Wert, welche für die Berechnung der CVSS Punktzahl von Bedeutung ist. In der Tabelle 4 sind alle Metrikwerte der einzelnen Metriken abgebildet. Standards Metrik Gruppe 12 Metrik Access Complexity (AC) Authentification (Au) Base Confidentiality Impact (C) Availability Impact (A) Exploitability (E) Temporal Remediation Level (RL) Report Confidence (RC) Collateral Damage Potential (CDP) Environmental Target Distribution (TD) Security Requirements (CR, IR, AR) Pflicht Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Nein Proof-of-Concept (POC) 0.9 Nein Functional (F) 0.95 Nein High (H) 1 Nein Not Defined (ND) 1 Nein Official Fix (OF) 0.87 Nein Temporary Fix (TF) 0.90 Nein Workaround (W) 0.95 Nein Unavailable (U) 1 Nein Not Defined (ND) 1 Nein Unconfirmed (UC) 0.9 Nein Uncorroborated (UR) 0.95 Nein Confirmed (C) 1 Nein Not Defined (ND) 1 Nein None (N) 0 Nein Low (L) 0.1 Nein Low-Medium (LM) 0.3 Nein Medium-High (MH) 0.4 Nein High (H) 0.5 Nein Not Defined (ND) 0 Nein None (N) 0 Nein Low (L) 0.25 Nein Medium (M) 0.75 Nein High (H) 1 Nein Not Defined (ND) 1 Nein Low (L) 0.5 Nein Medium (M) 1 Nein High (H) 1.51 Nein Not Defined (ND) 1 Nein Tabelle 4, Übersicht aller CVSS Metriken inklusive der Angabe der numerischen Werte Impact Metrics Integrity Impact (I) Numerischer Wert 0.395 0.646 1 0.35 0.61 0.71 0.45 0.56 0.704 0 0.275 0.660 0 0.275 0.660 0 0.275 0.660 0.85 Exploitability Metrics Access Vector (AV) Metrik-Wert Local (L) Adjacent(A) Network (N) High (H) Medium (M) Low (L) Multiple (M) Single (S) None (N) None (N) Partial (P) Complete (C) None (N) Partial (P) Complete (C) None (N) Partial (P) Complete (C) Unproven (U) Standards 13 Um eine CVSS Punktzahl zu bestimmen, müssen mindestens alle Metrikwerte der Base Metric Group festgelegt sein. Falls dies nicht der Fall ist, gilt die CVSS Punktzahl, oder auch Overall-Score genannt, als nicht bestimmt (engl.: Not Defined). Abbildung 3, Vorgehen bei Bestimmung des CVSS-Score Das in Abbildung 3 definierte Vorgehen bei der Bestimmung der CVSS Punktzahl zeigt die drei unterschiedlichen Scores. Diese sind der • Base-Score, • Temporal-Score, • Environmental-Score. Die jeweiligen Scores können nur berechnet werden, wenn alle Metriken der entsprechenden Metrikgruppe einen Metrikwert definiert haben. (NVD NIST) Standards 14 Berechnung des Base-Score Abbildung 4, Beispiel für die Berechnung des Base-Score Der in Abbildung 4 berechnete Base-Score gilt, falls keine Angaben in der Temporal Metric Group und der Evironmental Metric Group gemacht wurden, auch als Overall-Score. Wenn dies nicht der Fall ist, wird der Base-Score durch die Metriken der Temporal Metric Group und/oder der Environmental Metric Group weiter angepasst. Berechnung des Temporal Score Abbildung 5, Beispiel für die Berechnung des Temporal-Score Bei der Berechnung des Temporal-Score ist zu erkennen, dass dieser nie größer werden kann als der Base-Score, da der höchstmögliche numerische Werte der entsprechenden Metriken (E, RL, RC) 1 ist. Als Folge daraus lautet die Gleichung im schlechtesten Fall „TemporalScore = Base-Score * 1 * 1 * 1“, was gleichbedeutend mit „Temporal-Score = Base-Score“ ist. Falls keine Angaben in der Evironmental Metric Group angegeben wurden, ist der Temporal-Score auch der Overall-Score. Standards 15 Berechnung des Evironmental-Score Abbildung 6, Beispiel für die Berechnung des Environmental-Score Bei der Berechnung des Environmental-Score wird der Score der Auswirkungsmetriken (C, I und A) durch die Metriken der Sicherheitsbedingungen (CR, IR und AR) angepasst. Durch diesen angepassten Score muss dementsprechend auch der Base-Score und der TemporalScore neu berechnet werden. Zur Berechnung des Environmental-Score müssen nun der angepasste Temporal-Score, der numerische Wert aus den beiden Metriken Collatereal Damage Potential und Target Distribution in der in Abbildung 6 angegebenen Formel eingesetzt werden. Falls die Metrikwerte der Environmental Metric Group gesetzt sind, ist der OverallScore immer gleich dem Environemtal-Score. 2.2.4 CVSS Vector-String Die CVSS Punktzahl wird auch als CVSS Vector-String repräsentiert. Dies ist eine, auf ASCII basierende, Zeichendarstellung von CVSS Metriken. Sie wird standardmäßig genutzt um CVSS Metrik Informationen in einer kurzgefassten Form zu speichern oder zu übertragen. Der CVSS Vector String beginnt immer mit der Bezeichnung „CVSS:“ und der aktuellen Version „3.0“. Anschließend können, getrennt durch „/“, die Metrikinformationen angegeben werden. Eine Metrik und der Wert einer Metrik werden immer durch ein oder zwei Buchstaben, welche in Tabelle 1, Tabelle 2, Tabelle 3 und Tabelle 4 zusätzlich angegeben sind, dargestellt. Getrennt werden die Metrik und der Wert durch „:“. (FIRST) Beispiel: folgende Metriken und Metrikwerte sollen im CVSS Vector String angegeben werden: • Attack Vector (AV) -> Network (N) • Attack Complexity (AC) -> Low (L) • Privileges Required (PR) -> High (H) • User Interaction (UI) -> None (N) • Scope (S) -> Unchanged (U) • Confidentiality (C) -> Low (L) • Integrity (I) -> Low (L) • Availability (A) -> None (N) Der daraus resultierende CVSS Vector String: CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:L/U:L/A:N Standards 16 2.3 Common Weakness Enumeration 2.3.1 Allgemein Common Weakness Enumeration, kurz CWE, ist eine Liste, welche bekannte Arten von Softwareschwachstellen enthält. Dieses Verzeichnis soll einerseits als gängige Sprache zur Beschreibung von sicherheitskritischen Softwareschwachstellen (in deren Architektur, Design oder Code) eingesetzt werden und zum anderen als Standardmaßstab für Softwaresicherheitstools dienen, die sich mit diesen Schwachstellen auseinandersetzen. Zusätzlich beinhaltet CWE eine Standardvorgehensweise zur Schwachstellenerkennung, zur Schadensminderung und für Präventionsmaßnahmen. CWE ist eine Gemeinschaftsentwicklung von verschiedenen Organisationen wie Apple, Core Security, HP, IBM, Symantec, U.S. National Institute of Technologie, kurz NIST, und viele weiteren. Die MITRE Corporation unterhält CWE, verwaltet das Kompatibilitätsprogramm (Definition der gängigen Sprachen) und stellt unabhängige technische Unterstützung für die Community bereit. (The MITRE Corporation 2014b) 2.3.2 Unterscheidung Softwareschwachstellen und Softwarelücken CWE ist ein Verzeichnis von Softwareschwachstellen (engl.:software weakness). Eine Softwareschwachstelle kann ein Mangel, eine Störung, ein Bug oder ein anderer Fehler in der Architektur, im Design, oder im Quellcode einer Software sein. Dies sind beispielsweise Buffer Overflows, Format Strings, Code Injection, Authentifizierungsfehler oder Handler Errors. Softwaresicherheitslücken (engl.: software vulnerabilities) werden in CVE aufgelistet und können von Angreifern genutzt werden, um auf direktem Wege Zugriff zum Netzwerk oder zum System zu erlangen. Softwareschwachstellen können zu Softwaresicherheitslücken führen. (The MITRE Corporation 2014c) 2.3.3 Aufbau Die CWE Liste wird in vier unterschiedlichen Darstellungen (engl.: Views) veröffentlicht: • • als Verzeichnis (engl.: Dictionary); Alphabetisch sortierte Ansicht, als Klassifizierungsbaum (engl.: Classification Tree); ermöglicht einen einfacheren Zugriff zu bestimmten Schwachstellen für verschiedene potentielle Nutzer, durch Schichtung der Klassifizierungen, • grafisch (engl.: Graphical); dient zum einfacheren Verständnis individueller Schwachstellen im Klassifizierungsbaum, • aufgeteilt nach Thematik (engl.: Slices-by-Topic); es werden Teilmengen von CWE, anhand der Sprache oder anderen Attributen, bereitgestellt. (The MITRE Corporation 2015f) Standards Abbildung 7, Beispiel für grafische Darstellung einer CWE Liste (The MITRE Corporation) 17 Standards 18 Inhalt einer CWE-Liste Zur eindeutigen Identifizierung eines CWE Eintrags dienen die CWE Identifier, auch CWEIDs oder CWEs genannt. Diese sind in vier Haupttypen organisiert: • • • • Category IDs Compund IDs View IDs Weakness IDs Ein CWE Eintrag beinhaltet folgende Attribute: • • • • • • • • • • • • Name der Schwachstelle Beschreibung des Schwachstellentyps alternative Bedingungen für das Verhalten der Schwachstelle Beschreibung des Verhaltens der Schwachstelle Beschreibung der Ausnutzungsmöglichkeit der Schwachstelle Wahrscheinlichkeit der Ausnutzung der Schwachstelle Beschreibung der Konsequenzen eines Ausnutzung potentielle Schadensminderung Kontenbeziehungsinformationen Quellen Codebeispiele die Programmiersprache/Programmarchitektur CVE identifies der Schwachstellen, für welche die Art der Schwachstelle existiert (Weakness Vulnerabiities) • Referenzen • … (The MITRE Corporation 2014a) Abbildung 8, Beispiel für einen CWE Eintrag (The MITRE Corporation 2015g) Standards 19 2.3.4 Entwicklung Nach der Veröffentlichung von CVE im Jahre 1999 befasste sich die MITRE Corporation erstmals mit der Problematik der Kategorisierung der Softwareschwachstellen. Als Ergebnis wurde eine erste vorläufige Klassifizierung und Kategorisierung von Schwachstellen, Angriffen und Fehler erarbeitet. Diese war zwar ausreichend für CVE, jedoch zu grob, um als Identifizierung und Kategorisierung in der Sicherheitssoftware-Industrie genutzt zu werden. MITRE hat die internen CVE Kategorien überarbeitet und im Rahmen ihrer Mitwirkung im Software Assurance Metrics and Tool Evaluation Projekt, kurz SAMATE, 2005 das Dokument Preliminary List Of Vulnerability Examples for Researchers, kurz PLOVER, veröffentlicht. Dieses besaß über 1500 unterschiedliche Beispiele für reale Schwachstellen, die anhand des CVE-Identifiers eindeutig bestimmt wurden. Durch die Einführung einer Definition für die Beschreibung von Schwachstellen ist, als Weiterentwicklung von PLOVER, das CWEVerzeichnis entstanden. (The MITRE Corporation 2014b) 2.4 Common Platform Enumeration 2.4.1 Allgemein Der offene Industriestandard Common Platform Enumeration, kurz CPE, wurde erstellt, um IT-Systeme, -Plattformen und –Produkte in einem standardisierten Namensformat angeben zu können. Der Grund für die Entwicklung lag darin, dass Spezifizierungssprachen wie CVE ihre definierten Schwachstellen IT-Systemen, -Plattformen und -Produkten zuordnen. Damit die unterschiedlichen CNAs nicht unterschiedliche Formate für diese Angabe benutzen, bietet CPE dafür eine standardisierte Art und Weise, die zusätzlich geeignet für die Interpretation und Verarbeitung durch Maschinen ist. Die aktuellste Version von CPE ist Version 2.3, welche im August 2011 von NIST veröffentlicht wurde. NIST ist außerdem die Hauptverantwortliche Organisation für CPE und stellt das offizielle CPE Verzeichnis zur Verfügung. Entwickelt wurde CPE ursprünglich von der MITRE Corporation, die jedoch die Verantwortung und Entwicklung im Rahmen des Security Content Automation Protocol, kurz SCAP, an NIST übertragen haben. Der CPE-Standard besteht aus vier Spezifikationen für • eine für Maschinen verständliche Namensformatierung für IT-Systeme, -Plattformen und -Produkte (CPE-Names) (Cheikes et al. 2010), • den Abgleich/Vergleich von CPEs (Algorithmen) (Parmelee et al. 2010), • ein Verzeichnis von CPEs (Cichonski et al. 2010), • einer Definitionssprache zur Beschreibung von komplexen Gruppierungen von CPEs, mit dem Ziel IT Plattformen zu beschreiben (Waltermine et al. 2011). NIST bietet auf ihrer Webseite neben den Dokumentationen der Spezifikationen auch ein Verzeichnis von CPEs an. Dieses umfasst 105.297 unterschiedliche Namensbezeichnungen (Stand August 2015). Standards 20 2.4.2 Namensformatierung In CPE sind standardisierte Methoden definiert, welche Namen zu IT Produktklassen zuordnen. Die am einfachsten zu lesende Methode wird well-formed CPE name, kurz WFN genannt. Diese ist eine abstrakte, aber logische, Konstruktion für die Formatierung eines Namens. So ist beispielsweise die WFN-Repräsentation des Microsoft Internet Explorer 8.0.6001 Beta wie folgt: wfn:[part=“a“,vendor=“microsoft“,product=“internet_explorer“,version=“8\.0\.6001“, version=“beta“] Zu Beginn muss das entsprechende Präfix „wfn“ angegeben werden. Die verschiedenen Eigenschaften des Produktes werden innerhalb einer geöffneten und geschlossenen eckigen Klammern aufgezählt, wobei die Eigenschaftsdefinitionen wie Hersteller (engl.: vendor) oder Version (engl.: version) explizit mit angegeben werden. Die CPE Spezifikation zur Namenformatierung definiert außerdem zwei Verfahren zur Zusammenfügung eines WFN zu einer maschinenlesbaren Codierung, ebenso wie das Auseinanderfügen der maschinenlesbaren Codierung zurück zu einem WFN. Einer der Verfahren wird URI Zusammenfügung (engl.: Uniform Resource Identifier binding) genannt. Diese orientiert sich an der URI-Syntax und besitzt folgende Formatierung: cpe:/{part}:{vendor}:{product}:{version}:{update} {part} {vendor} {product} {version} {update} Unterscheidung zwischen Hardware (h), Betriebssystem (o) oder Anwendung (a) Name des Herstellers Name des Produktes Versionsnummer des Produktes Herstellerspezifischer Name zur Charakterisierung eines Updates, Service-Packs oder Status bei Veröffentlichung des Produktes (beispielsweise Beta, Alpha, usw.) Tabelle 5, Erläuterung der Eigenschaften des URI Bindings Das als WFN genannte Beispiel des Microsoft Internet Explorers sieht in der URI Zusammenführung wie folgt aus: cpe:/a:microsoft:internet_explorer:8.0.6001:beta Die URI Zusammenführung wird auch in dem von NIST angebotenen CPE Verzeichnis verwendet. Die zweite Art der Zusammenführung wird Formatierte String Zusammenführung (engl.: formatted string binding) genannt. Im Vergleich zur URI Zusammenführung sind nur geringe Syntaxunterschiede vorhanden. So wird zu Beginn das Präfix nicht mit „cpe:/“ angegeben, sondern mit „cpe:2.3:“. Dadurch kann sofort erkannt werden, um welche Version der von CPE es sich handelt. Das Hauptunterscheidungsmerkmal ist, dass sechs weitere Produktattribute angegeben werden können. Standards {edition} {sw_edition} {target_sw} {target_hw} {language} {other} 21 Vom Hersteller definierte editionsrelevante Anforderungen des Produktes Charakterisierung wie das Produkt zu einem bestimmten Markt oder Zielgruppe zugeschnitten wurde Die anvisierte Softwareumgebung in der das Produkt ausgeführt werden soll Die anvisierte Hardwarearchitektur (beispielsweise x86) auf der das Produkt arbeiten soll Vom Produkt unterstützte Sprachen Alle sonstigen wichtigen hersteller- oder produktspezifischen Beschreibungsmerkmale Tabelle 6, Zusätzliche Eigenschaften des Formatted String Bindings Das WFN Beispiel sieht in der Formatierten String Zusammenführung wie folgt aus: cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:* Das „*“ bedeutet, dass diese Werte nicht definiert wurden. (The MITRE Corporation 2013b) 2.5 Zusammenhang der Standards Die in Kapitel 2.1 bis 2.4 beschriebenen Standards stehen alle in einem Zusammenhang. Der Mittelpunkt der Verbindung stellt die Norm CVE dar. Diese macht es möglich Cybersicherheitslücken und -risiken eindeutig zu benennen, ohne jedoch detaillierte Informationen zu diesen zu nennen. Mit Hilfe eines CVSS-Eintrags kann der Schweregrad der Sicherheitslücke oder des Sicherheitsrisikos bestimmt werden. Ein CVE-Eintrag besitzt entweder keine oder genau eine Zuordnung zu einem CVSS-Eintrag. Dadurch wird eine mehrfache Festlegung des Schweregrads vermieden. Um zu bestimmen in welchem IT-Produkt, -Plattform, oder System das Sicherheitsrisiko, beziehungsweise die Sicherheitslücke, auftritt können dem CVE-Eintrag beliebig viele CPEs zugeordnet werden. Falls eine Sicherheitslücke auf eine Schwachstelle im Produkt zurückzuführen ist, kann diese Schwachstelle mit Hilfe des CWEStandards mit dem CVE-Eintrag verknüpft werden. Standards 22 Zusammenfassung Eine Sicherheitslücke oder ein Sicherheitsrisiko wird durch einen CVE-Eintrag eindeutig benannt, kann des Weiteren durch einen CVSS-Eintrag bewertet, mit Hilfe von CPE-Einträgen bestimmten IT-Produkten, in denen die Schwachstelle auftritt, zugeordnet und durch CWE mit aufgetretenen Schwachstellen verknüpft werden. Abbildung 9, Zusammenhang der Standards Standard verwaltet von aktuelle Version Erklärung The MITRE Corporation keine Versionierung Common Vulnerabilities Standard and Exposures [CVE] Verzeichnis NIST 2.0 Dient zur Eindeutigen Benennungen von Sicherheitslücken und -risiken Common Vulnerability Scoring System [CVSS] FIRST 3.0 Dient zur Einstufung des Schweregrads einer Sicherheitslücke oder eines -risiko Common Weakness Enumeration [CWE] The MITRE Corporation 2.9 Dient zur Definition einer Sprache zur Beschreibung von Softwareschwachstellen NIST Dient zur Definition eines Namensformat zur Benennung von IT-Systemen, -Plattformen und -Produkten Common Platform Enumeration [CPE] Standard Verzeichnis 2.3 Tabelle 7, Zusammenfassung der Standards Testphase 23 3 Testphase 3.1 Allgemein Um zu überprüfen ob die Entwicklung von Sicherheitsanalyseanwendungen auf Basis des CVE-Verzeichnisses sinnvoll ist, muss geprüft werden, ob die im Kapitel Standards beschriebenen Normen eine qualitativ und quantitativ ausreichende Informationsgrundlage für eine zuverlässige Schwachstellenerkennung von installierten Softwareprodukten bieten. Um eine möglichst realistische Beurteilung zu ermöglichen, werden die zur Verfügung stehenden Informationen der Standards mit Ergebnissen einer Software zur Schwachstellenerkennung und -einstufung verglichen. Diese Bewertung umfasst Aspekte wie den Detailgrad der Informationen, die Anzahl der gefundenen Schwachstellen und den Zeitpunkt der Erkennung einer Schwachstelle. Ein abschließendes Fazit zeigt, ob sich die Entwicklung einer Software zur Schwachstellenerkennung und –bewertung auf Basis von CVE, CVSS, CPE und CWE lohnt. 3.2 Definition der Testparameter 3.2.1 Softwareprofil Für den Test wird ein Softwareprofil mit 26 Programmen erstellt, welches als Grundlage der Überprüfung dient. Die einzelnen Programme werden über einen in Kapitel 3.2.2 definierten Zeitraum von einer in Kapitel 3.2.3 definierten Software überwacht. Zusätzlich werden alle CVE-Einträge aus dem frei verfügbaren, offiziellen CVE-Verzeichnis der National Vulnerability Database, kurz NVD, gesichert, die in Verbindung mit einem der Programme des Softwareprofils stehen. Abbildung 10, Darstellung der Funktionsweise des Softwareprofils Testphase 24 Die Programme des Softwareprofils müssen mehrere Kriterien erfüllen, die sich an der definierten Ziel-Benutzerumgebung des zu entwickelnden Software-Vulnerability-Tools orientieren. Die Softwareanwendungen müssen 1. unter Windows 7 installiert und genutzt werden können Grund: Windows 7 ist das zurzeit (Stand Juli 2015) am weitest verbreitete Betriebssystem auf dem deutschen Markt (statista 2015). Durch dieses Kriterium kann die größtmögliche Zielgruppe, Benutzer die Windows 7 als Betriebssystem besitzen, erreicht werden. 2. frei verfügbar sein (Freeware) Grund: Im Rahmen dieser Arbeit werden keine Softwareprodukte für den Vergleich erworben, da keine finanziellen Mittel zur Verfügung stehen. 3. beliebt und weit verbreitet sein Grund: Durch dieses Kriterium kann die größtmögliche Zielgruppe erreicht werden Um dem 3. Kriterium gerecht zu werden, wurden fünf unterschiedliche Top-Downloadlisten, beispielsweise von dem reichweitenstärksten Technikportal im deutschsprachigen Raum, CHIP Online (Wikipedia), oder dem meistbesuchten deutschsprachigen IT-Nachrichtenticker, Heise Online (Wikipedia), als Basis der Auswahl verwendet. In manchen Top-Downloadlisten finden sich Spiele wieder, welche jedoch in dieser Arbeit nicht berücksichtigt wurden, da der Schwerpunkt auf kostenlos erhältlichen Softwareanwendungen für Windows 7 liegt. Bei der Auswahl der 26 Softwareanwendungen aus den fünf Top-Downloadlisten wurde wie folgt vorgegangen: 1. Erstellung von Softwarekategorien Bevor bestimmte Anwendungen für das Softwareprofil der Testphase ausgewählt wurden, sind unterschiedliche Softwarekategorien erstellt worden. Dies dient dem Zweck, dass ein größtmöglicher Funktions- und Anwendungsbereich von den verschiedenen Softwareanwendungen abgedeckt wird. Die Softwarekategorien orientieren sich an den gelisteten Anwendungen und wurden nach eigenem Ermessen definiert. 2. Auswahl der am häufigsten gelisteten Anwendungen je Kategorie Je Kategorie, wurden die am häufigsten und besten gelisteten Anwendungen für das Softwareprofil ausgewählt. Die Anzahl der pro Kategorie ausgewählten Produkte wurde nach eigenem Ermessen bestimmt. Eine Ausnahme bei der Auswahl bildet der Internet Explorer von Microsoft, welcher trotz Abwesenheit in den Downloadlisten aufgenommen wurde. Grund dafür ist die standardmäßige Installation auf einem Windows Betriebssystem, weswegen der Internet Explorer nicht nachträglich heruntergeladen werden muss, aber trotzdem auf einem Großteil der Rechner der Zielgruppe installiert ist. Testphase 25 Kategorie Softwareanwendung installierte Version IrfanView GIMP 4.40 2.8.14 CDBurnerXP 4.5.5.5790 Microsoft Internet Explorer 11.0.9600.17937 Mozilla Firefox 40.0.2.5702 Google Chrome 44.0.2403.155 Adobe Flash Player 18.0.0.232 Microsoft Silverlight 5.1.40728.0 7-Zip 9.20 WinRAR 5.21.0.0 Skype 7.15.0.102 .NET Framework 4.0.30319.34209 Java Runtime Environment Apple iTunes 8.0.51.16 12.2.2.25 KMPlayer 3.9.1.138 VLC Player 2.2.1.0 Editor Notepad++ 6.7.9.2 Office Apache OpenOffice 4.11.9775 Adobe Acrobat Reader 15.008.20082 PDFCreator 2.1.2.884 FileZilla 3.13.0 PuTTY 0.65 Recuva 1.52.0.1086 TrueCrypt 7.1.1.0 AdwCleaner 5.0.0.3 Ccleaner 5.08.5308 Bilddarstellung/-bearbeitung Brennen Browser Browsererweiterung File-Archiver Kommunikation Laufzeitumgebung Multimedia PDF Serverkommunikation Sicherheit/Wiederherstellung Systemoptimierung Tabelle 8, Softwareprofil, welches als Grundlage für die Überprüfung dient Testphase Platz 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 filehippo 4 Ccleaner Adobe Acrobat Reader VLC Player Mozilla Firefox Avast! Free Antivirus BlueStacks App Player Skype Recuva uTorrent Google Chrome WinRAR KMPlayer Internet Download Manager Java Runtime Environment Microsoft Silverlight Speccy Flash Player Apple iTunes Defraggler tucows 5 IrfanView Adobe Acrobat Reader Express Files RegInOut System Utilities Outlook Express Phoenix EDID Designer Apple iTunes Adobe Flash Player Exifer DAEMON Tools Pro PDF Reader for Windows 7 TeamViewer Internet Download Manager PDF Reader for Windows 8 AmazingMIDI PDF Converter Free Karaoke Player Software Time Adjuster CutePDF Printer techtalk 6 Windows Live Essentials Microsoft Silverlight Adobe Flash Player Google Chrome Adobe Shockwave Player Windows Live Messanger Apple iTunes QuickTime Mozilla Firefox Skype TurboTax Bing Bar Adobe Acrobat Reader Google Earth Ccleaner Yahoo Toolbar MS Security Essentials 7-Zip HP Photosmart Essential chip 7 Adobe Flash Player Ccleaner Free Youtube Converter Avira Free Antivirus AdwCleaner Mozilla Firefox Adobe Acrobat Reader VLC Player Google Chrome PDFCreator TubeMate (Android-App) Apple iTunes GIMP CDBurnerXP Apache OpenOffice DAEMON Tools Lite avast Free Antivirus Skype Recuva heise 8 AdwCleaner H2testw Ccleaner TrueCrypt VLC Player IrfanView Mozilla Firefox 7-Zip PuTTY Netspot (für Apple) Disk Drill PDF-Xchange Viewer MediathekView Avira Free Antivirus FileZilla Notepad++ Adobe Flash Player PDFCreator Advanced IP Scanner FileHippo App Manager Shockwave Player K-Lite Codec Pack .NET Framework Malwarebytes Anti-Malware TeamViewer PDF Editor Half-Life DAEMON Tools Lite Sqirlz Morph DWG Viewer MS Office Word Viewer 2003 VLC media Player Ask Toolbar Picasa RealPlayer Safari Spybot - Search Destroy Windows Movie Maker PDF24 Creator AdBlock Plus für Chrome Teamspeak 3 Java Runtime Environment Audacity LicenseCrawler CDBurnerXP Classic Shell Adobe Acrobat Reader Minitool Partition Wizard SpyBot Search & Destroy definierte Kategorien Bilddarstellung/-bearbeitung Brennen Browser Browsererweiterung File-Archiver Kommunikation Laufzeitumgebung Multimedia Editor Office PDF Serverkommunikation Sicherheit/Wiederherstellung Systemoptimierung Tabelle 9, Fünf Top-Downloadlisten, in denen die für das Softwareprofil ausgewählten Anwendungen hervorgehoben sind 4 (FILEHIPPO 2015) [Stand August 2015] (Tucows 2015) [Stand August 2015] 6 (PC Pitstop 2013) [Stand Juni 2013] 7 (CHIP 2015) [Stand August 2015] 8 (heise online 2015)[Stand August 2015} 5 Testphase 27 3.2.2 Zeitraum Damit aussagekräftige Ergebnisse erzielt werden können, muss das Softwareprofil über einen möglichst langen Zeitraum überwacht werden. Für die Sammlung von CVE-Einträgen stellt dies kein Problem dar, da ein CVE-Eintrag ein Veröffentlichungsdatum enthält und das CVEVerzeichnis mit allen jemals veröffentlichten Schwachstellen frei verfügbar ist. Dadurch kann die Prüfung eines Zeitraums im Nachhinein durchgeführt werden und es muss beispielsweise nicht täglich kontrolliert werden, ob für das Softwareprofil zutreffende neue CVEs veröffentlicht wurden. Für ein Vergleichsprodukt ist dies jedoch nicht möglich, da es dort keine Möglichkeit gibt frei auszuwählen, für welchen Zeitraum und welche Anwendung man eine Schwachstellenüberprüfung durchführen möchte. Eine solche Anwendung bezieht sich im Normalfall immer auf die aktuell gegebene Situation. Infolgedessen muss das Ergebnis der Schwachstellesuche des Vergleichsprodukts über den gesamten, definierten Zeitraum in regelmäßigen Abständen überprüft und erfasst werden. Die Testphase beginnt am 23.08.2015 und endet am 20.11.2015. Dadurch wird über einen Zeitraum von 90 Tagen Informationen zu gefundenen, beziehungsweise veröffentlichten Schwachstellen gesammelt. Abbildung 11, Darstellung des Zeitraums der Testphase 3.2.3 Vergleichsprodukt Bei der Festlegung eines Vergleichsprodukts, für die Analyse der Quantität und Qualität von CVE-Einträgen, wurden verschiedene Anwendungen im Internet gesucht. Dabei wurden unterschiedlichste Softwareanwendungen gefunden, wie beispielsweise: • AlienVault Unified Security Management (kostenpflichtig) AlienVault Unified Security Management, kurz AlienVault USM, ist eine umfangreiche Software zur Sicherheitsanalyse der gesamten Unternehmensstruktur. Es bietet unter anderem eine Funktionalität zur Schwachstellenüberprüfung an. Diese stellt fest, ob Anwendungen oder Betriebssysteme Konfigurationsprobleme besitzen oder nicht auf dem aktuellsten Stand sind. AlienVault USM bietet jedoch auch die Möglichkeit Schwachstellen, welche durch CVEs eindeutig identifiziert sind, anhand von CVSS zu priorisieren. (AlienVault) Testphase • • • • • • 28 Cisco Security IntelliShield Alert Manager Service (kostenpflichtig) Cisco Security IntelliShield Alert Manager Service ist eine API-Schnittstelle mit der CISCOs IntelliShield-Datenbank genutzt werden kann, um automatisiert Sicherheitswarnungen und -informationen zu Hard- und Software zu erlangen. Es werden keine Angaben zu genutzten Standards gemacht. Der Cisco Security IntelliShield Alert Manager Service wurde während dieser Arbeit (03.08.2015) aus dem Verkauf genommen und wird nicht mehr angeboten. (Cisco Systems 2009) FileHippo App Manager (kostenlos) Der FileHippo App Manager scannt das IT-System, auf welchem es ausgeführt wird, nach installierten Programmen und überprüft ob Updates für diese bereitstehen. Eine Beurteilung von Sicherheitsschwachstellen existiert nicht. Das Tool ist ausschließlich darauf ausgelegt, Anwendungen auf dem aktuellsten Stand zu halten. (FILEHIPPO) IBM Internet Scanner (kostenpflichtig) IBM Internet Scanner überprüft ein Netzwerk um dort Sicherheitsschwachstellen zu finden und diese zu beheben. Bei der Angabe von Schwachstellen werden unter anderem CVEs genutzt. (IBM) Microsoft Baseline Security Analyzer (kostenlos) Microsoft Baseline Security Analyzer unterstützt IT-Experten bei der Bestimmung des Sicherheitsstatus in einem Unternehmen anhand von MicrosoftSicherheitsempfehlungen. Das Tool erkennt fehlende Sicherheitsupdates und häufig vorkommende Fehler in der Sicherheitskonfiguration von Rechnersystemen. Microsoft Baseline Security Analyzer nutzt keine der in Kapitel 2 erläuterten Standards. (Microsoft) Secunia Personal Software Inspector, kurz Secunia PSI (kostenlos) Secunia PSI untersucht ein IT-System auf installierte Programme und prüft, ob für diese Sicherheitsschwachstellen bekannt sind oder Updates zur Verfügung stehen. Gefundene Schwachstellen für eine Anwendung werden in einer Skala von 0 [keine Gefahr] bis 5 [sehr gefährlich] eingestuft. Secunia PSI ermöglicht es des Weiteren Updates von nicht aktuellen Softwareanwendungen zu installieren. Zu Identifikation von Schwachstellen wird CVE genutzt. (Secunia) SUMo (kostenlos) SUMo scannt den PC nach installierten Softwareanwendungen und prüft ob diese aktuell sind. Dabei wird eine Priorisierung nach der Größe der Updates vorgenommen. Große Updates sind mit Warnzeichen markiert, wohingegen kleine Updates nur einen einem Stern besitzen. Die Updates können direkt über SUMo installiert werden. SUMo nutzt keine der in Kapitel 2 erläuterten Standards. (KC Softwares) Alle kostenpflichtigen Anwendungen konnten nicht als Vergleichsprodukt ausgewählt werden, da für diese Arbeit keine finanziellen Mittel zu Verfügung standen. Von den anderen vier kostenlos erhältlichen Programmen, ist der Microsoft Baseline Security Analyzer zur Überprüfung der Sicherheitskonfigurationen von Rechnern in Netzwerken ausgelegt. Dadurch kann mit diesem kein Softwareprofil überprüft werden. Somit wurden zur Auswahl des Vergleichsproduktes der FileHippo App Manager, Secunia PSI und SUMo miteinander verglichen. Testphase 29 Version Design Einstufung der Kritikalität Grundlage der Einstufung der Kritikalität Scannen nach installierter Software Programme manuell hinzufügen Updates installieren Nutzung von Standards Nutzt herstellereigene Datenbank Werbeanzeigen Secunia PSI SUMo 3.0.0.100004 3.13.10.265 + übersichtlich + übersichtlich + modern (Win. 7-orientiert) + schlicht + schlicht - veraltet (Win. XP-orientiert) FileHippo App Manager 2.0.0.353 + modern (Win. 8-orientiert) - unübersichtlich - zu große Darstellung Ja Nein - feste Fenstergröße Nein Keine Angaben Keine Einstufung Keine Einstufung Ja Ja Ja CVE Ja Nein Ja Ja Ja Keine Angaben Keine Angaben Nein Ja Nein Ja Keine Angaben Ja Ja Tabelle 10, Vergleichsmatrix der drei potentiellen Softwareanwendungen Als Vergleichsprodukt wurde sich aufgrund von zwei Gründen für Secunia PSI entschieden. 1. Secunia PSI ist die einzige der drei Anwendungen, in welcher, die auf einem ITSystem gefundenen Programme, nach bereits bekannten Sicherheitslücken geprüft werden. Dadurch kann das Tool eine Einstufung der Angreifbarkeit von Anwendungen, auf Basis der gefundenen Sicherheitslücken, vornehmen. 2. Secunia PSI ist die einzige der drei Anwendungen die CVEs nutzt. Nur durch die Angabe von CVEs bei den gefundenen Sicherheitsschwachstellen können die Ergebnisse von Secunia PSI mit den Ergebnissen des öffentlich, verfügbarem CVE-Verzeichnis verglichen werden. SUMo und FileHippo App Manager dienen zur Überprüfung der Programmversion und nicht zur Überprüfung der Schwachstellen eines Programms. Vorgehen von Secunia PSI Secunia PSI sammelt von dem System, auf dem es ausgeführt wird, Informationen zu installierten Programmen, wie beispielsweise den Namen einer Anwendung oder die Versionsnummer. Diese Informationen sendet es bei der Schwachstellenüberprüfung zu einem Secunia-Server. Dort überprüft der Server, ob zu der übermittelten Anwendung in der installierten Version Schwachstellen in der Datenbank eingetragen sind und ob bereits eine neuere Version der Anwendung zur Verfügung steht. Der Secunia PSI stellt die zurückgelieferten Informationen in einer Liste dar. Falls Schwachstellen für eine bestimmte Anwendung gefunden wurden, so wird für diese eine Einstufung der Kritikalität in einer Skala von 0 bis 5 vorgenommen. Über ein Untermenü können weitere detaillierte Informationen, wie beispielsweise die CVE-IDs, zu Schwachstellen auf der Secunia-Webseite aufgerufen werden. Über Secunia PSI ist es möglich, nicht aktuelle Anwendungen zu aktualisieren. Testphase 30 3.3 Ablauf der Testphase Die Anwendungen des Softwareprofils, sowie das definierte Vergleichsprodukt Secunia PSI werden alle auf einem zur Verfügung stehenden IT-System installiert. Auf diesem System wird das Betriebssystem Windows 7 ausgeführt. Ab dem Beginn der Testphase wird, in regelmäßigen Abständen von bis zu maximal zwei Tagen, eine Überprüfung der Softwareanwendungen mit Secunia PSI durchgeführt. Falls bei dieser Überprüfung Sicherheitslücken entdeckt werden, müssen diese protokolliert werden. Secunia stellt für einige Sicherheitslücken weitere detaillierte Informationen auf ihrer Webseite zur Verfügung, welche aus Secunia PSI heraus aufgerufen werden kann. Der Vorgang der Überprüfung und Dokumentation der Sicherheitslücken mit Secunia PSI wird für die gesamte Testphase vom 23.08.2015 bis zum 20.11.2015 durchgeführt. Nach der Testphase können die CVE-Einträge für das Softwareprofil gesucht werden. Für diesen Zweck wird während der Testphase ein Tool entwickelt, welches es ermöglichen soll, das frei verfügbare CVE-Verzeichnis in einer lokalen Datenbank abzuspeichern und zu durchsuchen. Da die Suche von CVE-Einträgen unter Angabe von CPEs durchgeführt wird (siehe Kapitel 2.5), müssen die genauen Programmversionen bekannt sein, damit der korrekte CPEEintrag für die Suche bestimmt werden kann. Ohne die Angabe der Version wäre die zutreffende CPE-ID nicht zu bestimmen. Beispiel für Acrobat Reader in Version 11.0.9: cpe:/a:adobe:acrobat_reader:11.0.9 Aus diesem Grund werden vor Beginn der Testphase die Versionen der Softwareanwendungen dokumentiert. Testphase 31 Softwareanwendung .NET Framework 7-Zip Adobe Flash Player Adobe Reader AdwCleaner Ccleaner CDBurnerXP FileZilla Gimp Google Chrome IrfanView iTunes Java Runtime Environment KMPlayer Microsoft Internet Explorer Microsoft Silverlight Mozilla Firefox Notepad++ OpenOffice PDFCreator Putty Recuva Skype TrueCrypt VLC Player WinRAR Angabe der installierten Version in Secunia PSI in Systemsteuerung im Programm 4.5.51209 9.20 18.0.0.232 15.008.20082 5.8.0.5308 4.5.5.5790 3.13.0.0 2.24.24.0 44.0.2403.155 12.2.2.25 8.0.51.16 3.9.1.138 11.0.9600.17937 5.1.40728.0 40.0.2.5702 6.7.9.2 4.11.9775 2.1.2.884 0.65.0.0 1.52.0.1086 7.15.0.102 7.1.1.0 2.2.1.0 5.21.0.0 4.5.51209 9.20.00.00 18.0.0.232 15.008.20082 5.08 4.5.5.5790 3.13.0 2.8.14 44.0.2403.155 4.40 12.2.2.25 8.0.51.16 3.9.1.138 5.1.40728.0 40.0.2 6.7.9.2 4.11.9775 2.1.2 0.65 1.52.0.1086 7.15.0.102 7.1.1.0 2.2.1 5.21 9.20 5.0.0.3 5.08.5308 3.13.0 2.8.14 40.0.2 2.2.1 5.21 Tabelle 11, Angabe der installierten Version der Anwendungen des Softwareprofils Manche Versionsangaben in Secunia PSI und in der Systemsteuerung unterscheiden sich. Falls dies der Fall ist, wurde zusätzlich die Versionsangabe im Programm selbst überprüft. Software-Vulnerability-Tool 32 4 Software-Vulnerability-Tool 4.1 Ziel Das Hauptziel des zu entwickelnden Tools ist es, dass das CVE-Verzeichnis nach CVEEinträgen, denen ein CPE-Eintrag einer Softwareanwendung aus dem Softwareprofil zugeordnet ist, durchsucht werden kann. Abbildung 12, Darstellung des Ziels des Software-Vulnerability-Tools. Das Software-Vulnerability-Tool soll das CVE-Verzeichnis nach CVE-Einträgen durchsuchen, denen ein CPE-Eintrag einer Softwareanwendung aus dem definierten Softwareprofil zugeordnet ist. Um das Hauptziel zu erreichen wurden mehrere Unterziele definiert. Diese sind: • Die Speicherung des CVE-Verzeichnisses inklusive aller CVE-Informationen auf dem ausführenden System Das auf der Webseite der NVD verfügbare CVE-Verzeichnis muss lokal auf dem ausführenden IT-System gespeichert werden, damit dort nach der Speicherung unabhängig vom Internet das CVE-Verzeichnis durchsucht werden kann. • CVE-Informationen auf dem aktuellsten Stand zu halten Da das von der NVD zu Verfügung gestellte, öffentlich frei verfügbare CVEVerzeichnis täglich aktualisiert wird, muss eine Möglichkeit bereitgestellt werden, das lokal gespeicherte CVE-Verzeichnis zu aktualisieren. • Die Unabhängigkeit von CVE-Verzeichnis-Quellen Der Link zum Download des CVE-Verzeichnisses kann sich im Laufe der Zeit ändern, beziehungsweise kann es sein, dass die NVD bei der Bereitstellung des Verzeichnisses von einer anderen Organisation abgelöst wird. Daher muss es möglich sein die Quelle des CVE-Verzeichnisses anzupassen. • Die Suche im lokalen CVE-Verzeichnis Das lokal gespeicherte CVE-Verzeichnis muss anhand von verschiedener Kriterien durchsucht werden können Software-Vulnerability-Tool • • • 33 Die Suche im lokalen CVE-Verzeichnis anhand eines CPE-Profils Das Tool muss es ermöglichen eine Liste von CPE-Einträgen als Profil abzuspeichern und das lokal gespeicherte CVE-Verzeichnis anhand des CPE-Profils zu durchsuchen. Die Möglichkeit zur Anzeige von detaillierten Informationen eines CVE-Eintrags Es muss die Möglichkeit bestehen alle zur Verfügung stehenden Informationen eines CVE-Eintrags aus dem lokal gespeicherten CVE-Verzeichnis anzuzeigen. Diese Informationen sind beispielsweise eine CVSS-Bewertung, zugeordnete CPEs, Referenzen oder die CWE-Id. Die Generierung von Statistiken Im lokal gespeicherten CVE-Verzeichnis befinden sich viele unterschiedliche Informationen über die Standards. Um daraus aussagekräftige Beurteilungen ziehen zu können, muss die Möglichkeit bestehen, Statistiken über das lokal gespeicherte CVEVerzeichnis oder über ein -CPE-Profil zu generieren. 4.2 Anforderungen Um die definierten Ziele zu erreichen werden Anforderungen an das CVE-Tool gestellt und in einem Lastenheft zusammengefasst (siehe Anhang, Kapitel 9.2). Diese legen die Eigenschaften des zu entwickelnden Tools fest. Im Folgenden sind einige der wichtigsten Anforderungen aus dem Lastenheft für das Software-Vulnerability-Tool aufgeführt: (A1) Datenbank Das CVE-Verzeichnis muss in einer lokalen Datenbank gespeichert werden. (A4) Standardorientierte Tabellenstrukturierung Das Datenbankschema muss eine Strukturierung der Tabellen besitzen, welche die Standards CVE, CPE, CVSS und CWE klar voneinander trennt. (A13) Automatischer Download Die zu entwickelnde Software muss nach Aufforderung des Benutzers automatisch die benötigten Importdateien für CVEs und CPEs herunterladen. (A10) Quelle der Importdatei für CVEs II Ein URL-Pfad zu einer Informationsquelle für CVE-Einträge muss zu der Liste der CVEQuellen hinzugefügt werden können. (A30) Quelle der Importdatei für CVEs III Ein URL-Pfad zu einer Informationsquelle für CVE-Einträge muss aus der Liste der CVEQuellen entfernt werden können. (A15) Format der Importdatei für CVEs Die Datei in der die CVE-Einträge enthalten sind muss im XML-Format vorliegen. (A31) CVE-Quellen speichern Die vom Benutzer eingegebenen Quellen für CVE-Einträge müssen auch nach Beenden und erneutem Starten der zu entwickelnden Software weiterhin bestehen. (A25) Datenbank aktualisieren Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, die Datenbank mit wenig Benutzeraufwand aktualisieren zu können. Software-Vulnerability-Tool 34 (A34) CVE-Verzeichnis nach CVE-ID durchsuchen Die zu entwickelnde Software muss die Möglichkeit bieten, das lokale CVE-Verzeichnis unter Angabe einer CVE-ID als Suchkriterium zu durchsuchen. (A35) CVE-Verzeichnis nach bestimmten Softwareprodukt durchsuchen Die zu entwickelnde Software muss die Möglichkeit bieten, das lokale CVE-Verzeichnis unter Angabe eines Softwareprodukts als Suchkriterium zu durchsuchen. (A36) CVE-Verzeichnis ab einem bestimmten Datum durchsuchen Die zu entwickelnde Software muss die Möglichkeit bieten, das lokale CVE-Verzeichnis unter Angabe eines bestimmten Datums als Suchkriterium zu durchsuchen und alle Einträge anzuzeigen, die ab dem eingegebenen Datum veröffentlicht wurden. (A37) CVE-Verzeichnis bis zu einem bestimmten Datum durchsuchen Die zu entwickelnde Software muss die Möglichkeit bieten, das lokale CVE-Verzeichnis unter Angabe eines bestimmten Datums als Suchkriterium zu durchsuchen und alle Einträge anzuzeigen, die bis zu dem eingegebenen Datum veröffentlicht wurden. (A38) Kombination der Suchkriterien Die zu entwickelnde Software muss die Möglichkeit bieten, die in den Anforderung (A34), (A35), (A36) und (A37) definierten Suchkriterien miteinander zu kombinieren, um so eine detailliertere Suche zu ermöglichen. (A41) Detaillierte Anzeige von Suchergebnissen Die zu entwickelnde Software muss die Möglichkeit besitzen eine detaillierte Ansicht eines einzelnen Suchergebnisses der Suchergebnisliste anzuzeigen. (A74) CPE-Profil erstellen Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, ein CPE-Profil zu erstellen. (A62) CVE-Verzeichnis anhand des CPE-Profils durchsuchen Das zu entwickelnde System muss anhand eines CPE-Profils alle CVE-Einträge des CVEVerzeichnisses finden, die mit dem im Profil hinterlegten CPE-Einträgen verknüpft und im hinterlegten Zeitraum, falls vorhanden, veröffentlicht sind. Software-Vulnerability-Tool 35 4.3 Planung Die Softwareentwicklung dieser Arbeit wird in drei Ausbaustufen unterteilt. Dies bietet den Vorteil, dass verschiedene Funktionen, wie beispielsweise der Import und die Aktualisierung des CVE-Verzeichnisses, als eigene Anwendung entwickelt und getestet werden können. Abbildung 13, Darstellung der verschiedenen Ausbaustufen Die erste Ausbaustufe wird CVE-Import-Tool genannt. Dieses Tool bildet die Basis für die weiteren Entwicklungen. Das Ziel des CVE-Import-Tools ist es, dass frei verfügbare CVEVerzeichnis lokal abzuspeichern und aktualisieren zu können. Die Weiterentwicklung der 1. Ausbaustufe ist das CVE-Research-Tool. Es nutzt die bereits implementierten Funktionen des CVE-Import-Tools und muss diese jedoch um mehrere Suchfunktionen und eine Softwareprofilerstellung erweitern. Zusätzlich soll eine detaillierte Ansicht aller Informationen zu einem CVE-Eintrag ermöglicht werden. Die letzte Ausbaustufe bildet das Software-VulnerabilityTool. Dieses greift die Funktion der Profilsuche und der Profilerstellung des CVE-ResearchTools auf. Die Anwendung hat das Ziel zusätzliche Statistiken zu einzelnen Profilen oder der gesamten Datenbank zu erzeugen. Zusätzlich soll das Software-Vulnerability-Tool es ermöglichen ein CPE-Verzeichnis zu importieren, um so eine größere Basis von CPE-Einträgen zur Erstellung von Profilen zu besitzen. 4.3.1 Datenbanktyp und Datenbankschema Es gibt mehrere Möglichkeiten das CVE-Verzeichnis lokal zu sichern. In dieser Arbeit wurde sich für eine SQLite Datenbank entschieden. Dies bietet die Vorteile, dass: • • • • • kein Datenbankserver notwendig ist (keine Client-Server-Architektur notwendig), die gesamte Datenbank sich in einer Datei befindet, wodurch diese einfach verteilt werden kann, die meisten SQL-Sprachbefehle unterstützt werden, im Gegensatz zu beispielsweise XML die Informationen strukturiert in Tabellen gespeichert werden, die Datenbankschnittstellen in vielen Programmiersprachen, wie beispielsweise Java oder C#, vorhanden sind. Wie in der Anforderung (A4) des Kapitels 4.2 beschrieben ist, müssen die Informationen der Standards klar getrennt voneinander sein. Dies hat zur Folge, dass normalerweise vermeidbare Redundanzen der Tabellenstruktur bewusst in Kauf genommen werden. Ein Beispiel hierfür sind die CVSS-Informationen eines CVE-Eintrags. Da ein CVE-Eintrag entweder keine oder genau eine CVSS-Bewertung besitzt, sollten diese Informationen in einer Tabelle erfasst werden. In dem entwickelten Datenbankschema ist dies jedoch bewusst in zwei Tabellen auf- Software-Vulnerability-Tool 36 geteilt worden, um eine strukturierte Trennung der Standards CVE, CVSS, CPE und CWE zu verwirklichen. Abbildung 14, Datenbankschema der SQLite Datenbank 4.3.2 CVE-Import-Tool – 1. Ausbaustufe Die erste Ausbaustufe muss das CVE-Verzeichnis in Form einer XML-Datei von der Webseite der NVD (NVD NIST) herunterladen. Die einzelnen CVE-Einträge der XML-Datei werden nacheinander ausgelesen und über eine selbst entwickelte Schnittstelle in die SQLite Datenbank geschrieben. Falls ein CVE-Eintrag bereits in der Datenbank vorhanden ist, muss dieser Eintrag aktualisiert werden. Der Importvorgang kann vom Benutzer jederzeit gestartet werden, wodurch die Datenbank auf dem aktuellsten Stand gehalten werden kann. Abbildung 15, Darstellung der Funktionsweise des CVE-Import-Tools Software-Vulnerability-Tool Abbildung 16, Startbildschirm des CVE-Import-Tools Abbildung 17, Einstellungen des CVE-Import-Tools Abbildung 18, Importvorgang des CVE-Import-Tools 37 Software-Vulnerability-Tool 38 4.3.3 CVE-Research-Tool – 2. Ausbaustufe Das CVE-Research-Tool basiert auf dem CVE-Import-Tool, weswegen die Funktionsweise des CVE-Imports übernommen wird. Das Tool ermöglicht es, ein Softwareprofil (eine Liste von CPE-Einträgen) zu erstellen und lokal auf dem Rechner als XML-Datei zu sichern. Dieses Profil kann im Nachhinein geladen und bearbeitet werden. Die Hauptfunktion des Tools ist die Suche nach CVE-Einträgen anhand von Suchkriterien wie beispielsweise eine CVE-ID oder anhand eines Softwareprofils. Die Suche nutzt eine selbst entwickelte Schnittstelle zur Interaktion mit der SQLite Datenbank. Abbildung 19, Darstellung der Funktionsweise des CVE-Research-Tools Software-Vulnerability-Tool Abbildung 20, Startbildschirm des CVE-Research-Tools Abbildung 21, Profilerstellung und –bearbeitung im CVE-Research-Tool 39 Software-Vulnerability-Tool 40 Abbildung 22, Detailansicht eines CVE-Eintrags im CVE-Research-Tool 4.3.4 Software-Vulnerability-Tool – 3. Ausbaustufe Aufbauend auf dem CVE-Research-Tool wurde das Software-Vulnerability Tool entwickelt. Dieses besitzt, zu den gesamten bereits im CVE-Research-Tool implementierten Funktionen, die Möglichkeit ein CPE-Verzeichnis, beispielsweise das öffentlich verfügbare Verzeichnis der NVD, zu importieren, um dadurch auf eine größere Basis an CPE-Einträgen zurückgreifen zu können und das in Kapitel 6.2.4 beschriebene Problem zu minimieren. Des Weiteren wurde eine Funktionalität hinzugefügt, die es ermöglicht inkonsistente CVEs, das heißt CVEEinträge, denen keinen CPE-Namen zugeordnet ist, aufzulisten und im Detail zu betrachten. Es können zusätzlich drei verschiedene Statistiken zu einer Datenbank oder zu einem CPEProfil generiert werden. Eine Statistik dient dazu, die Anzahl der pro Jahr veröffentlichten CVE-Einträge grafisch darzustellen. Die Zweite Statistik kann die Verteilung des CVSSScores aufzeigen. Dafür wird der CVSS-Wertebereich von 0 bis 10 in kleinere Bereiche wie beispielsweise von 4 bis 5 aufgeteilt. Anschließend kann für jeden Bereich die Anzahl der CVEs, die einen entsprechenden CVSS-Base-Score besitzen, grafisch dargestellt werden. Die dritte Statistik zeigt die Häufigkeit von verwendeten CWE-IDs. Dies bedeutet, dass die Anzahl der CVEs dargestellt wird, die eine bestimmte CWE-ID nutzen, um so zu verdeutlichen, welche CWE-IDs am häufigsten verwendet werden. Software-Vulnerability-Tool Abbildung 23, Darstellung der ein- und ausgehenden Daten des Software-Vulnerability-Tools Abbildung 24, Startbildschirm des Software-Vulnerability-Tools 41 Software-Vulnerability-Tool Abbildung 25, Überarbeitete Einstellungen des Software-Vulnerability-Tools Abbildung 26, Ansicht der inkonsistenten CVEs im Software-Vulnerability-Tool 42 Software-Vulnerability-Tool 43 4.4 Entwicklung Bei der Realisierung der Tools wurde sich für einen modularen Aufbau der Softwarekomponenten entschieden. Dies bietet den Vorteil, dass verschiedene Softwarekomponenten wiederverwendet, jedoch unabhängig voneinander entwickelt werden können. Die Interaktion der verschiedenen Komponenten ist durch definierte Schnittstellen sichergestellt. Ein Beispiel hierfür ist die Interaktion mit der SQLite Datenbank. Die eigentliche Bibliothek dafür ist die System.Data.SQLite (Hwaci 2015). Da jedoch der Quellcode, welcher die Datenbankinteraktion enthält, wie beispielsweise das Hinzufügen eines CVE-Eintrags in die Datenbank, getrennt vom Rest des Projektes sein soll, wurde eine eigene Klassenbibliothek erstellt. Diese stellt Funktionen und Klassen bereit mit denen unkompliziert mit der SQLite Datenbank mit dem in Kapitel 4.3.1 definierten Datenbankschema interagiert werden kann. Die gesamte Entwicklung wird aufgrund der bereits vorhandenen Programmierkenntnisse in der Programmiersprache C# durchgeführt. Als Entwicklungsumgebung wird Visual Studio 2013 genutzt. Die verschiedenen Ausbaustufen werden alle als Windows Presentation Foundation Projekt, kurz WPF-Projekt, realisiert, welche das .NET-Framework in der Version. 4.5 nutzen. Ergebnisse 44 5 Ergebnisse 5.1 Ergebnisse des Secunia PSI In den 90 Tagen vom 23.08.2015 bis zum 20.11.2015 wurden insgesamt 19 Warnungen/Sicherheitslücken von Secunia PSI registriert und dokumentiert. Falls es möglich war, wurde auf eine Meldung einer Warnung die betroffene Softwareanwendung aktualisiert, sodass die Warnung von Secunia PSI nicht mehr erscheint und neue Sicherheitslücken gemeldet werden konnten. Datum Software bisherige Version sichere Version Kritikalität 23.08.2015 TrueCrypt 7.1.1.0 Product Discontinued End of life 30.08.2015 Mozilla Firefox 40.0.2.5702 40.0.3.5716 4/5 02.09.2015 Google Chrome 44.0.2403.157 45.x End of life 09.09.2015 .NET Framework 4.0.30319.34209 - 3/5 11.0.9600.17937 - 4/5 Windows 7 Enterprise - 4/5 09.09.2015 Microsoft Internet Explorer Windows 7 18.09.2015 Apple iTunes 12.2.2.25 12.3.0 4/5 24.09.2015 Mozilla Firefox 40.0.3.5716 41.x / 38.x (esr) End of life 15.10.2015 Google Chrome 45.0.2454.101 46.x End of life 15.10.2015 Adobe Acrobat Reader 15.8.20082.15957 2015.009.20069 4/5 19.10.2015 Mozilla Firefox 41.0.1.5750 41.0.2 / 38.x (esr) 3/5 23.10.2015 Java Runtime Environment 8.0.51.16 8u65 4/5 23.10.2015 Apple iTunes 12.3.0.44 12.3.1 4/5 02.11.2015 Apache OpenOffice 4.0.97774.500 4.1.2 4/5 05.11.2015 Mozilla Firefox 41.0.2.5765 42.x / 38.x (esr) End of life 10.11.2015 PuTTY 0.65.0.0 0.66.0.0 3/5 11.11.2015 Google Chrome 46.0.2490.80 46.0.2490.86 4/5 11.11.2015 Adobe Flash Player 19.0.0.226 19.0.0.245 4/5 12.11.2015 Windows 7 Windows 7 Enterprise - 4/5 09.09.2015 Tabelle 12, Von Secunia PSI gemeldete Sicherheitswarnungen Handlung keine Möglich Update auf Version 40.0.3.5716 Update auf Version 45.0.2454.101 Update auf Version 4.5.51209 Update auf Version 11.0.9600.18098 Update Update auf Version 12.3.0.44 Update auf Version 41.0.0.5750 Update auf Version 46.0.2490.71 Update auf Version 15.9.20077.29851 Update auf Version 41.0.2.5765 Update auf Version 8.0.650.17 Update auf Version 12.3.1.23 Update auf Version 4.0.9782.500 Update auf Version 42.0.0.5780 Update auf Version 0.66.0.0 Update auf Version 46.0.2490.86 Update auf Version 19.0.0.245 Update Ergebnisse 45 Zu manchen Sicherheitswarnungen von Secunia PSI existieren zusätzliche Informationen auf der Secunia Webseite. Im Folgenden sind beispielhaft Sicherheitswarnungen aufgeführt, bei denen dies zutrifft: 09.09.2015, .NET-Framework Abbildung 27, Detaillierte Informationen zur Warnung bezüglich des –NET-Frameworks am 09.09.2015 9 12.11.2015, Windows 7 Abbildung 28, Detaillierte Informationen zur Warnung bezüglich Windows 7 am 12.11.2015 10 9 https://secunia.com/advisories/66386 https://secunia.com/advisories/67337 10 Ergebnisse 15.10.2015, Acrobat Reader Abbildung 29, Detaillierte Informationen zur Warnung bezüglich Acrobat Reader am 15.10.2015 11 11 https://secunia.com/advisories/66814 46 Ergebnisse 47 5.2 Ergebnisse des CVE-Tools Bei der Suche nach passenden CVEs zu den Anwendungen aus dem Softwareprofil mussten zunächst über das Tool die passenden CPE-Einträge gefunden werden. Falls keine passenden Einträge gefunden wurden, kann davon ausgegangen werden, dass noch keine Sicherheitslücken zu der gesuchten Anwendung veröffentlicht wurden, beziehungsweise die Anwendung im CPE-Verzeichnis fehlt. Der Grund für die Aufführung von vermuteten und gefundenen CPE wird dem in Kapitel 6.2.4 beschriebenen Problem deutlich. In manchen Fällen wurden mehrere unterschiedliche Versionen einer Anwendung geprüft, was daran liegt, dass wenn Secunia PSI eine Schwachstelle gefunden hat, ein Update auf die aktuellste Version der entsprechenden Anwendung gemacht werden musste, damit Secunia neue Schwachstellen für die Softwareanwendung anzeigt. Dadurch wurden im Laufe des Testzeitraums mehrere Versionen überprüft. Softwareanwendung Version .NET Framework 4.0.30319.34209 4.5.51209 7-Zip 9.20 Adobe Flash Player 18.0.0.232 19.0.0.226 19.0.0.245 Adobe Reader AdwCleaner Apache OpenOffice Apple iTunes Ccleaner CDBurnerXP FileZilla Gimp 15.008.20082 15.009.20077 5.0.0.3 4.0.9774.500 / 4.11.9774 4.0.9782.500 / 4.12.9782 12.2.2.25 12.3.0.44 12.3.1.23 5.8.0.5308 4.5.5.5790 3.13.0 2.8.14 gefundene CPE cpe:/a:microsoft:.net_framework:4.0 cpe:/a:microsoft:.net_framework:4.5 cpe:/a:7-zip:7-zip:9.20 cpe:/a:7-zip:7-zip:9.20::~~~~x64~ cpe:/a:adobe:flash_player:18.0.0.232 cpe:/a:adobe:flash_player:19.0.0.226 keine cpe:/a:adobe:acrobat_reader_dc:2015.008.20082::~~ continuous~~~ vermutete CPE cpe:/a:adobe:flash_player:19.0.0.245 Anzahl CVEs 56 41 0 0 23 17 0 Zeitraum der CVEVeröffentlichung 10.04.2012 bis 11.11.2015 22.09.2015 11.11.2015 - 58 15.10.2015 bis 04.11.2015 keine keine cpe:/a:adobe:acrobat_reader_dc:2015.009.20077::~~ continuous~~~ keine 0 - - cpe:/a:apache:openoffice:4.1.1 - 5 28.04.2015 bis 10.11.2015 keine cpe:/a:apple:itunes:12.2 cpe:/a:apple:itunes:12.3.0 keine keine keine keine keine cpe:/a:apache:openoffice:4.1.2 cpe:/a:apple:itunes:12.3.1 cpe:/a:piriform:ccleaner:5.08.5308 cpe:/a:impressum:cdburnerxp:4.5.5.5790 cpe:/a:filezilla:filezilla:3.13.0 cpe:/a:gimp:gimp:2.8.14 Tabelle 13, Gefundene Sicherheitslücken zu Anwendungen aus dem Softwareprofil, Teil 1 0 63 12 0 0 0 0 0 08.05.2015 bis 18.09.2015 23.10.2015 - Ergebnisse Softwareanwendung 48 Version gefundene CPE 44.0.2403.155 44.0.2403.157 45.0.2454.101 Google Chrome 46.0.2490.71 46.0.2490.80 46.0.2490.86 IrfanView 4.40 8.0.51.16 Java Runtime Environment 8.0.650.17 KMPlayer 3.9.1.138 Microsoft Internet Explorer 11.0.9600.17937 11.0.9600.18098 Microsoft Silverlight 5.1.40728.0 40.0.2.5702 40.0.3.5716 Mozilla Firefox 41.0.1.5750 41.0.2.5765 42.0.0.5780 cpe:/a:google:chrome:44.0.2403 cpe:/a:google:chrome:44.0.2403 cpe:/a:google:chrome:45.0.2454.101 keine cpe:/a:google:chrome:46.0.2490.80 keine keine cpe:/a:oracle:jre:1.8.0:update_51 keine keine cpe:/a:microsoft:internet_explorer:11:cpe:/a:microsoft:internet_explorer:11:keine cpe:/a:mozilla:firefox:40.0.2 cpe:/a:mozilla:firefox:40.0.3 cpe:/a:mozilla:firefox:41.0.1 cpe:/a:mozilla:firefox:41.0.2 keine Notepad++ PDFCreator Putty Recuva Skype TrueCrypt VLC Player Windows 7 WinRAR keine keine keine keine keine keine cpe:/a:videolan:vlc_media_player:2.2.1 siehe Übersicht der Ergebnisse für Windows 7 keine 6.7.9.2 2.1.2.884 0.65 1.52.0.1086 7.15.0.102 7.1.1.0 2.2.1 64-Bit 5.21 vermutete CPE cpe:/a:google:chrome:45.0.2454.101 cpe:/a:google:chrome:46.0.2490.86 cpe:/a:irfanview:irfanview:4.40 cpe:/a:oracle:jre:1.8.0:update_650 cpe:/a:kmplayer:kmplayer:3.9.1.138 cpe:/a:microsoft:silverlight:5.1.40728.0 cpe:/a:mozilla:firefox:42.0.0 cpe:/a:notepad_plus_plus:notepad%2b%2b:6.7.9. 2 cpe:/a:pdfforge:pdfcreator:2.1.2 cpe:/a:putty:putty:0.65 cpe:/a:piriform:recuva:1.52 cpe:/a:skype:skype:7.15.0.102 cpe:/a:truecrypt_foundation:truecrypt:7.1.1 cpe:/a:rarlab:winrar:5.21 Tabelle 14, Gefundene Sicherheitslücken zu Anwendungen aus dem Softwareprofil, Teil 2 Zeitraum der CVEVeröffentlichung 15 04.09.2015 15 04.09.2015 10 15.10.2015 01 11.11.2015 0018 21.10.2015 bis 22.10.2015 00341 11.12.2013 bis 11.11.2015 341 11.12.2013 bis 11.11.2015 02 29.08.2015 28 24.09.2015 1 18.10.2015 2 05.11.2015 0- Anzahl CVEs 0000001 25.08.2015 30 09.09.2015 bis 11.11.2015 0- Ergebnisse 49 Für die folgenden Anwendungen existierten bereits CPEs, jedoch stimmte die entsprechende Versionsangabe nicht mit der installierten Version überein. Dies bedeutet, dass für diese Softwareanwendungen noch keine Sicherheitslücken veröffentlicht wurden. Die Anwendungen sind: • • • • • • • • • • • • • • Ccleaner CDBurnerXP FileZilla GIMP IrfanView KMPlayer Microsoft Silverlight Notepad++ PDFCreator PuTTY Recuva Skype TrueCrypt WinRAR Für die restlichen Anwendungen wurden entweder CVE-Einträge gefunden, oder es sind Sonderfälle eingetreten. .NET Framework Durch Secunia PSI wurde am 09.09.2015 ein Update auf die Version 4.5.51209 durchgeführt. Aus diesem Grund wurde die entsprechende CPE dieser Version ebenfalls überprüft. Beim .NET-Framework ist ein Problem aufgetreten, welches im Detail in Kapitel 6.2.4 beschrieben wird. cpe:/a:microsoft:.net_framework:4.0 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 56 8.1 22.09.2010 11.11.2015 Tabelle 15, Übersicht über CVE-Ergebnisse des .NET-Frameworks 4.0 cpe:/a:microsoft:.net_framework:4.5 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 41 8.1 10.04.2012 11.11.2015 Tabelle 16, Übersicht über CVE-Ergebnisse des .NET-Frameworks 4.5 7-Zip In 7-Zip ist ein Sonderfall aufgetreten, in denen eine CPE-ID für die Softwareanwendung existiert, jedoch keine Sicherheitslücken für diesen zugeordnet sind. Dies bedeutet, dass die folgenden CPEs in das von der NVD bereitgestellte CPE-Verzeichnis eingetragen wurden, obwohl keine Sicherheitslücke für diese Version existiert: • cpe:/a:7-zip:7-zip:9.20 • cpe:/a:7-zip:7-zip:9.20::~~~~x64~ Ergebnisse 50 Adobe Flash Player Zu Beginn der Überprüfung wurde der Adobe Flash Player in der Version 18.0.0.232 installiert. Durch verschiedene Aktualisierungen müssen auch die Versionen 19.0.0.226 und 19.0.0.245 geprüft werden. Erwähnenswert ist, dass von den gefundenen 40 Sicherheitslücken 23 einen CVSS-Base-Score von 10.0, und 35 einen CVSS-Base-Score von mindestens 9.3 besitzen. cpe:/a:adobe:flash_player:18.0.0.232 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 23 9.1 22.09.2015 22.09.2015 Tabelle 17, Übersicht über CVE-Ergebnisse des Adobe Flash Players 18.0.0.232 cpe:/a:adobe:flash_player:19.0.0.226 Anzahl CVEs durchschnittlicher CVSS-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 17 9.4 11.11.2015 11.11.2015 Tabelle 18, Übersicht über CVE-Ergebnisse des Adobe Flash Players 19.0.0.226 Adobe Acrobat Reader Durch verschiedene Angaben der Versionsnummer in Secunia PSI (15.8.20082.15957) und der Windows-Systemsteuerung (15.008.20082) war es kompliziert die passende CPE-ID zu bestimmen. Erschwerend kommt hinzu, dass Adobe die Versionsbenennung des AcrobatReaders im Juli verändert hat. Ohne manuelle Suche der CPEs in der Profilerstellung des Software-Vulnerability-Tools, wäre es nicht möglich gewesen die CPE-ID korrekt zu bestimmen. cpe:/a:adobe:acrobat_reader_dc:2015.008.20082::~~continuous~~~ Anzahl CVEs 58 durchschnittlicher CVSS-Base-Score 8.3 früheste Veröffentlichung eines CVE 15.10.2015 späteste Veröffentlichung eines CVE 04.11.2015 Tabelle 19, Übersicht über CVE-Ergebnisse des Adobe Acrobat Readers 2015.008.20082 AdwCleaner Zum Programm AdwCleaner wurden keine passenden CPE-IDs gefunden. Dies bedeutet, dass entweder noch nie Sicherheitslücken für AdwCleaner veröffentlicht wurden, oder dass die Anwendung generell nicht im CVE/CPE-Verzeichnis erfasst wird. Apache OpenOffice Ähnlich wie beim Adobe Acrobat Reader war es nur möglich die korrekte CPE-ID manuell im Software-Vulnerability-Tool zu bestimmen, da Secunia PSI (4.0.9774.500) und die Windows Systemsteuerung (4.11.9774) unterschiedliche Versionsangaben für Apache OpenOffice besitzen. Die Versionsnummer in der CPE lautet 4.1.1. cpe:/a:apache:openoffice:4.1.1 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 5 6.3 28.04.2015 10.11.2015 Ergebnisse 51 Tabelle 20, Übersicht über CVE-Ergebnisse von Apache OpenOffice 4.1.1 Apple iTunes Die gefundenen CPEs für Apples iTunes sind bezüglich der Versionsnummer nicht so genau wie die Versionsangabe in Secunia PSI oder der Windows Systemsteuerung. So wurde für die Version 12.2.2.25 nur ein CPE-Eintrag mit der Versionsnummer 12.2 und für die Version 12.3.0.44 nur ein Eintrag mit der Versionsnummer 12.3.0 gefunden. cpe:/a:apple:itunes:12.2 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 63 7.8 28.04.2015 10.11.2015 Tabelle 21, Übersicht über CVE-Ergebnisse von Apple iTunes 12.2.2.25 cpe:/a:apple:itunes:12.3.0 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 12 7.0 23.10.2015 23.10.2015 Tabelle 22, Übersicht über CVE-Ergebnisse von Apple iTunes 12.3.0.44 Google Chrome CPEs von Google Chrome sind in der Angabe der Version sind nicht immer so detailliert wie die Versionsangabe in Secunia PSI oder der Windows Systemsteuerung. So konnte beispielsweise für die Versionen 44.0.2403.155 und 44.0.2403.157 nur die gleiche CPE-Version manuell zugeordnet werden: 44.0.2403. Anders ist es bei der Version 45.0.2454.101. In diesem Fall existiert eine CPE-ID mit der genauen Versionsangabe: „cpe:/a:google:chrome:45.0.2454.101“. cpe:/a:google:chrome:44.0.2403 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 15 6.5 04.09.2015 04.09.2015 Tabelle 23, Übersicht über CVE-Ergebnisse von Google Chrome 44.0.2403.X cpe:/a:google:chrome:45.0.2454.101 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 10 7.0 15.10.2015 15.10.2015 Tabelle 24, Übersicht über CVE-Ergebnisse von Google Chrome 45.0.2454.101 cpe:/a:google:chrome:46.0.2490.80 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 1 7.3 11.11.2015 11.11.2015 Tabelle 25, Übersicht über CVE-Ergebnisse von Google Chrome 46.0.2490.80 Ergebnisse 52 Java Runtime Environment Die im Software-Vulnerability-Tool manuell gesuchte, passende CVE-ID besitzt in der Versionsnummer andere Angaben als die Versionsnummer in Secunia PSI und der Windows Systemsteuerung. Ohne manuelles Bestimmen der CPE-ID wäre eine korrekte Zuordnung nicht möglich gewesen. Version: 8.0.51.16, CPE: cpe:/a:oracle:jre:1.8.0:update_51 cpe:/a:oracle:jre:1.8.0:update_51 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 18 7.2 21.10.2015 22.10.2015 Tabelle 26, Übersicht über CVE-Ergebnisse der Java Runtime Environment 1.8.0 Update 51 Microsoft Internet Explorer Ähnlich wie bei dem .NET-Framework ist auch bei Microsofts Internet Explorer die Versionsangabe in CPEs viel zu ungenau, weswegen eine Zuordnung von Sicherheitslücken zu bestimmten Versionen des Internet Explorers nur bedingt möglich ist. Alle Sicherheitslücken der Internet Explorer Versionen 11.X werden in der CPE „cpe:/a:microsoft:internet_explorer:11:-“ erfasst. cpe:/a:microsoft:internet_explorer:11:Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 341 8.6 11.12.2013 13.11.2015 Tabelle 27, Übersicht über CVE-Ergebnisse des Microsoft Internet Explorer 11.X Mozilla Firefox Die für Mozilla Firefox gefundenen CPEs, besitzen nicht so detaillierte Versionsnummern wie die Angaben in Secunia PSI oder der Windows Systemsteuerung. Jedoch sind die Angaben detailliert genug, um genau zwischen den verschiedenen Firefox Versionen unterscheiden zu können. Bsp.: Version: 40.0.2.5702 entspricht der CPE: cpe:/a:mozilla:firefox:40.0.2 cpe:/a:mozilla:firefox:40.0.2 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 2 8.8 29.08.2015 29.08.2015 Tabelle 28, Übersicht über CVE-Ergebnisse von Mozilla Firefox 40.0.2.X cpe:/a:mozilla:firefox:40.0.3 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 28 6.5 24.09.2015 24.09.2015 Tabelle 29, Übersicht über CVE-Ergebnisse von Mozilla Firefox 40.0.3.X Ergebnisse 53 cpe:/a:mozilla:firefox:41.0.1 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 1 6.8 18.10.2015 18.10.2015 Tabelle 30, Übersicht über CVE-Ergebnisse von Mozilla Firefox 41.0.1.X cpe:/a:mozilla:firefox:41.0.2 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 2 6.3 05.11.2015 05.11.2015 Tabelle 31, Übersicht über CVE-Ergebnisse von Mozilla Firefox 41.0.2.X VLC Player Für die Anwendung VLC Player wurde ein CVE-Eintrag gefunden. Die Zuordnung zu einem passenden CPE war ohne Probleme möglich. cpe:/a:videolan:vlc_media_player:2.2.1 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 1 6.8 25.08.2015 25.08.2015 Tabelle 32, Übersicht über CVE-Ergebnisse VLC Players 2.2.1 Windows 7 Zur Überprüfung von Windows 7 musste ein Zeitraum angegeben werden, da Windows 7 keine Versionsbezeichnung in den CPEs führt. Die CPEs, welche über den Veröffentlichungszeitraum vom 23.08.2015 bis zum 20.11.2015 überprüft wurden sind: • • • • • • • • • • cpe:/o:microsoft:windows_7 cpe:/o:microsoft:windows_7::sp1 cpe:/o:microsoft:windows_7::sp1:~~~~x64~ cpe:/o:microsoft:windows_7::sp1:x64 cpe:/o:microsoft:windows_7:::x64 cpe:/o:microsoft:windows_7:::~~~~x64~ cpe:/o:microsoft:windows_7:-:sp1 cpe:/o:microsoft:windows_7:-:sp1:x64 cpe:/o:microsoft:windows_7:-:sp1:~~~~x64~ cpe:/o:microsoft:windows_7:-:-:x64 Windows 7 Anzahl CVEs durchschnittlicher CVSS-Base-Score früheste Veröffentlichung eines CVE späteste Veröffentlichung eines CVE 30 7,5 09.09.2015 11.11.2015 Tabelle 33, Übersicht über CVE-Ergebnisse Windows 7 Ergebnisse 54 5.3 Vergleich der beiden Ergebnisse Secunia bietet über ihre Webseite weitere Informationen zu von Secunia PSI gefundenen Sicherheitswarnungen. Diese zusätzlichen Informationen beinhalten zugeordnete CVE-IDs, wodurch die Ergebnisse von Secunia PSI und dem Software-Vulnerability-Tool sehr gut verglichen werden können. Anzahl CVEs Software Adobe Flash Player Version 18.0.0.232 Secunia PSI gefunden korrigiert 0 0 SoftwareVulnerability-Tool 23 19.0.0.226 17 17 17 Acrobat Reader 2015.008.20082 56 57 58 Apache OpenOffice 4.1.1 Apple iTunes 1 5 5 12.2.2.25 66 63 63 12.3.0.44 12 12 12 0 0 15 45.0.2454.101 0 0 10 46.0.2490.80 18 1 1 8.0.51.16 18 44.0.2405.157 Google Chrome Java Runtime Environment 25 18 40.0.2.5702 2 2 2 40.0.3.5716 0 0 28 41.0.1.5750 1 1 1 41.0.2.5765 0 0 2 PuTTY 0.65 1 0 0 VLC Player 2.2.1 0 0 1 Windows 7 SP1 - 64-Bit 4 4 30 203 180 286 Mozilla Firefox = Anzahl identisch = Anzahl unterschiedlich Tabelle 34, Vergleich der Anzahl der gefundenen CVEs zwischen Secunia PSI und dem SoftwareVulnerability-Tool In Tabelle 34 ist die Anzahl der gefundenen CVEs zu einer bestimmten Anwendung dargestellt. Die Tabelle enthält keine Einträge über das .NET-Framework und den Microsoft Internet Explorer, obwohl zu diesen Sicherheitslücken gefunden wurden. Der Grund dafür ist, dass das Software-Vulnerability-Tool bei beiden Anwendungen, aufgrund der zu ungenauen Versionsangabe in CPE-Einträgen, keine Überprüfung von bestimmten Versionen durchführen kann, da Sicherheitslücken für mehrere Versionen unter einer CPE-ID zusammengefasst werden. Durch diese Zusammenfassung ist ein Vergleich der Ergebnisse für das .NETFramework und den Internet Explorer nicht möglich. Beispiel: Secunia PSI [.NET-Framework 4.0.30319.34209]-> 2 CVEs im Vergleich zum Software-Vulnerability-Tool [.NET-Framework 4.0] -> 56 CVEs Ergebnisse 55 Bei CPE-Einträgen des Betriebssystems Windows 7 existieren keine Versionsangaben. Hier besteht jedoch die Möglichkeit durch Eingrenzung des Überprüfungszeitraums im SoftwareVulnerability-Tool nach entsprechenden CVEs zu suchen. Secunia PSI besitzt das Problem, dass wenn ein großer Versionssprung ansteht, es die Kritikalität „end of life“ anzeigt, obwohl Sicherheitslücken zu der installierten Version vorhanden sind. Zusätzlich gibt Secunia in vier Fällen (Apple iTunes, Google Chrome, Java Runtime Environment und PuTTY) falsche CVE-IDs an. Im Fall des VLC Players in der Version 2.2.1 erkennt Secunia PSI eine bereits bekannte Sicherheitslücke nicht. Dies könnte eventuell daran liegen, dass für den VLC Player noch kein Update für eine neuere Version zur Verfügung steht, was bedeuten würde, dass Secunia PSI nur Warnungen für Anwendungen ausgibt, wenn für diese ein Update oder Patch bereitsteht. Aufgrund dieser Vermutung wurde Secunia kontaktiert und um Aufklärung gebeten, jedoch wurde im Zeitrahmen dieser Bachelor Abschlussarbeit nicht mehr rechtzeitig auf diese Anfrage geantwortet (siehe Kapitel 9.3). Sicherheitslücken gefunden in Software-Vulnerability-Tool Softwareanwendung Secunia PSI .NET Framework 7-Zip Adobe Flash Player Adobe Reader AdwCleaner Apache OpenOffice Apple iTunes Ccleaner CDBurnerXP FileZilla Gimp Ja Nein Problem durch Update auf neuere Version Ja Nein Ja Angabe falscher CVEs Nein Nein Nein Nein Problem durch Update auf neuere Version Angabe falscher CVEs Nein Angabe falscher CVEs Nein Ja Nein Problem durch Update auf neuere Version Nein Nein Angabe falscher CVE Nein Nein Nein Nein Ja Nein Google Chrome IrfanView Java Runtime Environment KMPlayer Microsoft Internet Explorer Microsoft Silverlight Mozilla Firefox Notepad++ PDFCreator Putty Recuva Skype TrueCrypt VLC Player Windows 7 WinRAR zu ungenaue Versionsangabe in CPE Nein Ja Ja Nein Ja Ja Nein Nein Nein Nein Ja Nein Ja Nein zu ungenaue Versionsangabe in CPE Nein Ja Nein Nein Nein Nein Nein Nein Ja Ja Nein Tabelle 35, Vergleich der Ergebnisse von Secunia PSI und dem Software-Vulnerability-Tools Ergebnisse 56 5.3.1 Detaillierter Vergleich einzelner Softwareanwendungen Im Folgenden werden die Ergebnisse von betroffenen Softwareanwendungen detailliert miteinander verglichen. .NET Framework Die Ergebnisse des .NET-Frameworks können nicht direkt miteinander verglichen werden. Dies liegt daran, dass bei der Suche nach CVEs die CPE-Angabe für das .NET-Framework zu allgemein ist. Da alle Sicherheitslücken der .NET-Framework Versionen 4.0.X unter der CPE „cpe:/a:microsoft:.net_framework:4.0“ zusammengefasst werden, können für die installierte Version 4.0.30319.34209 insgesamt 56 Sicherheitslücken, die seit 22.09.2010 veröffentlicht wurden, gefunden werden. Das Problem hierbei ist, dass jede Version bei der die Versionsnummer mit 4.0 beginnt, diese 56 Sicherheitslücken zugeordnet sind. Dadurch ist für das .NET-Framework keine Bewertung einzelner Versionen möglich. In Kapitel 6.2.4 wird das Problem nochmals im Detail erläutert. Adobe Flash Player Es wurde ein automatisches Update von Version 18.0.0.232 auf 19.0.0.226 durchgeführt, weswegen Secunia PSI keine Sicherheitslücken zu dieser Version finden konnte, beziehungsweise nicht die benötigte Zeit hatte diese zu ermitteln. Die CVE-Einträge wurden am 22.09.2015 veröffentlicht. Falls der Adobe Flash Player das automatische Update beispielsweise am 01.09.2015 durchgeführt hat, war zum Zeitpunkt der Veröffentlich bereits eine andere Version des Adobe Flash Players installiert, wodurch Secunia PSI entsprechend nicht mehr die Version 18.0.0.232 überwachte. Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Secnuia PSI Software-Vulnerability-Tool Adobe Flash Player 18.0.0.232 22.09.2015 23 9.1 / 10.0 Adobe Flash Player 19.0.0.226 11.11.2015 10.11.2015 (laut Secunia) 11.11.2015 17 17 4/5 9.4 / 10.0 Tabelle 36, Vergleich der Ergebnisse des Adobe Flash Player zwischen Secunia PSI und dem SoftwareVulnerability-Tool Ergebnisse 57 Adobe Acrobat Reader In Folge der Dokumentation der aufgetretenen Schwachstellen am 15.10.2015 wurde Adobe Acrobat Reader aktualisiert. Da jedoch am 04.11.2015 die Sicherheitslücke „CVE-20157650“ zu der Version 2015.008.20082 veröffentlich wurde, fehlte diese zunächst in der Tabelle. Nach einer erneuten Überprüfung der Secunia-Webseite (Secunia) wurde festgestellt, dass diese CVE-ID entsprechend hinzugefügt wurde. Der einzige Unterschied zwischen Secunia PSI und der Überprüfung durch das Software-Vulnerability-Tool ist, dass die Sicherheitslücke „CVE-2015-7829“ bei Secunia nicht angegeben ist. Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Secnuia PSI Software-Vulnerability-Tool Adobe Acrobat Reader 2015.008.20082 15.10.2015 13.10.2015 (laut Secunia) 15.10.2015 bis 04.11 2015 56 (bzw. 57) 58 4/5 8.3 / 10.0 Tabelle 37, Vergleich der Ergebnisse des Adobe Acrobat Readers zwischen Secunia PSI und dem Software-Vulnerability-Tool Apache OpenOffice Aufgrund der Aktualisierung von OpenOffice in Folge der Dokumentation der Sicherheitslücke fehlten die am 10.11.2015 veröffentlichten Sicherheitslücken bei Secunia PSI. Nach einer Kontrolle der Secunia-Webseite wurde jedoch festgestellt, dass die am 10.11.2015 hinzugefügten CVE-Einträge jedoch dem Ergebnis zugeordnet worden. Dadurch bestehen keinerlei Unterschiede zwischen den Ergebnissen. Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Secnuia PSI Software-Vulnerability-Tool Apache OpenOffice 4.1.1 02.11.2015 27.04.2015 (laut Secunia) 28.04.2015 bis 10.11.2015 1 (bzw. 5) 5 4/5 6.3 / 10.0 Tabelle 38, Vergleich der Ergebnisse von OpenOffice zwischen Secunia PSI und dem SoftwareVulnerability-Tool Ergebnisse 58 Apple iTunes Secunia PSI hat der Version 12.2.2.25 weitere CVEs zugeordnet. Diese drei weiteren CVEs haben jedoch keinen Bezug zu iTunes, weswegen hier von einem Fehler seitens Secunia ausgegangen werden muss. Die CVEs sind: • CVE-2010-3190 (Fehler in Microsoft Foundation Class, kurz MFC Bibliothek in Visual Studio) • CVE-2014-8146 (Fehler in der Implementierung des Unicode Bidirectional Algorithms in ICU4C in International Components for Unicode, kurz ICU) • CVE-2015-1205 (unspezifizierte Sicherheitslücken in Google Chrome) Bis auf die oben erwähnte Ausnahme stimmen die Ergebnisse von Secunia PSI und dem Software-Vulnerability-Tool über ein. Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Secnuia PSI Software-Vulnerability-Tool Apple iTunes 12.2.2.25 18.09.2015 17.09.2015 (laut Secunia) 08.05.2015 bis 18.09.2015 66 (ohne Falschzuordnung 63) 63 4/5 6.8 / 10.0 Apple iTunes 12.3.0.44 23.10.2015 22.10.2015 (laut Secunia) 23.10.2015 12 12 4/5 7.0 / 10.0 Tabelle 39, Vergleich der Ergebnisse von iTunes zwischen Secunia PSI und dem Software-VulnerabilityTool Ergebnisse 59 Google Chrome Bei der Überprüfung von Google Chrome ergeben sich einige Unterschiede zwischen den Ergebnissen von Secunia PSI und dem Software-Vulnerability-Tool. So werden bei den Versionen 44.0.2403.157 und 45.0.2454.101 keine Sicherheitslücken von Secunia gefunden, sondern lediglich Warnungen ausgegeben, dass bereits neuere Programmversionen existieren. Bei der Überprüfung mit dem Software-Vulnerability-Tool werden jedoch 15, beziehungsweise 10 Sicherheitslücken für die entsprechenden Versionen gefunden. Entweder wurde die Aktualisierung von Google Chrome zu früh durchgeführt, so dass die Sicherheitslücken nicht mehr zugeordnet werden konnten, oder Secunia hat diese Sicherheitslücken nicht aufgeführt. Eine Überprüfung der entsprechenden Versionen auf der Secunia Webseite ist nach der Testphase nicht möglich, da die spezifische, von Secunia zur Identifikationen von Schwachstellen definierte, ID nicht bekannt ist (anders als beim Acrobat Reader und OpenOffice). Bei der Version 46.0.2490.80 findet Secunia PSI 18 zugeordnete CVE-Einträge, während es bei dem Software-Vulnerability-Tool nur ein CVE-Eintrag ist. Der von beiden gefundene CVE-Eintrag lautet „CVE-2015-1302“. Bei den 17 anderen, von Secunia PSI zugeordneten, CVE-Einträgen handelt es sich um Sicherheitslücken bezüglich des Adobe Flash Players. Daher ist in diesem Fall von einer falschen Zuordnung seitens Secunia auszugehen. Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Secnuia PSI Software-Vulnerability-Tool Google Chrome 44.0.2403.157 02.09.2015 04.09.2015 15 End of life 6.5 / 10.0 Google Chrome 45.0.2454.101 15.10.2015 15.10.2015 10 End of life 7.0 / 10.0 Google Chrome 46.0.2490.80 11.11.2015 11.11.2015 (laut Secunia) 11.11.2015 18 (ohne Falschzuordnung 1) 1 4/5 7.5 / 10.0 Tabelle 40, Vergleich der Ergebnisse von Google Chrome zwischen Secunia PSI und dem SoftwareVulnerability-Tool Java Runtime Environment Die unterschiedliche Anzahl der gefundenen CVEs kommt dadurch zusammen, dass Secunia PSI auch CVE-Einträge angegeben, hat welche nicht explizit der Version „1.8 u51“ zugeordnet sind, sondern beispielsweise der Version „1.8 u60“. Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Secnuia PSI Software-Vulnerability-Tool Java Runtime Environment 8.0.51.16 23.10.2015 21.10.2015 (laut Secunia) 21.10.2015 bis 22.10.2015 25 (ohne Falschzuordnung 18) 18 4/5 7.2 / 10.0 Tabelle 41, Vergleich der Ergebnisse der Java Runtime Environment zwischen Secunia PSI und dem Software-Vulnerability-Tool Ergebnisse 60 Microsoft Internet Explorer Beim Microsoft Internet Explorer besteht das gleiche Problem wie beim .NET-Framework. Da alle Sicherheitslücken der Internet Explorer Versionen 11.X unter der CPE „cpe:/a:microsoft:internet_explorer:11:-“ zusammengefasst werden, können für die installierte Version 11.0.9600.17937 insgesamt 341 Sicherheitslücken, die seit 11.12.2013 veröffentlicht wurden, gefunden werden. Das Problem hierbei ist, dass jede Version, bei der die Versionsnummer mit 11 beginnt, diese 341 Sicherheitslücken zugeordnet sind. Dadurch ist für den Internet Explorer keine Bewertung einzelner Versionen anhand des CVE-Verzeichnisses möglich. (detaillierte Erläuterung in Kapitel 6.2.4). Mozilla Firefox In den Versionen 40.0.3.5716 und 41.0.2.5765 wurden keine Sicherheitslücken in Secunia PSI angezeigt, sondern lediglich der Hinweis, dass ein Update verfügbar ist. In den anderen beiden Versionen 40.0.2.5702 und 41.0.1.5750 sind die Ergebnisse identisch. Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Secnuia PSI Software-Vulnerability-Tool Mozilla Firefox 40.0.2.5702 30.08.2015 28.08.2015 (laut Secunia) 29.08.2015 2 2 4/5 8.8 / 10.0 Mozilla Firefox 40.0.3.5716 24.09.2015 24.09.2015 28 End of life 6.5 / 10.0 Mozilla Firefox 41.0.1.5750 19.10.2015 16.10.2015 (laut Secunia) 18.10.2015 1 1 3/5 6.8 / 10.0 Mozilla Firefox 41.0.2.5765 05.11.2015 05.11.2015 2 End of life 6.3 / 10.0 Tabelle 42, Vergleich der Ergebnisse von Mozilla Firefox zwischen Secunia PSI und dem SoftwareVulnerability-Tool Putty Secunia PSI hat im Gegensatz zum Software-Vulnerability-Tool für PuTTY eine Sicherheitslücke mit der Kritikalität von 3/5 am 10.11.2015 entdeckt. Die angegebene CVE-ID lautet „CVE-2015-5309“. Diese Angabe ist problematisch, da diese CVE-ID nicht im CVEVerzeichnis existiert. Die ID wurde eine Zeit lang reserviert, ist jedoch nie veröffentlicht und später aus dem CVE-Verzeichnis entfernt worden. Ergebnisse 61 VLC Player Für den VLC Player hat Secunia PSI, im Gegensatz zum Software-Vulnerability-Tool, keine Sicherheitslücken gefunden. Der vom Tool entdeckte CVE-Eintrag mit der ID „CVE-20155949“ wurde am 25.08.2015 veröffentlicht und besitzt einen CVSS-Base-Score von 6.8. Windows 7 Da für das Betriebssystem Windows 7 keine Versionsangaben in den CPE-Einträgen vorhanden sind, wurden alle zutreffenden CPEs (Windows 7 SP1 64-Bit) über den definierten Testzeitraum geprüft. Die Anzahl der gefundenen CVEs, zwischen Secunia PSI und dem Software Vulnerability-Tool, unterscheidet sich enorm. Zeitpunkt der Dokumentation Veröffentlichung Anzahl CVEs Einstufung Kritikalität Secnuia PSI Software-Vulnerability-Tool Windows 7 – SP1 – 64-Bit 12.11.2015 09.09.2015 08.09.2015 (laut Secunia) 10.11.2015 (laut Secunia) 09.09.2015 bis 11.11.2015 1 3 30 4/ 5 4/5 7.5 / 10.0 Tabelle 43, Vergleich der Ergebnisse von Windows 7 zwischen Secunia PSI und dem SoftwareVulnerability-Tool 5.4 Allgemeine Statistiken zum gespeicherten CVE-Verzeichnis Zum Zeitpunkt der Überprüfung (24.11.2015) befanden sich insgesamt 72.903 CVE-Einträge in der SQLite-Datenbank des Software-Vulnerability-Tools. Von diesen besitzen 72.846 eine Bewertung anhand eines CVSS-Eintrags und 41.239 eine Verknüpfung mit einer CWE-ID. Insgesamt sind 199.138 unterschiedliche CPEs in der Datenbank vorhanden. Es existieren 1.921.344 CVE-CPE-Verknüpfungen, die festlegen, welches Softwareprodukt welche Sicherheitslücke enthält. CPEs 15318 9077 174743 Anwendungen (a) Betriebssysteme (o) Hardware (h) Abbildung 30, Anteil der unterschiedlichen CPEs Der Großteil der in der Datenbank vorhandenen CPEs ist für Anwendungen. Dieser Anteil macht über 87% aller CPEs aus. Ergebnisse 62 Abbildung 31, Balkendiagramm der pro Jahr veröffentlichten CVE-Einträge Bei der Übersicht der pro Jahr veröffentlichten CVEs ist ein stetiger Anstieg bis 2007 zu erkennen. Anschließend geht die Anzahl der veröffentlichten Einträge zurück. Im Jahre 2014 wurden bislang die meisten CVEs in einem Jahr veröffentlicht. Abbildung 32, Balkendiagramm zu Verteilung des CVSS-Base-Scores Bei der Verteilung des CVSS-Base-Scores ist eine Konzentration in dem Bereich zwischen 4 und 8 zu erkennen. Auffällig ist außerdem die geringe Anzahl von CVEs mit einem CVSSBase-Score von größer als 8 und kleiner als 9. Ergebnisse CWE-ID CWE-79 CWE-119 CWE-264 CWE-89 CWE-20 CWE-399 CWE-200 CWE-310 CWE-94 CWE-22 CWE-189 CWE-352 CWE-287 CWE-255 CWE-59 CWE-362 CWE-16 CWE-78 CWE-134 CWE-284 CWE-17 CWE-254 CWE-19 CWE-77 CWE-74 CWE-345 CWE-18 CWE-199 CWE-21 63 Titel Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Improper Restriction of Operations within the Bounds of a Memory Buffer Permissions, Privileges, and Access Controls Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Improper Input Validation Resource Management Errors Information Exposure Cryptographic Issues Improper Control of Generation of Code ('Code Injection') Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Numeric Errors Cross-Site Request Forgery (CSRF) Improper Authentication Credentials Management Improper Link Resolution Before File Access ('Link Following') Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') Configuration Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Uncontrolled Format String Improper Access Control Code Security Features Data Handling Improper Neutralization of Special Elements used in a Command ('Command Injection') Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') Insufficient Verification of Data Authenticity Source Code Information Management Errors Pathname Traversal and Equivalence Errors Tabelle 44, Darstellung der am häufigsten genutzten CWE-IDs zugeordnet in 6284 CVEs 6168 CVEs 4299 CVEs 4140 CVEs 3468 CVEs 2598 CVEs 2347 CVEs 2213 CVEs 2060 CVEs 1823 CVEs 1291 CVEs 1103 CVEs 968 CVEs 580 CVEs 417 CVEs 346 CVEs 293 CVEs 180 CVEs 161 CVEs 158 CVEs 145 CVEs 105 CVEs 76 CVEs 53 CVEs 18 CVEs 13 CVEs 4 CVEs 2 CVEs 1 CVEs Ergebnisse 64 5.5 Interpretation der Ergebnisse Aus dem Vergleich der Ergebnisse von Secunia PSI mit den gefundenen CVEs aus dem Software-Vulnerability-Tool geht hervor, dass die Nutzung des CVE-Verzeichnisses zur Bestimmung der Kritikalität einer Software, mit wenigen Ausnahmen, sehr gut geeignet ist. So wurden bis auf einige falsche Zuordnungen seitens Secunia PSI alle Sicherheitslücken und –warnungen auch in dem lokal gespeicherten CVE-Verzeichnis gefunden, in manchen Fällen sogar mehr. Beim Zeitpunkt der Veröffentlichung der Sicherheitsmängel gibt es maximal bis zu einen Tag Verzug. Secunia PSI bietet unter einem Link zur Secunia-Webseite detaillierte Informationen für Nutzer an. Wenn man diese Funktionalität nicht nutzt und nur Secunia PSI betrachtet, so bietet das CVE-Verzeichnis, dank CVSS, CWE und CPE, detailliertere Informationen zu einer Sicherheitslücke. Die Nutzung des CVE-Verzeichnisses zur Sicherheitsanalyse von Softwareanwendungen ist zu empfehlen, da im Zeitraum von 2006 bis 2014 pro Jahr durchschnittlich 6.400 Sicherheitslücken veröffentlicht wurden. Es gilt jedoch zur beachten, dass dies nur die veröffentlichten Sicherheitslücken sind. Dies bedeutet, dass, auch wenn für eine Softwareanwendung keine CVEs bekannt sind, man trotzdem davon ausgehen muss, dass die Anwendung nicht 100% sicher ist. Jedoch bietet das CVE-Verzeichnis zurzeit eine der besten Möglichkeiten an, kostenlos auf zuverlässige Daten zu Sicherheitslücken zuzugreifen. Diskussion 65 6 Diskussion 6.1 Verwandte Arbeiten 6.1.1 vFeed vFeed ist ein Framework, welches ein zu CVE, CWE und OVAL kompatibles Konzept zur Namensgebung über ein XML/JSON-Schema bereitstellt. Es bietet den Vorteil, dass zusätzliche strukturierte Third-Party-Referenzen und technische Charakteristiken für CVE-Einträge angegeben werden können. Zum vFeed-Framework gehört die Datenbank vFeed.db (The Correlated Community Vulnerability and Threat Database). Diese SQLite Datenbank ist eine Sammlung von Sicherheitsinformationen die genutzt wird, um Sicherheitslücken von verstreuten Internetquellen in einer Datenbank zu vereinen. (Ouchn 2015) Das vFeed-Framework und die dazugehörige Datenbank wären für die Entwicklung des Tools perfekt geeignet. Es besteht jedoch das Problem, dass die Datenbank nicht nach Belieben aktualisiert werden kann. Somit steht immer eine bestimmte Version der Datenbank zum Download bereit, die in definierten Abständen vom vFeed-Team aktualisiert wird. Für diese Abschlussarbeit ist es jedoch eine wichtige Voraussetzung, dass das lokal gespeicherte CVEVerzeichnis jederzeit aktualisiert werden kann, damit zu einem beliebigen Zeitpunkt immer die neusten CVE-Einträge enthalten sind. 6.1.2 CVE und CVSS Steve Christey, Principal Infosec Engineer der MITRE Corperation, veröffentliche im September 2010 ein Dokument im Namen des Homeland Security Systems Engineering and Development Institute, kurz HS SEDI, welches CVE und CVSS erläutert und den Zusammenhang beider widerspiegelt. Seine Arbeit beschreibt detailliert, warum beide Standards entwickelt wurden, wie sie genutzt und erstellt werden und verdeutlicht anhand von Statistiken den Verbreitungsgrad von CVE.(Christey 2010) Steve Christey konzentriert sich auf die Erläuterung der Standards CVE und CVSS, wohingegen dies nur ein Teil der Grundlage dieser Arbeit darstellt. Dieses Grundwissen wird in dieser Arbeit genutzt, um später eine Software zu implementieren, mit der sich überprüfen lässt, ob das CVE-Verzeichnis für Sicherheitsanalyseanwendungen genutzt werden kann. Diskussion 66 6.1.3 Reviewing the Secunia 2013 Vulnerability Review Brian Martin befasst sich in seinem Blog mit der Beurteilung des Secunia 2013 Vulnerability Reviews, welcher am 26.02.2014 veröffentlicht wurde. Dabei analysiert er zu Beginn die Vorgehensweise von Secunia bei der Erstellung der Statistiken. Er verweist darauf, dass Secunia nicht alle bisher veröffentlichten CVEs in ihrem Datenbestand enthält und kritisiert die eigene Bewertungsmethodik namens Secunia Vulnerability Criticality Classification. Es werden falsche Definitionsaussagen von Secunia, wie beispielsweise Third-Party-Software, kritisch hinterfragt und die mehrfache Zählung von Schwachstellen aufgezeigt. Brian Martin analysiert die Auswahl der Top 50 Produkte und vergleicht beispielhaft an einzelnen Produkten die Anzahl der gefundenen CVEs. (Martin 2014) Brian Martin befasst sich ausschließlich mit der Beurteilung des Secunia 2013 Vulnerability Reviews. In dieser Arbeit wird jedoch nur die Secunia entwickelte Anwendung Secunia PSI als Vergleichsprodukt verwendet. Die in dem Blog angesprochenen Mängel der Statistik spielen für diese Arbeit keine Rolle, da sich diese auf die Mehrfachzählung von Produkten und Schwachstellen in der Statistik beziehen. In dieser Arbeit werden jedoch die Ergebnisse von ganz bestimmten Versionen einer Anwendung, einzeln mit den Ergebnissen des SoftwareVulnerability-Tools verglichen werden. Dadurch können Schwachstellen nicht mehrfach gezählt werden. 6.1.4 Vulnerability management tools for COTS software - A comparison Die Arbeit von Herrn Welberg analysiert Schwachstellen-Management-Tools in zwei Schritten miteinander. Im ersten Schritt werden 30 Anwendungen anhand von Kriterien allgemein miteinander verglichen. Die Kriterien sind beispielsweise in den Anwendungsbereich oder die Untersuchungsart aufgeteilt. Drei der 30 Anwendungen nutzen eine korrelierte Analyse. Diese drei Anwendungen werden im zweiten Schritt detailliert miteinander verglichen. Des Weiteren wird bei diesen drei Anwendungen die Vorgehensweise detailliert erläutert. (Welberg) Während Herr Welberg sich auf den detaillierten Vergleich der Vorgehensweise bei der korrelierten Analyse von drei Schwachstellen-Management-Tools konzentriert, findet in dieser Arbeit nur ein kurzer Auswahlprozess eines Vergleichsproduktes statt. Der Auswahlprozess dient dazu ein passendes Schwachstellen-Management-Tool zu finden, mit der eine Einstufung der Angreifbarkeit von auf einem System installierten Softwareanwendungen durchgeführt werden kann. Die Ergebnisse des Vergleichsproduktes dienen im Vergleich mit den Ergebnissen des Software-Vulnerability-Tools zur Analyse der Quantität und Qualität von CVE-Einträgen. Diskussion 67 6.2 Feedback zu den Standards 6.2.1 Feedback zu CVE Die Anzahl der im Test gefundenen CVEs zum definierten Softwareprofil ist höher als bei dem Vergleichsprodukt Secunia PSI. Die Ergebnisse stellten sich auch häufig als zuverlässiger heraus, da Secunia einige falsch zugeordnete CVEs besitzt. Die hohe Zahl der beispielsweise im Jahr 2014 veröffentlichten CVEs (7928 Einträge) spricht des Weiteren für die gute Quantität von CVE. Es gibt jedoch Probleme mit dem Zusammenspiel von CPE und CVE, die dadurch die gefunden CVEs beeinflussen. Problem inkonsistenter CVEs Als inkonsistente CVEs werden in dieser Arbeit CVEs bezeichnet, denen keine CPEs zugeordnet sind. Betroffen sind (Stand 10.12.2015) 161 CVE-Einträge in der SQLite Datenbank. Das Problem dabei ist, dass ohne die Zuordnung zu einem CPE-Eintrag die Sicherheitslücke oder das Sicherheitsrisiko keinen Mehrwert bietet, da nicht definiert ist, wo beziehungsweise in welchem IT-Produkt, -System oder -Plattform diese auftritt. Auf eine Anfrage bezüglich dieser Problematik an die MITRE Corporation wurde mir mitgeteilt, dass es vorkommen kann, das die von der MITRE Corporation veröffentlichten CVEs noch nicht von dem NIST NVD Team analysiert wurden um die betroffenen CPEs zuzuordnen (siehe Kapitel 9.3). Das NIST NVD Team ist für die Definition und Zuordnung von CPEs verantwortlich. Dadurch kommt das beschriebene Problem häufig in kürzlich veröffentlichten CVEs vor. Abbildung 33, Veranschaulichung des Problems der inkonsistenten CVE-Einträge Die inkonsistenten CVEs werden trotz der beschriebenen Problematik in die Datenbank importiert. Durch die in Kapitel 4.3.4 beschriebene neue Funktionalität des SoftwareVulnerability-Tools können alle inkonsistenten CVE-Einträge angezeigt und im Detail betrachtet werden. Dadurch kann der Nutzer des Tools sich selbst einen Eindruck über die betroffenen Sicherheitslücken und –risiken verschaffen. Zusätzlich bietet das Hinzufügen der inkonsistenten CVEs den Vorteil, dass für den Import kein Sonderfall definiert werden muss, was zu einer simpleren Implementierung und schnelleren Durchführung des Imports führt. Diskussion 68 Problematik fehlender CPE-Zuordnungen bei der Angabe „and previous versions“ Es gibt Sicherheitslücken, die alle bisher veröffentlichten Versionen einer Anwendung, einer Hardware oder eines Betriebssystems betreffen. In solchen Fällen sind in der XML-Datei jedoch nicht alle CPEs der vorherigen Versionen aufgeführt, wodurch diese praktisch nicht von dem CVE-Eintrag betroffen sind. Ein Beispiel hierfür ist die Sicherheitslücke „CVE-20158480“. In der Zusammenfassung des CVE-Eintrags steht der Text „…in Google Chrome before 47.0.2526.73 …“. Auf der NVD-Webseite (NVD NIST 2015) steht bei der Angabe des CPEs in diesem Fall der Zusatz „and previous versions“. Abbildung 34, Ausschnitt der CPEs des Eintrags CVE-2015-8480 von der NVD-Webseite In der von der NVD-Webseite heruntergeladenen Importdatei (NVD NIST) für das SoftwareVulnerability-Tool sind jedoch in der CPE-Definition keine Angaben darüber enthalten, dass auch vorherige Versionen betroffen sind. Abbildung 35, Ausschnitt der CPE-Definition des Eintrags CVE-2015-8480 in der zu importierenden XML-Datei Durch das Fehlen der oben genannten Angaben in der Importdatei ist in dem lokal als Datenbank gespeicherten CVE-Verzeichnis nur die Version 46.0.2490.86 von der Sicherheitslücke betroffen und nicht auch alle davor veröffentlichten. Dadurch entsteht hier ein Informationsverlust. Die Anzahl der betroffenen CVEs kann nicht identifiziert werden, da für eine solche Überprüfung das gesamte CVE-Verzeichnis nach dem Zusatz „and previous versions“ durchsucht werden müsste und dieser nur auf der NVD-Webseite existiert. Anhand der auf der Webseite vorhandenen Suchkriterien ist ebenfalls keine Prüfung der Anzahl der betroffenen CVEs möglich. Diskussion 69 Abbildung 36, Detailansicht der CVE-2015-8480 im Software-Vulnerability-Tool Interessant ist zusätzlich der Fakt, dass auf der NVD-Webseite die CPEs mit dem entsprechenden Zusatz angezeigt werden, es jedoch in der XML-Datei keine Angaben dazu gibt. Auf eine Anfrage zu dieser Problematik an das NVD NIST Team ist im Zeitrahmen dieser Arbeit leider keine Antwort eingegangen (siehe Kapitel 9.3). 6.2.2 Feedback zu CVSS Das Zusammenspiel zwischen CVSS und CVE ist sehr gut. So existiert in 99,92% (Stand 24.11.2015) aller CVEs eine Bewertung durch CVSS. Die restlichen 0,08% der CVEs sind inkonsistent (siehe Kapitel 6.2.1), wodurch diesen auch kein CVSS-Einträge zugeordnet werden. Von den drei verschiedenen Metrikgruppen wird immer nur die Basis-Metrikgruppe (Base-Metric-Group) angegeben. Bei CVSS-Einträgen ist es sehr hilfreich, das neben dem Base-Score, dem Erstellungsdatum und der Herkunft auch die Metrikwerte angegeben sind. Dadurch kann nachvollzogen werden wie sich der Base-Score sich zusammensetzt, beziehungsweise ist besser erkennbar in welche Bewertungskriterien die Sicherheitslücke besonders kritisch abgeschnitten hat. Die Statistik zur Verteilung des CVSS-Base-Scores zeigt, dass der Großteil der CVEs einen Base-Score zwischen 4 und 8 besitzt. 6.2.3 Feedback zu CWE Das CVE-Verzeichnis nutzt CWE, im Gegensatz zu CVSS, nur in Form der Angabe der CWE-ID. Dies ist durchaus verständlich, da CWE sehr viele detaillierte Informationen zu Softwareschwachstellen enthält. Der relativ geringe Anteil (56,57%) der CVEs in denen eine CWE-ID angegeben ist lässt darauf zurückschließen, dass das Zusammenspiel von CVE und CWE noch nicht so gut ist. Durch die Darstellung der verwendeten CWE-IDs in Tabelle 44 ist zu erkennen, dass in 41.239 Fällen nur 29 unterschiedliche IDs verwendet wurden. Dies ist darauf zurückzuführen, dass das CWE-Verzeichnis eine sehr komplexe Struktur besitzt, indem beispielsweise die einzelnen CWE-IDs in einer Baumstruktur miteinander verknüpft sind. Dadurch werden häufig nur die obersten Softwareschwachstellen angegeben und nicht Diskussion 70 explizit nach den genauen Schwachstellen gesucht, da dies einen erheblichen Mehraufwand bedeuten würde. Beispiel: Die Bestimmung das Informationen enthüllt (CWE-200: Information Exposure) werden, ist relativ einfach. Die genauere Bestimmung wodurch diese Informationen enthüllt werden, beispielsweise durch gesendete Daten (CWE-201) oder durch Fehlermeldungen (CWE-209), benötigt jedoch einiges an Zeit in Anspruch. Aus diesem Grund wird häufig die Schwachstelle an der Wurzel in CVEs angegeben. Abbildung 37, Beispiel für die Baumstruktur des CWE-Verzeichnis 6.2.4 Feedback zu CPE Mit 199.138 unterschiedlichen CPEs enthält der Standard mit Abstand die meisten Datensätze aller Standards in der Datenbank. Doch wie die in Kapitel 6.2.1 beschrieben bestehen zwischen dem Zusammenspiel von CVE und CPE noch Probleme. Zusätzlich zu diesen Schwierigkeiten, sind zu CPE weitere Probleme aufgetreten. Problem der Zusammenfassung mehrerer Versionen zu einer CPE Bei der Suche des passenden CPE-Eintrags zum .NET-Framework und dem Internet Explorer sind die im CVE-Verzeichnis hinterlegten CPEs zu ungenau beziehungsweise zu allgemein gehalten. Dadurch besitzen unterschiedliche Versionen der Software die gleiche CPE, was eine genaue Zuordnung von Sicherheitslücken, zu bestimmten Versionen verhindert. Somit werden Sicherheitslücken von unterschiedlichen Versionen in einer CPE zusammengefasst. Beispiel: Eine Softwareanwendung in der Version 1.1.0 besitzt eine Sicherheitslücke, welche mit der Version 1.1.1 geschlossen wird. Da wie beim IE oder .NET-Framework die Version des CPE-Eintrags zu ungenau definiert ist, werden die Sicherheitslücken aller Versionen 1.1.X unter der CPE „cpe:/a:hersteller:anwendung:1.1“ zusammengefasst. Dies hat zur Folge, dass für die Version 1.1.1 auch die Sicherheitslücke angezeigt wird, welche eigentlich durch das Update von 1.1.0 auf 1.1.1 behoben wurde. Diskussion 71 Abbildung 38, Problem der Zusammenfassung von unterschiedlichen Versionen zu einer CPE (Beispiel anhand des .NET-Frameworks) Da alle Sicherheitslücken der .NET-Framework Versionen 4.0.X unter der CPE „cpe:/a:microsoft:.net_framework:4.0“ zusammengefasst werden, können für die installierte Version 4.0.30319.34209 insgesamt 56 Sicherheitslücken, die seit 22.09.2010 veröffentlicht wurden, gefunden werden. Das Problem hierbei ist, dass jede Version bei der die Versionsnummer mit 4.0 beginnt, diese 56 Sicherheitslücken zugeordnet sind. Dadurch ist für das .NET-Framework keine Bewertung einzelner Versionen möglich. Das beschriebene Problem tritt vor allem, aber nicht ausschließlich, bei Microsoft-Produkten auf. Weitere Produktebeispiele von Microsoft die das gleiche Problem haben sind: • Microsoft Windows 7 • Microsoft ASP.NET • Microsoft Office • Microsoft SQL Server Hervorzuheben bleibt jedoch, dass beispielweise bei Microsoft Silverlight das Problem nicht auftritt, da dort die Versionen detailliert in CPEs angegeben sind. Problem des Abdeckungsgrad der CPE-Einträge Beim Import der Daten von der NVD-Webseite wird bei jedem zu importierenden CPEEintrag vom Software-Vulnerability-Tool überprüft, ob die zugeordneten CPEs bereits in der Datenbank vorhanden sind. Falls dies nicht der Fall ist, wird der CPE-Eintrag zur Datenbank hinzugefügt. Dadurch sind nur CPEs in der Datenbank vorhanden, welche auch einem CVEEintrag zugeordnet sind. Dies stellt jedoch ein Problem dar. So kann dadurch bei der Erstellung eines CPE-Profils mit dem Software-Vulnerability-Tool nur IT-Systeme, -Plattformen oder -Produkte hinzugefügt werden, bei denen bereits ein CVE-Eintrag existiert. Aus diesem Grund konnte auch kein CPE-Profil mit allen Softwareanwendungen des Testprofils erstellt werden, da für den Großteil dieser Anwendungen keine passenden CPEs existierten. Auf der NVD-Webseite wird neben dem CVE-Verzeichnis auch ein CPE-Verzeichnis bereitgestellt. Dieses enthält zusätzlich CPEs für IT-Produkte, -Systeme oder Plattformen, für die noch kei- Diskussion 72 ne Sicherheitslücken veröffentlicht sind. Durch die Veränderung der Importfunktion ist es im Software-Vulnerability-Tool möglich, auch dieses Verzeichnis zu importieren. Dadurch existieren auch CPE-Einträge, für die noch keine CVEs veröffentlicht sind. Bei der Überprüfung der für die Testphase definierten IT-Produkte stellte sich jedoch heraus, dass trotz der zusätzlich importierten CPEs nur ein CPE-Eintrag in der Datenbank vorhanden war, welcher die aktuellste Version des entsprechenden IT-Produkts wiederspiegelt. Dies bedeutet, dass das Problem weiterhin besteht. Problem der automatisierten CPE-Generierung Um der beschriebenen Problematik des Abdeckungsgrades der CPE-Einträge entgegen zu wirken, wurde in Erwägung gezogen, automatisiert CPEs, auf Basis der zur Verfügung stehenden Informationen der installierten Software, zu erstellen. Über verschiedene C#Bibliotheken besteht die Möglichkeit, den Hersteller, die Produktbezeichnung und die Version einer installierten Software auszulesen. Mit diesen Informationen könnte versucht werden automatisiert einen CPE-Eintrag zu generieren. Das Problem besteht darin, dass die notwendige Kombination aus • Herstellername (vendor), • Produktbezeichnung (product), • Versionsnummer (version) und • Herstellerspezifischer Name zur Charakterisierung eines Updates (update), eines CPE-Eintrags sich häufig von den ausgelesenen Informationen der C#-Bibliothek oder der Systemsteuerung von Windows 7 unterscheidet. Beispiel 1, iTunes: Bei den Herstellerinformationen von iTunes ist bei den ausgelesenen Informationen der Zusatz für Unternehmensformen Inc. mit angegeben, wohingegen dieser bei jeglichen CPEs, die mit Apple in Verbindung stehen, nicht mit angegeben wird. Des Weiteren wird für iTunes die Versionsangabe in bereits existierenden CPEs nur bis zur maximal dritten Stelle angegeben, jedoch nie bis zur vierten Stelle. Hersteller Produkt Version ausgelesene Informationen Apple Inc. iTunes 12.3.1.23 cpe:/{part} : {vendor} generierte CPE cpe:/a : apple_inc existierende CPE cpe:/a : apple : {product} : itunes : itunes Bsp. für existierende CPE apple itunes 12.3.0 : {version} : 12.3.1.23 : 12.3.0 Tabelle 45, Beispielhafte CPE-Erstellung für iTunes : {update} Diskussion 73 Beispiel 2, OpenOffice: Wie in Beispiel 1 ist hier ein Zusatz im Herstellernamen enthalten, der in existierenden CPEs nicht angegeben wird. In der ausgelesenen Produktbezeichnung ist zusätzlich die Version angegeben, wohingegen die Bezeichnung in der Versionsangabe zu detailliert ist. Hersteller Produkt Version ausgelesene Informationen Apache Software Foundation OpenOffice 4.1.2 4.12.9782 Bsp. für existierende CPE apache openoffice 4.1.1 cpe:/{part} : {vendor} generierte CPE cpe:/a : apache_software_foundation existierende CPE cpe:/a : apache : {product} : openoffice_4.1.2 : openoffice : {version} : {update} : 4.12.9782 : 4.1.1 Tabelle 46, Beispielhafte CPE-Erstellung für OpenOffice Beispiel 3, Silverlight: Während in Beispiel 2 in den Informationen der Produktbezeichnung eine unnötige Beschreibung nach dem Produkt steht (openoffive_4.1.1), so steht sie im Fall von Silverlight davor. Hersteller Produkt Version ausgelesene Informationen Microsoft Corperation Microsoft Silverlight 5.1.40728.0 cpe:/{part} : {vendor} generierte CPE cpe:/a : microsoft_corperation existierende CPE cpe:/a : microsoft Bsp. für existierende CPE microsoft silverlight 5.1.40416.0 : {product} : microsoft_silverlight : silverlight : {version} : {update} : 5.1.40728.0 : 5.1.40416.0 Tabelle 47, Beispielhafte CPE-Erstellung für Silverlight Die automatisch generierten CPEs müssen vom Format der Angaben identisch zu bereits vorhanden CPEs sein. So muss beispielsweise die Bezeichnung des Herstellers Microsoft in CPE-Namen immer „microsoft“ lauten, und nicht „microsoft_corperation“ Ist dies nicht der Fall, so könnte es vorkommen, dass aufgrund der fehlerhaften Erstellung eines CPE-Namens eine bestimmte, bereits veröffentlichte Sicherheitslücke für ein IT-Produkt, nicht gefunden wird. Die Schwierigkeit der automatischen Erstellung liegt darin, dass keine allgemein gültigen Formatierungskriterien für die Generierung definiert werden können, sondern, individuell je nach Produkt, die unterschiedlichen Informationen passend formatiert werden müssen. So können beispielsweise in Beispiel 2 alle Wörter oder Angaben für die Produktbezeichnung die nach dem ersten Wort auftreten entfernt werden, wohingegen in Beispiel 3 alle Angaben die vor dem letzten Wort auftreten entfernt werden müssten. Diskussion 74 6.3 Feedback zu Secunia Secunia PSI funktioniert zuverlässig. Es scannt den Rechner nach installierten Anwendungen und überprüft anschließend die Angreifbarkeit. Die Bedienung ist sehr einfach, jedoch werden in Secunia PSI keine detaillierten Informationen zu den Warnungen angegeben. Bei einem Klick auf die Funktion „More Information“ wird man auf die Secunia Webseite weitergeleitet. Um dort die Angaben zu sehen, muss zunächst ein Account erstellt werden. Nach der Anmeldung werden anschließend die detaillierten Informationen zu den Warnungen angezeigt, in dem unter anderem auch die CVE-IDs angegeben sind. Beim Vergleich der Ergebnisse ist zwischen Secunia PSI und dem Software-VulnerabilityTool ist ein Verhaltensmuster seitens Secunia PSI aufgefallen, welches zu einer Vermutung schließen lässt. Im speziellen Fall des VLC Players in der Version 2.2.1 wurde vom SoftwareVulnerability-Tool die am 25.08.2015 veröffentliche Sicherheitslücke „CVE-2015-5949“ gefunden. Secunia PSI hat jedoch keine Warnungen zum VLC Player ausgegeben. Bei daraufhin angestellten Recherchen wurde festgestellt, dass für den VLC-Player noch keine neuere Version als die aktuell installierte Version 2.2.1 vorhanden ist. Wenn alle Warnungen von Secunia PSI über die Testphase betrachtet werden, kann man feststellen, dass, sobald eine Warnung angezeigt wird, immer die Möglichkeit besteht ein Update zu installieren. In Folge dessen wurde die Vermutung aufgestellt, dass Secunia PSI nur Warnungen oder Einstufungen zur Kritikalität anzeigt, wenn ein für die Behebung der Warnung benötigtes Update, bereits veröffentlicht ist. Dies würde bedeuten, dass im Falle des VLC Players Sicherheitswarnungen bewusst nicht angezeigt werden, da zum Zeitpunkt der Registrierung der Warnung noch keine Möglichkeit zur Behebung existiert. Auf eine Anfrage bezüglich dieser Vermutung wurde von Secunia im Zeitrahmen dieser Arbeit leider keine Antwort mehr erhalten (siehe Kapitel 9.3). Die Vermutung kann jedoch auch nicht bestätigt werden, da dafür mehr Ergebnisse mit einem solchen Fall, in dem • eine Sicherheitslücke mit Hilfe des Software-Vulnerability-Tools entdeckt wurde • Secuni PSI diese Sicherheitslücke nicht entdeckte und • kein Versionsupdate für die betroffene Anwendung möglich ist, aufgetreten sein müssten. Es existieren jedoch noch weitere Secunia PSI-spezifische Problem. Falsche CVE-Angaben Secunia PSI hat in den gefundenen Warnungen insgesamt 29 falsche CVE-Zuordnungen. Diese falschen Zuordnungen treten bei • Apple iTunes (3 CVEs), • Google Chrome (17 CVEs), • Java Runtime Environment (8 CVEs), • PuTTY (1 CVE), auf. Detaillierte Hinweise zu den falschen Zuordnungen können aus dem Kapitel 5.3.1 entnommen werden. Unterschiedliche Bewertung von Warnungen in Secunia PSI und der Secunia Webseite Bei Warnungen bezüglich Windows 7 ist es eine Auffälligkeit in der Bewertung festgestellt worden. Am 12.11.2015 ist beispielsweise die in Abbildung 39 dargestellte Warnung dokumentiert worden. Diskussion 75 Abbildung 39, Ausschnitt aus Secunia PSI zur Bewertung einer Warnung bezüglich Windows7 Wichtig ist hierbei, das Secunia PSI die Warnung mit einer Kritikalität mit vier von möglichen fünf Punkten bewertet. Während der Testphase wurde keine höhere Kritikalität als vier von fünf regisitriert. Die detaillierte Bewertung der Warnung auf der Secunia-Webseite ist in Abbildung 40 zu sehen. Abbildung 40, Ausschnitt der Secunia-Webseite zur Bewertung einer Warnung bezüglich Windows 7 Anhand der beiden Abbildungen ist zu erkennen, dass Secunia entweder auf der Webseite („Not Crititcal“) oder in der Anwendung (vier von fünf möglichen Punkten in der Einstufung der Kritikalität) eine falsche Bewertung darstellt. Hervorzuheben ist, dass dieses Problem nur in den beiden Warnungen zu Windows 7 aufgetreten ist Problematik zur Updatemöglichkeit von TrueCrypt Secunia PSI zeigte zu Beginn der Testphase eine Warnung für TrueCrypt an. In dieser wird angezeigt, dass die installierte Version nicht mehr vom Hersteller unterstützt wird (Kritikalität = „end of life“). Zusätzlich dazu steht in der Angabe der sicheren Version der Text „Product Discontinued“. Beim Updateversuch von TrueCrypt stellte sich heraus, dass die Entwicklung von TrueCrypt eingestellt wurde und es keine neuere Version gibt. Dies führt dazu, dass die Warnung in Secunia PSI nur durch eine Deinstallation von TrueCrypt entfernt werden könnte. Zusätzlich beeinflusst die Warnung auch die von Secunia angegeben Bewertung der Sicherheit des Systems (genannt Secunia System Score). Selbst wenn zu allen anderen Anwendungen keine Sicherheitswarnungen existieren, kann durch den TrueCrypt-Eintrag maximal ein Secunia System Score von 98% auf dem Testsystem erreicht werden. Diskussion 76 6.4 Feedback zur Implementierung des Tools Die Implementierung der jeweiligen Ausbaustufen lief weitestgehend ohne Probleme ab. Es existierte jedoch ein größeres Problem bei der Nutzung von SQLite. Sobald eines der entwickelten Tools auf einem Rechner ausgeführt wurde, auf der die Entwicklungsumgebung Visual Studio nicht installiert war, trat der in Abbildung 41 dargestellte Fehler auf. Abbildung 41, Fehlermeldung bei Ausführung der entwickelten Tools Das Problem lag an der genutzten SQLite-Bibliothek System.Data.SQlite für das .NETFramework. Dieses benötigt weitere Klassenbibliotheken und versucht diese beim Start der Anwendung aus dem Projektpfad zu öffnen oder aus dem Globalen Assembly Cache, kurz GAC, des Rechners zu laden. Da im Normalfall im GAC die gesuchten Klassenbibliotheken nicht installiert sind und diese im Projektpfad der verschiedenen Tools ebenfalls nicht mitgeliefert waren, tritt ein Fehler auf und das selbst entwickelte Tool stürzt ab. Sobald jedoch auf einem Testsystem, auf dem der Fehler reproduziert wurde, zur Problemanalyse mit Debugging Visual Studio installiert wurde, trat der Fehler nicht mehr auf. Wie sich im Nachhinein heraus stellte werden bei der Installation von Visual Studio automatisch die benötigte Klassenbibliotheken ins GAC hinzugefügt. Die Fehlersuche gestaltete sich als relativ schwierig, da die ausgegebene Exception besagt, dass ein ungekannter oder externer Fehler vorliegt. Für die Lösung des Problems wurden die benötigten Klassenbibliotheken identifiziert und in den Projektpfad der jeweiligen Tools hinzugefügt. 6.4.1 Hinweise zur Verarbeitung des CVE-Verzeichnisses Das CVE-Verzeichnis wird als XML-Datei von der NVD-Webseite (NVD NIST) heruntergeladen. Bei der Verarbeitung der Datei gibt es einige Sonderfälle die beachtet werden müssen. Reservierte CVEs überspringen Im CVE-Verzeichnis existieren einige CVE-IDs welche reserviert sind. Dies kann unterschiedlichste Gründe haben. Jedoch sollten diese CVEs nicht importiert werden, da sie keine Sicherheitslücken oder –risiken widerspiegeln. Ein Beispiel eines betroffenen CVE-Eintrags ist in Abbildung 42 zu sehen. Diskussion 77 Abbildung 42, Eine reservierte CVE-ID im CVE-Verzeichnis Die einfachste Möglichkeit reservierte CVEs zu erkennen ist den Beschreibungstext (XMLTag „vuln:summary“) auf ein Vorkommen von „** REJECT **“ zu überprüfen. Hierbei gilt jedoch darauf zu achten, dass keine Überprüfung mit der String-Funktion StartsWith() durchgeführt werden sollte, da es vorkommen kann das vor dem Text „** REJECT **“ noch ein Leerzeichen angegeben ist. „Null“-CPEs beachten In den entwickelten Tools werden beim Importvorgang die CPE-Namen nochmals in Part, Vendor, Product, Version und Update aufgeteilt. Bei wenigen Einzelfällen wurde jedoch ein IndeOutOfRange-Fehler aufgerufen, da ein bestimmter „Null“-CPE (siehe Abbildung 43) der bei der Aufteilung nicht beachtet wurde. Abbildung 43, „Null“-CPE in CVE-2014-4389 im CVE-Verzeichnis Beim Hinzufügen von CPEs sollte dieser spezielle CPE-Name berücksichtigt werden, da dieser, je nach Implementierung, ansonsten Fehler verursacht. Unterschiedliche Möglichkeiten der CPE-Angabe beachten Im CVE-Verzeichnis werden CPEs für einen CVE-Eintrag zwei verschiedenen XML-Tags angegeben. Zum einen ist dies der XML-Tag „vulnerability-configuration“ und zum anderen ist es der XML-Tag „vulnerability-software-list“. Es existieren drei Varianten, welche beachtet werden sollten. 1. Identische CPEs in beiden XML-Tags In diesem Fall ist es gleichgültig, aus welchem XML-Tag die CPEs verwendet werden. Abbildung 44, CPE-Angabe in beiden XML-Tags identisch Diskussion 78 2. Nur CPEs in XML-Tag vulnerability-configuration In diesem Fall müssen die CPEs aus dem XML-Tag „vulnerability-configuration“ entnommen werden, da ansonsten ein inkonsistenter CVE-Eintrag in der Datenbank entstehen würde. Abbildung 45, CPE-Angabe nur in XML-Tag „vulnerability-configuration“ 3. Mehrere XML-Tags vulnerability-configuration angegeben In diesem Fall können CPEs in mehreren XML-Tags der Art „vulnerabilityconfiguration“ angegeben sein. Hierbei ist es wichtig, dass all diese XML-Tags durchlaufen werden. Abbildung 46, CPEs in mehrere XML-Tags „vulnerability-configuration“ verteilt Die CPEs sollten aus den XML-Tags „vulnerability-configuration“ entnommen werden, da sich dies in der Entwicklung des Software-Vulnerability-Tools bewährt hat und es vorkommen kann, dass der XML-Tag „vulnerability-software-list“ nicht angegeben ist. Hierbei ist wichtig, dass wenn der oben beschriebene 3. Fall eintritt, in dem mehrere „vulnerabilityconfiguration“-Tags für einen CVE-Eintrag definiert sind, manche CPEs doppelt vorkommen können. Darauf sollte geachtet und entsprechend reagiert werden. Diskussion 79 6.4.2 Anmerkung zu Erstellung der Datenbankschemas Bei der Erstellung des Datenbankschemas wurde sich für eine strikte Trennung der unterschiedlichen Standards von CVE, CVSS, CWE und CPE entschieden (siehe Kapitel 4.3.1). Dadurch wurden zwar vermeidbare Redundanzen in Kauf genommen, jedoch hat sich dieser Ansatz bewährt, da so eine sehr übersichtliche und logische Datenbankstruktur geschaffen wurde. Ein weiterer Vorteil der klaren Trennung der Standards ist, dass weitere, wie beispielsweise das Common Configuration Enumeration, kurz CCE, ohne großen Aufwand in die Datenbankstruktur integriert werden können. 6.5 Feedback zur Testphase Die Testphase verlief ohne größere Probleme oder Schwierigkeiten ab. Es wurden in den 90 Tagen der Testphase die Ergebnisse von Secunia PSI regelmäßig überprüft und dokumentiert. Die Suche nach passenden CVEs mit Hilfe des Software-Vulnerability-Tools funktionierte weitestgehend gut. Nur die bereits in Kapitel 6.2.4 beschriebenen Probleme des Abdeckungsgrades der CPES und der nicht möglichen automatischen Generierung von CPEs, führte dazu, dass die passenden CPEs manuellen gesucht werden mussten. Des Weiteren konnte die Anwendung AdwCleaner nicht auf dem System installiert werden, da diese nur als ausführbare Datei verfügbar ist. Aus diesem Grund ist das Programm weder in der Systemsteuerung von Windows 7, dem CPE-Einträgen in der Datenbank oder in Secunia PSI aufgelistet. 6.6 Erweiterungsmöglichkeiten 6.6.1 Software zur Einstufung der Angreifbarkeit eines Systems Auf Basis des Software-Vulnerability-Tools kann eine Anwendung entwickelt werden, die das System nach installierten Softwareanwendungen prüft und diese Informationen, beispielsweise in Form einer XML-Datei, in einer Art Softwareprofil speichert. Die Einträge im Softwareprofil dürfen jedoch keine CPEs sein, da ansonsten das in Kapitel 6.2.4 beschriebene Problem des unzureichenden Abdeckungsgrades der CPE-Einträge, in Kombination mit dem Problem der automatisierten Generierung von CPEs auftritt. Anhand des Profils könnte die Anwendung die lokale SQLite-Datenbank, nach zutreffenden Sicherheitsrisiken beziehungsweise –lücken durchsucht werden. Die gefunden Informationen der Standards dienen als Basis zur Bewertung der Angreifbarkeit der einzelnen, auf dem System installierten Anwendungen und des Gesamtsystem. Diskussion 80 Abbildung 47, Mögliche Funktionsweise für eine Software zu Einstufung der Angreifbarkeit eines Systems, auf Basis, der vom CVE-Verzeichnis bereitgestellten Informationen. 6.6.2 Nutzung eines Datenbankservers Ein Schwachpunkt, der in Kapitel 6.6.1 definierten Anwendung, ist die lokal gespeicherte SQLite Datenbank. Diese ist im Software-Vulnerability-Tool bereits 410 Megabyte groß. In einer Unternehmensstruktur wäre dies ein Argument die Anwendung nicht einzusetzen, da jeder Mitarbeiter auf seinem Rechner die identische 410 Megabyte große Datenbank haben würde. Die Anwendung könnte jedoch so erweitert werden, dass anstelle einer lokalen SQLite Datenbank ein MySQL-Datenbankserver auf einem Serversystem genutzt wird. Dies würde den Vorteil bieten, dass Mitarbeiter sich keine Sorgen um die Aktualisierung der Datenbank machen müssten und es keine redundanten Datenbanken in der Unternehmensstruktur geben würde. Abbildung 48, Darstellung der Nutzung eines Datenbankservers anstelle lokaler SQLite-Datenbanken Diskussion 81 6.6.3 Nutzung einer Host-Client Struktur Die in Kapitel 6.6.2 beschriebene Erweiterungsmöglichkeit setzt voraus, dass die Endbenutzer, die von der Anwendung bereitgestellten Informationen über die Angreifbarkeit des Systems entsprechend nutzen, um beispielsweise für betroffene Anwendungen Updates oder Patches zu installieren. Da jedoch die wenigsten Endbenutzer dafür die benötigten Systemberechtigungen besitzen, wäre eine Erweiterungsmöglichkeit im Sinne eines Systemadministrators sinnvoll, mit welcher dieser eine Gesamtübersicht der Angreifbarkeit aller Rechner des Unternehmens erhalten würde. Dafür müsste eine Clientanwendung entwickelt werden, die auf allen Rechnern des Unternehmens installiert wird. Diese Clientanwendung sucht auf Anfrage einer Hostanwendung nach auf dem Rechner installierten Anwendungen und leitet diese Informationen weiter. Die Hostanwendung muss diese Informationen der einzelnen Clients verarbeiten und in der Datenbank abspeichern oder bestehende Informationen aktualisieren. Dadurch besitzt die Hostanwendung Informationen zu den Softwareprofilen aller Rechner und kann so jeden Rechner einzeln anhand der Standards auf die Angreifbarkeit prüfen. Abbildung 49, Funktionsweise einer Anwendung, welche die Angreifbarkeit mehrerer Rechner überprüfen kann Diskussion 82 6.6.4 Definition des Temporal Scores und Environmental Scores Im CVE-Verzeichnis ist nur der CVSS-Base-Score enthalten. Für Benutzer wäre es jedoch sinnvoll den Temporal Score und den Environmental Score angeben zu können. Dadurch könnte der CVSS-Score auf entsprechende Reaktionen wie beispielsweise die Installation eines Patches oder an spezielle, in der IT-Struktur vorhandenen, Gegebenheiten angepasst werden. Um die beiden Metriken angeben zu können, muss eine leichte Veränderung des in Abbildung 14 dargestellten Datenbankschemas durchgeführt werden. Eine mögliche Änderung der Tabellenstruktur ist in Abbildung 50 angegeben. Dort wird CVSS in die verschiedenen Metriken aufgeteilt. Der CVSS-Overall-Score wird in der Tabelle „cvss“ gespeichert. Besonderer Erklärung benötigt die Wertigkeit bei der Verbindung zwischen „cvss“ und „base_metrics“. Dort ist definiert, dass die Basismetriken leer sein dürfen. Eigentlich ist dies verboten, da die Basismetriken immer angegeben sein müssen, jedoch wird, wie beim Vorgehen in Abbildung 3 dargestellt, in solchen Fällen der CVSS-Overall-Score in der Tabelle „cvss“ auf „Not Defined“ gesetzt. Abbildung 50, Mögliche Änderung der Datenbankstruktur zur Speicherung aller CVSS-Metriken 6.6.5 Durchführung einer Testphase auf Basis anderer Testparameter Aufgrund der begrenzten Zeitvorgabe dieser Abschlussarbeit konnte keine längere Testphase durchgeführt werden. Eine Erweiterungsmöglichkeit wäre, dass anstelle von drei Monaten ein Softwareprofil über einen Zeitraum eines halben oder ganzen Jahres geprüft wird. Des Weiteren könnten die Programme des Testprofils geändert und weitere Anwendungen hinzugefügt werden. Anstelle des in dieser Arbeit definierten Vergleichsproduktes Secunia PSI könnte eine oder gar mehrere andere Anwendungen als Vergleich herangezogen werden. Dadurch könnten weit mehr Ergebnisse gesammelt werden und es könnten noch detailliertere Aussagen bezüglich der Quantität und Qualität des CVE-Verzeichnisses getroffen werden. Fazit 83 7 Fazit Die Ergebnisse der Testphase zeigen, dass die von Standards CVE, CVSS, CWE und CPE bereitgestellten Informationen die notwendige Qualität bieten, um als Grundlage für die Entwicklung von Sicherheitsanalyseanwendungen zu dienen. Das durch die NVD bereitgestellte CVE-Verzeichnis beinhaltet alle bereits veröffentlichten CVE-Einträge, was in diesem Test dazu führte, dass mehr Sicherheitslücken als bei dem ausgewählten Vergleichsprodukt Secunia PSI identifiziert wurden. Bei der Entwicklung des Software-Vulnerability-Tools wurden Eigenschaften des CVEVerzeichnisses identifiziert, die bei der Verarbeitung beachtet werden sollten. Darunter fallen die unterschiedlichen Möglichkeiten zur Angabe der CPEs, sowie die Beachtung reservierter CVEs. Im detaillierten Vergleich der Ergebnisse des Software-Vulnerability-Tools und Secunia PSI wurden einige Fehler und Probleme seitens Secunia deutlich. So sind in manchen Ergebnissen falsche CVEs zugeordnet. Des Weiteren ist eine unterschiedliche Bewertung in Secunia PSI und der Secunia Webseite bei Warnungen zu Windows 7 aufgefallen. Die Vermutung, dass Secunia PSI nur dann Warnungen zu Softwareanwendungen anzeigt, wenn zu diesen bereits eine Problemlösung in Form eines Updates existiert, konnte im Rahmen dieser Arbeit nicht eindeutig geklärt werden. Das Zusammenspiel der einzelnen Standards bietet jedoch Raum für Verbesserungen. So ist das Zusammenspiel zwischen CVE und CVSS bereits sehr gut, wohingegen beim Zusammenspiel zwischen CPE und CVE die größte Schwierigkeit besteht. Dies liegt zum größten Teil an Problemen, die den Standard CPE selbst betreffen, jedoch durch Verknüpfung mit CVE eben auch diesen beeinflussen. Ein Beispiel hierfür ist die Zusammenfassung mehrerer Versionen eines IT-Produktes zu einem CPE-Eintrag, wodurch ein CVE-Eintrag nicht mehr klar einer bestimmten Softwareversion zugeordnet werden kann. Ein weiteres Beispiel ist die fehlende Angabe im CVE-Verzeichnis, dass alle Produkte ab einer bestimmten Version von einem CVE-Eintrag betroffen sind. Das Zusammenspiel zwischen CVE und CWE wird durch die Angabe der CWE-ID in einem CVE-Eintrag realisiert. Um jedoch die detaillierten Informationen zu einer Softwareschwachstelle zu erhalten muss das CWE-Verzeichnis zusätzlich importiert werden. Die geringe Anzahl der im CVE-Verzeichnis genutzten, unterschiedlichen CWEs deuten darauf hin, dass nicht für jede Sicherheitslücke die detaillierte CWE-ID angegeben, sondern nur oberflächlich zwischen den Softwareschwachstellen unterschieden wird. Trotz dieser Probleme im Zusammenspiel ist es sinnvoll, das CVE-Verzeichnis als mögliche Informationsgrundlage für Sicherheitsanwendungen in Betracht zu ziehen, da der CVEStandard von vielen Herstellern genutzt wird, um ihre Sicherheitslücken eindeutig zu benennen. Dadurch bietet das von der NVD bereitgestellte CVE-Verzeichnis zurzeit eine der besten Möglichkeiten, kostenlos auf zuverlässige und gut strukturierte Informationen zu Sicherheitslücken zuzugreifen. Literaturverzeichnis 84 8 Literaturverzeichnis AlienVault, Inc (Hg.): Vulnerability-Assessment-Remediation. Online verfügbar unter https://www.alienvault.com/solutions/vulnerability-assessment-remediation, zuletzt geprüft am 12.12.2015. Cheikes, Brant A.; Waltermire, David; Scarfone, Karen (2010): Common Platform Enumeration. Naming Specification. Version 2.3. Hg. v. NIST. Online verfügbar unter http://csrc.nist.gov/publications/nistir/ir7695/NISTIR-7695-CPE-Naming.pdf, zuletzt aktualisiert am 30.08.2011, zuletzt geprüft am 12.12.2015. CHIP (Hg.) (2015): Top 100 -Downloads des Monats. Freeware. Online verfügbar unter http://www.chip.de/Downloads-Download-Charts-Top-100-desMonats_32417777.html?xbl_category=9232&xbl_freeware=1, zuletzt geprüft am 27.08.2015. Christey, Steve (2010): CVE and CVSS. Hg. v. The MITRE Corporation. Online verfügbar unter http://scap.nist.gov/events/2010/itsac/presentations/day1/SCAP_101CVE_and_CVSS.pdf, zuletzt aktualisiert am 27.09.2015, zuletzt geprüft am 11.12.2015. Cichonski, Paul; Waltermire, David; Scarefone, Karen (2010): Common Platform Enumeration. Dictionary Specification. Version 2.3. Hg. v. NIST. Online verfügbar unter http://csrc.nist.gov/publications/nistir/ir7697/NISTIR-7697-CPE-Dictionary.pdf, zuletzt aktualisiert am 30.08.2011, zuletzt geprüft am 12.12.2015. Cisco Systems, Inc. (Hg.) (2009): Cisco Security IntelliShield Alert Manager Service. Online verfügbar unter http://www.cisco.com/en/US/services/ps2827/ps6834/services_overview0900aecd803e85ee.p df, zuletzt geprüft am 12.12.2015. FILEHIPPO (Hg.): FileHippo App Manager. Online verfügbar unter http://www.filehippo.com/de/download_app_manager/, zuletzt geprüft am 12.12.2015. FILEHIPPO (Hg.) (2015): Beliebte Software. Online verfügbar unter http://filehippo.com/de/popular/, zuletzt geprüft am 27.08.2015. FIRST (Hg.): Common Vulnerability Scoring System v3.0. Specification Document. Online verfügbar unter http://www.first.org/cvss/specification-document, zuletzt geprüft am 12.12.2015. FIRST (Hg.): CVSS Frequently Asked Questions. Online verfügbar unter http://www.first.org/cvss/v2/faq, zuletzt geprüft am 12.12.2015. Focus (Hg.) (2015): Sicherheitslücke entdeckt. Experten warnen: Adobe Flash Player sofort abschalten! Online verfügbar unter http://www.focus.de/digital/computer/sicherheitslueckenentdeckt-experten-warnen-adobe-flash-player-sofort-deinstallieren_id_4427539.html, zuletzt aktualisiert am 24.01.2015, zuletzt geprüft am 11.12.2015. Literaturverzeichnis 85 heise online (Hg.) (2015): Top-Downloads des Monats. Online verfügbar unter http://www.heise.de/download/top-downloads50000505000/?prgll=30&lf=1&lf=3&lf=2&lf=5&styp=w&styp=s&liste=dwl&srt=dwl, zuletzt geprüft am 27.08.2015. Hwaci (Hg.) (2015): About System.Data.SQLite. Online verfügbar unter http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki, zuletzt aktualisiert am 13.12.2015, zuletzt geprüft am 15.12.2015. IBM (Hg.): Internet scanner. Internet scanner vulnerability assessment application helps provide the foundation for effective network security for your business. Online verfügbar unter http://www-935.ibm.com/services/id/en/it-services/internet-scanner.html, zuletzt geprüft am 12.12.2015. KC Softwares (Hg.): SUMo Software Update Monitor. Online verfügbar unter http://www.kcsoftwares.com/?sumo, zuletzt geprüft am 12.12.2015. Kuri, Jürgen (2015): Sicherheitslücke in Millionen Android-Geräten. Hg. v. heise online. Online verfügbar unter http://www.heise.de/security/meldung/Sicherheitsluecke-in-MillionenAndroid-Geraeten-Google-empfiehlt-Chrome-oder-Firefox-als-Abhilfe-2528130.html, zuletzt aktualisiert am 26.01.2015, zuletzt geprüft am 11.12.2015. Martin, Brian (2014): Reviewing the Secunia 2013 Vulnerability Review. Online verfügbar unter http://blog.osvdb.org/2014/03/18/reviewing-the-secunia-2013-vulnerability-review/, zuletzt aktualisiert am 18.03.2014, zuletzt geprüft am 11.12.2015. Mell, Peter; Scarfone, Karen; Romanosky, Sasha: A Complete Guide to theCommon Vulnerability Scoring System Version 2.0. Hg. v. FIRST. Online verfügbar unter http://www.first.org/cvss/v2/guide, zuletzt geprüft am 12.12.2015. Microsoft (Hg.): Microsoft Baseline Security Analyzer. Online verfügbar unter https://technet.microsoft.com/de-de/security/cc184924.aspx, zuletzt geprüft am 12.12.2015. NVD NIST (Hg.): Common Vulnerability Scoring System Version 2 Calculator. Online verfügbar unter https://nvd.nist.gov/cvss.cfm?calculator&adv&version=2, zuletzt geprüft am 12.12.2015. NVD NIST (Hg.): CVE dictionary 2015. Online verfügbar unter http://static.nvd.nist.gov/feeds/xml/cve/nvdcve-2.0-2015.xml.zip. NVD NIST (Hg.): NVD Data Feeds. Online verfügbar unter https://nvd.nist.gov/download.cfm#CVE_FEED, zuletzt geprüft am 12.12.2015. NVD NIST (Hg.) (2015): Vulnerability Summary for CVE-2015-8480. Online verfügbar unter https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8480, zuletzt aktualisiert am 07.12.2015, zuletzt geprüft am 08.12.2015. Ouchn, Nj (2015): vFeed Framework (API & Correlated Vulnerability Database). Online verfügbar unter https://github.com/toolswatch/vFeed/wiki/%5B1%5D-vFeed-Framework%28API-&-Correlated-Vulnerability-Database%29, zuletzt aktualisiert am 30.10.2015, zuletzt geprüft am 11.12.2015. Paar, C.; Schimmler, M. (2008): COPACOBANA. A Codebreaker for DES and other Ciphers. Online verfügbar unter http://www.copacobana.org/index.html, zuletzt aktualisiert am 01.05.2008, zuletzt geprüft am 12.12.2015. Parmelee, Mary C.; Booth, Harold; Waltermire, David; Scarfone, Karen (2010): Common Platform Enumeration. Name Matching Specification. Version 2.3. Hg. v. NIST. Online ver- Literaturverzeichnis 86 fügbar unter http://csrc.nist.gov/publications/nistir/ir7696/NISTIR-7696-CPE-Matching.pdf, zuletzt aktualisiert am 30.08.2011, zuletzt geprüft am 12.12.2015. PC Pitstop (Hg.) (2013): The 100 Most Popular Freeware Downloads. Online verfügbar unter http://techtalk.pcpitstop.com/2013/06/12/the-100-most-popular-freeware-downloads/, zuletzt aktualisiert am 12.06.2013, zuletzt geprüft am 12.12.2015. Secunia (Hg.): Adobe Reader / Acrobat Multiple Vulnerabilities. Online verfügbar unter https://secunia.com/advisories/66814. Secunia (Hg.): Secunia PSI. Online verfügbar unter http://secunia.com/vulnerability_scanning/personal/, zuletzt geprüft am 12.12.2015. statista (Hg.) (2015): Marktanteile der führenden Betriebssystemversionen in Deutschland von Januar 2009 bis September 2015. Online verfügbar unter http://de.statista.com/statistik/daten/studie/158102/umfrage/marktanteile-vonbetriebssystemen-in-deutschland-seit-2009/, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.): The CERT C Secure Coding Standard view. Online verfügbar unter https://cwe.mitre.org/data/pdf/734.pdf, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2013a): Terminology. Online verfügbar unter https://cve.mitre.org/about/terminology.html, zuletzt aktualisiert am 27.02.2013, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2013b): CPE Specifications — Archive. Online verfügbar unter http://cpe.mitre.org/specification/, zuletzt aktualisiert am 22.03.2013, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2014a): Frequently Asked Questions (FAQ). What information is included in a CWE weakness entry? Online verfügbar unter https://cwe.mitre.org/about/faq.html#B.3, zuletzt aktualisiert am 25.06.2014, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2014b): About CWE. Online verfügbar unter https://cwe.mitre.org/about/index.html, zuletzt aktualisiert am 11.07.2014, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2014c): Frequently Asked Questions (FAQ). What is the difference between a software vulnerability and software weakness? Online verfügbar unter https://cwe.mitre.org/about/faq.html#A.2, zuletzt aktualisiert am 25.07.2014, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2015a): About CVE. Online verfügbar unter https://cve.mitre.org/about/index.html, zuletzt aktualisiert am 21.01.2015, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2015b): CVE Numbering Authorities. Online verfügbar unter https://cve.mitre.org/cve/cna.html, zuletzt aktualisiert am 12.02.2015, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2015c): About CVE Identifiers. Online verfügbar unter https://cve.mitre.org/cve/identifiers/index.html, zuletzt aktualisiert am 10.03.2015, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2015d): CVE-ID Syntax Change. Online verfügbar unter https://cve.mitre.org/cve/identifiers/syntaxchange.html#new, zuletzt aktualisiert am 01.07.2015, zuletzt geprüft am 12.12.2015. Literaturverzeichnis 87 The MITRE Corporation (Hg.) (2015e): CVE Editorial Board. Online verfügbar unter https://cve.mitre.org/community/board/index.html, zuletzt aktualisiert am 03.11.2015, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2015f): CWE List Version 2.9. Online verfügbar unter https://cwe.mitre.org/data/index.html#documentation, zuletzt aktualisiert am 07.12.2015, zuletzt geprüft am 12.12.2015. The MITRE Corporation (Hg.) (2015g): CWE-369: Divide By Zero. Online verfügbar unter https://cwe.mitre.org/data/definitions/369.html, zuletzt aktualisiert am 08.12.2015, zuletzt geprüft am 12.12.2015. Tucows (Hg.) (2015): Top 100 Free Windows Downloads. Online verfügbar unter http://www.tucows.com/list_detail.html?id=9, zuletzt geprüft am 27.08.2015. Waltermine, David; Cichonski, Paul; Scarfone, Karen (2011): Common Platform Enumeration. Applicability Language Specification. Versio 2.3. Hg. v. NIST. Online verfügbar unter http://csrc.nist.gov/publications/nistir/ir7698/NISTIR-7698-CPE-Language.pdf, zuletzt aktualisiert am 30.08.2011, zuletzt geprüft am 12.12.2015. Welberg, S. M.: Vulnerability management tools for COTS software - A comparison. Hg. v. University of Twente. Online verfügbar unter http://doc.utwente.nl/64654/1/Vulnerability_management_tools_for_COTS_software__a_comparison_v2.1.pdf, zuletzt geprüft am 11.12.2015. Wikipedia (Hg.): Chip Online. Online verfügbar unter https://de.wikipedia.org/wiki/Chip_Online, zuletzt geprüft am 12.12.2015. Wikipedia (Hg.): Heise online. Online verfügbar unter https://de.wikipedia.org/wiki/Heise_online, zuletzt geprüft am 12.12.2015. Wikipedia (Hg.) (2015a): Smurf-Angriff. Online verfügbar unter https://de.wikipedia.org/wiki/Smurf-Angriff, zuletzt aktualisiert am 20.08.2015, zuletzt geprüft am 15.15.2015. Wikipedia (2015b): Mitre Corporation. Online verfügbar unter https://en.wikipedia.org/wiki/Mitre_Corporation, zuletzt aktualisiert am 07.10.2015, zuletzt geprüft am 12.12.2015. Erklärung des Kandidaten 88 Erklärung des Kandidaten Die Arbeit habe ich selbstständig verfasst und keine anderen als die angegebenen Quellen- und Hilfsmittel verwendet. Name des Verfasser: Matthias Scherf 15.12.2015 Datum Unterschrift des Kandidaten Anhang 89 9 Anhang 9.1 Detaillierte Informationen zu Ergebnissen von Secunia PSI Zu manchen Sicherheitswarnungen von Secunia PSI existieren zusätzliche Informationen auf der Secunia Webseite. Die Sicherheitswarnungen, bei denen dies zutrifft werden im Folgenden aufgeführt: 30.08.2015, Mozilla Firefox Abbildung 51, detaillierte Informationen zur Warnung bezüglich des Mozilla Firefox am 30.08.2015 12 09.09.2015, .NET-Framework Abbildung 52, detaillierte Informationen zur Warnung bezüglich des –NET-Frameworks am 09.09.2015 13 12 13 https://secunia.com/advisories/66121 https://secunia.com/advisories/66386 Anhang 90 09.09.2015, Microsoft Internet Explorer Abbildung 53, detaillierte Informationen zur Warnung bezüglich des Microsoft Internet Explorer am 09.09.2015 14 09.09.2015, Windows 7 Abbildung 54, detaillierte Informationen zur Warnung bezüglich Windows 7 am 09.09.2015 15 14 15 https://secunia.com/advisories/65987 https://secunia.com/advisories/66387 Anhang 18.09.2015, Apple iTunes Abbildung 55, detaillierte Informationen zur Warnung bezüglich Apple iTunes am 18.09.2015 16 16 https:/secunia.com/advisories/66341 91 Anhang 15.10.2015, Acrobat Reader Abbildung 56, detaillierte Informationen zur Warnung bezüglich Acrobat Reader am 15.10.2015 17 19.10.2015, Mozilla Firefox Abbildung 57, detaillierte Informationen zur Warnung bezüglich Mozilla Firefox am 19.10.2015 18 17 18 https://secunia.com/advisories/66814 https://secunia.com/advisories/66902 92 Anhang 93 23.10.2015, Java Runtime Environment Abbildung 58, detaillierte Informationen zur Warnung bezüglich der Java Runtime Environment am 23.10.2015 19 23.10.2015, Apple iTunes Abbildung 59, detaillierte Informationen zur Warnung bezüglich Apple iTunes am 23.10.2015 20 19 20 https://secunia.com/advisories/67038 https://secunia.com/advisories/66960 Anhang 94 02.11.2015, Apache OpenOffice Abbildung 60, detaillierte Informationen zur Warnung bezüglich Apache OpenOffice am 02.11.2015 21 10.11.2015, PuTTY Abbildung 61, detaillierte Informationen zur Warnung bezüglich PuTTY am 10.11.2015 22 21 22 https://secunia.com/advisories/64302 https://secunia.com/advisories/67306 Anhang 11.11.2015, Google Chrome Abbildung 62, detaillierte Informationen zur Warnung bezüglich Google Chrome am 11.11.2015 23 11.11.2015, Adobe Flash Player Abbildung 63, detaillierte Informationen zur Warnung bezüglich des Adobe Flash Players am 11.11.2015 24 23 24 https://secunia.com/advisories/67276 https://secunia.com/advisories/67114 95 Anhang 12.11.2015, Windows 7 Abbildung 64, detaillierte Informationen zur Warnung bezüglich Windows 7 am 12.11.2015 25 25 https://secunia.com/advisories/67337 96 Anhang 97 9.2 Lastenheft für das Software-Vulnerability-Tool 9.2.1 Einleitung Dieses Dokument dient dem Zweck die Eigenschaften und Funktionen der zu entwickelnden Software „Software-Vulnerability-Tool“ festzulegen. Dazu ist eine Sammlung von Pflichtanforderungen und optionalen Anforderungen erstellt worden, die als Grundlage zur Softwareentwicklung und Evaluation der Software dienen. Jede Anforderung muss des Weiteren dabei helfen ein definiertes Ziel zu erreichen. Die zu entwickelnde Software „Software-Vulnerability-Tool“ basiert auf den Anwendungen „CVE-Import-Tool“ und „CVE-Research-Tool“. Aus diesem Grund sind • • die Ziele (Z1) bis (Z7), sowie die Anforderungen (A1) bis (A62) für das „CVEResearch-Tool“, die Ziele (Z1) bis (Z4), sowie die Anforderungen (A1) bis (A33) für das „CVEImport-Tool“ identisch. 9.2.2 Ziele Die zu entwickelnde Software muss folgende Ziele erfüllen: (Z1) Speicherung aller Informationen von CVEs CVEs und alle mit einem CVE-Eintrag verknüpften Elemente müssen in einer geeigneten Art als Verzeichnis lokal auf dem ausführenden System gespeichert werden können. (Z2) Aktualität der Informationen Das CVE-Verzeichnis, welches lokal auf dem ausführenden System gespeichert wird, muss auf dem aktuellsten Stand gehalten werden können. (Z3) Unabhängigkeit von Quellen Das zu entwickelnde Programm muss unabhängig von einer bestimmten Quelle zur Informationsbeschaffung sein. Erläuterung: Es sollen somit beispielsweise unterschiedliche Quellen gleichzeitig oder einzelne Quellen verändert oder ausgetauscht werden können. Dies ist unter anderem durch die Definition eines XML-Schemas für CVEs möglich (Z4) Benutzerfreundlichkeit Das zu entwickelnde Programm muss benutzerfreundlich, intuitiv zu bedienen sein und für den Benutzer angemessene Reaktionszeiten besitzen. (Z5) Durchsuchen des lokalen CVE-Verzeichnisses Das lokal gespeicherte CVE-Verzeichnis muss durchsucht werden können und die Ergebnisse in einer geeigneten Form dargestellt werden. Anhang 98 (Z6) Anzeige detaillierter Informationen Die mit einem CVE-Eintrag verknüpften Informationen müssen alle in einer für den Nutzer einfachen und übersichtlichen Art und Weise angezeigt werden. (Z7) CVE-Verzeichnisses nach CPE-Profil durchsuchen Das CVE-Verzeichnis muss anhand einer Liste von CPEs (genannt CPE-Profil), welche in geeigneter Form lokal abgespeichert werden kann, durchsucht werden können. (Z8) Inkonsistenzen im CVE-Verzeichnis Der Nutzer muss Informationen zu Inkonsistenzen im CVE-Verzeichnis angezeigt bekommen. Hinweis: Mit Inkonsistenzen sind CVE-Einträge gemeint, denen kein CPE-Eintrag zugeordnet ist. (Z9) Statistiken Das zu entwickelnde Programm muss es dem Benutzer erlauben Statistiken zu erzeugen. 9.2.3 Anforderungen In diesem Kapitel werden die Anforderungen an die Anwendung definiert, welche diese erfüllen muss. • • • Pflichtanforderungen sind durch die Schlüsselwörter „muss“ und „darf nicht“ erkennbar Optionale Anforderungen sind durch das Schlüsselwort „soll“ erkennbar Jede Anforderung wird mit einem Ziel referenziert, welche die jeweilige Anforderung hilft zu erreichen Anforderungen werden in funktionale Anforderungen und nicht-funktionale Anforderungen getrennt. Funktionale Anforderungen Datenbank (A1) Datenbank Das CVE-Verzeichnis muss in einer lokalen Datenbank gespeichert werden. siehe Ziel (Z1) (A2) Datenbankserver Die Datenbank muss ohne Datenbankserver genutzt werden können. siehe Ziel (Z1) (A3) Verteilung Die Datenbank muss leicht verteilt werden können siehe Ziel (Z1) Datenbankschema (A4) Standardorientierte Tabellenstrukturierung Das Datenbankschema muss eine Strukturierung der Tabellen besitzen, welche die Standards CVE, CPE, CVSS und CWE klar voneinander trennt. siehe Ziel (Z1) Anhang 99 (A5) Vermeidbare Redundanzen I Das Datenbankschema muss vermeidbare Redundanzen erlauben, sofern diese Redundanzen nötig sind, um der Anforderung (A5) Standardorientierte Tabellenstruktur gerecht werden zu können. Erläuterung: Sofern eine Tabelle Inhalt enthält der standardspezifisch ist (also Informationen zu CVE, CPE, CVSS oder CWE besitzt), müssen vermeidbare Redundanzen erlaubt sein, um so die verschiedenen Standards tabellarisch klar trennen zu können. siehe Ziel (Z1) (A6) Vermeidbare Redundanzen II Das Datenbankschema darf nicht vermeidbare Redundanzen ermöglichen, wenn die Redundanzen nicht nötig sind, um der Anforderung (A5) Standardorientierte Tabellenstruktur gerecht zu werden. Erläuterung: Sofern eine Tabelle keinen Inhalt enthält der standardspezifisch ist (also keine Informationen zu CVE, CPE, CVSS oder CWE besitzt), müssen vermeidbare Redundanzen vermieden werden. siehe Ziel (Z1) (A7) Eindeutige Primärschlüssel Das Datenbankschema muss eindeutige Primärschlüssel für alle Tabellen definieren. siehe Ziel (Z1) (A8) Passende Datentypen Das Datenbankschema muss zu den zu speichernden Informationen passende Datentypen für die Tabellenspalten definieren. Erläuterung: Passend bedeutet in diesem Fall, dass beispielsweise für den Wert 1443052 kein TEXT-Datentyp, sondern ein INTEGER-Datentyp definiert wird. siehe Ziel (Z1) CVE- und CPE-Informationsbeschaffung (A9) Quelle der Importdatei für CVEs I Die CVE-Einträge sollen aus der National Vulnerability Database entnommen werden. siehe Ziele (Z2), (Z3) (A10) Quelle der Importdatei für CVEs II Ein URL-Pfad zu einer Informationsquelle für CVE-Einträge muss zu der Liste der CVEQuellen hinzugefügt werden können. siehe Ziele (Z2), (Z3) (A30) Quelle der Importdatei für CVEs III Ein URL-Pfad zu einer Informationsquelle für CVE-Einträge muss aus der Liste der CVEQuellen entfernt werden können. siehe Ziele (Z2), (Z3) (A31) CVE-Quellen speichern Die vom Benutzer eingegebenen Quellen für CVE-Einträge, müssen auch nach Beenden und erneutem Starten der zu entwickelnden Software weiterhin bestehen. siehe Ziel (Z4) Anhang 100 (A77) Quelle der Importdatei für CPEs I Zusätzliche CPE-Einträge sollen aus der National Vulnerability Database entnommen werden. siehe Ziele (Z2), (Z3) (A78) Quelle der Importdatei für CPEs II Ein URL-Pfad zu einer Informationsquelle für CPE-Einträge muss zu der Liste der CPEQuellen hinzugefügt werden können. siehe Ziele (Z2), (Z3) (A79) Quelle der Importdatei für CPEs III Ein URL-Pfad zu einer Informationsquelle für CPE-Einträge muss aus der Liste der CPEQuellen entfernt werden können. siehe Ziele (Z2), (Z3) (A80) CPE-Quellen speichern Die vom Benutzer eingegebenen Quellen für CPE-Einträge, müssen auch nach Beenden und erneutem Starten der zu entwickelnden Software weiterhin bestehen. siehe Ziel (Z4) (A13) Automatischer Download der CVE-Importdatei Die zu entwickelnde Software muss automatisch die benötigten Importdateien für CVEs herunterladen. siehe Ziel (Z2) (A81) Automatischer Download der CPE-Importdatei Die zu entwickelnde Software muss automatisch die benötigten Importdateien für CPEs herunterladen. siehe Ziel (Z2) (A14) Automatische Löschung Die zu entwickelnde Software muss nach dem erfolgreichen oder nicht erfolgreichen Import, automatisch die benötigten Importdateien für CVEs löschen. siehe Ziel (Z2) (A82) Automatische Löschung Die zu entwickelnde Software muss nach dem erfolgreichen oder nicht erfolgreichen Import, automatisch die benötigten Importdateien für CPEs löschen. siehe Ziel (Z2) (A15) Format der Importdatei für CVEs Die Datei in der die CVE-Einträge enthalten sind muss im XML-Format vorliegen. siehe Ziel (Z2) (A83) Format der Importdatei für CPEs Die Datei in der die CPE-Einträge enthalten sind muss im XML-Format vorliegen. siehe Ziel (Z2) (A17) Verarbeitung der Importdatei für CVEs Die Importdatei für CVEs muss von der zu entwickelnden Software ohne Informationsverlust ausgelesen werden. Erläuterung: Informationsverlust bedeutet, dass keine der in der Importdatei vorhandenen Informationen bzw. XML-Elemente übersprungen werden darf siehe Ziel (Z2) Anhang 101 (A84) Verarbeitung der Importdatei für CPEs Die Importdatei für CPEs muss von der zu entwickelnden Software ohne Informationsverlust ausgelesen werden. siehe Ziel (Z2) Datenbankfunktionalitäten (A19) CVE-Einträge zur Datenbank hinzufügen Noch nicht der Datenbank vorhandene CVE-Einträge müssen in diese hinzugefügt werden können. siehe Ziel (Z2) (A85) CPE-Einträge zur Datenbank hinzufügen Noch nicht der Datenbank vorhandene CPE-Einträge müssen in diese hinzugefügt werden können. siehe Ziel (Z2) (A21) CVE-Einträge in der Datenbank aktualisieren Bereits in der Datenbank vorhandene CVE-Einträge müssen in dieser aktualisiert werden können. siehe Ziel (Z2) (A86) CPE-Einträge in der Datenbank aktualisieren Bereits in der Datenbank vorhandene CVE-Einträge müssen in dieser aktualisiert werden können. siehe Ziel (Z2) (A23) Unterscheidung zwischen hinzufügen und aktualisieren von CVE-Einträgen Die zu entwickelnde Software muss automatisch erkennen, ob ein CVE-Eintrag hinzugefügt oder aktualisiert werden muss siehe Ziel (Z2) (A87) Unterscheidung zwischen hinzufügen und aktualisieren von CPE-Einträgen Die zu entwickelnde Software muss automatisch erkennen, ob ein CPE-Eintrag hinzugefügt oder aktualisiert werden muss siehe Ziel (Z2) Datenbank updaten (A25) Datenbank aktualisieren Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, die Datenbank mit wenig Benutzeraufwand aktualisieren zu können. siehe Ziele (Z2), (Z4) (A26) Letzte Datenbankaktualisierung Die zu entwickelnde Software muss das Datum und die Uhrzeit der letzten Datenbankaktualisierung speichern. siehe Ziel (Z2) (A27) Datenbankaktualisierung abbrechen Die zu entwickelnde Software muss die Möglichkeit bieten, den Aktualisierungsvorgang der Datenbank abbrechen zu können. siehe Ziel (Z2) Anhang 102 (A73) Anzeige der Anzahl der gespeicherten Datensätze der jeweiligen Standards Die zu entwickelnde Software muss die Anzahl der Datensätze, die für die jeweiligen Standards CVE, CVSS, CWE und CPE in der Datenbank gespeichert sind, anzeigen. siehe Ziele (Z4), (Z6) Datenbank updaten (A34) CVE-Verzeichnis nach CVE-ID durchsuchen Die zu entwickelnde Software muss die Möglichkeit bieten, das lokale CVE-Verzeichnis unter Angabe einer CVE-ID als Suchkriterium zu durchsuchen. siehe Ziel (Z5) (A35) CVE-Verzeichnis nach bestimmten Softwareprodukt durchsuchen Die zu entwickelnde Software muss die Möglichkeit bieten, das lokale CVE-Verzeichnis unter Angabe eines Softwareprodukts als Suchkriterium zu durchsuchen. siehe Ziel (Z5) (A36) CVE-Verzeichnis ab einem bestimmten Datum durchsuchen Die zu entwickelnde Software muss die Möglichkeit bieten, das lokale CVE-Verzeichnis unter Angabe eines bestimmten Datums als Suchkriterium zu durchsuchen und alle Einträge anzuzeigen, die ab dem eingegebenen Datum veröffentlicht wurden. siehe Ziel (Z5) (A37) CVE-Verzeichnis bis zu einem bestimmten Datum durchsuchen Die zu entwickelnde Software muss die Möglichkeit bieten, das lokale CVE-Verzeichnis unter Angabe eines bestimmten Datums als Suchkriterium zu durchsuchen und alle Einträge anzuzeigen, die bis zu dem eingegebenen Datum veröffentlicht wurden. siehe Ziel (Z5) (A38) Kombination der Suchkriterien Die zu entwickelnde Software muss die Möglichkeit bieten, die in den Anforderung (A34), (A35), (A36) und (A37) definierten Suchkriterien miteinander zu kombinieren, um so eine detailliertere Suche zu ermöglichen. siehe Ziel (Z5) (A39) Groß- und Kleinschreibung der Suchkriterien Die in den Anforderungen (A34) und (A35) definierten Suchkriterien müssen unabhängig ob groß oder klein geschrieben die gewünschte Suche des Nutzers ermöglichen. siehe Ziel (Z5) (A40) Anzeige der Suchergebnisse Die in den Anforderungen (A34) bis (A38) gefunden Suchergebnisse müssen in einer Liste angezeigt werden, welche mindestens • die CVE-ID • das Datum der Veröffentlichung • das Datum der letzten Bearbeitung des CVE-Eintrags darstellt siehe Ziel (Z5) (A41) Detaillierte Anzeige von Suchergebnissen Die zu entwickelnde Software muss die Möglichkeit besitzen eine detaillierte Ansicht eines einzelnen Suchergebnisses der Suchergebnisliste anzuzeigen. siehe Ziel (Z5) Anhang 103 Detaillierte Anzeige eines CVE-Updates (A42) Anzeige von verknüpften CPE-Einträgen Die zu entwickelnde Software muss in der detaillierten Ansicht eines CVE-Eintrags alle mit dem CVE-Eintrag verknüpften CPE-Einträge, falls vorhanden, auflisten. siehe Ziel (Z6) (A43) Anzeige des verknüpften CVSS-Eintrags Die zu entwickelnde Software muss in der detaillierten Ansicht eines CVE-Eintrags alle Informationen des mit dem CVE-Eintrag verknüpften CVSS-Eintrags, falls vorhanden, darstellen. siehe Ziel (Z6) (A44) Anzeige der Beschreibung Die zu entwickelnde Software muss in der detaillierten Ansicht eines CVE-Eintrags die Beschreibung des CVE-Eintrags, falls vorhanden, darstellen. siehe Ziel (Z6) (A45) Anzeige der verknüpften CWE-ID Die zu entwickelnde Software muss in der detaillierten Ansicht eines CVE-Eintrags die mit dem CVE-Eintrag verknüpften CWE-ID, falls vorhanden, darstellen. siehe Ziel (Z6) (A72) Link für weitere Informationen zur CWE-ID Die zu entwickelnde Software muss in der detaillierten Ansicht eines CVE-Eintrags die in (A45) beschriebene CWE-ID als Link darstellen, der falls angeklickt, den Nutzer zu einer Webseite mit detaillierten Informationen zur CWE-ID leitet. siehe Ziele (Z4), (Z6) (A46) Anzeige von verknüpften Referenzen Die zu entwickelnde Software muss in der detaillierten Ansicht eines CVE-Eintrags alle mit dem CVE-Eintrag verknüpften Referenzen, falls vorhanden, auflisten. siehe Ziel (Z6) CPE-Profil (A46) CPE-Profil erstellen Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, ein CPE-Profil zu erstellen. siehe Ziele (Z5), (Z7) (A47) CPE-Profil speichern Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, ein erstelltes CPEProfil in geeigneter Form, auf dem ausführenden System zu speichern. siehe Ziele (Z5), (Z7) (A48) CPE-Profil bearbeiten Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, ein gespeichertes CPE-Profil laden und anschließend bearbeiten zu können. siehe Ziele (Z5), (Z7) (A49) Anzeige aller vorhandenen CPE-Einträge des CVE-Verzeichnisses Bei der Erstellung und Bearbeitung eines CPE-Profils müssen alle im CVE-Verzeichnis gespeicherten CPE-Einträge in einer Liste dargestellt werden. siehe Ziele (Z5), (Z7) Anhang 104 (A50) Anzeige der CPE-Einträge des CPE-Profils Bei der Erstellung oder Bearbeitung eines CPE-Profils müssen die CPE-Einträge, welche zu dem CPE-Profil gehören, in einer Liste dargestellt werden. siehe Ziele (Z5), (Z7) (A51) Filterung der Liste der CPE-Einträge Die in der Anforderung (A49) definierte Liste von CPE-Einträgen muss nach dem CPENamen gefiltert werden können. siehe Ziele (Z4), (Z7) (A52) Inhalt der CPE-Listen Die in den Anforderungen (A47) und (A48) definierten Listen müssen folgende Informationen darstellen: • Part (Art des Produkts: Hardware {h}, Betriebssystem {o} oder Anwendung {a}) • Vendor (Name des Herstellers) • Product (Name des Produkts) • Version (Versionsnummer) • Update (Herstellerspezifischer Name {Alpha, Beta u.ä.}) siehe Ziele (Z5), (Z7) (A53) CPE-Eintrag zum CPE-Profil hinzufügen Bei der Erstellung und Bearbeitung eines CPE-Profils muss für den Nutzer die Möglichkeit bestehen aus der in Anforderung (A49) definierten Liste von CPE-Einträgen einen selektierten Eintrag in die Liste der CPE-Einträge des CPE-Profils hinzuzufügen. siehe Ziele (Z5), (Z7) (A54) Vermeidung doppelter CPE-Einträge im CPE-Profil Das zu entwickelnde System muss beim Hinzufügen eines CPE-Eintrags zu einem CPEProfil (A53) automatisch erkennen, ob dieser bereits im Profil existiert und entsprechend darauf reagieren, um mehrfache Einträge eines CPEs zu vermeiden. siehe Ziele (Z5), (Z7) (A55) CPE-Eintrag aus CPE-Profil entfernen Bei der Erstellung und Bearbeitung eines CPE-Profils muss für den Nutzer die Möglichkeit bestehen aus der in Anforderung (A50) definierten Liste von CPE-Einträgen einen selektierten Eintrag zu entfernen. siehe Ziele (Z5), (Z7) (A56) Zeitpunkt für CPE-Profil festlegen I Bei der Erstellung und Bearbeitung eines CPE-Profils muss für den Nutzer die Möglichkeit bestehen einen Zeitpunkt anzugeben, der bestimmt, ab wann Schwachstellen (CVEs) für CPE-Einträge des Profils frühestens veröffentlicht sein sollen. Hinweis: Beim späteren Durchsuchen der Datenbank sollen alle Schwachstellen ignoriert werden, die vor dem angegebenen Zeitpunkt veröffentlicht wurden siehe Ziele (Z5), (Z7) (A57) Zeitpunkt für CPE-Profil festlegen II Bei der Erstellung und Bearbeitung eines CPE-Profils muss für den Nutzer die Möglichkeit bestehen einen Zeitpunkt anzugeben, der bestimmt, bis wann Schwachstellen (CVEs) für CPE-Einträge des Profils spätestens veröffentlicht sein sollen. Hinweis: Beim späteren Durchsuchen der Datenbank sollen alle Schwachstellen ignoriert werden, die nach dem angegebenen Zeitpunkt veröffentlicht wurden siehe Ziele (Z5), (Z7) Anhang 105 (A58) Zeitraum für CPE-Profil festlegen Bei der Erstellung und Bearbeitung eines CPE-Profils müssen die in den Anforderungen (A56) und (A57) definierten Zeitpunkte kombiniert werden können, um so einen Zeitraum festzulegen, in dem die CVEs für das CPE-Profil veröffentlicht sein sollen. siehe Ziele (Z5), (Z7) (A59) Speichertort für das CPE-Profil abfragen I Bei der Erstellung und Bearbeitung eines CPE-Profils muss beim Speichervorgang der Name und der Speicherort, in welchem das CPE-Profil gespeichert werden soll, abgefragt werden. siehe Ziele (Z5), (Z7) (A60) Speichertort für das CPE-Profil abfragen II Wenn der Nutzer ein CPE-Profil bearbeiten möchte, muss der Speicherort des zu bearbeitenden CPE-Profils abgefragt werden. siehe Ziele (Z5), (Z7) (A61) Speichertort für das CPE-Profil abfragen III Wenn der Nutzer das CVE-Verzeichnis anhand eines CPE-Profils nach CVE-Einträgen durchsuchen möchte, muss der Speicherort des CPE-Profils abgefragt werden. siehe Ziele (Z5), (Z7) (A62) CVE-Verzeichnis anhand des CPE-Profils durchsuchen Das zu entwickelnde System muss anhand eines CPE-Profils alle CVE-Einträge des CVEVerzeichnisses finden, die mit dem im Profil hinterlegten CPE-Einträgen verknüpft und im hinterlegten Zeitraum, falls vorhanden, veröffentlicht sind. siehe Ziele (Z5), (Z7) Inkonsistenzen (A63) Prüfung der Datenbank auf inkonsistente CVEs Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, das in der Datenbank gespeicherte CVE-Verzeichnis auf inkonsistente CVE-Einträge prüfen zu können. siehe Ziel (Z8) (A64) Anzahl der inkonsistenten CVEs darstellen Die zu entwickelnde Software muss nach der Überprüfung der inkonsistenten CVEs (A63) die Anzahl der CVE-Einträge, die eine Inkonsistenz vorweisen, darstellen. siehe Ziel (Z8) (A65) Liste aller inkonsistenten CVE-Einträge darstellen Die zu entwickelnde Software muss nach der Überprüfung der Inkonsistenzen (A63) eine Liste aller CVE-Einträge, die eine Inkonsistenz vorweisen, darstellen. siehe Ziel (Z8) (A66) Detaillierte Ansicht eines inkonsistenten CVE-Eintrags Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, eine detaillierte Ansicht eines, aus der Liste der inkonsistenten CVE-Einträge stammenden (A65), CVE-Eintrags anzuzeigen. siehe Ziel (Z4) Anhang 106 Statistiken (A67) Statistik zur Anzahl der CVEs Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, eine Statistik zu der Anzahl der im Jahr veröffentlichten CVEs zu erzeugen. siehe Ziel (Z9) (A74) Statistik zur Anzahl der CVEs eines CPE-Profils Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, eine Statistik, zu der Anzahl der im Jahr veröffentlichten CVEs eines bestimmten CPE-Profils, zu erzeugen. siehe Ziel (Z9) (A68) Statistik zur Häufigkeit von verknüpften CWE-IDs Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten eine Statistik zu erzeugen, in der die Anzahl der CVEs, gruppiert nach den verwendeten CWE-IDs, dargestellt werden. Beispiel: Ist die CWE-ID „CWE-16“ in 53 CVE-Einträgen angegeben, so soll in der Statistik die ID „CWE-16“ mit der Anzahl 53 dargestellt werden. Ist in einem CVE-Eintrag keine CWE-ID angegeben, so wird die CVE-ID in dieser Statistik ignoriert. siehe Ziel (Z9) (A75) Statistik zur Häufigkeit von verknüpften CWE-IDs in einem CPE-Profil Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten eine Statistik zu erzeugen, in der die Anzahl der CVEs, gruppiert nach den verwendeten CWE-IDs, dargestellt werden. siehe Ziel (Z9) (A69) Statistik zu der Verteilung der CVSS-Base-Scores Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, eine Statistik zu der Verteilung aller in der Datenbank vorhandenen CVSS-Base-Scores zu erzeugen. Hinweis: Der CVSS-Score soll in Bereiche 1-2, 2-3 usw. aufgeteilt werden. Anschließend soll die Anzahl aller CVE-Einträge, welche einen CVSS-Base-Score im entsprechenden Bereich besitzen, in der Statistik aufgezeigt werden. siehe Ziel (Z9) (A76) Statistik zu der Verteilung der CVSS-Base-Scores in einem CPE-Profil Die zu entwickelnde Software muss dem Nutzer die Möglichkeit bieten, eine Statistik zu der Verteilung aller, für ein Profil gefundenen CVSS-Base-Scores zu erzeugen. siehe Ziel (Z9) (A70) Format der Statistiken Die Werte der in den Anforderungen (A67) bis (A69) und (A74) bis (A76) definierten Statistiken müssen alle automatisiert in eine Excel-Datei übertragen werden siehe Ziel (Z9) (A71) Format der Statistiken Aus den in der Anforderung (A70) übertragenen Werten muss automatisiert ein ExcelDiagramm erzeugt werden. siehe Ziel (Z9) Anhang 107 Funktionale Anforderungen (A28) Dauer der Ladevorgänge Die zu entwickelnde Software muss eine Reaktionszeit von maximal 10 Sekunden gewährleisten. Hinweis: Zur Reaktionszeit zählt beispielsweise das Öffnen der detaillierten Ansicht eines CVE-Eintrags oder das Öffnen des Menüfensters zur Erstellung eines CPE-Profils. Das Updaten der Datenbank zählt nicht als Reaktionszeit! siehe Ziel (Z4) (A29) Benutzeroberfläche Die Benutzeroberfläche muss strukturiert und übersichtlich sein. siehe Ziel (Z4) Anhang 108 9.3 E-Mail-Korrespondenzen E-Mail an MITRE Datum:06.12.2015 Von: Scherf, Matthias <[email protected]> An: [email protected] Text: Dear CVE-Team, I am currently writing my Bachelor Thesis dealing with the use of the CVE-dictionary for my university degree. Because of that, I programmed a Tool which imports your CVE-dictionary. There are some things that I find very strange and I would love to have some explanations from you: 1) I got CVE-entrys in my database which are not RESERVED and these CVEs did not have any CPEs assigned to them (for example CVE-2015-8480). This is strange because: What does a Vulnerability tell me if I dont know WHERE it appears? Right now I have 577 cases in which this problem appears. 2) I noticed a problem with CPEs, for example in CVE-2015-7200. In the summary it says: „…before 42.0 and Firefox ESR 38.X …“. So every Firefox version which is > 42 is effected by this CVE. But in the CPE-list of this CVE only firefox version 41.0.1 appears. That means (as I understand it) that all the smaller versions are not affected despite the text in the summary of the CVE. Is that possible? With kind regards, Matthias Scherf Hochschule-Trier Anhang 109 Datum:08.12.2015 Von: Coffin, Chris <[email protected]> An: Scherf, Matthias <[email protected]> Text: Matthias, > I got CVE-entrys in my database which are not RESERVED and these CVEs did not have any CPEs assigned to them (for example CVE-2015-8480). CVE-2015-8480 does appear to have one CPE assigned on the NVD (https://web.nvd.nist.gov/view/vuln/detail?vulnID=CVE-2015-8480). It is possible that NIST had not yet analyzed this CVE to determine applicable CPEs before you queried it. Please note that CPEs are not defined by the MITRE CVE Team. The NIST NVD team ([email protected]) assigns CPEs and you can contact them with questions related to the CPE assignments. > I noticed a problem with CPEs, for example in CVE-2015-7200. In the summary it says: „…before 42.0 and Firefox ESR 38.X …“. So every Firefox version which is > 42 is effected by this CVE. But in the CPE-list of this CVE only firefox version 41.0.1 appears. That means (as I understand it) that all the smaller versions are not affected despite the text in the summary of the CVE. Is that possible? Note that the full version string is “before 42.0 and Firefox ESR 38.x before 38.4.” This translates to, Firefox versions less than 42.0 are vulnerable AND Firefox ESR versions less than 38.4 are vulnerable. Versions 42.0 and 38.4 are the fixed versions according to the vendor. Chris Coffin The CVE Team The MITRE Corporation Bemerkung zur Antwort: Leider wurde am 07.12-2015 der CVE-Eintrag „CVE-2015-8480“ aktualisiert. Bei dieser Aktualisierung wurde auch der von Herrn Coffin angesprochene CPE-Eintrag hinzugefügt. Abbildung 65, Ausschnitt des Eintrags CVE-2015-8480 aus der NVD-Webseite Die Antwort zur zweiten Frage bezieht sich leider nicht auf die XML-Datei, weswegen eine weitere Email zu diesem Sachverhalt an das NIST NVD-Team gesendet wurde. Anhang 110 E-Mail an das NIST NVD-Team Datum:09.12.2015 Von: Scherf, Matthias <[email protected]> An: [email protected] Text: Dear CPE-Team I am currently writing a paper for my university degree about using the CVE-dictionary. Because of that, I programmed a Tool which imports the CVE-dictionary (For exmaple from this link „http://static.nvd.nist.gov/feeds/xml/cve/nvdcve-2.0-2015.xml.zip“). I have got a problem with some CPE-Entries. In the summary of the CVE-2015-7200 it says: „…before 42.0 and Firefox ESR 38.X …“. How can I see this in the CPE declaration of this CVE in the XML file? The file says: <vuln:vulnerable-configuration id="http://www.nist.gov/"> <cpe-lang:logical-test operator="OR" negate="false"> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox:41.0.2"/> </cpe-lang:logical-test> </vuln:vulnerable-configuration> <vuln:vulnerable-configuration id="http://www.nist.gov/"> <cpe-lang:logical-test operator="OR" negate="false"> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox_esr:38.0"/> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox_esr:38.0.1"/> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox_esr:38.0.5"/> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox_esr:38.1.0"/> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox_esr:38.1.1"/> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox_esr:38.2.0"/> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox_esr:38.2.1"/> <cpe-lang:fact-ref name="cpe:/a:mozilla:firefox_esr:38.3.0"/> </cpe-lang:logical-test> </vuln:vulnerable-configuration> <vuln:vulnerable-software-list> <vuln:product>cpe:/a:mozilla:firefox_esr:38.1.1</vuln:product> <vuln:product>cpe:/a:mozilla:firefox_esr:38.2.0</vuln:product> <vuln:product>cpe:/a:mozilla:firefox_esr:38.0.1</vuln:product> <vuln:product>cpe:/a:mozilla:firefox_esr:38.1.0</vuln:product> <vuln:product>cpe:/a:mozilla:firefox:41.0.2</vuln:product> <vuln:product>cpe:/a:mozilla:firefox_esr:38.2.1</vuln:product> <vuln:product>cpe:/a:mozilla:firefox_esr:38.3.0</vuln:product> <vuln:product>cpe:/a:mozilla:firefox_esr:38.0</vuln:product> <vuln:product>cpe:/a:mozilla:firefox_esr:38.0.5</vuln:product> </vuln:vulnerable-software-list> So Is there some indication where I can see that all earlier versions are affected? It is the same with CVE-2015-8480 where on the website (https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8480 ) it is saying „cpe:/a:google:chrome:46.0.2490.86 and previous versions“ but in the XML file it says: <vuln:vulnerable-configuration id="http://nvd.nist.gov/"> <cpe-lang:logical-test operator="OR" negate="false"> Anhang 111 <cpe-lang:fact-ref name="cpe:/a:google:chrome:46.0.2490.86"/> </cpe-lang:logical-test> </vuln:vulnerable-configuration> <vuln:vulnerable-software-list> <vuln:product>cpe:/a:google:chrome:46.0.2490.86</vuln:product> </vuln:vulnerable-software-list> Thank you and best wishes, Matthias Scherf Hochschule-Trier E-Mail an Secunia Datum:07.12.2015 Von: Scherf, Matthias <[email protected]> An: [email protected] Text: Dear Secunia PSI-Team I am currently writing my Bachelor Thesis dealing with Software Vulnerability Tools and I have got a question which is really bothering me. Is it possible that Secunia PSI only displays a vulnerability for a software if an update is available? I have never seen Secunia showing me vulnerabilities if that has not been the case. Sincerely, Matthias Scherf Hochschule-Trier
