Peringatan keamanan muncul pada sebuah aplikasi internal. Tim segera memeriksa aktivitas yang mencurigakan, tetapi satu pertanyaan belum terjawab: aplikasi tersebut terhubung ke sistem apa saja?

Diagram arsitektur yang tersedia sudah lama tidak diperbarui. Catatan integrasi API tersebar di beberapa tempat. Orang yang dahulu membangun sistem telah berpindah tim. Sebelum menentukan langkah penanganan, tim harus lebih dulu menyusun kembali gambaran tentang sistem yang sedang mereka lindungi.

Dalam situasi seperti ini, dokumentasi sistem yang buruk mengubah waktu respons menjadi waktu pencarian informasi. Penundaan dapat terjadi saat tim menilai luasnya dampak, memilih cara membatasi ancaman, hingga menentukan pihak yang berwenang mengambil keputusan.

Insiden Tidak Mengikuti Batas Satu Aplikasi

Aktivitas mencurigakan mungkin pertama kali terlihat pada satu server atau aplikasi. Namun, sistem tersebut bisa menggunakan layanan identitas bersama, bertukar data melalui API, atau terhubung dengan penyedia eksternal.

Tanpa peta hubungan antarsistem yang mutakhir, tim sulit memastikan apakah pemeriksaan perlu diperluas. Mereka harus mencari tahu alur data dan dependensi pada saat yang sama ketika ancaman mungkin masih berlangsung.

Masalahnya bukan semata-mata ketiadaan diagram. Inventaris aset yang tidak mencantumkan pemilik, lingkungan, dan fungsi sistem juga membatasi kemampuan tim untuk menentukan prioritas. Sebuah layanan yang tampak kecil secara teknis dapat berperan penting dalam proses bisnis.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia.

Pengujian keamanan kerap memperlihatkan bahwa pemahaman tentang suatu aplikasi terkumpul pada beberapa orang saja. Ketika hubungan antara aplikasi, API, akun layanan, dan infrastruktur belum terdokumentasi dengan baik, penelusuran risiko menjadi lebih lambat. Kondisi serupa dapat menyulitkan tim saat menghadapi insiden nyata.

Keputusan Cepat Memerlukan Informasi yang Tepat

Saat menemukan indikasi penyalahgunaan akun, menonaktifkan akun tersebut mungkin terlihat sebagai langkah yang jelas. Akan tetapi, bagaimana jika akun yang sama digunakan oleh beberapa layanan penting? Apakah penghentiannya akan mengganggu transaksi, pelaporan, atau akses pengguna?

Tim respons perlu mengetahui dependensi sebelum menjalankan tindakan pembatasan. Tanpa informasi itu, mereka menghadapi pilihan yang sulit: bertindak segera dengan risiko mengganggu layanan lain, atau menunda tindakan sambil menelusuri dampaknya.

Dokumentasi yang baik tidak menentukan keputusan secara otomatis. Fungsinya adalah menyediakan konteks agar tim dapat menilai pilihan dengan lebih cepat. Catatan mengenai penggunaan akun layanan, alur integrasi, serta layanan yang bergantung pada suatu komponen dapat sangat membantu pada tahap ini.

Hal yang sama berlaku dalam pemulihan. Menghidupkan kembali aplikasi belum tentu cukup jika basis data, layanan identitas, dan integrasi pendukung belum siap. Urutan pemulihan perlu disusun berdasarkan hubungan antarsistem, bukan perkiraan saat keadaan mendesak.

Penanggung Jawab yang Tidak Jelas Memperpanjang Eskalasi

Penanganan insiden melibatkan keputusan teknis dan bisnis. Ada tindakan yang dapat dilakukan langsung oleh tim keamanan, tetapi ada pula yang membutuhkan persetujuan pemilik layanan atau koordinasi dengan penyedia teknologi.

Apabila daftar penanggung jawab tidak diperbarui, tim harus mencari siapa yang memahami sistem, siapa yang dapat menyetujui penghentian sementara, dan siapa yang perlu menerima informasi tentang dampak operasionalnya. Percakapan berulang untuk mencari orang yang tepat dapat menghambat langkah berikutnya.

Setiap sistem kritis sebaiknya memiliki pemilik teknis, pemilik proses bisnis, dan jalur eskalasi yang jelas. Informasi kontak pengganti juga penting ketika penanggung jawab utama tidak tersedia. Dengan demikian, keputusan tidak bergantung pada kebetulan siapa yang sedang dapat dihubungi.

Dokumen yang Berguna Tidak Harus Panjang

Perusahaan tidak perlu menunggu seluruh dokumentasi sempurna sebelum memperbaiki kesiapan respons insiden. Prioritaskan terlebih dahulu sistem yang menopang layanan penting atau memproses data sensitif.

Untuk tiap sistem tersebut, tim perlu dapat menemukan jawaban atas beberapa pertanyaan berikut:

• Apa fungsi sistem dan data apa yang diproses?
• Di lingkungan mana sistem berjalan, dan siapa pemiliknya?
• Aplikasi, API, akun layanan, dan pihak eksternal apa yang terhubung?
• Di mana log yang relevan dapat diperiksa oleh tim berwenang?
• Apa dampaknya jika sistem diisolasi atau dihentikan?
• Siapa yang perlu dilibatkan saat pembatasan dan pemulihan?

Jawaban tersebut dapat disajikan dalam inventaris aset, diagram alur data, daftar dependensi, serta prosedur respons yang ringkas. Yang terpenting, dokumen mudah ditemukan oleh pihak berwenang dan sesuai dengan kondisi sistem yang sebenarnya.

Informasi sensitif tetap memerlukan perlindungan. Dokumentasi operasional tidak perlu memuat kata sandi atau kredensial. Cukup jelaskan pihak yang berwenang dan cara memperoleh akses melalui prosedur yang aman.

Perubahan Sistem Harus Diikuti Perubahan Dokumentasi

Sebuah diagram dapat akurat ketika pertama kali dibuat, lalu kehilangan kegunaannya setelah beberapa kali perubahan aplikasi. Integrasi baru ditambahkan, layanan dipindahkan, hak akses berubah, sementara catatannya tetap sama.

Karena itu, pembaruan dokumentasi perlu menjadi bagian dari proses perubahan sistem. Ketika tim menambah API, mengganti pemilik layanan, atau mengubah alur data, catatan terkait diperbarui pada kesempatan yang sama. Simulasi insiden kemudian dapat digunakan untuk menguji apakah informasi tersebut benar-benar membantu tim mengambil keputusan.

Dokumentasi sistem bukan sekadar pelengkap setelah proyek selesai. Dalam penanganan insiden siber, dokumentasi memberi tim pemahaman awal tentang apa yang terdampak, siapa yang harus dihubungi, dan tindakan apa yang mungkin memengaruhi layanan lain. Semakin sedikit waktu yang dihabiskan untuk mencari jawaban dasar, semakin besar ruang bagi tim untuk berfokus pada analisis dan penanganan ancaman.

Fourtrezz, melalui layanan vulnerability assessment dan penetration testing, dapat membantu perusahaan mengidentifikasi kelemahan keamanan pada aplikasi dan infrastruktur serta memahami risiko yang perlu diprioritaskan. Jika perusahaan Anda ingin meninjau keamanan sistem dan hubungan antarkomponen yang masuk dalam cakupan pengujian, diskusikan kebutuhan tersebut bersama tim Fourtrezz.

Hubungi Fourtrezz:
Website: www.fourtrezz.co.id
Telepon/WhatsApp: +62 857-7771-7243
Email: [email protected]