ACSC-Reifegradmodell "Essential Eight" – Leitlinien für 2023

• Die Ausführung von ausführbaren Dateien, Softwarebibliotheken, Skripten, Installationsprogrammen, kompiliertem HTML, HTML-Anwendungen und Systemsteuerungs-Applets auf Workstations wird über Standardbenutzerprofile und temporäre Ordner verhindert, die vom Betriebssystem, von Webbrowsern und E-Mail-Clients verwendet werden.

• Auf Workstations und mit dem Internet verbundenen Servern ist eine Form der Anwendungskontrolle implementiert.
• Die Anwendungskontrolle beschränkt die Ausführung von ausführbaren Dateien, Softwarebibliotheken, Skripten, Installationsprogrammen, kompiliertem HTML, HTML-Anwendungen und Systemsteuerungs-Applets auf von der Organisation genehmigte Software.
• Zugelassene und blockierte Ausführungen auf Workstations und mit dem Internet verbundenen Servern werden protokolliert.

• Auf Workstations und Servern ist eine Form der Anwendungskontrolle implementiert.
• Die Anwendungskontrolle beschränkt die Ausführung von ausführbaren Dateien, Softwarebibliotheken, Skripten, Installationsprogrammen, kompiliertem HTML, HTML-Anwendungen, Systemsteuerungs-Applets und Treibern auf von der Organisation genehmigte Software.
• Die "empfohlenen Blockierungsregeln" von Microsoft sind implementiert. Die "empfohlenen Treiberblockierungsregeln" von Microsoft sind implementiert.
• Regelsätze für die Anwendungskontrolle werden jährlich oder häufiger validiert.
• Zugelassene und blockierte Ausführungen auf Workstations und Servern werden zentral protokolliert.
• Ereignisprotokolle sind vor unbefugter Änderung und Löschung geschützt. Ereignisprotokolle werden auf Anzeichen von Kompromittierung überwacht und bei Erkennung solcher Anzeichen werden entsprechende Maßnahmen eingeleitet.

Die Verwendung von Dienstprogrammen in der Produktionsumgebung ist eingeschränkt und kontrolliert. Alle Server werden mithilfe unseres zentralen Puppet-Konfigurationssystems für unsere Standardbetriebsumgebung konfiguriert. Das beinhaltet die Entfernung ausgewählter Pakete aus dem Standard-Image sowie wichtige Paket-Updates. Alle Serverrollen lehnen alle eingehenden Netzwerkanfragen standardmäßig ab. Ausgewählte Ports sind nur für solche Serverrollen geöffnet, die aus Funktionsgründen auf den Port zugreifen müssen. Das Unternehmensnetzwerk von Atlassian ist von unserem Produktionsnetzwerk getrennt, und unsere Machine Images sind so gesichert, dass nur die erforderlichen Ports und Protokolle zugelassen werden. Alle Produktionssysteme werden derzeit in den US-Regionen unseres Cloud-Anbieters gehostet. Alle Daten, die außerhalb von gesicherten VPC-Netzwerken (Virtual Private Cloud) übertragen werden, sind über branchenübliche Kanäle verschlüsselt.
Auf allen Produktionsservern ist zudem ein IDS-System mit Funktionen für Echtzeit-Überwachung vorhanden, das bei Änderungen an den Dateien oder der Konfiguration des Produktionssystems sowie bei anomalen Sicherheitsereignissen Warnungen ausgibt.

• Mindestens alle vierzehn Tage wird eine automatisierte Methode der Asset-Erkennung verwendet, um die Erkennung von Assets für anschließende Sicherheitsrisiko-Scans zu unterstützen.
• Für Sicherheitsrisiko-Scans wird ein Scanner mit einer aktuellen Sicherheitsrisikodatenbank verwendet. Der Scanner wird mindestens täglich verwendet, um fehlende Patches oder Updates zur Beseitigung von Sicherheitsrisiken in Internetservices zu identifizieren.
• Ein Sicherheitsrisiko-Scanner wird mindestens alle vierzehn Tage verwendet, um fehlende Patches oder Updates zur Beseitigung von Sicherheitsrisiken in Produktivitätssoftware, Webbrowsern und Erweiterungen, E-Mail-Clients, PDF-Software und Sicherheitsprodukten zu identifizieren.
• Patches, Updates oder andere anbieterbasierte Maßnahmen gegen Sicherheitsrisiken in Internetservices werden innerhalb von zwei Wochen nach der Veröffentlichung oder innerhalb von 48 Stunden angewendet, falls eine Schwachstelle vorliegt.
• Patches, Updates oder andere anbieterbasierte Maßnahmen gegen Sicherheitsrisiken in Produktivitätssoftware, Webbrowsern und Erweiterungen, E-Mail-Clients, PDF-Software und Sicherheitsprodukten werden innerhalb eines Monats nach der Veröffentlichung angewendet.
• Internetservices, Produktivitätssoftware, Webbrowser und Erweiterungen, E-Mail-Clients, PDF-Software, Adobe Flash Player und Sicherheitsprodukte, die von Anbietern nicht mehr unterstützt werden, werden entfernt.

