Review NIST SP-800-61 (2nd Revision), Panduan Penanganan Insiden Keamanan Komputer. Part 1

 1. Pendahuluan


        Computer Security Incident Handling Guide (Panduan Penanganan Insiden Keamanan Komputer), merupakan sebuah panduan yang dikeluarkan oleh National Institute of Standards and Technology. Panduan ini sering direferensikan oleh berbagai pihak untuk menyusun sebuah SOP penanganan insiden CyberSecurity di dalam organisasi. Penanganan insiden juga termasuk proses deteksi, analisis dan publikasi dengan persyaratan tertentu sehingga insiden yang sama dapat dikenali dan dicegah oleh organisasi lain. Review ini akan penulis bagi menjadi beberapa part karena dokumen aslinya yang sangat panjang.

2. Isi


Tujuan dan batasan dari dokumen ini berupa:
  1. Membantu organisasi dalam melakukan mitigasi resiko dari insiden keamanan komputer dengan memberikan panduan praktikal dalam merespon insiden secara efektif dan efisien.
  2. Memberikan fokus pembahasan dalam mendeteksi, analisis, prioritasi, dan penanganan insiden

Target pembaca dari dokumen ini ialah:
  1. Computer Security Incident Response Teams (CSIRT) (Tim Respon Insiden Keamanan Komputer)
  2. Administrator Sistem dan Jaringan
  3. Staff Technical Support
  4. Chief Information Security Officers (CISOs)
  5. Chief Information Officers (CIOs)
  6. Computer Security Program Managers.
  7. dan semua pihak yang bertanggung jawab terhadap persiapan dan/atau respons kepada insiden keamanan.

Pertimbangan pertama sebuah organisasi adalah membuat definisi spesifik tentang INSIDEN supaya mempunyai batasan-batasan yang jelas. Hal ini termasuk:
  • Layanan yang diberikan oleh CSIRT
  • Penentuan struktur tim dan model yang bisa memberikan layanan tersebut
  • dan memilih dengan mengimplementasi satu atau lebih CSIRT.
Dokumen ini juga memberikan saran untuk merawat dan meningkatkan kapabilitas yang telah ada pada organisasi.

2.1 Kejadian dan Insiden

Sebuah event/kejadian merupakan semua aktivitas yang terlihat pada sebuah sistem atau jaringan. Seperti:
  • User yang menyambung ke sebuah layanan file-sharing
  • Server yang menerima request web page
  • User mengirim email
  • Firewall memblokir sebuah percobaan koneksi
  • dan lain sebagainya.
Sedangkan adverse event (kejadian yang merugikan) merupakan aktivitas yang memliki/menyebabkan kerugian/konsekuen negatif. Seperti:
  • System crash
  • Packet floods
  • Penyalahgunaan akses sistem
  • Penyalahgunaan akses ke file sensitif
  • Eksekusi malware yang merusak informasi
  • dan lain serupa.
Dokumen ini hanya membahasan kejadian merugikan yang berhubungan dengan keamanan komputer, bukan yang disebabkan oleh variabel lain seperti kerusakan alam, kesalahan listrik dll.

        Sebuah insiden keamanan komputer (computer security incident) merupakan pelanggaran/ancaman yang mungkin akan segera terjadi yang melanggar kebijakan keamanan komputer, aturan yang disetujui atau praktek standar keamanan. 

2.2 Kebutuhan terhadap Responder Insiden

        Manfaat dari memiliki tim respon insiden adalah organisasi memiliki kemampuan untuk merespon insiden secara sistematis sehingga tindakan penyelesaian dapat dilakukan dan dampak kerugian bisa diminimalkan. Manfaat lainnya juga ialah dapat membuat organisasi lebih siap dalam mencegah dan menghadapi insiden yang akan datang berdasarkan informasi yang telah dikumpulkan.

Selain untuk urusan bisnis, organisasi juga harus mematuhi regulasi, hukum dan aturan dalam menghadapi ancaman keamanan informasi.

