analisis sistem keamanan perangkat lunak, Essays (university) of Obstetrics

Download analisis sistem keamanan perangkat lunak and more Essays (university) Obstetrics in PDF only on Docsity!

MAKALAH

ANALISIS KEAMANAN SISTEM OERANGKAT LUNAK

Dosen Pebimbing : Maulidiansyah, M.Kom

Nama : Firnandi Feri Ariyanto

Nim : 17010138

UNIVERSITAS NURUL JADID

PAITON – PROBOLINGGO

ABSTRAK

Kesalahan kerentanan dan keamanan perangkat lunak dapat dikurangi jika secure software development process (SSDP) diikuti, seperti memenuhi aspek keamanan pada tahap membangun perangkat lunak. Keamanan perangkat lunak sangat penting dalam perangkat lunak, sebagian besar keamanan perangkat lunak tidak ditangani sejak software development life cycle (SDLC). Sistem perangkat lunak yang aman akan memberikan tingkat kepercayaan yang tinggi dari user, user akan merasa nyaman dan aman ketika berhubungan dengan sistem yang sudah kita bangun. Pada tulisan kali ini, kita akan membahas tentang keamanan pada fase-fase membangun perangkat lunak. Selain itu tulisan ini dapat membantu pengembang perangkat lunak untuk meningkatkan keamanan dan mengurangi vulnerability (kerentanan) pada perangkat lunak, sehingga kedepan keamanan harus terintegrasi ke dalam software development life cycle (SDLC). Keamanan harus dibangun “built-in” ke dalam produk yang yang kita kembangkan.

keamanan perangkat lunak. Akibat adanya cacat / kerusakan pada sistem keamanan perangkat lunak akan menimbulkan : a. Merusak nama perusahaan. b. Perusahaan akan mengalami kerugian cukup banyak. c. Kerugian cost (waktu dan biaya) untuk perbaikan. d. Berkurangnya kepercayaan konsumen terhadap perusahaan. Dalam tulisan “Quantifying Security in Secure Software Development Phases” (Khan & Zulkernine, 2009), mengusulkan metodologi yang memungkinkan para pengembang untuk menilai status keamanan SLDC.Dalam metodologi yang diusulkan, pertama-tama mengidentifikasi dan mengukur aspek keamanan yang terkait seperti : error (kesalahan), jumlah kerentanan, resiko, hubungan antara kesalahan dan kerentanan (vulnerability), persyaratan keamanan yang dibutuhkan dan lain-lain.Selain itu, mengitung indeks kemanan berdasarkan faktor resiko dan kemungkinan kerusakan.

Gambaran metodologi yang diusulkan oleh (Khan & Zulkernine, 2009) dalam gambar 1 adalah :

1. mengidentifikasi semua kelemahan dan kesalahan yang menyebabkan kerentanan dalam SLDC.
2. mengidentifikasi hubungan antara error (kesalahan) dan ketentanan.
3. mengidentifikasi persyaratan keamanan yang diperlukan untuk menghapus kesalahan.
4. menghitung indeks kerentanan berdasarkan jumlah kerentanan yang telah di hapus dan dan total kerentanan yang ditemukan di awal
5. Untuk keputusan yang lebih baik kerentanan yang lebih tinggi menjadi prioritas untuk di hapus karena memperhitungkan potensi kerusakan yang dapat disebabkan.

Keamanan Sistem Perangkat Lunak

Institusi/organisasi yang sudah menerapkan praktek keamanan sistem perangkat lunak bisa memperoleh manfaat tambahan berupa berkurangnya cost (waktu dan biaya). Seiring dengan pengurangan lubang pada perangkat lunak, keamanan sistem perangkat lunak harus terintegrasi ke dalam siklus hidup pengembangan software (SLDC) secara penuh. Kemanan harus “built in ”dalam produk yang sedang dikembangkan, dan tidak hanya diberikan keamanan di luar perangkat lunak seperti menginstal antivirus.Menurut (Istiyanto, 2011), Goal securitymanajemen terdapat pada 5 pondasi yaitu ; Protokol, Cryptografi, Access Control, Software, Serta Sosial Engineering. Pada gambar 2, terdapat beberapa manajemen keamanan salah satunya keamanan software. Keamanan software dilakukan melalui pengukuran pada ukuran-ukuran keamanan software yang bisa menimbulkan vulnerability pada setiap tahapan SDLC (Software Development Life Circle) sehinggakoreksi awal bisa dilakukan. Titik pengukuran ini meliputi analisa arsitektural, pemodelan ancaman, verifikasi desain, review desain, review kode, analisa

