Tweets & ReTweets

Association

Pen-Test, Audit & Assessment

Written By Scooter-google on Kamis, 25 September 2014 | 08.54

Mendengar dan membaca terkait maraknya kejahatan perbankkan saat ini yang tampil dalam berita baru - baru ini. Didik  berhasil membobol sebesar Rp 21 Milliar, dengan menggunakan modus penarikan tunai dengan menggunakan mesin ATM disaat bank tersebut sedang melakukan upgrade system dan penarikan tunai dengan menggunakan mesin EDC yang dia miliki, sungguh kejadian luar biasa.  Hal ini dilakukan dalam waktu kurang dari 24 jam. Hal diatas terjadi pada tanggal 10 April 2014.  Tidak lama setelah kejahatan Didik terungkap, kembali nasabah Bank Mandiri terkaget-kaget kartu ATM mereka terblokir secara otomatis. Hal ini dikarenakan Bank Mandiri mencurigakan telah terjadi penggandaan kartu ATM  nasabah mereka.

Seperti sebelumnya yang sudah saya tuliskan dalam blog ini terkait dengan isu HeartBleed ada yang bertanya - tanya. Apakah hal tersebut adalah virus, trojan, worm. Mungkin sebelumnya dapat baca terlebih dahulu apasih sebenarnya dan bagaimana dampaknya. saya coba mengambil dari potongan paragraf pertama dari halaman Heartbleed "The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library".

Dengan code CVE-2014-0160 dan yang buatkan inisial menjadi Heartbleed. Jadi berita ini perihal tentang kerentanan yang terjadi pada media Transport Layer Security protocol (TLS) yang menyebabkan ketika hal itu dilakukan eksploitasi mengarah ke kebocoran dari proses server ke klien dan dari klien ke server. 

Mengingat tentang vulnerability (kerentanan ), hal ini menjadi akan menjadi sebuah terminology yang sering muncul dalam masalah keamanan. Nah karena pada kesempatan kali ini akan coba memberikan informasi terkait Pen-Test, Audit dan Assessment.

Sering sekali ketiga istilah ini dijadikan satu pemahaman oleh masyarakat. terlebih terkait dengan masalah system informasi. sering sekali bila sudah berbicara terkait dengan masalah security (keamanan) maka paradigma yang dimunculkan adalah dengan menampilkan bagaimana dengan melakukan Penetration Testing /penetrasi test bahasa kerennya Pen-Test. Beberapa orang memberikan pendapat hal tersebut dapat dilakukan dengan Pen-Test. Dan beberapa orang mempertukarkan istilah - istilah tersebut yang sebenarnya berbeda arti dan tujuannya.

Pen-Test VS Audit.
Melakukan penetrasi pada suatu system TI bertujuan untuk mengetahi apakah system TI pada lingkungan tersebut mudah ditembus atau tidak oleh pihak luar atau memiliki kerentanan untuk ditembus tidak. Banyak orang menganggap bahwa Pen-Test adalah segalanya, hingga memberikan penilaian yang berlebihan terkait dengan proses tersebut. 
Tetapi  perlu diingat bahwa Pen-Test semata-mata untuk memberikan ukuran tingkat keamanan suatu sistem. Karena dari Pen-Test tidak dapat digunakan untuk mengungkapkan sebab-sebab lain diluar teknologi.

Beberapa contoh yang sering dijumpai tidak digantinya password default dari vendor pada perangkat Teknology Informasi terutama pada perangkat yang sifatnya Appliance dan Plug-and-Play  seperti switch dan router.  Hasil dari Pen-Test dapat mengungkapkan hal tersebut dan dapat memberikan rekomendasi terkait hal tersebut biasanya hal ini dilakukan dengan rekomendasi melakukan perubahan password.

