Security Software Development Life Cycle
Keamanan Data & Perangkat Lunak — Chapter 9
Motivasi untuk menggunakan Secure SDLC :
- Aspek security harus di-include bukan sebagai patch.
- Security engineering bukan hanya menjaga reliability tapi juga mengantisipasi kehadiran attacker.
- Vendor besar harus bisa membuat software yang lebih aman.
Microsoft Security Development Lifecycle (SDL)
Education and Awareness
Engineer diberikan training untuk menumbuhkan kesadaran aspek security di aspek design, development, testing, threat modeling dan review process. Diharuskan mengikuti training minimal 1x setahun.
Memilih teknologi stack itu penting untuk menentukan engineer harus ditraining apa saja (ex : node js, kotlin, dll).
Project Inception
Ketika memulai project, perlu untuk menentukan berapa banyak bug yang bisa ditolerir (bug bar). Menetapkan security advisor.
Fase 1 : Requirement
Peluang untuk mempertimbangkan security di awal proyek. Dilakukan dengan :
- Identifikasi kebutuhan security dan privacy
- Menetapkan security advisor
- Security advisor mereview product plan, membuat rekomendasi.
- Mengamanatkan penggunaan sistem tracking bug
- Menentukan dokumen security dan bug bar.
Fase 2 : Design
Menentukan dan mendokumentasikan arsitektur keamanan, identifikasi komponen-komponen penting. Identifikasi teknik desain (layering, least privilege, minimalisir attack surface).
Product Risk Assessment
Melakukan penilaian risiko keamanan, membuat rating dampak privacy, dan menyatukan semuanya.
Risk Analysis
Membuat artifak threat modeling, menentukan apa yang dimodelkan, membangun threat model, menggunakan threat model untuk membantu code review, menggunakan threat model untuk membantu testing,
Threat Modeling Artifact & Process
Menggunakan skenario, dependensi eksternal, asumsi security, dan catatan security eksternal.
Fase 3 : Implementation
Menentukan proses, dokumentasi dan tools yang dibutuhkan untuk memastikan secure deployment dan secure operation.
Ada beberapa tools yang bisa dipake untuk menemukan vulnerability (FindBug, SonarQube). Beberapa tools ada yang online specific requirement seperti untuk XSS, SQL Injection, dll.
Secure Coding Policies
Menggunakan compiler dan tools versi terbaru. Gunakan source code analysis tools. Jangan gunakan banned function (contohnya scanf). Gunakan ceklis secure coding (misalnya dari owasp)
Fase 4 : Verification
Dimulai sesegera mungkin, setelah tahap koding selesai.
Secure Testing Policies
Melakukan Fuzz testing, Penetration testing, Run-time verification, Review dan update threat model (jika terjadi regresi), dan mengevaluasi attack surface.
Fase 5 : Release — Response Plan
Menyiapkan plan untuk merespon. Membuat support policy yang jelas dan konsisten dengan kebijakan perusahaan. Menyediakan rencana respons insiden software security.
Get Radinal Dwiki Novendra, S.T., M.T.’s stories in your inbox
Join Medium for free to get updates from this writer.
Response biasanya tidak ada di software development lifecycle, paling biasanya dipanggil ketika ada maintenance. Di software ada 3 tipe maintenance :
- Preventive maintenance. Ketika memperbaiki bagian yang fishy
- Corrective maintenance. Ketika ada vulnerability.
- Condition-based maintenance. Ketika ada perubahan proses bisnis atau teknologi.
Penting untuk menyediakan fitur send crash report agar bisa mengumpulkan diagnostik dari software.
Fase 5 : Release — Final Security
Memastikan requirement SDL terpenuhi dan tidak ada security vulnerability yang ditemukan.
Fase 5 : Release — Archive
Saat rencana respons terkait security diselesaikan. Dokumentasi customer diperbarui, arsipkan kode sumber RTM, simbol, threat model ke lokasi pusat.
Post SDL Requirement : Response
Rencanakan pekerjaan, kerjakan rencananya. Eksekusi tugas respons yang diuraikan selama fase Security Response Planning and Release.
Security Response Planning
Persiapan untuk respons, bangun pusat security respons, merespon semua laporan isu.
Security Response Execution
Mengikuti rencana, membuatnya selagi berjalan, mengetahui apa yang harus dilewati.
Panduan SDL untuk Metodologi Agile
Memperkenalkan Security ke dalam SDLC
Bagaimana cara memastikan countermeasure seperti access control sudah jalan atau belum?
You cannot manage something that you can not measure
- Harus bisa mengukur, mengetahui bagaimana kondisi access control itu berjalan atau tidak.
- Harus memproduksi log, dan harus ada alert jika log tidak bertambah.
Bagaimana cara memastikan apakah TLS sudah berjalan?
- Menggunakan wireshark, dicek apakah terenkripsi
- Manual oleh orang operation untuk cek manual seminggu sekali, untuk mengantisipasi downgrade attack.
Touchpoint for Software Security
McGraw membuat framework untuk menerapkan security di setiap aspek SDLC.
Code Review dengan Tools
Tujuannya adalah menemukan bug lebih awal, tidak sempurna tapi tujuannya bagus. Tools static analysis yang bagus harus mudah digunakan, bahkan untuk orang non-security.
Architectural Risk Analysis
Defect yang dihasilkan oleh desain menyebabkan 50% masalah security. Risiko adalah Probability dikalikan dengan Severity. Namun terdapat tradeoff antara countermeasure dan cost. Beberapa teknik yang mungkin bisa digunakan seperti attack resistance analysis pattern, ambiguity analysis dan weakness analysis.
Ouput yang dihasilkan dari architectural risk analysis adalah security requirement, countermeasure, dan security policy (access control & data retention policy).
Contoh 4 Tier Web App
Software Penetration Testing
Merupakan teknik yang umum dalam security. Namun belum tentu hal yang baik, karena terkadang pentest yang dilakukan oleh orang security yang terlalu bersemangat malah membuat tim software developer menjadi marah alias baper, juga terlalu menekankan pada ancaman dari luar. Pentest memiliki batasan karena menjadi upaya yang terlambat untuk mengatasi masalah security karena dilaksanakan di akhir siklus pengembangan.
Namun tentu saja pentest bisa digunakan sebagai panduan untuk memperkuat keamanan pada aplikasi yang ada di sebuah organisasi. Dan bisa menjadi menguntungkan jika pentest :
- Memiliki umpan balik ke pengembangan.
- Menjadi pengecekan terakhir sebelum program dioperasikan (production).
- Menjadi pengecekan pertama dari postur security.
Risk Based Security Testing
Berbeda dengan testing pada umumnya. Testing pada umumnya hanya fokus pada software jika mengalami kegagalan atau failure. Sedangkan security testing berasumsi adanya musuh cerdas yang berniat menghancurkan sistem.
Pendekatan dalam security testing :
- Functional security testing. Untuk memastikan fungsionalitas diterapkan dengan benar.
- Adversarial security testing. Melakukan pengujian keamanan berbasis risiko yang dimotivasi oleh pemahaman dan simulasi pendekatan penyerang.
Dalam security testing pertimbangkan SIAPA dan BAGAIMANA dalam masalah security (threat dan vulnerability). Pikirkan malicious input dari semua vektor, misalnya dari sockets, pipes, win32 registry, files, RPC, argumen command-line, dst. Dan ini berbeda dengan pentest.
Software Security Memenuhi Security Operation
Berkaitan dengan kegiatan DevOps. Konfigurasi dan kustomisasi lingkungan deploymen aplikasi dengan hati-hati, mulai dengan komponen level jaringan, dan berakhir pada konfigurasi setup dari application security. Pertimbangkan sebagian besar aspek yang berkaitan dengan operation dan manajemen software.
