Prodi Bisnis Digital · FEB UNDIP

Laboratorium Financial Technology

Pertemuan 9: Cybersecurity dan Manajemen Risiko dalam Fintech

Mengapa aplikasi dompet digital yang Anda pakai tiap hari bisa jadi sasaran empuk peretas — dan bagaimana perusahaan fintech mengukur serta mengelola risiko itu secara sistematis.

RPS minggu 10 · 2x50 menit

Selamat datang kembali setelah UTS, Anda sekarang masuk ke paruh kedua semester yang lebih menekankan aspek regulasi, risiko, dan keberlanjutan bisnis fintech. Hari ini kita membahas topik yang sangat relevan dengan kehidupan sehari-hari Anda: keamanan siber dan manajemen risiko di industri fintech, mulai dari mengapa GoPay, OVO, atau DANA rawan diserang, sampai bagaimana bank seperti Bank Syariah Indonesia pernah lumpuh karena serangan ransomware pada Mei 2023. Bayangkan Anda adalah calon manajer risiko di sebuah startup fintech Indonesia — pertemuan ini membekali Anda dengan kerangka berpikir untuk mengidentifikasi ancaman, menghitung skor risiko, dan merancang mitigasi yang masuk akal secara finansial. Kita akan banyak menghitung dari nol supaya konsep yang terasa abstrak seperti "risiko" menjadi angka yang bisa Anda pertanggungjawabkan di depan atasan. Siapkan kalkulator dan catatan Anda, karena dua jam ke depan akan sangat padat namun aplikatif.

Bagian 1 dari 3

Lanskap Ancaman Siber di Fintech

Mengapa fintech jadi target utama, jenis-jenis serangan yang paling umum, dan anatomi satu insiden nyata di Indonesia.

Mengapa Fintech Jadi Target Utama Serangan Siber?

Fintech menyimpan dua hal yang paling dicari penjahat siber: uang dan data pribadi — sekaligus dalam satu sistem.

SKALA TRANSAKSI

~Rp 5.000 T

Estimasi nilai transaksi digital payment Indonesia per tahun

Volume sebesar ini membuat celah keamanan sekecil apa pun berpotensi dieksploitasi untuk keuntungan besar.

DATA NASABAH

Jutaan

Rekam data pribadi & finansial per platform

NIK, nomor rekening, riwayat transaksi — data ini bernilai tinggi di pasar gelap (dark web).

KECEPATAN TUMBUH

Cepat

Startup fintech sering rilis fitur lebih cepat dari audit keamanannya

Tekanan "time-to-market" membuat pengujian keamanan kadang jadi prioritas terakhir.

Coba Anda bayangkan diri Anda sebagai peretas: mana yang lebih menarik untuk diserang, warung kelontong atau aplikasi yang menyimpan uang dan data pribadi jutaan orang sekaligus? Itulah sebabnya fintech seperti dompet digital, platform pinjaman online, atau robo-advisor menjadi sasaran empuk — mereka menggabungkan nilai finansial langsung dengan data pribadi yang sensitif dalam satu sistem. Ditambah lagi, banyak startup fintech di Indonesia tumbuh sangat cepat mengejar target pengguna, sehingga kadang fitur keamanan menjadi nomor dua dibanding kecepatan rilis produk baru. Anda perlu memahami bahwa ini bukan sekadar isu teknis IT, melainkan isu manajemen strategis — satu insiden keamanan bisa menghancurkan kepercayaan yang dibangun bertahun-tahun dalam hitungan jam, seperti yang pernah dialami beberapa platform e-commerce dan perbankan digital Indonesia.

Peta Ancaman: Jenis-Jenis Serangan Siber Umum

PHISHING

Email/SMS/link palsu menyamar sebagai bank atau e-wallet resmi untuk mencuri kredensial login atau kode OTP (One-Time Password, kode sekali pakai).

MALWARE & RANSOMWARE

Perangkat lunak jahat yang menyusup ke sistem; ransomware mengunci/mengenkripsi data dan meminta tebusan agar bisa dibuka kembali.

DDOS

