Serangan organisasi yang paling berhasil dilaksanakan melalui kerentanan dan bookmark dalam perangkat lunak. Untungnya, pemindai kerentanan perangkat lunak tidak dianggap oleh perusahaan sebagai sesuatu yang eksotis, tetapi sebagai elemen penting dari infrastruktur perlindungan. Jika dengan volume pengembangan yang kecil Anda dapat menggunakan apa adanya pemindai, maka ketika volumenya besar, Anda harus mengotomatiskan prosesnya. Tetapi siapa yang harus mengelolanya? Putuskan seberapa sering untuk memeriksa rilis? Verifikasi kerentanan? Putuskan apakah akan memveto rilis dan mengirim kode untuk memperbaiki kerentanan? Dan jawab banyak pertanyaan lainnya. Di sinilah Manajer Keamanan Aplikasi, manajer pengembangan perangkat lunak yang aman, menjadi yang terdepan.
Tetapi di mana menemukan burung langka atau bagaimana menanamnya sendiri? Artem Bychkov, manajer keamanan aplikasi di Raiffeisenbank JSC, dan Daniil Chernov, kepala Rostelecom Solar, Solar appScreener, menjelaskan persyaratan untuk manajer keamanan aplikasi yang ditentukan oleh praktik pengembangan di perusahaan Rusia.
Siapa Manajer Keamanan Aplikasi
Organisasi cepat atau lambat menyadari kebutuhan untuk merekrut orang semacam itu dalam tim. Khususnya, karena tidak ada spesialis yang tersedia di perusahaan yang secara langsung cocok untuk peran ini. Pengembang? Pengalaman kerja mereka terhubung secara khusus dengan pengembangan perangkat lunak - sangat sulit bagi mereka untuk menerjemahkan kerentanan yang ditemukan menjadi risiko IS, dan terlebih lagi risiko untuk bisnis. Para petugas keamanan? Perendaman dalam seluk-beluk pengembangan merupakan masalah bagi mereka: untuk memverifikasi kerentanan, seseorang harus dapat memahami kode perangkat lunak dalam berbagai bahasa, yang membutuhkan pengalaman pengembangan yang serius.
Mari kita lihat tugas-tugas yang muncul selama implementasi proses pengembangan yang aman, yang harus ditangani oleh Manajer Keamanan Aplikasi (AFM).
Pembaca mungkin memiliki pendapat bahwa pekerjaan AFM semata-mata terkait dengan verifikasi pengembangan perangkat lunak untuk kepatuhan dengan persyaratan keselamatan. Tetapi masalah keamanan muncul pada berbagai tahap siklus hidup sistem, dari desain hingga penyebaran hingga produksi. Ada berbagai model untuk membangun siklus pengembangan yang aman (Software Touchpoints Keamanan, SDLC dan lain-lain) dan berbagai metode untuk menanamkan praktik-praktik ini dalam proses (tergantung pada pendekatan yang digunakan - air terjun, gesit). Tetapi mereka semua sepakat pada poin-poin utama: Anda perlu memikirkan keamanan di semua tahap siklus hidup sistem.
Jelas, dalam kerangka proyek yang kurang lebih besar, satu orang tidak mungkin dapat melakukan pekerjaan di semua tahap. Jarang ada orang yang mampu mengembangkan persyaratan keamanan aplikasi, melakukan tinjauan arsitekturnya dan memverifikasi hasil pekerjaan analis, melakukan audit keamanan kode, memverifikasi bahwa tes keamanan aplikasi yang diperlukan dilakukan selama pengujian, dan bahwa sistem tersebut dikerahkan dengan aman dan dikonfigurasi dengan benar. Selain itu, seringkali kegiatan ini dilakukan oleh perwakilan dari berbagai tim dan unit. Agar seluruh mekanisme berfungsi sebagaimana mestinya, kekuatan pendorong proses haruslah AFM. Tugas AFM adalah untuk memastikan implementasi praktik pengembangan yang aman, baik sendiri atau dengan mendelegasikan tugas tertentu kepada spesialis khusus. Namun, berdasarkan praktik kami, AFM tidak mungkin untuk hanya membagikan tugas kepada mereka yang bertanggung jawab dan berpuas diri.
Apa persyaratan untuk AFM
Pertama, dia dituntut untuk memahami proyek yang dia ikuti. Ini sangat penting dalam pengembangan tangkas, ketika, tidak seperti model air terjun, Anda tidak memiliki 2 bulan untuk melakukan tinjauan sebelum rilis. Itu tergantung pada AFM, misalnya, bagaimana persyaratan yang dibentuk pada tahap desain akan ditafsirkan oleh tim, bagaimana mereka akan jatuh pada arsitektur, apakah mereka secara umum dapat diwujudkan dan apakah mereka akan menciptakan masalah teknis yang serius di masa depan. Paling sering, AFM adalah konsumen utama, juru bahasa, dan evaluator laporan instrumen dan audit otomatis yang dibuat oleh pihak ketiga. AFM yang menyaring hasil yang tidak relevan dan salah, mengevaluasi risiko, dan berpartisipasi dalam proses pengelolaan pengecualian dan mengembangkan langkah-langkah kompensasi.
Berikut ini adalah contoh nyata: audit atau pemindai kode sumber mengungkapkan penggunaan fungsi hash tidak aman (MD5) dalam sebuah proyek. Kebijakan perusahaan secara resmi menegaskan bahwa itu tidak dapat digunakan, dan vendor setuju untuk mengganti fungsi dengan yang lebih aman dalam 3 bulan dan jumlah yang besar. Nuansa adalah bahwa dalam kasus ini, ketidakstabilan fungsi hash terhadap tabrakan tidak mempengaruhi keamanan sistem, karena fungsi tersebut tidak digunakan untuk melindungi integritas. Pendekatan formal dalam kasus ini dan penggantian satu fungsi dengan yang lain menyebabkan waktu yang tertunda tidak masuk akal untuk output proyek menjadi biaya yang produktif dan signifikan, memberikan keuntungan nol dalam keamanan.
Kedua, selain yang pertama, AFM harus memiliki pengetahuan dari berbagai bidang: Anda perlu memahami proses pengembangan dan prinsip-prinsip keamanan informasi. "Keterampilan keras" juga penting, karena sangat sulit untuk mengevaluasi secara kritis hasil kerja spesialis khusus dan alat otomatis, jika Anda tidak dapat membaca kode, Anda tidak memahami cara-cara yang memungkinkan untuk mengeksploitasi kerentanan. Tentunya, banyak yang dihadapkan pada situasi di mana kerentanan kritis muncul dalam analisis kode atau laporan terpanjang, tetapi pengembang tidak setuju dengan ini (dan, sebagai suatu peraturan, mereka juga ingin membuat sistem yang aman) dan menunjukkan bahwa auditor tidak dapat mengoperasikan ini kerentanan. Bagaimana cara mengevaluasi siapa yang benar dalam situasi yang sama? Tanpa keterampilan teknis, menyelesaikan sengketa secara objektif akan sulit. Jika proses pengembangan perangkat lunak yang aman dibangun oleh tangan organisasi eksternal dan / atau sesuai dengan model layanan, siapa dan bagaimana akan mengevaluasi kinerja praktik "teknis"?
Contoh kehidupan lain: alat pengembangan baru sedang diperkenalkan, kinerjanya diperiksa pada proyek referensi, setelah itu dipindahkan ke operasi komersial. Proyek secara bertahap terhubung ke sana, dashboard hijau yang indah ditarik ... dan di sini insiden keamanan informasi terjadi. Ternyata, "lubang" yang digunakan seharusnya telah terdeteksi pada tahap analisis dinamis. Tapi ini tidak terjadi, karena ... tidak ada yang melihat, tetapi bagaimana pemindai kerentanan top-end ini, yang biasanya menghasilkan hasil yang sangat baik, bekerja dengan aplikasi SPA menggunakan kerangka JavaScript baru. Ternyata dia tidak bisa "melihat" formulir otentikasi yang dihasilkan secara dinamis dan melakukan pemeriksaan yang diperlukan. Dan tidak ada yang memperhatikannya, karena semuanya bekerja. Pengembang tidak perlu mempelajari secara spesifik fungsi pemindai untuk menarik perhatian, dan tim keamanan tidak melihat perbedaan kritis antara berbagai pendekatan berbeda dalam pengembangan web.
Di mana mendapatkan spesialis seperti itu
Mereka yang mempelajari pasar pasti menghadapi kekurangan akut dari pakar keamanan aplikasi. Biasanya, skenarionya adalah sebagai berikut: pelanggan internal menyusun persyaratan untuk kandidat dan mentransfernya ke staf. Jika persyaratannya ketat, maka menurut hasil pencarian gratis, perusahaan menerima nol kandidat, karena spesialis yang sudah jadi jarang mengirim resume di domain publik. Jika mereka berganti pekerjaan, maka ini paling sering terjadi dengan mudah dan alami melalui kontak yang ada. Bagaimana menjadi
Anda dapat mencoba memikat seorang profesional dari perusahaan lain, tetapi jalur ini tidak selalu dapat diterima karena berbagai alasan. Semakin sering, kompetisi untuk outstaffing AFM muncul di pasar, yang cukup berhasil memungkinkan Anda untuk menutup masalah dengan menyewa ahli dari penyedia layanan.
Tetapi ada opsi lain. Anda dapat mencoba menumbuhkan profesional Anda. Perwakilan dari dua bidang dapat menjadi kandidat yang cocok untuk peran ini:
- orang-orang dari pembangunan yang gemar atau ingin berkembang di bidang keamanan;
- penjaga teknologi yang terbiasa dengan pengembangan dan keamanan perangkat lunak dan ingin menyelami topik ini lebih dalam.
Baik mereka dan kandidat lainnya harus menguasai paket pengetahuan yang hilang. Pada saat yang sama, orang-orang dari pengembangan yang ingin “reforge” akan memiliki pemahaman yang lebih baik tentang budaya dan proses yang ada dalam tim yang mereka kenal. Mereka mungkin perlu sedikit waktu untuk menguasai bidang pengetahuan yang terkait dengan keamanan informasi. Namun, pengalaman menunjukkan bahwa di antara pengembang, penguji, analis dan arsitek, Anda dapat menemukan orang-orang yang tertarik pada keamanan yang sudah memiliki seperangkat pengetahuan tertentu di bidang keamanan aplikasi. Mereka bisa menjadi kandidat ideal untuk pekerjaan AFM.
Petugas keamanan profesional harus menyesuaikan diri, mengubah pendekatan yang sudah dikenal untuk mengatur pekerjaan dan mengadopsi budaya dalam tim pengembangan. Namun, jika seorang spesialis keamanan menulis kode dan terbiasa dengan proses pengembangan, maka ia akan bergabung dengan tim dengan cepat dan sederhana.
Total
Pengendalian keamanan pengembangan terutama merupakan proses bisnis, untuk keberhasilan fungsi yang memerlukan interaksi terkoordinasi dari semua anggota tim. "Jantung" dari proses ini adalah AFM yang memenuhi syarat - itu adalah inspirer, dan mesin pengarah, dan pelaksana banyak tugas, dan manajer pengendali, dan banyak lainnya. Secara umum, pembaca, dan mesin penuai, dan dude ada di pipa. Mencari atau membesarkan spesialis seperti itu tidak mudah, tetapi jika Anda berhasil, maka semua orang akan bahagia.