LPSE [In]security

Josua Sinambela
Follow me

Josua Sinambela

Professional Computer Network & Information Security Consultant, Digital Forensic Investigator. Have more than 14 years of experiences in Networking Technology & InfoSec fields
Josua Sinambela
Follow me

LPSEINFOsec.ID –  Lembaga Pengadaan Secara Elektronik atau disingkat LPSE, merupakan lembaga yang berfungsi untuk menyelenggarakan pengadaan barang/jasa untuk Pemerintahan, baik di tingkat pusat maupun daerah. LPSE memanfaatkan aplikasi SPSE (Sistem Pengadaan Secara Elektronik) yang dikembangkan oleh Lembaga Kebijakan Pengadaan Barang/Jasa Pemerintah (LKPP) bekerja sama dengan Lembaga Sandi Negara (LEMSANEG) dan Badan Pengawasan Keuangan dan Pembangunan (BPKP). LKPP merupakan salah satu dari 28 Lembaga Pemerintah Non-Kementerian (LPNK) yang berada di bawah dan bertanggungjawab langsung kepada Presiden Republik Indonesia.

LKPP mulai mengembangkan SPSE sejak tahun 2007, saat ini SPSE terakhir dikenal dengan SPSE versi 4.1.0. Pemanfaatan aplikasi e-procurement seperti SPSE dalam pengadaan barang/jasa untuk pemerintahan adalah langkah yang sangat baik untuk menuju Good Governance dan perlu didukung setiap elemen pemerintah, pelaku usaha dan masyarakat umum.

Bulan April 2016 lalu, kabar terkait keamanan LPSE kembali menjadi booming disebabkan marak berita tertangkapnya salah satu tersangka pelaku pembobolan aplikasi Sistem Pengadaan Secara Elektronik (SPSE) yang dikelola oleh LPSE. Beberapa berita bisa dilihat pada url satu, dua, tiga dan empat

Dari informasi pada berita berita tersebut dapat diambil beberapa kesimpulan, bahwa pelaku sudah melakukan aktifitas ilegalnya cukup lama dan berhasil mengakses dan mengontrol/mengatur sistem -sistem LPSE di beberapa lokasi/sistem yang berbeda. Dan berdasarkan analisis penulis, kelompok yang anggotanya sudah tertangkap ini bukan merupakan satu satunya yang mampu melakukan aktifitas ilegal tersebut. Sebenarnya kasus yang kurang lebih sama sudah terjadi sebelum-sebelumnya dibeberapa sistem LPSE yang tersebar di Indonesia, banyak pelaku usaha yang ingin ikut tender di berbagai LPSE tetapi karena selalu ada gangguan pada sistem maka tidak dapat mengakses sistem SPSE, akhirnya tidak berhasil mengupload dokumen sebagai administrasi peserta lelang.

Mungkin masih ada pelaku atau kelompok lainnya yang mampu dan melakukan aktifitas pembobolan sistem pada LPSE seperti kasus tersebut. Penulis akan mencoba mengurai berbagai faktor-faktor mengapa masih dimungkinkan terjadi penyalahgunaan akses dan pembobolan dengan memetakan keamanan sistem LPSE saat ini berdasarkan prinsip-prinsip keamanan dan lapisan (layer) keamanan.

Pada bukunya Computer crime: a crimefighter’s handbook, David Icove membagi keamanan komputer menjadi beberapa lapisan, yakni lapisan Keamanan Fisik (Physical Security), Manusia/SDM (People), Data/Teknik Komunikasi (System/Technology), Kebijakan/Prosedur (Policy & Procedure). Penulis akan mencoba menggambarkan kondisi SPSE berdasarkan lapisan-lapisan tersebut satu-persatu.

Keamanan Fisik (Physical Security)

data-center-1-862x646