2.3 Aturan, Rencana dan Pembuatan Prosedur Responder Insiden

        Aturan yang mengatur responder insiden biasanya disesuaikan sendiri oleh organisasi yang berkaitan, namun sebagian besar memiliki aturan yang sama seperti berikut:
  1. Pernyataan komitmen manajemen
  2. Tujuan dan objektif dari aturan
  3. Batasan aturan (untuk pihak dan aturan apa yang berlaku dan dalam kondisi apa)
  4. Definisi insiden keamanan komputer dan pengertian yang berkaitan lainnya
  5. Struktur organisasi dan definisi peran, tanggung jawab serta level otoritas
  6. Prioritas dan rating insiden
  7. Pengukuran performa
  8. Laporan dan form kontak.
        Organisasi harus memiliki pendekatan yang resmi, fokus dan terkoordinasi dalam merespon insiden, termasuk rencana respon insiden yang menyajikan roadmap untuk implementasi kapabilitas respon insiden. Rencana respon insiden harus memiliki elemen berikut:
  1. Misi
  2. Strategi dan tujuan
  3. Persetujuan manajemen senior
  4. Pendekatan organisasi dalam merespon insiden
  5. Bagaimana cara tim respon insiden berkomunikasi dengan departemen lain dan organisasi lain
  6. Metrik untuk mengukur tingkat efektif dan kapabilitas tim respon insiden
  7. Roadmap untuk meningkatkan kapabilitas tim respon insiden
  8. Bagaimana program sesuai dengan keseluruhan organisasi.
Saat organisasi sudah mengembangkan rencana dan mendapat persetujuan dari manajemen, organisasi harus mengimplementasikan dan mereview setidaknya SETAHUN SEKALI untuk memastikan organisasi mengikuti roadmap untuk meningkatkan kapabilitas dan memenuhi tujuan dari tim respon insiden.

        Organisasi harus membuat SOP (Standard operating procedures) berdasarkan aturan dan rencana dari tim respon insiden. SOP terdiri dari proses teknikal spesifik, teknik, ceklis dan form yang dapat digunakan oleh tim respon insiden. SOP harus detail dan komprehensif untuk memastikan prioritas dari organisasi tercerminkan dalam operasi. Mengikuti SOP harus dan dapat meminimalisir error. SOP harus divalidasi dan diuji akurasi dan kegunaaannya, kemudian disebarkan kesemua member tim respon insiden. 

        Organisasi harus menginformasikan ke pihak lain terkait insiden, seperti menghubungi pihak berwajib, media dan tenaga ahli. Contoh lain dari pihak yang biasa dihubungi dalam insiden adalah ISP, vendor software yang memiliki celah keamanan, dan tim respon insiden lainnya. Organisasi mungkin juga dapat membagikan indikator insiden yang berkaitan dengan pihak lain untuk meningkatkan deteksi dan analisis. Namun, tim respon insiden harus berdiskusi dan mendapat persetujuan terlebih dahulu dengan departemen hubungan masyarakat, legal dan manajemen organisasi. Tim respon insiden harus melakukan dokumentasi semua kontak dan komunikasi dengan pihak luar untuk tujuan pertanggung jawaban dan pembuktian.


Media

        Tim respon insiden harus menjalin komunikasi dengan pihak media sesuai dengan prosedur dan kebijakan dari organisasi. Biasanya, organisasi menempatkan 1 kontak POC dan 1 kontak cadangan. Adapun untuk POC perlu dipertimbangkan untuk:
  1. Terlatih dalam membagikan informasi dengan media seperti tidak memberikan informasi sensitif organisasi terkait detail teknis mitigasi insiden yang dapat mengundang serangan lanjutan/lain, memberikan pernyataan positif secara efektif untuk kepercayaan publik.
  2. Menetapkan prosedur pemberian informasi singkat kepada kontak media terkait insiden terkait sebelum melakukan diskusi dengan media
  3. Menjaga pernyataan status terkini terkait insiden sehingga media mendapatkan informasi yang konsisten dan update
  4. Mengingatkan semua staff tentang prosedur umum dalam menghadapi pihak media
  5. Melakukan tiruan keadaan interview dan press conference terkait penanganan insiden. Adapun untuk contoh pertanyaan yang biasa diberikan oleh pihak media adalah:
  • Siapa yang menyerang dan kenapa?
  • Kapan terjadi serangan? Bagaimana? Apakah karena kurangnya keamanan yang ada pada organisasi?
  • Seberapa luas serangan ini berdampak? Apa langkah yang diambil untuk pencegahan insiden yang sama di masa yang akan datang?
  • Apa dampak dari serangan ini? Apakah ada data (PII) yang tersebar? Berapa perkiraan kerugian dari insiden ini?

Pihak Berwajib / Badan Hukum

        Tim respon insiden harus menyiapkan POC untuk menjalin komunikasi dengan Pihak Berwajib / Badan Hukum untuk memenuhi prosedur hukum yang berlaku. Kebanyakan, organisasi memilih 1 POC untuk bertanggung jawab menjalin komunikasi dengan Pihak Berwajib / Badan Hukum. POC ini harus familiar dengan prosedur laporan yang relevan dengan Pihak Berwajib / Badan Hukum. Organisasi tidak disarankan untuk menghubungi lebih dari 1 PB / BH karena dapat menimbulkan konflik yuridiksi.

