Persyaratan Keamanan Data

Mempersiapkan untuk Menjawab Pertanyaan Keamanan Data

Aliran Data

Buat (atau perbarui, jika diperlukan) diagram atau deskripsi aliran data yang menggambarkan bagaimana aplikasi atau sistem memproses Data Platform.

1. Sisi klien - Mencakup semua perangkat lunak klien seperti browser, perangkat seluler, dan tipe perangkat lain yang didukung.
2. Sisi server - Mencakup server atau lingkungan cloud terkait dan identifikasi:
1. Komponen tempat Data Platform:
1. Masuk atau keluar lingkungan server (mis., web listener dan REST API)
2. Ditulis untuk penyimpanan persisten dan tahan lama, seperti database, disk, atau file log
2. Model hosting, misalnya:
1. Hosting mandiri - Server milik organisasi yang dijalankan dalam pusat data yang dimiliki sendiri atau bersama.
2. Infrastructure as a Service (IaaS) - Seperti AWS EC2, Microsoft Azure IaaS, dan Google Compute Engine.
3. Platform as a Service (PaaS) - seperti AWS Elastic Beanstalk, Google App Engine, Force.com.
4. Backend as a Service (BaaS) - seperti AWS Amplify, Azure Mobile Apps, Firebase, dan MongoDB Switch.
5. Hybrid - beberapa kombinasi model di atas.

Pada akhirnya, diagram atau deskripsi aliran data harus menyertakan:

1. Tempat token akses Meta API dibuat dan ditransmisikan / disimpan / diperbarui, baik di perangkat lunak klien dan server (jika berlaku terhadap desain sistem)
2. Bagaimana Anda mengambil Data Platform dari API Meta, khususnya berfokus pada Informasi Identifikasi Pribadi (PII) seperti nama orang, alamat email, jenis kelamin, tanggal lahir, dan data pengguna lainnya
3. Bagaimana Anda menggunakan, menyimpan, dan mengirimkan data
4. Pihak keempat mana pun tempat Data Platform dikirim

Mempersiapkan Bukti

Anda mungkin diminta untuk mengirimkan bukti untuk mendukung jawaban terkait perlindungan keamanan data yang Anda terapkan. Kami menyarankan Anda membaca Panduan Bukti dalam dokumen ini untuk contoh bukti yang dapat diterima dan mempersiapkan bukti yang sesuai. Kami menerima jenis file dokumen umum bersama dengan tangkapan layar dan rekaman layar. Pastikan file tidak dilindungi kata sandi. Anda dapat mengunggah beberapa file sekaligus, masing-masing maksimum 2 GB. Kami menerima .xls, .xlsx, .csv, .doc, .docx, .pdf, .txt, .jpeg, .jpg, .png, .ppt, .pptx, .mov, .mp4, .zip, dan .zipx.

Jenis-jenis Bukti

Untuk aplikasi yang diminta mengunggah bukti terkait perlindungan keamanan data, Meta memerlukan dua jenis dokumentasi yang berbeda:

1. Bukti Kebijakan atau Prosedur - Dokumen kebijakan atau prosedur yang menjelaskan pendekatan keamanan data untuk [perlindungan ini]
2. Bukti Penerapan - Bukti dari sistem atau aplikasi, seperti konfigurasi fitur atau tangkapan layar, yang menunjukkan cara Anda menerapkan perlindungan yang diberikan

Bukti Kebijakan atau Prosedur

Bukti kebijakan atau prosedur, kadang-kadang disebut sebagai kontrol administratif, adalah dokumentasi tertulis yang menjelaskan pendekatan untuk perlindungan keamanan data tertentu. Bentuk bukti ini dapat bervariasi – dapat berupa kutipan dari serangkaian kebijakan internal, sebagian atau seluruh halaman wiki internal, atau dokumen yang baru dibuat yang Anda gunakan untuk menjelaskan pendekatan jika Anda tidak memiliki pra-dokumentasi yang ada. Bagaimanapun, bukti kebijakan atau prosedur yang Anda unggah harus dengan jelas menjelaskan bagaimana pendekatan untuk perlindungan yang diberikan terkait dengan persyaratan Meta. Berikan hanya kebijakan atau bahasa yang relevan dan diperlukan untuk tinjauan keamanan Meta, atau gunakan kotak teks bebas yang terkait dengan pertanyaan untuk mengarahkan peninjau kami ke bagian yang relevan.

Bukti Penerapan

Bukti penerapan menggambarkan bagaimana Anda telah menerapkan kebijakan atau prosedur dalam praktik secara langsung melalui tangkapan layar atau perekaman layar. Karena developer yang berbeda memiliki konfigurasi yang berbeda, kami tidak dapat memberikan contoh untuk setiap skenario. Karena itu, bukti penerapan harus menunjukkan tingkat detail yang sama dengan contoh yang kami berikan sejauh mungkin.

Bukti Kelengkapan

Kami memahami bahwa mungkin terlalu membebani untuk menyiapkan bukti penerapan yang secara komprehensif menunjukkan penerapan perlindungan keamanan data yang diberikan. Dengan mengingat hal itu, Anda harus mengirimkan bukti sesuai dengan panduan di sini, dengan berhati-hati untuk mengedit informasi sensitif dari bukti sebelum mengirimkannya:

1. Bukti Kebijakan atau Prosedur harus dengan jelas memenuhi atau melampaui persyaratan Meta
1. Meta akan meninjau bukti kebijakan atau prosedur untuk pernyataan yang sesuai dengan persyaratan Meta untuk perlindungan yang diberikan.
2. Anda harus membubuhi keterangan pada dokumen untuk menyorot bagian yang relevan
3. Misalnya, relevan dengan perlindungan Aktifkan enkripsi TLS 1.2 atau lebih tinggi untuk semua koneksi jaringan tempat Data Platform ditransmisikan, bukti yang dapat diterima akan mencakup dokumen yang dengan jelas menyatakan:
1. Data Platform dari Meta tidak boleh dikirimkan melalui jaringan tidak tepercaya dalam format tidak terenkripsi
2. Semua web listener (mis., load balancer yang terhubung ke internet) yang menerima atau mengembalikan Data Platform akan dikonfigurasi sedemikian rupa sehingga TLS 1.2 diaktifkan
3. Semua web listener yang menerima atau mengembalikan Data Platform akan dikonfigurasi sedemikian rupa sehingga yang berikut ini dinonaktifkan: SSL v2, SSL v3, TLS 1.0, dan TLS 1.1
2. Bukti Implementasi harus menunjukkan satu atau lebih contoh penerapan setiap kebijakan atau prosedur
1. Anda harus mengunggah satu atau lebih dokumen, tangkapan layar, atau konfigurasi fitur yang menunjukkan bagaimana Anda telah menerapkan setiap perlindungan
2. Meta akan meninjau bukti penerapan untuk memastikannya selaras dengan bukti kebijakan atau prosedur
3. Misalnya, relevan dengan perlindungan Aktifkan enkripsi TLS 1.2 atau yang lebih baru untuk semua koneksi jaringan tempat Data Platform ditransmisikan, bukti yang dapat diterima akan mencakup laporan pengujian Qualys SSL untuk salah satu domain web yang dikonfigurasi sesuai dengan kebijakan atau prosedur.

Data Sensitif yang Harus Anda Redaksi dari Bukti

Jangan mengirimkan bukti yang mengandung salah satu dari nilai-nilai ini dalam bentuk yang dapat dibaca (tidak diedit). Jika Anda menggunakan editor gambar untuk tangkapan layar, letakkan kotak hitam di atas nilainya. Jika Anda menggunakan editor PDF, pastikan Anda mengedit teks dengan menggunakan fitur yang benar-benar menghapus nilai daripada sekadar menambahkan lapisan sambil mempertahankan teks (mis., fitur redaksi di aplikasi Pratinjau Apple).

• Data kesehatan
• Data keuangan
• Alamat IP
• Kata sandi, kredensial, dan token akses
• Kunci enkripsi
• Alamat Fisik
• Personally Identifying Information (PII) tentang individu alami (tidak termasuk bisnis atau organisasi perusahaan lainnya), karyawan atau afiliasi lain yang dapat mengidentifikasi individu tersebut secara langsung atau tidak langsung, seperti:

  • Nama
  • Alamat email
  • ID Pengguna
  • Tanggal lahir
  • Data lokasi
  • Data kesehatan
  • Identitas budaya, sosial, politik
  • Data yang dapat diidentifikasi dengan cara lain kepada individu dalam konteks bukti spesifik
• Langkah-langkah reproduksi terperinci untuk kerentanan (misalnya, dalam laporan uji penetrasi)
• Data yang diketahui atau seharusnya diketahui oleh developer berasal dari atau tentang anak-anak di bawah usia 13 tahun

Melindungi Data Platform yang Disimpan Sisi Server dengan Enkripsi Saat Istirahat

Pertanyaan: Apakah Anda menerapkan enkripsi saat istirahat untuk semua Data Platform yang disimpan di lingkungan cloud, server, atau pusat data?

Maksud

Enkripsi saat istirahat melindungi Data Platform dengan membuat data tidak dapat diuraikan tanpa kunci dekripsi terpisah. Hal ini memberikan lapisan perlindungan tambahan terhadap akses baca yang belum disahkan.

• Pada server atau di lingkungan cloud - tempat Data Platform yang terkait dengan semua pengguna aplikasi cenderung terkonsentrasi - enkripsi saat istirahat mengurangi risiko pelanggaran data.
• Misalnya, enkripsi saat istirahat akan melindungi terhadap ancaman seperti akses yang belum disahkan ke cadangan database, yang mungkin tidak dilindungi seketat database produksi itu sendiri

Ringkasan Persyaratan

Jika Anda menyimpan sisi server Data Platform:

• Anda HARUS melindungi data tersebut:

  • Dengan enkripsi saat istirahat, atau
  • Dengan perlindungan alternatif yang dapat diterima (lihat Perlindungan Alternatif yang Dapat Diterima)

• Khusus untuk jenis enkripsi yang digunakan:

  • Baik tingkat aplikasi (misalnya, perangkat lunak mengenkripsi/mendekripsi kolom tertentu dalam database) maupun enkripsi disk penuh dapat diterima
  • Meskipun kami merekomendasikan agar enkripsi standar industri (misalnya, AES, BitLocker, Blowfish, TDES, RSA) digunakan, kami tidak memerlukan algoritme atau panjang kunci tertentu

Jika developer TIDAK menyimpan sisi server Data Platform, persyaratan ini tidak berlaku.

Kasus Spesial

Penyimpanan Sisi Server menggunakan IaaS, Hosting Mandiri, atau Hosting Hybrid

Jika Anda menyimpan Data Platform menggunakan hosting IaaS (mis., AWS EC2, Microsoft Azure IaaS, dan Google Compute Engine), hosting mandiri, atau pendekatan hybrid, maka pertanyaan ini berlaku.

Penyimpanan Sisi Server menggunakan Produk SaaS, PaaS, atau BaaS

Namun, ada model hosting backend lain yang merupakan kasus khusus:

