Open marcel-haag opened 1 year ago
Erfassung von Schwachstellen und Kommunikation
Da öfter dieselbe Sicherheitslücke unabhängig voneinander mehrfach entdeckt wird und nicht jeder Hersteller seit jeher alle Sicherheitslücken öffentlich dokumentiert hat, gibt es Bemühungen, einen zentralen „Ort der Wahrheit” zu schaffen. Diese Rolle nimmt seit langer Zeit CVE (Common Vulnerabilities and Exposures) ein. → https://cve.mitre.org/
CVE ist eine über das Internet nutzbare Datenbasis, die jeder Sicherheitslücke eine eindeutige Nummer, die CVE-ID, zuweist; die CVE-ID hat das Format CVE-YYYY-nnnn, besteht also aus einem konstanten Präfix, dem Jahr der Eintragung und einer fortlaufenden Nummer, Einträge zunächst als candidate und nach dem Aussortieren von Falschmeldungen und Duplikaten als entry führt, eine Kurzbeschreibung sowie Verweise auf, genauere Beschreibungen enthält. Insbesondere ist keine automatisierte Auswertung, z.B. mit Software-Tools, möglich. Deshalb gibt es Bestrebungen, das verwendete Vokabular durch fest vorgegebene Aufzählungen und Begriffsdefinitionen zu vereinheitlichen: CWE (Common Weakness Enumeration) ermöglicht einheitliche Schwachstellenbeschreibungen; beispielsweise steht CWE-120 für klassische Buffer Overflows in C-Programmen. → https://cwe.mitre.org/
CPE (Common Product Enumeration) gibt einheitliche Bezeichnungen für bekannte Softwareprodukte und deren Versionsnummern vor. → https://cpe.mitre.org/
CAPEC (Common Attack Pattern Enumeration and Classification) führt einheitliche Bezeichnungen für Angriffswege ein; beispielsweise beschreibt CAPEC-66, was unter SQL Injection zu verstehen ist und wie der Angriff vermieden werden kann. → https://capec.mitre.org/
Durch die Anreicherung von Meldungen mit diesen Angaben wird der Grundstein für Security-Tools gelegt, die neue Beschreibungen von Sicherheitslücken automatisch auswerten und den Kunden verständlich aufbereitet anzeigen können. Eine wichtige Rolle spielt dabei das Security Content Automation Protocol (SCAP), das zunehmend in Enterprise-Security-Produkte integriert wird. → https://csrc.nist.gov/projects/security-content-automation-protocol/
Mit SCAP-Werkzeugen wie der Open-Source-Software OpenSCAP können beispielsweise Server automatisiert durchsucht werden, um festzustellen, ob darauf Software mit bekannten Sicherheitslücken installiert ist. → https://www.open-scap.org/
Die National Vulnerability Database (NVD) reichert die CVE-Entries mit diesen Angaben an und enthält auch den CVSS Score. → https://nvd.nist.gov/
Bewertung und Priorisierung mit CVSSv3 Aufgrund der Verschiedenartigkeit von Sicherheitslücken ist es schwierig, rein intuitiv abzuschätzen, welche davon die „größte” bzw. dringendste ist. Ein empirischer Ansatz, der zum De-facto-Standard geworden ist, ist das Common Vulnerability Scoring System (CVSS), das aktuell in Version 3 vorliegt. Es zielt darauf ab, jeder Sicherheitslücke auf Basis eines einheitlichen, möglichst objektiven Bewertungsverfahrens eine Zahl, den sogenannten CVSS Score, zuzuordnen. Es ermöglicht also eine quantitative Bewertung von Verwundbarkeiten anhand einer definierten Menge typischer Charakteristika von Sicherheitslücken. → https://www.first.org/cvss/
Zwingend anzuwenden sind die sogenannten Base Metrics, die die grundlegenden, inhärenten und unveränderlichen Charakteristika von Sicherheitslücken abdecken. Optional können die Temporal Metrics , die sich im Laufe der Zeit ändernde Aspekte bewerten, und die Environmental Metrics angewandt werden; Letztere berücksichtigen die konkrete Betriebsumgebung, für die eine Sicherheitslücke analysiert wird. In jeder der drei Kategorien werden für jede Sicherheitslücke dieselben Fragen gestellt, für die eine der vorgegebenen Antwortmöglichkeiten ausgewählt werden muss. Es handelt sich insgesamt also um einen recht einfach anzuwendenden Multiple-Choice-Fragebogen, der in Form eines sogenannten CVSS Calculator bereitgestellt wird.
Der CVSS Score ist eine Zahl zwischen 0 und 10 und wird meist mit einer Nachkommastelle Genauigkeit angegeben.
Dabei umfassen die CVSS Base Metrics den Angriffsweg (Attack Vector): Benötigt der Angreifer physischen Zutritt zum System, muss er einen Account auf dem Zielsystem haben, lässt sich der Angriff aus dem LAN oder sogar über das Internet durchführen? die Komplexität des Angriffs (Attack Complexity): Ist er sehr einfach oder nur mit großem Aufwand durchzuführen? die für den Angriff notwendigen Berechtigungen (Privileges required): Kann ihn jeder durchführen, nur registrierte Benutzer oder sogar nur Administrator- Accounts? die Mitwirkung eines Benutzers (User Interaction): Kann der Angreifer die Sicherheitslücke direkt selbst ausnutzen oder ist er wie z. B. bei einem malwareverseuchten E-Mail-Anhang auf die „Mitarbeit” eines Opfers angewiesen? die Auswirkung auf andere Systeme (Scope): Betrifft eine Sicherheitslücke nur ein System oder wirkt sie sich typischerweise auch auf andere Systeme aus? die Auswirkungen auf die IT-Sicherheitsziele (Confidentiality, Integrity, Availability): Sie sind qualitativ in einer der Stufen nicht, niedrig oder hoch anzugeben.
Je höher der CVSS Base Score ist, desto schneller sollte sich der Hersteller um einen Patch bemühen.
Die Temporal Metrics und die Environmental Metrics liefern weitere Fragen, deren Antworten nur zu einem bestimmten Zeitpunkt bzw. in einer bestimmten Umgebung gelten. Die drei Temporal Metrics beziehen sich auf den Reifegrad von Exploits für die Sicherheitslücke (Exploit Code Maturity): Sind Exploits reine Theorie, gibt es einen Proof-of-Concept-Exploit z.B. für eine bestimmte Plattform, ist ein gut funktionierendes Exploit in Umlauf geraten oder gibt es schon einen Computerwurm, bei dem sich die Schadsoftware selbstständig über das Internet verbreitet? verfügbare Abhilfen (Remediation Level): Gibt es noch gar keine Lösung, ist zumindest ein Workaround bekannt, wurde ein vorläufiger Patch oder bereits ein offizieller dauerhafter Fix veröffentlicht? die Zuverlässigkeit der Sicherheitslückenmeldung (Report Confidence): Handelt es sich um ein reines Gerücht, ist die Sicherheitslücke nachvollziehbar dokumentiert oder wurde sie sogar schon vom Hersteller bestätigt?
Ressourcensammlung für C4PO-Ticket Improvement(s) bezüglich dem Eintragen von findings / comments im Pentest zu..
oder allgemein Erfassung von Schwachstellen und Kommunikation.