Distributed Denial of Service — membanjiri server dengan lalu lintas palsu hingga aplikasi lumpuh dan tak bisa diakses nasabah.

SQL INJECTION

Menyisipkan kode berbahaya lewat kolom input (misal formulir login) untuk mengakses database secara ilegal.

SOCIAL ENGINEERING

Manipulasi psikologis — pura-pura jadi petugas bank via telepon untuk membujuk korban memberi kode OTP sendiri.

INSIDER THREAT

Ancaman dari dalam — karyawan atau mitra yang menyalahgunakan akses sah untuk mencuri data atau dana.

Perhatikan bahwa keenam jenis serangan ini punya karakter yang berbeda-beda, sehingga cara mengatasinya pun berbeda — Anda tidak bisa menangani ransomware dengan cara yang sama seperti menangani social engineering. Phishing dan social engineering menyerang sisi manusia, sedangkan malware, DDoS, dan SQL injection menyerang sisi teknis sistem; insider threat unik karena pelakunya justru orang yang dipercaya organisasi. Di Indonesia, phishing dan social engineering lewat WhatsApp atau telepon yang mengaku dari bank sangat marak menyasar nasabah awam, sementara serangan skala besar seperti ransomware lebih sering menyasar institusi keuangan langsung. Ingat baik-baik keenam istilah ini karena kita akan memakainya berulang kali sepanjang kuliah, termasuk saat membahas kasus nyata Bank Syariah Indonesia sebentar lagi.

Anatomi Serangan Phishing: Langkah demi Langkah

Walkthrough kasus umum: bagaimana satu pesan palsu bisa berujung dana nasabah e-wallet terkuras.

Tahap	Apa yang Terjadi
1. Umpan	Nasabah menerima SMS/WhatsApp "Akun Anda akan diblokir, klik link ini untuk verifikasi" — meniru gaya resmi bank/e-wallet.
2. Jebakan	Link mengarah ke halaman login palsu yang tampilannya identik dengan aplikasi asli.
3. Pencurian Kredensial	Korban memasukkan username, password, bahkan kode OTP — semua langsung terkirim ke peretas.
4. Eksekusi	Peretas login ke akun asli nasabah dalam hitungan detik dan langsung mentransfer dana keluar.
5. Pencucian	Dana dipecah ke banyak rekening penampung agar sulit dilacak sebelum ditarik tunai.

Sekarang mari kita bedah satu serangan phishing tahap demi tahap supaya Anda paham betapa cepatnya proses ini terjadi — biasanya kurang dari lima menit dari SMS pertama sampai dana nasabah ludes. Perhatikan bahwa di tahap ketiga, korban sebenarnya menyerahkan kunci brankasnya sendiri secara sukarela karena percaya sedang berkomunikasi dengan bank resmi — ini sebabnya edukasi nasabah menjadi kontrol keamanan yang sama pentingnya dengan sistem teknis. Kasus semacam ini nyata terjadi di Indonesia dan menimpa nasabah berbagai bank maupun e-wallet, seringnya menyasar orang yang kurang familiar dengan modus digital, termasuk pelaku UMKM yang baru migrasi ke pembayaran digital. Sebagai calon profesional fintech, tugas Anda nanti bukan hanya membangun sistem yang aman, tapi juga merancang komunikasi dan edukasi yang mencegah nasabah "membuka pintu" bagi peretas sendiri.

Studi Kasus: Serangan Ransomware Bank Syariah Indonesia (2023)

APA YANG TERJADI

Mei 2023, layanan BSI (ATM, mobile banking, kantor cabang) lumpuh selama beberapa hari
Kelompok ransomware LockBit mengklaim mencuri ~1,5 TB data nasabah dan karyawan
Peretas meminta tebusan; sebagian data diklaim disebar di dark web saat tuntutan tak dipenuhi

DAMPAK & PELAJARAN

Kerugian operasional, reputasi, dan potensi sanksi regulator (OJK)
Menunjukkan pentingnya backup data terisolasi dan rencana pemulihan bencana
Kasus ini jadi pengingat: institusi keuangan besar sekalipun tidak kebal serangan

