Datensicherheitsanforderungen

Vorbereitung auf die Beantwortung von Datensicherheitsfragen

Datenflüsse

Erstelle (bzw. aktualisiere, sofern nötig) ein Datenflussdiagramm oder eine entsprechende Beschreibung, das bzw. die veranschaulicht, wie die App oder das System Plattformdaten verarbeitet.

1. Clientseitig: Berücksichtige alle Client-Software wie Browser, Mobilgeräte und andere unterstützte Gerätearten.
2. Serverseitig: Berücksichtige alle zugehörigen Server- oder Cloudumgebungen und gib Folgendes an:
1. Die Komponenten, bei denen Plattformdaten:
1. in die Serverumgebung(en) eintreten oder sie verlassen (z. B. Web Listener und REST APIs)
2. in beständigen oder langlebigen Speicher geschrieben werden, wie Datenbanken, Festplatten oder Protokolldateien
2. Das Hosting-Modell, z. B.:
1. Selbst gehostet: Die eigenen Server einer Organisation werden in einem eigenen oder gemeinsam genutzten Rechenzentrum betrieben.
2. Infrastructure-as-a-Service (IaaS): z. B. AWS EC2, Microsoft Azure IaaS und Google Compute Engine.
3. Platform-as-a-Service (PaaS): z. B. AWS Elastic Beanstalk, Google App Engine, Force.com.
4. Backend-as-a-Service (BaaS): z. B. AWS Amplify, Azure Mobile Apps, Firebase und MongoDB Switch.
5. Hybrid: eine Kombination aus den obigen Modellen.

Letzten Endes sollte das Datenflussdiagramm bzw. die Datenflussbeschreibung Folgendes enthalten.

1. An welcher Stelle in der Client- und Server-Software Meta API-Zugriffsschlüssel generiert und übermittelt/gespeichert/verlängert werden (sofern für das Systemdesign anwendbar)
2. Wie du Plattformdaten aus den APIs von Meta abrufst, insbesondere in Bezug auf personenbezogene Informationen wie Name, E-Mail-Adresse, Geschlecht, Geburtsdatum einer Person oder andere Nutzerdaten
3. Wie du diese Daten verwendest, speicherst und übermittelst
4. Jegliche Viertparteien, an die Plattformdaten gesendet werden

Erstellung von Nachweisen

Möglicherweise musst du für deine implementierten Datenschutzvorkehrungen Belege einreichen. Wir empfehlen, den Belegleitfaden in diesem Dokument zu lesen. Darin findest du Beispiele für akzeptable Belege und kannst deine Belege entsprechend vorbereiten. Wir akzeptieren Dokumente in gängigen Formaten sowie Screenshots und Bildschirmaufnahmen. Stelle bitte sicher, dass die Dateien nicht passwortgeschützt sind. Du kannst mehrere Dateien mit einer maximalen Größe von jeweils 2 GB hochladen. Wir akzeptieren die Dateitypen .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip und .zipx.

Arten von Belegen

Meta verlangt zwei Arten von Belegen für Datenschutzvorkehrungen in Apps:

1. Richtlinien- oder Prozessbeleg: Ein Dokument, das die Datenschutzrichtlinien oder -prozesse für diese Maßnahme erläutert
2. Implementierungsbeleg: Ein Nachweis aus dem System oder der App, der zeigt, wie du die Maßnahme implementiert hast, z. B. die Konfiguration eines Tools oder eine Bildschirmaufnahme

Richtlinien- oder Prozessbeleg

Ein Richtlinien- oder Prozessbeleg ist eine schriftliche Dokumentation, in der die Herangehensweise einer bestimmten Datenschutzvorkehrung dargelegt wird. Dieser Beleg kann beispielsweise ein Auszug aus internen Richtlinien sein, eine teilweise oder vollständige Seite des internen Wikis oder ein neu erstelltes Dokument, in dem du den Ablauf erläuterst, falls keine bestehende Dokumentation vorliegt. In jedem Fall muss der hochgeladene Richtlinien- oder Prozessbeleg klar erläutern, wie die Herangehensweise der Datenschutzvorkehrung die Anforderungen von Meta erfüllt. Bitte lade nur die Richtlinien oder Auszüge hoch, die für Metas Sicherheitsprüfung relevant und notwendig sind, oder verwende das Textfeld zur Frage, um unsere Prüfer auf die entsprechenden Abschnitte hinzuweisen.

Implementierungsbeleg

Ein Implementierungsbeleg zeigt anhand eines Screenshots oder einer Bildschirmaufnahme, wie du die Richtlinie oder das Verfahren praktisch implementiert hast. Da die Konfiguration je nach Entwickler variiert, können wir nicht für jedes Szenario ein Beispiel geben. Dein Implementierungsbeleg sollte jedoch nach Möglichkeit ebenso detailliert sein wie unsere Beispiele.

Vollständigkeit der Belege

Uns ist bewusst, dass es einen unverhältnismäßigen Aufwand darstellen kann, umfassende Implementierungsbelege für eine Datenschutzvorkehrung zu erstellen. Du solltest jedoch Belege entsprechend dieser Richtlinien einreichen und vor der Einreichung darauf achten, vertrauliche Informationen zu zensieren:

1. Der Richtlinien- oder Prozessbeleg muss die Anforderungen von Meta eindeutig erfüllen oder darüber hinausgehen
1. Meta prüft den Richtlinien- oder Prozessbeleg auf Aussagen zur entsprechenden Vorkehrung, die den Anforderungen entsprechen.
2. Du solltest Anmerkungen hinzufügen, um die relevanten Abschnitte hervorzuheben.
3. Für die Vorkehrung „Für alle Netzwerkverbindungen, über die Plattformdaten übermittelt werden, ist eine TLS 1.2 -Verschlüsselung oder höher erforderlich“ gilt beispielsweise ein Dokument, das folgende Aussagen enthält, als akzeptabler Beleg:
1. Plattformdaten von Meta dürfen nie unverschlüsselt über nicht vertraute Netzwerke übertragen werden
2. Für alle Weblistener (z. B. mit dem Internet verbundene Loadbalancer), die Plattformdaten empfangen oder zurückgeben, ist in der Konfiguration TLS 1.2 aktiviert
3. Für alle Weblistener, die Plattformdaten empfangen oder zurückgeben, sind folgende Protokolle in der Konfiguration deaktiviert: SSL v2, SSL v3, TLS 1.0 und TLS 1.1
2. Der Implementierungsbeleg muss für die Implementierung jeder Richtlinie bzw. jedes Prozesses mindestens ein Beispiel zeigen
1. Du musst für die Implementierung jeder Vorkehrung mindestens ein Dokument, einen Screenshot oder eine Tool-Konfiguration hochladen, das die Implementierung zeigt
2. Meta prüft die Implementierungsbelege, um sicherzustellen, dass sie den Richtlinien- oder Prozessbelegen entsprechen
3. Für die Vorkehrung Für alle Netzwerkverbindungen, über die Plattformdaten übermittelt werden, ist eine TLS 1.2 -Verschlüsselung oder höher erforderlich gilt beispielsweise der Qualys-SSL-Testbericht für eine Webdomain, die entsprechend der Richtlinie oder dem Prozess konfiguriert ist, als akzeptabler Beleg.

Vertrauliche Daten, die in Belegen zu zensieren sind

Reiche keine Belege ein, die folgende Informationen in lesbarer Form enthalten. Wenn du einen Screenshot mit einem Bildeditor aufgenommen hast, überlagere diese Informationen mit einem schwarzen Rechteck. Wenn du einen PDF-Editor verwendest, achte darauf, zur Zensur dieser Informationen ein Tool zu verwenden, das sie tatsächlich entfernt und nicht nur verdeckt (z. B. das Tool „Redigieren“ in der App „Vorschau“ von Apple)

• Gesundheitsdaten
• Finanzdaten
• IP-Adressen
• Passwörter, Anmeldedaten und Zugriffsschlüssel
• Verschlüsselungscodes
• Postadressen
• Personenbezogene Informationen über natürliche Personen (nicht über Unternehmen oder andere Organisationen), Mitarbeiter oder andere verbundene Personen, die direkt oder indirekt die Identität dieser Person preisgeben könnten, beispielsweise:

  • Name
  • E-Mail-Adressen
  • Nutzer-IDs
  • Geburtsdaten
  • Standortdaten
  • Gesundheitsdaten
  • Kulturelle, gesellschaftliche oder politische Identität
  • Daten, die im Kontext des Belegs anderweitig auf die Identität der Person hindeuten könnten
• Detaillierte Schritte zur Reproduktion einer Schwachstelle (z. B. in einem Penetrationstestbericht)
• Daten, von denen die Entwickler wissen oder vernünftigerweise wissen müssten, dass sie von Kindern unter 13 Jahren stammen oder diese betreffen

Serverseitig gespeicherte Plattformdaten durch Verschlüsselung ruhender Daten schützen

Frage: Setzt du die Verschlüsselung ruhender Daten für alle in einer Cloud-, Server- oder Rechenzentrumsumgebung gespeicherten Plattformdaten durch?

Absicht

Die Verschlüsselung ruhender Daten schützt die Plattformdaten, indem sie die Daten ohne gesonderten Entschlüsselungscode unlesbar macht. Dies bietet einen zusätzlichen Schutz vor unbefugtem Lesezugriff.

• Auf Servern oder in einer Cloud-Umgebung, wo die Plattformdaten aller Benutzer einer App gespeichert sind, verringert die Verschlüsselung ruhender Daten das Risiko einer Datenschutzverletzung
• Die Verschlüsselung ruhender Daten schützt beispielsweise vor Bedrohungen wie dem unbefugten Zugriff auf ein Datenbank-Backup, das möglicherweise nicht so gut geschützt ist wie die Produktionsdatenbank selbst.

Zusammenfassung der Anforderungen

Beim serverseitigen Speichern von Plattformdaten:

• MUSST du diese Daten mit einer der folgenden Methoden schützen:

  • Verschlüsselung ruhender Daten oder
  • Zulässige alternative Schutzmaßnahmen (siehe Zulässige alternative Schutzmaßnahmen)

• Je nach Art der verwendeten Verschlüsselung gilt:

  • Es ist sowohl eine Verschlüsselung auf Anwendungsebene (z. B. Software, die bestimmte Spalten in einer Datenbank ver- und entschlüsselt) als auch eine Verschlüsselung auf dem gesamten Speichermedium zulässig.
  • Auch wenn wir empfehlen, eine Verschlüsselung nach Branchenstandard (z. B. AES, BitLocker, Blowfish, TDES, RSA) zu verwenden, schreiben wir keine bestimmten Algorithmen oder Schlüssellängen vor.

Wenn ein Entwickler KEINE Plattformdaten serverseitig speichert, gilt diese Anforderung nicht.

Sonderfälle

Serverseitige Speicherung mit IaaS, Self-Hosting oder Hybrid-Hosting

Wenn du Plattformdaten über IaaS-Hosting (z. B. AWS EC2, Microsoft Azure IaaS und Google Compute Engine) speicherst oder wenn du Self-Hosting oder einen hybriden Ansatz verwendest, so ist diese Frage zutreffend.

Serverseitige Speicherung mit SaaS-, PaaS- oder BaaS-Produkten

Es gibt jedoch auch andere Backend-Hosting-Modelle, die einen Sonderfall darstellen:

Wenn du Plattformdaten nur über eines dieser Modelle speicherst (und kein IaaS, Self-Hosting oder Hybrid-Hosting einsetzt), ist diese Frage nicht zutreffend. Du solltest diese Beziehung stattdessen im Abschnitt Dienstleister in der Datenschutzbewertung beschreiben.

• BaaS – z. B. AWS Amplify, Azure Mobile Apps, Azure Playfab, Google Firebase und MongoDB Switch
• PaaS – z. B. AWS Elastic Beanstalk, Google App Engine, Force.com
• SaaS – z. B. MailChimp oder Salesforce

Serverseitige Speicherung über Meta-APIs

Wenn du Plattformdaten nur über eine Meta-API, z. B. player.setDataAsync(), im Instant Games-SDK speicherst, ist diese Frage nicht zutreffend.

Nachweis-Leitfaden

Wenn du aufgefordert wirst, Nachweise für diese Schutzmaßnahmen zu erbringen, befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

Beispielimplementierungsnachweis

AWS RDS

AWS RDS – Die Verschlüsselung ruhender Daten ist in AWS RDS konfigurierbar. Entwickler müssen daher sichergehen, dass die Konfigurationsoption so eingestellt ist, dass diese Schutzmaßnahme angewendet wird.

Als repräsentative RDS-Instanz, die Plattformdaten enthält, kannst du das AWS CLI-Tool verwenden, um die StorageEncrypted-Konfiguration abzurufen.

# List RDS instances in default region
$ aws rds describe-db-instances \
  --query 'DBInstances[*].DBInstanceIdentifier'

[
    "database-1",
    "database-2"
]

# For each instance returned, retrieve the storage encrypted config
$ aws rds describe-db-instances \
  --db-instance-identifier database-1 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

$ aws rds describe-db-instances \
  --db-instance-identifier database-2 \
  --query 'DBInstances[*].StorageEncrypted'
[
    true
]

AWS DynamoDB

AWS DynamoDB verschlüsselt standardmäßig ruhende Daten. Die Konfiguration für die Verschlüsselung ruhender Daten für eine Tabelle kannst du mit diesen Befehlen abrufen.