Organisasi Respon Insiden (diluar organisasi)

        Semua organisasi disarankan untuk melaporkan insiden ke badan CSIRT yang sesuai di tempat organisasi tersebut berada. Organisasi juga harus membuat kebijakan untuk mengatur siapa dan bagaimana insiden dilaporkan. Contoh pada dokumen ini karena dibuat di USA maka disarankan untuk melaporkan insiden ke US-CERT. Untuk di Indonesia, saat tulisan ini dibuat penulis hanya menemukan beberapa CSIRT pemerintahan yang menaungi badan pemerintahan saja seperti GOV-CSIRT milik BSSN.

ISP

        Organisasi mungkin perlu bantuan dari ISP untuk memblokir jaringan sumber serangan atau melacak sumber serangan.

Pemilik Alamat Sumber Serangan

        Jika sumber serangan berasal dari alamat diluar organisasi, tim respon insiden mungkin perlu berkomunikasi dengan POC pemilik alamat sumber serangan untuk memberitahu terhadap aktivitas yang terjadi dan meminta untuk mengumpulkan bukti.

Vendor Software

        Tim respon insiden perlu berbicara kepada tim pengembang software untuk kegiatan yang mencurigakan yang disebabkan oleh software mereka. Komunikasi ini mungkin menyertakan pertukaran informasi seperti log tertentu atau alert FP untuk mendeteksi signature serangan. Hal ini membantu vendor software untuk melakukan patch keamanan jika memang benar insiden disebabkan melalui celah software mereka serta membantu organisasi menangani insiden.

Para Pihak Lain yang terdampak

        Organisasi perlu menginformasikan kepada pihak lain yang terdampak terhadap insiden yang terjadi, seperti pelanggan, stakeholder dan lainnya.


2.4 Struktur Tim Respon Insiden

        Tim respon insiden harus bisa dihubungi oleh tiap orang yang menemukan atau mencurigai adanya insiden yang telah terjadi. Satu atau lebih anggota tim, tergantung dari besarnya insiden dan kesediaan anggota, menangani insiden tersebut. Responder akan menganalisis data, menentukan dampak dan bertindak sesuai dengan batasan dampak dan mengembalikan services ke keadaan normal. Keberhasilan responder tergantung dengan partisipasi dan kooperasi dari tiap individual dalam organisasi.

Model Tim

  1. Central Incident Response Team. Satu tim respon insiden yang menangani keseluruhan organisasi, cocok untuk organisasi dengan skala kecil dengan perbedaan sumber daya komputer yang minimal.
  2. Distributed Incident Response Team. Memiliki lebih dari 1 tim respon insiden. Cocok untuk organisasi besar dengan lokasi cabang berbeda, dengan banyak variasi sumber daya komputer. Namun, semua tim harus menjadi bagian dari satu koordinasi sehingga proses penanganan insiden dapat dilakukan secara konsisten dan pertukaran informasi dapat dilakukan dengan tim di organisasi.
  3. Coordinating Team. Satu tim respon insiden memberikan saran kepada tim lain tanpa harus memiliki otoritas diantara mereka. Tidak dibahas secara detail pada dokumen ini.

Model Staff Tim Respon Insiden
  1. Employee. Organisasi melakukan semua pekerjaan respon insiden dengan bantuan teknis dan administrasi terbatas dari kontraktor.
  2. Partially Outsourced. Organisasi melakukan hire outsource beberapa bagian dari tim respon insiden.
  3. Fully Outsourced. Organisasi sepenuhnya mengandalkan tenaga outsource untuk melakukan respon insiden, biasanya kontraktor lapangan. Model ini biasa digunakan ketika organisasi perlu full-time, onsite tim respon insiden namun tidak memiliki pegawai yang cukup berkualifikasi. Perlu diasumsikan bahwa organisasi harus memiliki pegawai yang mengawasi kerja outsource.

