1. Rangkuman Materi
Software Security Design
Secure Software Development Life Cycle (SDLC)
dengan business logic flaw. Memperbaiki Memperbaiki masalah (security) yang terjadi di production 100x lebih mahal daripada ketika pada fase desain. Terdapat salah satu contoh kesalahan desain yaitu banyaknya aplikasi yang tidak melakukan verifikasi email (sebagai identitas) untuk pembuatan akun, reset password, dll yang mengakibatkan orang lain dapat membuat akun kita dengan alamat email orang tersebut. Langkah yang dapat dilakukan sehingga ti9dak terjadinya hal seperti itulah adalah
- Pengguna mengisikan alamat email sebagai akun
- Email dikirimkan dengan tautan (link) yang unik
- Tunggu pengguna melakukan klik terhadap tautan (untuk verifikasi)
- Akun baru dibuat Setelah sistem mendapatkan verifikasi tersebut
Security is a Concern not a Feature
- User authentication pada website penyimpanan foto
- User story (function-focused) : Sebagai pengguna, Saya ingin sebuah halaman login sehingga Saya dapat mengakses foto yang sudah saya upload.
- User story (security concern) : Sebagai pengguna, Saya ingin mengakses foto yang sudah saya upload melewati halaman login, sehingga foto saya tetap rahasia
Pendekatan tradisional Software Security dan Kelemahannya
- Cara penanganan keamanan dalam perangkat lunak seperti ini biasa terjadi, tetapi juga bermasalah karena beberapa alasan, beberapa di antaranya:
- Pengembang perlu secara eksplisit memikirkan kerentanan keamanan, sementara pada saat yang sama berfokus pada penyelesaian fungsionalitas bisnis.
- Mengharuskan setiap pengembang untuk menjadi ahli keamanan.
- Diasumsikan bahwa orang yang menulis kode dapat memikirkan setiap potensi kerentanan yang mungkin terjadi sekarang atau di masa mendatang.
Arsitektur dan Desain
- Arsitektur dan desain merupakan fase kritis dari SDLC
- Keputusan yang diambil pada fase ini menentukan ketahanan sistem terhadap serangan.
- Keputusan yang baik yang dibuat selama fase ini tidak hanya akan menghasilkan pendekatan dan struktur yang lebih tangguh dan tahan terhadap serangan, tetapi juga sering membantu untuk menentukan dan memandu keputusan yang baik di fase selanjutnya seperti kode dan pengujian. Keputusan buruk yang dibuat selama fase ini dapat menyebabkan cacat desain yang tidak pernah dapat diatasi atau diselesaikan bahkan oleh kode dan upaya pengujian yang paling cerdas dan disiplin sekalipun.
- Setengah dari cacat yang menyebabkan kerentanan keamanan yang ditemukan dalam perangkat lunak saat ini sebenarnya disebabkan oleh kelemahan dalam arsitektur dan desain [McGraw 2006]
- Tujuan membangun keamanan ke dalam fase arsitektur
Issue dan Tantangan
- Tantangan untuk membangun keamanan ke dalam bagian arsitektur dan desain dari SDLC adalah bahwa arsitektur tidak hanya harus mengatasi masalah keamanan yang dipahami namun pada tingkat abstraksinya juga harus fleksibel dan tangguh di bawah kondisi keamanan yang terus berubah.
- Tidak ada sistem yang dapat sepenuhnya aman
Software Architecture and Software Design
- Arsitektur perangkat lunak (Software Architecture) dari suatu sistem menggambarkan organisasi atau struktur sistem, dan memberikan penjelasan tentang bagaimana perilakunya.
- Desain perangkat lunak (Software Design) adalah proses konseptualisasi requirement perangkat lunak ke dalam implementasi perangkat lunak.
Hubungan Software Architecture dan Software Design
- Arsitektur perangkat lunak memaparkan struktur sistem sambil menyembunyikan detail implementasi. Arsitektur juga berfokus pada bagaimana elemen dan komponen dalam suatu sistem berinteraksi satu sama lain.
- Desain perangkat lunak menggali lebih dalam detail implementasi sistem. Masalah desain mencakup pemilihan struktur data dan algoritma, atau detail implementasi komponen individual.
Architectural Risk Analyst
- Melakukan analisis risiko arsitektur
- Analisis risiko arsitektur dimaksudkan untuk memberikan jaminan bahwa masalah keamanan tingkat arsitektur dan desain diidentifikasi dan ditangani sedini mungkin dalam life cycle, menghasilkan tingkat ketahanan, toleransi, dan ketangguhan terhadap serangan yang lebih baik.
- Tanpa analisis semacam ini, kelemahan arsitektural akan tetap tidak tertangani sepanjang life cycle dan kemungkinan besar akan mengakibatkan kerentanan keamanan yang serius pada perangkat lunak yang diterapkan.
1. Software characterization
- Memahami software dan cara kerjanya.
- Untuk architectural risk analysis membutuhkan deskripsi minimal menggunakan diagram yang menghasilkan gambaran yang komprehensif, namun ringkas yang secara jelas menggambarkan sifat sebenarnya dari perangkat lunak tersebut.
- Mengumpulkan informasi untuk karakterisasi perangkat lunak ini biasanya melibatkan peninjauan spektrum yang luas dari artefak sistem dan melakukan wawancara mendalam dengan pemangku kepentingan tingkat tinggi seperti manajer produk/program dan desainer perangkat lunak.
2. Threat analysis
- Threat (Ancaman) adalah agen yang melanggar perlindungan aset informasi dan kebijakan keamanan situs.
- Threat Analysis mengidentifikasi ancaman yang relevan untuk arsitektur, fungsionalitas, dan konfigurasi tertentu.
- Selama analisis ini, threat dapat dipetakan ke kerentanan untuk memahami bagaimana perangkat lunak dapat dieksploitasi.
- Rencana mitigasi terdiri dari tindakan pencegahan yang dianggap efektif terhadap kerentanan yang teridentifikasi yang dieksploitasi oleh ancaman ini.
- Penilaian kerentanan memeriksa prasyarat yang harus ada agar kerentanan dapat dieksploitasi dan menilai status yang mungkin dimasuki perangkat lunak saat dieksploitasi.
- Tiga kegiatan membentuk penilaian kerentanan arsitektur: analisis resistensi serangan, analisis ambiguitas, dan analisis ketergantungan.
- Pengujian analisis risiko hanya dapat membuktikan adanya—bukan tidak adanya—cacat.
- Analisis risiko arsitektur mempelajari kerentanan dan ancaman yang mungkin berbahaya atau tidak berbahaya. Apakah kerentanan dieksploitasi secara sengaja (jahat) atau tidak sengaja (nonmalicious)
- Salah satu keuntungan saat melakukan penilaian kerentanan pada tingkat arsitektur adalah kemampuan untuk melihat hubungan dan efek pada tampilan “forest-level" daripada “tree-level".
4. Risk likelihood determination
- Setelah menentukan ancaman mana yang penting dan kerentanan mana yang mungkin ada untuk dieksploitasi, akan berguna untuk memperkirakan kemungkinan berbagai kemungkinan risiko.
- Dalam keamanan perangkat lunak, "kemungkinan" adalah perkiraan kualitatif tentang seberapa besar kemungkinan serangan yang berhasil.
- Meskipun demikian, konsep kemungkinan dapat berguna saat memprioritaskan risiko dan mengevaluasi keefektifan mitigasi potensial.
- Faktor-faktor yang perlu dipertimbangkan:
- Motivasi dan kemampuan ancaman
- Dampak kerentanan (dan karena itu daya tarik bagi penyerang)
- Efektivitas kontrol saat ini
- Risk Impact harus di tentukan
- Aspek yang perlu diperhatikan
- Identify Threatened Assets
- Identify Business Impact
- Risk Exposure Statement
- Mitigasi risiko memerlukan perubahan arsitektur perangkat lunak atau bisnis dalam satu atau lebih cara untuk mengurangi kemungkinan atau dampak risiko.
- Pengujian formal dan informal, seperti pengujian penetrasi, dapat digunakan untuk menguji keefektifan tindakan mitigasi ini.
- Mitigasi yang ditujukan pada kelemahan arsitektur seringkali lebih rumit untuk diimplementasikan daripada mitigasi yang berfokus pada bug pengkodean, yang cenderung lebih terlokalisasi.
- Mitigasi arsitektur sering membutuhkan perubahan pada banyak modul, banyak sistem, atau setidaknya banyak kelas dan entitas yang terpengaruh dapat dikelola dan diimplementasikan oleh tim yang berbeda.
Desain
- Desain adalah panduan prinsip bagaimana sebuah sistem dibangun dan dapat diterapkan di semua tingkatan
- Desain mencakup aktivitas apa pun yang melibatkan pengambilan keputusan aktif
- Mendefinisikan sesuatu yang tidak boleh terjadi
- Safety
- Abuse, Misuse, pelanggaran kebijakan.
- Desain keamanan berupa kendali (control)
Desain Kendali
- Software Security Design Considerations
- Confidentiality Design (Menggunakan kriptografi)
- Integrity Design (Menggunakan hash functions)
- Availability Design (Data replication)
- Authentication Design(SSO)
- Authorization Design (Roles, separation of duty, least priviledge)
- Auditing/Logging Design
- Secure Design Principles
- Least privilege
- Separation of duties
- Defense in Depth
- Fail Secure
- Economy of Mechanism
- Complete Mediation
- Open Design
- Least Common Mechanism
- Psychological Acceptability
- Leveraging Existing Components
- Least Privilage
- Gunakan access rights (privilage) se-minimal mungkin
- Terkait dengan konfigurasi bukan softwarenya
- Modular programming
- Separation of Duty
- Memisahkan kunci kriptografi (splitting keys)
- Defense in Depth
- Layered defense (berlapis-lapis)
- Masalah (vulnerability) di satu tempat tidak menjadikan total compromise
- Fail Secure
- Bila gagal, masuk ke zona secure
- Hati-hati untuk tidak menjadi DoS
- Economy of Mechanism
- Fungsi dan pengamanan yang tidak dibutuhkan (berlebihan) harus dihindari
- Complete Mediation
- Access request harus diuji setiap saat
- Open Design
- Pisahkan kerahasiaan dengan desain
- Lawannya adalah security through obscurity
- Least Common Mechanism
- Mekanisme yang sama (common) untuk pengguna / proses dengan tingkat otoritas yang berbeda tidak boleh digunakan bersama (shared)
- Potensi terjadinya kebocoran informasi
- Harus dikotak-kotakkan
- Psychological Acceptability
- Penerapan pengamanan diusahakan tidak menyulitkan pengguna. Jika tidak, akan terjadi masalah keamanan di tempat lain
- Psychological Acceptability (cont.)
- Penerapan Keamanan harus : mudah digunakan, tidak mengubah accessibility, transparan terhadap pengguna
- Leveraging Existing Components
- Menggunakan komponen / layanan yang sudah tersedia
- Menggunakan algoritma kriptografi yang sudah terbukti aman
- Menggunakan library yang banyak digunakan
Design Consideration
- Confidentiality Design => Menggunakan kriptografi
- Integrity Design => Penggunaan hash function
- Availability Design => Menghindari Denial of Service (DoS)
2. Buat contoh untuk menghitecture risk analysis.
0 comments:
Post a Comment