Sistem SPSE yang digunakan oleh LPSE-LPSE, saat ini terpasang di ratusan (atau bahkan ribuan) mesin server yang tersebar di seluruh instansi-instansi pemerintahan baik di Pusat (Lembaga/Kementrian maupun Non Kementrian) maupun Daerah. Setiap instansi mengelola infrastruktur (datacenter) masing masing LPSE, mulai dari Jaringan Intranet/Internet hingga server-servernya. Setiap instansi dan pemerintah daerah memiliki kesiapan dan kelengkapan infrastruktur berbeda satu sama lainnya, banyak instansi pemerintah khususnya didaerah yang secara fisik, NOC atau Datacenternya belum memadai terutama dari segi keamanan. Salah satu kejadian yang merupakan pengalaman pribadi penulis beberapa tahun lalu, saat memberikan workshop keamanan pada salah satu datacenter/ruang server yang dikelola salah satu Pemerintah Daerah, tiba tiba saja ada seorang tukang semir yang masuk ke ruangan datacenter tersebut dan menawarkan jasanya, “pak sepatunya pak” sambil menunjukkan alat semir sepatu ditangannya. Ternyata pintu ruang datacenter yang berisi rak rak server dan beragam perangkat “canggih dan mahal” itu kelihatannya selalu terbuka selama jam kerja. Menariknya lagi, datacenter ini terletak di gedung satu lantai dengan ruangan kantor dengan space terbuka, meja-meja pegawai dibatasi sekat sekat pendek, ruang datacenter hanya dibatasi oleh sekat kaca transparan. Sehingga setiap pegawai dan masyarakat umum yang lalu lalang dari sekitar datacenter di kantor tersebut, bisa melihat isi datacenter dari luar ruangan. Jika tukang semir sepatu saja bisa masuk, artinya phisical security bisa dikatakan hampir tidak ada. Memang banyak juga pemerintah daerah yang datacenternya sudah mumpuni, dilengkapi berbagai perangkat keamanan fisik mulai dari kunci digital/fingerprint dan CCTV, dan juga dilengkapi dengan standar keamanan dari disaster (kebakaran/api). Tetapi pengalaman penulis yang sering berkunjung ke instansi pemerintah di daerah, masih lebih banyak datacenter yang dikelola “seadanya”. Penulis belum melihat adanya kewenangan LKPP sampai menentukan layak tidaknya suatu infrastruktur instansi pemerintah untuk mengoperasikan aplikasi SPSE. Penulis berharap kedepan ada standard keamanan fisik infrastruktur datacenter di setiap instansi pemerintah di daerah secara umum dan infrastruktur yang mengelola sistem SPSE secara khusus.

Manusia/SDM (People)

People Security