Tetapi diluar hal tersebut Pen-Test tidak dapat mengungkapkan kerentanan lain misal dikarenakan tenaga Administrator tidak memiliki kemampuan dan pengetahuan yang cukup dalam mengkonfigurasi perangkat sehingga tidak tahu bagaimana melakukan perubahan Password, dan atau password dibiarkan karena dapat dipergunakan oleh user yang lain. atau tidak adanya tenaga Administrator yang bertanggung jawab, ada atau tidak adanya check list monitoring perangkat tersebut. Beberapa hal tersebut tidak dapat diungkap dengan hanya melakukan Pen-Test saja. Dan yang menjadi catatan kembali terkait dengan Pen-Test bahwa hasil yang terjadi hanya menggambarkan kejadian pada saat itu saja "on the spot" . adapun setelah hal tersebut dilakukan tidak dapat digambarkan. Karena terkait dengan kontrol - kontrol yang digunakan.


Selain itu, pentest merupakan pengukuran yang tertuju hanya pada satu saat (snapshot) tertentu saja. Jika hasil pentest menunjukkan bahwa suatu sistem aman, tidak berarti sistem tersebut akan aman sebulan kemudian, karena mungkin ditemukannya kerentanan-kerentanan baru yang tidak dijumpai saat dilakukan pentest.
Jika pada pentest, kontrol-kontrol pengamanan yang ada (biasanya) tidak diberitahukan kepada pihak penguji, sebaliknya dalam melakukan audit, kontrol-kontrol yang ada akan diberitahukan oleh auditee (pihak yang diuji) kepada auditor (pihak penguji). Selanjutnya, auditor akan menilai apakah kontrol-kontrol yang ada tersebut telah dilaksanakan dengan semestinya atau apakah sudah efektif untuk mengurangi risiko yang telah teridentifikasi sebelumnya pada saat assessment .
Pentest sering juga digunakan sebagai salah satu cara dalam melakukan audit; dan biasanya digunakan sebagai substantive test atau pada situasi dimana konfigurasi dari suatu peralatan tidak didapatkan. Misalnya, pada audit untuk menguji apakah firewall yang terpasang sudah sesuai dengan aturan yang diinginkan. Jika konfigurasi firewall tidak didapatkan, maka pentest dapat digunakan sebagai alternatif, atau sebagai pelengkap untuk membuktikan apakah running configuration memang sesuai dengan aturan yang diinginkan (bisa jadi print-out configuration yang diberikan pihak auditor tidak sama dengan running configuration).
Penggunaan Best practices dalam audit
Langkah awal dalam melakukan audit adalah mengidentifikasi struktur kontrol yang ada, beserta alasan kenapa diadakannya kontrol tersebut. Salah satu cara yang dapat dipakai adalah dengan memeriksa kebijakan keamanan (security policy) yang telah ditetapkan. Tetapi, terkadang langkah ini dilewati dengan berbagai macam alasan, dan pihak auditor melakukan blind audit dengan semata-mata berpatokan pada best practices seperti ISO 17799, dan COBIT. Penggunaan best practices tanpa memperhatikan alasan dibalik pangadaan kontrol tersebut, sering menyebabkan kontrol yang disyaratkan pada best practices tapi tidak aplikatif bagi perusahaan, menjadi temuan auditor.
Suatu kali seorang manajer TI perusahaan alat-alat berat mendapat teguran dari atasannya karena pada audit yang dilakukan auditor luar (external auditor), ditemukan adanya user pada divisi keuangan yang mempunyai privilegeadministrator pada sistem operasi. Temuan tersebut dikategorikan sebagai high risk. Kalau hanya dilihat dari kacamata best practices saja, akses dengan level administrator memang seharusnya hanya diberikan kepada administrator. Tetapi, alasan dibalik kenapa user pada divisi keuangan tersebut mempunyaiprivilege administrator, ternyata disebabkan oleh program yang digunakan usertadi membutuhkan privilege administrator agar dapat berjalan sempurna.

