Close

Schweregrade von Sicherheitsvorfällen


Wie Sicherheitsverletzungen gemeldet werden

  • Sicherheitsscanner-Tickets wie die von Nexpose und Snyk
  • Bug-Bounty-Ergebnisse, die von Sicherheitsexperten über Bugcrowd gefunden werden
  • Sicherheitsschwachstellen, die vom Sicherheitsteam im Rahmen von Überprüfungen gemeldet werden
  • Von Atlassian-Mitarbeitenden gemeldete Sicherheitsschwachstellen

Framework und Einstufung des Schweregrads

Atlassian nutzt das Common Vulnerability Scoring System (CVSS), um Sicherheitsrisiken auszuwerten und entdeckte Sicherheitslücken zu priorisieren. CVSS ist ein System zum Erfassen von Sicherheitsrisiken, das sich in der Branche etabliert hat. Auf FIRST.org kannst du mehr über CVSS erfahren.

Schweregrade

Die Sicherheitsempfehlungen von Atlassian enthalten Angaben zu Schweregraden. Diese Schweregrade basieren auf einer von uns ermittelten CVSS-Bewertung (Common Vulnerability Scoring System) für jede spezifische Schwachstelle.

  • Kritisch
  • Hoch
  • Mittel
  • Niedrig

Für CVSS v3 verwendet Atlassian das folgende Bewertungssystem für den Schweregrad:

CVSS V3-BEWERTUNGSBEREICH
EMPFOHLENER SCHWEREGRAD

9,0 – 10,0

Kritisch

7,0 – 8,9

Hoch

4,0 – 6,9

Mittel

0,1 – 3,9

Niedrig

In manchen Fällen zieht Atlassian weitere, nicht mit der CVSS-Bewertung zusammenhängende Faktoren heran, um den Schweregrad von Sicherheitslücken zu bewerten. Dieser Ansatz wird von der CVSS-v3.1-Spezifikation unterstützt:

Profitipp:

Verbraucher können CVSS-Informationen als Grundlage für einen organisatorischen Schwachstellenmanagementprozess verwenden, der auch Faktoren berücksichtigt, die nicht Teil von CVSS sind, um die Bedrohungen ihrer Technologieinfrastruktur einzustufen und fundierte Entscheidungen zur Behebung zu treffen. Zu diesen Faktoren können gehören: Anzahl der Kunden in einer Produktlinie, finanzielle Verluste aufgrund von Datenschutzverletzungen, Bedrohung des Lebens oder Eigentums oder die öffentliche Meinung bei stark in den Medien diskutierten Schwachstellen. Diese Faktoren liegen außerhalb des Umfangs von CVSS.

Falls Atlassian diesen Ansatz verfolgt, beschreiben wir, welche zusätzlichen Faktoren berücksichtigt wurden und aus welchem Grund, wenn wir die Schwachstelle öffentlich machen.

Es folgen einige Beispiele für Schwachstellen, die mit einem bestimmten Schweregrad verknüpft sind. Bitte beachte, dass die Details deiner Installation bei dieser Bewertung nicht berücksichtigt werden und die Ergebnisse nur als Anhaltspunkt zu verstehen sind.

Schweregrad: kritisch

Schwachstellen, die unter "kritisch" laufen, weisen üblicherweise die meisten der folgenden Eigenschaften auf:

  • Die Ausnutzung der Schwachstelle führt womöglich zur Kompromittierung von Servern oder Infrastrukturgeräten auf Stammebene.
  • Die Ausnutzung erfolgt in der Regel ohne Umwege, d. h. der Angreifer braucht keine besonderen Authentifizierungsdaten oder Kenntnisse über einzelne Opfer und muss keinen Zielbenutzer (etwa mittels Social Engineering) dazu überreden, spezielle Maßnahmen vorzunehmen.

Bei kritischen Schwachstellen empfiehlt es sich, möglichst schnell Patches oder Upgrades durchzuführen, falls keine Behebungsmaßnahmen vorhanden sind. Ein Faktor zur Risikominimierung wäre beispielsweise, wenn niemand über das Internet auf deine Installation zugreifen kann.

Schweregrad: hoch

Schwachstellen, die unter "hoch" laufen, weisen üblicherweise einige der folgenden Eigenschaften auf:

  • Die Ausnutzung der Schwachstelle ist schwierig.
  • Die Ausnutzung könnte zu erweiterten Privilegien führen.
  • Die Ausnutzung kann zu erheblichen Datenverlusten oder Ausfällen führen.

Schweregrad: mittel

Schwachstellen, die unter "mittel" laufen, weisen üblicherweise einige der folgenden Eigenschaften auf:

  • Schwachstellen, bei denen der Angreifer einzelne Opfer mit Social-Engineering-Techniken manipulieren muss
  • Denial-of-Service-Schwachstellen, die sich schwer einrichten lassen
  • Exploits, bei denen ein Angreifer sich im selben Netzwerk befinden muss wie das Opfer
  • Schwachstellen, deren Ausnutzung nur eingeschränkten Zugang gewährt
  • Schwachstellen, bei denen für eine erfolgreiche Ausnutzung Benutzerprivilegien erforderlich sind.

Schweregrad: niedrig

Schwachstellen im niedrigen Bereich wirken sich in der Regel kaum auf Geschäftsabläufe in Unternehmen aus. Für die Ausnutzung von derartigen Schwachstellen ist normalerweise der Zugriff auf ein lokales oder physisches System erforderlich. Schwachstellen im Code von Drittanbietern, auf die nicht vom Atlassian-Code aus zugegriffen werden kann, werden ggf. auf einen niedrigeren Schweregrad heruntergestuft.

Zeitleiste für die Behebung

Die Service Level Objectives zur Behebung von Sicherheitsschwachstellen bestimmt Atlassian je nach Schweregrad und Produkt. Es gibt einen Zeitrahmen für die Behebung von Sicherheitsproblemen, der unserer Richtlinie zur Behebung von Sicherheitslücken entspricht.

Verkürzte Problembehebungsfristen gelten für:

  • Alle cloudbasierten Atlassian-Produkte
  • Jira Align (sowohl die Cloud-Version als auch die selbstverwaltete Version)
  • Jede Software bzw. jedes System, das von Atlassian verwaltet wird oder auf der Atlassian-Infrastruktur läuft

Verlängerte Problembehebungsfristen gelten für:

  • Alle selbstverwalteten Atlassian-Produkte
    • Das sind Produkte, die von Kunden auf kundenverwalteten Systemen installiert werden.
    • Dazu gehören die Data-Center-, Desktop- und Mobilanwendungen von Atlassian

Zeitrahmen für die CVSS-Auflösung

Schweregrade
Verkürzte Problembehebungsfristen
Verlängerte Problembehebungsfristen

Kritisch

Innerhalb von 10 Tagen nach Bestätigung Innerhalb von 90 Tagen nach Bestätigung

Hoch

Innerhalb von 4 Wochen nach Bestätigung Innerhalb von 90 Tagen nach Bestätigung

Mittel

Innerhalb von 12 Wochen nach Bestätigung Innerhalb von 90 Tagen nach Bestätigung

Niedrig

Innerhalb von 25 Wochen nach Bestätigung Innerhalb von 180 Tagen nach Bestätigung