Kasus BSI ini penting Anda pahami karena menunjukkan bahwa bahkan institusi keuangan besar dengan sumber daya IT yang jauh lebih besar dari startup fintech pun bisa lumpuh total oleh satu serangan ransomware. Selama beberapa hari nasabah tidak bisa menarik uang dari ATM, transaksi mobile banking gagal, dan antrean panjang terjadi di kantor cabang — bayangkan dampaknya bila itu terjadi pada aplikasi yang Anda kelola dan jutaan penggunanya bergantung padanya setiap hari untuk transaksi. Angka kerugian pasti dari insiden ini tidak dipublikasikan resmi secara rinci, jadi anggap sebagai estimasi kasar yang beredar di pemberitaan, bukan angka final terverifikasi. Sepanjang sisa kuliah ini, kita akan terus merujuk kasus BSI sebagai contoh nyata saat membahas siklus respons insiden dan pentingnya rencana keberlangsungan bisnis, supaya konsep-konsep tersebut tidak terasa abstrak bagi Anda.

CIA Triad: Fondasi Keamanan Informasi

Tiga pilar yang harus dijaga setiap sistem fintech — kerangka paling dasar dalam keamanan siber.

CONFIDENTIALITY

Kerahasiaan

Data hanya bisa diakses pihak berwenang. Contoh: enkripsi data nasabah agar tak terbaca pihak luar.

INTEGRITY

Integritas

Data tidak boleh diubah tanpa izin. Contoh: saldo rekening tidak bisa dimanipulasi peretas.

AVAILABILITY

Ketersediaan

Sistem harus tetap bisa diakses saat dibutuhkan. Contoh: aplikasi tetap jalan meski diserang DDoS.

CIA triad ini adalah kerangka paling fundamental yang akan Anda temui di hampir setiap literatur keamanan siber, jadi pastikan Anda hafal ketiga istilahnya beserta contohnya. Ambil contoh kasus BSI tadi: saat sistem lumpuh, yang paling terasa oleh nasabah adalah pelanggaran availability karena mereka tidak bisa menarik uang, sementara kebocoran 1,5 TB data adalah pelanggaran confidentiality. Sedangkan integrity terancam kalau, misalnya, peretas berhasil mengubah catatan saldo rekening nasabah — ini yang paling berbahaya karena bisa merusak kepercayaan terhadap keakuratan sistem finansial itu sendiri. Setiap kontrol keamanan yang akan kita bahas nanti, mulai dari enkripsi sampai autentikasi berlapis, sebenarnya dirancang untuk melindungi satu atau lebih dari tiga pilar ini, jadi gunakan kerangka CIA sebagai "peta" untuk mengevaluasi kontrol apa pun yang Anda temui di industri.

Bagian 2 dari 3

Kerangka Manajemen Risiko Siber

Dari identifikasi ancaman ke angka: cara mengukur risiko dan memperkirakan potensi kerugian finansial.

Siklus Manajemen Risiko Siber

Manajemen risiko bukan aktivitas sekali jadi, melainkan siklus berkelanjutan.

Siklus ini berputar terus — ancaman baru bermunculan (misal modus phishing model baru), sehingga identifikasi harus diulang secara berkala, bukan sekali di awal proyek saja.

Perhatikan diagram ini baik-baik karena inilah kerangka besar yang akan menaungi seluruh perhitungan yang akan kita lakukan setelah ini. Tahap identifikasi berarti Anda mendaftar aset apa saja yang perlu dilindungi — misalnya data nasabah, sistem pembayaran, reputasi merek — dan ancaman apa yang mengintai masing-masing aset tersebut. Tahap analisis adalah saat Anda mengubah ancaman kualitatif menjadi angka kuantitatif seperti skor risiko, yang akan kita hitung sebentar lagi menggunakan kombinasi likelihood dan impact. Yang sering dilupakan mahasiswa adalah tahap keempat, monitoring — banyak perusahaan fintech merasa "sudah aman" setelah memasang satu sistem keamanan, padahal ancaman terus berevolusi sehingga siklus ini harus diulang secara rutin, idealnya setiap kuartal atau setiap kali ada perubahan sistem besar.

Hitung dari Nol #1: Skor Risiko (Likelihood x Impact)

