Code-to-Cloud-Sicherheit mit dem Common Configuration Scoring System verbessern
14. Dezember 2023
0 Min. LesezeitProprietäre Schweregradbewertungen bedeuten für AppSec-Teams oft zusätzlichen Aufwand. Bei jedem neuen Anbieter müssen Sie dessen individuelles Schweregrad-Framework bewerten und Risiken zwischen verschiedenen Tools übertragen. Um diesen Aufwand zu beseitigen und unseren Kunden eine klare Sicherheitsbewertung von Konfigurationen über den gesamten SDLC hinweg zu ermöglichen, wird Snyk unsere Regeln für Code-to-Cloud-Sicherheit künftig nach dem Common Configuration Scoring System (CCSS) standardisieren!
Mit diesem Update des Snyk Security Research-Teams verfolgen wir weiterhin unsere Mission, Entwickler und Sicherheitsteams gleichermaßen dabei zu unterstützen, Sicherheitsprobleme besser zu bewerten, zu priorisieren und zu behandeln – für einen sichereren und effizienteren Entwicklungslebenszyklus.
Die Regeln und Schweregrade der neuesten Version von Snyk Infrastructure as Code (IaC), IaC+, werden nach CCSS bewertet. So kann Snyk Kunden präzisere Risikobewertungen für ihre Infrastructure-as-Code- und Cloud-Konfigurationen bereitstellen, die auf dem technischen Schweregrad (CCSS), Threat Intelligence sowie dem Anwendungs- und Geschäftskontext basieren.
Was sagt ein Schweregrad aus?
Branchenübliche Frameworks wie das Common Vulnerability Scoring System (CVSS) und das Common Configuration Scoring System (CCSS) bieten eine wertvolle Methodik zur Bewertung von Sicherheitslücken und eine gemeinsame Sprache für alle. Anbieter müssen dadurch kein eigenes Framework entwickeln, und Kunden können Anbieter direkt miteinander vergleichen, ohne die Bewertungen erst übertragen zu müssen.
Kurz gesagt: Diese Frameworks definieren verschiedene Metriken und Formeln, mit denen sich deren Werte in einen Score von 0 bis 10 und einen entsprechenden Schweregrad umwandeln lassen: niedrig, mittel, hoch oder kritisch.
Was ist das Common Configuration Scoring System?
Das Common Configuration Scoring System (CCSS) wurde vom National Institute of Standards and Technology (NIST) entwickelt. Es basiert auf CVSS und wurde angepasst, um Sicherheitsprobleme bei Softwarekonfigurationen zu behandeln. Da IaC-Fehlkonfigurationen im Wesentlichen Sicherheitskonfigurationen betreffen, können wir CCSS auf sie anwenden.
Die Standardisierung mit CCSS behebt mehrere der zuvor genannten Probleme. Mithilfe vertrauter, auf CVSS basierender Begriffe, Metriken und Formeln ordnet CCSS IaC-Fehlkonfigurationen Vektoren zu. Anhand dieser Vektoren können wir den Score und Schweregrad eines Problems ermitteln.
So kann Snyk das bisherige Verfahren zur Zuweisung von Schweregraden für IaC-Fehlkonfigurationen ablösen. Der Wechsel zum CCSS-Standard erhöht außerdem die Transparenz: Snyk zeigt Vektor, Score und Schweregrad an, ohne dass eine lange Einarbeitung nötig ist – ähnlich wie bereits bei CVSS-Sicherheitslücken.
Der CCSS-Vektor für das obige Problem lautet `AV:L/AC:H/Au:M/C:P/I:C/A:N/PL:U/EM:A`. Daraus ergeben sich ein Basis-Score von `8.3` und der Schweregrad `High`. Die ersten sechs Metriken sind in der obigen Grafik dargestellt, die letzten beiden – `PL` und `EM` beziehungsweise `Privilege Level` und `Exploitation Method` – jedoch nicht. Der Hauptgrund dafür ist, dass diese beiden Metriken den Basis-Score nicht beeinflussen, obwohl sie eine wichtige Rolle spielen.
`Privilege Level` kann den Wert `User`, `Application`, `Root` oder `Not Defined` annehmen und gibt an, welche Ebene des unbefugten Zugriffs ein Angreifer erreichen könnte. Im Basisvektor und beim Basis-Score liefert `PL` zusätzliche Informationen für Kunden und wird bei der Berechnung bestimmter Umgebungsmetriken verwendet.
`Exploitation Method` ist etwas interessanter, da die Werte vieler Basismetriken vom Wert der Metrik `EM` abhängen. `EM` kann den Wert `Active` oder `Passive` annehmen. `Active`-Fehlkonfigurationen machen eine Schwachstelle für Angreifer ausnutzbar, etwa wenn AWS-S3-Buckets öffentlich lesbar sind oder eine Datenbank mit einem Standardpasswort für den Root-Benutzer nach außen exponiert ist. `Passive`-Fehlkonfigurationen verhindern autorisierte Aktionen oder erschweren Verteidigern die Arbeit. Beispiele dafür sind deaktiviertes API-Logging oder Datenbanksicherungen, die nicht lange genug aufbewahrt werden. `Passive`-Fehlkonfigurationen sind üblicherweise Fehler oder Richtlinienverstöße, die sich schnell beheben lassen. `Active`-Fehlkonfigurationen können dagegen komplexer sein und mehr Planung und Analyse erfordern.
Wie hat Snyk CCSS implementiert?
Snyk verfügt über eine große Anzahl von Sicherheitsregeln zur Prüfung von IaC- und Cloud-Konfigurationen, denen Schweregrade nach dem bisherigen Verfahren zugewiesen wurden. CCSS-Vektoren manuell hinzuzufügen, Scores zu berechnen und neue Schweregrade abzuleiten, wäre eine mühsame Aufgabe. Skripte könnten dabei helfen, aber ihnen fehlen die nötigen Entscheidungsfähigkeiten. Zum Glück gibt es einen besseren Weg!
Durch die Integration von KI in den Implementierungsprozess konnten wir die Anpassung unseres bestehenden Regelsatzes an die CCSS-Standards vereinfachen. Die KI wird mithilfe von Prompts gesteuert, die wir um unser besonderes Fachwissen ergänzt haben. So wird der Schweregrad jeder Fehlkonfiguration konsistent und präzise bestimmt. Das macht unsere Sicherheitsbewertungen für Nutzer transparenter und zuverlässiger und unterstreicht zugleich Snyks Engagement, die Entwickler-zentrierte Sicherheitspraxis der Branche maßgeblich voranzubringen.
Aufbauend auf unseren bisherigen Erfahrungen mit KI machten wir uns daran, die CCSS-Spezifikation zusammen mit zusätzlichen, auf unseren Untersuchungen basierenden Richtlinien in einem Prompt zusammenzufassen. Nach der Analyse der Ergebnisse ergab sich folgende Verteilung der Schweregrade:
Und so sieht sie nun aus:
Die obigen Diagramme zeigen, dass unsere bisherigen Snyk-Schweregradeinstufungen oft deutlich konservativer waren als die nach CCSS.
Die Standardisierung unseres Schweregradsystems nach CCSS bietet nicht nur ein wiederholbares Verfahren zur Bestimmung von Regelschweregraden, sondern bewahrt auch wertvolle Kontextdaten für detaillierte Analysen, etwa den Risikowert von Snyk. Darüber hinaus zeigt die Analyse der Basis-Score-Verteilung in unserem Datensatz eine Glockenkurve. Das entspricht der erwarteten statistischen Verteilung von Scores zwischen 0 und 10 und bestätigt, dass die KI-gestützte CCSS-Methode ausgewogene und verlässliche Schweregradbewertungen liefert.
Wie geht es mit Snyk IaC weiter?
Halten Sie Ausschau nach Updates aus der Sicherheitsforschung und der Einführung von CCSS-Schweregraden auf updates.snyk.io!
Wenn Sie mehr über das Common Vulnerability Scoring System (CVSS) erfahren möchten, das es seit fast zwei Jahrzehnten gibt: Wir haben schon oft, sehr oft darüber berichtet.
Wenn Sie mehr darüber erfahren möchten, wie KI als Entwicklungstool unseren Sicherheitsforschungsprozess unterstützt, lesen Sie hier weiter – dort finden Sie auch einige Best Practices.