kode, test unit dan test system. Dengan praktek-praktek di atas diharapkan bisa menjamin kwalitas perangkat lunak yang dirilis akan aman dari serangan. Terkadang kita sulit membedakan sistem keamanan pada level non aplikasi dan aplikasi. Tidak ada definisi yang jelas mengenai pola keamanan karena banyak penulis mendifinisikan dan merujuk berbagai sumber dari konteks keamanan.Ramachandran (2002) pola keamanan sebagaielemen dasar. Romanosky (2002) menyelidiki pola keamanan menggunakan format tertentu untuk memeriksa pola desain perangkat lunak (Gamma dkk, 1995). Serta beberapa penulis mendifinisikan pola keamanan untuk Aplikasi Web (Weiss, 2003;Kienzle & Penatua, 2002), keamanan pola untuk sistem agen (Mouratidis dkk, 2003), Keamanan Kroptografi perangkat lunak (Braga dkk, 1998), untuk java code (Mahmoud, 2000), serta metadata, otentikasi dan otorisasi (Fernandez, 2000; Lee Brown dkk, 1999).

TAHAP KEAMANAN PERANGKAT LUNAK

Keamanan perangkat lunak merupakan hal yang nyata kesalahan dalam banyak pengembangan sikulus perangkat lunak (SDLC) seperti yang sudah di jelaskan sebelumnya yaitu persyaratan spesifikasi, desain, source code bagian dari perangkat lunak yang menyebabkan vulnerability (khan & zulernine, 2009). Keamanan perangkat lunak menjadikan salah satu ancaman keamanan untuk perangkat lunak, seperti :

1. Kesalahan persyaratan spesifikasi (Requirement specification) : salah atau terdapat kekurangan persayaratan dalam requirement specification pada saat tahap perancangan perangkat lunak.

Keamanan Pada Fase Perencanaan

Fase perencanaan merupakan proses yang pertama yang dilakukan investigasi awal untuk mengumpulkan permasalahan-permasalahan yang ada di dalam sistem terutama yang berkaitan dengan keamanan system.Membangun perangkat lunak yang aman adalah tanggung jawab semua stakeholder pada saat software development lifecycle (SLDC). Tujuan keamanan siklus hidup perangakat lunak yang professional (Secure Software Life Cycle Professional (SSLP) yaitu memastikan bahwa perangkat lunak yang dibangun tidak rentan terhadap gangguan keamanan (Mano Paul, 2008).Perangkat lunak tidak 100% aman. Namun, perangkat lunak dapat dirancang, dikembangkandengan secure mindset. Faktor kebutuhan kontrol keamanan diperlukan untuk meminimalkan dampak eksploitasi. Berikut ini merupakan misi dari SSLP dalam membangun pertahanan perangkat lunak dari hack-resilient (Mano Paul, 2008):

1. Lindungi kepercayaan pelanggan anda.
2. Mengetahui bisnis anda dan terjamin.
3. Memahami teknologi perangkat lunak.
4. Patuh terhadap peraturan dan Privasi.
5. Mengetahui Prinsip dasar keamanan software.
6. Pastikan melindungi informasi yang sensitive.
7. Desain software dengan fitur yang aman.
8. Mengembangkan software dengan fitur yang aman.
9. Deploy (Menyebarkan) software dengan fitur yang aman.

10. Mempelajari (educate yourself) cara membangun software yang aman Selain hal di atas, pada tahap perancangan diperlukan validasi terhadap kebijakan,standart dan lainnya yang berkaitang dengan keamanan perangkat lunak dan dikonfirmasikan dengan stakeholdernya (User) hingga mereka menyetujui. Di bawah ini merupakan prinsip mengembangkan perangkat lunak secara aman (Curtis, 2005). 1 Economic of Mechanism : Melakukan desain sederhana dan sekecil mungkin 2 Fail-Safe defaults : Hak akses diberikan dengan jelas. 3 Complete mediation : Setiap akses harus diperiksa otoritasnya. 4 Open design : Desain sebaiknya tidak di rahasiakan namun tetap di jaga. 5 Separation of privilege : Bila memungkinkan, mekanisme proteksi memerlukan paling tidak dua kunci untuk membukanya, hal ini akan lebih aman daripada hanya mempunyai satu kunci. 6 Least Privilage : Setiap program dan setiap pemakai dari system sebaiknya mengoperasikan dengan menggunakan minimal hak akases yang dibutuhkan untuk menyelesaikan pekerjaanya. 7 Least Common Mechanism : Meminimalkan jumlah mekanisme umum untuk pemakai. 8 Psychological acceptability : Human interface didesain untuk kemudahan penggunaan sehingga para pemakai secara rutin dan otomatis dapat mengaplikasikan mekanisme keamanan secara benar.

tanda-tanda keamanan aliran infromasi berorientasi obyek. Metrik tersebut memungkinkan pengembang perangkat lunak untuk membandingkan tingkat keamanan berbagai alternatife desain.

Keamanan Pada Fase Implementasi

Pastikan desain diterjemahkan ke dalam kodeselama pelaksanaan. Berikut ini adalah kegiatanyang perlu dilakukan selama pelaksanaan untuk mencapai kode yang (Khan & Zulkernine, 2009) : a) High-level bahasa pemrograman memberikan tingkat aman yang mendekati kesempurnaan. Namun, terkadang kita perlu menggunakan bahasa pemrograman yang low level untuk mendapatkan akses langsung ke perangkat keras. Bahasa pemrograman yang High Level harus dipilih namun harus tetap melihat persyaratan pemrograman pengembangan perangkat lunak. b) Standar keamanan coding dan mengikuti petunjuk harus diikuti untuk menghindari kesalahan source code. c) Unit pengujian (testing) harus dilakukan denganmemikirkan masalah keamanan. Kesalahankeamanan dilaporkan dalam perangkat lunak yang digunakan sebagai referensi.

Fase Assurance(Jaminan)

Selama fase jaminan, perangkat lunak tersebutharus akan diperiksa secara berkala untuk memenuhi persyaratan. Kegiatan yang dilakukan selama fase ini adalah sebagai berikut (Khan & Zulkernine, 2009) :

1. Kode harus diperiksa (Jika ada kesalahan berdasarkan daftar dari kesalahan yangdilaporkan sebelumnya ) untuk mengidentifikasi perangkat lunak dan kesalahan keamanan.Selain itu, alat analisis statis harus digunakanuntuk menemukan kesalahan. Kesalahan yangditemukan harus segera diselesaikan.
2. Uji kasus harus dikembangkan berdasarkan kebutuhan fungsional dan keamanan.
3. Integrasi dan pengujian perlu dilakukan berdasarkan pengujian syarat keamanan.Penetration harus dilakukan berdasarkan kerentanan yang diketahui dan potensi serangan yang akan di temui oleh perngkat lunak. Kesalahan keamanan yang ditemukan harus Dihilangkan.

PUSTAKA

Alshammari, B., fridge, C., & Corney, d. (2010). Security Metrics for Object-Oriented Design. Carlsson, B., & Baca, D. (2005). Software Security Analysis - Execution Phase Auidit. IEEE Computer Society. Chandra, S., Khan, R. A., & Agrawal, A. (2009). Security Estimation Framework: Design Phase Perspective. IEEE Computer Society. Curtis, C. (2005). case Study : An Evolution of putting security into SDLC. Dai, L., & Bai, Y. (2011). An Organization-Driven Approach for Enterprise. IEEE Computer Society. Eugene Lebanidze. (2005). Securing Enterprise Web Applications at the Source : An Application Security Perspective. Istiyanto, J. E. (Pemain). (2011). Goal Security Management. Kelas, Yogyakarta, Yogyakarta, Sleman. Khan, M. U., & Zukernine, M. (2009). Actifity and Artifact views of a secure software development proses. IEEE Computer Society , 2. Khan, M. U., & Zulkernine, M. (2008). Quantifying Secrity in Secure Software Development Phasess. IEEE Computer Society , 1. Mano Paul. (2008). The ten Best Practices for secure software development. Information System Security Certification COnsortiu,Inc. Peterson, G. (2004). Software Security. CHI Publlishing Ltd.