Keamanan yang ditambahkan di akhir proyek sudah terlambat

Banyak proyek perangkat lunak punya urutan yang sama. Kebutuhan dikumpulkan, layar digambar, kode ditulis, lalu menjelang peluncuran seseorang bertanya: “Sudah aman?” Pertanyaan itu datang paling akhir. Jawabannya biasanya berupa uji penetrasi, daftar temuan, dan beberapa minggu perbaikan.

Kami percaya urutan ini terbalik. Tulisan ini menjelaskan alasannya, dan apa yang kami minta dari diri sendiri dan dari vendor mana pun.

Satu catatan jujur: kami kolektif baru dan belum punya portofolio. Argumen di bawah bersandar pada sumber publik yang kami tautkan, bukan pada klaim pengalaman.

Dua jenis kesalahan

OWASP, komunitas yang menerbitkan daftar risiko aplikasi web paling dikenal, membedakan dua hal. Ada desain yang tidak aman. Ada implementasi yang tidak aman. Dalam kategori A04 pada edisi 2021, OWASP menulis bahwa desain yang tidak aman tidak bisa diperbaiki oleh implementasi yang sempurna.

Contoh sederhana. Sebuah aplikasi menyimpan data penerima manfaat dan semua staf bisa melihat semuanya, karena memang begitu rancangannya. Kode yang bersih tidak mengubah fakta itu. Tidak ada celah teknis di sana. Yang salah adalah keputusan tentang siapa boleh melihat apa.

Kesalahan jenis ini lahir di rapat dan di papan tulis, bukan di editor kode. Pemindai otomatis tidak menemukannya, sebab kodenya melakukan persis yang diminta.

OWASP juga menyebut secure design sebagai budaya dan metodologi yang terus menilai ancaman. Mereka menganjurkan pemodelan ancaman dimasukkan ke sesi penyempurnaan kebutuhan, terutama untuk login, kendali akses, logika bisnis, dan alur utama. Dalam ringkasan kategori itu, komunitasnya juga mengajak bergerak melampaui “shift-left” di tahap kode menuju kegiatan sebelum kode ditulis.

Apa yang dikatakan kerangka kerja resmi

NIST, lembaga standar Amerika Serikat, menerbitkan Secure Software Development Framework (SSDF), dokumen SP 800-218 versi 1.1 pada Februari 2022. Abstraknya mengakui bahwa sedikit model siklus pengembangan yang membahas keamanan secara rinci. Karena itu, praktik pengembangan aman perlu ditambahkan ke setiap model.

SSDF mengelompokkan praktiknya dalam 4 kelompok:

• Prepare the Organization: menyiapkan orang, proses, dan teknologi.
• Protect the Software: menjaga kode dan rilis dari perubahan tanpa izin.
• Produce Well-Secured Software: membangun perangkat lunak dengan celah keamanan sesedikit mungkin saat dirilis.
• Respond to Vulnerabilities: menangani celah yang ditemukan setelah rilis.

Perhatikan urutannya. Kelompok pertama adalah persiapan, sebelum satu baris kode pun ditulis. Keamanan di sini adalah bagian dari cara bekerja, bukan fase terakhir.

NIST juga menulis bahwa praktik ini membantu mengurangi jumlah celah pada perangkat lunak yang dirilis, membatasi dampak celah yang lolos, dan mencegah celah yang sama muncul lagi. Dokumennya ditujukan juga bagi pembeli, supaya pembeli dan pemasok punya bahasa bersama.

Mengapa akhir proyek adalah tempat terburuk

Ini pendapat kami, dan kami berikan sebagai pendapat.

Di akhir proyek, 3 hal sudah terkunci. Anggaran hampir habis. Tenggat sudah dijanjikan ke atasan atau donor. Arsitektur sudah berdiri. Temuan keamanan yang menuntut perubahan arsitektur akan berhadapan dengan ketiganya, dan biasanya kalah. Hasilnya adalah daftar “risiko diterima” yang panjang.

