Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Secure Software Design

1,303 views

Published on

Secure Software Design (in Bahasa Indonesia)

Published in: Technology
  • Be the first to comment

Secure Software Design

  1. 1. Secure  So(ware  Design   Budi  Rahardjo   budi-­‐at-­‐indocisc.com     2013  
  2. 2. Desain  •  Merupakan  kelanjutan  setelah  spesifikasi  2013   BR  -­‐  Secure  So(ware  Design   2  
  3. 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. 4. Desain  •  Bentuknya  seperF  apa?   –  Flowchart   –  DFD   –  UML   –  DeskripFf  (teks  dan  gambar)  dengan  bahasa   natural  2013   BR  -­‐  Secure  So(ware  Design   4  
  5. 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. 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. 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. 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. 9. Desain  Kendali  •  Bagaimana  mendeskripsikannya?   –  Sama  dengan  metoda  yang  digunakan  untuk   mendeskripsikan  desain   •  Use  case  2013   BR  -­‐  Secure  So(ware  Design   9  
  10. 10. So(ware  Security  Design  ConsideraFons  •  Confidenality  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. 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. 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. 13. SeparaFon  of  Duty  •  Fungsionalitas  dipisahkan   (compartementalize)   –  Memisahkan  kunci  kriptografi  (spliCng  keys)  2013   BR  -­‐  Secure  So(ware  Design   13  
  14. 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. 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. 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. 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. 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. 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. 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. 21. Psychological  Acceptability  (cont.)  •  Penerapan  pengamanan  harus   –  Mudah  digunakan   –  Tidak  mengubah  accessibility   –  Transparan  terhadap  pengguna  2013   BR  -­‐  Secure  So(ware  Design   21  
  22. 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  

×