Secure Software Design
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Secure Software Design

  • 1,151 views
Uploaded on

Secure Software Design (in Bahasa Indonesia)

Secure Software Design (in Bahasa Indonesia)

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,151
On Slideshare
1,149
From Embeds
2
Number of Embeds
2

Actions

Shares
Downloads
46
Comments
0
Likes
3

Embeds 2

https://twitter.com 1
http://affanul.net 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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  •  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. 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