$ aws dynamodb list-tables --output table

--------------
| ListTables |
+------------+
||TableNames||
|+----------+|
||  Users   ||
|+----------+|


$ aws dynamodb describe-table \
 --table-name Users \
 --query "Table.SSEDescription.Status"

"ENABLED"

AWS DocumentDB

AWS DocumentDB muss so konfiguriert werden, dass die Verschlüsselung ruhender Daten angewendet wird. Als repräsentatives Cluster, das Plattformdaten enthält, kannst du diese Befehle verwenden, um die StorageEncrypted-Konfiguration abzurufen.

$ aws docdb describe-db-clusters --query 'DBClusters[*].DBClusterIdentifier'

[
    "docdb-users"
]

$ aws docdb describe-db-clusters \
  --db-cluster-identifier 'docdb-users' \
  --query 'DBClusters[*].StorageEncrypted'
[
    true
]

AWS S3

AWS S3-Buckets können so konfiguriert werden, dass die Verschlüsselung ruhender Daten auf alle Objekte angewendet wird, die in einem Bucket erstellt werden. Verwende diese Befehle, um Buckets aufzulisten und die Konfiguration für die standardmäßige Bucket-Verschlüsselung abzurufen.

$ aws s3api list-buckets --output table --query "Buckets[*].Name"

---------------------------------------------
|                ListBuckets                |
+-------------------------------------------+
|  platform.storage                         |
+-------------------------------------------+

$ aws s3api get-bucket-encryption \
  --bucket  platform.storage \
  --query "ServerSideEncryptionConfiguration.Rules[*].ApplyServerSideEncryptionByDefault" \
  --output table
---------------------
|GetBucketEncryption|
+-------------------+
|   SSEAlgorithm    |
+-------------------+
|  AES256           |
+-------------------+

Microsoft Azure

Sieh in der Microsoft-Dokumentation zur Verschlüsselung ruhender Daten in Azure nach, die für die Nutzung der jeweiligen Dienste durch die Organisation relevant ist.

Google Cloud Platform

Sieh in der Google-Dokumentation zur Verschlüsselung ruhender Daten auf Google Cloud Platform nach.

Zulässige alternative Schutzmaßnahmen

Wenn du in der serverseitigen Umgebung keine Verschlüsselung ruhender Daten implementierst, kannst du Plattformdaten mit einer alternativen zulässigen Methode schützen. In diesem Fall solltest du Folgendes beschreiben:

1. Sensibilität der Plattformdaten – Die Speicherung bestimmter Plattformdaten wird mit einem niedrigeren oder höheren Risiko gleichgesetzt. Du musst herausfinden, welche speziellen Plattformdaten-Benutzerattribute serverseitig gespeichert werden.
2. Angewendete Kontrollmechanismen zur Senkung der Wahrscheinlichkeit bestimmter Gefahren
1. Kontrollmechanismen zur Vermeidung der Kompromittierung von Netzwerken, die Plattformdaten enthalten
2. Kontrollmechanismen zur Vermeidung der Kompromittierung von Apps/Systemen, die Zugriff auf Plattformdaten haben
3. Kontrollmechanismen zur Vermeidung des Verlustes physischer Speichermedien (z. B. außer Betrieb genommene Netzwerkspeichergeräte)
4. Kontrollmechanismen zur Vermeidung des Verlustes physischer Speichermedien (z. B. außer Betrieb genommene Netzwerkspeichergeräte)
5. Kontrollmechanismen zur Vermeidung des unbefugten Zugriffs auf Backup-Kopien von Speicher, der Plattformdaten-Backups enthält
3. Nachweisstärke – Vermerke unbedingt, ob diese Schutzmaßnahmen durch einen unabhängigen Prüfer bewertet wurden, beispielsweise im Rahmen eines SOC2-Audits.

Schutz von Plattformdaten, die auf Geräten der Organisation und Wechselmedien gespeichert sind, vor Verlust

Frage: Speziell in Bezug auf Daten, die auf Geräten der Organisation und persönlichen Geräten gespeichert sind: Wird eine Verschlüsselung ruhender Daten durchgesetzt oder gibt es Richtlinien und Regeln, um das Risiko von Datenverlusten für alle auf diesen Geräten gespeicherten Plattformdaten zu reduzieren?

Absicht

Wenn ein Entwickler Plattformdaten auf Geräten wie Mitarbeiter-Laptops oder Wechselmedien (z. B. USB-Laufwerken) speichert, besteht ein hohes Risiko, dass Unbefugte auf diese Daten zugreifen, wenn das Gerät verloren geht oder gestohlen wird. Entwickler sollten Maßnahmen ergreifen, um dieses Risiko zu minieren.

Zusammenfassung der Anforderungen

• Um das Risiko eines nicht autorisierten Zugriffs auf Plattformdaten zu verringern, müssen die Entwickler entweder technische Kontrollmechanismen (bevorzugt) oder administrative Kontrollmechanismen (nicht bevorzugt, aber zulässig) in Bezug auf die Plattformdaten auf Geräten der Organisation (z. B. Laptops) und Wechselmedien durchführen.

  • Technische Kontrollmechanismen – Beispiele für technische Kontrollmechanismen sind: 1) Erlauben, dass sich nur verwaltete Geräte mit dem Unternehmensnetzwerk verbinden; 2) Erzwingen einer vollständigen Festplattenverschlüsselung auf verwalteten Geräten (z. B. BitLocker); 3) Blockieren von Wechselmedien (z. B. USB-Laufwerken), damit sie nicht an verwaltete Geräte angeschlossen werden können; 4) Verwenden von DLP-Technologie (Data Loss Prevention) auf verwalteten Geräten.
  • Administrative Kontrollmechanismen – Beispiele für administrative Kontrollmechanismen sind schriftliche Richtlinien mit jährlichen Schulungen über den korrekten Umgang mit Plattformdaten auf Geräten der Organisation und privaten Geräten.

Nachweis-Leitfaden

Wenn du aufgefordert wirst, Nachweise für diese Schutzmaßnahmen zu erbringen, befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

Du kannst eine oder beide Schutzmaßnahmen einsetzen: a) technische Kontrollmechanismen (z. B. Festplattenverschlüsselung) oder b) Regeln/Richtlinien, um das Risiko eines Datenverlusts bei Plattformdaten zu verringern, die auf Geräten der Organisation gespeichert sind, z. B. Laptops und Mobiltelefonen.

Zu den technischen Kontrollmechanismen zählen u. a.:

• Blockieren von nicht verwalteten Geräten für die Verbindung mit sensiblen Diensten, z. B. dem Unternehmensnetzwerk
• Erzwingen der Festplattenverschlüsselung auf verwalteten Geräten (z. B. über BitLocker für Windows oder FileVault für Mac)
• Blockieren von Wechselmedien (z. B. USB-Laufwerken) auf verwalteten Geräten
• Einsatz von DLP-Software auf verwalteten Geräten, um den unsachgemäßen Umgang mit Plattformdaten zu unterbinden (z. B. das Versenden von Daten als E-Mail-Anhang)

Zu den Regeln/Richtlinien zählen u. a.:

• Eine Dokumentation, die den akzeptablen und inakzeptablen Umgang mit Daten im Allgemeinen und mit Plattformdaten im Besonderen beschreibt
• Ein Verfahren, das den Mitgliedern der Organisation die Richtlinien ins Bewusstsein ruft (z. B. vertragliche Vereinbarung als Einstellungsvoraussetzung, Schulungen, regelmäßige Erinnerungen per E-Mail)

Beispielnachweis

Eine Organisation stuft Plattformdaten von Meta gemäß ihres Datenklassifizierungsstandards als „private Daten“ ein. Die Organisation hat Richtlinien für den Umgang mit Daten erstellt und verpflichtet alle Mitarbeiter und Mitarbeiterinnen, diese Richtlinien zu verstehen und zu befolgen.

Schutz von über Netzwerke übermittelten Plattformdaten durch Verschlüsselung während der Übermittlung

Frage: Aktivierst du das Sicherheitsprotokoll TLS 1.2 oder eine aktuellere Version für alle Netzwerkverbindungen, die öffentliche Netzwerke, über die Plattformdaten übermittelt werden, passieren oder eine Verbindung zu ihnen herstellen? Stellst du außerdem sicher, dass Plattformdaten niemals unverschlüsselt über öffentliche Netzwerke übermittelt werden (z. B. über HTTP oder FTP) und dass die Sicherheitsprotokolle SSL v2 und SSL v3 niemals verwendet werden?

Absicht

Plattformdaten, die über das Internet übermittelt werden, sind für jeden zugänglich, der den Netzwerkverkehr überwachen kann. Deshalb müssen Plattformdaten durch Verschlüsselung geschützt werden, um zu verhindern, dass diese unberechtigten Parteien die Daten lesen können.

• Die Verschlüsselung während der Übermittlung schützt die Plattformdaten, wenn sie über nicht vertrauenswürdige Netzwerke (z. B. das Internet) übermittelt werden, indem sie außer für das Herkunfts- und das Zielgerät unlesbar gemacht werden.
• Mit anderen Worten: Zwischengeschaltete Dritte sind nicht in der Lage, die Plattformdaten zu lesen, selbst wenn sie den Netzwerkverkehr mitverfolgen können (dies wird auch als Man-in-the-Middle-Angriff bezeichnet).
• TLS ist die am weitesten verbreitete Form der Verschlüsselung während der Übermittlung. Es ist die Technologie, die von Browsern verwendet wird, um die Kommunikation mit Websites wie etwa denen von Banken zu sichern.

Zusammenfassung der Anforderungen

Unabhängig davon, ob du Plattformdaten serverseitig verarbeitest oder nicht:

• Plattformdaten dürfen nie unverschlüsselt über nicht vertrauenswürdige Netzwerke übermittelt werden
• Für alle Weblistener (z. B. mit dem Internet verbundene Loadbalancer), die Plattformdaten empfangen oder zurückgeben, musst du Folgendes tun:

  • TLS 1.2 oder höher aktivieren
  • SSL v2 und SSL v3 deaktivieren
• TLS 1.0 und TLS 1.1 dürfen nur aus Gründen der Kompatibilität mit Client-Geräten, die nicht TLS 1.2+-fähig sind, verwendet werden
• Meta empfiehlt, die Verschlüsselung während der Übermittlung für Übermittlungen von Plattformdaten anzuwenden, die vollständig innerhalb privater Netzwerke stattfinden, z. B. in einer Virtual Private Cloud (VPC), dies ist jedoch nicht verpflichtend.

Die nachstehende Tabelle fasst die Richtlinie zur Verschlüsselung während der Übermittlung für verschiedene Übermittlungsarten zusammen.

Nachweis-Leitfaden

Wenn du aufgefordert wirst, Nachweise für diese Schutzmaßnahmen zu erbringen, befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen. Eine einfache Möglichkeit, einen Implementierungsnachweis zu erstellen, der die Konfiguration von einem der Weblistener aufzeigt, ist die Verwendung des Qualys SSL Server Test-Tools.

• Führe das Qualys SSL Server Test-Tool für einen oder mehrere der Weblistener aus, die identisch konfiguriert sind (einschließlich derjenigen, die auf nicht standardmäßigen Ports laufen).
• Setze ein Häkchen bei der Option „Die Ergebnisse nicht auf den Tafeln anzeigen“, um zu verhindern, dass die Ergebnisse zur Qualys-Website hinzugefügt werden. Drucke die komplette Seite mit den Testergebnissen als PDF aus. Wiederhole die oben genannten Schritte für alle Weblistener, an die bzw. von denen du Plattformdaten übermittelst, die eine abweichende TLS-Konfiguration haben

Beispielimplementierungsnachweis

Dies ist eine Beispielausgabe aus dem Qualys SSL Server Test-Tool. Beachte die roten Anmerkungen im Abschnitt „Konfiguration“, die zusammenfassen, welche SSL-/TLS-Versionen unterstützt werden. Hinweis: Dieses Beispiel umfasst nur die beiden ersten Seiten, aber du solltest die vollständigen Testergebnisse aufführen.

Zulässige alternative Schutzmaßnahmen

Möglicherweise schützt du die Plattformdaten während der Übermittlung mit einer anderen Art der Verschlüsselung als TLS; dies ist unter Umständen akzeptabel, wenn der Ansatz einen gleichwertigen Schutz bietet. In diesen Fall solltest du Details zur verwendeten Verschlüsselung angeben, damit Meta sie überprüfen kann:

• Symmetrische oder asymmetrische Verschlüsselung?
• Verschlüsselungsalgorithmus (z. B. AES, BitLocker, TDES, RSA)?
• Was ist das Mindestschlüssellänge?

App und Systeme auf Schwachstellen und Sicherheitsprobleme überprüfen

Frage: Überprüfst du die App und Systeme jährlich auf Schwachstellen und Sicherheitsprobleme? (Führst du beispielsweise eine manuelle Eindringprüfung durch?)

Absicht

Entwickler müssen auf Schwachstellen und Sicherheitsprobleme überprüfen, damit diese proaktiv entdeckt und im Idealfall Sicherheitsvorfälle verhindert werden können, bevor sie auftreten