Assessment
Apa salahnya menggunakan best practices dalam melakukan audit ? Penggunaan best practices sebetulnya sah-sah saja selama pihak yang diaudit juga menggunakan best practice yang sama. Perlu diingat, kontrol yang diuji dalam audit, seharusnya adalah kontrol yang telah disepakati bersama oleh pihak-pihak yang berkepentingan terhadap keamanan aset yang dijaga oleh kontrol tersebut, yang biasanya dirangkum dalam bentuk kebijakan keamanan (security policy ).
Dalam British Standard 7799 bagian kedua (BS 7799:2), yang merupakan acuan dalam proses sertifikasi BS 7799, menyebutkan perlunya statement of applicability (SOA) pada akhir assessment . SOA adalah suatu pernyataan, atau boleh dikatakan sebagai suatu kesepakatan dari perusahaan terhadap kontrol-kontrol mana saja yang disarankan BS 7799:1 (atau sekarang sudah diadopsi menjadi ISO 17799, salah satu standar internasional manajemen kemanan sistem informasi) yang relevan dan dipakai, dan mana yang tidak. Dalam proses sertifikasi BS 7799 ini, pihak auditor akan berpatokan pada SOA yang telah ditetapkan bukan pada keseluruhan kontrol yang direkomendasikan BS 7799.
Kerancuan aktivitas audit dan assessment sering dijumpai pada Request for Proposal (RFP). Beberapa RFP meminta jasa audit yang sebenarnya adalah kegiatan assessment , atau sebaliknya, meminta jasa assessment yang sebenarnya adalah kegiatan audit. Penggunaan kata audit dan assessmentsering dipertukarkan, yang pada esensinya berbeda fungsi dalam manajemen keamanan sistem informasi.
Assessment adalah kegiatan yang dilakukan pada awal proses manajemen keamanan sistem informasi, yang ditujukan untuk mengidentifikasikan risiko-risiko beserta bentuk kontrol yang perlu diadakan untuk mengurangi risiko tersebut. Dalam melakukan assessment best practices seperti COBIT, maupun ISO 17799 akan sangat berguna dalam memberikan kerangka kerja yang sistematis dan komprehensif. Memang kadang kita sulit membedakan kegiatan audit dan assessment dalam praktik di lapangan, karena ada kegiatan audit yang diawali dengan assessment terlebih dahulu. Atau, hasil temuan audit sering menjadi bahan pertimbangan untuk melakukan re- assessment terhadap kontrol yang ada, sehingga kegiatan audit kelihatannya sebagai kegiatanassessment .
Pada kasus manajer TI perusahaan alat-alat berat di atas, temuan audit tersebut seharusnya dapat menjadi pertimbangan untuk pengadaan kontrol yang lebih baik, ketimbang hanya sekedar menyalahkan prosedur kerja divisi TI. Kontrol yang dapat diadakan untuk kasus ini adalah, misalnya pemisahan sistem atau komputer yang digunakan untuk menjalankan program keuangan tadi terhadap sistem yang lain, sehingga si user mempunyai privilege administrator hanya untuk sistem itu saja, bukan untuk sistem yang lain. Atau jika memungkinkan, dibuatkan suatu mekanisme baru sehingga program tersebut pada saat aktif memiliki privilege sebagai administrator, walaupun dijalankan oleh user yang tidak memiliki privilege administrator.

08.54 | 0 comments | Read More

Menghitung Service Level Agreement

Semua ini diawali dengan seringnya beberapa client dan beberapa rekan kerja sering melakukan diskusi bersama terkait dengan service yang mereka terima dari vendor. Biasanya hal ini terjadi karena merasa tidak mendapatkan service yang seharusnya saat produk tersebut ditawarkan ..  (hehe he...biasa marketing ). 

Apa itu SLA ?
Sesuai dengan judul diatas Service Level Agreement bisa diartikan sebagai perjanjian kedua pihak terkait dengan service yang akan diberikan dan service yang akan diperoleh customer. Maka berbicara SLA terlebih untuk jasa Korporasi/perusahaan misal sebuah perusahaan menyewa layanan  jaringan komunikasi Bank A. maka SLA terkait dengan ketersediaan layanan jaringan selama 365 hari dalam satu tahun akan menjadi dasar pengukuran layanan yang diberikan kepada Bank A.
Bila vendor tidak dapat menyediakan layanan sesuai dengan SLA yang diperjanjikan berarti mereka melanggar SLA yang telah diperjanjikan. Misal layanan SLA 99% dalam satu bulan dan atau satu tahun.