Pada lapisan Sumberdaya Manusia/SDM (people), terdapat beberapa hal yang perlu diperhatikan dalam implementasi sistem informasi (SPSE). Yang pertama adalah dari sisi personal pengembang sistem SPSE itu sendiri, mulai dari keahlian (skill), attitude, loyalitas hingga moral pengembang setiap sistem informasi sepenting SPSE sewajarnya harus mendapat perhatian khusus. SPSE dikembangkan berbasis web menggunakan bahasa pemrograman java dan database PostgreSQL, serta berjalan di atas server ber-OS Linux. Versi terakhir (4.x) dikembangkan menggunakan framework Play Framework, yakni framework pengembangan berbasis Java. Tentu saja para pengembang adalah orang orang yang ahli dibidangnya. Secara umum saat recruitment cukup mudah bagi IT Management suatu instansi melihat skill/keahlian seseorang, tetapi untuk attitude, loyalitas dan moral mungkin hanya orang-orang tertentu yang bisa menilainya (spt psikologi), atau bahkan hanya waktu yang bisa mengungkapkannya. Penulis pernah membaca dari beberapa sumber berita, bahwa banyak pengembang SPSE di LKPP yang telah berpindah pindah, artinya kemungkinan adanya “turnover itention” yang cukup tinggi, sehingga LKPP harus mencari pengganti penerus para developer tersebut. Turnover” seorang developer dari sebuah tim pengembang sistem informasi jika tidak diantisipasi sebelumnya, bisa menjadi seperti mimpi buruk bagi tim pengembang lainnya, karena tidak mudah menemukan rekan developer yang sama pola kerjasama/skill/attitudenya. Apalagi jika seorang developer tersebut termasuk salah satu “panutan” atau “sumber inspirasi teknis” bagi rekan rekannya satu tim. “Turnover intension” seorang developer biasanya berhubungan dengan work environment dan remunerasi, tetapi tidak tertutup juga karena permasalahan lainnya. Yang paling perlu dikuatirkan adalah jika si developer yang akan keluar/pindah dengan sengaja atau tanpa sengaja meninggalkan bugs atau backdoor pada aplikasi yang dikembangkannya. Artinya security bugs dan backdoor ini suatu saat dapat ditemukan atau dimanfaatkan orang lain. Yang kedua atau berikutnya adalah dari sisi orang orang yang pengelola infrastruktur dan sistem SPSE itu saat diimplementasikan. Pada sisi ini, kita ketahui bahwa pengelola infrastruktur dan sistem SPSE merupakan tim bentukan instansi pemerintah di pusat maupun daerah yang menjalankan LPSE. Pengelola infrastruktur dan sistem yang dimaksud adalah system administrator dan network administrator yang bertugas merawat sistem dan jaringan SPSE. Hampir sama dengan pengembang sistem, faktor faktor seperti skill, attitude, loyalitas dan moral juga menjadi perhatian yang penting bagi pengelola infrastruktur dan sistem SPSE ini. Jika di LKPP Pusat mungkin dengan mudah mendapatkan/mencari atau memfilter system/network administrator yang mumpuni secara skill, tetapi pasti sangat berbeda kondisinya dengan di instansi  pada Pemerintah Daerah khususnya di luar Jawa. Biasanya di lingkungan pemerintah daerah, relatif sulit mencari system/network administrator yang memiliki skill baik. Apalagi sampai memfilter yang memiliki attitude, loyalitas dan moral? Tidak jarang di instansi pemerintahan terutama di daerah, system/network administrator SPSE di handle, ditangani atau bahkan di maintenance oleh pihak ketiga (orang orang ini biasanya yang dipercaya oleh instansi tersebut, yang tidak jarang juga merupakan kontraktor TI di daerah tersebut). Sebagai system administrator sebuah server yang memiliki akun admin atau superuser, memiliki priviledge untuk mengontrol sistem secara penuh, dapat mengakses database dan dokumen-dokumen pada sistem secara langsung tanpa tercatat pada sistem aplikasi. Berbeda dengan pengguna yang berstatus panitia, ppk dan bahkan auditor, yang mungkin hanya dapat berinteraksi melalui sistem aplikasi SPSE dan otomatis dapat terekam pada history aplikasinya. Bagian lain yang harus diperhatikan dari setiap pengelola sistem SPSE (system administrator dan network administrator), bahwa belum adanya standard kompetensi untuk keahlian (skill) yang dijadikan acuan bahwa seseorang administrator sistem/jaringan SPSE sudah layak atau belum mengelola sistem SPSE. Karena menurut penulis, administrasi pengelolaan dan monitoring sistem SPSE termasuk bagian yang sangat kritis untuk keberhasilan LPSE memenuhi tugas-tugas dan tanggungjawabnya mencegah kecurangan pada proses pengadaan. Berbeda dengan panitia pengadaan (PPK) yang sudah memiliki standard kompetensi dengan mengikuti ujian tertentu yang ditetapkan oleh LKPP. Secara umum para system dan network administrator yang ditunjuk ikut mengelola SPSE di instansi instansi dan daerah merupakan administrator datacenter yang tugasnya bukan hanya mengelola SPSE, tetapi ada banyak sistem/server dan jaringan lain yang harus dikelola, sehingga monitoring atau pengelolaan SPSE terkadang tidak dilakukan dengan baik. Biasanya system administrator dan network administrator tersebut melakukan administrasi sistem SPSE hanya saat terjadi incident atau sistem tidak dapat diakses berdasarkan laporan para pengguna. Padahal system dan network administrator merupakan ujung tombak keamanan sistem dan aplikasi SPSE, yang harusnya secara periodik harus selalu melakukan update, monitoring sistem, dan koordinasi dengan pengembang di LKPP Pusat untuk mengantisipasi adanya anomali dan berbagai ancaman serangan.

Sistem/Data/Teknik Komunikasi (System/Technology)

system-security

Jika kita semua sepakat bahwa sistem yang digunakan oleh LPSE yakni SPSE adalah sistem yang sangat penting dan berharga demi kepentingan masyarakat melalui implementasi good governance dan percepatan pembangunan, maka SPSE sudah seharusnya menjadi sistem yang memiliki kehandalan yang baik dan dan keamanan yang tinggi. Oleh sebab itu juga SPSE harusnya sudah menggunakan teknologi atau teknik teknik pengamanan data/informasi dan komunikasi terbaik. Tetapi berdasarkan pengamatan penulis yang sudah biasa melakukan audit keamanan, penetration testing dan security testing di berbagai instansi pemerintahan, universitas dan corporate, sepertinya belum demikian kondisinya. Aplikasi SPSE yang dikembangkan oleh LKPP bersama LEMSANEG dan BPKP mulai dari versi awal hingga versi yang terakhir (SPSE v.4.x ?) masih memiliki kelemahan pada keamanan (security vulnerability) dan sifatnya berbahaya (kritikal), kelemahan-kelemahan ini ditemukan penulis saat ada kegiatan audit/penetration testing terhadap beberapa instansi pemerintah berdasarkan permintaan instansi tersebut. Saat artikel ini ditulis versi SPSE yang paling banyak digunakan adalah v.3.6, meskipun masih ada beberapa yang menggunakan v3.5. Saat ini LKPP sedang menyiapkan agar LPSE-LPSE di setiap lembaga pemerintah mulai migrasi ke v.4.x.