Jika Anda menyimpan Data Platform hanya melalui salah satu dari ini (dan tidak menggunakan IaaS, Self Hosting, atau Hybrid Hosting), pertanyaan ini tidak berlaku. Sebaiknya Anda menjelaskan hubungan ini di bagian Penyedia Layanan di DPA.

• BaaS - misalnya, AWS Amplify, Azure Mobile Apps, Azure Playfab, Google Firebase, dan MongoDB Switch
• PaaS - mis., AWS Elastic Beanstalk, Google App Engine, Force.com
• SaaS - mis., MailChimp atau Salesforce

Penyimpanan Sisi Server menggunakan Meta API

Jika Anda menyimpan Data Platform hanya melalui Meta API, misalnya menggunakan player.setDataAsync(), dalam SDK Instant Games, pertanyaan ini tidak berlaku.

Panduan Bukti

Jika Anda diminta mengirimkan bukti untuk perlindungan ini, ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

Contoh Bukti Penerapan

AWS RDS

AWS RDS - enkripsi saat istirahat dapat dikonfigurasi di AWS RDS, jadi developer harus memastikan bahwa opsi konfigurasi diatur untuk menerapkan perlindungan ini.

Untuk instance RDS representatif yang berisi Data Platform, gunakan fitur AWS CLI untuk mengambil konfigurasi StorageEncrypted-nya.

# 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 dienkripsi saat istirahat secara default. Anda dapat mengambil konfigurasi enkripsi saat istirahat untuk tabel menggunakan perintah ini.

$ 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 harus dikonfigurasi untuk menerapkan enkripsi saat istirahat. Untuk cluster representatif yang berisi Data Platform, gunakan perintah ini untuk mengambil konfigurasi StorageEncrypted.

$ 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

Bucket AWS S3 dapat dikonfigurasi untuk menerapkan enkripsi saat istirahat ke semua objek yang dibuat dalam bucket. Gunakan perintah ini untuk membuat daftar bucket dan mengambil konfigurasi untuk enkripsi bucket default.

$ 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

Lihat dokumentasi Microsoft tentang enkripsi saat istirahat di Azure yang relevan dengan penggunaan layanan mereka oleh organisasi.

Platform Google Cloud

Lihat dokumentasi Google tentang enkripsi saat nonaktif di Platform Google Cloud.

Perlindungan Alternatif yang Dapat Diterima

Jika Anda tidak menerapkan enkripsi saat istirahat di lingkungan sisi server, Anda mungkin melindungi Data Platform dengan cara alternatif yang masih dapat diterima. Dalam hal ini, Anda harus menjelaskan hal-hal berikut:

1. Sensitivitas Data Platform - Penyimpanan Data Platform tertentu dianggap berisiko lebih rendah atau lebih tinggi. Anda perlu meneliti atribut pengguna data platform spesifik mana yang disimpan di sisi server.
2. Kontrol yang Diterapkan untuk Mengurangi Kemungkinan Bahaya Tertentu
1. Kontrol untuk mencegah kompromi jaringan yang berisi Data Platform
2. Kontrol untuk mencegah kompromi aplikasi/sistem yang memiliki akses ke Data Platform
3. Kontrol untuk mencegah hilangnya media penyimpanan fisik (misalnya, perangkat penyimpanan jaringan yang dinonaktifkan) yang berisi Data Platform
4. Kontrol untuk mencegah hilangnya media penyimpanan fisik (misalnya, perangkat penyimpanan jaringan yang dinonaktifkan) yang berisi Data Platform
5. Kontrol untuk mencegah akses tidak sah ke backup cadangan penyimpanan yang berisi backup Data Platform
3. Kekuatan Bukti - pastikan untuk mencatat apakah perlindungan ini telah dievaluasi oleh auditor independen, misalnya sebagai bagian dari audit SOC2.

Melindungi Data Platform yang Disimpan di Perangkat Organisasi dan Media Portabel dari Kehilangan

Pertanyaan: Khususnya mengenai data yang disimpan di perangkat organisasi dan perangkat pribadi: Apakah Anda menerapkan enkripsi saat istirahat, atau apakah Anda memiliki kebijakan dan aturan untuk mengurangi risiko hilangnya data, untuk semua Data Platform yang disimpan di perangkat ini?

Maksud

Jika developer mengizinkan Data Platform pada perangkat seperti laptop karyawan atau penyimpanan portabel (mis., drive USB), data tersebut berisiko tinggi untuk diakses tanpa izin jika perangkat hilang atau dicuri. Developer harus mengambil langkah untuk membatasi risiko ini.

Ringkasan Persyaratan

• Untuk mengurangi risiko akses Data Platform yang tidak sah, Pengembang harus memiliki kontrol teknis (lebih disukai) atau kontrol administratif (tidak lebih disukai, tetapi dapat diterima) yang relevan dengan Data Platform pada perangkat organisasi (mis., laptop) dan media portabel.

  • Kontrol teknis - contoh kontrol teknis meliputi: 1) Mengizinkan hanya perangkat yang dikelola untuk terhubung ke jaringan perusahaan, 2) memberlakukan enkripsi disk penuh pada perangkat yang dikelola (mis. BitLocker), 3) Memblokir media yang dapat dipindahkan (mis. drive USB) agar tidak terhubung ke perangkat yang dikelola, 4) menggunakan teknologi Data Loss Prevention (DLP) pada perangkat yang dikelola.
  • Kontrol administratif - contoh kontrol administratif mencakup dokumentasi kebijakan tertulis dan pelatihan tahunan tentang cara yang dapat diterima untuk menangani Data Platform pada perangkat organisasi dan pribadi.

Panduan Bukti

Jika Anda diminta mengirimkan bukti untuk perlindungan ini, ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

Anda mungkin menggunakan salah satu atau keduanya dari: a) kontrol teknis (mis., enkripsi disk), atau b) aturan/kebijakan untuk mengurangi risiko kehilangan data untuk Data Platform yang disimpan di perangkat organisasi seperti laptop dan ponsel.

Kontrol teknis dapat mencakup:

• Memblokir perangkat yang tidak dikelola agar tidak terhubung ke layanan sensitif, seperti jaringan produksi
• Menerapkan enkripsi disk pada perangkat yang dikelola (mis., melalui BitLocker di Windows atau FileVault di Mac)
• Memblokir media portabel agar tidak digunakan (misalnya, drive USB) pada perangkat yang dikelola
• Menggunakan perangkat lunak DLP pada perangkat terkelola untuk memblokir penanganan Data Platform yang tidak tepat (mis., mengirimkannya dalam lampiran email)

Aturan/kebijakan dapat mencakup:

• Dokumentasi yang menjelaskan cara penanganan data yang dapat diterima dan tidak dapat diterima, secara umum, dan Data Platform secara khusus
• Mekanisme untuk membuat anggota organisasi mengetahui pedoman (mis., perjanjian kontrak sebagai syarat kerja, pelatihan, pengingat berkala melalui email)

Contoh Bukti

Sebuah organisasi mengklasifikasikan Data Platform dari Meta sebagai “data pribadi” sesuai standar klasifikasi datanya. Organisasi telah membuat Pedoman Penanganan Data dan mewajibkan semua personel untuk memahami dan mematuhi kebijakan ini.

Melindungi Data Platform yang Dikirim melalui Jaringan dengan Enkripsi saat Transit

Pertanyaan: Apakah Anda mengaktifkan protokol keamanan TLS 1.2 atau versi terbaru untuk semua koneksi jaringan yang melewati, atau menghubungkan, atau jaringan publik silang ketika Data Platform dikirim? Selain itu, apakah Anda memastikan bahwa Data Platform tidak pernah dikirim melalui jaringan publik dalam bentuk yang tidak dienkripsi (mis., melalui HTTP atau FTP) dan protokol keamanan SSL v2 dan SSL v3 tidak pernah digunakan?

Maksud

Platform Data yang dikirim melalui internet dapat diakses oleh siapa saja yang dapat mengamati traffic jaringan. Oleh karena itu, Data Platform harus dilindungi dengan enkripsi agar pihak yang tidak berwenang tidak dapat membaca data tersebut.

• Enkripsi saat transit melindungi Data Platform saat dikirimkan melalui jaringan yang tidak tepercaya (mis., internet) dengan membuatnya tidak dapat diuraikan kecuali untuk perangkat asal dan destinasi
• Dengan kata lain, pihak di tengah transmisi tidak akan dapat membaca Data Platform meskipun mereka dapat melihat traffic jaringan (ini juga disebut serangan man-in-the-middle)
• TLS adalah bentuk enkripsi yang paling umum saat transit karena merupakan teknologi yang digunakan browser untuk mengamankan komunikasi ke situs web seperti bank

Ringkasan Persyaratan

Baik apakah Anda memproses sisi server Data Platform atau tidak:

• Data Platform tidak boleh dikirimkan melalui jaringan tidak tepercaya dalam format tidak terenkripsi
• Untuk semua web listener (mis., load balancer yang terhubung ke internet) yang menerima atau mengembalikan Data Platform, Anda harus:

  • Mengaktifkan TLS 1.2 ke atas
  • Menonaktifkan SSL v2 dan SSL v3
• TLS 1.0 dan TLS 1.1 hanya dapat digunakan untuk kompatibilitas dengan perangkat klien yang tidak mendukung TLS 1.2+
• Meta merekomendasikan, tetapi tidak mengharuskan, bahwa enkripsi saat transit diterapkan pada transmisi Data Platform yang seluruhnya berada dalam jaringan pribadi, misalnya, dalam Virtual Private Cloud (VPC).

Tabel di bawah ini merangkum kebijakan enkripsi saat transit untuk berbagai jenis transmisi.

Panduan Bukti

Jika Anda diminta mengirimkan bukti untuk perlindungan ini, ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan. Cara langsung untuk menghasilkan bukti implementasi yang menunjukkan konfigurasi salah satu web listener web adalah dengan menggunakan alat Uji Server SSL Qualys.

• Jalankan alat Uji Server SSL Qualys terhadap satu atau beberapa web listener yang dikonfigurasi secara identik (termasuk yang dijalankan pada port tidak standar).
• Centang opsi "Jangan tampilkan hasil di papan" untuk mencegah hasil ditambahkan ke situs web Qualys. Cetak seluruh halaman hasil pengujian ke PDF Ulangi langkah di atas untuk semua web listener yang Anda kirimkan Data Platform ke/dari yang memiliki konfigurasi TLS berbeda

Contoh Bukti Penerapan

Ini adalah contoh hasil dari alat Uji Server SSL Qualys. Perhatikan anotasi merah di bagian Konfigurasi, yang merangkum versi SSL/TLS mana yang didukung. Catatan: contoh ini hanya mencakup dua halaman pertama tetapi Anda harus menyertakan hasil pengujian lengkap.

Perlindungan Alternatif yang Dapat Diterima

Anda mungkin melindungi Data Platform saat transit menggunakan jenis enkripsi yang berbeda selain TLS; ini mungkin dapat diterima jika pendekatan tersebut memberikan perlindungan yang setara. Dalam hal ini, Anda harus mengirimkan detail tentang enkripsi yang digunakan untuk ditinjau oleh Meta:

• Enkripsi simetris atau asimetris?
• Algoritme enkripsi (mis., AES, BitLocker, TDES, RSA)?
• Berapa panjang kunci minimal?

Menguji Aplikasi dan Sistem untuk Mendeteksi Kerentanan dan Masalah Keamanan

Pertanyaan: Apakah Anda menguji aplikasi dan sistem untuk kerentanan dan masalah keamanan setidaknya setiap 12 bulan? (Misalnya, apakah Anda melakukan uji penetrasi manual?)

Maksud

Developer harus menguji kerentanan dan masalah keamanan sehingga dapat ditemukan secara proaktif, yang idealnya mencegah insiden keamanan sebelum terjadi.

• Developer aplikasi yang menggunakan platform Meta untuk memproses Data Platform dengan perangkat lunak yang mereka tulis melalui aplikasi/sistem yang mereka konfigurasikan dan operasikan
• Perangkat lunak konfigurasi sistem mungkin berisi kerentanan keamanan yang dapat dieksploitasi oleh pelaku jahat, yang mengarah ke akses yang tidak sah ke Data Platform.

Ringkasan Persyaratan

Berlaku untuk semua developer:

• Anda harus sudah menguji perangkat lunak yang digunakan untuk memproses Data Platform guna mendeteksi kerentanan keamanan dengan melakukan:

  • Uji penetrasi aplikasi/sistem, atau
  • Pemindaian kerentanan/analisis statis perangkat lunak
• Output uji harus menunjukkan bahwa tidak ada kerentanan dengan severitas kritis atau tinggi yang belum terselesaikan
• Uji harus sudah diselesaikan dalam 12 bulan terakhir.

Persyaratan tambahan untuk developer yang memproses sisi server Data Platform:

• Anda harus sudah secara khusus menguji perangkat lunak sisi server untuk mendeteksi kerentanan keamanan dengan melakukan:

  • Uji penetrasi aplikasi/sistem, atau
  • Pemindaian kerentanan/analisis statis Anda juga harus sudah menguji konfigurasi cloud untuk mendeteksi masalah keamanan jika Anda menggunakan penyedia hosting cloud Persyaratan ini berlaku apa pun pendekatan hosting-nya (misalnya, BaaS, PaaS, IaaS, self-hosted, atau hybrid)

Panduan Bukti

Jika Anda diminta mengirimkan bukti untuk perlindungan ini, ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

Jika organisasi memproses Data Platform di lingkungan cloud atau server:

• Kirimkan bukti bahwa uji penetrasi atau eksekusi fitur SAST telah selesai. Bukti harus berisi:

  • Pernyataan tentang cakupan uji
  • Tanggal uji diselesaikan – tanggal harus dalam 12 bulan terakhir
  • Ringkasan ataupun daftar kerentanan yang ditemukan selama uji. Ringkasan atau daftar harus mencakup kategorisasi severitas (misalnya, kritis, tinggi, sedang, rendah, informasional). Biasanya, tidak boleh ada kerentanan dengan severitas kritis atau tinggi yang belum terselesaikan

• Jika berlaku (yaitu, jika Anda menggunakan host cloud seperti AWS, GCP, Azure, atau yang serupa), kirimkan bukti bahwa peninjauan konfigurasi cloud telah dilakukan, misalnya output dari menjalankan NCC Scout Suite, AWS Config, atau yang serupa. Jika ini tidak berlaku untuk organisasi, sertakan dalam pengiriman bukti dokumen yang menjelaskan alasan mengapa peninjauan konfigurasi cloud tidak berlaku.
• Hapus atau edit informasi sensitif seperti langkah reproduksi kerentanan terperinci dari bukti sebelum dikirimkan

Jika organisasi TIDAK memproses Data Platform di lingkungan cloud atau server:

• Kirimkan bukti bahwa uji penetrasi atau eksekusi fitur SAST telah selesai. Bukti harus berisi:

  • Pernyataan tentang cakupan uji
  • Tanggal uji diselesaikan – tanggal harus dalam 12 bulan terakhir
  • Ringkasan ataupun daftar kerentanan yang ditemukan selama uji. Ringkasan atau daftar harus mencakup kategorisasi severitas (misalnya, kritis, tinggi, sedang, rendah, informasional). Biasanya, tidak boleh ada kerentanan dengan severitas kritis atau tinggi yang belum terselesaikan.
• Hapus atau edit informasi sensitif seperti langkah reproduksi kerentanan terperinci dari bukti sebelum dikirimkan

Contoh Bukti

Uji Penetrasi - Sebuah organisasi menugaskan dilakukannya uji penetrasi terhadap perangkat lunak mereka yang menjalankan sisi server yang terintegrasi dengan Meta API dan memproses Data Platform. Perusahaan penguji menyelesaikan uji dan menghasilkan surat ringkasan seperti di bawah ini. Memberikan anotasi merah, yang menyoroti bahwa tanggal saat uji berlangsung dinyatakan (harus dalam 12 bulan terakhir) dan terdapat ringkasan temuan dengan severitas kritis/tinggi yang belum terselesaikan pada akhir uji (atau uji ulang, jika berlaku) . Harap edit informasi sensitif dari laporan (khususnya, langkah reproduksi kerentanan terperinci apa pun) sebelum mengirimkannya.

Analisis statis - Jika menggunakan pendekatan yang berbeda, misalnya fitur SAST, ekspor hasil ke dalam dokumen yang menyertakan tanggal dijalankannya SAST dan daftar temuan yang mencakup setiap jenis temuan dan tingkat severitas/kritisnya.

Peninjauan Konfigurasi Cloud

Developer memakai NCC Scout Suite yang menggunakan aturan default bagi penyedia cloud mereka (dalam hal ini, AWS) guna meninjau konfigurasi cloud mereka untuk mendeteksi kerentanan dan masalah keamanan. Alat ini menghasilkan file JSON yang berisi hasil run secara detail. Dalam contoh ini, terdapat sejumlah masalah yang ditandai sebagai severitas “Bahaya” yang perlu ditinjau dan diselesaikan oleh developer.

$ 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"
  }
}

Pendekatan lain untuk melakukan peninjauan konfigurasi cloud bagi developer yang menggunakan aturan Amazon Web Services.

# 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"}]}'

[]

Perlindungan Alternatif yang Dapat Diterima

Jika mengoperasikan Program Pengungkapan Kerentanan (Vulnerability Disclosure Program/VDP) yang berfungsi, misalnya, menggunakan platform BugCrowd atau HackerOne, Anda dapat menyajikan ini sebagai perlindungan alternatif, bukan uji penetrasi atau pemindaian kerentanan. Untuk menunjukkan ini, Anda harus mengirimkan bukti bahwa:

• Tidak ada pengecualian untuk cakupan VDP yang relevan dengan cara Anda memproses Data Platform
• Terdapat penelitian dan pelaporan kerentanan aktual yang sedang berlangsung dalam 12 bulan terakhir, biasanya ditunjukkan oleh setidaknya 1 laporan kerentanan yang valid per bulan
• Kerentanan yang dikirim (valid) diberi skor severitas, misalnya, menggunakan CVSS 3.1
• Kerentanan diselesaikan dalam waktu yang wajar, biasanya kurang dari 90 hari setelah tanggal pengiriman

Dalam hal ini, bukti harus mencakup:

• Pernyataan cakupan dan bagaimana hal tersebut saling terkait dengan perangkat lunak yang digunakan untuk memproses Data Platform
• Laporan pengiriman kerentanan aktual dalam program selama 12 bulan terakhir. Laporan harus menyertakan judul kerentanan, tanggal pengiriman, tanggal penyelesaian (jika diselesaikan), dan kategori/skor severitas.

Lindungi Rahasia Aplikasi Meta dan Token Akses API

Pertanyaan: Apakah token akses Meta API dan rahasia aplikasi dilindungi dengan kedua cara berikut?

1. Dengan tidak pernah menyimpan token akses Meta API di perangkat klien yang dapat diakses di luar aplikasi dan pengguna saat ini.
2. Dengan menggunakan brankas data (mis., Vault oleh Hashicorp) dengan layanan manajemen kunci (KMS) terpisah jika disimpan di lingkungan cloud, server, atau pusat data.

Maksud

Rahasia aplikasi dan token akses sangat penting untuk keamanan cara Meta API membuat keputusan tentang tindakan yang diizinkan. Jika pihak yang tidak berwenang mendapatkan akses ke kredensial ini, mereka dapat memanggil Meta API - meniru developer sebenarnya - dan mengambil tindakan apa pun yang telah kami berikan kepada aplikasi (misalnya, membaca data dari Meta API tentang pengguna aplikasi).

• Anda memiliki akses ke kredensial sensitif sebagai bagian dari penggunaan Platform Meta. Secara khusus:

  • Token Akses - Saat orang mengotorisasi aplikasi, perangkat lunak mendapatkan kredensial yang disebut token akses yang digunakan dalam panggilan API berikutnya
  • Rahasia Aplikasi - Meta membagikan rahasia aplikasi dengan developer dengan harapan bahwa hanya pihak tepercaya (misalnya, admin aplikasi) dalam organisasi yang memiliki akses ke rahasia ini
• Pihak yang tidak berwenang yang dapat membaca kredensial sensitif ini dapat menggunakannya untuk memanggil Meta API seolah-olah mereka adalah Anda (ini terkadang disebut peniruan identitas token) yang mengarah ke akses tidak sah ke Data Platform
• Oleh karena itu, kredensial ini harus dilindungi dari akses yang belum disahkan untuk mencegah penyamaran identitas

Ringkasan Persyaratan

Token Akses

1. Pada perangkat klien - Token akses meta tidak boleh ditulis sedemikian rupa sehingga pengguna atau proses lain dapat membacanya.
2. Sisi server - Jika Anda memproses atau menyimpan token akses Meta di sisi server, token akses tersebut:
1. Harus dilindungi menggunakan brankas data (mis., Vault oleh Hashicorp) dengan layanan manajemen kunci (KMS) terpisah dan di mana akses ke kunci deskripsi terbatas pada aplikasi
2. Tidak boleh ditulis ke file log

Rahasia Aplikasi - salah satu dari dua hal ini harus benar:

1. Anda tidak pernah mengekspos rahasia aplikasi di luar lingkungan server yang aman (misalnya, tidak pernah dikembalikan oleh panggilan jaringan ke browser atau aplikasi seluler dan rahasia tersebut tidak disematkan ke dalam kode yang didistribusikan ke klien asli/desktop atau seluler)
2. Atau Anda harus mengonfigurasi aplikasi dengan jenis Native/Desktop sehingga Meta API tidak lagi mempercayai panggilan API yang menyertakan rahasia aplikasi

Panduan Bukti

Jika Anda diminta mengirimkan bukti untuk perlindungan ini, ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