Mengapa kita perlu SLA ? 
sebelumnya saya sudah informasikan bahwa SLA bisa dikatakan sebagai garansi terkait komitmen vendor kepada kita, sebagai bentuk tanggung jawab mereka kepada customer untuk dapat memberikan layanan sesuai dengan apa yang telah diperjanjikan oleh kedua pihak. Maka bila hal tersebut terjadi ketidak sesuaian dari perjanjian dan hal tersebut berulang terjadi, maka SLA akan menjadi perhatian. 
Jadi jelas bahwa SLA menjadi garansi layanan yang diberikan vendor kepada customernya.  

Mengapa SLA dibutuhkan
SLA dibutuhkan dilihat dari sisi penyedia layanan adalah sebagai jaminan atas service yang diberikan kepada klien, sehingga klien tersebut bisa puas atas layanan yang diberikan, dampak lain yang akan muncul dari sisi penyedia layanana adalah konsep pemasaran tradisional yaitu pemasaran dari mulut ke mulut , maksudnya adalah klien akan memberikan rekomendasi kepada temannya/ rekan lainnya bahwa layanan yang diberikan oleh penyedia tersebut bagus, sehingga berharap teman/ rekan lainnya mau berlangganan kepada provider/ penyedia layanan tersebut
Dari sisi Klien adalah menjamin aspek ketersedian  (availability) informasi(kalau kita mengacu kepada konsep informasi yang berkualias, adalah mengacu kepada availability, accurate, Update). Sehingga pihak klien merasa terbantu dengan ketersediaan layanan yang diberikan oleh pihak provider, sehingga proses pengelolaan data/ informasi dengan pihak-pihak terkait (customer/ vendor) berjalan lancar & tidak terganggu karena layanan itu mati, bisa dibayangkan jika klien tersebut adalah sebuah institusi perbankan (dimana layanan yang dibutuhkan adalah 24 jam , dengan kata lain layanan internet nya tidak boleh down (mati), dan bisa dibayangkan juga jika layanan dari perbankan itu down (mati), akibatnya dari aspek pemasaran nasabahnya dari bank tersebut tidak akan percaya , sehingga dampak yang paling tragis adalah nasabah tersebut akan berpindah kepada layanan dari bank lain ?, begitupula layanan-layanan lainnya seperti Perguruan tinggi, yang nantinya akan berdampak kepada image yang kurang baik dari perguruan tinggi tersebut.

SLA sebagai layanan untuk Aplikasi Bisnis
Dengan mengetahui hal itu, diharapkan tingkat pelayanan dan juga tingkat minimum, pelanggan dapat menggunakan layanan dengan maksimal. Hal ini juga sangat membantu jika klien adalah perantara, yang menjual kembali atau bundling dengan pelayanan yang lebih besar yang sedang dijual. SLA telah digunakan sejak awal 1980-an oleh perusahaan telepon dengan pelanggan dan reseller yang lebih besar perusahaannya dengan pelayanan mereka. Konsep “tertangkap” dari bisnis unit dan usaha lainnya dalam perusahaan besar mulai menggunakan istilah dan pengaturan yang ideal dalam awal kontrak layanan telekomunikasi.
Ide menciptakan sebuah layanan yang lebih besar dari layanan yang lebih kecil hampir membutuhkan SLA dari penyedia jasa. Misalnya, untuk memiliki cakupan ponsel nasional, Anda tidak perlu untuk membangun menara dan antena di seluruh kota. Sebaliknya, Anda bisa menemukan perusahaan lokal dan daerah yang menawarkan layanan yang sama, menulis tentang SLA dan mengukur hasilnya. Untuk pelanggan anda, anda akan menawarkan SLA yang sama. Dalam SLA asli tidak memerlukan perusahaan dari mana anda membeli, dan anda dapat mengontrol biaya anda, ketika pelanggan mematuhi SLA yang anda buat dengan mereka. Hal ini memberikan kemampuan bagi Perusahaan untuk menggunakan banyak sub kontraktor untuk menyediakan pelayanan yang lebih besar, namun mengendalikan biaya dan sumber daya untuk menawarkan produk yang lebih besar.
Penggunaan SLA tidak terbatas pada dunia IT atau telekomunikasi – mereka juga digunakan untuk real estate, medis dan bidang apapun yang menyediakan produk atau layanan kepada pelanggan.Layanan berorientasi manusia dan bisnis memiliki kebutuhan untuk mengukur dan memikul tanggung jawab, dan SLA menyediakan pengukuran dan ide bagi entitas untuk menyepakati.

Bagaimana Menghitung SLA
Untuk menghitung SLA tergantung dari layanan yang diberikan sebagai contoh yang mudah  beberapa provider IT  khususnya provider / penyedia layanan internet memberikan SLA antara 96% – 99%, artinya dalam 1 bulan pihak provider menjamin bahwa layanan yang diberikan adalah :
Berikut ilustrasi bila kita asumsikan SLA yang diperjanjikan adalah 98%, dalam hal ini verdor tersebut memberikan layanan selama satu bulan sebesar 98% dalam keadaan ON, artinya ada kemungkinan 2 % mengalami kendala dan hal itu menjadi tidak permasalah.

ilustrasi  :
1 hari = 24 Jam   1 bulan = 30 Hari

Andaikan cost sewa internet dalam satu bulan Rp 1.000.000,- maka
1 Bln =  30 x 24 = 720 Jam   (720 Jam adalah nilai dari 100 % layanan )

sedangkan bila SLA yang diperjanjikan kepada kita adalah 98 %
98 % x 720 = 705.6  Jam. Jadi nilai yang diperjanjikan dalam satu bulan kondisi UP adalah sebanyak 705.6 Jam sedangkan bila terjadi kendala dalam satu bulan bila dijumlahkan waktunya sampai dengan 14.4 Jam masih dalam kondisi yang wajar.

Bagaimana bila terjadi kurang dari jumlah SLA 
Kondisi dapat terjadi bila vendor tidak cermat dalam mengelola bisnisnya atau terjadi wan prestasi dalam kontrak tersebut. Hal ini biasa disebut juga dengan denda pengembalian atau pembayaran kepada pihak penyewa biasa disebut juga dengan Restitusi.
Sebagai contoh berdasarkan cost yang dibayarkan pelanggan untuk menyewa layanan internet dalam satu bulan harus membayar Rp. 1.000.000 :

Biaya bulanan internet = Rp. 1.000.000
SLA layanan (contoh bulan Juli)  = 76,6% (100% – 23,3%), artinya pihak provider bulan juli hanya bisa memberikan layanan internet sebesar 76,6% artinya ada selisih (98% – 76.6% = 21.3%, yang tidak bisa dipenuh oleh pihak provider)
Nah 21,3 % itu adalah hak kita u/ mendapatkan penggantian, penggantian ini biasanya dlm bentuk pengurangan pembayaran, misalkan kita bayar
1bulan Rp. 1.000.000 = untuk layanan 98% (1% sekitar Rp. 10.000)
Maka u/ layanan hanya 76.6% = 1.000.000 – (21.3% X Rp. 10.000)
=  Rp1.000.000 – Rp. 213.000
    =  Rp. 787.000
Artinya dlm bulan ini kita hanya punya kewajiban membayar sekitar Rp. 787.000
Semoga sharing ini dapat bermanfaat bagi rekan sekalian, mengingat manfaatnya kita dengan memahami SLA, semoga dapat diaplikasikan dilingkungan tempat rekan sekalian hingga kita tidak memiliki masalah. Patut diingat awal dari perhitungan SLA itu mulai dihitung saat kita telah mendapatkan tiket problem terkait layanan yang tidak dapat mereka hadirkan kepada kita sebagai customer sesuai dengan yang diperjanjikan maka mulai saat itu kita dapat menghitung berapa persentase yang akan dijadikan nilai persentase layanan yang mereka berikan.



08.50 | 0 comments | Read More