Penulis meyakini bahwa LKPP sudah melakukan antisipasi-antisipasi adanya vulnerabilitas pada setiap sistem telah dikembangkan. LKPP dipastikan juga telah melakukan internal audit atau internal penetration testing atau vulnerability assessment, atau bahkan juga mungkin telah mengundang dari pihak eksternal. Penulis sendiri masih ingat, sekitar tahun 2007/2008 ketika LKPP akan memperkenalkan sistem SPSE versi awal yang dikembangkannya, LKPP mengirimkan surat permintaan penawaran untuk kegiatan penetration/security testing/vulnerability assessment yang ditujukan kepada lembaga-lembaga dan perusahaan bidang keamanan di Indonesia. Salah satu yang menerima surat permintaan penawaran dari LKPP pada saat itu termasuk tempat penulis bekerja saat ini. Dari kejadian tersebut, penulis sangat menyakini bahwa LKPP sudah aware terhadap kemungkinan adanya permasalahan keamanan pada sistem yang dikembangkannya. Tetapi karena setiap aplikasi merupakan hasil pekerjaan para tim developer yang juga manusia, bisa dipastikan selalu dimungkinkan ada kesalahan pengkodean yang terjadi sehingga menyebabkan munculnya kelemahan (vulnerability) pada sistem aplikasi SPSE. Bahkan meskipun SPSE tersebut sudah dilakukan antisipasi seperti penetration testing/security testing baik internal maupun eksternal, tetap saja dimungkinkan selalu adanya temuan-temuan kelemahan baru, yang mungkin tidak ditemukan saat proses assessment/pentest sebelumnya. Hal ini dapat juga disebabkan pengalaman dan skill setiap pentester/auditor juga pasti berbeda atau perkembangan teknologi yang relatif sangat cepat. Kritikalnya adalah jika terdapat salah satu kelemahan pada kode aplikasi yang bisa diexploitasi di salah satu SPSE, maka dipastikan semua SPSE yang terpasang oleh LPSE yang menggunakan versi yang sama juga memiliki kelemahan. Dapat disimpulkan juga bahwa jika seorang hacker mampu membobol salah satu LPSE/SPSE, maka dimungkinan dapat membobol ratusan SPSE lainnya.

Kedepannya diharapkan selain melakukan penetration testing secara berkala, baik oleh tim internal maupun external, LKPP dapat juga mengadopsi mekanisme bug bounty seperti yang dilakukan oleh berbagai perusahaan internet dan DoD US beberapa waktu lalu. Bug bounty pada dasarnya merupakan suatu program yang diperuntukkan bagi para praktisi keamanan untuk mencari celah-celah yang rentan dieksploitasi dari suatu produk layanan yang berbasis TI. Program ini pada umumnya dibuat oleh perusahaan-perusahaan besar atau lembaga pemerintah yang sangat bergantung pada media internet untuk mengizinkan bug hunter (istilah peserta bug bounty) mencari celah keamanan dari produk mereka. Sebut saja Microsoft, Twitter, Google, Facebook, PayPal, Uber ataupun perusahaan raksasa lainnya yang selalu menjadi langganan bagi para bug hunter untuk melaporkan celah keamanan. Selain kelemahan dari sisi pengkodean aplikasi SPSE, kemungkinan kelemahan lainnya adalah pada proses penyimpanan informasi/data pada database. Banyak developer/analis sistem yang hanya memanfaatkan teknik teknik proteksi enkripsi/hashing sederhana dalam menyimpan informasi yang sifatnya sensitif/rahasia, misalnya password, Token, Private Key. Pada banyak kasus, developer-developer masih percaya dengan kekuatan algoritma hashing (sering di sebut enkripsi searah) seperti MD5, SHA1, SHA256 atau bahkan SHA512 dalam pengamanan password di database. Padahal sudah jelas-jelas hasil hashing ini dengan mudah di pecahkan (crack) melalui dictionary/brute force attack, atau dengan hanya memanfaatkan fasilitas hash cracker online yang bertebaran di internet. Ada juga developer yang hanya menyimpan informasi sensitif/rahasia hanya mengandalkan teknik encode seperti base64, yang mana sangat mudah dibaca dan dibongkar. Pada beberapa aplikasi, para developer ada juga yang sudah lebih baik pengamanan informasi/datanya pada database, meskipun masih tetap menggunakan algoritma hashing, tetapi dengan adanya salt (salting) yakni penambahan kode tertentu pada informasi password yang akan di-hash sebelum disimpan pada database. Sehingga meskipun attacker/hacker mampu mengakses database tersebut dengan teknik teknik hacking (contoh: SQL Injection), tetapi informasi hash tersebut masih relatif lebih sulit untuk dipecahkan (di-crack) dibandingkan tanpa salt sama sekali. Penyimpanan informasi-informasi yang bersifat sensitif/rahasia jika diperoleh pihak lain seperti password, private key, token idealnya disimpan dengan algoritma enkripsi yang lebih kuat dan bukan dengan sekedar checksum/hashing. Sehingga meskipun terjadi incident atau database kebobolan, informasi tersebut masih relatif lebih sulit untuk dibaca/dipecahkan si attacker. Salah satu contoh algoritma enkripsi yang relatif lebih baik dari pada algoritma hashing spt MD5, SHA1, SHA256 adalah bcrypt/jbcrypt. Pada bahasa pemrograman PHP dan Java sudah disediakan komponen atau modulenya. Jikapun ingin tetap memanfaatkan algoritma hashing, diharapkan developer menambahkan salt yang dinamis untuk setiap akun/passwordnya.