Sertakan dokumentasi tentang kebijakan untuk melindungi token akses Meta API dan rahasia aplikasi Jika aplikasi memproses token akses Meta sisi server, sertakan bukti yang menunjukkan perlindungan yang Anda ambil (mis., penggunaan brankas, yang menunjukkan bahwa nilai disimpan dalam file terenkripsi format, konfigurasi aplikasi untuk meminta bukti rahasia aplikasi).

Contoh Bukti

Organisasi menggunakan AWS Secrets Manager untuk menyimpan data sensitif secara aman, termasuk Rahasia Aplikasi Meta.

Organisasi telah mengonfigurasi aplikasi Metanya agar memerlukan bukti Rahasia Aplikasi untuk panggilan API.

Perlindungan Alternatif yang Dapat Diterima

1. Jika Anda tidak melindungi token akses yang disimpan di sisi server dengan brankas data atau melalui enkripsi tingkat aplikasi, Anda dapat:
1. Melindungi rahasi aplikasi dengan menggunakan vault atau enkripsi aplikasi tempat kuncinya hanya dapat diakses di aplikasi
2. Dan konfigurasikan aplikasi untuk memerlukan bukti rahasia aplikasi untuk semua panggilan API ke Meta
2. Jika pendekatan #1 di atas tidak memungkinkan (yaitu, tidak dapat memerlukan bukti rahasia karena akan memblokir panggilan API tertentu yang diperlukan), maka Meta akan mempertimbangkan kontrol lain yang Anda miliki untuk membatasi risiko penggunaan token akses yang tidak sah dibandingkan dengan risiko penyalahgunaan token akses yang disimpan

Miliki Rencana Respons Insiden dan Uji Sistem dan Proses Respons Insiden

Pertanyaan: Apakah Anda menguji sistem dan proses yang akan Anda gunakan untuk merespons insiden keamanan (mis., kebocoran data atau serangan siber) setidaknya setiap 12 bulan?

Maksud

Insiden keamanan terjadi pada semua perusahaan cepat atau lambat, sehingga penting bagi organisasi merencanakan sebelumnya tentang siapa yang perlu melakukan tindakan untuk mengatasi insiden tersebut, berkomunikasi dengan pemangku kepentingan, memulihkan dan belajar dari pengalaman.

• Jika insiden keamanan terjadi, menyiapkan rencana atau pedoman - dengan tim yang terdiri dari orang-orang yang terlatih tentang tindakan yang harus dilakukan - dapat mengurangi durasi insiden dan pada akhirnya membatasi pemaparan Data Platform
• Meskipun organisasi yang berbeda akan memiliki tingkat kecanggihan respons insiden yang berbeda, kami memerlukan setidaknya rencana dasar yang mencakup aktivitas utama - mendeteksi, bereaksi, memulihkan, dan meninjau bersama dengan personel yang diberi peran dan tanggung jawab

Ringkasan Persyaratan

Developer harus memiliki:

• Rencana respons insiden yang memenuhi kriteria minimal Meta.
• Dokumen ini harus mencakup (setidaknya): (1) peran dan tanggung jawab, (2) deteksi, (3) langkah untuk bereaksi sesuai dengan kewajiban hukum yang berlaku (misalnya, pemberitahuan pelanggaran data kepada otoritas pengawas dan subjek data yang relevan) dan pemulihan, dan (4) proses peninjauan pasca insiden
• Bukti terdokumentasi bahwa rencana tersebut telah diuji baru-baru ini (dalam 12 bulan terakhir) dan bahwa semua personel yang disebutkan dalam rencana tersebut berpartisipasi

Panduan Bukti

Ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

• Kirimkan rencana respons insiden (satu atau lebih dokumen). Itu harus berisi topik berikut: peran dan tanggung jawab, deteksi, reaksi dan pemulihan, dan tinjauan pasca insiden

  • Jika Anda tidak memiliki rencana respons insiden, ada banyak sumber informasi yang tersedia di internet yang dapat membantu, misalnya lihat template rencana respons insiden Counteractive dan Referensi dan Bacaan Tambahan
• Kirimkan bukti bahwa Anda telah menguji paket tersebut dalam 12 bulan terakhir. Bukti ini dapat mengambil bentuk yang berbeda, tetapi harus mencakup:

  • Deskripsi skenario (misalnya, latihan di atas meja sebagai respons terhadap serangan ransomware),
  • Tanggal saat pengujian berlangsung
  • Peran masing-masing peserta dan,
  • Jika salah satu personel yang disebutkan dalam bagian peran dan tanggung jawab rencana tidak berpartisipasi, pembenaran untuk masing-masing
• Edit informasi sensitif (misalnya PII seperti nama individu dan alamat email) dari bukti ini sebelum mengirimkannya Contoh Bukti

Rencana Respons Insiden

Developer telah membuat rencana respons insiden komprehensif berdasarkan template ini. Gambar-gambar ini hanya menggambarkan daftar isi tetapi ada tautan di bawah ini ke template lengkap.

Lihat Template rencana respons insiden counteractive lengkap (format docx)

Uji Respons Insiden

Developer telah melakukan pengujian rencana respons insiden mereka melalui latihan tabletop dan mendokumentasikan hasilnya berdasarkan template ini.

Memerlukan Autentikasi Multi-Faktor untuk Akses Jarak Jauh

Pertanyaan: Apakah Anda memerlukan autentikasi multi-faktor untuk akses jarak jauh ke setiap akun yang bisa terhubung ke lingkungan cloud atau server dan/atau untuk mengakses layanan yang Anda gunakan untuk melaksanakan, memelihara, memantau, dan mengoperasikan sistem tempat Anda menyimpan Data Platform dari Meta?

Maksud

Teknik umum yang digunakan oleh musuh untuk mendapatkan akses ke data rahasia adalah memulai dengan mendapatkan akses ke fitur yang digunakan developer untuk membuat atau mengoperasikan aplikasi/sistem mereka. Fitur canggih tersedia untuk meretas akun yang hanya dilindungi oleh kata sandi; autentikasi multi-faktor memberikan lapisan keamanan tambahan untuk melindungi dari risiko ini.

• Developer perangkat lunak menggunakan berbagai fitur untuk membuat, menyebarkan, dan mengelola aplikasi/sistem mereka
• Penggunaan fitur ini dari jarak jauh melalui internet (misalnya, seorang karyawan yang bekerja dari rumah dan mengirimkan fitur perangkat lunak baru atau memperbarui konfigurasi cloud) sudah umum
• Fitur yang dilindungi dengan autentikasi faktor tunggal (nama pengguna dan kata sandi) sangat rentan terhadap serangan pengambilalihan akun. Misalnya, penyerang dapat menggunakan alat untuk mencoba kombinasi nama pengguna dan kata sandi yang bocor dari satu fitur untuk mendapatkan akses ke fitur lain
• Autentikasi multi-faktor melindungi dari serangan semacam itu dengan meminta faktor tambahan selain kata sandi saat login, misalnya, kode yang dihasilkan oleh aplikasi autentikator

Ringkasan Persyaratan

Terkait dengan pemrosesan Data Platform organisasi, akses jarak jauh ke fitur ini harus dilindungi dengan autentikasi multi faktor (yaitu, bukan sekadar kata sandi):

• Fitur yang digunakan untuk menerapkan dan mengelola perubahan kode/konfigurasi ke aplikasi/sistem
• Akses administratif ke lingkungan cloud atau server, jika berlaku

Secara khusus, MFA atau perlindungan alternatif yang dapat diterima diperlukan untuk hal-hal berikut:

• Fitur kolaborasi/komunikasi - misalnya email bisnis atau Slack
• Repositori kode - misalnya, GitHub atau fitur lain yang digunakan untuk melacak perubahan pada kode/konfigurasi aplikasi/sistem
• Dan, jika Anda memproses sisi server data platform:

  • Fitur penyebaran perangkat lunak - fitur yang digunakan untuk menyebarkan kode ke lingkungan cloud/server, misalnya, Jenkins atau fitur Continuous Integration/Continuous Deployment (CI/CD) lainnya
  • Fitur administratif - portal atau akses lain yang digunakan untuk mengelola/memantau lingkungan cloud atau server
  • Akses jarak jauh ke server - SSH, desktop jarak jauh, atau fitur serupa yang digunakan untuk login jarak jauh ke server yang menjalankan sisi server

Tentang penerapan MFA:

• Penggunaan aplikasi atau perangkat keras autentikator (mis., YubiKey) direkomendasikan dan lebih disukai daripada kode yang dikirim melalui SMS
• Tetapi organisasi dapat menggunakan penerapan MFA apa pun

Panduan Bukti

Jika Anda diminta mengirimkan bukti untuk perlindungan ini, ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

• Bukti penerapan harus menunjukkan bahwa MFA diterapkan pada fitur yang berlaku untuk lingkungan yang tercantum di atas (yaitu, fitur kolaborasi, repositori kode, penyebaran cloud/server, portal administratif cloud/server, akses jarak jauh cloud/server)
• Penerapan akan bervariasi tergantung konfigurasi:

  • Misalnya, jika Anda menggunakan penyedia SSO, ini mungkin tangkapan layar konfigurasi global untuk organisasi atau tangkapan layar konfigurasi per aplikasi.
  • Jika Anda tidak memiliki penyedia SSO, ini mungkin tangkapan layar konfigurasi fitur tertentu
• Bagaimanapun, kami memerlukan bukti bahwa MFA diaktifkan untuk semua pengguna dan bukan hanya contoh akun dengan MFA diaktifkan

Contoh Bukti

AzureAD

Organisasi menggunakan AzureAD sebagai solusi Single Sign On mereka. Kebijakan ini memerlukan Autentikasi Multi Faktor.

Kebijakan tersebut kemudian dipetakan ke aplikasi cloud yang menerapkannya. Dengan menggunakan pendekatan ini, bukti harus menunjukkan seluruh bagian Item terpilih untuk memperjelas aplikasi cloud mana yang memerlukan MFA.

Okta

Aturan ini membutuhkan MFA untuk semua login.

AWS IAM

Ini adalah contoh kebijakan AWS IAM yang mengizinkan konfigurasi MFA tetapi melarang tindakan lain jika MFA tidak ada.

GitHub

Organisasi telah mengonfigurasi autentikasi GitHub untuk mewajibkan MFA bagi semua orang di organisasi.

Perlindungan Alternatif yang Dapat Diterima

• Untuk semua jenis akses jarak jauh yang ada di organisasi tetapi di mana MFA tidak diberlakukan, Anda harus menjelaskan jika Anda menggunakan satu atau beberapa pendekatan ini untuk mencegah pengambilalihan akun:

  • Persyaratan kata sandi yang kuat - Misalnya, kompleksitas kata sandi minimal, melarang kata-kata dalam kamus, melarang kata sandi yang diketahui telah dilanggar sebelumnya
  • Backoff autentikasi - penggunaan fitur yang memperkenalkan masa tunggu yang semakin lama di antara upaya login yang gagal dari sumber yang sama
  • Penguncian otomatis - Misalnya, mekanisme untuk secara otomatis memblokir login ke akun setelah 10 kali gagal login

Memiliki Sistem untuk Memelihara Akun Pengguna