Skenario: risiko serangan phishing terhadap nasabah aplikasi e-wallet. Skala 1-5 untuk tiap faktor.

Langkah	Perhitungan	Nilai
1. Tentukan Likelihood (kemungkinan terjadi, skala 1-5)	Phishing pada nasabah e-wallet: sangat sering terjadi di lapangan	4
2. Tentukan Impact (dampak jika terjadi, skala 1-5)	Potensi kerugian dana nasabah + rusaknya reputasi platform	5
3. Hitung Risk Score = Likelihood × Impact	4 × 5	20
4. Bandingkan dengan ambang batas kategori	Skor > 15 dari skala maksimum 25 = kategori Kritis	Kritis

HASIL AKHIR

Skor 20 — Kritis

Butuh mitigasi segera, bukan sekadar dipantau

Mari kita hitung bersama-sama, dan saya minta Anda ikut mencatat di kertas Anda sendiri sambil saya jelaskan setiap langkahnya. Likelihood mengukur seberapa sering skenario ini realistis terjadi — untuk phishing pada e-wallet, angkanya tinggi karena modus ini memang marak di Indonesia, jadi kita beri nilai 4 dari skala 1 sampai 5. Impact mengukur seberapa parah akibatnya jika benar-benar terjadi — karena menyangkut dana nasabah langsung dan bisa merusak reputasi platform secara luas, kita beri nilai 5, yaitu dampak paling parah. Dengan mengalikan keduanya kita dapat skor 20 dari skala maksimum 25, yang jatuh pada kategori "Kritis" — artinya tim manajemen risiko fintech ini wajib segera mengalokasikan sumber daya untuk mitigasi, bukan menunda-nunda sampai kuartal berikutnya. Perhatikan bahwa matriks likelihood-impact ini adalah alat paling umum dipakai industri karena sederhana namun efektif untuk memprioritaskan mana risiko yang harus ditangani lebih dulu.

Coba Sendiri: Susun Heatmap Risiko 5x5

Klik sel likelihood dan impact untuk berbagai skenario ancaman, lihat bagaimana skor dan kategori risikonya berubah pada matriks 5x5.

Kontrol Keamanan Teknis: Enkripsi, MFA, Tokenisasi

ENKRIPSI

Mengubah data jadi kode acak yang hanya bisa dibaca dengan kunci tertentu. Melindungi data at rest (tersimpan) maupun in transit (saat dikirim), umumnya standar AES-256 dan TLS/SSL.

MFA / 2FA

Multi-Factor Authentication — verifikasi berlapis (password + OTP + biometrik sidik jari/wajah) sehingga satu kredensial bocor saja tidak cukup untuk membobol akun.

TOKENISASI

Mengganti data sensitif (misal nomor kartu) dengan token acak yang tak bermakna di luar sistem — dipakai kartu kredit digital dan dompet elektronik.

Kredensial Bocor + MFA Aktif ≠ Akun Berhasil Dibobol

Ketiga kontrol teknis ini adalah lapisan pertahanan yang paling sering Anda temui saat memakai aplikasi fintech sehari-hari, meski mungkin selama ini Anda tidak sadar sedang berinteraksi dengannya. Enkripsi memastikan bahwa meskipun data berhasil dicuri, peretas hanya mendapat kode acak yang tak berguna tanpa kunci dekripsinya — analoginya seperti mencuri brankas tapi tidak punya kombinasi angkanya. MFA adalah alasan mengapa aplikasi perbankan Anda sering minta kode OTP tambahan setelah memasukkan password; formula sederhana di slide ini menekankan bahwa satu kredensial bocor tidak otomatis berarti akun Anda dibobol, selama lapisan verifikasi kedua tetap aman dan tidak ikut diserahkan ke peretas seperti pada kasus phishing tadi. Tokenisasi banyak dipakai GoPay, OVO, dan platform sejenis saat menyimpan data kartu kredit Anda, sehingga nomor kartu asli tidak pernah benar-benar tersimpan di server mereka. Sebagai calon praktisi fintech, Anda perlu memahami bahwa ketiga kontrol ini saling melengkapi, bukan saling menggantikan.