• App-Entwickler, die die Meta-Plattform verwenden, um Plattformdaten mit Software, die sie schreiben, über Apps/Systeme verwenden, die sie konfigurieren und betreiben
• Software und die dazugehörigen Systemkonfigurationen können Sicherheitslücken enthalten, die es böswilligen Akteuren ermöglichen, unbefugten Zugriff auf die Plattformdaten zu erhalten

Zusammenfassung der Anforderungen

Geltend für alle Entwickler:

• Du musst die für die Verarbeitung von Plattformdaten eingesetzte Software mithilfe einer der folgenden Möglichkeiten auf Schwachstellen überprüft haben:

  • Eindringtest der App/des Systems oder
  • Prüfung auf Schwachstellen/statische Analyse der Software
• Das Ergebnis des Tests darf keine ungelösten kritischen oder hochgradigen Schwachstellen aufweisen
• Der Test darf nicht länger als 12 Monate zurückliegen

Zusätzliche Anforderungen an Entwickler, die Plattformdaten serverseitig verarbeiten:

• Insbesondere musst du serverseitige Software mithilfe einer der folgenden Methoden auf Schwachstellen überprüft haben:

  • Eindringtest der App/des Systems oder
  • Prüfung auf Schwachstellen/statische Analyse Du musst außerdem die Cloud-Konfiguration auf Sicherheitsprobleme getestet haben, wenn du einen Cloud-Hosting-Anbieter nutzt Diese Anforderung gilt unabhängig vom Hosting-Ansatz (z. B. BaaS, PaaS, IaaS, selbst-gehostet oder hybrid)

Nachweis-Leitfaden

Wenn du aufgefordert wirst, Nachweise für diese Schutzmaßnahmen zu erbringen, befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

Wenn die Organisation Plattformdaten in einer Cloud- oder Serverumgebung verarbeitet:

• Reiche einen Nachweis über einen Eindringtest oder über die Ausführung eines SAST-Tools ein. Der Nachweis muss Folgendes enthalten:

  • Eine Erklärung zum Umfang des Tests
  • Das Datum, an dem der Test abgeschlossen wurde – das Datum sollte nicht länger als 12 Monate zurückliegen
  • Eine Zusammenfassung oder eine Liste der im Rahmen des Tests erkannten Schwachstellen. Die Zusammenfassung oder Liste muss die Einstufung zum Schweregrad enthalten (z. B. kritisch, hoch, mittel, niedrig, informativ). Das Ergebnis des Tests sollte normalerweise keine ungelösten kritischen oder hochgradigen Schwachstellen aufweisen

• Sofern anwendbar (d. h. wenn du einen Cloud-Host wie AWS, GCP, Azure o. ä. nutzt), musst du einen Nachweis einreichen, dass die Überprüfung einer Cloud-Konfiguration durchgeführt wurde, beispielsweise das Ergebnis der Ausführung von NCC Scout Suite, AWS Config o. ä. Wenn dies für die Organisation nicht gilt, füge dem eingereichten Nachweis ein Dokument bei, in dem erläutert wird, warum keine Überprüfung der Cloud-Konfiguration anwendbar ist.
• Entferne oder zensiere sensible Informationen wie die genauen Reproduktionsschritte für die Schwachstelle aus dem Nachweis, bevor du ihn einreichst

Wenn die Organisation KEINE Plattformdaten in einer Cloud- oder Serverumgebung verarbeitet:

• Reiche einen Nachweis über einen Eindringtest oder über die Ausführung eines SAST-Tools ein. Der Nachweis muss Folgendes enthalten:

  • Eine Erklärung zum Umfang des Tests
  • Das Datum, an dem der Test abgeschlossen wurde – das Datum sollte nicht länger als 12 Monate zurückliegen
  • Eine Zusammenfassung oder eine Liste der im Rahmen des Tests erkannten Schwachstellen. Die Zusammenfassung oder Liste muss die Einstufung zum Schweregrad enthalten (z. B. kritisch, hoch, mittel, niedrig, informativ). Das Ergebnis des Tests sollte normalerweise keine ungelösten kritischen oder hochgradigen Schwachstellen aufweisen.
• Entferne oder zensiere sensible Informationen wie die genauen Reproduktionsschritte für die Schwachstelle aus dem Nachweis, bevor du ihn einreichst

Beispielnachweis

Eindringtest – Eine Organisation gibt einen Eindringtest ihrer serverseitig ausgeführten Software, die mit Meta-APIs integriert ist und Plattformdaten verarbeitet, in Auftrag. Das prüfende Unternehmen schließt den Test ab und erstellt eine Zusammenfassung ähnlich der unten stehenden. Beachte die Anmerkungen in Rot. Sie heben hervor, dass das Datum der Testdurchführung vermerkt ist (darf nicht länger als 12 Monate zurückliegen) und dass eine Zusammenfassung der Ergebnisse der nicht behobenen kritischen/hochgradigen Schwachstellen am Ende des Tests (oder erneuten Tests, sofern zutreffend) vorliegt. Zensiere sensible Informationen (insbesondere die genauen Reproduktionsschritte für die Schwachstelle) im Bericht, bevor du ihn einreichst.

Statische Analyse – Wenn du einen anderen Ansatz nutzt, beispielsweise ein SAST-Tool, exportiere die Ergebnisse in ein Dokument, das das SAST-Ausführungsdatum und eine Liste der Ergebnisse, einschließlich Typ jedes Ergebnisses und Schweregrad/Kritikalität, umfasst.

Überprüfung der Cloud-Konfiguration

Ein Entwickler nutzt NCC Scout Suite mit dem standardmäßigen Regelsatz für seinen Cloud-Anbieter (in diesem Fall AWS), um die Cloud-Konfiguration auf Schwachstellen und Sicherheitsprobleme zu überprüfen. Das Tool gibt eine JSON-Datei mit den Ausführungsergebnissen aus. In diesem Beispiel finden sich mehrere Probleme, die mit dem Schweregrad „Gefahr“ gekennzeichnet sind und die der Entwickler überprüfen und beheben muss.

$ python3 scout.py aws –-no-browser
2022-08-22 11:39:38 localhost scout[76981] INFO Saving data to scoutsuite-report/scoutsuite-results/scoutsuite_results_aws-043954759379.js

$ cd scoutsuite-report/scoutsuite-results
$ tail -n +2 scoutsuite_results_aws-043954750000.js| jq '. | {last_run}' | pbcopy

{
  "last_run": {
    "ruleset_about": "This ruleset consists of numerous rules that are considered standard by NCC Group. The rules enabled range from violations of well-known security best practices to gaps resulting from less-known security implications of provider-specific mechanisms. Additional rules exist, some of them requiring extra-parameters to be configured, and some of them being applicable to a limited number of users.",
    "ruleset_name": "default",
    "run_parameters": {
      "excluded_regions": [],
      "regions": [],
      "services": [],
      "skipped_services": []
    },
    "summary": {
      "acm": {
        "checked_items": 4,
        "flagged_items": 2,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 2
      },
      "awslambda": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "cloudformation": {
        "checked_items": 11,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 11,
        "rules_count": 1
      },
      "cloudfront": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "cloudtrail": {
        "checked_items": 153,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 17,
        "rules_count": 9
      },
      "cloudwatch": {
        "checked_items": 2,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 2,
        "rules_count": 1
      },
      "codebuild": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "config": {
        "checked_items": 17,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1227,
        "rules_count": 1
      },
      "directconnect": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "dynamodb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ec2": {
        "checked_items": 760,
        "flagged_items": 108,
        "max_level": "danger",
        "resources_count": 44,
        "rules_count": 28
      },
      "efs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elasticache": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "elb": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 3
      },
      "elbv2": {
        "checked_items": 42,
        "flagged_items": 4,
        "max_level": "danger",
        "resources_count": 0,
        "rules_count": 5
      },
      "emr": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 0
      },
      "iam": {
        "checked_items": 801,
        "flagged_items": 27,
        "max_level": "danger",
        "resources_count": 87,
        "rules_count": 37
      },
      "kms": {
        "checked_items": 15,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 15,
        "rules_count": 1
      },
      "rds": {
        "checked_items": 1,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 27,
        "rules_count": 9
      },
      "redshift": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 6
      },
      "route53": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 3
      },
      "s3": {
        "checked_items": 121,
        "flagged_items": 34,
        "max_level": "warning",
        "resources_count": 7,
        "rules_count": 18
      },
      "secretsmanager": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 1,
        "rules_count": 0
      },
      "ses": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 4
      },
      "sns": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 7
      },
      "sqs": {
        "checked_items": 0,
        "flagged_items": 0,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 8
      },
      "vpc": {
        "checked_items": 271,
        "flagged_items": 211,
        "max_level": "warning",
        "resources_count": 0,
        "rules_count": 9
      }
    },
    "time": "2022-08-22 11:42:25-0400",
    "version": "5.11.0"
  }
}

Ein weiterer Ansatz für die Durchführung einer Überprüfung der Cloud-Konfiguration für Entwickler mithilfe des Amazon Web Services-Regelsatzes.

# Show that AWS Foundational Security Best Practices are enabled
$ aws securityhub get-enabled-standards                                                                                                            
{
    "StandardsSubscriptions": [
        {
            "StandardsSubscriptionArn": "arn:aws:securityhub:us-west-1:043954759379:subscription/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsArn": "arn:aws:securityhub:us-west-1::standards/aws-foundational-security-best-practices/v/1.0.0",
            "StandardsStatus": "READY"
        }
    ]
}

# Show that aggregator is configured for a representative region used to process Platform Data
$ aws securityhub list-finding-aggregators

$ aws securityhub get-finding-aggregator --finding-aggregator-arn '{REPLACE-WITH-FINDING-AGGREGATOR-ARN}'


# Demonstrate that the ruleset is running by fetching active findings and counting the number of lines of output
$ aws securityhub get-findings --query 'Findings[?RecordState==`ACTIVE`]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}' --output text | wc -l                                     

4876
# Demonstrate that there are no active critical severity findings
$ aws securityhub get-findings --query 'Findings[?Severity.Label==`CRITICAL`] | [?RecordState==`ACTIVE`] | [*][Title, GeneratorId]' --filters '{"GeneratorId":[{"Value": "aws-foundational-security","Comparison":"PREFIX"}]}'

[]

Zulässige alternative Schutzmaßnahmen

Wenn du ein funktionierendes Vulnerability Disclosure Program (VDP) betreibst, z. B. wenn du die BugCrowd- oder HackerOne-Plattform nutzt, kannst du dies statt eines Eindringtests oder einer Prüfung auf Schwachstellen als alternative Schutzmaßnahme angeben. Um dies zu belegen, musst du einen Nachweis über Folgendes einreichen:

• Es gibt keine Ausschlüsse vom Umfang des VDP, die für die Art deiner Verarbeitung von Plattformdaten relevant sind
• Es gibt eine laufende Forschung und Berichterstellung zu Schwachstellen für die vergangenen 12 Monate, was normalerweise durch mindestens einen gültigen Schwachstellenbericht pro Monat belegt wird
• Eingereichten (tatsächlichen) Schwachstellen wird ein Wert für den Schweregrad zugewiesen, z. B. über CVSS 3.1
• Schwachstellen werden innerhalb eines angemessenen Zeitraums behoben, normalerweise innerhalb von 90 Tagen nach dem Datum der Einreichung

In diesem Fall muss der Nachweis Folgendes beinhalten:

• Eine Erklärung zum Umfang und dazu, inwiefern er sich auf die Software bezieht, die zur Verarbeitung von Plattformdaten verwendet wird
• Einen Bericht zu den eigentlichen Einreichungen von Schwachstellen im Programm in den vergangenen 12 Monaten. Der Bericht sollte den Titel der Schwachstelle, das Datum der Einreichung, das Datum der Behebung (sofern behoben) und die Kategorie/den Wert des Schweregrads enthalten.

Meta-App-Geheimcode und Meta-API-Zugriffstoken schützen

Frage: Sind Meta-API-Zugriffstoken und Meta-App-Geheimcodes auf die folgenden beiden Arten geschützt?

1. Indem Meta-API-Zugriffstoken niemals auf Client-Geräten gespeichert werden, wo sie außerhalb der aktuellen App und des aktuellen Nutzers zugänglich sind.
2. Indem ein Data Vault (z. B. Vault von Hashicorp) mit separatem Schlüsselmanagement (Key Management Service, KMS) verwendet wird und dabei die Zugriffstoken bzw. Geheimcodes in einer Cloud-, Server- oder Datacenter-Umgebung gespeichert werden.

Absicht

App-Geheimcodes und Zugriffstoken bilden die Grundlage für die Sicherheit der Entscheidungen, die Meta-APIs bezüglich der auszuführenden Aktionen treffen. Unbefugte mit Zugriff auf die Anmeldeinformationen können sich als die tatsächlichen Entwickler ausgeben, Meta-APIs aufrufen und darin sämtliche Aktionen ausführen, die wir den jeweiligen Apps zugestanden haben (z. B. das Auslesen von Daten über die App-Benutzer).

• Du hast im Rahmen der Nutzung der Meta-Plattform Zugang zu vertraulichen Anmeldeinformationen. Dazu gehören im Einzelnen:

  • Zugriffstoken – Wenn eine App autorisiert wird, erhält die Software ein Zugriffstoken, das bei nachfolgenden API-Aufrufen verwendet werden kann.
  • App-Geheimcode – Meta teilt einen App-Geheimcode mit den Entwicklern und geht davon aus, dass nur vertrauenswürdige Personen (z. B. App-Administratoren) innerhalb der Organisation Zugang zu diesem Geheimcode haben.
