Keamanan Aplikasi, atau Cara Menanamkan Keamanan dalam Pengembangan Kustom. Pengalaman pribadi di AGIMA

Badan-badan digital semakin memperhatikan keamanan infrastruktur di mana mereka sedang berkembang, dan juga mulai berupaya memastikan keamanan aplikasi. Anda mungkin membaca tentang variasi dan kekritisan kerentanan, alat, dan metode untuk memberikan keamanan informasi. Tetapi bagaimana mengabaikan atau memastikan keamanan aplikasi memengaruhi proses pengembangan kustom itu sendiri?

Apa yang ada di artikel:

Kami tidak akan mengulangi untuk keseratus kalinya mengapa keamanan begitu penting, kerentanan apa yang ada, atau bagaimana Tim Merah mengalahkan Tim Biru dalam pertempuran lain. Ini adalah cerita pendek tentang mengapa kami menambahkan keamanan untuk pengembangan kustom dan bagaimana kami melakukannya.

Untuk siapa artikel itu?

Artikel ini mungkin menarik bagi manajer proyek, direktur teknis, pemimpin tim, dan semua orang yang entah bagaimana berhubungan dengan organisasi proses pengembangan aplikasi.

Penafian:

Artikel ini bukan obat mujarab, tetapi hanya pendapat pribadi penulis (Alexey Klinov, kepala keamanan informasi di AGIMA).

Bagaimana semuanya dimulai

AGIMA telah lama terlibat dalam pengembangan komprehensif prosedur pengendalian kualitas dan departemen QA. Semua produk kami menjalani banyak pemeriksaan internal:

• gunakan daftar periksa setelah setiap tahap / sprint pengembangan produk;
• Kami membahas fungsionalitas kritis bisnis dengan jaringan autotest;
• Kami mencoba untuk menutupi kode dengan unit test sebanyak mungkin;
• kami menggunakan penganalisa kode yang memenuhi standar (misalnya, untuk PHP adalah PSR 0-4, dll.);
• Kami melakukan uji beban tanpa gagal.

Rincian lebih lanjut tentang proses kami dapat ditemukan di artikel . Tetapi mengapa kami memutuskan untuk menambah batas pengujian lainnya?

Oleh pelanggan

Banyak pelanggan mencari kerentanan sendiri: mereka menggunakan pemindai instrumental atau melakukan tes pena. Dengan satu atau lain cara, kode dan proyek kami secara keseluruhan sering menjalani berbagai pemeriksaan oleh pelanggan.
Jumlah cek meningkat, laporan hasil pemindaian instrumental dan tes pena menjadi semakin banyak. Mempelajari, mereproduksi, menyetujui dan memperbaiki kerentanan memakan banyak sumber daya internal dan dapat ditunda selama berminggu-minggu.

Dari tangan ke tangan ketika orang lain sedang mengembangkan proyek

Terkadang proyek diwarisi dari kontraktor lain. Mereka bisa dalam kondisi pra-penjualan, dan "dalam pertempuran". Tanggung jawab atas pekerjaan sudah ada pada kita, dan seluruh "gerobak" bug dan kerentanan, anehnya, juga.
Kami menyarankan bahwa lebih efisien dan lebih murah untuk memiliki keahlian kami sendiri dalam hal ini.

Apa yang menghalangi?

Ketika berkembang, kami fokus pada kualitas aplikasi, kecepatan commissioning dan biaya. Menambahkan elemen tambahan dalam bentuk analisis kode untuk kerentanan, satu lagi jalur uji atau karyawan akan memengaruhi indikator ini. Mengingat margin bisnis yang rendah, ini sangat penting untuk pengembangan kebiasaan. Pada saat yang sama, untuk mengoptimalkan biaya, pendekatan pengendalian keamanan produk harus bersifat universal dan diterapkan pada semua proyek. Tetapi pelanggan biasanya tidak mengatakan "buat kami aplikasi yang sama dengan orang-orang di sana, hanya hijau." Klien tidak hanya menginginkan desainnya, tetapi juga fungsionalitasnya. Selain itu, setiap sektor bisnis memiliki kebutuhannya sendiri: persyaratan untuk aplikasi di sektor keuangan, obat-obatan dan ritel berbeda. Tim dan teknologi pada setiap proyek bisa sangat berbeda.

Jelas, kontrol keamanan produk meningkatkan kualitasnya. Tetapi bagaimana analisis keamanan akan memengaruhi biaya dan waktu proyek?

Dengan menambahkan revisi tambahan kode ke estimasi, kami awalnya membuat proyek lebih mahal dan menambah waktu pengembangan, seperti halnya dengan jenis pengujian lainnya. Tetapi anggaran ini masih harus dibelanjakan, hanya kurang sistematis dan lebih menyakitkan. Faktanya, produk pada output lebih “bersih”, yang mengurangi tingkat hutang teknis, menghilangkan kebutuhan untuk menghabiskan banyak waktu dan sumber daya untuk perbaikan setelah uji pena, dan, dengan demikian, waktu untuk memasukkan produk ke dalam produksi berkurang.
Ke depan, dalam kasus kami, implementasi analisis keamanan ternyata lebih murah dan lebih cepat, dengan mempertimbangkan seluruh siklus proyek. Biaya dalam beberapa proyek dikurangi hingga 20%, termasuk dengan mengurangi waktu untuk melokalisasi kerentanan dan menghilangkannya bahkan sebelum tim peninjau kode memimpin.
Diputuskan untuk menemukan cara terbaik untuk menerapkan keamanan informasi dalam proses pengembangan kami.

