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