• Wenn Unbefugte Zugriff auf die vertraulichen Anmeldeinformationen haben, können sie damit Meta-APIs aufrufen und diese nutzen, als ob sie du wären (dies wird auch als Token-Nachahmung bezeichnet). Dies führt zu unbefugtem Zugriff auf die Plattformdaten.
• Deshalb müssen Anmeldeinformationen vor unbefugten Zugriffen geschützt werden, um eine Nachahmung zu verhindern.

Zusammenfassung der Anforderungen

Zugriffstoken

1. Auf Client-Geräten – Meta-Zugriffstoken dürfen nicht von anderen Benutzern oder Prozessen gelesen werden können.
2. Serverseitig – Beim serverseitigen Verarbeiten oder Speichern von Meta-Zugriffstoken muss Folgendes sichergestellt sein:
1. Die Meta-Zugriffstoken müssen durch einen Data Vault (z. B. Vault von Hashicorp) mit separatem Schlüsselmanagement (Key Management Service, KMS) geschützt werden, bei dem der Zugriff auf den Entschlüsselungscode auf die Anwendung beschränkt ist.
2. Die Meta-Zugriffstoken dürfen nicht in Protokolldateien geschrieben werden.

App-Geheimcode– Einer der folgenden Punkte muss zutreffen:

1. Du gibst den App-Geheimcode niemals außerhalb einer gesicherten Serverumgebung weiter (beispielsweise wird er niemals über einen Netzwerkaufruf an einen Browser oder eine mobile App übermittelt oder wird nicht in den Code eingebettet, der an mobile oder native bzw. Desktop-Clients weitergegeben wird).
2. Oder: Du musst die App mit dem Typ Native/Desktop konfiguriert haben, damit API-Aufrufe, die den App-Geheimcode enthalten, von Meta-APIs zurückgewiesen werden.

Nachweis-Leitfaden

Wenn du aufgefordert wirst, Nachweise für diese Schutzmaßnahmen zu erbringen, befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

Reiche Dokumente ein, die sich auf die Richtlinie zum Schutz der Meta-API-Zugriffstoken und des Meta-Geheimcodes beziehen. Wenn die App Meta-Zugriffstoken serverseitig verarbeitet, lege Nachweise für deine Schutzmaßnahmen bei (z. B. Verwendung eines Vaults; Nachweis, dass Werte in einem verschlüsselten Format gespeichert werden; App-Konfiguration, die „appsecret proofs“ erfordert).

Beispielnachweis

Eine Organisation verwendet AWS Secrets Manager, um vertrauliche Daten, einschließlich des Meta-App-Geheimcodes, sicher zu speichern.

Eine Organisation hat seine Meta-App so konfiguriert, dass bei API-Aufrufen ein Nachweis für den App-Geheimcode erforderlich ist.

Zulässige alternative Schutzmaßnahmen

1. Wenn serverseitig gespeicherte Zugriffstoken nicht durch einen Data Vault oder über eine App-Verschlüsselung geschützt werden, hast du folgende Möglichkeiten:
1. Schütze den App-Geheimcode mit einem Vault oder durch App-Verschlüsselung, wenn der Schlüssel nur für die App zugänglich ist.
2. Konfiguriere die App außerdem so, dass alle API-Aufrufe an Meta „appsecret proof“ erfordern.
2. Wenn der oben genannte Ansatz 1 nicht möglich ist (d. h. „appsecret proof“ kann nicht angefordert werden, weil so bestimmte notwendige API-Aufrufe blockiert würden), wird Meta andere Funktionen berücksichtigen, mit denen du das Risiko einer nicht autorisierten Nutzung der Zugriffstoken verglichen mit dem Risiko des Missbrauchs gespeicherter Zugriffstoken beschränkst.

Reaktionsplan für Vorfälle bereithalten und die Systeme und Prozesse zur Vorfallsreaktion überprüfen

Frage: Testest du die Systeme und Prozesse, mit denen du auf einen Sicherheitsvorfall reagieren würdest (z. B. eine Datenschutzverletzung oder einen Cyberangriff), mindestens alle 12 Monate?

Absicht

Sicherheitsvorfälle treten früher oder später in jeder Organisation auf. Daher ist es wichtig, dass Organisationen im Voraus planen, welche Maßnahmen zur Eindämmung des Vorfalls, zur Kommunikation mit den Betroffenen, zur Wiederherstellung und zur Aufarbeitung ergriffen werden müssen.

• Wenn ein Sicherheitsvorfall eintritt, kann ein entsprechender Aktionsplan mit einem geschulten Team die Vorfallsdauer verkürzen und letztlich die Gefährdung der Plattformdaten begrenzen
• Auch wenn die verschiedenen Organisationen unterschiedlich auf Vorfälle reagieren, benötigen wir zumindest einen grundlegenden Reaktionsplan, der die wichtigsten Aktivitäten zur Erkennung, Reaktion, Wiederherstellung und Überprüfung sowie die zugewiesenen Rollen und Verantwortlichkeiten der Mitarbeiter enthält

Zusammenfassung der Anforderungen

Der Entwickler muss über Folgendes verfügen:

• Reaktionsplan für Vorfälle, der die Mindestkriterien von Meta erfüllt.
• Dieses Dokument muss (mindestens) Folgendes beinhalten: (1) Rollen und Verantwortlichkeiten, (2) Erkennung, (3) Schritte zur Reaktion gemäß den geltenden Rechtsvorschriften (z. B. Benachrichtigung über Datenpanne an zuständige Aufsichtsbehörden und betroffene Personen) und zur Behebung und (4) Prüfprozess in der Folge von Vorfällen
• Dokumentierte Belege dafür, dass der Reaktionsplan kürzlich getestet wurde (innerhalb der letzten 12 Monate) und dass alle darin genannten Personen daran teilgenommen haben

Nachweis-Leitfaden

Befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

• Reiche den Reaktionsplan für Vorfälle (ein oder mehrere Dokumente) ein. Er sollte folgende Themen behandeln: Rollen und Verantwortlichkeiten, Erkennung, Reaktion und Behebung sowie Prüfung nach Vorfällen

  • Wenn du keinen Reaktionsplan für Vorfälle hast, findest du im Internet viele hilfreiche Ressourcen, beispielsweise die Vorlage für einen Reaktionsplan für Vorfälle von Counteractive sowie Referenzen und weitere Informationen
• Reiche einen Nachweis ein, dass du den Plan in den vergangenen 12 Monaten getestet hast. Dieser Nachweis kann unterschiedliche Formen haben, sollte jedoch Folgendes beinhalten:

  • Beschreibung des Szenarios (z. B. Planübung als Reaktion auf Ransomware-Angriffe),
  • Datum des Tests
  • Rolle der einzelnen Teilnehmer und
  • Sofern Mitarbeiter, die unter Rollen und Verantwortlichkeiten im Plan erwähnt werden, nicht teilgenommen haben, jeweils eine entsprechende Begründung
• Zensiere sensible Informationen (z. B. personenbezogene Informationen wie Name und E-Mail-Adresse von Personen) in diesem Nachweis, bevor du den Beispielnachweis einreichst

Reaktionsplan für Vorfälle

Ein Entwickler hat aufgrund dieser Vorlage einen umfassenden Reaktionsplan für Vorfälle erstellt. Diese Abbildungen zeigen nur das Inhaltsverzeichnis, doch du findest den Link zur vollständigen Vorlage unten.

Sieh dir die vollständige Counteractive-Vorlage für einen Reaktionsplan für Vorfälle (docx-Format) an

Test zur Vorfallsreaktion

Ein Entwickler hat einen Test seines Reaktionsplans für Vorfälle mittels einer Planübung durchgeführt und die Ergebnisse anhand dieser Vorlage dokumentiert.

Erfordernis einer Multi-Faktor-Authentifizierung für den Fernzugriff

Frage: Ist eine Multi-Faktor-Authentifizierung erforderlich für den Fernzugriff auf Konten, die sich mit der Cloud- oder Serverumgebung verbinden, und/oder um auf die Dienste zugreifen zu können, die du für die Bereitstellung, Wartung, Überwachung und den Betrieb der Systeme nutzt, auf denen die Plattformdaten von Meta gespeichert sind?

Absicht

Eine gängige Vorgehensweise von Angreifern, um sich Zugang zu vertraulichen Daten zu verschaffen, besteht darin, sich zunächst Zugang zu den Tools zu verschaffen, die der Entwickler für die Erstellung oder den Betrieb seiner App bzw. seines Systems verwendet. Es gibt eine Vielzahl raffinierter Tools, um Konten zu hacken, die nur durch Passwörter geschützt sind. Die Multi-Faktor-Authentifizierung bietet eine zusätzliche Sicherheitsebene zum Schutz vor diesem Risiko.

• Softwareentwickler verwenden für die Entwicklung, den Einsatz und die Verwaltung ihrer Apps bzw. Systeme eine Vielzahl von Tools.
• Es ist üblich, diese Tools aus der Ferne über das Internet zu nutzen (z. B. wenn ein Mitarbeiter von zu Hause aus arbeitet und eine neue Softwarefunktion ausliefert oder die Cloud-Konfiguration aktualisiert).
• Wenn diese Tools lediglich mit einer Ein-Faktor-Authentifizierung (Benutzername und Passwort) geschützt werden, sind sie sehr anfällig für Kontoübernahmeangriffe. Angreifer verwenden verschiedene Kombinationen von durchgesickerten Benutzernamen und Passwörtern, um sich mithilfe bestimmter Tools Zugang zu anderen Tools zu verschaffen.
• Die Multi-Faktor-Authentifizierung schützt vor solchen Angriffen, indem sie bei der Anmeldung neben dem Passwort einen zusätzlichen Faktor verlangt, z. B. einen von der Authentifizierungs-App generierten Code.

Zusammenfassung der Anforderungen

Im Zusammenhang mit der Verarbeitung von Plattformdaten durch die Organisation muss der Fernzugriff auf die folgenden Tools durch eine Mehrfaktor-Authentifizierung (d. h. nicht lediglich durch ein Passwort) geschützt werden:

• Tools für die Bereitstellung und Verwaltung von Code- und Konfigurationsänderungen an der App bzw. dem System
• Administrativer Zugang zu einer Cloud oder Serverumgebung, sofern zutreffend

Insbesondere ist die Multi-Faktor-Authentifizierung oder ein akzeptabler alternativer Schutz für die folgenden Bereiche erforderlich:

• Tools für die Zusammenarbeit und Kommunikation, wie beispielsweise geschäftliche E-Mails oder Slack
• Code-Repository wie beispielsweise GitHub oder ein anderes Tool, das verwendet wird, um Änderungen am Code oder an der Konfiguration der App bzw. des Systems zu verfolgen
• Bei einer serverseitigen Verarbeitung der Plattformdaten:

  • Software-Deployment-Tools: Tools zur Bereitstellung von Code in der Cloud oder Serverumgebung, wie beispielsweise Jenkins oder ein anderes CI/CD-Tool (Continuous Integration/Continuous Deployment)
  • Verwaltungstools: Portale oder andere Zugangslösungen für die Verwaltung bzw. Überwachung der Cloud oder Serverumgebung
  • Fernzugriff auf Server: SSH, Remote-Desktop oder ähnliche Tools zur Fernanmeldung bei Servern, die serverseitig laufen

Bezüglich der Implementierung der Multi-Faktor-Authentifizierung:

• Die Verwendung einer Authentifizierungs-App oder -Hardware (z. B. YubiKey) wird empfohlen und bevorzugt gegenüber per SMS gesendeten Codes.
• Organisationen können jedoch eine beliebige Multi-Faktor-Authentifizierung verwenden.

Nachweis-Leitfaden

Wenn du aufgefordert wirst, Nachweise für diese Schutzmaßnahmen zu erbringen, befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

• Der Implementierungsbeleg sollte bestätigen, dass für die oben aufgeführten Tools, die für die Umgebung gelten, eine Multi-Faktor-Authentifizierung durchgesetzt wird (z. B. Tools für die Zusammenarbeit, Code-Repository, Cloud/Server-Bereitstellung, Cloud/Server-Administrationsportal, Cloud/Server-Fernzugriff).
• Die Implementierung hängt von der jeweiligen Konfiguration ab:

  • Wenn du beispielsweise einen SSO-Anbieter nutzt, kann dies ein Screenshot der globalen Konfiguration für die Organisation oder ein Screenshot einer Pro-App-Konfiguration sein.
  • Wenn du keinen SSO-Anbieter nutzt, kann dies ein Screenshot der Konfiguration eines bestimmten Tools sein.
• In jedem Fall benötigen wir einen Nachweis, dass für alle Nutzer eine Multi-Faktor-Authentifizierung aktiviert ist – und nicht nur ein Beispiel für ein Konto mit aktivierter Multi-Faktor-Authentifizierung.

Beispielnachweis

AzureAD

Eine Organisation nutzt AzureAD als Single Sign-On-Lösung. Diese Richtlinie erfordert eine Multi-Faktor-Authentifizierung.