Pertanyaan: Apakah Anda memiliki sistem untuk memelihara akun (menetapkan, mencabut, dan meninjau akses serta hak istimewa)?

Maksud

Memiliki kebersihan manajemen akun yang baik adalah bagian penting untuk mencegah penggunaan akun yang tidak berwenang untuk mendapatkan akses ke Data Platform. Secara khusus, developer harus memastikan bahwa akses ke sumber daya atau sistem dicabut ketika tidak lagi diperlukan.

• Akun adalah unit dasar manajemen untuk memberikan orang akses ke sistem, data, dan fungsi administratif
• Akun diberikan izin yang memungkinkan tindakan tertentu; praktik yang baik adalah memberikan hanya izin minimum yang dibutuhkan akun – hal ini disebut prinsip hak istimewa terkecil
• Saat seseorang keluar dari organisasi, akun pengguna mereka harus segera dinonaktifkan karena beberapa alasan:

  • (1) untuk mencegah akses oleh orang tersebut (yaitu, mantan karyawan), dan
  • (2) untuk mengurangi kemungkinan bahwa orang yang tidak berwenang dapat menggunakan akun tanpa diketahui. Misalnya, pelaku jahat dapat menggunakan manipulasi psikologis untuk menyebabkan divisi bantuan TI mereset sandi akun. Jika akun ini milik karyawan saat ini, karyawan tersebut kemungkinan besar akan melaporkan ketidakmampuannya untuk login, sedangkan jika akun tersebut masih aktif tetapi milik karyawan yang sudah keluar, kemungkinannya kecil untuk diketahui.
• Dengan pemikiran ini, organisasi harus memiliki cara sistematis untuk mengelola akun, memberikan izin atau hak istimewa, dan mencabut akses saat tidak lagi diperlukan.

Ringkasan Persyaratan

• Anda harus memiliki fitur atau proses untuk mengelola akun untuk setiap fitur/sistem/aplikasi berikut:

  • Yang digunakan untuk berkomunikasi satu sama lain, misalnya, Slack atau email bisnis
  • Yang digunakan untuk mengirimkan perangkat lunak, misalnya penyimpanan kode dan
  • Mengelola dan mengoperasikan sistem (sebagaimana berlaku untuk memproses Data Platform)
• Anda harus meninjau secara berkala (yaitu, minimal sekali setiap 12 bulan) pemberian akses dan memiliki proses untuk mencabut akses ketika: (1) tidak lagi diperlukan, dan (2) tidak lagi digunakan
• Anda juga harus memiliki proses untuk segera mencabut akses ke fitur ini ketika seseorang meninggalkan organisasi
• Meta tidak memerlukan

  • Bahwa setiap fitur tertentu digunakan – developer dapat menggunakan produk direktori seperti Google Cloud Identity atau Microsoft Azure Active Directory, produk cloud seperti AWS Identity and Access Management (IAM), atau menggunakan spreadsheet yang selalu diperbarui secara berkala.
  • Bahwa terdapat satu fitur terkonsolidasi untuk mengelola akun di berbagai jenis akses ini.

Panduan Bukti

Ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

• Kebijakan/prosedur - Menyediakan dokumen kebijakan dan prosedur terdokumentasi yang mencakup praktik pengelolaan akun. Dokumen ini harus berisi prosedur untuk membuat akun, memberikan izin, kompleksitas kata sandi minimum, kebijakan penguncian akun, kebijakan MFA, prosedur reset akun, dan proses untuk mencabut akses setelah periode tidak aktif dan ketika seseorang meninggalkan organisasi (misalnya, karyawan mengundurkan diri atau diberhentikan).
• Bukti Implementasi - Berikan bukti dari setidaknya satu dari fitur atau proses berikut yang tersedia untuk mengelola akun (atau dinyatakan tidak berlaku untuk lingkungan): (1) Email bisnis dan fitur kolaborasi, (2) Repositori kode, (3) Fitur penerapan cloud/server, (4) Portal administratif cloud/server, (5) Login jarak jauh cloud/server (misalnya, SSH atau desktop jarak jauh). Untuk fitur atau proses khusus yang bersifat representatif, sertakan bukti yang menunjukkan bahwa:

  • Orang yang telah meninggalkan organisasi telah dicabut aksesnya ke fitur-fitur ini (misalnya, laporan rekonsiliasi yang membandingkan akun pengguna dengan data otoritatif anggota organisasi saat ini)
  • Akses yang tidak digunakan selama beberapa waktu akan dicabut (misalnya, laporan yang menunjukkan bahwa tanggal akses terakhir dari perwakilan pemegang akun pengguna aktif adalah dalam 90 hari terakhir jika periode tidak aktif maksimumnya adalah tiga bulan)

Contoh Bukti

Kebijakan/prosedur - Developer telah membuat Standar Pengelolaan Siklus Masa Pakai Akses yang mencakup prosedur untuk memberikan, meninjau, dan mencabut akses.

Contoh Implementasi - Akses Dicabut untuk Personel yang Keluar

Developer menggunakan Workday sebagai sumber otoritatif untuk data Sumber Daya Manusia (SDM), termasuk status pekerjaan saat ini. Developer tersebut menggunakan Google Cloud Identity sebagai Penyedia Identitas (IdP) mereka untuk mengelola akun pengguna dan memberikan akses ke sistem dan alat informasi.

Developer mengirimkan bukti bahwa akses untuk personel yang keluar telah dicabut dengan mengirimkan laporan yang menunjukkan bahwa laporan rekonsiliasi terbaru (yaitu, dalam 12 bulan terakhir) telah dijalankan yang menunjukkan bahwa tidak ada akun pengguna aktif di Google Cloud Identity untuk orang yang bukan merupakan karyawan aktif menurut laporan karyawan saat ini di Workday.

Contoh Implementasi - Akses Dicabut Ketika Tidak Lagi Digunakan

Developer menggunakan Google Cloud Identity sebagai Penyedia Identitas (IdP) mereka untuk mengelola akun pengguna dan memberikan akses ke sistem dan alat informasi.

Developer mengirimkan bukti bahwa akses dicabut ketika tidak lagi digunakan (misalnya, tidak ada aktivitas login dalam 6 bulan terakhir) dengan mengirimkan bukti direktori pengguna mereka yang diurutkan berdasarkan login terakhir guna menunjukkan bahwa tidak ada akun pengguna aktif di mana login terakhir di lebih lama dari waktu tersebut.

Contoh Implementasi - GitHub (Repositori Kode)

Developer menggunakan alat Single Sign On (SSO) untuk manajemen identitas dan pemberian akses ke sistem dan fitur informasi. Developer telah mengonfigurasi GitHub untuk mewajibkan autentikasi SSO.

Selalu Perbarui Versi Perangkat Lunak Anda

Pertanyaan: Apakah Anda memiliki sistem untuk menjaga kode sistem dan lingkungan diperbarui, termasuk server, mesin virtual, distribusi, pustaka, paket, dan perangkat lunak antivirus?

Maksud

Komponen perangkat lunak diperbarui atau dipatching secara rutin untuk mengatasi kerentanan keamanan, dan pada akhirnya komponen ini akan mencapai akhir masa pakainya saat tidak lagi didukung. Developer yang mengemas atau mengandalkan komponen ini harus selalu mengikuti perkembangan untuk menghindari menjalankan perangkat lunak dengan kerentanan yang diketahui.

• Developer aplikasi mengandalkan berbagai perangkat lunak pihak ke-3 untuk menjalankan aplikasi/sistem yang memproses Data Platform
• Misalnya, developer akan mengandalkan beberapa atau semua ini:

  • Pustaka, SDK, Paket - developer mengemasnya dengan kode khusus mereka sendiri untuk membuat aplikasi
  • Gambar Mesin Virtual, kontainer aplikasi, dan sistem operasi - aplikasi berjalan di dalam satu atau beberapa kontainer ini, yang menyediakan layanan seperti virtualisasi dan akses ke jaringan dan penyimpanan
  • Browser, sistem operasi, dan aplikasi lain yang digunakan oleh karyawan/kontributor - perangkat lunak yang berjalan di perangkat seluler dan komputer laptop yang digunakan developer untuk membuat dan menjalankan sistem mereka
• Kerentanan keamanan secara rutin ditemukan di komponen ini, yang menyebabkan patch dirilis
• Kerentanan yang diperbaiki oleh patch kemudian diungkapkan dalam database publik dengan peringkat severitas (rendah, sedang, tinggi, atau kritis)
• Oleh karena itu, developer di platform kami harus memiliki cara sistematis untuk mengelola patch dengan

  • Mengidentifikasi patch yang relevan dengan aplikasi/sistem mereka
  • Memprioritaskan urgensi berdasarkan eksposur, dan
  • Menerapkan patch sebagai aktivitas bisnis yang berlangsung

Ringkasan Persyaratan

Untuk komponen perangkat lunak berikut, sebagaimana berlaku, Anda harus memiliki cara yang pasti dan dapat diulang untuk mengidentifikasi patch yang tersedia yang mengatasi kerentanan keamanan, memprioritaskan berdasarkan risiko, dan menerapkan patch sebagai aktivitas yang berlangsung:

1. Galeri, SDK, paket, kontainer aplikasi, dan sistem operasi yang digunakan di lingkungan cloud atau server
2. Galeri, SDK, paket yang digunakan pada perangkat klien, misalnya, dalam aplikasi seluler
3. Sistem operasi dan aplikasi yang digunakan oleh anggota untuk membuat dan mengoperasikan aplikasi/sistem mereka, misalnya, sistem operasi dan browser yang berjalan di laptop karyawan

Meta tidak memerlukan penggunaan fitur tertentu untuk aktivitas ini. Sudah umum bahwa organisasi akan menggunakan beragam pendekatan agar versi berbagai jenis perangkat lunak yang digunakannya selalu yang terkini (misalnya, galeri yang dikemas dengan pembaruan aplikasi vs sistem operasi untuk laptop karyawan).

Diagram di bawah ini mengilustrasikan di mana patching mungkin diperlukan untuk berbagai jenis arsitektur.

Panduan Bukti

Jika Anda diminta mengirimkan bukti untuk perlindungan ini, ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

Mulai dengan mengidentifikasi jenis perangkat lunak dalam lingkup di lingkungannya, misalnya, Galeri, SDK, Paket, citra Mesin Virtual, penampung aplikasi, serta sistem operasi, Browser, sistem operasi, dan aplikasi lainnya yang digunakan oleh karyawan/kontributor.

Anda mungkin memiliki satu atau beberapa fitur yang Anda gunakan untuk aktivitas berikut:

• Stok - dokumen melalui cuplikan layar atau dokumen yang merupakan fitur atau proses yang, pada akhirnya, mewakili galeri, paket, SDK, wadah, server aplikasi, dan sistem operasi dalam cakupan yang memerlukan patch. Harus ada stok untuk perwakilan jenis perangkat lunak (mis., aplikasi cloud, aplikasi klien, perangkat karyawan).
• Mengidentifikasi patch perangkat lunak yang tersedia - fitur atau proses harus ada untuk mengidentifikasi patch keamanan yang relevan dengan stok.
• Prioritas - perlu ada fitur atau proses (mis., tiket Jira, masalah GitHub, spreadsheet pelacakan) dengan patch yang relevan ditetapkan sebagai prioritas

  • Patching
  • Dokumen melalui cuplikan layar atau dokumen yang menunjukkan bahwa, setelah patch yang relevan diidentifikasi dan diprioritaskan, patch tersebut kemudian diluncurkan ke berbagai tujuan.
