CARAKA adalah sistem autentikasi yang mumpuni, mampu melakukan autentikasi meskipun sumber daya yang diautentikasi berada dalam kondisi offline. Hal ini sangat dibutuhkan untuk sistem-sistem produksi yang sangat bermisi kritis, di mana biasanya Database dibuat tidak dapat diakses oleh manapun kecuali dari Aplikasi (karena memang yang membutuhkan data adalah aplikasi). Dengan adanya CARAKA, kita tetap dapat menjamin sistem autentikasi yang terjaga, termonitor, dan tervalidasi (dengan adanya fitur approval). CARAKA tidak dirancang untuk mendeteksi Ransomware secara langsung sehingga pertanyaan di atas tidak terlalu relevan dengan topik dan penjelasan terkait CARAKA.

Sebagai catatan: Akses Control itu selalu bersifat reaktif, sistem pengamanan yang bersifat proaktif dapat diharapkan pada antivirus, namun semua sistem pertahanan keamanan secara umum dirancang untuk bersifat reaktif karena proaktifitas dari sistem keamanan pada sistem produksi dalam berpotensi membuat sistem menjadi lambat sehingga kontraproduktif dengan tujuan dibangunnya sistem pelayanan tersebut.

Kami sudah pernah menyampaikannya di tahun 2021 dan 2022 di webinar-webinar yang kami selenggarakan jauh sebelum adanya studi kasus tersebut. Kami menyampaikan bahwa ketika terjadi breach terhadap sistem, mayoritas dilakukan oleh internal atau human error. Hal seperti ini biasa disebut dengan fraud atau penyalahgunaan akses dan privileged yang sudah menjadi hal umum di mana-mana.

CARAKA diciptakan untuk mengantisipasi hal tersebut, sebuah akses kontrol yang ultimate. Jadi ketika seseorang mempunyai akses kontrol, bisa diatur agar atasan dapat mengetahui jika orang tersebut menggunakan akses tersebut dan tidak sembarangan dalam melakukan sudo. Ketika ada kebutuhan untuk privilege escalation maka dengan adanya CARAKA maka atasan/klien akan tahu siapa yang mengakses dan kapan akses itu terjadi. Jadi sasaran utamanya adalah sisi operasional yang sudah diatur dalam tata laksana. Pendekatan perilaku dapat digunakan ketika disain pengaturan hak akses dirancang, bukan secara otomatis. Caraka memastikan otentikasi disisi mobile application menggunakan biometric untuk membuka akses kedalam aplikasi CARAKA setiap saat, untuk memastikan pengguna Aplikasi adalah mereka yang berwenang. CARAKA sangat menarik untuk membagi akses privilege antara End-User, Administrator, Managed Support, Vendor, dan lainnya.

Pada topik bahasan kali ini kami lebih membahas kepada cara menghindari ransomware, bukan tindakan pemulihannya. Namun, jika client Equnix ada yang terkena ransomware, maka jika ransomware tersebut mengenkripsi data dan cara membuka enkripsi tersebut hanya dengan tebusan, maka data sulit untuk diselamatkan. Sedangkan jika masih ada opportunity untuk dipulihkan, maka kami akan usahakan. Namun, kami tidak menjanjikan hal itu karena recovery juga tergantung dengan teknologi yang diimplementasikan pada ransomware.

Teknologi paling ultimate yang dapat kami sarankan untuk kalangan bisnis adalah menggunakan database yang mendukung enkripsi secara mumpuni, seperti 11DB/Postgres dengan kemampuan enkripsi sangat cepat karena menggunakan metode column-based encryption serta dilengkapi dengan index yang telah dipatenkan. Sehingga 11DB/Postgres ini cepat, aman, dan terpercaya.

Jika membicarakan teknologi from bottom to top untuk menghindari ransomware, maka kita dapat menggunakan OS Linux, database 11DB/Postgres dengan fitur enkripsi, CARAKA untuk mengontrol akses dengan ketat, HSM fisik maupun online (Ksema), serta mengimplementasikan back up yang mumpuni. Dengan begitu, maka kita dapat menghindari ransomware.

Pertanyaan yang sangat baik, jawabannya semua komponen tersebut memiliki vulnerability sendiri-sendiri sebagai celah masuknya ancaman Ransomware:

1. People: sudah jelas, ini yang paling dominan.
2. Teknologi: karena tidak ada teknologi yang sempurna, akan ada bug, exploit, dan lainnya.
3. Proses: bisa dieksploitasi karena kurang mumpuni dan kurang lengkap dalam melingkupi keseluruhan proses yang dibutuhkan.

Dan, pencegahannya sudah dijelaskan dalam presentasi sebelumnya, ada 3 langkah yang dilakukan oleh attacker dalam deployment Ransomware: Access, Monitor, and Attack! CARAKA mengambil domain pengamanan pada konteks akses. Monitor itu domain dari teknologi lainnya yang bisa di-deploy untuk kebutuhan tersebut.

(1) Jika kita bicara tentang mata uang kripto, kita tidak bisa banyak komen, karena relevan dan tidak relevan itu tergantung pada teknologi yang akan datang itu bagaimana. Misalkan pemerintah melarang transaksi menggunakan bitcoin itu berarti menjadi tidak relevan. Jika masih ada kemungkinan dipakai bitcoin sebagai bagian dalam transaksi di suatu negara, maka permintaan tebusan menggunakan bitcoin menjadi relevan (meskipun dilarang bitcoin tetap dapat ditransaksikan, namun menjadi illegal). Bahwasannya muncul ransomware, salah satu faktornya adalah bitcoin yang sudah saya jelaskan. Sebab cara lain yang selain bitcoin itu tidak mudah, atau dapat dilakukan tracking, sehingga attacker juga mempertimbangkan dua kali untuk minta tebusan menggunakan media transfer uang yang konvensional.

(2) Kemudian external logging itu diletakkannya di suatu tempat yang sangat aman di cloud. Yang terpenting adalah ketika sebuah sistem breach atau di attack oleh attacker, dia bisa menghilangkan log yang ada di sana tapi tidak bisa menghilangkan log CARAKA, karena CARAKA ada di luar sistem tersebut. Jadi aplikasi yang diperkuat autentikasinya dengan CARAKA, sebetulnya dapat tidak terkoneksi ke internet. Kita punya mekanisme untuk autentikasi dengan SyncOTP (offline OTP) dan juga karena kita bisa authenticate kita juga bisa logging. Satu-satunya komunikasi antara perangkat dengan CARAKA adalah visual QR Code itu, dan kemudian typing respon challenge nya, jadi sangat aman dan terpercaya karena kita ngelock di internet yang tidak terhubung ke resource-resource yang diamankan.

Jika HP di-root atau jailbreak oleh seseorang atau malware, maka otomatis terdapat sebuah akses atau proses yang memiliki hak akses lebih tinggi dari user yang ada, dan ini juga dapat mengancam app CARAKA. Oleh karena itu, jika ingin menggunakan CARAKA mobile, maka tidak boleh menggunakan handphone yang terkena root/jailbreak.

Jika download aplikasi, sebaiknya download dari app store yang terpercaya karena sudah ada prosedur tertentu dan dapat diketahui siapa pembuat aplikasi. Jadi, jika ada institusi yang membuat aplikasi di dalam mobile yang ternyata isinya nasty code atau malware, maka dapat dengan mudah menemukan orangnya dan bisa dituntut.

Jika kita gunakan CARAKA di server data seperti synology—yang merupakan storage server (bukan aplikasi langsung), maka tetap dimungkinkan. Namun, harus modifikasi storage tersebut agar dapat melakukan autentikasi dengan CARAKA. Ketika laptop/server terhubung ke NFS/NASF, maka akan muncul QRCode yang harus di-capture dengan handphone supaya bisa login ke dalam laptop/server tersebut.

Anda dapat menggunakan CARAKA untuk mengimplementasikan MFA pada sistem produksi. Kami sebagai owner sebuah produk security, maka tidak etis jika kami membahas mana yang lebih baik di antara satu produk dengan produk yang lain. Saran kami kepada para user dalam memilih produk security yang baik mungkin bisa menggunakan beberapa cara. Pertama adalah dengan cara riset ke Gartner, atau Googling atau yang lain. Kemudian bisa juga dengan menggunakan konsultan yang mumpuni dan mempunyai exposure yang baik dalam bidang security. Bisa juga dengan menanyakan ke vendor mengenai kelemahan dari produk yang mereka tawarkan. Setiap produk pasti ada kelebihan dan kekurangan masing-masing. Setiap produk juga harus mempunyai fungsi spesifik yang menjadi unggulan dibandingkan dengan domain-domain lainnya. Seperti contoh database RDBMS PostgreSQL yang diperuntukkan untuk transaction.

