Software Security

II5166 - Keamanan Informasi Lanjut Budi Rahardjo 2012

Peta Software Security

2012

BR - Software Security

Mengapa Software Penting?

Berbagai perangkat / layanan bergantung pada software
Perangkat bisnis (ATM, e-commerce) Alat komunikasi Peralatan medis Transportasi modern Peralatan elektronik rumah tangga
2012 BR - Software Security 3

Konsekuensi Kegagalan
Kerugian tangible & intangible Reputasi rusak & kepercayaan customer hilang Berakibat fatal bila operasionalnya terganggu Kerugian produktivitas

2012

BR - Software Security

Statistik Software Vulnerabilities

Processes for Producing Secure Software , IEEE Security & Privacy, May/June 2004

2012

BR - Software Security

Sumber Masalah Keamanan Software

Connectivity
Software terhubung ke mana-mana

Extensibility
Software dapat diubah meskipun sudah dipasang dan digunakan (deployed)

Complexity
Software semakin kompleks

2012

BR - Software Security

Software terhubung ke mana-mana

Dahulu Software berdiri sendiri (standalone) Potensi serangan dilakukan secara fisik saja Sekarang Software terhubung ke Internet (ATM, ecommerce)
SCADA bisa diakses melalui Internet

Connectivity

Potensi serangan datang dari manamana

2012

BR - Software Security

Extensibility
Software dapat diubah meskipun sudah dipasang dan digunakan (deployed) Diubah sambil jalan Fitur yang belum ada dapat dikembangkan sambil jalan
Autoupdate Applet, plug-in, Trend ke depan (JAVA, .NET) makin bisa dikembangkan Malicious extension bisa masuk ke sistem

2012

BR - Software Security

Software Semakin Kompleks

Dihitung dari jumlah baris (Lines of Code)
Trennya akan makin terus naik
Operating System Windows 3.1 Windows NT Windows 95 Windows NT 4.0 Windows 98 Windows NT 5.0/2K beta Debian GNU/ Linux 2.2 Windows 2000 Windows XP Red Hat 7.1 Windows Vista Year 1990 1996 1997 1998 1999 2000 2000 2000 2001 2007 2007 Lines Of Codes 3 milion 4 milion 15 milion 16.5 milion 18 milion 20 milion 55 milion 35 milion 40 milion 50 milion 50 milion

Complexity

Semakin banyak jumlah baris:

makin meningkat potensi lubang keamanan makin banyak insiden

2012

BR - Software Security

Solving the Problems

3 Pillars of So,ware Security Applied Risk Management So,ware Security Touchpoints Knowledge

2012

BR - Software Security

10

Risk Management Framework

understanding the business context

3 Pillars of So,ware Security

Applied Risk Management

idenAfy the business and technical risk synthesize and rank the risks

So#ware Security Touchpoints Knowledge

dene the risk miAgaAon strategy carrying out xes and validaAng

2012

BR - Software Security

11

Software Security Touchpoints

Applied Risk Management

Code review (Tools) Architectural Risk Analysis PenetraAon TesAng

3 Pillars of So,ware Security

So,ware Security Touchpoints

Risk-based Security TesAng Abuse Cases Security Requirements

Knowledge

Security operaAons

2012

BR - Software Security

12

Software Security Knowledge

Applied Risk Management

Principles Guidelines

So#ware Security Touchpoints

Rules AKack PaKerns

3 Pillars of So,ware Security

Knowledge

Historical Risks VulnerabiliAes Exploits

2012

BR - Software Security

13

Pihak Terlibat Dalam Software Security

Developer
beda sudut pandang antara Developer dan Security Engineer: bekerja sama dengan: SoluAon Architects & System Administrators Berkontribusi terhadap so#ware security lewat:
mengadopsi best-pracAce bagi applicaAon security development mengetahui posisi security vulnerability dan bagaimana mengatasinya menggunakan secure programming techniques

Build vs. Break

Pandangan developer terhadap security:

asumsi bahwa rewall akan melindungi terlalu percaya pada kriptogra memeriksa produk setelah jadi

Pandangan security engineer terhadap development:

9dak memahami metoda aKack dan toolnya 9dak bisa melindungi aplikasi dari aKack secara umum selalu mengulang kesalahan coding terlalu fokus ke spesikasi

2012

BR - Software Security

14

Software Security: when & where

Analysis Design All Stages Development Deployment Network All layers Host ApplicaAon

Security must be considered at

2012

BR - Software Security

15

Kelemahan Umum Dalam SDLC

