Belajar Cyber Security #1: CIA Triad — Fondasi Pemikiran Keamanan

Hari ini saya memutuskan untuk mulai belajar keamanan siber secara serius, bukan lagi sekadar membaca berita soal kebocoran data. Saya programmer — saya tahu cara membuat aplikasi yang jalan, tapi jujur saya sering tidak tahu apakah aplikasi saya aman atau tidak. Saya selama ini membangun fitur secepat mungkin, lalu pasrah kalau ada yang bobol. Mulai dari episode #1 ini, saya ingin memperbaiki cara pandang itu. Ini catatan belajar pertama saya.

Ilustrasi CIA Triad — Confidentiality, Integrity, Availability
CIA Triad: Confidentiality, Integrity, Availability — tiga prinsip yang dipakai NIST untuk mendefinisikan keamanan informasi.

Keamanan siber itu bukan produk, tapi cara berpikir

Salah satu kesalahan pemahaman saya selama ini: saya mengira “keamanan” itu sesuatu yang bisa dibeli — pasang antivirus, pasang firewall, selesai. Ternyata tidak. Keamanan siber lebih mirip kebiasaan kebersihan daripada alat. Alat bantu memang penting, tapi kalau pola pikirnya tidak berubah, alat termahal pun tetap bisa ditembus lewat cara yang sederhana.

Di dokumentasi NIST (National Institute of Standards and Technology), keamanan informasi didefinisikan dalam tiga tujuan inti yang dikenal sebagai CIA triad. Tiga huruf ini adalah lensa pertama yang saya pelajari, dan ternyata hampir semua diskusi keamanan — dari password sampai backup server — bisa dipetakan ke salah satu ketiganya.

CIA Triad: Confidentiality, Integrity, Availability

  • Confidentiality (Kerahasiaan) — data hanya boleh dibaca oleh orang yang berhak. Analogi sederhana dari dunia programmer: enkripsi adalah gembok, dan hak akses database adalah siapa yang memegang kuncinya. Kalau password admin bocor, confidentiality runtuh.
  • Integrity (Integritas) — data tidak diubah oleh pihak yang tidak berwenang. Ini yang paling sering saya abaikan sebagai developer. Misalnya, kalau ada orang bisa diam-diam mengubah saldo di database lewat SQL Injection, masalahnya bukan cuma data hilang — data palsu justru lebih berbahaya karena sistem masih “percaya” datanya asli.
  • Availability (Ketersediaan) — data dan sistem bisa diakses saat dibutuhkan. Serangan DDoS adalah contoh klasik: tidak ada data yang dicuri, tidak ada yang diubah — server hanya dibuat tidak bisa melayani. Untuk bisnis, downtime berarti uang hilang.
PrinsipPertanyaan kuncinyaContoh pelanggaran
ConfidentialitySiapa yang boleh melihat data ini?Password bocor, enkripsi dilewati
IntegrityApakah data masih asli?SQL Injection mengubah saldo
AvailabilityBisa diakses saat dibutuhkan?DDoS, ransomware mengenkripsi file

Yang menarik: tiga prinsip ini sering bertabrakan. Mengenkripsi semua database memperkuat confidentiality, tapi kalau kunci hilang, availability ikut hilang. Membuka akses publik memperkuat availability, tapi confidentiality anjlok. Keamanan pada akhirnya adalah soal menyeimbangkan ketiganya, bukan mengejar salah satu sampai ekstrem. Ini yang saya catat sebagai pelajaran terbesar dari episode ini.

Klasifikasi ancaman: mengenal musuh dulu

Sebelum belajar cara bertahan, saya perlu tahu apa yang saya hadapi. Dari bacaan saya (OWASP, CISA), ancaman bisa diklasifikasi dari beberapa sudut. Dari sisi pelakunya: script kiddie (pemula yang menjalankan tool orang lain), cybercriminal (motivasi uang), insider (karyawan yang tahu jalan belakang), sampai state-sponsored actor (didukung negara, biasanya menyasar infrastruktur strategis).

Dari sisi teknisnya, ancaman yang paling sering saya temui di dunia developer: malware (termasuk ransomware yang mengenkripsi file sampai tebusan dibayar), phishing (menipu manusia, bukan mesin — dan manusia tetap jadi titik terlemah), injection (SQL Injection, command injection — input pengguna yang diam-diam jadi instruksi untuk sistem), serta konfigurasi yang salah (bucket storage terbuka publik, port terbuka tanpa password). Pola yang saya lihat berulang: sebagian besar insiden besar tidak dimulai dari serangan super canggih, tapi dari satu kelalaian kecil yang tidak ditangani.

Kenapa programmer wajib paham

Alasan paling jujur: hampir semua celah keamanan web lahir dari kode yang saya tulis. Injection ada karena saya menyisipkan input pengguna ke query tanpa sanitasi. Authentication lemah karena saya membuat login sendiri alih-alih memakai library yang sudah teruji. Data bocor karena saya menaruh API key di file .env yang ter-commit ke git.

Ini berarti bagi saya: keamanan bukan tanggung jawab tim keamanan di ujung proyek, setelah semua fitur selesai. Keamanan harus hadir saat menulis kode — di setiap query, setiap endpoint, setiap keputusan desain. Di episode-episode berikutnya, saya akan mulai mengurai satu per satu: password dan autentikasi, malware, jaringan dasar, sampai web security fundamentals seperti OWASP Top 10. Saya tidak akan langsung mahir, tapi setidaknya saya tahu ke mana harus belajar selanjutnya.

Catatan terakhir untuk diri sendiri: saya belajar keamanan untuk mempertahankan sistem yang saya bangun, bukan untuk menyerang orang lain. Di Indonesia, aktivitas hacking tanpa izin diatur dalam UU ITE, dan bahkan penetration testing pun harus dengan izin tertulis dari pemilik sistem. Kalau suatu hari nanti saya ingin menguji keamanan aplikasi, jalannya adalah lab pribadi atau program bug bounty yang resmi — bukan menjajal skill ke sistem orang.

Sumber

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *

Situs ini menggunakan Akismet untuk mengurangi spam. Pelajari bagaimana data komentar Anda diproses