• Mindestens alle vierzehn Tage wird eine automatisierte Methode der Asset-Erkennung verwendet, um die Erkennung von Assets für anschließende Sicherheitsrisiko-Scans zu unterstützen.
• Für Sicherheitsrisiko-Scans wird ein Scanner mit einer aktuellen Sicherheitsrisikodatenbank verwendet.
• Der Scanner wird mindestens täglich verwendet, um fehlende Patches oder Updates zur Beseitigung von Sicherheitsrisiken in Internetservices zu identifizieren.
• Ein Sicherheitsrisiko-Scanner wird mindestens einmal pro Woche verwendet, um fehlende Patches oder Updates zur Beseitigung von Sicherheitsrisiken in Produktivitätssoftware, Webbrowsern und Erweiterungen, E-Mail-Clients, PDF-Software und Sicherheitsprodukten zu identifizieren.
• Ein Sicherheitsrisiko-Scanner wird mindestens alle vierzehn Tage verwendet, um fehlende Patches oder Updates zur Beseitigung von Sicherheitsrisiken in anderen Anwendungen zu identifizieren.
• Patches, Updates oder andere anbieterbasierte Maßnahmen gegen Sicherheitsrisiken in Internetservices werden innerhalb von zwei Wochen nach der Veröffentlichung oder innerhalb von 48 Stunden angewendet, falls eine Schwachstelle vorliegt.
• Patches, Updates oder andere anbieterbasierte Maßnahmen gegen Sicherheitsrisiken in Produktivitätssoftware, Webbrowsern und Erweiterungen, E-Mail-Clients, PDF-Software und Sicherheitsprodukten werden innerhalb von zwei Wochen nach der Veröffentlichung angewendet.
• Patches, Updates oder andere Schutzmaßnahmen von Anbietern gegen Schwachstellen in anderen Anwendungen werden innerhalb eines Monats nach der Veröffentlichung angewendet.
• Internetservices, Produktivitätssoftware, Webbrowser und Erweiterungen, E-Mail-Clients, PDF-Software, Adobe Flash Player und Sicherheitsprodukte, die von Anbietern nicht mehr unterstützt werden, werden entfernt.

• Mindestens alle vierzehn Tage wird eine automatisierte Methode der Asset-Erkennung verwendet, um die Erkennung von Assets für anschließende Sicherheitsrisiko-Scans zu unterstützen.
• Für Sicherheitsrisiko-Scans wird ein Scanner mit einer aktuellen Sicherheitsrisikodatenbank verwendet.
• Der Scanner wird mindestens täglich verwendet, um fehlende Patches oder Updates zur Beseitigung von Sicherheitsrisiken in Internetservices zu identifizieren.
• Ein Sicherheitsrisiko-Scanner wird mindestens einmal pro Woche verwendet, um fehlende Patches oder Updates zur Beseitigung von Sicherheitsrisiken in Produktivitätssoftware, Webbrowsern und Erweiterungen, E-Mail-Clients, PDF-Software und Sicherheitsprodukten zu identifizieren.
• Ein Sicherheitsrisiko-Scanner wird mindestens alle vierzehn Tage verwendet, um fehlende Patches oder Updates zur Beseitigung von Sicherheitsrisiken in anderen Anwendungen zu identifizieren.
• Patches, Updates oder andere anbieterbasierte Maßnahmen gegen Sicherheitsrisiken in Internetservices werden innerhalb von zwei Wochen nach der Veröffentlichung oder innerhalb von 48 Stunden angewendet, falls eine Schwachstelle vorliegt.
• Patches, Updates oder andere anbieterbasierte Maßnahmen gegen Sicherheitsrisiken in Produktivitätssoftware, Webbrowsern und Erweiterungen, E-Mail-Clients, PDF-Software und Sicherheitsprodukten werden innerhalb von zwei Wochen nach der Veröffentlichung oder innerhalb von 48 Stunden angewendet, falls eine Schwachstelle vorliegt.
• Patches, Updates oder andere Schutzmaßnahmen von Anbietern gegen Schwachstellen in anderen Anwendungen werden innerhalb eines Monats nach der Veröffentlichung angewendet.
• Anwendungen, die von Anbietern nicht mehr unterstützt werden, werden entfernt.

Für alle unsere Produkte und Serviceangebote gibt es einen umfangreichen Prozess zur Fehlerbehebung. Hierfür verwenden wir unser eigenes Produkt Jira, mit dem wir Probleme aufspüren und Anfragen bearbeiten. Diese Prozesse werden durch zahlreiche Richtlinien, Beratungsservices und SLOs zur Behebung von Sicherheitslücken untermauert, an die wir uns halten. Wir nehmen Fehlerberichte über unseren Support Channel, unser Bug-Bounty-Programm und security@atlassian.com entgegen. Weitere Informationen zu unseren SLOs für die Behebung von Sicherheits-Bugs sind in unserem Trust Center verfügbar.

Weitere Informationen zum Thema findest du auch in unserem Trust Center unter: Unser Ansatz für externe Sicherheitstests