Dari sisi komunikasi data, karena aplikasi SPSE merupakan aplikasi yang berbasis Web, maka harusnya telah memanfaatkan protokol HTTPS (SSL) secara default. Dari pengamatan penulis, hanya sekitar 20-30% dari seluruh LPSE yang ada yang telah memanfaatkan protokol HTTPS pada sistem SPSE mereka. Sedang 70-80% masih menggunakan protokol HTTP (Plain Text) saja. Hal ini dapat menjadi masalah keamanan yang serius bagi setiap LPSE yang masih memanfaatkan HTTP saja, karena setiap komunikasi data yang dilakukan setiap pengguna baik itu admin, panitia, ULP, auditor dan penyedia akan dimungkinan disadap atau dibaca oleh pihak pihak yang tidak bertanggung jawab, khususnya jika mengakses sistem SPSE dari jaringan public atau jaringan yang tidak dapat dipercaya seperti Wifi/Hotspot. Implementasi HTTPS/SSL pada server juga sebenarnya belum tentu dapat menjamin komunikasi data pengguna selalu terenkripsi saat transmisi. Menurut penulis, untuk sistem SPSE yang saat ini, meskipun LPSE yang mengelola sudah menggunakan HTTPS/SSL, masih ada teknik teknik yang dapat digunakan para hacker untuk melakukan downgrade protokol (seperti stripping SSL). Hal ini terutama disebabkan jika ternyata server aplikasi SPSE belum menerapkan HSTS Policy (HTTP Strict Transport Security). Setiap teknologi keamanan yang diciptakan memang selalu ada cara/trick bagi para hacker untuk mem-bypass-nya, oleh sebab itu keamanan sistem/aplikasi jangan dianggap sebagai sekedar fitur, melainkan merupakan proses yang harus dilakukan secara terus-menerus. Dengan menerapkan sistem keamanan yang tinggi, berarti akan mengurangi kenyamanan dalam menggunakan dan mengelolanya. Sehingga kita harus menyesuaikan dengan level keamanan yang kita inginkan, masih ingat bahwa kita menginginkan keamanan SPSE ke level tertinggi atau seaman mungkin, sehingga tujuan dibangunnya SPSE tersebut tercapai.

Kebijakan dan Prosedur (Policy & Procedure)

Write Your Own Stinking Procedures