• Sertakan kebijakan seputar waktu untuk menyelesaikan dan menggunakan perangkat lunak End of Life (EOL).

Contoh Bukti

Snyk untuk aplikasi NodeJS - Developer menggunakan Command Line Interface (CLI) Synk untuk mengidentifikasi dependensi pihak ketiga dalam paket yang telah mengetahui kerentanan keamanan dan memprioritaskan berdasarkan tingkat severitas kerentanan tersebut.

Audit NPM

Developer menggunakan Audit NPM untuk menemukan kerentanan dalam dependensi yang digunakan dalam aplikasi Node. Contoh citra di bawah menunjukkan beberapa kerentanan severitas tinggi yang memerlukan patching.

Trivy

Developer menggunakan Trivy untuk menemukan kerentanan dalam citra mesin. Contoh citra di bawah menunjukkan kerentanan tingkat severitas tinggi di galeri yang disertakan dalam citra ini yang memerlukan patching.

Windows Server Update Services (WSUS)

Developer menggunakan Windows Server Update Services (WSUS) untuk mengelola perangkat server dan PC/laptopnya. Contoh citra di bawah ini menunjukkan tampilan admin fitur WSUS, yang memungkinkan untuk meninjau, menyetujui, dan menerapkan pembaruan Windows.

Miliki Sistem untuk Mencatat Akses ke Data Platform dan Menelusuri tempat Data Platform Dikirim dan Disimpan

Maksud

Tanpa file log yang andal, sulit bagi developer untuk mendeteksi akses tidak sah ke Data Platform.

• Log audit memungkinkan organisasi untuk merekam fakta bahwa suatu peristiwa terjadi, mis. bahwa pengguna tertentu mengeksekusi kueri terhadap tabel database yang berisi Data Platform
• Log ini lalu dapat mendukung proses seperti memicu peringatan otomatis berdasarkan aktivitas mencurigakan atau analisis forensik setelah insiden keamanan diidentifikasi

Ringkasan Persyaratan

Jika Anda memproses sisi server Data Platform, maka dalam lingkungan itu:

• Anda harus menyimpan log audit yang mencatat peristiwa penting (misalnya, akses ke Data Platform, penggunaan akun dengan izin yang lebih tinggi, perubahan konfigurasi log audit)
• Log audit harus dikonsolidasikan ke dalam repositori pusat dan dilindungi dari perubahan atau penghapusan

Panduan Bukti

Jika Anda diminta untuk mengunggah bukti, itu harus menunjukkan bahwa:

• Anda memiliki pemahaman terkini tentang bagaimana Data Platform disimpan, diakses, dan ditransfer, misalnya melalui diagram aliran data terkini yang menunjukkan tampilan keseluruhan sistem, menunjuk layanan yang menyimpan Data Platform, dan menunjukkan titik masuk dan keluar, termasuk transfer yang diharapkan ke layanan pihak ke-4 mana pun
• Anda telah menerapkan log audit tahan tamper
• Peristiwa yang terkait dengan akses data platform direkam dalam log

Memantau Transfer Data Platform dan Poin Utama di mana Data Platform dapat Keluar dari Sistem (mis., Pihak Ketiga, Endpoint Publik)

Maksud

Memahami bagaimana Data Platform diharapkan diproses, lalu memantau pemrosesan aktual adalah cara penting bagi organisasi untuk memastikan bahwa Data Platform hanya digunakan untuk tujuan yang dimaksudkan

• Developer perlu menjaga pemahaman terkini tentang bagaimana Data Platform disimpan, dikirim melalui jaringan, dan ditulis ke backup (yang dapat direplikasi di tempat lain)
• Misalnya, pemantauan dapat mengidentifikasi situasi di mana Data Platform sedang dikirim dengan cara yang tidak terduga atau jika sedang dikirim melalui jaringan tanpa enkripsi yang sesuai saat transit sehingga Anda dapat mengambil tindakan

Ringkasan Persyaratan

Jika Anda memproses sisi server Data Platform, di dalam lingkungan server tersebut Anda harus:

• Pertahankan diagram aliran data yang akurat yang menunjukkan di mana Data Platform disimpan, diproses, dan ditransmisikan melalui jaringan
• Mengonfigurasi pemantauan (misalnya, log audit dengan produk pemantauan otomatis) untuk transfer Data Platform di luar sistem
• Konfigurasikan, jika memungkinkan, sistem pemantauan untuk meningkatkan peringatan yang segera ditinjau jika terjadi transfer Data Platform yang tidak terduga (lihat juga persyaratan di bawah ini - Memiliki sistem otomatis untuk memantau log dan peristiwa keamanan lainnya, dan untuk menghasilkan peringatan untuk kejadian abnormal atau terkait keamanan)

Panduan Bukti

Jika Anda diminta mengirimkan bukti untuk perlindungan ini, ikuti petunjuk di bagian Menyiapkan Bukti untuk mengetahui cara menyiapkan bukti kebijakan/prosedur dan penerapan.

Anda harus memberikan bukti bahwa:

• Anda memiliki pemahaman terkini tentang bagaimana Data Platform disimpan, diakses, dan ditransfer, misalnya melalui diagram aliran data terkini yang menunjukkan tampilan keseluruhan sistem, menunjuk layanan yang menyimpan Data Platform, dan menunjukkan titik masuk dan keluar, termasuk transfer yang diharapkan ke layanan pihak ke-4 mana pun
• Log audit tahan tamper telah diterapkan
• Peristiwa yang terkait dengan transfer Data Platform direkam dalam log; peristiwa harus mencakup waktu, identitas pengguna atau aplikasi yang mengambil tindakan, serta sumber dan tujuan

Miliki Sistem Otomatis untuk Memantau Log dan Peristiwa Keamanan Lainnya, dan guna Menghasilkan Peringatan untuk Peristiwa yang Tidak Normal atau Peristiwa yang Berkaitan dengan Keamanan.

Maksud

Tidak realistis jika hanya mengandalkan manusia untuk meninjau dan mengidentifikasi perilaku tak terduga dalam sistem modern yang dapat diakses internet. Karenanya, terdapat fitur yang dapat menyerap file log dan sinyal lain untuk membunyikan alarm yang memerlukan investigasi lebih lanjut oleh manusia.

Ringkasan Persyaratan

Jika Anda memproses sisi server Data Platform, di dalam lingkungan server tersebut Anda harus:

• Memiliki fitur yang mampu menyerap file log dan peristiwa lainnya, menetapkan aturan yang akan membunyikan alarm jika terpicu, dan mekanisme untuk mengarahkan alarm ke orang (misalnya, investigator keamanan yang sedang bertugas)
• Menyerap sinyal yang relevan ke dalam fitur (misalnya, log akses web, upaya autentikasi, tindakan yang diambil oleh pengguna dengan hak akses yang lebih tinggi)
• Seiring waktu, menyesuaikan dan menyempurnakan aturan untuk menyeimbangkan sinyal dengan derau (misalnya, dengan menghindari terlalu banyak alarm palsu tetapi juga tidak mengabaikan peristiwa yang memerlukan penyelidikan)

Panduan Bukti

Pengembang biasanya akan mengadopsi fitur Security Information and Event Management (SIEM) untuk tujuan ini, misalnya:

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

Anda harus memberikan bukti bahwa sumber sinyal yang relevan benar-benar diarahkan ke fitur pilihannya, bahwa pemicu atau alarm telah dikonfigurasi, bukti bahwa alarm diarahkan kepada orang yang bertanggung jawab untuk menindaklanjuti, dan terakhir bahwa ada proses ketika alarm diatur secara berkala (misalnya, melalui tinjauan bulanan dan siklus pembaruan).

Glosarium

A

Pihak ketiga - dalam terminologi manajemen risiko, pihak ketiga mengacu pada developer di platform Meta (pihak pertama adalah Meta sendiri; pihak kedua adalah orang yang menggunakan produk Meta)

Pihak keempat - dalam manajemen risiko, pihak keempat mengacu pada perusahaan yang diandalkan developer untuk menyediakan layanan yang menjalankan bisnis mereka (pihak pertama adalah Meta, pihak kedua adalah pengguna Meta, dan pihak ketiga adalah developer di platform Meta) Token akses - kredensial, seperti kata sandi, yang memungkinkan perangkat lunak memanggil API untuk mengambil tindakan (mis., membaca data dari profil pengguna).

Amazon Web Services (AWS) - Serangkaian layanan komputasi cloud Amazon

ID Lingkup aplikasi (ASID) - pengidentifikasi unik yang dibuat Meta saat seseorang memilih untuk menggunakan aplikasi. ASID membantu meningkatkan privasi bagi pengguna dengan mempersulit set data untuk menghubungkan pengguna di seluruh aplikasi, karena satu pengguna yang menggunakan dua aplikasi akan memiliki ASID yang berbeda di setiap aplikasi.

Rahasia aplikasi - rahasia bersama yang disediakan Meta untuk developer melalui dasbor aplikasi. Kepemilikan rahasia aplikasi mengotorisasi perangkat lunak untuk mengambil beberapa tindakan melalui Graph API, jadi developer perlu berhati-hati agar pihak tanpa otorisasi tidak dapat mengakses rahasia aplikasi.

Pembobolan aplikasi - jika aktor jahat dapat memperoleh akses tidak sah ke jaringan internal organisasi melalui kesalahan konfigurasi atau kerentanan di dalam aplikasi mereka (mis., kerentanan perangkat lunak di aplikasi web), itu disebut pembobolan aplikasi. Perlindungan terhadap pembobolan aplikasi adalah dengan melakukan uji penetrasi pada aplikasi. Lihat juga pembobolan jaringan.

Kontainer aplikasi - kontainer mengemas kode perangkat lunak dan dependensi terkait sehingga aplikasi akan berjalan di berbagai jenis server (mis., server yang menjalankan sistem operasi yang berbeda seperti Linux atau Windows Server). Developer akan membuat gambar kontainer yang mengemas aplikasi mereka. Mesin kontainer aplikasi atau runtime menghosting (menjalankan) gambar kontainer.

Enkripsi aplikasi - metode untuk melindungi data di mana perangkat lunak aplikasi itu sendiri melakukan operasi enkripsi dan dekripsi. Sebaliknya, Transport Layer Security (TLS) dengan lancar mengenkripsi data dalam transit saat aplikasi menciptakan koneksi yang aman ke server jarak jauh (mis., menggunakan HTTPS) dan penyedia cloud menawarkan layanan untuk mengenkripsi data saat istirahat secara transparan.

Antarmuka Pemrograman Aplikasi (API) - memungkinkan dua komputer berbicara dengan satu sama lain melalui jaringan, misalnya aplikasi seluler mengambil cuaca hari ini untuk lokasi tertentu dari sistem ramalan cuaca terpusat.