Langkah pertama

Pandangan kami tentang peningkatan keamanan aplikasi:



Perlindungan WAF dan DDoS adalah lapisan perlindungan tambahan pada prod. Dan untuk tujuan kita, kita membutuhkan penganalisa kode untuk kerentanan dan uji pena.

Kubus kecil

Memilih analisa untuk memulai, kami mengecualikan produk mahal yang dibayar. Kami berhenti di SonarQube - penganalisa yang memiliki versi shareware. Ada juga versi cloud , tetapi versi gratisnya membuat proyek sepenuhnya terbuka, yang dalam kasus kami tidak dapat diterima.
Oleh karena itu, untuk memulai - Edisi Komunitas SonarQube. Ini mendukung 15 bahasa, termasuk Java, JavaScript, C #, PHP dan Python. Solusinya dikerahkan cukup cepat dan tidak menimbulkan masalah khusus, ini difasilitasi oleh panduan terperinci.



Sistem diferensiasi hak yang mudah digunakan: Anda dapat membangun matriks akses ke setiap proyek.



SonarQube memungkinkan Anda untuk mengamati dinamika proyek dan menyimpan sejarah analisis. Kami sendiri dapat menetapkan ambang batas kualitas untuk setiap proyek, yang memungkinkan kami untuk mengoptimalkan analisis untuk berbagai proyek.





Kami menguji produk di beberapa proyek:

1. Dimungkinkan untuk menangkap beberapa kerentanan yang tidak terlihat dalam proyek saat ini.
2. Waktu implementasi sangat minim.
3. Kami memastikan bahwa dalam kerangka CI, kode dikembalikan untuk revisi yang menunjukkan potensi kerentanan.

Kami memutuskan bahwa ini sudah cukup untuk usaha kami.

Apa selanjutnya

Untuk kami sendiri, kami mengidentifikasi tiga pendekatan yang bervariasi tergantung pada proyek dan kebutuhan pelanggan:

• Integrasi penuh ke dalam proses pengembangan (CI / CD).
• Audit keamanan di pos-pos pemeriksaan.
• Audit keamanan situasional atau satu kali.

Integrasi penuh ke dalam proses pengembangan

Kami mengintegrasikan solusi ke dalam GitLab. Menggunakan GitLab CI / CD untuk mengotomatiskan peluncuran cek. Ini membutuhkan plugin Plugin Sonar GitLab gratis. Sistem memberi tahu pengembang tentang komitmen yang gagal verifikasi dan menambahkan komentar yang menjelaskan area masalah (jenis kerentanan, rekomendasi untuk memperbaikinya, dan lainnya).
Salah satu proyek mengimplementasikan integrasi dengan Bitbucket dan Bamboo. Dalam hal ini, plugin berbayar Sonar untuk Bamboo dan Sonar untuk Bitbucket Server diperlukan. Setelah operasi pengujian, pelanggan siap untuk biaya tambahan, solusinya sangat cocok dengan tumpukan teknologi.



Opsi yang ideal adalah ketika tenggat waktu, anggaran, dan klien memungkinkan kami untuk mengintegrasikan proses keamanan kami ke dalam siklus kerja sehari-hari dengan kode. Dalam praktiknya, ternyata pendekatan ini relevan untuk pengembangan jangka panjang dan dukungan proyek dengan rilis yang sering.

Audit Keamanan Pos Pemeriksaan

Bagi kami, pendekatan ini optimal untuk proyek-proyek di mana rilis jarang terjadi, misalnya, sekali seperempat. Fungsionalitas atau persyaratan produk dapat berubah selama operasi. Jika Anda terus-menerus melihat setiap baris kode untuk keamanan, banyak waktu ekstra dihabiskan untuk produk yang kami dan pelanggan nanti bisa tolak.

Apa yang kita kaitkan dengan poin kontrol:

• Tonggak logis dalam pengembangan MVP.
• Rilis versi tertentu dari produk yang mengandung fungsionalitas interaksi pengguna yang kritis.
• Rilis spesifik, sprint, atau seperangkat sprint, yang juga memiliki fungsi kritis untuk berinteraksi dengan pengguna.

Pada proyek-proyek utama, kami mulai menggabungkan analisis terintegrasi dengan audit keamanan di breakpoints. Dengan demikian, kami mengidentifikasi kerentanan yang tidak diketahui selama proses pengembangan.

Dengan menggunakan pendekatan ini, kami mengurangi jumlah iterasi debugging ketika menempatkan produk ke dalam operasi komersial. Kami sedang mempersiapkan kumpulan koreksi dan perbaikan, yang mencakup kesalahan fungsional, kerentanan keamanan informasi, dan persyaratan infrastruktur.