Hitung dari Nol #2: Estimasi Kerugian Tahunan (ALE)

ALE (Annualized Loss Expectancy) membantu menentukan anggaran keamanan yang masuk akal — bukan tebak-tebakan.

Langkah	Perhitungan	Nilai
1. Tentukan Asset Value (nilai aset informasi)	Estimasi nilai data nasabah + sistem terdampak	Rp 500.000.000
2. Tentukan Exposure Factor (EF, % aset yang hilang/rusak)	Perkiraan proporsi kerusakan bila insiden terjadi	40%
3. Hitung SLE (Single Loss Expectancy) = Asset Value × EF	Rp 500.000.000 × 40%	Rp 200.000.000
4. Tentukan ARO (Annualized Rate of Occurrence, frekuensi/tahun)	1 insiden diperkirakan tiap 2 tahun = 1 ÷ 2	0,5
5. Hitung ALE = SLE × ARO	Rp 200.000.000 × 0,5	Rp 100.000.000

ALE PER TAHUN

Rp 100 juta

Anggaran mitigasi idealnya lebih kecil dari angka ini agar tetap efisien secara biaya

Perhitungan ALE ini sedikit lebih rumit dari skor risiko tadi, jadi mari kita telusuri pelan-pelan satu per satu. Pertama kita tentukan Asset Value, yaitu perkiraan nilai ekonomis dari aset yang berisiko — di sini kita pakai contoh Rp 500 juta sebagai estimasi nilai data dan sistem yang berpotensi terdampak, angka ini sifatnya perkiraan manajemen, bukan harga pasar yang eksak. Selanjutnya Exposure Factor sebesar 40 persen menunjukkan proporsi aset yang diperkirakan hilang atau rusak jika insiden benar-benar terjadi, sehingga SLE atau kerugian per kejadian menjadi Rp 200 juta. ARO sebesar 0,5 berarti kita memperkirakan insiden semacam ini terjadi rata-rata sekali setiap dua tahun berdasarkan data historis atau benchmark industri. Hasil akhirnya, ALE sebesar Rp 100 juta per tahun, menjadi acuan penting: jika perusahaan menghabiskan lebih dari Rp 100 juta setahun untuk mitigasi risiko spesifik ini, secara ekonomi itu tidak efisien — inilah cara manajer risiko fintech mengambil keputusan anggaran keamanan berbasis data, bukan sekadar insting.

Coba Sendiri: Kalkulator ALE (Annualized Loss Expectancy)

Ubah nilai aset, exposure factor, dan frekuensi kejadian per tahun — amati bagaimana estimasi kerugian tahunan (ALE) berubah.

Kontrol Keamanan Organisasi: Access Control

Kontrol teknis saja tak cukup — bagaimana organisasi mengatur siapa yang boleh mengakses apa sama pentingnya.

LEAST PRIVILEGE

Hak Akses Minimum

Karyawan hanya diberi akses yang benar-benar dibutuhkan untuk pekerjaannya — staf customer service tidak perlu akses ke database inti sistem pembayaran.

SEGREGATION OF DUTIES

Pemisahan Tugas

Satu orang tidak boleh memegang kendali penuh atas proses sensitif — misal, yang menyetujui transaksi harus berbeda dari yang mengeksekusinya, mencegah penyalahgunaan (insider threat).

Kontrol organisasi ini sering diabaikan startup fintech yang timnya masih kecil — padahal semakin cepat perusahaan tumbuh, semakin besar risiko akses yang "menumpuk" pada segelintir orang.

Setelah tadi kita bahas kontrol teknis seperti enkripsi dan MFA, sekarang kita masuk ke sisi manusia dan proses organisasi, yang justru sering jadi celah paling besar. Prinsip least privilege berarti setiap karyawan hanya mendapat akses seminimal mungkin untuk menjalankan tugasnya — bayangkan jika seorang staf magang di startup fintech punya akses penuh ke database transaksi seluruh nasabah, risiko penyalahgunaan atau kebocoran akan sangat tinggi meski niatnya tidak jahat sekalipun. Segregation of duties atau pemisahan tugas mencegah satu orang punya kendali penuh atas proses finansial sensitif, misalnya orang yang membuat permintaan pembayaran harus berbeda dari yang menyetujuinya, sehingga kecurangan lebih sulit dilakukan sendirian. Callout peringatan di slide ini penting Anda catat karena banyak startup fintech Indonesia di tahap awal, ketika timnya masih sangat kecil, cenderung memberi akses penuh ke semua orang demi kepraktisan — kebiasaan ini berbahaya jika tidak segera dirapikan seiring pertumbuhan perusahaan.