Unser Atlassian-Sicherheitsteam nutzt mehrere Methoden, um Sicherheitsrisiken sowohl in der internen als auch in der externen Infrastruktur zu erkennen. Jira-Tickets werden zu Nachverfolgung und Fehlerbehebung erstellt. Die Fälligkeitsdaten werden gemäß unserem SLO vergeben, basierend sowohl auf dem Schweregrad als auch auf der Quelle der Schwachstelle. Ein fortlaufender Prozess erstellt Tickets für identifizierte Schwachstellen für Systembesitzer. Unser Sicherheitsmanagementteam überprüft alle gemeldeten Schwachstellen und stellt sicher, dass geeignete Maßnahmen zur Behebung ergriffen werden.

• Microsoft Office-Makros sind für alle Benutzer deaktiviert, bei denen keine nachweisliche Betriebserfordernis vorliegt.
• In Dateien, die aus dem Internet stammen, sind Microsoft Office-Makros blockiert.
• Der Antiviren-Scan für Microsoft Office-Makros ist aktiviert.
• Die Sicherheitseinstellungen für Microsoft Office-Makros können von Benutzern nicht geändert werden.

• Microsoft Office-Makros sind für alle Benutzer deaktiviert, bei denen keine nachweisliche Betriebserfordernis vorliegt.
• In Dateien, die aus dem Internet stammen, sind Microsoft Office-Makros blockiert. Der Antiviren-Scan für Microsoft Office-Makros ist aktiviert.
• Win32-API-Aufrufe über Microsoft Office-Makros sind blockiert.
• Die Sicherheitseinstellungen für Microsoft Office-Makros können von Benutzern nicht geändert werden.
• Zugelassene und blockierte Ausführungen von Microsoft Office-Makros werden protokolliert.

• Microsoft Office-Makros sind für alle Benutzer deaktiviert, bei denen keine nachweisliche Betriebserfordernis vorliegt.
• Microsoft Office-Makros dürfen nur ausgeführt werden, wenn sie in einer Sandbox-Umgebung oder an einem vertrauenswürdigen Speicherort ausgeführt werden oder von einem vertrauenswürdigen Herausgeber digital signiert wurden.
• Inhalte an vertrauenswürdigen Speicherorten dürfen nur von Benutzern erstellt oder bearbeitet werden, die dafür verantwortlich sind, zu überprüfen, dass Microsoft Office-Makros frei von bösartigem Code sind, und über entsprechende Berechtigungen verfügen.
• Microsoft Office-Makros, die von einem nicht vertrauenswürdigen Herausgeber digital signiert wurden, können nicht über die Nachrichtenleiste oder die Backstage-Ansicht aktiviert werden.
• Die Liste der vertrauenswürdigen Herausgeber von Microsoft Office wird jährlich oder häufiger überprüft.
• In Dateien, die aus dem Internet stammen, sind Microsoft Office-Makros blockiert.
• Der Antiviren-Scan für Microsoft Office-Makros ist aktiviert.
• Win32-API-Aufrufe über Microsoft Office-Makros sind blockiert.
• Die Sicherheitseinstellungen für Microsoft Office-Makros können von Benutzern nicht geändert werden.
• Zugelassene und blockierte Ausführungen von Microsoft Office-Makros werden an einem zentralen Ort protokolliert.
• Ereignisprotokolle sind vor unbefugter Änderung und Löschung geschützt.
• Ereignisprotokolle werden auf Anzeichen von Kompromittierung überwacht und bei Erkennung solcher Anzeichen werden entsprechende Maßnahmen eingeleitet.

Atlassian arbeitet mit externen Subunternehmern zusammen, um Website-, Anwendungsentwicklungs-, Hosting-, Wartungs-, Sicherungs-, Speicher-, virtuelle Infrastruktur-, Zahlungsabwicklungs-, Analyse- und andere Services bereitzustellen. Diese Serviceanbieter haben eventuell Zugriff auf personenbezogene Daten oder verarbeiten diese, damit sie diese Services für uns bereitstellen können. Atlassian benachrichtigt die betroffenen Kunden über die Nutzung von Subunternehmern, die ihre personenbezogenen Daten bearbeiten könnten, bevor es zur Verarbeitung kommt. Eine Liste der externen Subunternehmer, mit denen Atlassian zusammenarbeitet, findest du auf der Seite Unterauftragsverarbeiter von Atlassian. Auf dieser Seite können Besucher einen RSS-Feed abonnieren, um sich benachrichtigen zu lassen, wenn wir neue Unterauftragsverarbeiter hinzufügen.

Wir haben eine zentralisierte Systemverwaltungslösung (Mobile Device Management) für unsere Mac-Laptop-Flotte implementiert.
Wir haben eine Lösung zur Verwaltung mobiler Geräte für unsere Windows-Endgeräte und Smartphones implementiert (VMware Workplace ONE).

• Webbrowser verarbeiten Java aus dem Internet nicht.
• Webbrowser verarbeiten keine Webanzeigen aus dem Internet.
• Internet Explorer 11 verarbeitet keine Inhalte aus dem Internet.
• Die Sicherheitseinstellungen des Webbrowsers können von Benutzern nicht geändert werden.

