Sicherheitsupdates und -ressourcen

Das Android-Sicherheitsteam ist für die Verwaltung von Sicherheitslücken verantwortlich, die in der Android-Plattform und in vielen der wichtigsten Android-Apps entdeckt werden, die auf Android-Geräten vorinstalliert sind.

Das Android-Sicherheitsteam findet Sicherheitslücken durch interne Forschung und reagiert auch auf von Dritten gemeldete Fehler. Zu den Quellen für externe Fehler gehören Probleme, die über das Formular für Sicherheitslücken gemeldet wurden, veröffentlichte und noch nicht veröffentlichte akademische Forschung, Upstream-Maintainer von Open-Source-Projekten, Benachrichtigungen von unseren Geräteherstellerpartnern und öffentlich bekannt gegebene Probleme, die in Blogs oder sozialen Medien gepostet wurden.

Sicherheitsprobleme melden

Jeder Entwickler, Android-Nutzer oder Sicherheitsforscher kann das Android-Sicherheitsteam über das Schwachstellenformular über potenzielle Sicherheitsprobleme informieren.

Fehler, die als Sicherheitsprobleme gekennzeichnet sind, sind extern nicht sichtbar. Sie können jedoch sichtbar gemacht werden, nachdem das Problem bewertet oder behoben wurde. Wenn Sie einen Patch oder einen Compatibility Test Suite-Test (CTS-Test) einreichen möchten, um ein Sicherheitsproblem zu beheben, hängen Sie ihn bitte an den Fehlerbericht an und warten Sie auf eine Antwort, bevor Sie den Code in AOSP hochladen.

Fehler priorisieren

Die erste Aufgabe bei der Behandlung einer Sicherheitslücke besteht darin, den Schweregrad des Fehlers und die betroffene Android-Komponente zu ermitteln. Die Schwere des Fehlers bestimmt, wie das Problem priorisiert wird. Die Komponente bestimmt, wer den Fehler behebt, wer benachrichtigt wird und wie die Korrektur für die Nutzer bereitgestellt wird.

Kontexttypen

In dieser Tabelle finden Sie die Definitionen von Hardware- und Software-Sicherheitskontexten. Der Kontext kann durch die Sensibilität der Daten, die er normalerweise verarbeitet, oder den Bereich, in dem er ausgeführt wird, definiert werden. Nicht alle Sicherheitskontexte sind für alle Systeme relevant. Die Tabelle ist von der niedrigsten zur höchsten Berechtigungsstufe sortiert.

Kontexttyp Typdefinition
Eingeschränkter Kontext Eine eingeschränkte Ausführungsumgebung, in der nur die minimalsten Berechtigungen bereitgestellt werden.

Beispiel: Vertrauenswürdige Apps verarbeiten nicht vertrauenswürdige Daten in einer Sandbox-Umgebung.
Benachteiligter Kontext Eine typische Ausführungsumgebung, die von Code ohne Berechtigungen erwartet wird.

Beispiel: Eine Android-App, die in einer SELinux-Domain mit dem Attribut untrusted_app_all ausgeführt wird.
Privilegierter Kontext Eine Umgebung mit privilegierten Berechtigungen, die möglicherweise Zugriff auf PII mehrerer Nutzer hat und/oder die Systemintegrität aufrechterhält.

Beispiel: Eine Android-App mit Funktionen, die durch die SELinux-untrusted_app-Domain verboten wären, oder mit Zugriff auf privileged|signature-Berechtigungen.
Betriebssystemkernel Funktionen, die:
  • ist Teil des Kernels
  • wird im selben CPU-Kontext wie der Kernel ausgeführt (z. B. Gerätetreiber)
  • direkten Zugriff auf den Kernel-Speicher hat (z. B. Hardwarekomponenten auf dem Gerät)
  • kann Skripts in eine Kernelkomponente (z. B. eBPF) laden.
  • ist einer der wenigen Nutzerdienste, die als kerneläquivalent gelten (z. B. apexd, bpfloader, init, ueventd und vold).
