Schließen

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. Externe Sicherheitsforscher, die uns dabei unterstützen, leisten wertvolle Arbeit für unser Sicherheitsteam und sollten angemessen dafür entlohnt werden. 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 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.

Die Berichte zu diesen Tests veröffentlichen wir weder ganz noch auszugsweise, weil wir den Testern für ihre Beurteilungen umfassende Informationen zur Verfügung stellen.

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.

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 Bemühungen um 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.

Berichterstattung über Schwachstellen

Wenn ein Benutzer im Rahmen der normalen Verwendung eines unserer Produkte (d. h. nicht bei einem zielgerichteten Versuch, das System zu testen – Tests dieser Art dürfen nur im Rahmen unseres Bug-Bounty-Programms erfolgen) eine Schwachstelle erkennt, begrüßen wir eine Benachrichtigung über unser Atlassian-Supportteam. Wir reagieren zeitnah auf alle gemeldeten Schwachstellen und halten die Anfragesteller auf dem Laufenden, während wir das Problem untersuchen und behandeln.

Wir bitten die Sicherheitsforscher, vor dem Offenlegen eines Problems unsere Genehmigung einzuholen. Atlassian geht bei der Verarbeitung von Veröffentlichungsanfragen pro Bericht vor. Die Anfragen werden erst nach Behebung der gemeldeten Schwachstelle berücksichtigt.

 

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:

Marketplace-Apps: Marketplace-Apps sind von unserem Bug-Bounty-Programm ausdrücklich ausgenommen. Wir führen für diese Apps keinerlei Code-Überprüfungen oder Sicherheitstests durch. Wir geben Informationen über die uns gemeldeten Schwachstellen in Apps zwar weiter, sie sind jedoch nicht für ein "Kopfgeld" qualifiziert.

Von Kunden veranlasste Tests: Im Einklang mit unserer Kundenvereinbarung gestatten wir derzeit keine von Kunden veranlassten Tests unserer Produktionsumgebungen. Da wir uns zu Offenheit verpflichtet haben, veröffentlichen wir Statistiken aus unserem Bug-Bounty-Programm, um Kunden zu versichern, dass wir über ein aktives Programm für Sicherheitstests verfügen. Selbstverständlich dürfen sich unsere Kunden und deren Sicherheitsberater gerne für unser Bug-Bounty-Programm registrieren und im Rahmen dieses Prozesses Tests durchführen.

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 für die Behebung von Bugs, die als internes Service Level Agreement (SLA) zwischen unseren Produktteams und unserem Sicherheitsteam fungiert. Zur Kategorisierung von Bugs nutzen wir das Common Vulnerability Scoring System (CVSS Version 3), das uns hilft, Kunden über den Schweregrad von Schwachstellen zu informieren. Wir bemühen uns, folgende Zeitrahmen zur Behebung von Sicherheitsproblemen einzuhalten:

  • Bugs mit dem Schweregrad Kritisch (CVSS v2-Bewertung >= 8, CVSS v3-Bewertung >= 9) sollten im Produkt spätestens 4 Wochen nach der Meldung behoben sein.
  • Bugs mit dem Schweregrad Hoch (CVSS v2-Bewertung >= 6, CVSS v3-Bewertung >= 7) sollten im Produkt spätestens 6 Wochen nach der Meldung behoben sein.
  • Bugs mit dem Schweregrad Mittel (CVSS v2-Bewertung >= 3, CVSS v3-Bewertung >= 4) sollten im Produkt spätestens 8 Wochen nach der Meldung behoben sein.

Diese Zeitrahmen werden jährlich überprüft und bei Bedarf an die sich verändernde Bedrohungslandschaft angepasst.

Darüber hinaus ist anzumerken, dass wir das Ziel verfolgen, die Kosten des Aufspürens und Ausnutzens von Schwachstellen in unseren Produkten zu steigern. Daher ist eine Möglichkeit zur Quantifizierung dieser Kosten erforderlich. Als Näherungswert verwenden wir das den Sicherheitsforschern angebotene "Kopfgeld" (Bounty). Einfach ausgedrückt sollte sich die Anzahl der im Rahmen des Bug-Bounty-Programms gefundenen Bugs mit der Zeit verringern und wir müssen dementsprechend den auf die Ermittlung von Bugs ausgesetzten Betrag erhöhen, wenn wir weiterhin Meldungen erhalten möchten. Wenn auf das Aufspüren einer Schwachstelle 3.000 US-Dollar ausgesetzt sind, sich der Aufwand aber dennoch nicht mehr lohnt (weil er mehr als diesen Betrag verschlingen würde), werden wir die Kosten für das Ermitteln der Schwachstelle erhöhen.  

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. 

 

Möchtest du noch mehr wissen?

Wir haben in diesem kurzen White Paper auf einige andere Dokumente und Ressourcen verwiesen, mit denen du dich näher befassen solltest, wenn du mehr über unseren Ansatz für Sicherheitstests erfahren möchtest. 

 

Download der aktuellen Testberichte

Alle Sicherheitslücken in den unten aufgeführten Berichten werden von uns intern über Jira verfolgt, so wie sie über das Bug-Bounty-Programm hereinkommen, und gemäß dem in unserer Richtlinie für die Behebung von Sicherheits-Bugs angegebenen SLA-Zeitplan wieder geschlossen.