• Webbrowser verarbeiten Java aus dem Internet nicht.
• Webbrowser verarbeiten keine Webanzeigen aus dem Internet.
• Internet Explorer 11 verarbeitet keine Inhalte aus dem Internet.
• Die ACSC- oder Anbieterhärtungsanleitungen für Webbrowser sind implementiert.
• Die Sicherheitseinstellungen des Webbrowsers können von Benutzern nicht geändert werden.
• Microsoft Office wird daran gehindert, untergeordnete Prozesse zu erstellen.
• Microsoft Office wird daran gehindert, ausführbare Inhalte zu erstellen.
• Microsoft Office wird daran gehindert, Code in andere Prozesse einzufügen.
• Microsoft Office ist so konfiguriert, dass die Aktivierung von OLE-Paketen verhindert wird.
• Die ACSC- oder Anbieterhärtungsanleitungen für Microsoft Office sind implementiert.
• Die Sicherheitseinstellungen von Microsoft Office können von Benutzern nicht geändert werden.
• PDF-Software wird daran gehindert, untergeordnete Prozesse zu erstellen.
• Die ACSC- oder Anbieterhärtungsanleitungen für PDF-Software sind implementiert.
• Die Sicherheitseinstellungen von PDF-Software können von Benutzern nicht geändert werden.
• Ereignisse der blockierten PowerShell-Skriptausführung werden protokolliert.

• Webbrowser verarbeiten Java aus dem Internet nicht.
• Webbrowser verarbeiten keine Webanzeigen aus dem Internet.
• Internet Explorer 11 ist deaktiviert oder wurde entfernt.
• Die ACSC- oder Anbieterhärtungsanleitungen für Webbrowser sind implementiert.
• Die Sicherheitseinstellungen des Webbrowsers können von Benutzern nicht geändert werden.
• Microsoft Office wird daran gehindert, untergeordnete Prozesse zu erstellen.
• Microsoft Office wird daran gehindert, ausführbare Inhalte zu erstellen.
• Microsoft Office wird daran gehindert, Code in andere Prozesse einzufügen.
• Microsoft Office ist so konfiguriert, dass die Aktivierung von OLE-Paketen verhindert wird.
• Die ACSC- oder Anbieterhärtungsanleitungen für Microsoft Office sind implementiert.
• Die Sicherheitseinstellungen von Microsoft Office können von Benutzern nicht geändert werden.
• PDF-Software wird daran gehindert, untergeordnete Prozesse zu erstellen.
• Die ACSC- oder Anbieterhärtungsanleitungen für PDF-Software sind implementiert.
• Die Sicherheitseinstellungen von PDF-Software können von Benutzern nicht geändert werden.
• .NET Framework 3.5 (beinhaltet .NET 2.0 und 3.0) ist deaktiviert oder wurde entfernt.
• Windows PowerShell 2.0 ist deaktiviert oder wurde entfernt.
• PowerShell ist für die Verwendung des Constrained Language Mode konfiguriert.
• Ereignisse der blockierten PowerShell-Skriptausführung werden zentral protokolliert.
• Ereignisprotokolle sind vor unbefugter Änderung und Löschung geschützt.
• Ereignisprotokolle werden auf Anzeichen von Kompromittierung überwacht und bei Erkennung solcher Anzeichen werden entsprechende Maßnahmen eingeleitet.

Die Image-Builds des Basisbetriebssystems von AWS Linux AMI verfügen über begrenzte Ports, Protokolle und Services. Wir vergleichen unsere Builds mit der aktuellen AMI-Version, um die richtigen Einstellungen festzulegen.
Unsere Docker-Images werden in einer streng kontrollierten Änderungsumgebung verwaltet, um eine angemessene Überprüfung und Genehmigung aller Änderungen sicherzustellen.

Unsere Endgeräte sind gehärtet, um unsere Benutzer zu schützen, wir schränken aber den Zugriff auf Hardware-Ports nicht ein.

Wir verwenden ein HTTP-Proxyprodukt eines Drittanbieters für unseren Jira/Confluence Public Edge und wir haben L7-HTTP-Sicherheitsregeln darauf implementiert (man könnte sie als WAF bezeichnen, denn die Funktionsweise ist im Grunde dieselbe.)

• Anfragen für privilegierten Zugriff auf Systeme und Anwendungen werden validiert, wenn sie zum ersten Mal eingehen.
• Privilegierte Konten (ausgenommen privilegierte Servicekonten) werden daran gehindert, auf das Internet, E-Mail und Webservices zuzugreifen.
• Privilegierte Benutzer verwenden separate privilegierte und unprivilegierte Betriebsumgebungen.
• Unprivilegierte Konten können sich nicht in privilegierten Betriebsumgebungen anmelden.
• Privilegierte Konten (mit Ausnahme lokaler Administratorkonten) können sich nicht in unprivilegierten Betriebsumgebungen anmelden.

• Anfragen für privilegierten Zugriff auf Systeme und Anwendungen werden validiert, wenn sie zum ersten Mal eingehen.
• Der privilegierte Zugriff auf Systeme und Anwendungen wird nach 12 Monaten automatisch deaktiviert, sofern er nicht erneut bestätigt wird.
• Der privilegierte Zugriff auf Systeme und Anwendungen wird nach 45 Tagen Inaktivität automatisch deaktiviert.
• Privilegierte Konten (ausgenommen privilegierte Servicekonten) werden daran gehindert, auf das Internet, E-Mail und Webservices zuzugreifen.
• Privilegierte Benutzer verwenden separate privilegierte und unprivilegierte Betriebsumgebungen.
• Privilegierte Betriebsumgebungen werden nicht in unprivilegierten Betriebsumgebungen virtualisiert.
• Unprivilegierte Konten können sich nicht in privilegierten Betriebsumgebungen anmelden.
• Privilegierte Konten (mit Ausnahme lokaler Administratorkonten) können sich nicht in unprivilegierten Betriebsumgebungen anmelden.
• Verwaltungsaktivitäten werden über Jump-Server abgewickelt.
• Anmeldedaten für lokale Administrator- und Servicekonten sind lang, einzigartig, unvorhersehbar und verwaltet.
• Ereignisse mit privilegiertem Zugriff werden protokolliert.
• Ereignisse in der Verwaltung von privilegierten Konten und Gruppen werden protokolliert.