1. Tidak memahami konsekuensi jangka panjang dari proses pengamanan yang lemah 2. Konik di se9ap fase antara kepen9ngan bisnis dan keamanan 3. Melihat security requirements dengan konsep yang keliru 4. Tidak menerapkan building with security in mind 5. Mengabaikan aspek security semasa tesAng 6. Tidak menggunakan security tesAng tools yang tepat
Source: hKp://www.securitypark.co.uk

2012

BR - Software Security

16

Start the Security Process

Security Requirement So#ware Engineering Secure So#ware

Membangun so,ware/aplikasi yang tetap berperilaku normal ke9ka ada serangan Aspek dasar security:
CondenAality Integrity Availability

Perbedaan mendasar So,ware Safety dan So,ware Security:

So,ware Security memper9mbangan keberadaan aktor yang melakukan serangan

2012

BR - Software Security

17

Sotware Engineering Evolution

Conventional Software Engineering
Misuse Cases Abuse Cases Attack Cases

Design Design VericaAon Coding TesAng

Bagaimana memas<kan bahwa so#ware <dak melakukan hal-hal lain yang <dak diinginkan???

Semua langkah ditujukan untuk menguji bahwa so#ware melakukan semua hal yang diinginkan pengembang

Bagaimana mengiden<kasi resiko keamanan so#ware dan melakukan mi<gasi?

2012

BR - Software Security

18

Secure Software Development Life Cycle (SSDLC)

Source: www.computer.org
2012 BR - Software Security 19

Security Framework: SD3

" secure architecture & code threat analysis vulnerability reduction attack surface area reduced unused features turned off by default minimum privileges used Protection: detect, defend, recover, manage Process: how to guides, architecture guides People: training
Sumber : MSDN (Microsoft Developer Network)

Secure by Default

" " "

Secure by Design

" " "

Secure in Deployment

" "

2012

BR - Software Security

20

Security Throughout Project Life Cycle

2012

BR - Software Security

21

Security Requirement
Mendenisikan lingkungan security dan obyek<f
Example: A Client-Server application

Mengembangkan model ancaman/serangan

Mensosialisasikan kebijakan security

Example:

Example: To use the presence or instant messaging services, users must be authenticated. Messages mustn t be tampered with. The message sender should be properly authenticated. Presence information shouldn t be tampered with. The subscriber database s privacy should be guaranteed. Message sending should be time-stamped security if user A sends a message at time t to B, he can t modify the message so that B thinks it was sent at time t .

2012

BR - Software Security

22

Secure Software Design

Architectureal Issues
Jika disain arsitektur software sudah memiliki lubang keamanan, maka implementasi tidak mengubah hal tersebut. Analogi: bangunan yang didesain tanpa dinding di bagian belakang

2012

BR - Software Security

23

Design Review

Contoh review terhadap desain: Software development by Example, IEEE Security & Privacy, July/August 2005

2012

BR - Software Security

24

Implementasi: Secure Coding

Menentukan hasil dari implementasi

Analogi : Dinding yang dibangun dengan batu bata (beton) akan berbeda dengan tripleks (bedeng) Ada beberapa tools yang dapat digunakan untuk menguji (static analysis tools)
2012 BR - Software Security 25

Risk Analysis

2012

BR - Software Security

26

Penetration Testing
High level overview of the test cases How explanatory testing will be conducted Which component will be tested Dependency testing User interface testing Design testing Implementation testing Reproduction steps Severity Exploit scenarios

Building a test plan

ExecuDng test cases

ReporDng

Source: Application Penetration Testing, IEEE Security & Privacy, Jan/Feb 2005

2012

BR - Software Security

27

"Improving the Security of Your Site by Breaking Into it

(Dan Farmer/Wietse Venema, 1993) http://www.fish.com/security/admin-guide-to-cracking.html

2012

BR - Software Security

28

Blackbox vs. Whitebox

Blackbox
Tidak ada pengetahuan awal mengenai sistem yang akan diuji. Penguji menentukan dulu lokasi dan coverage target. Menguji berbasis input dan output saja
Tanpa source code Memberikan input yang tidak lazim
2012

Whitebox
Diberi pengetahuan lengkap mengenai sistem yang akan diuji Mencari lubang keamanan dengan menelusuri program :
Dengan source code Identifikasi programming error Mencari kelemahan (algoritma dan teknik implementasi)
29

BR - Software Security

Top Software Security Flaws

Buer Overow

Input validaDon bugs

Race condiDon

2012

BR - Software Security

30