A very short Introduction to Software Security
1 like661 views
(some parts are in Bahasa Indonesia.) Secure Software Development Lifecycle
A very short Introduction to Software Security
- 1. A Very Short Introduction to Software Security Budi Rahardjo @rahard 2017
- 2. Security ≒ Network security ≒ Host / computer security ≒ Application security 2017 BR - Software Security 2
- 3. Potensi Lubang Keamanan www.bank.co.id Internet Web Site Users ISP Network sni鍖ed, 鍖ood, attacked Network sni鍖ed, attacked Network sni鍖ed, attacked Malware Virus Trojan horse Applications (database) compromised OS hacked Security Holes ≒ System (OS) / host ≒ Network ≒ Applications (db) Userid, Password, PIN, credit card #
- 4. 2014 Issues ≒ Bashbug ≒ Heartbleed 2017 BR - Software Security 4
- 5. SSL Heartbeat 2017 BR - Software Security 5
- 6. 2017 BR - Software Security 6
- 7. 2017 BR - Software Security 7
- 8. 2017 BR - Software Security 8
- 9. Bashbug 2017 BR - Software Security 9
- 10. 2014 2017 BR - Software Security 10
- 11. Mengapa Software Penting? ≒ Berbagai perangkat / layanan bergantung pada software Perangkat bisnis (ATM, e-commerce) Alat komunikasi Peralatan medis Transportasi modern Peralatan elektronik rumah tangga 2017 BR - Software Security 11
- 12. Konsekuensi Kegagalan ≒ Kerugian tangible & intangible ≒ Reputasi rusak & kepercayaan customer hilang ≒ Berakibat fatal bila operasionalnya terganggu ≒ Kerugian produktivitas 2017 BR - Software Security 12
- 13. Apple iOS 7 bug Failed to check SSL: goto bug Must upgrade to iOS 7.0.6 2017 BR - Software Security 13
- 14. Statistik Software Vulnerabilities Processes for Producing Secure Software, IEEE Security & Privacy, May/June 2004 2017 BR - Software Security 14
- 15. Sumber Masalah Keamanan Software ≒ Connectivity Software terhubung ke mana-mana ≒ Extensibility Software dapat diubah meskipun sudah dipasang dan digunakan (deployed) ≒ Complexity Software semakin kompleks 2017 BR - Software Security 15
- 16. Connectivity Software terhubung ke mana-mana Dahulu ≒ Software berdiri sendiri (standalone) ≒ Potensi serangan dilakukan secara fisik saja Sekarang ≒ Software terhubung ke Internet (ATM, e- commerce) SCADA bisa diakses melalui Internet ≒ Potensi serangan datang dari mana- mana 2017 BR - Software Security 16
- 17. 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 2017 BR - Software Security 17
- 18. Complexity Software Semakin Kompleks Dihitung dari jumlah baris (Lines of Code) ≒ Trennya akan makin terus naik Semakin banyak jumlah baris: ≒ makin meningkat potensi lubang keamanan ≒ makin banyak insiden 2017 BR - Software Security 18 Operating System Year Lines Of Codes Windows 3.1 1990 3 milion Windows NT 1996 4 milion Windows 95 1997 15 milion Windows NT 4.0 1998 16.5 milion Windows 98 1999 18 milion Windows NT 5.0/2K beta 2000 20 milion Debian GNU/ Linux 2.2 2000 55 milion Windows 2000 2000 35 milion Windows XP 2001 40 milion Red Hat 7.1 2007 50 milion Windows Vista 2007 50 milion
- 19. Pihak Terlibat Dalam Software Security 2017 BR - Software Security 19 Developer beda sudut pandang antara Developer dan Security Engineer: 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 a3ack dan toolnya 9dak bisa melindungi aplikasi dari a3ack secara umum selalu mengulang kesalahan coding terlalu fokus ke spesi鍖kasi bekerja sama dengan: Solu6on Architects & System Administrators Berkontribusi terhadap so3ware security lewat: mengadopsi best-prac6ce bagi applica6on security development mengetahui posisi security vulnerability dan bagaimana mengatasinya menggunakan secure programming techniques
- 20. Software Security: when & where 2017 BR - Software Security 20 Security must be considered at All Stages Analysis Design Development Deployment All layers Network Host Applica6on
- 21. Start the Security Process 2017 BR - Software Security 21 Security Requirement So3ware Engineering Secure So3ware Membangun soAware/aplikasi yang tetap berperilaku normal ke9ka ada serangan Aspek dasar security: Con鍖den6ality Integrity Availability Perbedaan mendasar SoAware Safety dan SoAware Security: SoAware Security memper9mbangan keberadaan aktor yang melakukan serangan
- 22. Sotware Engineering Evolution 2017 BR - Software Security 22 Semua langkah ditujukan untuk menguji bahwa so3ware melakukan semua hal yang diinginkan pengembang Bagaimana memas<kan bahwa so3ware <dak melakukan hal-hal lain yang <dak diinginkan??? Bagaimana mengiden<鍖kasi resiko keamanan so3ware dan melakukan mi<gasi? Conventional Software Engineering ≒ Design ≒ Design Veri鍖ca6on ≒ Coding Tes6ng Abuse Cases Attack Cases Misuse Cases
- 23. Secure Software Development Life Cycle (SSDLC) 2017 BR - Software Security 23 Source: www.computer.org
- 24. Security Framework: SD3 2017 BR - Software Security 24 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 Secure by Design Secure by Default Secure in Deployment Sumber : MSDN (Microsoft Developer Network)
- 25. Security Throughout Project Life Cycle 2017 BR - Software Security 25
- 26. Security Requirement 2017 BR - Software Security 26 Mende鍖nisikan lingkungan security dan obyek<f Mengembangkan model ancaman/serangan Mensosialisasikan kebijakan security Example: A Client-Server application Example: Example: ≒ To use the presence or instant messaging services, users must be authenticated. ≒ Messages mustnt be tampered with. ≒ The message sender should be properly authenticated. ≒ Presence information shouldnt be tampered with. ≒ The subscriber databases privacy should be guaranteed. ≒ Message sending should be time-stamped security if user A sends a message at time t to B, he cant modify the message so that B thinks it was sent at time t .
- 27. Security Requirement ≒ How to describe Using natural language Using diagrams ≒ Assignment Create a security requirement for ≒ internet banking web-based application ≒ Sistem informasi kepegawaian 2017 BR - Software Security 27
- 28. Contoh Security Requirements ≒ Users must authenticate? Is anonymous access allowed? Is concurent access allowed? ≒ Password Length? Strength? Aging? (History?) Failed attempts locked out? How many times? How to unlock? Must be shown with asterisks (*) ≒ Is concurrent access allowed? ≒ Changes must be logged ≒ Audit log must provide enough data for forensic ≒ Data in transit, in process, in storage must be encrypted 2017 BR - Software Security 28
- 29. Secure Software Design ≒ Architectural Issues Jika disain arsitektur software sudah memiliki lubang keamanan, maka implementasi tidak mengubah hal tersebut. Analogi: bangunan yang didesain tanpa dinding di bagian belakang 2017 BR - Software Security 29
- 30. Design Review 2017 BR - Software Security 30 Contoh review terhadap desain: Software development by Example, IEEE Security & Privacy, July/August 2005
- 31. Contoh Security Design ≒ Requirement Pengguna tidak boleh login dari dua (2) tempat yang berbeda (parallel/concurrent login) ≒ Ada skenario pengujian login dari 2 IP yang berbeda pada saat yang bersamaan ≒ Bagaimana caranya? Manual? Otomatis? ≒ Desain kendali Cookies + nomor IP + jenis browser + identitas komputer lainnya Pemberitahuan (dan pencatatan) kejadian 2017 BR - Software Security 31
- 32. 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) 2017 BR - Software Security 32
- 33. Secure Code ≒ Static analysis Melakuan analisis terhadap source code ≒ Bergantung kepada bahasa yang digunakan ≒ Masih dibutuhkan banyak penelitian ≒ Dynamic analysis Menjalankan software dan kemudian melakukan analisis keamanan ≒ Melihat isi memory 2017 BR - Software Security 33
- 34. Risk Analysis 2017 BR - Software Security 34
- 35. Penetration Testing 2017 BR - Software Security 35 ≒ High level overview of the test cases ≒ How explanatory testing will be conducted ≒ Which component will be tested Building a test plan Execu?ng test cases Repor?ng ≒ Dependency testing ≒ User interface testing ≒ Design testing ≒ Implementation testing ≒ Reproduction steps ≒ Severity ≒ Exploit scenarios Source: Application Penetration Testing, IEEE Security & Privacy, Jan/Feb 2005
- 36. "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 2017 BR - Software Security 36
- 37. 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 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) 2017 BR - Software Security 37
- 38. Top Software Security Flaws 2017 BR - Software Security 38 Bu鍖er Over鍖ow Input valida?on bugs Race condi?on
- 39. Penutup ≒ Keamanan perangkat lunak (software security) masih merupakan bidang yang baru ≒ Akan lebih banyak masalah terkait dengan software security ≒ Kemampuan mengembangkan software yang aman sangat dibutuhkan 2017 BR - Software Security 39