Die Richtlinie wird dann den Cloud-Anwendungen zugeordnet, für die sie gilt. Bei diesem Ansatz sollte der gesamte Abschnitt Ausgewählte Elemente angezeigt werden, um zu verdeutlichen, welche Cloud-Anwendungen eine Multi-Faktor-Authentifizierung erfordern.

Okta

Diese Regel erfordert für alle Anmeldungen eine Multi-Faktor-Authentifizierung.

AWS IAM

Das ist ein Beispiel für eine AWS IAM-Richtlinie, die die Konfiguration einer Multi-Faktor-Authentifizierung erlaubt, aber andere Aktionen verbietet, wenn keine Multi-Faktor-Authentifizierung verfügbar ist.

GitHub

Eine Organisation hat die GitHub-Authentifizierung so konfiguriert, dass für alle Mitarbeiter der Organisation eine Multi-Faktor-Authentifizierung erforderlich ist.

Zulässige alternative Schutzmaßnahmen

• Für jede Art von Fernzugriff, die in der Organisation verwendet wird, bei der aber keine Multi-Faktor-Authentifizierung erzwungen wird, solltest du beschreiben, ob du einen oder mehrere dieser Ansätze verwendest, um die Übernahme von Konten zu verhindern:

  • Anforderungen für starke Passwörter – z. B. eine Mindestanforderung an die Komplexität des Passworts, Verbot von Wörterbüchern, Verbot von Passwörtern, von denen bekannt ist, dass sie schon einmal geknackt wurden
  • Authentifizierungs-Backoff – Nutzung eines Tools, bei dem die Wartezeiten-Abstände zwischen fehlgeschlagenen Anmeldeversuchen von derselben Quelle immer länger werden.
  • Automatische Sperren – die Anmeldung bei einem Konto wird bei dieser Methode nach 10 fehlgeschlagenen Anmeldeversuchen automatisch gesperrt.

Einsatz eines Systems zur Verwaltung von Nutzerkonten

Frage: Verfügst du über ein System zur Verwaltung von Konten (Zuweisung, Widerruf und Überprüfung von Zugriffsrechten und Berechtigungen)?

Absicht

Ein ordentliches und gut geführtes Kontenmanagement zu haben ist ein wichtiger Aspekt dabei, eine unberechtigte Nutzung von Konten zum Erlangen des Zugriffs auf Plattformdaten zu verhindern. Vor allem müssen Entwickler sicherstellen, dass der Zugriff auf Ressourcen oder Systeme widerrufen wird, wenn er nicht mehr benötigt wird.

• Konten sind die grundlegende Verwaltungseinheit, um Personen Zugriff auf Systeme, Daten und Verwaltungsfunktionen zu gewähren.
• Konten werden mit Berechtigungen ausgestattet, die bestimmte Handlungen ermöglichen. Eine gute Praxis ist es, einem Konto nur das erforderliche Mindestmaß an Berechtigungen zu gewähren. Dies wird als Prinzip der minimalen Berechtigungsvergabe bezeichnet.
• Wenn eine Person aus einer Organisation ausscheidet, ist es von entscheidender Bedeutung, ihre Nutzerkonten umgehend zu deaktivieren, unter anderem aus den folgenden Gründen:

  • (1) Um den Zugriff durch die betreffende Person (d. h. den ehemaligen Mitarbeiter) zu verhindern und
  • (2) um die Wahrscheinlichkeit zu verringern, dass eine nicht autorisierte Person das Konto unbemerkt nutzen könnte. Ein böswilliger Akteur könnte beispielsweise mittels Social Engineering einen IT-Helpdesk dazu veranlassen, das Passwort für das Konto zurückzusetzen. Handelt es sich um das Konto eines aktuellen Mitarbeiters, wird dieser wahrscheinlich Probleme beim Anmelden bei seinem Konto melden. Handelt es sich hingegen um ein Konto, das noch aktiv ist, jedoch einem ausgeschiedenen Mitarbeiter gehört, ist es weniger wahrscheinlich, dass dies bemerkt wird.
• Aus diesem Grund müssen Organisationen über eine systematische Methode für die Verwaltung von Konten, die Erteilung von Berechtigungen und den Widerruf eines nicht mehr benötigten Zugriffs verfügen.

Zusammenfassung der Anforderungen

• Du musst über ein Tool oder Verfahren zur Verwaltung von Konten für jede(s) der folgenden Tools, Systeme und Apps verfügen:

  • Lösungen für die Kommunikation untereinander, z. B. Slack oder eine geschäftliche E-Mail-Adresse
  • Lösungen für die Auslieferung von Software, z. B. Code Repository und
  • Lösungen für die Verwaltung und den Betrieb des Systems (ggf. für die Verarbeitung von Plattformdaten)
• Du musst die Zugriffsberechtigungen regelmäßig (d. h. mindestens alle 12 Monate) überprüfen und über ein Verfahren verfügen, um den Zugriff zu widerrufen, wenn (1) er nicht mehr benötigt wird bzw. (2) nicht mehr genutzt wird.
• Außerdem musst du über ein Verfahren verfügen, mit dem der Zugriff auf diese Tools umgehend widerrufen werden kann, wenn eine Person die Organisation verlässt.
• Meta verlangt nicht,

  • dass irgendein bestimmtes Tool verwendet wird: Entwickler können ein Produkt aus dem Verzeichnis verwenden, wie Google Cloud Identity oder Microsoft Azure Active Directory, ein Cloudprodukt wie AWS Identity and Access Management (IAM) oder eine Tabelle, die regelmäßig aktualisiert wird;
  • dass es für alle diese unterschiedlichen Zugriffsarten nur ein einziges konsolidiertes Tool zur Verwaltung von Konten gibt.

Nachweis-Leitfaden

Befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

• Richtlinien / Verfahren: Stelle dokumentierte Richtlinien und Verfahrensdokumente zur Verfügung, aus denen die Kontenverwaltungspraktiken hervorgehen. Wir erwarten, dass dieses Dokument Verfahren für Folgendes enthält: Erstellung von Konten, Erteilung von Berechtigungen, Mindestkomplexität von Passwörtern, Richtlinie zur Sperrung von Konten, Richtlinie zur Multi-Faktor-Authentifizierung, Verfahren zum Zurücksetzen von Konten und ein Verfahren zum Widerrufen des Zugriffs nach einem Zeitraum der Inaktivität und wenn Personen die Organisation verlassen (z. B. wenn ein Mitarbeiter ausscheidet oder ihm gekündigt wird).
• Implementierungsnachweis: Stelle von mindestens einem der folgenden für die Verwaltung von Konten eingesetzten Tools oder Verfahren einen Nachweis bereit (oder kennzeichne es als nicht für die Umgebung zutreffend): (1) Geschäftliche E-Mail-Adresse und Tools für die Zusammenarbeit, (2) Code Repository, (3) Tools für die Cloud-/Server-Bereitstellung, (4) Cloud-/Server-Administrationsportal, (5) Cloud-/Server-Anmeldung aus der Ferne (z. B. SSH oder Remote Desktop). Füge für jedes einzelne Tool oder Verfahren einen Nachweis hinzu, der belegt, dass:

  • für Personen, die aus der Organisation ausgeschieden sind, ihr Zugriff auf diese Tools widerrufen wurde (z. B. ein Abstimmungsbericht, der die Nutzerkonten mit den maßgeblichen Daten aktueller Mitglieder der Organisation vergleicht);
  • ein für eine gewisse Zeit nicht genutzter Zugriff widerrufen wird (z. B. ein Bericht, aus dem hervorgeht, dass das letzte Zugriffsdatum eines repräsentativen Inhabers eines aktiven Nutzerkontos innerhalb der vergangenen 90 Tage liegt, wenn der maximale Inaktivitätszeitraum drei Monate beträgt).

Beispielnachweis

Richtlinien / Verfahren: Ein Entwickler hat einen Access Lifecycle Management-Standard erstellt, der Verfahren zum Erteilen, Überprüfen und Widerrufen von Zugriffsrechten umfasst.

Beispiel für die Implementierung – Zugriff wird für ausgeschiedene Mitarbeiter widerrufen

Ein Entwickler verwendet Workday als maßgebliche Quelle für Human Resources (HR)-Daten, u. a. für den aktuellen Beschäftigungsstatus. Dieser Entwickler nutzt Google Cloud Identity als Identitätsanbieter (IdP) für die Verwaltung von Nutzerkonten und die Erteilung von Zugriffsrechten auf Informationssysteme und -tools.

Ein Entwickler weist nach, dass die Zugriffsrechte für ausgeschiedene Mitarbeiter widerrufen werden, indem er einen Bericht einreicht, der belegt, dass ein kürzlich (d. h. innerhalb der vergangenen 12 Monate) durchgeführter Abstimmungsbericht ergeben hat, dass in Google Cloud Identity keine aktiven Nutzerkonten für Personen bestehen, die laut eines Workday-Berichts über aktuelle Mitarbeiter keine aktiven Mitarbeiter sind.

Beispiel für die Implementierung – Zugriff wird widerrufen, wenn er nicht mehr genutzt wird

Ein Entwickler nutzt Google Cloud Identity als Identitätsanbieter (IdP) für die Verwaltung von Nutzerkonten und die Gewährung des Zugriffs auf Informationssysteme und ‑tools.

Ein Entwickler weist nach, dass der Zugriff widerrufen wird, wenn er nicht mehr genutzt wird (wenn es z. B. in den vergangenen sechs Monaten keine Logins gegeben hat), indem er als Nachweis sein nach der letzten Anmeldung geordnetes Nutzerverzeichnis vorlegt, um zu belegen, dass es keine aktiven Nutzerkonten gibt, bei denen die letzte Anmeldung vor diesem Zeitraum lag.

Beispiel für die Implementierung – GitHub (Code Repository)

Ein Entwickler nutzt ein Single Sign On (SSO)-Tool für die Identitätsverwaltung und die Gewährung des Zugriffs auf Informationssysteme und ‑tools. Der Entwickler hat GitHub so konfiguriert, dass eine SSO-Authentifizierung erforderlich ist.

Software auf dem neuesten Stand halten

Frage: Verfügst du über ein System, um Systemcode und Umgebungen, einschließlich Servern, virtuellen Maschinen, Distributionen, Bibliotheken, Paketen und Antivirus-Software, auf dem neuesten Stand zu halten?

Absicht

Softwarekomponenten werden regelmäßig aktualisiert oder gepatcht, um Sicherheitsschwachstellen zu beheben. Irgendwann erreichen diese Komponenten jedoch das Ende ihrer Lebensdauer und werden nicht mehr unterstützt. Entwickler, die diese Komponenten in einem Paket einsetzen oder sich auf sie stützen, müssen sie auf dem neuesten Stand halten, um den Einsatz von Software mit bekannten Sicherheitslücken zu vermeiden.

• App-Entwickler greifen auf verschiedene Software von Drittanbietern zurück, um Apps bzw. Systeme zu betreiben, die Plattformdaten verarbeiten.
• Entwickler setzen beispielsweise häufig einige oder sämtliche der folgenden Komponenten ein:

  • Bibliotheken, SDKs, Pakete: Entwickler verpacken diese in ihren eigenen Code bei der Erstellung einer App.
  • Images von virtuellen Maschinen, App-Container und Betriebssysteme: Eine App läuft in einem oder mehreren dieser Container, die Services wie Virtualisierung und Zugriff auf Netzwerke und Speicher bereitstellen.
  • Browser, Betriebssysteme und andere von den Mitarbeitern / Mitwirkenden verwendete Anwendungen: Software, die auf den Mobilgeräten und Laptops läuft, die ein Entwickler für die Entwicklung und den Betrieb seines Systems verwendet.
• In diesen Komponenten werden regelmäßig Sicherheitslücken gefunden, für die entsprechende Patches veröffentlicht werden.
• Die durch Patches behobenen Schwachstellen werden danach in öffentlichen Datenbanken mit einer Bewertung des Schweregrads (niedrig, mittel, hoch oder kritisch) veröffentlicht.
• Daher müssen Entwickler, die die Meta-Plattform nutzen, eine systematische Methode zur Verwaltung von Patches einsetzen, indem sie

  • Patches identifizieren, die für ihre App bzw. ihr System von Bedeutung sind
  • Dringlichkeiten auf der Grundlage der Gefährdung priorisieren und
  • Patches im Rahmen der laufenden Geschäftsaktivität implementieren

Zusammenfassung der Anforderungen

Für die folgenden Softwarekomponenten musst du ggf. über ein festgelegtes und reproduzierbares Verfahren verfügen, um verfügbare Patches zur Behebung von Sicherheitsschwachstellen zu identifizieren, nach Risiko zu priorisieren und sie kontinuierlich anzuwenden:

1. Bibliotheken, SDKs, Pakete, App-Container und Betriebssysteme, die in einer Cloud oder Serverumgebung verwendet werden
2. Bibliotheken, SDKs, Pakete, die auf Client-Geräten verwendet werden, z. B. in mobilen Apps
3. Betriebssysteme und Apps, die von Mitgliedern zur Entwicklung und zum Betrieb der App bzw. des Systems verwendet werden, wie beispielsweise Betriebssysteme und Browser, die auf Mitarbeiter-Laptops laufen