Bukti rahasia aplikasi - lapisan keamanan tambahan untuk panggilan API ke Meta di mana developer membuat parameter (bukti rahasia aplikasi) yang menunjukkan bahwa mereka memiliki rahasia aplikasi. Bukti rahasia aplikasi adalah produk hashing (juga disebut fungsi satu arah) berdasarkan rahasia aplikasi dan token akses. Mengonfigurasi aplikasi untuk mengharuskan bukti rahasia aplikasi saat pemanggilan Graph API mengurangi potensi bahaya dari pelanggaran token akses pengguna, karena token akses tersebut tidak dapat digunakan tanpa parameter bukti rahasia aplikasi tambahan.

B

Backend as a Service (BaaS) - gaya komputasi cloud yang menyediakan serangkaian kemampuan server-side untuk developer aplikasi agar developer dapat fokus pada menciptakan frontend (yaitu bagian aplikasi yang berinteraksi dengan pengguna). Solusi BaaS serupa dengan PaaS dan, selain itu, menambahkan layanan seperti autentikasi pengguna dan notifikasi otomatis seluler. Misalnya, ini adalah beberapa produk BaaS populer: AWS Amplify, Azure Mobile Apps, Firebase, dan MongoDB Switch.

C

Teks tersandi - sinonim untuk data terenkripsi, teks tersandi adalah nama yang diberikan pada data yang telah dibuat tidak dapat dibaca melalui beberapa algoritma enkripsi. Kebalikan dari teks tersandi adalah teks terang.

Client side - orang biasanya berinteraksi dengan layanan yang dapat diakses dengan internet dengan membuka situs web di browser atau menjalankan aplikasi seluler di ponsel atau tablet. Browser atau aplikasi seluler disebut sebagai klien lokal atau client side. Klien membuat permintaan dari komputer jarak jauh (server) melalui internet.

Komputasi cloud - mengacu pada gaya pengelolaan komputer, jaringan, dan penyimpanan server sehingga organisasi tidak perlu khawatir tentang lingkungan fisik (yaitu pusat data penuh dengan rak server dan kabel jaringan). Sebaliknya, organisasi dapat menyediakan aset ini sesuai permintaan dan membayar layanan yang mereka gunakan.

Konfigurasi cloud - set opsi komputasi cloud yang telah ditetapkan oleh organisasi sehubungan dengan penggunaan mereka atas penyedia cloud yang menjalankan beberapa perangkat lunak. Contoh konfigurasi cloud mencakup jenis koneksi jaringan apa yang diizinkan atau diblokir, di mana file log ditulis dan berapa lama disimpan, dan set pengguna yang diotorisasi untuk membuat perubahan pada konfigurasi cloud.

Kontrol kompensasi - kontrol keamanan yang berbeda dari beberapa set persyaratan dasar tetapi dimaksudkan untuk memberikan perlindungan yang sebanding terhadap risiko.

D

Database - perangkat lunak yang memungkinkan data arbitrer disimpan, dibaca, diperbarui, dan dihapus. Database dapat berjalan di klien dan di server. Organisasi yang berintegrasi dengan platform Meta biasanya akan menyimpan data yang mereka ambil dari Graph API dalam database yang menjalankan server side.

Dekripsi - proses di mana data terenkripsi diubah kembali ke format aslinya. Dengan kata lain, dekripsi mengubah teks tersandi menjadi teks terang.

E

Enkripsi - proses di mana data diubah ke format yang tidak dapat digunakan oleh siapa saja yang tidak dapat mendekripsinya. Dengan kata lain, enkripsi mengubah teks terang menjadi teks tersandi.

Enkripsi saat istirahat - data yang sudah dilindungi dengan enkripsi saat ditulis ke penyimpanan tetap (mis., disk drive). Enkripsi saat istirahat memberikan lapisan perlindungan tambahan terhadap akses tidak sah karena aktor yang dapat membaca file mentah di perangkat penyimpanan akan melihat teks tersandi dan tidak akan dapat mendekripsinya kecuali mereka juga dapat memperoleh akses ke kunci dekripsi.

Enkripsi dalam transit - data yang sudah dilindungi dengan enkripsi saat dikirim melalui jaringan. Enkripsi dalam transit memberikan perlindungan terhadap penyadapan di sepanjang jalur jaringan karena aktor yang dapat membaca paket jaringan akan melihat teks tersandi dan tidak akan dapat mendekripsinya kecuali mereka juga dapat memperoleh akses ke kunci dekripsi.

Perangkat lunak End of Life (EOL) - saat organisasi memilih menghentikan dukungan (mis., membuat patch untuk mengatasi kerentanan keamanan) untuk produk perangkat lunak, perangkat lunak tersebut dianggap EOL. Karena perangkat lunak ini tidak lagi dipelihara, sangat berisiko untuk menjalankan perangkat lunak EOL.

G

Google Cloud Platform (GCP) - serangkaian Graph API layanan komputasi cloud Google - cara utama bagi aplikasi untuk membaca dan menulis ke grafik sosial Meta. Semua SDK dan produk Meta berinteraksi dengan Graph API dalam beberapa cara.

H

Fungsi hashing - fungsi kriptografi yang mengambil data sebagai input dan menghasilkan kode pendek yang tidak dapat dibalik menjadi input asli. Dalam kriptografi, fungsi hashing digunakan untuk melindungi data seperti kata sandi, alih-alih menyimpan kata sandi pengguna sebagai teks terang yang dapat dicuri, kata sandi pertama-tama diubah dengan fungsi hash lalu disimpan. Kemudian, untuk mengonfirmasi bahwa pengguna memasukkan kata sandi yang benar, sistem akan menggunakan fungsi hash yang sama untuk mengubah input dan membandingkan hash yang dihasilkan dengan nilai yang disimpan. Disebut juga sebagai fungsi satu arah karena hash output tidak dapat dibalik menjadi input asli.

Lingkungan yang di-hosting - mengacu pada set server jarak jauh, jaringan, dan perangkat penyimpanan yang dijalankan organisasi di pusat data mereka sendiri atau dalam pusat data kolokasi (atau colo) dengan pelanggan lain. Pengaturan ini relatif jarang di era modern karena komputasi cloud menjadi lebih populer.

I

Penyedia identitas (IdP) - layanan cloud yang digunakan untuk memusatkan manajemen identitas digital dan mengautentikasi pengguna. Organisasi yang menggunakan IdP biasanya mengonfigurasi aplikasi cloud untuk mengandalkan IdP untuk autentikasi pengguna. Organisasi kemudian dapat mengelola pengguna dengan membuat, memberikan akses ke aplikasi yang dipilih, dan menonaktifkan akun pengguna secara terpusat dalam IdP, bukan melakukannya berulang kali di setiap aplikasi cloud.

Manajemen Identitas dan Akses (IAM) - mengacu pada kategori fitur dan proses yang digunakan untuk mengelola akun dan memberikan akses ke sistem.

Infrastructure as a Service (IaaS) - pendekatan komputasi cloud yang memungkinkan pelanggan mengonfigurasi layanan komputasi, penyimpanan, dan jaringan tanpa bertanggung jawab sendiri atas aset fisik (mis., mengelola pusat data yang penuh dengan server, perangkat jaringan, dan array penyimpanan). Dibandingkan Paas, IaaS memberi organisasi lebih banyak kontrol atas konfigurasi aset cloud mereka, tetapi dengan lebih banyak kompleksitas dalam mengelola aset tersebut. Misalnya, ini adalah beberapa produk IaaS populer: AWS EC2, Microsoft Azure IaaS, dan Google Compute Engine.

L

Pustaka - blok bangunan perangkat lunak yang sudah ada sebelumnya, biasanya dari perusahaan atau developer eksternal, yang digunakan untuk menangani tugas tertentu dalam aplikasi atau sistem developer lain. Pustaka menyederhanakan pengembangan aplikasi karena developer tidak perlu membuat kembali wheel ketika pustaka sudah ada untuk fungsi tertentu. Namun, pustaka dapat memiliki kerentanan keamanan, atau dapat menyertakan sendiri pustaka tambahan yang memilikinya, sehingga developer yang menggunakan pustaka sebagai bagian dari aplikasi mereka perlu mengetahui pustaka apa yang digunakan dan menjaganya tetap terbaru dari waktu ke waktu.

M

Klien seluler atau aplikasi seluler - aplikasi yang diinstal seseorang di ponsel atau tablet dari toko aplikasi seluler (mis., iOS App Store atau Google Play Store). Sudah umum bagi klien seluler untuk berkomunikasi melalui internet dengan REST API organisasi dan juga dapat berkomunikasi dengan pihak lain (mis., ke Graph API melalui Facebook SDK untuk Android).

Autentikasi Multi-Faktor (MFA) - pendekatan autentikasi yang memerlukan lebih dari satu faktor untuk memperoleh akses ke aplikasi atau sistem. MFA, berbeda dengan autentikasi satu faktor yang hanya mengandalkan kata sandi untuk mengautentikasi pengguna, biasanya akan memerlukan kata sandi ditambah satu atau beberapa hal ini: kode yang dikirim melalui email atau SMS, kode dari aplikasi autentikator, pemindaian biometrik, atau kode keamanan. MFA melindungi dari pengambilalihan akun dengan mempersulit aktor tanpa otorisasi memaksa masuk ke akun, mis., dengan berulang kali mencoba login ke akun menggunakan alamat email yang diketahui dan kata sandi umum hingga berhasil.

N

Perangkat lunak native - aplikasi yang diunduh dan diinstal ke laptop atau perangkat seluler disebut sebagai perangkat seluler native (mis., aplikasi Facebook untuk iOS). Sebaliknya, aplikasi yang berjalan dalam browser disebut sebagai aplikasi web (mis., membuka Facebook menggunakan browser Chrome).

Pembobolan jaringan - jika aktor jahat dapat memperoleh akses tidak sah ke jaringan internal organisasi melalui kesalahan konfigurasi atau kerentanan di dalam jaringan itu sendiri, itu disebut pembobolan jaringan. Perlindungan terhadap pembobolan jaringan adalah menjalankan pemindaian jaringan untuk mengidentifikasi kesalahan konfigurasi dan kerentanan di dalam jaringan yang dapat diakses dari internet. Lihat juga pembobolan aplikasi.

Pemindaian jaringan - proses manajemen risiko yang menggunakan perangkat lunak untuk: (1) mengidentifikasi server aktif di jaringan yang akan menanggapi komunikasi jarak jauh, lalu (2) melihat apakah salah satu server tersebut menjalankan perangkat lunak versi lama yang diketahui rentan terhadap satu atau beberapa eksploitasi keamanan. Organisasi dapat menggunakan pemindaian jaringan secara berkala untuk memastikan bahwa tidak ada port terbuka yang tidak terduga di perimeter jaringan mereka, misalnya.