Kami telah mengumpulkan statistik biaya waktu dengan prosedur validasi IS terintegrasi di dan tanpa titik kontrol. Kami hanya mengukur aktivitas debug dan pelepasan dalam lingkungan yang produktif.
Dengan pendekatan yang komprehensif, rata-rata, dua iterasi debugging diperlukan. Total durasi mereka adalah ~ 15-20% dari total waktu pengembangan.
Ketika menghubungkan pihak ketiga dengan validasi keamanan informasi, rata-rata dua iterasi debugging fungsional dan tiga iterasi debugging kerentanan keamanan informasi / persyaratan infrastruktur diperoleh. Secara total, ini berjumlah ~ 45% dari total waktu pengembangan, tidak termasuk waktu yang dihabiskan oleh pihak ketiga, hanya di pihak kami.

Audit keamanan situasional atau satu kali

Untuk proyek sederhana, kami memutuskan untuk menerapkan pendekatan dengan satu kali pemeriksaan seluruh basis kode sebelum rilis final. Pendaratan cukup untuk memeriksa sekali sebelum rilis. Menerapkan pemindaian kode dalam suatu proses atau melakukan pemeriksaan perantara pada proyek-proyek semacam itu mahal dan tidak berguna.

Juga, audit situasional mulai dilakukan pada proyek-proyek yang ditransfer kepada kami dari pengembang lain. Sebelum melanjutkan dengan pengembangan lebih lanjut, kami meminimalkan utang teknis produk yang ada. Setelah itu, kami menentukan pendekatan kontrol keamanan yang akan kami gunakan dalam pengembangan lebih lanjut dari proyek.

Ini adalah hasil pemindaian proyek yang belum menjalani audit penuh bug dan keamanan selama beberapa tahun:



Lebih dari 700 artefak kerentanan! Tentu saja, jika Anda menyaring semua positif palsu dan artefak kecil, hanya menyisakan pemblokir dan kritis, gambar tidak akan begitu mengerikan. Tetapi ini adalah beban utang teknis, yang dalam hal apa pun perlu diproses!



Kami peringkat kerentanan dan menyusun peta jalan, di mana kami mencatat berapa banyak iterasi kerentanan kritis perlu dihilangkan. Itu tergantung pada potongan kode yang mereka pengaruhi, data apa yang bisa diperoleh dengan menggunakan kerentanan ini. Seberapa mungkin penyerang mengeksploitasi kerentanan tertentu.

Untuk kasus ini, kami menghabiskan lebih dari 200 jam kerja “memilah” dan menghilangkan kerentanan yang ditemukan, dan hanya setelah itu kami memulai pengembangan produk sepenuhnya. Kadang-kadang perlu untuk menyelesaikan kasus seperti itu, karena ketidaktahuan jauh lebih mahal.

Kami tidak berhenti di situ:

• Analisis ditambahkan ke sebagian besar proyek.
• Alat kontrol keamanan dilengkapi oleh appScreener dari Rostelecom-Solar.
• Menambahkan audit manual dan uji pena untuk proyek-proyek utama.
• Kelompok kriteria dan tingkat kritikalitas yang diperkenalkan untuk fungsionalitas yang diimplementasikan dalam hal dampak pada keamanan aplikasi.

Jadi apa selanjutnya?

Upaya untuk menerapkan keamanan informasi dalam proses pengembangan kebiasaan telah menguntungkan kami:

• Kami mengurangi risiko reputasi baik untuk diri sendiri maupun pelanggan, meminimalkan kemungkinan peretasan aplikasi kami.
• Kami hampir menghilangkan tahap panjang aplikasi debugging setelah uji penetrasi oleh organisasi pihak ketiga.
• Kami telah meningkatkan kompetensi karyawan di bidang keamanan informasi dan berencana untuk terus berayun ke arah ini: untuk menumbuhkan pemimpin keamanan baru, memperkaya basis pengetahuan kami, memperbaiki pendekatan kami dan mencoba yang baru.
• Kami telah menerima keunggulan kompetitif yang sangat baik atas perusahaan lain yang menyediakan layanan pengembangan kustom dan tidak memiliki kompetensi keamanan informasi.

Semakin kita bergerak menuju peningkatan keamanan informasi, semakin banyak kita melihat poin untuk pertumbuhan: menambah pemeriksaan prosedur kami tidak hanya untuk TOP-10 OWASP dan CWE / SANS, tetapi misalnya, mempercepat pelacakan buletin keamanan atau mengajarkan CI kami untuk menggunakan panduan keamanan untuk kerangka kerja kita.

Kami telah mengadakan acara IB pertama kami ( Rostelecom-Solar Business Dinner - AGIMA ), telah menulis artikel ini dan berencana untuk terus membawa praktik baru ke pasar kami, seperti yang kami lakukan dengan desain adaptif di zaman kami (lihat Adaptoz atau kamus adaptif kami) desain , dirilis pada 2013) - bersama kami saat itulah tren ini dimulai, dan sekarang telah menjadi dasarnya standar de facto. Kami ingin melakukan hal yang sama dengan keamanan informasi, karena "ketika Anda mengajar orang lain, Anda belajar sendiri."