Meta verlangt nicht die Verwendung irgendeines bestimmten Tools für diese Aktivitäten. Es ist üblich, dass eine Organisation unterschiedliche Ansätze verwendet, um verschiedene Arten von Software auf dem neuesten Stand zu halten (z. B. Bibliotheken, die in der App integriert sind, vs. Betriebssystem-Updates für Mitarbeiter-Laptops).

Das nachstehende Diagramm veranschaulicht für verschiedene Architekturarten, wo möglicherweise ein Patching erforderlich ist.

Nachweis-Leitfaden

Wenn du aufgefordert wirst, Nachweise für diese Schutzmaßnahmen zu erbringen, befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

Beginne mit der Identifizierung der in den Anwendungsbereich fallenden Softwarearten in der Umgebung, z. B. Bibliotheken, SDKs, Pakete, Images virtueller Maschinen, App-Container und Betriebssysteme, Browser, Betriebssysteme und andere von den Mitarbeitern / Mitwirkenden verwendete Anwendungen.

Dir hast möglicherweise ein Tool oder mehrere Tools, das/die du für folgende Aktivitäten nutzt:

• Bestand: Dokumentiere mit einem Screenshot oder Dokument, dass ein Tool oder Verfahren eingesetzt wird, das letztendlich eine Liste der in den Anwendungsbereich fallenden Bibliotheken, Pakete, SDKs, Container, App-Server und Betriebssysteme, die gepatcht werden müssen, darstellt. Es müssen Bestände für jedes Beispiel der Softwarearten (z. B. Cloud-App(s), Client-App(s), Mitarbeitergeräte) vorhanden sein.
• Identifizierung verfügbarer Softwarepatches: Es muss ein Tool oder Verfahren zur Identifizierung vorhandener Sicherheitspatches geben, die relevant für den Bestand sind.
• Priorisierung: Es muss ein Tool oder Verfahren geben (z. B. eine Tabelle zum Erfassen von Jira-Tickets und GitHub-Problemen), durch das den relevanten Patches eine Priorität zugewiesen wird.

  • Patching
  • Dokumentiere mit einem Screenshot oder Dokument, der/das belegt, dass die relevanten Patches nach ihrer Identifizierung und Priorisierung an die unterschiedlichen Zielorte verteilt werden.
• Integriere Richtlinien im Zusammenhang mit der zeitlichen Klärung und Nutzung von End-of-Life-(EOL)-Software.

Beispielnachweis

Snyk for a NodeJS-App: Entwickler verwenden die Schnittstelle Snyk Command Line Interface (CLI) zur Identifizierung von in Paketen gebündelten Drittanbieter-Abhängigkeiten, die bekannte Sicherheitsschwachstellen aufweisen, und zur Priorisierung aufgrund des Schweregrades dieser Schwachstellen.

NPM Audit

Entwickler nutzen NPM Audit, um Schwachstellen in den Abhängigkeiten zu finden, die in einer Node-App verwendet werden. Das nachstehende Beispiel-Image zeigt mehrere Schwachstellen mit hohem Schweregrad, die gepatcht werden müssen.

Trivy

Entwickler nutzten Trivy, um Schwachstellen in einem Maschinenimage zu finden. Das nachstehende Beispiel-Image zeigt Schwachstellen mit hohem Schweregrad in Bibliotheken in diesem Image, die gepatcht werden müssen.

Windows Server Update Services (WSUS)

Entwickler nutzen Windows Server Update Services (WSUS), um ihre Server und PCs / Laptops zu verwalten. Das nachstehende Beispielbild zeigt eine Admin-Ansicht des WSUS-Tools, mit dem die Überprüfung, Genehmigung und Nutzung von Windows-Updates möglich ist.

Ein System zur Protokollierung des Zugriffs auf Plattformdaten und zur Nachverfolgung, wohin Plattformdaten versendet und wo sie gespeichert werden, einsetzen

Absicht

Ohne zuverlässige Protokolldateien kann es für einen Entwickler schwierig bis unmöglich sein, unbefugten Zugriff auf Plattformdaten zu erkennen.

• Mithilfe von Audit-Protokollen kann eine Organisation aufzeichnen, dass ein Event aufgetreten ist, z. B. dass ein bestimmter Nutzer eine Abfrage von Datenbanktabellen mit Plattformdaten ausgeführt hat
• Diese Protokolle können Prozesse wie das Auslösen automatisierter Warnungen basierend auf verdächtigen Aktivitäten oder forensische Analysen nach Erkennung eines Sicherheitsvorfalls unterstützen

Zusammenfassung der Anforderungen

Wenn du Plattformdaten serverseitig verarbeitest, solltest du in dieser Umgebung Folgendes tun:

• Du solltest Audit-Protokolle führen, in denen wichtige Events erfasst werden (z. B. Zugriff auf Plattformdaten, Nutzung von Konten mit erweiterten Berechtigungen, Änderungen an der Audit-Protokollkonfiguration)
• Audit-Protokolle sollten in ein zentrales Repository konsolidiert und vor Änderung oder Löschung geschützt werden

Nachweis-Leitfaden

Wenn du aufgefordert wirst, einen Nachweis hochzuladen, sollte dieser belegen, dass:

• du über einen aktuellen Kenntnisstand darüber verfügst, wie die Plattformdaten gespeichert, aufgerufen und übermittelt werden, beispielsweise über ein aktuelles Datenflussdiagramm, das eine Gesamtansicht des Systems zeigt, Dienste benennt, die die Plattformdaten speichern, und die Eingangs- und Ausgangspunkte zeigt, einschließlich erwarteter Übermittlungen an irgendwelche Dienste von Viertparteien
• du manipulationssichere Audit-Protokolle implementiert hast
• Events in Bezug auf den Zugriff auf Plattformdaten in den Protokollen erfasst werden

Überwachen der Übermittlung von Plattformdaten und wichtiger Stellen, an denen Plattformdaten das System verlassen können (z. B. Drittanbieter, öffentliche Endpunkte)

Absicht

Zu verstehen, wie Plattformdaten verarbeitet werden sollen und dann die tatsächliche Verarbeitung zu überwachen, ist eine wichtige Möglichkeit für eine Organisation, um sicherzustellen, dass Plattformdaten nur für die beabsichtigten Zwecke verwendet werden

• Entwickler müssen stets über einen aktuellen Kenntnisstand darüber verfügen, wie die Plattformdaten gespeichert, über Netzwerke übermittelt und in Backups (die woanders repliziert werden können) gesichert werden
• Beispielsweise könnte die Überwachung Situationen identifizieren, in denen Plattformdaten in unerwarteter Weise oder, bei Übermittlung über ein Netzwerk, ohne geeignete Verschlüsselung während der Übermittlung übermittelt werden, sodass du Maßnahmen ergreifen kannst

Zusammenfassung der Anforderungen

Wenn du Plattformdaten serverseitig verarbeitest, solltest du in dieser Serverumgebung Folgendes tun:

• Ein genaues Datenflussdiagramm erstellen und pflegen, das zeigt, wo die Plattformdaten netzwerkübergreifend gespeichert, verarbeitet und übermittelt werden
• Bei Übermittlungen von Plattformdaten außerhalb des Systems eine Überwachung konfigurieren (z. B. Prüfprotokolle mit einem automatisierten Überwachungsprodukt)
• Wenn möglich, das Überwachungssystem so konfigurieren, dass es Warnhinweise generiert, die im Falle unerwarteter Übermittlungen von Plattformdaten umgehend überprüft werden (siehe auch die nachfolgende Anforderung – Einsatz eines automatisierten Systems für die Überwachung von Protokollen und anderen Sicherheitsereignissen und zum Generieren von Warnhinweisen bei ungewöhnlichen oder sicherheitsrelevanten Ereignissen)

Nachweis-Leitfaden

Wenn du aufgefordert wirst, Nachweise für diese Schutzmaßnahmen zu erbringen, befolge die Anweisungen im Abschnitt Erstellung von Nachweisen, um sowohl Richtlinien- bzw. Verfahrens- als auch Implementierungsnachweise zu erstellen.

Du solltest nachweisen, dass:

• du über einen aktuellen Kenntnisstand darüber verfügst, wie die Plattformdaten gespeichert und übermittelt werden bzw. Auskunft über sie erteilt wird; beispielsweise über ein aktuelles Datenflussdiagramm, das eine Gesamtansicht des Systems zeigt, Dienste benennt, die die Plattformdaten speichern, und die Eingangs- und Ausgangspunkte zeigt, einschließlich erwarteter Übermittlungen an irgendwelche Dienste von Viertparteien
• manipulationssichere Prüfprotokolle implementiert wurden
• Ereignisse im Zusammenhang mit Übermittlungen von Plattformdaten in den Protokollen erfasst werden; die Ereignisse sollten den Zeitpunkt, die Identität des Nutzers oder der App, der/die Handlung durchführt, und die Quelle und Destination enthalten

Einsatz eines automatisierten Systems für die Überwachung von Protokollen und anderen Sicherheitsereignissen und zum Generieren von Warnhinweisen bei ungewöhnlichen oder sicherheitsrelevanten Ereignissen

Absicht

Es ist unrealistisch, sich in einem modernen, über das Internet zugänglichen System bei der Überprüfung und Identifizierung von unerwartetem Verhalten auf Menschen zu verlassen. Stattdessen gibt es Tools, die Protokolldateien und andere Signale zur Generierung von Warnhinweisen erkennen können, die von Menschen näher untersucht werden müssen.

Zusammenfassung der Anforderungen

Wenn du Plattformdaten serverseitig verarbeitest, solltest du in dieser Serverumgebung Folgendes tun:

• Ein Tool einsetzen, das Protokolldateien und andere Ereignisse erkennen und Regeln aufstellen kann und das beim Auslösen Warnhinweise generieren sollte, sowie einen Mechanismus, der die Warnhinweise an Menschen weiterleitet (z. B. an einen Sicherheitsbeauftragten in Bereitschaft)
• Entsprechende Signale in das Tool einspeisen (z. B. Web-Zugriffsprotokolle, Authentifizierungsversuche, von Nutzern mit höheren Berechtigungen durchgeführte Handlungen)
• Im Laufe der Zeit die Regeln anpassen und verfeinern, um das Signal-Rausch-Verhältnis auszugleichen (beispielsweise, indem zu viele falsche Warnhinweise vermieden werden, aber auch keine Ereignisse ignoriert werden, die eine Untersuchung rechtfertigen)

Nachweis-Leitfaden

Ein Entwickler würde üblicherweise ein Security Information and Event Management (SIEM)-Tool für diesen Zweck einsetzen, wie z. B.:

• McAfee Enterprise Security Manager
• SolarWinds Security Event Manager
• Splunk Enterprise Security
• Sumo Logic

Du solltest nachweisen, dass die jeweiligen Signalquellen in das ausgewählte Tool weitergeleitet werden, dass Auslöser oder Alarmsignale bzw. Warnhinweise konfiguriert worden sind, dass die Warnhinweise an die Mitarbeiter weitergeleitet werden, die für weitere Bearbeitung zuständig sind, und schließlich, dass es ein Verfahren gibt, durch das die Alarmsignale regelmäßig angepasst werden (z. B. durch monatliche Überprüfungs- und Aktualisierungszyklen).

Glossar

A

Drittanbieter: In der Risikomanagementterminologie bezieht sich Drittanbieter auf die Entwickler auf der Meta-Plattform (Erstanbieter ist Meta selbst; Zweitanbieter sind die Personen, die die Produkte von Meta nutzen).

Viertanbieter: In der Risikomanagementterminologie bezieht sich Viertanbieter auf die Firmen, auf die sich Entwickler stützen, damit sie ihnen Dienstleistungen bereitstellen, die ihre Geschäftstätigkeit ermöglichen (Erstanbieter ist Meta, Zweitanbieter sind Metas Nutzer und Drittanbieter sind die Entwickler auf der Meta-Plattform).Zugriffsschlüssel: Anmeldeinformationen, wie ein Passwort, die es der Software gestatten, eine API anzurufen, damit sie eine bestimmte Aktion ausführt (z. B. Daten aus dem Profil eines Nutzers auslesen).

Amazon Web Services (AWS): Amazons Cloud-Computing-Services

App-spezifische ID (ASID): Eine eindeutige ID, die Meta generiert, wenn eine Person eine App nutzt. Mithilfe von ASIDs kann der Datenschutz für die Nutzer verbessert werden, indem es Datensätzen erschwert wird, Nutzer über verschiedene Apps hinweg in Beziehung zu setzen, da ein einziger Nutzer, der zwei Apps nutzt, unterschiedliche ASIDs in jeder App erhält.

App-Geheimcode: Ein gemeinsamer Geheimcode, den Meta Entwicklern über das App-Dashboard zur Verfügung stellt. Der Besitz des App-Geheimcodes berechtigt die Software, bestimmte Aktionen über die Graph API durchzuführen. Deshalb müssen Entwickler sehr vorsichtig sein, damit unberechtigte Parteien keinen Zugriff auf den App-Geheimcode erlangen können.

App-Kompromittierung: Wenn ein böswilliger Akteur über eine Fehlkonfiguration oder eine Schwachstelle in der App einer Organisation (z. B. eine Software-Schwachstelle in einer Web-App) unberechtigten Zugriff auf das interne Netzwerk dieser Organisation erlangt, wird dies als App-Kompromittierung bezeichnet. Das Durchführen von Eindringtests (Pentests) schützt vor einer App-Kompromittierung. Siehe auch Netzwerkkompromittierung.

