Secure Software Design

Secure So(ware Design

Budi Rahardjo budi-‐at-‐indocisc.com

2013

Desain

•  Merupakan kelanjutan setelah spesifikasi

2013 BR -‐ Secure So(ware Design 2

Desain

•  Masalah desain terkait business logic flaw (bukan bugs karena kode belum dibuat)

•  Memperbaiki masalah (security) yang terjadi di producFon 100x lebih mahal daripada keFka pada fasa desain

specifica+on architectural blueprint code


Desain

•  Bentuknya seperF apa? – Flowchart – DFD – UML – DeskripFf (teks dan gambar) dengan bahasa natural


Desain

•  Mendefinisikan sesuatu yang harusnya terjadi •  Kondisi normal

Spesifikasi Implementasi MulFplier (spec.) MulFplier (impl.)

(tes/ng? verifica/on?)


Security Desain

•  Mendefinisikan sesuatu yang Fdak boleh terjadi (dari kacamata security) – Safety?

– Abuse | misuse | pelanggaran kebijakan – Kendali (control) yang diterapkan terhadap hal di atas


Contoh #1

•  Contoh yang Fdak boleh terjadi – Pengguna login dari dua (2) tempat yang berbeda (parallel login) •  Ada skenario pengujian login dari 2 IP yang berbeda •  Bagaimana caranya? Manual? OtomaFs?

– Bagaiman kendalinya? •  Cookies + nomor IP + jenis browser + idenFtas komputer lainnya


Contoh #2

•  Password recovery – Pertanyaan yang sudah dipersiapkan • Warna favorit? •  Nama binatang peliharaan (pets)?

–  Jawaban yang terbatas jumlahnya atau mudah ditebak •  Tebak warna: merah, biru, hijau, ... •  Kasus Paris Hilton, nama pets diketahui (via media entertainment) •  Data via faceboook (social media lainnya)


Desain Kendali

•  Bagaimana mendeskripsikannya? – Sama dengan metoda yang digunakan untuk mendeskripsikan desain •  Use case


So(ware Security Design ConsideraFons •  Confiden'ality Design – Menggunakan kriptografi

•  Integrity Design – Menggunakan hash funcFons

•  Availability Design –  Data replicaFon?

•  AuthenFcaFon Design –  SSO?

•  AuthorizaFon Design –  Roles, separaFon of duty, least priviledge

•  AudiFng/Logging Design


Secure Design Principles

•  Least privilege •  SeparaFon of duFes •  Defense in Depth •  Fail Secure •  Economy of Mechanism •  Complete MediaFon

Source: Mano Paul, “Official (ISC)2 Guide to the CSSLP”, CRC Press, 2011

•  Open Design •  Least Common Mechanism

•  Psychological Acceptability

•  Leveraging ExisFng Components


Least Privilage

•  Gunakan access rights (privilage) se-‐minimal mungkin

•  Terkait dengan konfigurasi bukan so(warenya •  Modular programming •  Contoh – Database: Fdak menggunakan “sa” (admin) untuk aplikasi

– Web: apache menggunakan “www-‐data” bukan “root” – Mail: posjix menggunakan user yang berbeda untuk menerima email dan menulis mailbox


SeparaFon of Duty

•  Fungsionalitas dipisahkan (compartementalize) – Memisahkan kunci kriptografi (spliCng keys)


Defense in Depth

•  Layered defense •  Masalah (vulnerability) di satu tempat Fdak menjadikan total compromise

•  Contoh – Menggunakan zona security yang berbeda

– Menggunakan input validaFon, stored procedures, Fdak memperkenankan dynamic query construcFon


Fail Secure

•  Bila gagal, masuk ke zona secure •  Contoh – Gagal login beberapa kali, account dikunci – Pesan kesalahan (error messages) Fdak mengungkapkan rahasia (non-‐verbose) •  Error ... /to/some/path/file

•  HaF-‐haF untuk Fdak menjadi DoS (bergantung kepada kebijakan)


Economy of Mechanism

•  “the more complex the design of the soGware, the more likely there are vulnerabili/es”

•  Fungsi dan pengamanan yang Fdak dibutuhkan (berlebihan) harus dihindari

•  Simplicity ... Zen ...

•  Kemudahan


Complete MediaFon

•  Access request harus diuji seFap saat •  Contoh – URL dengan user=budi diganF menjadi rahardjo ternyata menampilkan data “rahardjo” tanpa harus login

– Tidak boleh bergantung hanya kepada client-‐side, cookie-‐based caching of authen/ca/on creden/als

–  Instruksi “jangan tekan tombol lebih dari sekali” Fdak efekFf


Open Design

•  Pisahkan kerahasiaan dengan desain –  Contoh algoritma kriptografi yang memisahkan antara algoritma dan kunci-‐nya

– Algoritma dapat direview tanpa merisikokan kerahasiaan. (Contoh algoritma yang terbuka AES, RSA, dll.)

•  Lawannya adalah security through obscurity –  Tingkat kerahasiaan so(ware bergantung kepada kerahasiaan desain. Harus dihindari. Bocornya desain berdampak kepada gagalnya keamanan

– Desain harus terbuka untuk review (scruFny) – Hard coding informasi yang sensiFf berbahaya


Least Common Mechanism

•  Mekanisme yang sama (common) untuk pengguna / proses dengan Fngkat otoritas yang berbeda Fdak boleh digunakan bersama (shared)

•  Potensi terjadinya kebocoran informasi

•  Harus dikotak-‐kotakkan


Psychological Acceptability

•  Security mechanism should be designed to maximize usage, adop/on, and automa/c applica/on

•  Penerapan pengamanan diusahakan Fdak menyulitkan pengguna. Jika Fdak, akan terjadi masalah keamanan di tempat lain – Aturan / desain: “password harus kompleks dan sering diubah”

–  Pengguna kesulitan mengingat password (yang selalu berubah)

–  Pengguna menuliskan password tersebut di kertas dan menyimpannya dekat kompyter


Psychological Acceptability (cont.)

•  Penerapan pengamanan harus – Mudah digunakan – Tidak mengubah accessibility – Transparan terhadap pengguna


Leveraging ExisFng Components

•  Menggunakan komponen / layanan yang sudah tersedia (daripada membuat sendiri) – Menggunakan algoritma kriptografi yang sudah terbukF aman

– Menggunakan library yang banyak digunakan


Secure Software Design

Technology