Saya kira, kita hanya memiliki satu kesempatan mitigasi terhadap potensi serangan ransomware, yaitu before atau prevensi. Untuk during dan after silakan berkonsultasi dengan Vendor produk security seperti penyedia XDR, SDR, dll.

Untuk pencegahan, saran kami:

1. Langkah pertama adalah memastikan akses terbagi dengan tepat, dan memiliki proses supervisi yang ketat, implementasikan zero trust dengan menggunakan CARAKA. Akses disini termasuk di semua layer, dari OS, Aplikasi, Database, Network, Tools, Monitoring, dan lainnya.
2. Berikutnya, pelaksanaan backup yang presisi dan otomatis, dari ukuran, proses backup (Incremental/Snapshot), proses validasi hasil backup, data integrity check pada backup, lokasi backup dengan potensi aksesnya.
3. Laksanakan internal audit keamanan secara umum dan berkala, tentunya titik-titik rentan, dan pastikan semua mekanisme monitoring dan alert berjalan dengan semestinya.

CARAKA bukan sebuah AI ataupun heuristic detection system. CARAKA adalah sistem kontrol akses yang mumpuni. CARAKA berfungsi untuk meningkatkan kontrol terhadap akses sistem dengan cara yang lebih baik melalui autentikasi, approval, notifikasi, dan juga hierarki. Dengan fitur offline OTP, CARAKA dapat melakukan autentikasi dengan tepat tanpa harus terhubung ke jaringan internet.

CARAKA sebagai tools access control tidak langsung berhubungan dengan perlindungan data pribadi. CARAKA memiliki fungsi untuk memastikan akses kontrol terjaga dengan baik, tercatat dengan independen, memiliki proses approval yang berjenjang, memastikan individu atau entitas yang mengakses sistem dalam kontrol yang baik dan tidak ada kemungkinan pembobolan akses yang terjadi di aplikasi masuk ke dalam database. Sehingga CARAKA dapat membantu audit kepatuhan yang transparan untuk akses dan kontrol.

(1) Pembatasan hak akses terhadap data menggunakan ACL dari sistem operasi. Sementara perangkat dalam sistem CARAKA dapat diatur tingkatan notifikasi sesuai keperluan, dari tingkat paling rendah yang dapat melakukan akses secara langsung, hingga tingkat paling tinggi yang memerlukan persetujuan (approval) dari atasan untuk setiap akses. Dengan demikian, jika sebuah perangkat disetel ke tingkat notifikasi paling tinggi (approval), setiap aksi penting hanya dapat dilakukan dengan sepengetahuan atasan.

(2) CARAKA tidak mencatat riwayat pengaksesan data, namun pengaksesan sistem.

(1) CARAKA tidak dirancang untuk mitigasi pasca serangan ransomware. CARAKA dirancang untuk menghindarkan sistem agar tidak terkena ransomware dengan cara mengontrol akses yang lebih mumpuni. Sehingga visibility end-to-end terhadap rantai akses data bukan menjadi domain delivery CARAKA.

(2) CARAKA mendukung MFA adaptif dengan kemampuan membatasi hak akses (melalui ring level) serta tingkatan notifikasi berbeda-beda untuk setiap perangkat yang terdaftar dalam sistem CARAKA. Dengan demikian, setiap perangkat dapat diatur sesuai dengan potensi risiko dari pemiliknya. Contohnya perangkat milik teknisi probation dapat ditempatkan di ring level rendah dan untuk akses memerlukan persetujuan dari atasan langsung.

CARAKA bukanlah antimalware/antivirus ataupun EDR yang secara aktif melakukan identifikasi terhadap potensi threat dari sistem yang berjalan.

(1) CARAKA memiliki fitur subordinate delegation sehingga dapat memberikan akses untuk device baru.

(2) CARAKA tidak mendukung federated identity (SSO) dari provider lain.

(1) Hak akses terhadap data menjadi domain Access Control List (ACL) dari sistem operasi Linux, sehingga bukan domain delivery dari CARAKA.

(2) CARAKA dirancang untuk mengamankan akses terhadap sistem, bukan untuk mencegah kebocoran data secara aktif atau langsung.