Anwendungscontainer: Ein Container paketiert einen Softwarecode und die zugehörigen Abhängigkeiten, sodass die App auf verschiedenen Servertypen läuft (z. B. Server mit verschiedenen Betriebssystemen wie Linux oder Windows Server). Entwickler erstellen ein Container-Image, das ihre App paketiert. Eine Anwendungscontainer-Maschine oder ‑Runtime hostet das Container-Image bzw. führt es aus.

Anwendungsverschlüsselung: Eine Methode zum Schutz von Daten, bei der die Anwendungssoftware selbst die Verschlüsselungs- und Entschlüsselungsvorgänge durchführt. Im Gegensatz dazu verschlüsselt Transport Layer Security (TLS) die Daten während der Übermittlung nahtlos, wenn eine Anwendung eine sichere Verbindung zu einem Fernserver aufbaut (z. B. mittels HTTPS), und Cloud-Anbieter bieten Services für die transparente Verschlüsselung von ruhenden Daten an.

Anwendungsprogrammierschnittstelle (Application Programming Interface, API): Ermöglicht es zwei Computern, über ein Netzwerk miteinander zu kommunizieren; Beispiel: Eine mobile App ruft das heutige Wetter für einen bestimmten Ort von einem zentralisierten Wettervorhersagesystem ab.

Appsecret proof: Eine zusätzliche Sicherheitsebene für API-Aufrufe an Meta, bei der ein Entwickler einen Parameter generiert (den appsecret proof), der belegt, dass er den App-Geheimcode besitzt. Der appsecret proof ist das Ergebnis einer Hashing-Funktion (auch als Einwegfunktion bezeichnet), die auf dem App-Geheimcode und ‑Zugriffsschlüssel basiert. Indem eine App so konfiguriert wird, dass während Graph API-Aufrufen appsecret proofs erforderlich sind, wird der potenzielle Schaden reduziert, der durch eine Verletzung von Nutzerzugriffsschlüsseln verursacht wird, da diese Zugriffsschlüssel nicht ohne den zusätzlichen appsecret proof-Parameter verwendet werden können.

B

Backend-as-a-Service (BaaS): Eine Form von Cloud-Computing, die einem App-Entwickler eine Reihe von serverseitigen Funktionen bereitstellt, sodass sich der Entwickler darauf konzentrieren kann, das Frontend (d. h. den Teil einer App, mit dem die Nutzer interagieren) zu entwickeln. BaaS-Lösungen ähneln PaaS-Lösungen, bieten jedoch zusätzliche Services wie Nutzerauthentifizierung und mobile Push-Benachrichtigungen. Einige Beispiele für beliebte BaaS-Produkte: AWS Amplify, Azure Mobile Apps, Firebase und MongoDB Switch.

C

Ciphertext (Geheimtext): Ein Synonym für verschlüsselte Daten. Als Ciphertext werden Daten bezeichnet, die mithilfe eines bestimmten Verschlüsselungsalgorithmus unlesbar gemacht worden sind. Das Gegenteil von Ciphertext ist Plaintext (Klartext).

Clientseite: Üblicherweise interagieren die Menschen mit über das Internet zugänglichen Diensten, indem sie eine Website in einem Browser öffnen oder eine mobile App auf einem Telefon oder Tablet ausführen. Der Browser oder die mobilen Apps werden als lokale Clients oder Clientseite bezeichnet. Clients stellen über das Internet Anfragen von Remotecomputern (Servern) aus.

Cloud-Computing: Bezeichnet eine Form der Verwaltung von Servercomputern, Netzwerken und Speichern, durch die eine Organisation sich nicht um die physische Umgebung kümmern muss (es handelt sich also um ein mit Serverschränken und Netzwerkkabeln gefülltes Datacenter). Stattdessen kann die Organisation diese Assets im Bedarfsfall bereitstellen und für die Services zahlen, die sie nutzt.

Cloud-Konfiguration: Die Auswahl an Cloud-Computing-Optionen, die eine Organisation in Bezug auf ihren Einsatz eines Cloud-Anbieters festgelegt hat, der bestimmte Software einsetzt. Zur Cloud-Konfiguration gehören u. a. folgende Komponenten: Welche Arten von Netzwerkverbindungen gestattet oder blockiert sind, wo Protokolldateien geschrieben werden und wie lange sie aufbewahrt werden und diejenigen Nutzer, die autorisiert sind, Änderungen an der Cloud-Konfiguration vorzunehmen.

Ersatzmechanismen: Ein Sicherheitsmechanismus, der von einigen grundlegenden Anforderungen abweicht, aber dennoch einen vergleichbaren Schutz vor einem Risiko bietet.

D

Datenbank: Software, die das Speichern, Auslesen, Aktualisieren und Löschen beliebiger Daten ermöglicht. Datenbanken können sowohl auf Clients als auch auf Servern betrieben werden. Organisationen, die über eine Integration mit der Meta-Plattform verfügen, speichern Daten, die sie aus der Graph API abrufen, üblicherweise in einer Datenbank, die serverseitig läuft.

Entschlüsselung: Der Prozess, bei dem verschlüsselte Daten wieder zurück in ihr ursprüngliches Format umgewandelt werden. Mit anderen Worten, bei der Entschlüsselung wird aus Ciphertext (Geheimtext) Plaintext (Klartext).

E

Verschlüsselung: Der Prozess, bei dem Daten in ein Format umgewandelt werden, das für jeden, der es nicht entschlüsseln kann, nicht verwendbar ist. Mit anderen Worten wird bei der Verschlüsselung aus Plaintext (Klartext) Ciphertext (Geheimtext).

Verschlüsselung ruhender Daten: Daten, die bei ihrer dauerhaften Speicherung (z. B. auf einem Laufwerk) mittels Verschlüsselung geschützt worden sind. Die Verschlüsselung ruhender Daten bietet einen zusätzlichen Schutz vor nicht autorisiertem Zugriff, da ein Akteur, der die Rohdateien auf dem Speichergerät lesen kann, nur den Geheimtext sieht und ihn nicht entschlüsseln kann, sofern er nicht auch noch Zugriff auf den Entschlüsselungscode erlangen kann.

Verschlüsselung während der Übermittlung: Daten, die während ihrer Übermittlung über ein Netzwerk mittels Verschlüsselung geschützt worden sind. Die Verschlüsselung während der Übermittlung bietet Schutz vor Lauschangriffen entlang des Netzwerkpfades, da ein Akteur, der die Netzwerkpakete lesen kann, nur den Geheimtext sieht und ihn nicht entschlüsseln kann, sofern er nicht auch noch Zugriff auf den Entschlüsselungscode erlangen kann.

End-of-Life-(EOL)-Software: Wenn eine Organisation den Support für ein Softwareprodukt einstellt (z. B. das Erstellen von Patches zur Behebung von Sicherheitsschwachstellen ), gilt diese Software als EOL-Software. Da diese Software nicht mehr gewartet wird, ist es sehr riskant, irgendeine EOL-Software auszuführen.

G

Google Cloud Platform (GCP): Googles Cloud-Computing-Dienste.Graph API: Die gängigste Methode, mit der Apps Daten in den Meta Social Graph schreiben und daraus auslesen. Alle Meta-SDKs und ‑Produkte interagieren auf irgendeine Weise mit der Graph API.

H

Hashing-Funktion: Eine kryptographische Funktion, die beliebige Daten als Eingabe verwendet und einen kurzen Code ausgibt, der nicht wieder in die ursprüngliche Eingabe zurückverwandelt werden kann. In der Kryptographie werden Hashing-Funktionen zum Schutz von Daten wie Passwörtern eingesetzt: Anstatt das Passwort eines Nutzers als Klartext zu speichern, der gestohlen werden könnte, werden Passwörter zunächst mit einer Hash-Funktion umgewandelt und dann gespeichert. Zur Bestätigung, dass ein Nutzer das richtige Passwort eingegeben hat, nutzt das System später dieselbe Hash-Funktion, um die Eingabe umzuwandeln und den sich ergebenden Hash mit dem gespeicherten Wert zu vergleichen. Dies wird auch als Einwegfunktion bezeichnet, da der ausgegebene Hash nicht wieder in die ursprüngliche Eingabe zurückverwandelt werden kann.

Gehostete Umgebung: Bezieht sich auf die Remoteserver, Netzwerke und Speichergeräte, die eine Organisation in ihrem eigenen Datacenter oder in einem externen Datacenter gemeinsam mit anderen Kunden betreibt. Diese Konstellation ist heutzutage relativ unüblich, da das Cloud-Computing beliebter geworden ist.

I

Identitätsanbieter (IdP): Ein Cloud-Service, der für die Zentralisierung der Verwaltung digitaler Identitäten und zur Authentifizierung von Nutzern verwendet wird. Organisationen, die einen IdP nutzen, konfigurieren in der Regel Cloud-Apps so, dass sie sich für die Nutzerauthentifizierung auf den IdP stützen können. Die Organisation kann dann Nutzer verwalten, indem sie zentral über den IdP ausgewählte Apps erstellt, Zugriff auf sie gewährt und Nutzerkonten deaktiviert, anstatt dies immer wieder in jeder Cloud-App tun zu müssen.

Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM): Bezieht sich auf die Kategorie von Tools und Verfahren, die für die Verwaltung von Konten und die Gewährung des Zugriffs auf Systeme eingesetzt werden.

Infrastructure-as-a-Service (IaaS): Ein Cloud-Computing-Ansatz, bei dem Kunden Computing-, Speicher- und Networking-Services konfigurieren können, ohne selbst für die physischen Assets verantwortlich zu sein (z. B. Verwaltung eines mit Servern, Netzwerkgeräten und Speicher-Arrays gefüllten Datacenters). Im Vergleich zu PaaS erhalten Organisationen bei IaaS mehr Kontrolle über die Konfiguration ihrer Cloud-Assets, allerdings auf Kosten einer erhöhten Komplexität bei der Verwaltung dieser Assets. Einige Beispiele für beliebte IaaS-Produkte: AWS EC2, Microsoft Azure IaaS und Google Compute Engine.

L

Bibliothek: Bereits vorhandene Software-Bausteine, in der Regel von einem externen Unternehmen oder Entwickler, die für bestimmte Aufgaben in der App oder im System eines anderes Entwicklers genutzt werden. Bibliotheken erleichtern die Entwicklung von Apps, da Entwickler das Rad nicht neu erfinden müssen, wenn eine Bibliothek für eine bestimmte Funktion bereits existiert. Bibliotheken können jedoch Sicherheitslücken aufweisen oder selbst zusätzliche Bibliotheken hinzufügen, die solche Schwachstellen enthalten, sodass Entwickler, die Bibliotheken als Teil ihrer App nutzen, wissen müssen, welche Bibliotheken verwendet werden, und sie müssen sie stets auf dem neuesten Stand halten.

M

Mobile Client oder mobile App: Eine App, die eine Person aus einem mobilen App-Store (z. B. iOS App Store oder Google Play Store) auf einem Telefon oder Tablet installiert. Es ist üblich, dass Mobile Clients über das Internet mit der REST API einer Organisation und möglicherweise auch mit anderen Parteien kommunizieren (z. B. über das Facebook-SDK für Android mit der Graph API).

Multi-Faktor-Authentifizierung (MFA): Ein Authentifizierungsansatz, der mehr als einen Faktor verlangt, um Zugriff auf eine App oder ein System zu erlangen. Im Gegensatz zur Ein-Faktor-Authentifizierung, die sich zum Authentifizieren eines Nutzers lediglich auf ein Passwort stützt, verlangt die MFA in der Regel ein Passwort sowie zusätzlich mindestens eine dieser Optionen: Einen per E-Mail oder SMS versendeten Code, einen Code von einer Authentifizierungs-App, einen biometrischen Scan oder einen Sicherheitsstick. Die MFA schützt vor Kontoübernahmen, indem sie es nicht autorisierten Akteuren erschwert, in ein Konto einzudringen. Diese Akteure versuchen beispielsweise, sich unter Verwendung einer bekannten E-Mail-Adresse und üblicher Passwörter so lange bei einem Konto anzumelden, bis sie Erfolg haben.

N

Native Software: Apps, die heruntergeladen und auf Laptops oder Mobilgeräten installiert werden, werden als native Software bezeichnet (z. B. die Facebook-App für iOS). Eine in einem Browser ausgeführte App wird hingegen als Web-App bezeichnet (z. B. das Öffnen von Facebook im Chrome-Browser).

Netzwerkkompromittierung: Wenn ein böswilliger Akteur über eine Fehlkonfiguration oder eine Schwachstelle im Netzwerk selbst unberechtigten Zugriff auf das interne Netzwerk einer Organisation erlangt, wird dies als Netzwerkkompromittierung bezeichnet. Als Schutz vor einer Netzwerkkompromittierung kann ein Netzwerk-Scan durchgeführt werden, um Fehlkonfigurationen und Schwachstellen im mit dem Internet verbundenen Netzwerk zu identifizieren. Siehe auch unter „App-Kompromittierung“.