Bagian 3 dari 3

Regulasi, Respons Insiden & Praktik Terbaik

Aturan hukum yang mengikat, cara merespons saat insiden benar-benar terjadi, dan peran manusia dalam pertahanan siber.

Regulasi: UU PDP dan Ketahanan Siber Sektor Jasa Keuangan

UU NO. 27/2022 — PDP

Undang-Undang Pelindungan Data Pribadi, berlaku penuh sejak Oktober 2024
Mewajibkan persetujuan eksplisit pengguna, kewajiban lapor jika ada kebocoran data
Sanksi administratif hingga pidana bagi pelanggaran serius

POJK KEAMANAN & KETAHANAN SIBER

OJK mewajibkan bank & fintech menerapkan manajemen risiko TI dan keamanan siber
Mencakup kewajiban audit sistem, pelaporan insiden ke regulator
~Aturan terus diperbarui OJK — selalu cek versi POJK terbaru sebelum menerapkan di praktik

Sebagai calon profesional fintech, Anda wajib tahu bahwa keamanan siber bukan hanya urusan teknis, tapi juga kewajiban hukum yang bisa berujung sanksi jika diabaikan. Undang-Undang Pelindungan Data Pribadi nomor 27 tahun 2022 adalah payung hukum utama di Indonesia, mewajibkan perusahaan meminta persetujuan eksplisit sebelum mengumpulkan data pribadi Anda, dan mewajibkan mereka melapor kepada otoritas serta pemilik data jika terjadi kebocoran. Selain itu, OJK sebagai regulator sektor jasa keuangan mewajibkan bank dan fintech menerapkan manajemen risiko teknologi informasi serta keamanan siber secara berkelanjutan, termasuk audit sistem berkala dan pelaporan insiden — saya sengaja memberi tanda "kira-kira" pada detail POJK karena aturan teknis ini terus diperbarui OJK dari waktu ke waktu, jadi kalau Anda bekerja di industri nanti, selalu cek versi regulasi terbaru, jangan mengandalkan catatan kuliah lama. Regulasi ini penting dipahami karena pelanggaran bukan hanya berisiko reputasi, tapi juga sanksi administratif hingga pidana bagi perusahaan dan bahkan individu yang bertanggung jawab.

Business Continuity & Disaster Recovery Plan

Rencana tertulis agar bisnis tetap berjalan (atau cepat pulih) saat bencana — termasuk serangan siber — benar-benar terjadi.

RTO — RECOVERY TIME OBJECTIVE

Target Waktu Pulih

Berapa lama maksimal sistem boleh mati sebelum dianggap merugikan bisnis secara serius — misal, target maksimal 4 jam untuk sistem pembayaran inti.

RPO — RECOVERY POINT OBJECTIVE

Batas Kehilangan Data

Seberapa jauh mundur data yang boleh hilang — misal backup tiap 1 jam berarti maksimal kehilangan data 1 jam terakhir.

BCP (Business Continuity Plan) fokus pada bisnis tetap jalan; DRP (Disaster Recovery Plan) fokus pada pemulihan sistem TI — keduanya saling melengkapi, bukan pengganti satu sama lain.