Ada juga masalah insentif. Tim yang membangun ingin selesai. Penguji di akhir ingin menemukan sesuatu. Keduanya wajar, tetapi tidak ada yang bertanggung jawab atas pertanyaan yang lebih awal: data apa yang kita simpan, dan apakah kita perlu menyimpannya?

Batas dari pendekatan ini

Keamanan sejak awal tidak menghapus pengujian di akhir. Pengujian tetap perlu, karena orang tetap salah ketik, pustaka tetap punya celah, dan konfigurasi server tetap bisa keliru. Yang berubah adalah isi hasil pengujian. Bila desainnya sudah dipikirkan, temuan di akhir berupa perbaikan kecil. Bila belum, temuan di akhir berupa pertanyaan besar yang tidak punya anggaran.

Pendekatan ini juga tidak gratis. Ia menuntut waktu di minggu pertama, ketika semua orang ingin melihat layar yang bisa diklik. Kami menganggap waktu itu sebagai bagian dari pekerjaan, bukan tambahan. Klien yang menolaknya berhak menolak, tetapi ia perlu tahu apa yang ditukar.

Seperti apa “sejak baris pertama” dalam praktik

Kami tidak mau slogan ini jadi kosong. Maka inilah yang kami maksud, dalam hal yang bisa diperiksa:

• Sebelum desain layar, kami menulis daftar data yang disimpan dan siapa yang boleh mengaksesnya.
• Sebelum kode, kami menulis daftar “apa yang bisa salah” untuk alur paling sensitif. Itu bentuk paling sederhana dari pemodelan ancaman.
• Setiap perubahan kode diperiksa orang kedua.
• Pustaka pihak ketiga dicatat, lengkap dengan versinya.
• Saat serah terima, klien menerima catatan keamanan: apa yang dipasang, apa yang diuji, dan risiko yang masih tersisa.

Poin terakhir penting. Tidak ada sistem yang bebas risiko. Catatan yang jujur tentang risiko tersisa lebih berguna daripada janji “aman”.

CISA, badan keamanan siber Amerika Serikat, merumuskan prinsip serupa untuk pembuat perangkat lunak. Prinsip pertamanya: ambil tanggung jawab atas hasil keamanan pelanggan. Prinsip lainnya: keterbukaan dan akuntabilitas, serta kepemimpinan dari puncak organisasi. Kalimat itu tidak berhenti pada kode. Ia menyentuh siapa yang memutuskan dan siapa yang menanggung.

Empat pertanyaan untuk vendormu

Kamu tidak perlu paham kode untuk menanyakan ini. Jawaban yang berbelit-belit sudah menjadi informasi.

1. Kapan keamanan pertama kali dibahas dalam proyek ini? Jawaban yang baik menyebut tahap kebutuhan, bukan tahap pengujian.
2. Siapa yang memeriksa pekerjaan programmer, dan apakah orangnya berbeda?
3. Daftar pustaka dan plugin apa yang dipakai, dan siapa yang memantau pembaruannya?
4. Dokumen apa yang kami terima saat serah terima, dan apakah ada bagian tentang risiko yang masih tersisa?

Vendor yang punya proses akan menjawab dengan dokumen. Vendor yang tidak punya akan menjawab dengan kata sifat.

Yang dapat kamu kerjakan minggu ini

Pilih satu sistem milik organisasimu yang menyimpan data paling sensitif. Tulis di satu halaman:

• data apa yang tersimpan,
• siapa saja yang bisa membukanya hari ini,
• 3 hal terburuk yang bisa terjadi pada data itu.

Lalu periksa: apakah daftar siapa yang bisa membuka itu cocok dengan kenyataan di sistem? Selisih antara keduanya adalah temuan pertamamu, dan kamu menemukannya tanpa membayar pemindai apa pun.

Bila kamu ingin membahas hasilnya dengan kami, tulis lewat halaman kontak.