Node Package Manager (NPM) - sebuah fitur yang digunakan oleh developer JavaScript untuk mempercepat pengembangan dengan memungkinkan paket yang dibuat sebelumnya disertakan di dalam aplikasi atau sistem developer. NPM menyertakan fitur untuk mengaudit set paket yang digunakan oleh aplikasi dan untuk mengidentifikasi paket yang memiliki kerentanan keamanan yang diketahui.

O

Bucket penyimpanan objek - jenis penyimpanan tetap di cloud yang memudahkan organisasi untuk menyimpan file ke penyimpanan tetap, termasuk file yang sangat besar, tanpa perlu khawatir tentang meningkatkan skala aset fisik seperti array penyimpanan atau cara mencadangkan file ini untuk memastikannya tidak hilang jika terjadi bencana seperti kebakaran atau banjir.

Sistem Operasi - perangkat lunak yang berjalan di komputer atau perangkat seluler yang memungkinkan aplikasi berjalan dan menggunakan prosesor, memori, penyimpanan, dan sumber daya jaringan komputer tersebut. Misalnya, Windows Microsoft, macOS atau iOS Apple, dan Linux.

Anggota organisasi - seseorang dengan peran dan tanggung jawab dalam organisasi, misalnya karyawan, kontraktor, pekerja kontingen, magang, atau relawan.

Perangkat organisasi - komputer atau perangkat seluler yang digunakan oleh anggota organisasi dalam konteks melakukan pekerjaan untuk organisasi.

P

Ketentuan Platform 6.a.i - Mengacu pada Ketentuan Platform Meta bagian (6) judul (a) paragraf (i), yang menjelaskan kewajiban developer platform terkait dengan keamanan data.

Paket - sinonim untuk pustaka

Patch - pembaruan perangkat lunak yang mengatasi kerentanan keamanan, memperbaiki bug, atau menambah fungsionalitas baru. Semua jenis perangkat lunak mendapatkan patch, termasuk Sistem Operasi, kontainer, pustaka, dan SDK.

Uji penetrasi - serangan simulasi terhadap aplikasi atau sistem di mana penguji mencoba menemukan kerentanan dalam kode atau konfigurasi yang dapat dieksploitasi oleh aktor tanpa otorisasi. Penguji penetrasi akan menggunakan fitur yang mirip dengan penjahat siber untuk melakukan pengintaian, memindai potensi kelemahan, dan menguji kerentanan yang dapat digunakan untuk mendapatkan akses tidak sah. Di akhir uji penetrasi, penguji akan membuat laporan yang menjelaskan temuan bersama dengan tingkat keseriusan masing-masing dan organisasi yang memelihara perangkat lunak bertanggung jawab untuk membuat perbaikan untuk mengatasi kerentanan.

Teks terang - sinonim untuk data yang tidak terenkripsi, teks terang adalah nama yang diberikan untuk data yang belum dilindungi oleh enkripsi. Platform as a Service (PaaS) - pendekatan komputasi cloud di mana pelanggan meluncurkan aplikasi ke dalam platform yang dikelola oleh penyedia cloud. Dibandingkan IaaS, PaaS lebih mudah dikelola oleh pelanggan karena tidak hanya aset fisik (yaitu, server, perangkat penyimpanan, dan perangkat jaringan) dikelola oleh host cloud, tetapi juga sistem operasi dan kontainer aplikasi tempat aplikasi pelanggan berjalan. Misalnya, ini adalah beberapa produk PaaS populer: AWS Elastic Beanstalk, Google App Engine, Force.com.

Port - ketika klien membuat koneksi ke server melalui internet, alamat destinasi memiliki dua bagian: (1) alamat Protokol Internet (IP) untuk server dan (2) nomor port di server itu yang akan ditanggapi oleh aplikasi tertentu. Protokol umum menggunakan port yang dicadangkan (misalnya, HTTPS menggunakan 443) tetapi developer dapat menggunakan port khusus untuk komunikasi jaringan jika diinginkan.

R

REST API - gaya yang diadopsi secara luas untuk membangun layanan yang dapat diakses web di mana klien dan server berkomunikasi menggunakan protokol HTTP. Developer di platform Meta mungkin menghosting REST API di subdomain seperti api.example.com di mana aplikasi seluler mereka mengirim dan menerima Data Platform ke/darinya.

S

Secure Shell (SSH) - skema komunikasi yang memungkinkan administrator untuk login dari jarak jauh ke server dan menjalankan program di server tersebut. Disebut aman karena komunikasi antara klien dan server dilindungi dari penyadapan, tidak seperti protokol sebelumnya seperti Telnet. Juga disebut sebagai Secure Socket Shell.

Secure Sockets Layer (SSL) - Versi enkripsi yang usang dan tidak aman dalam perjalanan. Versi aman yang modern disebut Transport Layer Security (TLS).

Server - komputer yang menyediakan layanan jarak jauh melalui jaringan. Browser dan aplikasi seluler terhubung ke server melalui internet.

Komputasi tanpa server - gaya komputasi cloud di mana host cloud mengelola infrastruktur fisik, sistem operasi server, dan kontainer. Developer hanya bertanggung jawab atas kode khusus dan pustaka terkait bersama dengan konfigurasi cloud.

Server side - data atau komputasi di sisi lain koneksi jaringan (yaitu, di server) disebut sebagai server side. Sebaliknya, data atau komputasi pada perangkat lokal seperti laptop atau perangkat seluler disebut sebagai client side.

Single Sign On (SSO) - pengaturan di mana aplikasi mengandalkan direktori pengguna terpusat (yaitu, IdP) untuk mengautentikasi pengguna. Selain memusatkan administrasi akun pengguna dan akses aplikasi untuk organisasi, pengguna diuntungkan dengan memiliki satu set kredensial alih-alih mengharuskan pengguna untuk menjaga kredensial yang berbeda (mis., nama pengguna dan kata sandi) untuk setiap aplikasi yang berbeda.

Kit Pengembangan Perangkat Lunak (SDK) - blok bangunan kode yang dapat digunakan developer untuk menyederhanakan proses pengembangan untuk kebutuhan tertentu. Misalnya, Meta membuat dan memelihara SDK yang menyederhanakan bekerja dengan Graph API untuk developer iOS dan Android. Serupa dengan pustaka, developer yang menggunakan SDK di aplikasi mereka harus selalu memperbaruinya dari waktu ke waktu.

Software as a Service (SaaS) - memungkinkan pelanggan untuk menggunakan aplikasi berbasis cloud melalui internet. Tidak seperti PaaS atau IaaS, pelanggan aplikasi SaaS tidak menerapkan kode khusus atau bertanggung jawab untuk mengonfigurasi, mengupgrade, atau melakukan patching aplikasi SaaS karena semua ini adalah tanggung jawab vendor perangkat lunak SaaS. Misalnya, ini adalah beberapa produk SaaS populer: Dopbox, MailChip, Salesforce, Slack.

Analisis statis - lihat Pengujian Keamanan Aplikasi Statis

Pengujian Keamanan Aplikasi Statis (SAST) - pendekatan untuk menemukan kerentanan dalam perangkat lunak dengan menjalankan fitur khusus pada kode sumber. Fitur SAST akan mengidentifikasi potensi kerentanan, seperti yang tercantum dalam proyek 10 Teratas OWASP, lalu developer bertanggung jawab untuk meninjau temuan, membedakan positif benar dari positif palsu, dan memperbaiki kerentanan dalam perangkat lunak. SAST dapat berguna karena memungkinkan developer menemukan kerentanan sebelum dimasukkan ke dalam produksi, tetapi tidak seperti uji penetrasi, fitur SAST tidak akan dapat menemukan kerentanan yang terkait dengan konfigurasi produksi aplikasi.

T

Enkripsi data transparan - jenis enkripsi saat istirahat yang biasanya berlaku untuk penyimpanan database (yaitu, isi database itu sendiri dan file lognya). Dalam pengaturan ini, perangkat lunak database mengelola kunci enkripsi dan secara transparan menangani operasi enkripsi (saat menulis) dan operasi dekripsi (saat membaca).

Transport Layer Security (TLS) - skema enkripsi dalam transit yang menggunakan enkripsi untuk melindungi data yang dikirimkan melalui jaringan dari penyadap di sepanjang jalur jaringan. TLS adalah versi aman dan modern dari teknologi lama yang disebut SSL.

Autentikasi Dua Faktor (2Fac) - sinonim untuk Autentikasi Multi-Faktor. Vault - sistem manajemen rahasia untuk data sensitif seperti kunci enkripsi, token akses, dan kredensial lainnya. Vault memungkinkan kontrol ketat atas siapa yang dapat mengakses rahasia di dalamnya dan menawarkan layanan tambahan seperti menyimpan log audit.

V

Mesin Virtual (VM) - sangat mirip dengan Kontainer Aplikasi – VM berjalan di host yang disebut hypervisor sedangkan Kontainer Aplikasi berjalan di mesin kontainer. Perbedaan utamanya adalah gambar VM berisi Sistem Operasi sedangkan Kontainer Aplikasi tidak. Baik VM maupun Kontainer Aplikasi berisi aplikasi dan dependensi seperti pustaka.

Virtual Private Cloud (VPC) - istilah yang digunakan oleh AWS untuk mengacu pada set sumber daya cloud yang menyerupai jaringan tradisional di pusat data di era sebelum cloud.

Kerentanan - cela dalam sistem atau aplikasi yang dapat dieksploitasi, misalnya, untuk membaca data yang tidak berhak dibaca oleh aktor

Program Pengungkapan Kerentanan (VDP) - pendekatan di mana organisasi meminta laporan kerentanan keamanan dari peneliti (kadang-kadang disebut peretas etis) sehingga kerentanan dapat ditemukan dan diperbaiki sebelum aktor jahat mengeksploitasinya. VDP yang efektif membutuhkan sekelompok peneliti yang secara aktif mencari kerentanan, analis dalam organisasi untuk meninjau dan melakukan triase pengungkapan yang masuk, dan engineer yang memiliki pengetahuan tentang keamanan siber yang mampu membuat dan menerapkan perbaikan untuk kerentanan.

Pemindaian kerentanan - pendekatan yang menggunakan perangkat lunak untuk mencari kerentanan di server, jaringan, dan aplikasi. Dibandingkan uji penetrasi, pemindaian kerentanan lebih murah untuk dijalankan dan karenanya dapat dijalankan berulang kali (mis., bulanan atau triwulanan) tetapi biasanya uji penetrasi akan menemukan kerentanan yang dilewatkan oleh pemindaian kerentanan karena penguji penetrasi yang terampil membawa keterampilan dan naluri analitis yang sulit ditiru dengan pendekatan yang sepenuhnya otomatis. Lihat juga pemindaian jaringan.

W

Aplikasi web - Aplikasi web adalah program yang berjalan di dalam browser dan terdiri dari sumber daya seperti dokumen HTML, kode JavaScript, video dan media lainnya, dan CSS untuk penataan gaya. Berbeda dengan aplikasi seluler yang diinstal seseorang ke ponsel dari toko aplikasi, orang cukup mengambil aplikasi web dari server jarak jauh menggunakan browser mereka (mis., www.facebook.com) tanpa memerlukan langkah penginstalan.