(1) CARAKA fokus dalam melindungi akses ke sistem dan setiap percobaan akses akan tercatat. Pengguna yang tidak memiliki ring level yang dibutuhkan atau permintaan akses approval yang ditolak, tidak akan bisa mengakses sistem. Di luar hal tersebut, itu adalah tugas dari endpoint security, bukan domain dari CARAKA.

(2) CARAKA tidak didesain untuk pemberian hak akses sementara secara otomatis. Pemberian hak akses selalu dilakukan dengan sepengetahuan seorang superordinate atau atasan. Saat ini, CARAKA menghindarkan perubahan Hak Akses secara otomatis, karena proses yang otomatis cenderung terlupa oleh atasannya sehingga memiliki potensi resiko.

(1) CARAKA membatasi pada level akses sistem, CARAKA tidak membaca perilaku pengguna dan melakukan penilaian apakah termasuk perilaku mencurigakan (AI dan heuristic system).

(2) CARAKA mengantisipasi serangan ransomware melalui pembatasan akses sejak awal sehingga akses yang tidak diinginkan tidak akan terjadi. Perlu dipahami, serangan ransomware itu tidak terjadi begitu saja, ada prosesnya. Dari awal adalah mendapatkan akses, baik dilakukan dengan scanning port, exploits, social engineering, virus/macro/trojan yang dapat mengirimkan informasi credential dan masih banyak lainnya. CARAKA mengamankan proses awal ini, ketika akses terjadi, CARAKA memastikan tidak dimanipulasi tanpa persetujuan. Proses berikutnya seperti monitoring dan deteksi, saat ini di luar domain delivery CARAKA.

CARAKA tidak menggunakan AI ataupun metode heuristic dalam membatasi hak akses sistem.

(1) Keamanan endpoint bukan menjadi domain delivery CARAKA. CARAKA hanya bertugas untuk mencegah akses yang tidak sesuai, serta untuk memungkinkan pengauditan terhadap akses. Dalam hal BYOD, selama tidak ada manipulasi informasi konfidensial pada device user (Device User hanya dipakai sebagai interface saja) maka tidak perlu dilakukan instalasi PAM CARAKA karena tidak termasuk resource yang perlu diamankan aksesnya. Sebaliknya ketika device tersebut mengakses resource perusahaan maka akan mendapatkan challenge dari CARAKA untuk kebutuhan 2FA nya sehingga penumpang gelap dari device tersebut tidak dapat dengan mudah masuk karena harus melewati 2FA tersebut. Kecuali device user adalah bagian dari tempat manipulasi informasi sensitif kantor, maka harus juga ter-install CARAKA.

(2) CARAKA bukanlah sebagai pendeteksi ancaman dalam sebuah sistem. CARAKA berfungsi untuk memitigasi serangan dengan meningkatkan kontrol akses dengan lebih baik dan tercatat secara mandiri.

(1) Pengaturan hak akses dalam sistem CARAKA didesain sangat sederhana sehingga mengurangi peluang adanya miskonfigurasi. Penerapan kontrol akses pada setiap resource adalah sama pada setiap teknologi cloud, menggunakan implementasi PAM pada proses login OS Linux. Tidak ada potensi yang dapat dimanipulasi oleh malware dalam mekanisme ini, kecuali kesalahan desain mekanisme delegasi, yang berarti adalah permasalahan tata laksana, bukan dari teknologi itu sendiri.

(2) Pembatasan hak akses data bukan merupakan domain CARAKA saat ini, melainkan ACL dari sistem operasi. Menarik ide yang disampaikan, kami akan assess apakah hal tersebut layak untuk diimplementasikan pada versi dimasa mendatang.

(1) Data QR yang ditransmisikan berbentuk ciphertext yang hanya bisa divalidasi oleh sistem CARAKA. Proses komunikasi antara device dan server pun dilindungi oleh SSL/TLS. Pada kondisi ini tidak ada potensi terjadi adanya eavesdropping dari MITM.

(2) CARAKA melakukan validasi perangkat dan institusi yang terhubung sehingga tidak bisa dipalsukan. Di dalam perangkat Android (saat ini baru hanya Android yang kami rilis) terdapat Vault yang kami pergunakan sebagai end-security. Reverse Engineering yang dilakukan tidak dapat melakukan tampering terhadap Vault tersebut. Bilamana Anda memiliki informasi mengenai bukti adanya tampering pada Vault tersebut, dengan senang hati kami akan mengevaluasinya.

