Secure Software Design

Secure Software Design

• 1.
  Secure  So(ware  Design   Budi  Rahardjo   budi-­‐at-­‐indocisc.com     2013  
• 2.
  Desain   •  Merupakan  kelanjutan  setelah  spesifikasi   2013   BR  -­‐  Secure  So(ware  Design   2  
• 3.
  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   2013   BR  -­‐  Secure  So(ware  Design   3  
• 4.
  Desain   •  Bentuknya  seperF  apa?   –  Flowchart   –  DFD   –  UML   –  DeskripFf  (teks  dan  gambar)  dengan  bahasa   natural   2013   BR  -­‐  Secure  So(ware  Design   4  
• 5.
  Desain   •  Mendefinisikan  sesuatu  yang  harusnya  terjadi   •  Kondisi  normal   Spesifikasi    Implementasi   MulFplier  (spec.)    MulFplier  (impl.)   (tes/ng?  verifica/on?)   2013   BR  -­‐  Secure  So(ware  Design   5  
• 6.
  Security  Desain   • Mendefinisikan  sesuatu  yang  Fdak  boleh   terjadi  (dari  kacamata  security)   –  Safety?   –  Abuse  |  misuse  |  pelanggaran  kebijakan   –  Kendali  (control)  yang  diterapkan  terhadap  hal  di   atas   2013   BR  -­‐  Secure  So(ware  Design   6  
• 7.
  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   2013   BR  -­‐  Secure  So(ware  Design   7  
• 8.
  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)   2013   BR  -­‐  Secure  So(ware  Design   8  
• 9.
  Desain  Kendali   • Bagaimana  mendeskripsikannya?   –  Sama  dengan  metoda  yang  digunakan  untuk   mendeskripsikan  desain   •  Use  case   2013   BR  -­‐  Secure  So(ware  Design   9  
• 10.
  So(ware  Security  Design   ConsideraFons   •  Confiden'ality  Design   •  AuthenFcaFon  Design   –  Menggunakan   –  SSO?   kriptografi   •  AuthorizaFon  Design   •  Integrity  Design   –  Roles,  separaFon  of   –  Menggunakan  hash   duty,  least  priviledge   funcFons   •  AudiFng/Logging   •  Availability  Design   Design   –  Data  replicaFon?   2013   BR  -­‐  Secure  So(ware  Design   10  
• 11.
  Secure  Design  Principles   •  Least  privilege   •  Open  Design   •  SeparaFon  of  duFes   •  Least  Common   •  Defense  in  Depth   Mechanism   •  Fail  Secure   •  Psychological   •  Economy  of  Mechanism   Acceptability   •  Complete  MediaFon   •  Leveraging  ExisFng   Components   Source:  Mano  Paul,  “Official  (ISC)2   Guide  to  the  CSSLP”,  CRC  Press,  2011   2013   BR  -­‐  Secure  So(ware  Design   11  
• 12.
  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   2013   BR  -­‐  Secure  So(ware  Design   12  
• 13.
  SeparaFon  of  Duty   •  Fungsionalitas  dipisahkan   (compartementalize)   –  Memisahkan  kunci  kriptografi  (spliCng  keys)   2013   BR  -­‐  Secure  So(ware  Design   13  
• 14.
  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   2013   BR  -­‐  Secure  So(ware  Design   14  
• 15.
  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)   2013   BR  -­‐  Secure  So(ware  Design   15  
• 16.
  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   2013   BR  -­‐  Secure  So(ware  Design   16  
• 17.
  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   2013   BR  -­‐  Secure  So(ware  Design   17  
• 18.
  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   2013   BR  -­‐  Secure  So(ware  Design   18  
• 19.
  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   2013   BR  -­‐  Secure  So(ware  Design   19  
• 20.
  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   2013   BR  -­‐  Secure  So(ware  Design   20  
• 21.
  Psychological  Acceptability  (cont.)   •  Penerapan  pengamanan  harus   –  Mudah  digunakan   –  Tidak  mengubah  accessibility   –  Transparan  terhadap  pengguna   2013   BR  -­‐  Secure  So(ware  Design   21  
• 22.
  Leveraging  ExisFng  Components   •  Menggunakan  komponen  /  layanan  yang   sudah  tersedia  (daripada  membuat  sendiri)   –  Menggunakan  algoritma  kriptografi  yang  sudah   terbukF  aman   –  Menggunakan  library  yang  banyak  digunakan   2013   BR  -­‐  Secure  So(ware  Design   22