• Anfragen für privilegierten Zugriff auf Systeme und Anwendungen werden validiert, wenn sie zum ersten Mal eingehen.
• Der privilegierte Zugriff auf Systeme und Anwendungen wird nach 12 Monaten automatisch deaktiviert, sofern er nicht erneut bestätigt wird.
• Der privilegierte Zugriff auf Systeme und Anwendungen wird nach 45 Tagen Inaktivität automatisch deaktiviert.
• Der privilegierte Zugriff auf Systeme und Anwendungen ist beschränkt auf das, was Benutzer und Services zur Erfüllung ihrer Aufgaben benötigen.
• Privilegierte Konten werden daran gehindert, auf das Internet, E-Mail und Webservices zuzugreifen.
• Privilegierte Benutzer verwenden separate privilegierte und unprivilegierte Betriebsumgebungen.
• Privilegierte Betriebsumgebungen werden nicht in unprivilegierten Betriebsumgebungen virtualisiert.
• Unprivilegierte Konten können sich nicht in privilegierten Betriebsumgebungen anmelden.
• Privilegierte Konten (mit Ausnahme lokaler Administratorkonten) können sich nicht in unprivilegierten Betriebsumgebungen anmelden.
• Die Just-in-Time-Administration wird für die Verwaltung von Systemen und Anwendungen verwendet.
• Verwaltungsaktivitäten werden über Jump-Server abgewickelt.
• Anmeldedaten für lokale Administrator- und Servicekonten sind lang, einzigartig, unvorhersehbar und verwaltet.
• Windows Defender Credential Guard und Windows Defender Remote Credential Guard sind aktiviert.
• Ereignisse mit privilegiertem Zugriff werden zentral protokolliert.
• Ereignisse in der Verwaltung von privilegierten Konten und Gruppen werden zentral protokolliert.
• Ereignisprotokolle sind vor unbefugter Änderung und Löschung geschützt.
• Ereignisprotokolle werden auf Anzeichen von Kompromittierung überwacht und bei Erkennung solcher Anzeichen werden entsprechende Maßnahmen eingeleitet.

Atlassian beschränkt weiterhin die Mitarbeiter, die diesen Zugriff für ihre berufliche Rolle und ihre Aufgaben benötigen. Alle Tier-1-Systeme werden über eine zentrale Single-Sign-On (SSO)- und Verzeichnislösung von Atlassian verwaltet. Benutzer erhalten auf der Grundlage dieser Profile angemessene Zugriffsrechte, die über einen Workflow aus unserem Personalverwaltungssystem gesteuert werden. Atlassian nutzt MFA für den Zugriff auf alle Tier-1-Systeme. Wir haben die Zwei-Faktor-Authentifizierung für die Hypervisor-Managementkonsole und die AWS-API sowie einen täglichen Auditbericht über den gesamten Zugriff auf die Hypervisor-Verwaltungsfunktionen aktiviert. Die Zugriffslisten für die Hypervisor-Managementkonsole und die AWS-API werden vierteljährlich überprüft. Wir führen außerdem eine 8-stündige Synchronisation zwischen unserem HR-System und unserem Identitätsspeicher durch.

Wir führen zweimal pro Jahr Review-Zyklen für kritische Services in unserem Review-Prozess für Berechtigungen durch. Die Validierung des Benutzerzugriffs wird regelmäßig mit Systembesitzern für interne unternehmenseigene Benutzerkonten vorgenommen.

• Mindestens alle vierzehn Tage wird eine automatisierte Methode der Asset-Erkennung verwendet, um die Erkennung von Assets für anschließende Sicherheitsrisiko-Scans zu unterstützen.
• Für Sicherheitsrisiko-Scans wird ein Scanner mit einer aktuellen Sicherheitsrisikodatenbank verwendet.
• Ein Scanner für Sicherheitsrisiken wird mindestens täglich verwendet, um fehlende Patches oder Updates zur Vermeidung von Sicherheitsrisiken in Betriebssystemen internetfähiger Services zu identifizieren.
• Ein Scanner für Sicherheitsrisiken wird mindestens alle zwei Wochen verwendet, um fehlende Patches oder Updates zur Vermeidung von Sicherheitsrisiken in Betriebssystemen von Workstations, Servern und Netzwerkgeräten zu identifizieren.
• Patches, Updates oder andere anbieterbasierte Schutzmaßnahmen gegen Sicherheitsrisiken in Betriebssystemen internetfähiger Services werden innerhalb von zwei Wochen nach der Veröffentlichung oder innerhalb von 48 Stunden angewendet, falls ein Exploit vorliegt.
• Patches, Updates oder andere anbieterbasierte Schutzmaßnahmen gegen Sicherheitsrisiken in Betriebssystemen von Workstations, Servern und Netzwerkgeräten werden innerhalb eines Monats nach der Veröffentlichung angewendet.
• Betriebssysteme, die von Anbietern nicht mehr unterstützt werden, werden ersetzt.