Trusted Hardware Base (THB) Diskrete Hardwarekomponenten, in der Regel auf dem SoC, die für die wichtigsten Anwendungsfälle des Geräts kritische Funktionen bereitstellen (z. B. Mobilfunk-Basisbänder, DSPs, GPUs und ML-Prozessoren).
Bootloader-Kette Eine Komponente, die das Gerät beim Start konfiguriert und dann die Steuerung an das Android-Betriebssystem übergibt.
Vertrauenswürdige Ausführungsumgebung Eine Komponente, die so konzipiert ist, dass sie auch vor einem feindseligen Betriebssystemkernel geschützt ist (z. B. TrustZone und Hypervisoren wie pKVM, die virtuelle Maschinen vor dem Betriebssystemkernel schützen).
Secure Enclave / Secure Element (SE) Eine optionale Hardwarekomponente, die gemäß Introduction to Secure Elements vor allen anderen Komponenten auf dem Gerät und vor physischen Angriffen geschützt ist.

Dazu gehört auch der Titan M-Chip, der in einigen Android-Geräten verbaut ist.

Schweregrad

Der Schweregrad eines Fehlers spiegelt im Allgemeinen den potenziellen Schaden wider, der entstehen könnte, wenn ein Fehler erfolgreich ausgenutzt würde. Verwenden Sie die folgenden Kriterien, um den Schweregrad zu bestimmen.

Bewertung Folge einer erfolgreichen Ausnutzung
Kritisch
  • Ausführung von beliebigem Code in der TEE oder SE
  • Umgehen von Softwaremechanismen, die verhindern sollen, dass sicherheitsrelevante Software- oder Hardwarekomponenten nicht richtig funktionieren (z. B. Überhitzungsschutz)
  • Remotezugriff auf vertrauliche Anmeldedaten, die für die Authentifizierung von Remotediensten verwendet werden (z. B. Kontopasswörter oder Bearer-Tokens)
  • Ausführung von beliebigem Code per Fernzugriff im Kontext des Mobilfunk-Basisbands ohne Nutzerinteraktion (z. B. Ausnutzung eines Fehlers im Mobilfunkdienst)
  • Ausführung von beliebigem Remote-Code in einem privilegierten Kontext, der Bootloader-Kette, THB oder dem Betriebssystemkernel
  • Remote-Umgehung von Anforderungen an die Nutzerinteraktion bei der Paketinstallation oder ähnliches Verhalten
  • Remote-Umgehung von Anforderungen an die Nutzerinteraktion für wichtige Entwickler-, Sicherheits- oder Datenschutzeinstellungen
  • Permanenter Denial-of-Service per Fernzugriff (erfordert das Neuflashen des gesamten Betriebssystems oder ein Zurücksetzen auf die Werkseinstellungen)
  • Umgehen von Secure Boot aus der Ferne
  • Unbefugter Zugriff auf Daten, die durch die SE geschützt sind, einschließlich des Zugriffs, der durch schwache Schlüssel in der SE ermöglicht wird.