LKPP yang merupakan singkatan dari Lembaga Kebijakan Pengadaan Barang/Jasa Pemerintah, secara harfiah dari nama lembaga sudah jelas bahwa tugas utama berhubungan dengan pengembangan/penyusunan kebijakan-kebijakan terkait pengadaan barang dan jasa pemerintah. Jadi dapat dipastikan lembaga LKPP memiliki banyak ahli yang berpengalaman dalam membuatkan berbagai kebijakan-kebijakan dan prosedur-prosedur sesuai dengan tugasnya. LKPP sudah membuat berbagai kebijakan-kebijakan dan berbagai SOP terkait layanan pengguna, pedoman bimtek, pengamanan & pemeliharaan infrastruktur, dokumentasi, pengembangan sistem, registrasi hingga penanangan masalah SPSE. Kebijakan dan SOP ini juga sudah disosialisasikan dan didistribusikan ke setiap LPSE yang ada di instansi pusat maupun daerah. Menurut penulis, dari mempelajari dokumentasi online terkait kebijakan dan SOP-SOP yang ada, harusnya sudah tidak ada lagi permasalahan yang berlarut-larut dengan sistem SPSE, karena SOPnya sudah sedemikian lengkap dan jelas hingga setiap penanganannya. Setiap bagian/unit/komponen LPSE sudah memiliki tanggungjawab dan kewenangan masing masing. Sekarang tinggal bagaimana melakukan monitoring terhadap implementasi di lapangan, apakah semua SOP telah dilakukan secara baik, atau masih banyak aktifitas yang tidak sesuai dengan SOP tersebut, dan bagaimana proses pemberian sanksi jika ternyata terdapat pelanggaran atau tidak sesuai Kebijakan dan SOP tersebut.

Masih terkait kebijakan dan SOP, dari hasil pencarian online, penulis menemukan dokumen SOP LPSE yang cukup lengkap dan detil dipublish oleh salah satu LPSE Kementerian. SOP ini terdiri dari 400 halaman. Menurut analisis penulis, dari keseluruhan isi dokumen SOP ini, banyak informasi yang harusnya hanya diketahui kalangan terbatas, yaitu komunitas Pengelola LPSE saja, hal ini adalah untuk menjaga informasi tersebut tidak disalahgunakan oleh pihak yang tidak bertanggung jawab. Penulis mengkategorikan beberapa informasi pada dokumen SOP tersebut sebagai Information Leakage” yang harusnya bisa diminimalkan. SOP-SOP yang terpublish secara online harusnya adalah yang memang berhubungan dengan layanan pengguna atau masyarakat luas. Informasi yang dapat disalahgunakan para cracker/hacker pada SOP yang terpublish tersebut antara lain :

– Proses Instalasi SPSE, Framework SPSE hingga detil framework SPSE
– Konfigurasi Web, Path Konfigurasi, Konfigurasi Database hingga File Log System/Aplikasi
– Daftar paket aplikasi dan aplikasi pendukung, path Aplikasi hingga versi setiap aplikasi
– Konfigurasi Keamanan Web, penggunaan Web Application Firewall dan Module keamanan lainnya
– Nama Database, User dan Password database yang digunakan untuk latihan dan production
– Instruksi-instruksi monitoring Log, pengamanan datacenternya, informasi backup & recover
– Prosedur penangan insiden keamanan, infrastruktur, dan sistem

Detil Framework SPSE
Detil Framework SPSE

Jika para hacker/attacker mendapatkan informasi informasi diatas dengan mudah, artinya kelemahan dari sistem SPSE tersebut otomatis menjadi relatif lebih mudah juga didapatkan. Demikian juga untuk menemukan cara-cara evasion dari setiap filter/proteksi yang dilakukan oleh sistem SPSE, sehingga kemungkinan untuk dipenetrasi/exploitasi semakin besar. Pada proses pengamanan sistem informasi, terdapat lapisan keamanan yang biasa disebut dengan istilah “Security by Obscurity”, artinya untuk keamanan sistem, kita dapat menambahkan lapisan untuk mempersulit para attacker/hacker menemukan informasi-informasi mengenai jenis teknologi, konfigurasi, teknik proteksi hingga versi aplikasi yang kita gunakan. Selain dengan tidak mempublish jenis aplikasi, versi aplikasi dan konfigurasi, kita juga bisa membuat seolah-olah jenis aplikasi atau versinya tidak sesuai dengan kenyataanya. Bukan berarti kita hanya memanfaatkan lapisan tersebut sebagai satu satunya pengaman sistem, tetapi kita hanya menjadikannya sebagai salah satu lapisan keamanan tambahan, sehingga para attacker terutama para “kiddies” relatif lebih sulit untuk menemukan informasi tersebut. Sedangkan lapisan-lapisan keamanan lainnya tetap masih harus diaktifkan atau dilakukan.

Facebook Comments

Josua Sinambela

Professional Computer Network & Information Security Consultant, Digital Forensic Investigator. Have more than 14 years of experiences in Networking Technology & InfoSec fields

You May Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *