Close

Unser Ansatz für externe Sicherheitstests


Atlassian erhält regelmäßig Anfragen nach Berichten zu Penetrationstests, weil sich Kunden von unseren Prozessen zur Ermittlung (und Behebung) von Sicherheitsschwachstellen in Atlassian-Produkten und der Atlassian Cloud überzeugen möchten. Unser Ansatz für externe Sicherheitstests beruht auf dem Konzept der "kontinuierlichen Sicherheit": Statt punktueller Penetrationstests nutzen wir ein durchgehend aktives Modell für Tests, das in Form eines Bug-Bounty-Programms mit Crowdsourcing umgesetzt wird.

Unsere Philosophie und unser Ansatz

Atlassian ist für seine Werte bekannt. Diese Werte beeinflussen unser gesamtes Handeln – und damit auch unseren Ansatz für Sicherheitstests. In der Praxis sind wir durch unsere Werte zu folgenden Philosophien und Ansätzen gelangt:

  • Bugs sind ein unvermeidlicher Teil des Entwicklungsprozesses. Die Frage ist daher nicht, ob überhaupt Bugs vorhanden sind, sondern wie effektiv und schnell wir diese finden und beheben. Das bedeutet nicht, dass wir Bugs einfach hinnehmen – natürlich arbeiten wir ständig an Innovationen, um ihre Häufigkeit und ihren Schweregrad zu mindern. Dennoch ist das Leugnen von Software-Bugs kein effektiver Ansatz.
  • Wir verfolgen das Ziel, die Kosten für das Aufspüren und Ausnutzen von Schwachstellen in unseren Produkten und Services zu erhöhen. Durch eine schnelle Problemerkennung und -behebung versuchen wir, das Auffinden von sicherheitsrelevanten Bugs teurer zu machen. Wenn wir die Kosten für das Ausnutzen einer Schwachstelle erhöhen – indem wir dafür sorgen, dass es länger dauert und mehr Know-how und Ressourcen seitens der Angreifer erfordert –, verringern wir die Rendite dieser Angreifer. Sobald die Rendite niedrig genug ist, wird es für Angreifer unattraktiv, nach Schwachstellen zu suchen und diese auszunutzen.
  • Wir unterstützen und nutzen Branchenstandards. Die Standardisierung unserer Terminologie und Herangehensweise hilft uns sicherzustellen, dass wir alles abdecken. Den Kunden hilft sie, unser Vorgehen nachzuvollziehen. So sorgen beispielsweise gängige Schwachstellenbewertungen gemäß Common Vulnerability Scoring System (CVSS) zwischen uns und unseren Kunden für Klarheit über den Schweregrad konkreter Schwachstellen. Wir befolgen auch die in ISO 27001 und von der Cloud Security Alliance (CSA) dargelegten Prozesse zum Management von Schwachstellen.
  • Externe Sicherheitsforscher sind eine wertvolle Erweiterung unseres Teams. Wenn ein Atlassian-Produkt eine Schwachstelle aufweist, ist es in unserem Interesse und im Interesse der Kunden, diese so schnell wie möglich zu finden und zu beheben. Daher werden externe Sicherheitsforscher im Rahmen unseres Bug-Bounty-Programms finanziell entlohnt, wenn sie Schwachstellen in unseren Produkten entdecken. Mit der Unterstützung dieser externen Experten können wir unser Team weit über herkömmliche Ansätze hinaus skalieren.
  • Wir gehen bei unserem Programm für Sicherheitstests offen und transparent vor: Unser Bug-Bounty-Programm enthält Statistiken über die gefundenen Bugs. Wir legen offen, wie schnell wir sicherheitsrelevante Bugs zu beheben versuchen. Außerdem veröffentlichen wir unten auf dieser Seite zusammenfassende Testberichte, sofern es uns möglich ist.

Zuverlässige, kontinuierliche Sicherheit

Penetrationstests

Bei Produkten und Infrastrukturen mit hohem Risiko beauftragen wir durchaus Sicherheitsberatungsunternehmen mit Penetrationstests. Dies kann beispielsweise bei einer für uns eingerichteten neuen Infrastruktur (z. B. unserer Cloud-Umgebung), einem neuen Produkt (z. B. Trello) oder einer grundlegenden Umgestaltung der Architektur (z. B. zur verstärkten Nutzung von Microservices) der Fall sein.

Unser Ansatz für Penetrationstests ist in diesen Fällen sehr zielgerichtet und fokussiert. Im Allgemeinen werden Tests folgender Art durchgeführt:

  • White-Box-Tests: Die Tester erhalten zur Unterstützung ihrer Tests Designdokumente und Briefings von unseren Produktentwicklern.
  • Tests mit Code-Unterstützung: Die Tester erhalten umfassenden Zugriff auf die relevante Codebasis, damit sie unerwartetes Systemverhalten bei den Tests besser diagnostizieren und potenzielle Ziele leichter ermitteln können.
  • Bedrohungsbasierte Tests: Bei den Tests liegt der Fokus auf einem bestimmten Bedrohungsszenario, beispielsweise einer infizierten Instanz, bei der dann die laterale Verbreitung von diesem Ausgangspunkt aus getestet wird.