• Mindestens alle vierzehn Tage wird eine automatisierte Methode der Asset-Erkennung verwendet, um die Erkennung von Assets für anschließende Sicherheitsrisiko-Scans zu unterstützen.
• Für Sicherheitsrisiko-Scans wird ein Scanner mit einer aktuellen Sicherheitsrisikodatenbank verwendet.
• Ein Scanner für Sicherheitsrisiken wird mindestens täglich verwendet, um fehlende Patches oder Updates zur Vermeidung von Sicherheitsrisiken in Betriebssystemen internetfähiger Services zu identifizieren.
• Ein Scanner für Sicherheitsrisiken wird mindestens wöchentlich verwendet, um fehlende Patches oder Updates zur Vermeidung von Sicherheitsrisiken in Betriebssystemen von Workstations, Servern und Netzwerkgeräten zu identifizieren.
• Patches, Updates oder andere anbieterbasierte Schutzmaßnahmen gegen Sicherheitsrisiken in Betriebssystemen internetfähiger Services werden innerhalb von zwei Wochen nach der Veröffentlichung oder innerhalb von 48 Stunden angewendet, falls ein Exploit vorliegt.
• Patches, Updates oder andere anbieterbasierte Schutzmaßnahmen gegen Sicherheitsrisiken in Betriebssystemen von Workstations, Servern und Netzwerkgeräten werden innerhalb von zwei Wochen nach der Veröffentlichung angewendet.
• Betriebssysteme, die von Anbietern nicht mehr unterstützt werden, werden ersetzt.

• Mindestens alle vierzehn Tage wird eine automatisierte Methode der Asset-Erkennung verwendet, um die Erkennung von Assets für anschließende Sicherheitsrisiko-Scans zu unterstützen.
• Für Sicherheitsrisiko-Scans wird ein Scanner mit einer aktuellen Sicherheitsrisikodatenbank verwendet.
• Ein Scanner für Sicherheitsrisiken wird mindestens täglich verwendet, um fehlende Patches oder Updates zur Vermeidung von Sicherheitsrisiken in Betriebssystemen internetfähiger Services zu identifizieren.
• Ein Scanner für Sicherheitsrisiken wird mindestens wöchentlich verwendet, um fehlende Patches oder Updates zur Vermeidung von Sicherheitsrisiken in Betriebssystemen von Workstations, Servern und Netzwerkgeräten zu identifizieren.
• Patches, Updates oder andere anbieterbasierte Schutzmaßnahmen gegen Sicherheitsrisiken in Betriebssystemen internetfähiger Services werden innerhalb von zwei Wochen nach der Veröffentlichung oder innerhalb von 48 Stunden angewendet, falls ein Exploit vorliegt.
• Patches, Updates oder andere anbieterbasierte Schutzmaßnahmen gegen Sicherheitsrisiken in Betriebssystemen von Workstations, Servern und Netzwerkgeräten werden innerhalb von zwei Wochen nach der Veröffentlichung oder innerhalb von 48 Stunden angewendet, wenn ein Exploit vorliegt.
• Das neueste Release oder das vorherige Release des Betriebssystems wird verwendet. Betriebssysteme, die von Anbietern nicht mehr unterstützt werden, werden ersetzt.

Für alle unsere Produkte und Serviceangebote gibt es einen umfangreichen Prozess zur Fehlerbehebung. (Hierfür verwenden wir unser eigenes Produkt Jira, mit dem wir Vorgänge erfassen und Anfragen bearbeiten.) Diese Prozesse werden durch zahlreiche Richtlinien, Beratungsservices und SLOs zur Behebung von Sicherheits-Bugs untermauert, an die wir uns halten. Wir nehmen Fehlerberichte über unseren Support-Kanal, unser Bug-Bounty-Programm und über security@atlassian.com entgegen. Weitere Informationen zu unseren SLOs für die Behebung von Sicherheits-Bugs sind in unserem Trust Center verfügbar.

Weitere Informationen zum Thema findest du auch in unserem Trust Center unter: Unser Ansatz für externe Sicherheitstests

Unser Atlassian-Sicherheitsteam nutzt mehrere Methoden, um Sicherheitsrisiken sowohl in der internen als auch in der externen Infrastruktur zu erkennen. Jira-Tickets werden zur Nachverfolgung und Fehlerbehebung erstellt. Die Fälligkeitsdaten werden gemäß unserem SLO vergeben, basierend sowohl auf dem Schweregrad als auch auf der Quelle des Sicherheitsrisikos. Wir haben einen fortlaufenden Prozess, bei dem Tickets für identifizierte Sicherheitsrisiken für Systembesitzer erstellt werden. Unser Sicherheitsmanagementteam überprüft alle gemeldeten Sicherheitsrisiken und stellt sicher, dass geeignete Maßnahmen zur Behebung ergriffen werden.

