Dalam prosesnya, kita sering ditanya pertanyaan: bagaimana menerapkan penganalisa statis dalam pengembangan sehingga
semuanya baik-baik saja.
Kita sudah bicara tentang mengapa analisa statis diperlukan untuk pengembangan yang aman. Artikel ini akan berguna jika Anda memilih penganalisa statis atau sudah berencana untuk mengimplementasikannya. Bagaimana cara mengatur proses sehingga kerentanan yang ditemukan dalam kode akhirnya diperbaiki? Pada artikel ini, kami akan mencoba membantu Anda mengatasi masalah ini.
Apa yang akan datang?
Menerapkan penganalisa sedemikian rupa sehingga kerentanan diperbaiki secara stabil bukanlah hal yang cepat. Dari pengalaman, kita dapat mengatakan bahwa dibutuhkan dari beberapa minggu hingga beberapa bulan. Jika Anda menerapkan alat analisis di perusahaan besar, bersiaplah untuk serangkaian persetujuan. Bagaimanapun, ini adalah ratusan basis kode yang perlu dianalisis, dan lusinan tim dengan pesanan pengembangan mereka sendiri.
Untuk menambahkan tahap pengembangan baru - analisis statis, Anda harus mempelajari bagaimana proses masing-masing tim bekerja dan mengusulkan solusi yang nyaman bagi semua orang. Di perusahaan kecil, tatanan pengembangan yang sudah ada mungkin tidak ada sama sekali. Implementasi alat analisis dapat menjadi alasan untuk membangun suatu proses. Agar integrasi menjadi lebih lembut, kami menyarankan Anda untuk mencari tahu penganalisa mana yang memiliki kemampuan untuk ini.
Apa saja opsi integrasi?
Biasanya, penganalisa mengasumsikan antarmuka non-grafis (CLI, REST) untuk integrasi ke dalam proses apa pun. Ada penganalisa dengan integrasi siap pakai: dengan alat bangun dan lingkungan pengembangan, dengan sistem kontrol versi (Git, SVN), server CI / CD (Jenkins, TeamCity, TFS), sistem manajemen proyek (Jira) dan manajemen pengguna (Direktori Aktif). Semakin bermanfaat bagi perusahaan Anda, semakin mudah untuk mengatur semuanya.
Bagaimana Anda bisa membangun suatu proses?
Pertimbangkan situasi standar: departemen yang terlibat adalah keamanan informasi, manajemen rilis dan pengembangan. Sebagai aturan, pelanggan dari implementasi analisa adalah keamanan informasi (IS). Tugasnya adalah menyetujui siapa, kapan, dan apa yang akan dilakukan. Kami membedakan langkah-langkah berikut:
memulai analisis, memproses hasil analisis, membuat permintaan untuk memperbaiki kerentanan, memperbaiki kerentanan, memeriksa koreksi . Pertimbangkan setiap langkah lebih terinci.
Langkah 1. Jalankan analisis
Anda dapat menjalankan analisis secara manual atau otomatis. Pendekatan memiliki pro dan kontra mereka.
Secara manualDia sendiri ingat penganalisa, dia mengunduh kode sendiri, dia pergi dan melihat hasilnya.
Jika ada sekitar selusin proyek di perusahaan dan satu petugas keamanan dipercaya untuk memantau keamanan, skenario seperti itu mungkin terjadi. Jika ada sekitar seratus proyek, Anda perlu mengonfigurasi otomatisasi.
OtomatisPutuskan seberapa sering dan pada titik mana Anda perlu menganalisis kode. Misalnya, sebelum memasuki lingkungan yang produktif, sesuai dengan jadwal yang diberikan (seminggu sekali) atau setelah setiap perubahan.
Jika aplikasi ini jarang diperbarui, tetapi Anda juga perlu memantau keamanannya, konfigurasikan analisis jika ada perubahan.
Jika banyak orang bekerja pada kode, banyak cabang dibuat, perubahan sering dituangkan - lebih baik sering menganalisis, tetapi tidak mengganggu pengembangan. Misalnya, pada saat membuat permintaan menggabungkan dengan cabang utama atau ketika status tugas di cabang ini berubah. Integrasi dengan sistem kontrol versi atau dengan sistem manajemen proyek akan membantu Anda dengan ini. Integrasi dengan CI / CD akan membuat analisis salah satu langkah pembangunan.
Atur jadwal sehingga Anda punya waktu untuk memproses hasilnya.
Langkah 2. Proses hasil analisis
Jangan menginstruksikan pengembang untuk segera memperbaiki semua kerentanan yang ditemukan. Biarkan petugas keamanan memverifikasi mereka terlebih dahulu. Hasil analisis pertama mungkin tampak menyedihkan: lusinan kritis, ratusan kerentanan kurang kritis, dan ribuan positif palsu. Apa yang harus dilakukan di sini? Kami menyarankan untuk memperbaiki kerentanan secara bertahap. Tujuan utamanya adalah untuk mencapai ketiadaan kerentanan dalam kode lama dan baru. Pada tahap awal, verifikasi kritis (masih tidak aman dengan mereka) dan kerentanan baru (kode baru lebih mudah untuk diperbaiki).
Gunakan filter. Urutkan kerentanan berdasarkan tingkat keparahan, berdasarkan bahasa, file, dan direktori. Alat yang lebih canggih akan menunjukkan kepada Anda kerentanan hanya dalam kode baru, menyembunyikan kerentanan di perpustakaan pihak ketiga. Filter telah diterapkan, tetapi apakah masih ada banyak kerentanan?
Lihat kerentanan yang paling mungkin. Ada analis yang mengevaluasi kemungkinan false positive. Jika ada banyak kerentanan, dan tingkat kekritisan hampir sama untuk semua orang, filter hasilnya menggunakan metrik ini. Jadi Anda dengan cepat memproses kerentanan yang paling mungkin (lihat tangkapan layar di bawah).
Gunakan status verifikasi. Untuk menangkap hasil verifikasi, biasanya penganalisa menawarkan untuk bekerja dengan status kerentanan: konfirmasi atau tolak sebagai false positive. Sebagai aturan, pekerjaan yang dilakukan harus dilestarikan selama pemindaian ulang.
Langkah 3. Buat permintaan perbaikan kerentanan
Jika pengembang memulai analisis kodenya dan segera memperbaiki kerentanannya, maka tentu saja Anda tidak perlu membuat permintaan yang tidak perlu.
Jika petugas keamanan meninjau dan memverifikasi hasilnya, maka untuk koreksi lebih lanjut dari kerentanan yang dikonfirmasi biasanya perlu mengatur tugas. Kami telah berulang kali menghadapi kenyataan bahwa pada tahap inilah kesulitan muncul.
Formulir permintaanAda perusahaan di mana tugas-tugas besar untuk tahap diperbaiki dalam sistem manajemen proyek (misalnya, Jira). Dan untuk subtugas dan bug, misalnya, Masalah GitLab digunakan, akses yang hanya dapat diakses oleh pemimpin tim dan timnya. Itu juga terjadi bahwa perakitan tidak mungkin tanpa membuat tugas terpisah dalam sistem manajemen proyek. Penganalisa dapat memiliki integrasi dengan mana Anda dapat membuat pertanyaan yang diperlukan segera di antarmuka.
Seringkali dalam perusahaan yang sama dengan berbagai kelompok pengembangan, masing-masing dari mereka memiliki prosedur sendiri untuk melaksanakan tugas-tugas kerja. Dan Anda perlu beradaptasi dengan semua orang. Muncul pertanyaan:
- Apakah layak untuk mengalokasikan proyek terpisah untuk memperbaiki kerentanan atau membuat tugas di yang sudah ada?
- Apakah kerentanan bug yang dikenal atau entitas baru?
- Buat tugas terpisah untuk setiap kerentanan atau kelompok yang serupa?
- Apa yang harus saya berikan sebagai deskripsi masalah: tautan ke kerentanan di antarmuka penganalisa atau tempat dalam kode dan jelaskan masalahnya secara singkat?
- Dan apakah pengembang memerlukan akses ke hasil - cukup kirim laporan PDF dengan teks “lihat halaman 257 "dan itu sudah cukup?
Tentu saja, itu tergantung pada bagaimana proses dalam tim disesuaikan, sistem pelacakan kesalahan apa yang digunakan.
Jika kode ini ditulis oleh kontraktor untuk siapa akses ke sistem internal minimal, skema dengan laporan PDF cocok. Biasanya, untuk laporan, Anda dapat memilih kerentanan yang menarik bagi Anda dan segera mengirimkannya ke alamat yang diinginkan dari antarmuka penganalisa.
Jika perusahaan tidak dapat melakukan satu langkah pun tanpa membuat proyek untuk jenis tugas tertentu dengan jumlah sumber daya tertentu, maka Anda harus mencari alat dengan integrasi untuk sistem Anda. Integrasi yang paling fleksibel akan menghasilkan deskripsi tugas untuk Anda (mereka bahkan tidak akan melupakan tautan ke kode sumber dalam sistem kontrol versi) dan akan memungkinkan Anda untuk mengisi semua bidang yang diperlukan. Pilih jenis tugas, tentukan induk, artis, dan bahkan versi rilis.
Biaya dan ketentuan tenaga kerjaJika tim memutuskan untuk memberikan penilaian biaya tenaga kerja untuk setiap tugas, maka tugas memperbaiki kerentanan perlu dilakukan hal yang sama. Sepanjang jalan, pengembang memverifikasi kerentanan. Terkadang pada langkah ini ternyata kerentanannya salah atau tidak mungkin untuk dieksploitasi.
Tetapi sebagai suatu peraturan, sumber daya masih belum cukup untuk segera memperbaiki semua kerentanan. Karena itu, penting juga untuk mengoordinasikan prioritas mereka.
Tugas-tugas ditentukan oleh biaya tenaga kerja dan prioritas - maka mereka yang bertanggung jawab atas tanggal rilis (ini mungkin manajer proyek atau pimpinan tim yang sama) memutuskan apa yang harus diperbaiki dan kapan. Pada awalnya, menggunakan analisa, kami menyarankan Anda untuk tidak menunda rilis, jika tidak semua kerentanan diperbaiki.
Langkah 4. Perbaiki kerentanan
Cara mengalokasikan sumber daya dengan benar: menghubungkan orang baru atau mempercayakan kepada mereka yang sudah terlibat dalam pembangunan adalah masalah anggaran. Satu hal yang benar: jika perusahaan mengalokasikan sumber daya untuk pemasangan alat analisis, Anda perlu mempersiapkan biaya untuk memperbaiki kerentanan. Cara yang mungkin adalah dengan meletakkan persentase waktu untuk memperbaiki kerentanan sebagai pekerjaan dengan hutang teknis.
Ada dua skenario: segera diperbaiki dalam proses pengembangan atau atas permintaan petugas keamanan. Memperbaiki kerentanan selama pengembangan adalah skenario ideal. Segera ditemukan - segera diperbaiki. Pengembang memindai cabang fiturnya sebelum meminta penggabungan dengan cabang utama. Ini juga dapat diotomatisasi melalui integrasi: dengan lingkungan pengembangan, dengan alat bangun, sistem kontrol versi, atau dengan CI / CD.
Skenario lain adalah menganalisis cabang pengembangan utama setelah semua perubahan. Seorang petugas keamanan atau pemimpin tim meninjau hasilnya dan membuat tugas untuk memperbaiki kerentanan. Skenario ini lebih memakan waktu. Pada input pengembang adalah kode sumber, tugas koreksi, dan hasil analisis. Untuk pengembang, tugas untuk memperbaiki kerentanan tidak jauh berbeda dengan memperbaiki bug.
Langkah 5. Verifikasi perbaikannya
Anda perlu memastikan bahwa kerentanan benar-benar diperbaiki dan yang baru belum muncul di tempatnya. Ada hasil analisis kode yang diperbaiki. Apa yang harus dicari? File dan nomor baris kerentanan? Atau cari berdasarkan nama kerentanan? Itu mungkin dan begitu. Tetapi jika kode diubah, garis dengan kerentanan dapat bergeser, dan masih ada banyak kejadian satu kerentanan. Beberapa analis mungkin menunjukkan kerentanan "tetap". Setuju, sehingga Anda dapat memeriksa perbaikan kerentanan lebih cepat (lihat tangkapan layar).
Contohnya
Berikut adalah dua skenario yang mungkin.
Skenario 1
Tim menggunakan Git untuk kontrol versi, Jira untuk proyek dan manajemen tugas. Jenkins mengkonfigurasi jadwal pembuatan. Misalnya, sehari sekali jika ada perubahan di cabang. Sebagai langkah tambahan, awal dari penganalisis ditunjukkan.
Petugas keamanan meninjau hasil analisis cabang utama (master atau pengembangan), dan pengembang meninjau cabang fitur-fiturnya.
Pengembang memperbaiki kerentanan jika perlu. Jika penganalisa dapat memfilter kerentanan berdasarkan permintaan: hanya tampilkan kerentanan baru atau tidak menunjukkan kerentanan di perpustakaan pihak ketiga, tampilkan kerentanan di direktori atau file tertentu - pengembang akan dapat dengan cepat melihat hasil yang menarik baginya. Jadi, probabilitas koreksi lebih tinggi.
Petugas keamanan meninjau hasil analisis cabang utama. Menggunakan integrasi dengan Jira, petugas keamanan menciptakan tugas manajemen kerentanan dari antarmuka penganalisa. Berikutnya adalah koordinasi tenggat waktu dan prioritas.
Ketika kerentanan diperbaiki dan kode baru melewati semua tahap pengembangan internal (tinjauan dari pemimpin tim, pengguna dan pengujian regresi), petugas keamanan harus memastikan bahwa kerentanan tidak lagi ada. Penulis menutup tugas yang sudah selesai.
Skenario 2
Kode untuk perusahaan ditulis oleh sekelompok kontraktor. Timlid berinteraksi dengan pengembang melalui email dan menggunakan GitLab untuk kontrol versi. Kontraktor tidak memiliki akses ke sistem manajemen proyek internal (Jira).
Petugas keamanan atau ketua tim sendiri meninjau hasil analisis cabang pengembangan utama. Kontraktor tidak memiliki akses ke penganalisa. Jika ada kerentanan yang perlu diperbaiki, petugas keamanan mengirim laporan PDF dengan hasil analisis kepada pemimpin tim atau langsung ke pengembang.
Dari laporan tersebut, pengembang menemukan di mana kerentanan ditemukan, terdiri dari apa dan bagaimana cara memperbaikinya. Berharga jika untuk kerentanan terkait dengan aliran data tidak aman (misalnya, injeksi SQL), skema distribusi akan diturunkan ke dalam laporan: dari sumber data hingga penggunaannya dalam pemanggilan fungsi / metode (lihat tangkapan layar).
Setelah memperbaiki kerentanan, ketua tim memberi tahu petugas keamanan bahwa sudah waktunya untuk memeriksa hasil pemindaian ulang.
Apa lagi yang penting?
Untuk membangun interaksi antara keamanan informasi dan pengembangan. Penting bahwa kedua belah pihak tertarik untuk memperbaiki kerentanan. Nah, jika itu bukan hanya permintaan, tapi juga komunikasi langsung.
Jangan abaikan peran pengguna. Penganalisa yang baik harus memiliki kemampuan untuk membedakan hak. Kecil kemungkinan bahwa kontraktor akan memerlukan hak administrator atau hasil analisis sistem internal. Untuk mengedit hasil - untuk mengubah kekritisan dan status - itu sudah cukup untuk memungkinkan petugas keamanan dan pimpinan tim. Prinsip hak minimum belum dibatalkan.
Jika perusahaan besar dan menggunakan sistem manajemen pengguna (misalnya, Direktori Aktif), pertimbangkan alat dengan integrasi yang sudah jadi. Anda akan dapat menggunakan kembali peran dan grup yang diterima di perusahaan dan memberi mereka hak yang diperlukan.
Kesimpulan
Setelah memilih penganalisa, siapkan fakta bahwa itu masih perlu diimplementasikan dengan benar. Jangan takut pertemuan dan koordinasi dengan peserta: semakin baik Anda memahami dalam proses, semakin bermanfaat hasilnya. Penting bahwa skenario kerja tidak hanya disetujui, tetapi juga mulai mengikuti.
Diposting oleh Elizaveta Kharlamova, Lead Analyst, Solar appScreener