Netzwerk-Scan: Ein Risikomanagementverfahren, bei dem Software genutzt wird, um: (1) in einem Netzwerk aktive Server zu identifizieren, die auf aus der Ferne versendete Mitteilungen antworten, und anschließend (2) zu prüfen, ob irgendeiner dieser Server alte Softwareversionen einsetzt, die bekanntermaßen anfällig sind für eine oder mehrere Arten der Ausnutzung von Sicherheitslücken. Eine Organisation kann regelmäßig Netzwerk-Scans durchführen, um sicherzustellen, dass es beispielsweise keine unerwarteten offenen Ports in ihrer Netzwerkumgebung gibt.

Node Package Manager (NPM): Ein Tool, das von JavaScript-Entwicklern zur Beschleunigung der Entwicklung verwendet wird, indem es die Integration vorgefertigter Pakete in der App oder im System eines Entwicklers ermöglicht. NPM umfasst Funktionen zur Überprüfung der von einer App genutzten Pakete und zur Identifizierung von Paketen, die bekannte Sicherheitslücken enthalten.

O

Objektspeicher-Buckets: Eine Form der dauerhaften Speicherung in der Cloud, die Organisationen das dauerhafte Speichern von Dateien, einschließlich sehr großer Dateien, erleichtert, ohne dass sie sich Gedanken darüber machen müssen, physische Assets wie Speicherarrays zu skalieren oder wie sie diese Dateien in Backups sichern, um sicherzustellen, dass sie im Falle einer Katastrophe wie Feuer oder Überschwemmung nicht verloren gehen.

Betriebssystem: Die Software, die auf einem Computer oder Mobilgerät ausgeführt wird, und es den Anwendungen ermöglicht, die Prozessor-, Arbeitsspeicher-, Speicher- und Netzwerkressourcen dieses Computers zu betreiben bzw. zu nutzen. Beispiele: Microsofts Windows, Apples macOS oder iOS und Linux.

Organisationsmitglied: Jemand, der in einer Organisation eine Funktion innehat und Verantwortung trägt, z. B. ein Mitarbeiter, ein Auftragnehmer, ein befristet Beschäftigter, ein Praktikant oder ein Freiwilliger.

Organisationsgerät: Ein Computer oder Mobilgerät, das von einem Organisationsmitglied im Rahmen seiner Tätigkeit für die Organisation genutzt wird.

P

Abschnitt 6.a.i der Plattform-Nutzungsbedingungen: Bezieht sich auf Abschnitt (6), Überschrift (a), Absatz (i) der Meta-Plattform-Nutzungsbedingungen, in dem die Pflichten von Plattform-Entwicklern in Bezug auf die Datensicherheit beschrieben sind.

Paket: Synonym für Bibliothek.

Patch: Software-Updates, die Sicherheitsschwachstellen oder Fehler beheben oder neue Funktionen hinzufügen. Sämtliche Software wird gepatcht, einschließlich Betriebssystemen, Containern, Bibliotheken und SDKs.

Penetrationstest: Ein simulierter Angriff auf eine App oder ein System, bei dem der Tester versucht, Schwachstellen im Code oder in der Konfiguration zu finden, die von einem nicht autorisierten Akteur ausgenutzt werden könnten. Pentester verwenden ähnliche Tools wie Cyberkriminelle, um Erkundungen durchzuführen, nach potenziellen Schwachstellen zu suchen und solche Schwachstellen zu testen, die genutzt werden könnten, um unberechtigten Zugriff zu erlangen. Am Ende eines Pentests erstellen die Tester einen Bericht, in dem die Ergebnisse erläutert werden und der Schweregrad jeder Schwachstelle dargelegt wird. Die Organisation, die die Software pflegt, ist dann dafür verantwortlich, Lösungen zur Behebung der Schwachstellen zu entwickeln.

Plaintext (Klartext): Ein Synonym für unverschlüsselte Daten. Als Plaintext werden die Daten bezeichnet, die nicht durch Verschlüsselung geschützt worden sind. Platform-as-a-Service (PaaS): Ein Cloud-Computing-Ansatz, bei dem Kunden eine Anwendung auf einer Plattform einsetzen, die von dem Cloud-Anbieter verwaltet wird. Im Vergleich zu IaaS ist PaaS für Kunden einfacher zu verwalten, da nicht nur die physischen Assets (also die Server, Speichergeräte und Netzwerkgeräte) von dem Cloud-Host verwaltet werden, sondern auch das Betriebssystem und der Anwendungscontainer, auf denen die App des Kunden läuft. Einige Beispiele für beliebte PaaS-Produkte: AWS Elastic Beanstalk, Google App Engine, Force.com.

Port: Wenn ein Client über das Internet eine Verbindung zu einem Server herstellt, besteht die Zieladresse aus zwei Teilen: (1) einer Internetprotokoll-(IP)-Adresse für den Server und (2) einer Portnummer auf diesem Server, auf die eine bestimmte Anwendung antwortet. Gängige Protokolle nutzen reservierte Ports (Beispiel: HTTPS nutzt 443), aber Entwickler können bei Bedarf benutzerdefinierte Ports für die Netzwerkkommunikation nutzen.

R

REST API: Eine weit verbreitete Form der Gestaltung von über das Internet zugänglichen Diensten, bei denen der Client und der Server über das HTTP-Protokoll miteinander kommunizieren. Entwickler auf der Meta-Plattform könnten eine REST API auf einer Subdomain wie api.example.com hosten, an die ihre mobile App Plattformdaten sendet bzw. von der sie diese erhält.

S

Secure Shell (SSH): Ein Kommunikationsschema, bei dem sich Administratoren aus der Ferne bei Servern anmelden und Programme auf diesen Servern ausführen können. Es wird als sicher bezeichnet, da die Kommunikation zwischen dem Client und dem Server vor Lauschangriffen geschützt ist, anders als bei früheren Protokollen wie Telnet. Dies wird auch als Secure Socket Shell bezeichnet.

Secure Sockets Layer (SSL): Eine veraltete und unsichere Form der Verschlüsselung während der Übermittlung. Die moderne und sichere Version heißt Transport Layer Security (TLS).

Server: Ein Computer, der über ein Netzwerk Services aus der Ferne bereitstellt. Browser und mobile Apps kommunizieren mit den Servern über das Internet.

Serverloses Computing: Eine Form von Cloud-Computing, bei der der Cloud-Host die physische Infrastruktur, das Server-Betriebssystem und den Container verwaltet. Die Entwickler sind nur für den benutzerdefinierten Code und die zugehörigen Bibliotheken sowie die Cloud-Konfiguration verantwortlich.

Serverseite: Die Daten oder Berechnungen auf der anderen Seite einer Netzwerkverbindung (z. B. auf einem Server) werden als Serverseite bezeichnet. Die Daten oder Berechnungen auf einem lokalen Gerät wie einem Laptop oder Mobilgerät werden hingegen als Clientseite bezeichnet.

Single Sign-On (SSO): Ein Konzept, bei dem die Apps auf ein zentralisiertes Nutzerverzeichnis (d. h. einen IdP) vertrauen, um Nutzer zu authentifizieren. Zusätzlich zur Zentralisierung der Verwaltung von Nutzerkonten und App-Zugang für die Organisation, profitieren Nutzer, indem sie nur einen einzigen Satz an Zugangsdaten anstatt verschiedene Zugangsdaten (z. B. Benutzername und Passwort) für jede unterschiedliche App benötigen.

Software Development Kit (SDK): Ein Codebaustein, den Entwickler nutzen können, um den Entwicklungsprozess für ein bestimmtes Erfordernis zu vereinfachen. Meta erstellt und pflegt SDKs, die für iOS- und Android-Entwickler die Arbeit mit der Graph API vereinfachen. Ähnlich wie bei einer Bibliothek müssen Entwickler, die SDKs in ihren Apps verwenden, diese SDKs stets auf dem neuesten Stand halten.

Software-as-a-Service (SaaS): Ermöglicht Kunden die Nutzung von cloudbasierten Apps über das Internet. Anders als bei PaaS oder IaaS setzten Kunden einer SaaS-App keinen benutzerdefinierten Code ein und sind auch nicht für das Konfigurieren, Upgraden oder Patchen der SaaS-App verantwortlich, da alle diese Aufgaben in der Verantwortung des Anbieters der SaaS-Software liegen. Einige Beispiele für beliebte SaaS-Produkte: Dopbox, MailChip, Salesforce, Slack.

Statische Analysen: Siehe „Statische Anwendungssicherheitstests“.

Statische Anwendungssicherheitstests (SAST): Ein Ansatz zum Auffinden von Schwachstellen in Software, indem ein spezielles Tool über den Quellcode läuft. Ein SAST-Tool identifiziert potenzielle Schwachstellen, z. B. diejenigen, die im Projekt „OWASP Top 10“ aufgeführt sind. Der Entwickler ist dann dafür verantwortlich, die Ergebnisse zu prüfen, Richtig-Positive von Falsch-Positiven zu unterscheiden und Schwachstellen in der Software zu beheben. SAST-Tools können nützlich sein, da Entwickler mit ihrer Hilfe Schwachstellen entdecken können, bevor sie in die Produktion überführt werden, allerdings ist ein SAST-Tool im Gegensatz zu einem Penetrationstest nicht in der Lage, Schwachstellen im Zusammenhang mit der Produktionskonfiguration der App zu finden.

T

Transparente Datenverschlüsselung: Eine Form der Verschlüsselung ruhender Daten, die üblicherweise in der Datenbankspeicherung Anwendung findet (d. h. die Datenbankinhalte selbst und ihre Protokolldateien werden verschlüsselt). Bei diesem Konzept verwaltet die Datenbanksoftware die Verschlüsselungscodes und führt auf transparente Weise die Verschlüsselungstätigkeiten (bei Schreibvorgängen) und Entschlüsselungstätigkeiten (bei Lesevorgängen) durch.

Transport Layer Security (TLS): Eine Form der Verschlüsselung während der Übermittlung, die die Verschlüsselung verwendet, um die über Netzwerke übermittelten Daten entlang des Netzwerkpfades vor Lauschangriffen zu schützen. TLS ist die moderne sichere Form der veralteten früheren SSL-Technologie.

Zweistufige Authentifizierung (2Fac): Ein Synonym für die Multi-Faktor-Authentifizierung. Vault: Ein Managementsystem zur Verwaltung von Geheimcodes für sensible Daten wie Verschlüsselungscodes, Zugriffsschlüssel und andere Zugangsdaten. Vault ermöglicht eine strenge Kontrolle darüber, wer auf die enthaltenen Geheimschlüssel zugreifen kann und bietet zusätzliche Services wie das Führen von Prüfprotokollen.

V

Virtuelle Maschine (VM): Einem Anwendungscontainer sehr ähnlich – eine VM läuft jedoch auf einem Host (einem sogenannten Hypervisor), während ein Anwendungscontainer auf einer Containermaschine läuft. Der wichtigste Unterschied besteht darin, dass ein VM-Image ein Betriebssystem enthält, ein Anwendungscontainer jedoch nicht. Sowohl VMs als auch Anwendungscontainer enthalten Anwendung(en) und Abhängigkeiten wie Bibliotheken.

Virtual Private Cloud (VPC): Ein Begriff, der von AWS verwendet wurde, um auf eine Gruppe von Cloudressourcen zu verweisen, die einem traditionellen Netzwerk in einem Rechenzentrum in der Zeit vor dem Cloud-Zeitalter ähnelt.

Schwachstelle: Ein Fehler in einem System oder einer App, der ausgenutzt werden könnte, beispielsweise um Daten zu lesen, für die der Akteur ansonsten keine Leseberechtigung hätte.

Vulnerability Disclosure Program (VDP, Programm zur Aufdeckung und Offenlegung von Schwachstellen): Ein Ansatz, bei dem Organisationen Forscher (manchmal auch ethische Hacker genannt) mit der Erstellung von Berichten über Sicherheitslücken beauftragen, sodass die Schwachstellen aufgedeckt und behoben werden können, bevor böswillige Akteure sie ausnutzen. Ein effektives VDP erfordert Folgendes: Mehrere Forscher, die aktiv nach Schwachstellen suchen, Analysten in der Organisation zur Überprüfung und Einteilung (Triage) der eingehenden Meldungen und Ingenieure, die über gute Kenntnisse im Bereich Cybersicherheit verfügen und Lösungen zur Fehlerbehebung erstellen und einsetzen können.

Schwachstellen-Scan: Ein Ansatz, der Software einsetzt, um in Servern, Netzwerken und Apps nach Schwachstellen zu suchen. Im Vergleich zu einem Penetrationstest ist ein Schwachstellen-Scan kostengünstiger durchzuführen und kann deshalb wiederholt durchgeführt werden (z. B. monatlich oder vierteljährlich). Es ist jedoch bezeichnend, dass ein Pentest Schwachstellen findet, die ein Schwachstellen-Scan übersieht, da qualifizierte Penetrationstester analytische Fertigkeiten und Instinkte mitbringen, die sich mit rein automatisierten Ansätzen nur schwer nachbilden lassen. Siehe auch unter „Netzwerk-Scan“.

W

Web-App: Web-Apps sind Programme, die innerhalb von Browsern laufen und Ressourcen wie HTML-Dokumente, JavaScript-Code, Videos und andere Medien sowie CSS für die Gestaltung umfassen. Im Gegensatz zu einer mobilen App, die eine Person aus einem App-Store auf einem Mobiltelefon installiert, können Nutzer eine Web-App über ihren Browser von einem Remoteserver abrufen (z. B. www.facebook.com), ohne dass ein Installationsschritt erforderlich ist.