• Die Multi-Faktor-Authentifizierung wird von den Unternehmensbenutzern verwendet, wenn sie sich bei den internetfähigen Services ihres Unternehmens authentifizieren.
• Die Multi-Faktor-Authentifizierung wird von den Unternehmensbenutzern verwendet, wenn sie sich bei internetfähigen Services von Drittanbietern authentifizieren, die die sensiblen Daten ihres Unternehmens verarbeiten, speichern oder weitergeben.
• Die Multi-Faktor-Authentifizierung (sofern verfügbar) wird von den Unternehmensbenutzern verwendet, wenn sie sich bei internetfähigen Services von Drittanbietern authentifizieren, die die nicht sensiblen Daten ihres Unternehmens verarbeiten, speichern oder weitergeben.
• Die Multi-Faktor-Authentifizierung wird für Unternehmensbenutzer außerhalb der Organisation standardmäßig aktiviert, wenn sie sich bei den internetfähigen Services ihres Unternehmens authentifizieren (sie können diese jedoch ablehnen).

• Die Multi-Faktor-Authentifizierung wird von den Unternehmensbenutzern verwendet, wenn sie sich bei den internetfähigen Services ihres Unternehmens authentifizieren.
• Die Multi-Faktor-Authentifizierung wird von den Unternehmensbenutzern verwendet, wenn sie sich bei internetfähigen Services von Drittanbietern authentifizieren, die die sensiblen Daten ihres Unternehmens verarbeiten, speichern oder weitergeben.
• Die Multi-Faktor-Authentifizierung (sofern verfügbar) wird von den Unternehmensbenutzern verwendet, wenn sie sich bei internetfähigen Services von Drittanbietern authentifizieren, die die nicht sensiblen Daten ihres Unternehmens verarbeiten, speichern oder weitergeben.
• Die Multi-Faktor-Authentifizierung wird für Unternehmensbenutzer außerhalb der Organisation standardmäßig aktiviert, wenn sie sich bei den internetfähigen Services ihres Unternehmens authentifizieren (sie können diese jedoch ablehnen).
• Die Multi-Faktor-Authentifizierung wird verwendet, um privilegierte Benutzer von Systemen zu authentifizieren.
• Die Multi-Faktor-Authentifizierung verwendet entweder: etwas, das Benutzer haben, und etwas, das Benutzer wissen, oder etwas, das Benutzer haben und das durch etwas freigeschaltet wird, das Benutzer wissen oder sind.
• Erfolgreiche und erfolglose Multi-Faktor-Authentifizierungsereignisse werden protokolliert.

• Die Multi-Faktor-Authentifizierung wird von den Unternehmensbenutzern verwendet, wenn sie sich bei den internetfähigen Services ihres Unternehmens authentifizieren.
• Die Multi-Faktor-Authentifizierung wird von den Unternehmensbenutzern verwendet, wenn sie sich bei internetfähigen Services von Drittanbietern authentifizieren, die die sensiblen Daten ihres Unternehmens verarbeiten, speichern oder weitergeben.
• Die Multi-Faktor-Authentifizierung (sofern verfügbar) wird von den Unternehmensbenutzern verwendet, wenn sie sich bei internetfähigen Services von Drittanbietern authentifizieren, die die nicht sensiblen Daten ihres Unternehmens verarbeiten, speichern oder weitergeben.
• Die Multi-Faktor-Authentifizierung wird für Unternehmensbenutzer außerhalb der Organisation standardmäßig aktiviert, wenn sie sich bei den internetfähigen Services ihres Unternehmens authentifizieren (sie können diese jedoch ablehnen).
• Die Multi-Faktor-Authentifizierung wird verwendet, um privilegierte Benutzer von Systemen zu authentifizieren.
• Die Multi-Faktor-Authentifizierung wird verwendet, um Benutzer wichtiger Daten-Repositorys zu authentifizieren.
• Die Multi-Faktor-Authentifizierung schützt vor Phishing-Angriffen und verwendet entweder: etwas, das Benutzer haben, und etwas, das Benutzer wissen, oder etwas, das Benutzer haben und das durch etwas freigeschaltet wird, das Benutzer wissen oder sind.
• Erfolgreiche und erfolglose Multi-Faktor-Authentifizierungsereignisse werden zentral protokolliert.
• Ereignisprotokolle sind vor unbefugter Änderung und Löschung geschützt.
• Ereignisprotokolle werden auf Anzeichen von Kompromittierung überwacht und bei Erkennung solcher Anzeichen werden entsprechende Maßnahmen eingeleitet.

Für Confluence und Jira ist die Multi-Faktor-Authentifizierung für einzelne Konten verfügbar. Weitere Informationen darüber, wie du die Multi-Faktor-Authentifizierung aktivierst, findest du unter: Verpflichtende Zwei-Faktor-Authentifizierung

BBC unterstützt 2FA weiterhin (Stand Februar 2022), ist im Allgemeinen in Atlassian Access integriert und unterstützt auch zusätzliche Funktionen, die über Access angeboten werden. Die verpflichtende Multi-Faktor-Authentifizierung kann auf Organisationsebene mit Atlassian Access eingerichtet werden. Weitere Informationen findest du unter: Verpflichtende Zwei-Faktor-Authentifizierung

In Bezug auf spezifische Produkte:

Bitbucket unterstützt MFA-basierte SSO-Optionen. Weitere Informationen findest du unter: Verpflichtende Zwei-Faktor-Authentifizierung | Bitbucket Cloud

Halp verwendet SSO über Slack OAuth und MS Teams. Slack und MS Teams bieten mehrere Optionen für die Multi-Faktor-Authentifizierung. Weitere Informationen findest du unter: SAML-Single-Sign-On & Azure AD Connect: Seamless Single-Sign-On

Opsgenie unterstützt die Verwendung von MFA-basierten SSO-Optionen. Weitere Informationen findest du unter: SSO für Opsgenie konfigurieren

Statuspage unterstützt die Verwendung von MFA-basierten SSO-Optionen.

Trello unterstützt die Multi-Faktor-Authentifizierung. Weitere Informationen darüber, wie du die Multi-Faktor-Authentifizierung aktivierst, findest du unter: Aktivierung der Zwei-Faktor-Authentifizierung für dein Trello-Konto.

Jira Align unterstützt die Verwendung von MFA-basierten SSO-Optionen.

• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden so häufig durchgeführt und so lange aufbewahrt, wie es Business-Continuity-Anforderungen verlangen.
• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden synchronisiert, um eine Wiederherstellung auf einen gemeinsamen Zeitpunkt zu ermöglichen.
• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden sicher und wiederherstellbar aufbewahrt.
• Die Wiederherstellung wichtiger Daten, Software und Konfigurationseinstellungen aus Backups auf einen gemeinsamen Zeitpunkt wird im Rahmen von Disaster-Recovery-Übungen getestet.
• Unprivilegierte Konten können nicht auf Backups zugreifen, die zu anderen Konten gehören.
• Unprivilegierte Konten werden daran gehindert, Backups zu ändern und zu löschen.

• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden so häufig durchgeführt und so lange aufbewahrt, wie es Business-Continuity-Anforderungen verlangen.
• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden synchronisiert, um eine Wiederherstellung auf einen gemeinsamen Zeitpunkt zu ermöglichen.
• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden sicher und wiederherstellbar aufbewahrt.
• Die Wiederherstellung wichtiger Daten, Software und Konfigurationseinstellungen aus Backups auf einen gemeinsamen Zeitpunkt wird im Rahmen von Disaster-Recovery-Übungen getestet.
• Unprivilegierte Konten können nicht auf Backups zugreifen, die zu anderen Konten gehören.
• Privilegierte Konten (mit Ausnahme von Backup-Administratorkonten) können nicht auf Backups zugreifen, die zu anderen Konten gehören.
• Unprivilegierte Konten werden daran gehindert, Backups zu ändern und zu löschen.
• Privilegierte Konten (mit Ausnahme von Backup-Administratorkonten) werden daran gehindert, Backups zu ändern und zu löschen.

• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden so häufig durchgeführt und so lange aufbewahrt, wie es Business-Continuity-Anforderungen verlangen.
• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden synchronisiert, um eine Wiederherstellung auf einen gemeinsamen Zeitpunkt zu ermöglichen.
• Backups wichtiger Daten, Software und Konfigurationseinstellungen werden sicher und wiederherstellbar aufbewahrt.
• Die Wiederherstellung wichtiger Daten, Software und Konfigurationseinstellungen aus Backups auf einen gemeinsamen Zeitpunkt wird im Rahmen von Disaster-Recovery-Übungen getestet.
• Unprivilegierte Konten können weder auf Backups zugreifen, die zu anderen Konten gehören, noch auf ihre eigenen Konten.
• Privilegierte Konten (mit Ausnahme von Backup-Administratorkonten) können weder auf Backups zugreifen, die zu anderen Konten gehören, noch auf ihre eigenen Konten.
• Unprivilegierte Konten werden daran gehindert, Backups zu ändern und zu löschen. Privilegierte Konten (einschließlich Backup-Administratorkonten) werden während ihrer Aufbewahrungsfrist daran gehindert, Backups zu ändern und zu löschen.

Atlassian unterhält einen Standard zur Aufbewahrung und Vernichtung von Daten, der festlegt, wie lange wir Daten verschiedener Arten aufbewahren müssen. Daten werden gemäß der Atlassian-Richtlinie für Datensicherheit und Information Lifecycle Management und den darauf aufbauenden Kontrollen klassifiziert.
Was Kundendaten betrifft, so werden bei Kündigung eines Atlassian-Vertrags die Daten eines Kundenteams aus der Live-Produktionsdatenbank entfernt. Alle direkt bei Atlassian hochgeladenen Dateianhänge werden innerhalb von 14 Tagen entfernt. Die Daten des Teams verbleiben in verschlüsselten Backups, bis der 60-tägige Aufbewahrungszeitraum für diese Backups überschritten ist und sie gemäß den Atlassian-Richtlinien zur Datenaufbewahrung vernichtet werden. Für den Fall, dass innerhalb von 60 Tagen nach einer angeforderten Datenlöschung eine Datenbankwiederherstellung erforderlich ist, wird das Operations-Team die Daten so schnell wie möglich erneut löschen, wenn das Live-Produktionssystem vollständig wiederhergestellt ist. Weitere Informationen findest du unter: Speicher überwachen und Daten zwischen Produkten verschieben.