Bayangkan skenario seperti yang dialami BSI: jika perusahaan sudah punya BCP dan DRP yang matang, downtime yang dialami nasabah semestinya bisa jauh lebih singkat karena tim sudah punya panduan jelas langkah demi langkah, bukan panik mencari solusi di tengah krisis. RTO menjawab pertanyaan "berapa lama kita boleh offline", sementara RPO menjawab "berapa banyak data yang boleh hilang" — keduanya adalah target terukur yang harus disepakati manajemen sebelum insiden terjadi, bukan didiskusikan saat sistem sudah down. Misalnya, untuk sistem pembayaran inti sebuah e-wallet, RTO yang wajar mungkin hanya beberapa jam karena setiap menit downtime berarti kerugian transaksi dan kepercayaan nasabah yang signifikan. Perbedaan BCP dan DRP juga penting Anda pahami: BCP lebih luas mencakup bagaimana seluruh operasional bisnis tetap berjalan meski sistem utama down, misalnya lewat prosedur manual sementara, sedangkan DRP lebih spesifik ke pemulihan infrastruktur teknologi itu sendiri.

Walkthrough: Siklus Respons Insiden Siber

Menerapkan kerangka lima tahap pada skenario mirip kasus BSI — dari deteksi sampai pembelajaran.

Tahap	Yang Dilakukan Tim Keamanan
1. Persiapan	Tim & prosedur respons sudah disiapkan sebelum insiden — bukan dadakan saat krisis.
2. Deteksi & Analisis	Sistem monitoring mendeteksi aktivitas mencurigakan (login abnormal, enkripsi massal file).
3. Containment (Isolasi)	Sistem terdampak diputus dari jaringan agar serangan tak menyebar ke sistem lain.
4. Eradication & Recovery	Malware dibersihkan tuntas, sistem dipulihkan dari backup bersih sesuai RTO/RPO yang ditetapkan.
5. Lessons Learned	Evaluasi menyeluruh: celah mana yang dieksploitasi, apa yang harus diperbaiki agar tak terulang.

Kerangka lima tahap ini adalah standar yang dipakai luas di industri keamanan siber, sering disebut kerangka NIST karena mengacu pada standar dari lembaga National Institute of Standards and Technology di Amerika Serikat, namun prinsipnya berlaku universal. Tahap persiapan sering dilupakan padahal paling krusial — organisasi yang sudah punya tim dan prosedur jelas sebelum insiden terjadi akan jauh lebih tenang dan cepat merespons dibanding yang baru mulai berpikir saat sistem sudah lumpuh. Pada kasus seperti BSI, tahap containment sangat menentukan seberapa luas dampak serangan — semakin cepat sistem terdampak diisolasi dari jaringan, semakin kecil kemungkinan ransomware menyebar ke sistem lain yang masih sehat. Tahap terakhir, lessons learned, adalah yang membedakan organisasi yang benar-benar belajar dari insiden dengan yang hanya "memadamkan api" lalu melupakannya — evaluasi menyeluruh inilah yang seharusnya memicu perbaikan kontrol keamanan berikutnya, menutup siklus manajemen risiko yang kita bahas di awal tadi.

Faktor Manusia: Security Awareness & Budaya Keamanan

Studi industri berulang kali menunjukkan: mayoritas insiden keamanan siber melibatkan kesalahan manusia, bukan semata kegagalan teknologi.

PELATIHAN RUTIN

Simulasi phishing berkala untuk melatih karyawan mengenali email/pesan mencurigakan sebelum terlambat.

HIGIENE PASSWORD

Password unik & kuat per akun, tidak dipakai berulang, dikelola lewat password manager — bukan dicatat di kertas.

BUDAYA LAPOR CEPAT

Karyawan didorong segera melapor jika curiga ada insiden, tanpa takut disalahkan — kecepatan lapor menentukan besarnya kerugian.

Setelah kita membahas banyak kontrol teknis dan prosedural, penting Anda ingat bahwa manusia sering menjadi "titik terlemah" sekaligus "garis pertahanan pertama" dalam keamanan siber — dua sisi mata uang yang sama. Pelatihan simulasi phishing, misalnya, dilakukan banyak bank dan fintech besar dengan mengirim email phishing palsu ke karyawan sendiri untuk mengukur seberapa banyak yang tertipu, lalu memberi pelatihan tambahan bagi yang gagal mendeteksinya. Higiene password terdengar sepele, tapi kebiasaan memakai password yang sama di banyak akun adalah salah satu penyebab paling umum akun dibobol, karena begitu satu platform bocor, peretas otomatis mencoba kredensial yang sama di platform lain. Budaya lapor cepat sama pentingnya — banyak insiden justru membesar karena karyawan yang menyadari sesuatu janggal memilih diam karena takut disalahkan, padahal keterlambatan pelaporan sering kali lebih merugikan daripada kesalahan awal itu sendiri. Sebagai calon manajer, salah satu tugas terpenting Anda kelak adalah membangun budaya organisasi yang membuat karyawan nyaman melapor secepat mungkin.