Hoch
  • Ein vollständiges Umgehen einer wichtigen Sicherheitsfunktion (z. B. SELinux, FBE oder seccomp)
  • Ein allgemeiner Bypass für eine Defense-in-Depth- oder Exploit-Minderungstechnologie in der Bootloader-Kette, im TEE oder im SE
  • Ein allgemeiner Bypass für Betriebssystemschutzmechanismen, der Speicher- oder Dateiinhalte über App-, Nutzer- oder Profilgrenzen hinweg offenbart
  • Angriffe auf eine SE, die zu einem Downgrade auf eine weniger sichere Implementierung führen
  • Von der aus der Ferne erreichbaren, manipulierten Bare-Metal-Firmware (z. B. Baseband, Communications Processor (CP)) in den Application Processor (AP)-Kernel wechseln oder Mechanismen umgehen, die Bare-Metal-Firmware vom AP-Kernel isolieren sollen
  • Umgehen des Geräteschutzes, des Schutzes für zurückgesetzte Geräte (in Android 15 und höher) oder von Mobilfunkanbieterbeschränkungen
  • Umgehung von Anforderungen an die Nutzerinteraktion, die durch die TEE gesichert sind
  • Kryptografische Sicherheitslücke, die Angriffe auf End-to-End-Protokolle ermöglicht, einschließlich Angriffe auf Transport Layer Security (TLS) und Bluetooth (BT).
  • Lokaler Zugriff auf vertrauliche Anmeldedaten, die für die Authentifizierung von Remote-Diensten verwendet werden (z. B. Kontopasswörter oder Inhabertokens)
  • Lokale Ausführung von beliebigem Code in einem privilegierten Kontext, der Bootloader-Kette, THB oder dem Betriebssystemkernel
  • Lokales Umgehen von Secure Boot
  • Umgehen des Sperrbildschirms
  • Lokales Umgehen der Anforderungen an die Nutzerinteraktion für Einstellungen für Kernentwickler, Sicherheit oder Datenschutz
  • Lokale Umgehung der Anforderungen an die Nutzerinteraktion bei der Paketinstallation oder entsprechendes Verhalten
  • Lokaler dauerhafter Denial-of-Service (permanent, erfordert das Neuflashen des gesamten Betriebssystems oder das Zurücksetzen auf die Werkseinstellungen)
  • Remotezugriff auf geschützte Daten (d. h. Daten, die auf einen privilegierten Kontext beschränkt sind)
  • Remoteausführung von beliebigem Code in einem nicht privilegierten Kontext
  • Remote-Denial-of-Service für Mobilfunk- oder WLAN-Dienste, der bis zum Eingreifen des Nutzers anhält und ohne Nutzerinteraktion ausgelöst wird (z. B. ein Absturz des Mobilfunkschnittstellendienstes durch ein fehlerhaftes Paket, der nicht automatisch behoben wird und einen manuellen Neustart oder Geräte-Reboot erfordert).
  • Umgehen von Anforderungen an die Nutzerinteraktion per Fernzugriff (Zugriff auf Funktionen oder Daten, für die entweder eine Nutzeraktion oder eine Nutzerberechtigung erforderlich sein sollte)
  • Gezielte Verhinderung des Zugriffs auf den Rettungsdienst
  • Übertragung sensibler Informationen über ein unsicheres Netzwerkprotokoll (z. B. HTTP und unverschlüsseltes Bluetooth), wenn der Anfragende eine sichere Übertragung erwartet. Hinweis: Dies gilt nicht für die WLAN-Verschlüsselung (z. B. WEP).
  • Unbefugter Zugriff auf Daten, die durch die TEE geschützt sind, einschließlich des Zugriffs, der durch schwache Schlüssel in der TEE ermöglicht wird
Mäßig
  • Ein allgemeiner Bypass für eine Defense-in-Depth- oder Exploit-Minderungstechnologie in einem privilegierten Kontext, THB oder dem Betriebssystemkernel
  • Eine allgemeine Umgehung von Betriebssystemschutzmechanismen, die den Prozessstatus oder Metadaten über App-, Nutzer- oder Profilgrenzen hinweg offenlegen
  • Umgehen der WLAN-Verschlüsselung oder ‑Authentifizierung
  • Kryptografische Sicherheitslücke in Standard-Krypto-Primitiven, die das Auslesen von Klartext ermöglicht (nicht in TLS verwendete Primitive)
  • Lokaler Zugriff auf geschützte Daten (d. h. Daten, die auf einen privilegierten Kontext beschränkt sind)
  • Lokale Ausführung von beliebigem Code in einem nicht privilegierten Kontext
  • Lokales Umgehen der Anforderungen an die Nutzerinteraktion (Zugriff auf Funktionen oder Daten, die normalerweise entweder eine Nutzeraktion oder eine Nutzerberechtigung erfordern)
  • Remotezugriff auf ungeschützte Daten (d. h. Daten, auf die normalerweise jede lokal installierte App zugreifen kann)
  • Remote-Ausführung von beliebigem Code in einem eingeschränkten Kontext
  • Temporäre Denial of Service auf dem Gerät per Fernzugriff (Aufhängen oder Neustarten des Geräts)
Niedrig
  • Ein allgemeiner Bypass für eine mehrschichtige Sicherheitsstrategie auf Nutzerebene oder eine Technologie zur Eindämmung von Exploits in einem nicht privilegierten Kontext
  • Umgehung einer Berechtigung mit normalem Schutzniveau
  • Kryptografische Sicherheitslücke bei nicht standardmäßiger Verwendung
  • Allgemeines Umgehen von Personalisierungsfunktionen auf dem Gerät wie Voice Match oder Face Match
  • Falsche Dokumentation, die zu einer Sicherheitslücke führen kann
  • Lokale Ausführung von beliebigem Code in einem eingeschränkten Kontext
  • Vom System definierter Text, der eine irreführende Beschreibung enthält, die eine falsche Erwartung in Bezug auf die Sicherheit weckt