Wir veröffentlichen Beurteilungsschreiben (Letters of Assessment, LoAs) von unseren Partnern, die die Penetrationstests durchführen. Eine für die externe Nutzung bestimmte Version dieser LoAs ist unten auf dieser Seite zu finden. Da wir den Testern für ihre Beurteilungen umfassende Informationen zur Verfügung stellen, veröffentlichen wir nicht das gesamte Dokument. Die meisten dieser Systeme und Produkte werden später in unser öffentliches Bug-Bounty-Programm aufgenommen. So erhalten Kunden die gewünschte externe Bestätigung der Sicherheit. Die bei diesen Beurteilungen gefundenen Probleme werden selektiert und gemäß unserem Service Level Objective (SLO) für öffentliche Sicherheitsschwachstellen behoben.

Bug-Bounty-Programm

Unser Bug-Bounty-Programm wird von Bugcrowd gehostet. Ziel dieses Programms ist es, sicherzustellen, dass unsere Produkte fortlaufend auf Sicherheitsschwachstellen getestet werden. Dieses Herzstück unseres Programms für externe Sicherheitstests ist das Ergebnis umfassender Forschungen, Analysen und Vergleiche zwischen verschiedenen Testmodellen.

Wir sind davon überzeugt, dass die Teilnahme unabhängiger Sicherheitsforscher an unserem Bug-Bounty-Programm den effektivsten Prozess für externe Sicherheitstests darstellt. Dies begründen wir wie folgt:

  1. Bug-Bounty-Programme sind durchgehend aktiv. Penetrationstests dagegen dauern in der Regel nur wenige Wochen. In einer äußerst agilen Entwicklungsumgebung mit häufigen Releases sind kontinuierliche Tests unverzichtbar.
  2. Im Bug-Bounty-Programm kommen mehr als 60.000 potenzielle Tester zusammen. Für Penetrationstest stehen dagegen meist nur 1 bis 2 Personen zur Verfügung. Auch wenn diese 1 bis 2 Personen sehr effektiv arbeiten, können sie nie die geballten Fähigkeiten des Teams aus Bug-Bounty-Programmteilnehmern übertreffen.
  3. Bug-Bounty-Sicherheitsforscher entwickeln spezielle Tools und gehen sowohl vertikal (bestimmte Arten von Bugs) als auch horizontal (bestimmte Bountys) vor. Diese Spezialisierung maximiert die Wahrscheinlichkeit, auch schwer erkennbare – und dennoch erhebliche – Schwachstellen zu entdecken.

Für den internen Support setzen wir auch weiterhin Penetrationstests und spezialisierte Sicherheitsberater ein, aber für unser externes Programm mit hoher Abdeckung ist Bug Bounty besser geeignet. Wir sind überzeugt, dass die Kombination verschiedener Ansätze unsere Chancen auf die Aufdeckung von Schwachstellen maximiert.

Unser Bug-Bounty-Programm deckt mehr als 25 unserer Produkte und Umgebungen ab – von unseren Server-Produkten über mobile Apps bis hin zu Cloud-Produkten. Details zur Anzahl der gemeldeten Schwachstellen, unserer durchschnittlichen Reaktionszeit und der durchschnittlichen Prämienhöhe sind auf der Bugcrowd-Website zu finden. Dort haben sich mehr als 800 Tester speziell für unser Programm registriert.

Zu den Schwachstellen, die im Zuge unseres Bug-Bounty-Programms erkannt werden sollen, zählen gängige Bedrohungen aus den Listen des Open Web Application Security Project (OWASP) und des Web Application Security Consortium (WASC). Beispiele dafür sind:

  • Instanzübergreifende Datenlecks/Datenzugriffe
  • Remote-Code-Ausführung (Remote Code Execution, RCE)
  • Server-Side Request Forgery (SSRF)
  • Cross-Site-Scripting (XSS)
  • Cross-Site-Request-Forgery (CSRF)
  • SQL-Injection (SQLi)
  • XML External Entity-Angriffe (XXE)
  • Schwachstellen bei der Zugriffskontrolle (z. B. Insecure-Direct-Object-Reference-Probleme)
  • Probleme im Zusammenhang mit Path Traversal/Directory Traversal

Im Rahmen unserer Initiative für Offenheit und Transparenz laden wir alle Benutzer ein, die Seite zu unserem Bug-Bounty-Programm zu besuchen, sich für das Programm zu registrieren und uns auf den Prüfstand zu stellen.

Marketplace-AppsMarketplace-Apps sind vom Atlassian-Bug-Bounty-Hauptprogramm ausgeschlossen. Marketplace-Apps werden jedoch im Rahmen anderer, von Atlassian gehosteter Bug-Bounty-Programme geprüft, zum Beispiel dem Programm zur Offenlegung von Schwachstellen und dem Bug-Bounty-Programm für von Atlassian entwickelte Apps.