Latihan Kelompok: Audit Risiko Skenario Fintech

SKENARIO

Sebuah startup lending fintech (P2P lending) baru meluncurkan fitur pencairan pinjaman instan via aplikasi mobile. Tim keamanannya masih terdiri dari 2 orang.

TUGAS KELOMPOK (15 MENIT)

1. Identifikasi 2 aset kritis & 2 ancaman utama yang relevan.
2. Hitung Risk Score (Likelihood x Impact) untuk salah satu ancaman.
3. Usulkan 2 kontrol mitigasi konkret (teknis atau organisasi).

Presentasikan hasil kelompok Anda dalam 2 menit — fokus pada angka skor risiko dan alasan pemilihan mitigasi, bukan sekadar daftar istilah.

Sekarang saatnya Anda mempraktikkan langsung semua konsep yang sudah kita bahas — bentuk kelompok kecil 3 sampai 4 orang dan bayangkan Anda adalah tim manajemen risiko di startup P2P lending fiktif ini. Perhatikan bahwa skenario ini sengaja dibuat mirip kondisi nyata banyak startup fintech Indonesia tahap awal: fitur baru yang menarik secara bisnis tapi tim keamanannya masih sangat kecil, sehingga rentan seperti yang kita bahas di slide motivasi tadi. Gunakan kerangka Hitung dari Nol yang sudah kita latih untuk menghitung skor risiko, dan jangan asal menyebut angka — jelaskan alasan Anda memilih nilai likelihood dan impact tertentu berdasarkan skenario ini. Saya akan berkeliling untuk mendengarkan diskusi tiap kelompok, dan pastikan semua anggota kelompok Anda paham cara menjelaskan hasilnya, karena presentasi singkat nanti bisa diminta dari siapa saja dalam kelompok, bukan hanya juru bicara.

Rangkuman & Menuju Pertemuan Berikutnya

Istilah	Inti
CIA Triad	Kerahasiaan, Integritas, Ketersediaan
Risk Score	Likelihood × Impact
ALE	SLE × ARO (estimasi rugi/tahun)
RTO/RPO	Target waktu & data pulih pasca-insiden

TUGAS SEBELUM PERTEMUAN 10

Baca Kasus

Cari 1 berita insiden siber fintech Indonesia lain (selain BSI), catat jenis serangan & dampaknya — akan didiskusikan singkat di awal pertemuan berikutnya tentang Analisis Data Keuangan & Pemodelan Kuantitatif.

Mari kita rangkum perjalanan kita hari ini: kita mulai dari memahami mengapa fintech jadi target favorit peretas, mengenali jenis-jenis serangan lewat kasus nyata BSI, lalu belajar mengukur risiko secara kuantitatif lewat skor risiko dan estimasi kerugian tahunan, dan menutup dengan bagaimana organisasi merespons insiden serta membangun budaya keamanan yang kuat. Empat istilah di tabel kiri — CIA Triad, Risk Score, ALE, dan RTO/RPO — adalah bekal minimum yang harus Anda kuasai, karena akan muncul lagi baik dalam kuis maupun saat kita membahas topik analisis data keuangan minggu depan. Tugas sebelum pertemuan berikutnya sengaja ringan tapi aplikatif: cari satu berita insiden siber fintech Indonesia lain di luar kasus BSI yang kita bahas hari ini, lalu identifikasi jenis serangan dan dampaknya memakai kerangka yang sudah Anda pelajari. Terima Kasih atas partisipasi aktif Anda hari ini, dan sampai jumpa di pertemuan berikutnya ketika kita mulai masuk ke sisi kuantitatif fintech — analisis data keuangan dan pemodelan.