(1) CARAKA menggunakan format data tertentu yang tidak dapat dipalsukan, sebab sistem CARAKA sendirilah yang akan memeriksanya. Di dalam format tersebut terdapat check dan validasi lainnya sehingga hampir tidak dapat dilakukan phishing pada QR Code tersebut, justru kami menantang siapa pun untuk membuktikan sebaliknya.

(2) CARAKA memiliki rate limiting dan akan mengunci sementara jika terjadi kegagalan autentikasi tiga kali berturut-turut.

Jika diperhatikan di demo, QR Code nya memiliki banyak bit, karena kita memakai 64 bit. Digitnya panjang dan kemungkinannya akan sangat banyak, variasi sangat besar, dan tidak pernah ada angka yang sama. Kita sudah lakukan calculation dan melakukan perhitungan-nya sendiri. Potensi collision itu sangat kecil dan sangat aman. Makin panjang jangka waktu yang diberikan untuk autentikasi, makin rentan pula terhadap aksi-aksi yang tidak bertanggung jawab. Pada intinya, semua hal sudah dipertimbangkan dengan baik, dari jangka waktu untuk membuka akses respon, ukuran bit dari challenge respon, sudah dipertimbangkan dengan sangat matang, dengan populasi komputer server sekian milyar di dunia ini.

CARAKA baru di-develop di Linux OS karena saat ini mostly server production mission critical running pada OS Linux. Jadi, belum bisa berinteraksi dengan active directory Microsoft, tetapi masih bisa dikombinasikan. Jika active directory sebagai SSO, kemudian perangkat yang diautentikasikan menggunakan Linux, maka CARAKA-nya baru dapat aktif.

Security comes with inflexibility. Itu memang merupakan sebuah konsekuensi logis. Jika ingin meningkatkan security, maka harus ada mekanisme atau prosedur tertentu yang dapat menimbulkan ketidaknyamanan. Namun, terkait CARAKA ini, hanya timbul sedikit ketidaknyamanan karena proses autentikasinya cepat sekali, kurang dari setengah detik. Plus, dengan offline (pada resources) maka resource dapat tetap di-autentifikasi tanpa adanya koneksi ke Internet, hal ini tentu memberikan sedikit fleksibilitas.

Untuk fitur yang kami launch saat ini, belum terdapat fitur detection terhadap log, tetapi ini merupakan ide bagus untuk pengembangan produk ke depannya. Di CARAKA terdapat log external yang nanti bisa digunakan untuk fungsi tersebut. Namun, untuk saat ini, kami rasa intervensi manusia dalam menjaga keamanan pada lingkungan mission critical masih lebih baik dibandingkan dengan AI. Kecuali, jika nanti AI sudah lebih mature, maka kita dapat mengaktifkan AI untuk deteksi anomali akses tersebut.

Kita bisa menegakkan SOP dengan lebih baik, karena setiap level bisa menggunakan CARAKA untuk mengakses ke dalam resources penting terutama resources IT. Bisa saja nanti kita kembangkan, CARAKA tidak hanya untuk mengakses server, tapi juga pintu atau pagar yang bisa dibuka pakai CARAKA nantinya. Bisa juga untuk mengakses resources lainnya seperti printer server yang di kantor atau dokumen-dokumen di storage dan lain sebagainya. Tapi yang kali ini kita sudah miliki adalah untuk mengontrol akses terhadap server atau resources IT yang menggunakan OS Linux agar bisa diatur atau di notifikasi aksesnya, atau mendapatkan approval ketika akses dilakukan. Itu sangat align dengan penegakkan SOP, jika di sebuah perusahaan memiliki SOP yang sudah baku untuk masalah pengaksesan sistem. Maka dengan kita memakai CARAKA, SOP itu bisa dilaksanakan dengan lebih baik tanpa ada perlu check and recheck lagi karena sudah dilakukan di dalam teknologi.

Dalam satu server CARAKA yang disediakan untuk umum, diharapkan nantinya akan memiliki ribuan bahkan ratusan ribu akun Institusi, yang menjadi domain penggunaan secara komersial. Jika ada organisasi yang memiliki banyak cabangnya maka sebaiknya setiap cabang adalah institusi.