Von Kunden veranlasste Tests – Gemäß unseren Nutzungsbedingungen für unsere Cloud-Produkte erlauben wir von Kunden veranlasste Tests. Da wir uns zur Offenheit verpflichtet haben, veröffentlichen wir regelmäßig Statistiken aus unserem Bug-Bounty-Programm.

Wir sind der Meinung, dass unsere Bug-Bounty-Programme eine effiziente und ökonomische Methode sind, um die Sicherheit unserer Produkte und Services zu beurteilen. Gleichzeitig verstehen wir, dass Kunden gerne eigene Sicherheitstests durchführen möchten. Deshalb erlauben wir Sicherheitsbeurteilungen (Penetrationstests, Schwachstellentests) durch Kunden unter der Voraussetzung, dass bestimmte Sicherheitsregeln eingehalten werden.

Berichterstattung über Schwachstellen

Wenn du auf eine Schwachstelle stößt und diese an Atlassian melden möchtest, schaue dir bitte unsere Anweisungen zur Meldung von Schwachstellen an.

Einer der Unternehmenswerte von Atlassian lautet "Offene Unternehmenskultur – kein Bullsh**" und wir sind der Meinung, dass die Offenlegung von Schwachstellen zu diesem Wert dazugehört. Wir versuchen, Sicherheitsschwachstellen innerhalb der entsprechenden Service Level Objectives (SLOs) zu beheben. Wir akzeptieren Offenlegungsanträge, die im Rahmen unserer Bug-Bounty-Programme gestellt wurden, nachdem ein Problem behoben und in der Produktionsumgebung veröffentlicht wurde. Wenn eine Meldung jedoch Kundendaten enthält, wird der Antrag abgelehnt. Wenn du eine Offenlegung außerhalb eines unserer Bug-Bounty-Programme planst, bitten wir dich, dies rechtzeitig anzukündigen und zu warten, bis das jeweilige SLO abgeschlossen wurde.

Nicht von unserem Programm für Sicherheitstests abgedeckte Aspekte

Ebenso wie wir offen und klar mitteilen, welche Tests wir durchführen, benennen wir auch Tests, die wir nicht selbst durchführen oder derzeit nicht unterstützen. Folgende Aspekte sind von unserem Programm für Sicherheitstests ausgenommen:

Bestimmte Schwachstellenarten mit geringem Risiko: Unsere Produkte sollen Teams helfen, ihr volles Potenzial zu entfalten. Zusammenarbeit ist dabei unverzichtbar. Schwachstellen im Zusammenhang mit der Erhebung und Erfassung von Informationen werden in der Regel nicht als erhebliche Risiken erachtet.

Die richtige Einstufung

Wir haben eine Richtlinie zur Behebung von Sicherheits-Bugs, die abhängig vom Schweregrad und Produkt den SLO-Zeitrahmen (Service Level Objective) zur Behebung von Schwachstellen festlegt. Zur Bewertung von Schwachstellen nutzen wir das Common Vulnerability Scoring System, das uns hilft, Kunden über den Schweregrad von Schwachstellen zu informieren.

Es ist außerdem unser Ziel, die Kosten für das Aufspüren und Ausnutzen von Schwachstellen in unseren Produkten zu steigern. Wir verwenden unsere Bug-Bounty-Programme, um diese Kosten zu quantifizieren. Da wir die Sicherheit stetig verbessern, sollte sich die Zahl der im Rahmen der Bug-Bounty-Programme gefundenen Bugs mit der Zeit verringern. Wir müssten dann den auf die Ermittlung von Bugs ausgesetzten Betrag erhöhen, um weiterhin qualitativ hochwertige Meldungen zu erhalten. Wenn auf das Aufspüren einer Schwachstelle beispielsweise 3.000 US-Dollar ausgesetzt sind, sich der Aufwand aber nicht mehr lohnt (weil er mehr als diesen Betrag verschlingen würde), haben wir die Kosten für das Ermitteln der Schwachstelle effektiv erhöht.

Das heißt, du kannst davon ausgehen, dass sich unsere Prämien für gefundene Bugs mit der Zeit erhöhen.

Zusammenfassung

Atlassian unterhält mit seinem Bug-Bounty-Programm ein ausgereiftes, offenes und transparentes Programm für externe Sicherheitstests.

Download der aktuellen Bug-Bounty-Berichte

Alle Sicherheitslücken, die in den unten aufgeführten Berichten identifiziert wurden, werden von uns intern über Jira verfolgt, so wie sie über das Bug-Bounty-Programm hereinkommen. Die im Bug-Bounty-Programm gefundenen Probleme werden selektiert und gemäß unserem Service Level Objective (SLO) für öffentliche Sicherheitsschwachstellen behoben.