Model Seleksi Tim

  1. Kebutuhan ketersediaan 24/7. Kebanyakan staff tim respon diperlukan ketersediaan 24/7, ini berarti bisa lewat dihubungi melalui HP atau juga bisa diperlukan kehadiran onsite.
  2. Full Time vs Part Time Member. Organisasi dengan dana terbatas mungkin hanya dapat memiliki staff tim respon insiden yang separuh waktu. Contohnya adalah staff IT Help Desk dapat menjadi POC untuk pelaporan insiden.
  3. Employee Morale. Pekerjaan tim respon insiden sangatlah membuat stress, mengurangi pekerjaan administrasi dapat mengurangi beban kerja staff tim respon insiden sekaligus menjadi booster moral.
  4. Biaya. Organisasi mungkin akan gagal mendanai tim respon insiden untuk biaya spesifik seperti training dan maintaining skill. Tim respon insiden harus memiliki pengetahuan lebih dari kebanyakan IT Staff seperti menggunakan tools respon insiden dan digital forensic.
  5. Staff Expertise. Staff organisasi biasanya memiliki pengetahuan yang lebih baik tentang lingkungan organisasi daripada outsource, yang bisa menguntungkan dalam mendeteksi false positif yang terlibat pada kebiasaan tertentu organisasi pada taget kritis.


Pada part 1 ini, penulis menyampaikan review yang sudah diusahakan untuk sesingkat mungkin tanpa mengurangi bagian penting. Part 1 hanya mengcover 30% dokumen aslinya.

Komentar

Komentar baru tidak diizinkan.

Postingan populer dari blog ini

OSPF Mikrotik v7

Gambar
 Pendahuluan      Pada saat penulis mendapatkan pelatihan MTCNA dan MTCRE kemarin, rata-rata mikrotik yang digunakan terpasang RouterOS v6 dan v5. Ketika penulis melakukan review terhadap materi dengan langsung implementasi pada perangkat virtual yang dimiliki, ternyata RouterOS v7 terjadi perubahan sedikit terutama pada setup routing OSPF. Pada tulisan ini, penulis akan mencoba mengimplementasikan kembali ilmu yang pernah dipelajari tentang routing OSPF antar perangkat mikrotik di versi RouterOS v7. Pembahasan Penulis melakukan implementasi pada lingkungan virtual GNS3. Topologi diatur seperti gambar dibawah ini: Gambar 1. Topologi pada GNS3 (abaikan cisco di R1 karena penulis masih bingung integrasinya) Semua mikrotik sudah diatur pada konfigurasi dasar (IP, DNS, DHCP Client+Server, NAT). Pada konfigurasi dasar, vPC yang tersambung pada mikrotik masih tidak bisa berkomunikasi satu sama lain karena tidak dibuat routing yang mengarah pada jaringan mereka masing-masin...
Read more »

DoH dengan Mikrotik

Gambar
 Pendahuluan Disclaimer: Penulis membagikan informasi ini untuk tujuan edukasi, segala tindakan yang melanggar etika dan hukum berada sepenuhnya di tanggung jawab pembaca yang mencoba dan melakukan.     DNS yang berfungsi mentranslasi sebuah alamat website menjadi IP Address merupakan hal terpenting dalam bagian dari jaringan internet. Namun jika diperhatikan, traffic DNS pada umumnya yang menggunakan port 53 tidak dienkripsi sedangkan di masa sekarang traffic yang tidak terenkripsi sudah dirasa sangat tidak aman. Gambar 1. Contoh traffic DNS pada umumnya yang tidak terenkripsi pada port 53. Hal ini membuat traffic DNS rentan untuk diketahui oleh pihak lain ataupun dimodifikasi oleh pihak yang tidak bertanggung jawab. Selain itu, DNS yang tidak terenkripsi dimanfaatkan oleh beberapa pihak ISP untuk melakukan pengalihan traffic agar pelanggan tidak mengunjungi situs tersebut ( dibaca: diblokir/pengendalian konten/internet positif) . Hal ini dilakukan oleh ISP dengan mema...
Read more »

VRRP di Mikrotik, Redundansi Gateway Jaringan

Gambar
 Pendahuluan      Jika pada  post sebelumnya penulis menyajikan redundansi terhadap routing/link jaringan melalui routing OSPF, maka kali ini penulis akan menunjukkan bagaimana redundansi terhadap perangkat router yang menjadi gateway banyak client. Ketika suatu perangkat router mengalami fail maka otomatis packet dibawah router tidak bisa diteruskan, sehingga diciptakan protokol VRRP (Virtual Router Redundancy Protocol) untuk menanggulangi masalah tersebut. Protokol ini akan menyiapkan suatu perangkat router lain sebagai backup apabila router utama gagal. Perangkat-perangkat dibawahnya tidak perlu mengganti IP Gateway karena dengan protokol ini akan disematkan IP pada interface virtual yang dihandle oleh lebih dari 1 router. Pembahasan     Pada percobaan kali ini, dibuat topologi seperti berikut: Gambar 1 . Topologi jaringan yang akan dipasang VRRP pada GNS3. Keterangan: Jaringan client dan router akan mengambil 10.10.1.0/28 IP untuk interface VRRP a...
Read more »