Geringe Sicherheitsauswirkungen (Negligible Security Impact, NSI)
  • Eine Sicherheitslücke, deren Auswirkungen durch einen oder mehrere Bewertungsmodifikatoren oder versionsspezifische Architekturänderungen gemindert wurden, sodass der tatsächliche Schweregrad unter „Niedrig“ liegt, obwohl das zugrunde liegende Code-Problem möglicherweise weiterhin besteht
  • Alle Sicherheitslücken, die ein fehlerhaftes Dateisystem erfordern, wenn dieses Dateisystem vor der Verwendung immer übernommen/verschlüsselt wird.
  • Lokaler vorübergehender Denial-of-Service, z. B. wenn das Problem durch Neustarten des Geräts oder Deinstallieren der auslösenden App behoben werden kann.

Schweregradmodifikatoren

Der Schweregrad von Sicherheitslücken lässt sich oft leicht ermitteln. Die Bewertungen können sich jedoch je nach Umständen ändern.

Grund Effekte
Erfordert die Ausführung in einem privilegierten Kontext, um den Angriff auszuführen (gilt nicht für TEE, SE und Hypervisoren wie pKVM) –1 Schweregrad
Sicherheitslückenspezifische Details begrenzen die Auswirkungen des Problems –1 Schweregrad
Umgehung der biometrischen Authentifizierung, die biometrische Informationen direkt vom Geräteinhaber erfordert –1 Schweregrad
Compiler- oder Plattformkonfigurationen mindern eine Sicherheitslücke im Quellcode. Mittlerer Schweregrad, wenn die zugrunde liegende Sicherheitslücke einen mittleren oder höheren Schweregrad hat
Erfordert physischen Zugriff auf das Innere des Geräts und ist auch dann möglich, wenn das Gerät ausgeschaltet ist oder seit dem Einschalten nicht entsperrt wurde –1 Schweregrad
Erfordert physischen Zugriff auf das Innere des Geräts, während es eingeschaltet und zuvor entsperrt wurde –2 Schweregrad
Ein lokaler Angriff, für den die Bootloader-Kette entsperrt sein muss Nicht höher als „Niedrig“
Ein lokaler Angriff, bei dem der Entwicklermodus oder dauerhafte Einstellungen des Entwicklermodus auf dem Gerät aktiviert sein müssen (und der kein Fehler im Entwicklermodus selbst ist). Nicht höher als „Niedrig“
Wenn keine SELinux-Domain den Vorgang gemäß der von Google bereitgestellten SEPolicy ausführen kann Geringe Auswirkungen auf die Sicherheit

Lokal, proximal und remote

Ein Remote-Angriffsvektor bedeutet, dass der Fehler ohne Installation einer App oder ohne physischen Zugriff auf ein Gerät ausgenutzt werden kann. Dazu gehören Fehler, die durch das Aufrufen einer Webseite, das Lesen einer E‑Mail, den Empfang einer SMS oder die Verbindung mit einem feindseligen Netzwerk ausgelöst werden können.

Proximal-Angriffsvektoren gelten als Remote-Angriffsvektoren. Dazu gehören Fehler, die nur von einem Angreifer ausgenutzt werden können, der sich physisch in der Nähe des Zielgeräts befindet, z. B. ein Fehler, der das Senden fehlerhafter WLAN- oder Bluetooth-Pakete erfordert. Wir betrachten Angriffe, die auf Ultrabreitband (UWB) und NFC basieren, als proximal und daher als Remote-Angriffe.

Für lokale Angriffe muss der Angreifer zuvor Zugriff auf das Opfer haben. In einem hypothetischen Beispiel, in dem es nur um Software geht, könnte dies über eine schädliche App erfolgen, die das Opfer installiert hat, oder über eine Instant App, deren Ausführung es zugestimmt hat.

Erfolgreich gekoppelte Geräte (z. B. Bluetooth-Companion-Geräte) gelten als lokal. Wir unterscheiden zwischen einem gekoppelten Gerät und einem Gerät, das an einem Kopplungsvorgang beteiligt ist.

  • Fehler, die die Fähigkeit des Nutzers beeinträchtigen, das andere Gerät zu identifizieren, mit dem es gekoppelt wird (d.h. die Authentifizierung), werden als proximal und daher als Remote betrachtet.
  • Fehler, die während des Kopplungsvorgangs, aber vor der Nutzereinwilligung (d.h. der Autorisierung) auftreten, gelten als proximal und daher als Remote-Fehler.
  • Fehler, die nach der Nutzereinwilligung auftreten, gelten als lokal, auch wenn die Kopplung letztendlich fehlschlägt.

Physische Angriffsvektoren gelten als lokal. Dazu gehören Fehler, die nur von einem Angreifer ausgenutzt werden können, der physischen Zugriff auf das Gerät hat, z. B. ein Fehler auf dem Sperrbildschirm oder ein Fehler, der das Einstecken eines USB-Kabels erfordert. Da Geräte häufig entsperrt sind, wenn sie über USB angeschlossen werden, haben Angriffe, die eine USB-Verbindung erfordern, unabhängig davon, ob das Gerät entsperrt sein muss oder nicht, denselben Schweregrad.

Netzwerksicherheit

Android geht davon aus, dass alle Netzwerke feindselig sind und Angriffe einschleusen oder den Traffic ausspionieren könnten. Die Link-Layer-Sicherheit (z. B. WLAN-Verschlüsselung) schützt zwar die Kommunikation zwischen einem Gerät und dem Access Point, mit dem es verbunden ist, aber nicht die verbleibenden Links in der Kette zwischen dem Gerät und den Servern, mit denen es kommuniziert.

Im Gegensatz dazu schützt HTTPS in der Regel die gesamte Kommunikation von Anfang bis Ende. Die Daten werden an der Quelle verschlüsselt und erst entschlüsselt und überprüft, wenn sie ihr endgültiges Ziel erreicht haben. Daher werden Sicherheitslücken, die die Sicherheit der Link-Layer-Netzwerke beeinträchtigen, als weniger schwerwiegend eingestuft als Sicherheitslücken in HTTPS/TLS: Die WLAN-Verschlüsselung allein reicht für die meisten Kommunikationen im Internet nicht aus.

Biometrische Authentifizierung

Die biometrische Authentifizierung ist ein schwieriges Feld und selbst die besten Systeme können durch eine ähnliche Übereinstimmung getäuscht werden (siehe Blog für Android-Entwickler: Lockscreen and authentication improvements in Android 11). Diese Schweregrade unterscheiden zwischen zwei Arten von Angriffen und sollen das tatsächliche Risiko für den Endnutzer widerspiegeln.

Bei der ersten Art von Angriffen kann die biometrische Authentifizierung auf allgemeine Weise umgangen werden, ohne dass hochwertige biometrische Daten des Eigentümers erforderlich sind. Wenn ein Angreifer beispielsweise ein Stück Kaugummi auf einen Fingerabdrucksensor legen kann und dadurch aufgrund von Rückständen auf dem Sensor Zugriff auf das Gerät erhält, ist das ein einfacher Angriff, der auf jedem anfälligen Gerät durchgeführt werden könnte. Dafür sind keine Kenntnisse des Geräteinhabers erforderlich. Da der Angriff verallgemeinerbar ist und sich möglicherweise auf eine größere Anzahl von Nutzern auswirkt, erhält er die volle Schweregradeinstufung (z. B. „Hoch“ für das Umgehen des Sperrbildschirms).

Bei der anderen Art von Angriffen wird in der Regel ein Präsentationsangriffsinstrument (Spoof) verwendet, das auf dem Geräteinhaber basiert. Manchmal sind diese biometrischen Informationen relativ leicht zu erhalten. Wenn beispielsweise das Profilbild einer Person in den sozialen Medien ausreicht, um die biometrische Authentifizierung zu täuschen, erhält der biometrische Bypass die volle Schweregradeinstufung. Wenn ein Angreifer jedoch biometrische Daten direkt vom Geräteinhaber erfassen müsste (z. B. einen Infrarot-Scan des Gesichts), ist das eine so große Hürde, dass die Anzahl der von dem Angriff betroffenen Personen begrenzt wird. Daher wird der Modifikator -1 angewendet.

SYSTEM_ALERT_WINDOW und Tapjacking

Informationen zu unseren Richtlinien zu SYSTEM_ALERT_WINDOW und Tapjacking finden Sie im Abschnitt Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen (Tapjacking-/Overlay-Schwachstelle SYSTEM_ALERT_WINDOW auf einem nicht sicherheitskritischen Bildschirm) auf der Seite Bugs with no security impact (Bugs ohne Sicherheitsrisiko) der BugHunter University.

Sicherheit für mehrere Nutzer in Android Automotive OS

Android Automotive OS verwendet ein Sicherheitsmodell für mehrere Nutzer, das sich von den anderen Formfaktoren unterscheidet. Jedes Android-Nutzerkonto ist für eine andere Person vorgesehen. Ein temporärer Gastnutzer kann beispielsweise einem Freund zugewiesen werden, der das Fahrzeug vom Fahrzeughalter ausleiht. Für solche Anwendungsfälle haben Nutzer standardmäßig Zugriff auf die für die Nutzung des Fahrzeugs erforderlichen Komponenten, z. B. WLAN- und Mobilfunknetzwerkeinstellungen.

Betroffene Komponente

Das Entwicklungsteam, das für die Behebung des Fehlers verantwortlich ist, hängt davon ab, in welcher Komponente sich der Fehler befindet. Das kann eine Kernkomponente der Android-Plattform, ein Kernel-Treiber, der von einem Erstausrüster (Original Equipment Manufacturer, OEM) bereitgestellt wird, oder eine der vorinstallierten Apps auf Pixel-Geräten sein.

Fehler im AOSP-Code werden vom Android-Entwicklungsteam in unseren internen Repositories behoben.

Die Komponente spielt auch eine Rolle dabei, wie Nutzer Updates erhalten. Ein Fehler im Framework oder Kernel erfordert ein OTA-Firmwareupdate (Over-the-Air), das von jedem OEM bereitgestellt werden muss. Ein Fehler in einer App oder Bibliothek, die bei Google Play veröffentlicht wurde (z. B. Gmail, Google Play-Dienste oder WebView), kann Android-Nutzern als Update über Google Play gesendet werden.

Partner benachrichtigen

Wenn eine Sicherheitslücke in AOSP in einem Sicherheitsbulletin für Android behoben wird, benachrichtigen wir Android-Partner über die Details des Problems und stellen Patches bereit. Die Liste der unterstützten Backport-Versionen ändert sich mit jedem neuen Android-Release. Wenden Sie sich an den Hersteller Ihres Geräts, um eine Liste der unterstützten Geräte zu erhalten.

Code für AOSP freigeben

Wenn sich der Sicherheitsfehler in einer AOSP-Komponente befindet, wird das Update an AOSP gesendet, nachdem das OTA für Nutzer veröffentlicht wurde.

Android-Updates erhalten

Updates für das Android-System werden in der Regel über OTA-Updatepakete auf Geräte übertragen. Diese Updates können vom OEM, der das Gerät hergestellt hat, oder vom Mobilfunkanbieter, der den Dienst für das Gerät bereitstellt, stammen. Updates für Google Pixel-Geräte werden vom Google Pixel-Team bereitgestellt, nachdem sie ein technisches Akzeptanzverfahren (Technical Acceptance, TA) des Mobilfunkanbieters durchlaufen haben. Google veröffentlicht auch Pixel-Factory Images, die auf Geräte geladen werden können.

Google-Dienste aktualisieren

Das Android-Sicherheitsteam stellt nicht nur Patches für Sicherheitsfehler bereit, sondern prüft auch Sicherheitsfehler, um festzustellen, ob es andere Möglichkeiten gibt, Nutzer zu schützen. Google Play scannt beispielsweise alle Apps und entfernt alle Apps, die versuchen, einen Sicherheitsfehler auszunutzen. Bei Apps, die nicht über Google Play installiert wurden, können Geräte mit Google Play-Diensten auch die Funktion Apps überprüfen verwenden, um Nutzer vor potenziell schädlichen Apps zu warnen.

Weitere Informationen

Informationen für Android-App-Entwickler: https://developer.android.com

Sicherheitsinformationen sind auf den Websites für Android Open Source und Entwickler verfügbar. Gute Ausgangspunkte:

Berichte

Das Android-Sicherheitsteam veröffentlicht manchmal Berichte oder Whitepapers. Weitere Informationen finden Sie unter Sicherheitsberichte.