Open Source

Untuk seluruh software yang bersifat Open Source tidak akan tenggelam oleh waktu dikarenakan banyak yang mendukung program tersebut dan software tersebut tidak kalah bersaing dengan software berbayar lainnya.

Certified

Mengambil sertifikasi semata-mata bukan untuk menjadi tenar atau sombong, tapi untuk mengetahui apakah anda mampu mengemban tanggung jawab secara moral terhadap apa yang anda telah pelajari dan bagaimana memberikan ilmu tersebut kepada orang lain tanpa pamrih.

Operating System Pentest

Sistem operasi Bactrack, Kali Linux, dll memang sangat memanjakan para Pentester dalam melaksanakan tugasnya sesuai dengan prosedur yang berlaku. Di OS tersebut disediakan beberapa tools menarik seperti untuk memperoleh information gathering, vulnerability assesment, exploit, dll.

Sherlock Holmes

Film detektif yang satu ini pasti disukai oleh beberapa rekan IT dikarenakan proses jalan ceritanya ketika memecahkan sebuah kasus tidak monoton dan memerlukan logika berpikir yang diluar kebiasaan. Daya hayal harus tinggi ketika ingin menonton film ini.

Forensic

Kegiatan forensic bidang IT sangat membutuhkan tingkat pemahaman yang tinggi akan suatu kasus yang ditangani. Tim yang menangani forensic harus bisa membaca jalan pikiran si Attacker seperti apa jika melakukan serangan. Biasanya Attacker lebih maju selangkah dibanding dengan tim pemburunya.

Jumat, 16 Agustus 2024

Apa yang harus dilakukan negara ketika datanya sudah bocor dimana-mana?

Mungkin bagi semua orang data negara yang bocor belakangan ini membuat panik sebagian orang, tapi kita harus menyikapi dengan santai. Saya pribadi sangat santai menyikapi karena semua itu sudah terjadi dan siapa yang berani menuntut sebuah negara disitu?

Data apa yang belum bocor? Jangan bingung untuk mencarinya karena nanti sulit ketemu.

Dari pemberitaan yang sudah heboh hampir beberapa tahun, pada intinya tidak ada "root cause" dari insiden keamanan informasi yang dipaparkan ke masyarakat. Lantas buat apa kita pusing dan panik? Pengolah datanya saja seperti kurang belajar dari hal yang pernah terjadi di tempat lain dan akhirnya terjadi lagi.

Solusinya harus seperti apa jika semua sudah terjadi? Coba masyarakat mulai peduli terhadap datanya sendiri baik dari sisi logic maupun physical.

Memang sebagian masyarakat menilai kurang seriusnya melakukan pengamanan dan hanya sebatas ceremony dan gagahan jika sudah dicap dapat ini itu.

Ide gila saya adalah merubah semua data (sampai metadata) itu meskipun akan memakan waktu panjang dan migrasi model data dari yang sudah bocor menjadi sebuah data baru. Jika sulit, anggap saja data yang telah bocor menjadi sebuah data/informasi publik dan bukan rahasia. Jangan terlalu dipaksakan membuat data yang bocor tetap menjadi sebuah rahasia karena itu percuma menurut sudut pandang saya pribadi.

Lantas negara itu harus melakukan apa? Rombak sumber daya (people, products, dan partners) serta proses semua harus dibenahi. Siapkan rumah yang mumpuni yang dimana nanti ada pengelolaan data dan informasi di dalam rumah tersebut. Buat bentuk desain, tata kelola dan standar untuk masuk ke rumah tersebut akan seperti apa. Ingat tidak bisa langsung loncat langsung mengamankan isi data di rumahnya.

Ingat harus ada pondasi desain, tata kelola dan standar terkait keamanan informasi (mencakup siber dan privasi). Coba perhatikan negara berkembang bagaimana mereka menerbitkan semua itu dan pahami pola rilis masing-masing dokumen tersebut.

Terkadang pola pikir Threat Actor lebih maju karena mereka harus "out of the box thinking" sedangkan pengelola data hanya berpikir sesuai proses bisnis dan terlalu keseringan menggunakan konsep yang ada di User Acceptance Test (UAT).

Kemudian langkah apalagi yang harus dilakukan? Ada rahasia yang harus dibuka biar Threat Actor baca, yaitu seperti konsep memberikan tanda pada uang atau emas. Tanda itu bisa digunakan untuk sistem yang ada di negara tersebut. Bahkan menggunakan konsep Blockchain sepertinya menarik untuk pengelolaan data. Jangan cuman dibuat National Data Centers, tapi coba terapkan semacam Blockchain Hybrid atau Blockchain Konsorsium. Metode itu bisa dikombinasikan dengan "Zero Trust for Next Generation". Bisa saja bekerjasama dengan Multi Region dan dampaknya adalah tingkatan data tidak lagi bisa dianggap rahasia dan tinggal menyepakati dengan negara lain akan seperti apa.

Ide gila "Blockchain for Multi Region + Zero Trust for Next Generation" semoga bisa terjadi disuatu saat untuk negara itu.

Jumat, 03 November 2023

Catatan Kecil untuk Debian Kecil

Catatan kecil aplikasi khusus yang ada di Debian dalam pekerjaan pengujian walaupun bisa saja setiap orang berbeda-beda. Berikut ini agar mudah diingat dan bisa dikembangkan kembali sesuai kebutuhan masing-masing:


$ sudo apt update 
$ sudo apt install snapd
$ sudo snap install core 
$ sudo snap install nmap 
sudo snap install sqlmap 
$ sudo snap install metasploit-framework 
$ sudo snap install crackmapexec 
$ sudo apt install python3
$ sudo snap install john-the-ripper
$ sudo apt-get -y install dirb
$ sudo snap install dnslookup
$ sudo apt install dnsenum 
$ sudo apt install dnsrecon  
$ sudo snap install sliver
$ sudo apt-get -y install fierce 
$ git clone https://github.com/m4ll0k/Atlas.git 
$ sudo apt-get -y install humanfriendly 
$ sudo snap install amass

Kamis, 16 Februari 2023

Sedikit Membahas ISO/IEC 27001:2022 dan 27002:2022


Akhirnya ada keinginan untuk menulis kembali walau sebenarnya sedikit malas gerak. Jadi sebenarnya tulisan ini akan sedikit membahas tentang ISO/IEC 27001 dan 27002 versi 2022, walaupun saat ini sudah 2023 dan sedikit terlambat. Tidak ada salahnya tetap membahas secara umum karena melihat perkembangan di dunia Cybersecurity khususnya bidang ISO banyak beberapa yang masih melihat bahwa itu hanya sekedar Sistem Manajemen belaka saja.

Sebenarnya dari versi terdahulu saya juga kurang menyukai jika ada segelintir pihak yang memandang Standar tersebut hanya memfokuskan ke aspek Manajemen. Ini pemikiran keliru bahwa mungkin ada beberapa Auditor Badan Sertifikasi serta teman-teman lainnya yang dahulu melihat "Kriptografi" ya sebatas itu dan melihat dari sisi aliran data yang harus di kripto atau enkrip. Memang hal itu tidak salah, tapi menurut saya pribadi masih ada yang kurang.

Dari situlah saya sempat berdiskusi dengan beberapa teman bahwa kenapa penerapan Kriptografi itu diperluas. Misalkan pada data Password yang disimpan di database, itu juga perlu dilihat penerapannya seperti apa. Jika hanya sebatas "Hash", maka sangat tidak dianjurkan dan lebih direkomendasikan menggunakan model Kriptografi secara baik atau memakai Enkripsi.

Kemudian ada juga terkait file di aplikasi seperti "Config, Configuration dan sejenisnya" yang mana biasanya file tersebut menghubungkan antara aplikasi ke database engine. Banyak yang kurang peduli terhadap hal tersebut, padahal ada risiko yang melekat jika server aplikasi telah diambil alih oleh Attacker dan Attacker dapat membaca informasi yang ada di file tersebut untuk loncat ke server database. Apalagi celakanya banyak database yang jalan dengan tingkatan "root, sa, administrator" atau high privilege. Andaikata informasi yang ada di file tersebut, seperti username dan password tidak bersifat plaintext atau menerapkan Kriptografi, maka saya pikir akan sedikit menurunkan risiko atau membuat Attacker bekerja lebih maksimal lagi untuk mengambil alih server database, walau banyak proses yang harus dilakukan penjagaan secara baik.

Memang jadinya jika diperketat, beberapa pihak akan merasa dibebankan dan menjadi tidak nyaman. Ini yang saya dan teman-teman selalu memberikan edukasi kepada semua pihak, jika berbicara Cybersecurity dan sejenisnya, jangan mempunyai tingkat toleransi yang rendah. Mungkin banyak "Oknum" yang hanya sekedar ingin mendapatkan Sertifikasi dan jika berpikir seperti itu, maka saya dapat katakan sama saja menjadi orang bodoh yang mana sebenarnya sudah ada arahan secara jelas dari Standar ISO dan kurang membedah lebih dalam. (Maaf jika menggunakan kata bodoh).

Jadi ketika ruang lingkupnya adalah sebuah layanan yang didukung oleh sebuah sistem, mau tidak mau harus dipaksa menerapkan seperti Firewall (internal & eksternal), Web Application Firewall (jika aplikasi berbasiskan web), Privilege Access Management, Endpoint Detection and Response (EDR) atau AntiVirus yang sedikit pintar bahkan jika ingin menonaktifkan harus menggunakan credentials, menerapkan segmentasi yang berbeda antara workstation dengan server, pembatasan Teleworking (SSH, Remote Desktop, dll), bahkan port yang dibuka harus dibatasi dan tidak ditoleransi port seperti Telnet, FTP, http dan sejenisnya bersifat aktif atau open.

Ada beberapa hal yang patut diperhitungkan lainnya seperti File Sharing dan ini sering kali menjadi ajang penyebaran Ransomware, Malware dan sejenisnya. Jika tidak mau terdampak dari insiden Cybersecurity maka setidaknya fitur tersebut tidak digunakan. Jika mau dipaksa digunakan, pertimbangkan dari sisi risiko yang mungkin terjadi di kemudian harinya.

Tulisan di atas masih pembuka dan intinya saya mencoba mengatakan bahwa dari versi sebelumnya juga sudah membahas detil terkait "Teknologi", tapi dari beberapa pihak untuk menangkap hal tersebut yang masih lemah. Pada akhirnya sekarang terbukti di versi 2022 terdapat kategori khusus "Teknologi" walau dibeberapa kalimat menurut saya masih kurang tegas dan masih ada beberapa Annex yang saya masih kurang sreg masuk ke dalam sebuah kategori Teknologi. Sebagai contoh Threat Intelligence yang masuk ke kategori kontrol "Organizational", walau saya berpikir lebih cocok masuk ke "Teknologi" karena sangat sulit melakukan hal itu tanpa bantuan Teknologi. Memang ini bahasa yang halus dari ISO bahwa bisa jadi "Organziational" itu mirip maknanya dengan "Process". Jadi disiapkan mekanismenya melalui sebuah proses dan tidak memaksa ke arah Teknologi. Jika seperti itu, saya sangat merasa tidak akan efektif penerapan dari Threat Intelligence. Bisa saja saya membantah bahwa seperti "Annex 8.3 Information Access Restriction" jangan masuk ke kategori Teknologi tapi ke Organziational. Akan tetapi kita ikuti saja versi yang sudah terbit ini dan saya mulai menangkap pola pikir para perumus ISO tersebut.

Saya disini tidak akan membahas perubahan Clause, karena bagi saya arahnya sudah ketebak. Jika pembaca melihat ISO/IEC 20000-1:2018 dan ISO 22301:2019, akan terlihat pola dan strukturnya yang sekarang mulai menyeragamkan. Tujuan utama selain menyeragamkan adalah untuk memudahkan ketika ingin melakukan integrasi dengan standar ISO lainnya. Di ISO/IEC 27001 versi 2022 juga akan ada sudut pandang yang sedikit berubah terkait pengelolaan risiko (risk management), walaupun di awal saya katakan tidak tertulis secara jelas. Hal apa itu? Jadi sekarang diusahakan ketika identifikasi risiko, tidak perlu lagi menuliskan risiko positif ke dalam daftar risiko (risk register). Ketika berbicara Cybersecurity, cobalah memfokuskan ke Risiko yang negatif dan jangan membuang tenaga untuk mendaftarkan risiko positif. Saat ini dari tiket insiden Cybersecurity juga bisa naik level menjadi sebuah risiko, tapi perlu dikaji lebih dalam lagi. Ini yang saya senang sebenarnya dan apalagi dari hasil Vulnerability Assessment (VA), Penetration Test (Pentest), itu bisa diintegrasikan ke dalam proses pengelolaan risiko (Risk Management). Mungkin dari dahulu ketika saya berbicara bahwa hasil VA atau Pentest bisa masuk ke Risk Register, beberapa pihak bingung atau berkata dalam hati "ah masa begitu". Sekarang alhamdulillah terbukti bahwa itu hal yang benar. Jadi temuan dari VA atau Pentest itu tidak bisa langsung dikatakan sebuah Risiko tapi perlu dikaji lagi dan saya lebih senang bahwa temuan tersebut hanya baru terlihat dari sisi "dampak (impact)", dan jika tidak percaya coba bedah CVSS. Mereka hanya melihat ke Confidentiality, Integrity dan Availability yang notabennya adalah sebuah Impact. Oh ya apalagi jika hasil temuan masih menggunakan Likelihood X Impact, ini juga masih menjadi ambigu bagi saya pribadi. Namun saya membebaskan pihak lain dalam menerapkan sebuah ilmu itu seperti apa dan wajar jika mempunyai beberapa pemikiran yang berbeda. Saya sangat senang jika alurnya seperti ini: "Vulnerability --> Threat --> Risk".

Wah sudah terlalu panjang basa basinya dan coba kita lihat Annex 8.28 Secure coding:

Control:
Secure coding principles should be applied to software development.


Purpose:
To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software.

Other information:

...

Some web applications are susceptible to a variety of vulnerabilities that are introduced by poor design and coding, such as database injection and cross-site scripting attacks. In these attacks, requests can be manipulated to abuse the webserver functionality.

Dari contoh di atas, Annex tersebut masuk ke kategori Teknologi walaupun sebenarnya bisa saja untuk memitigasi tidak memerlukan sebuah Teknologi. Bisa di awali dengan secure coding yang baik, tapi disini saya sudah senang bahwa ISO sekarang lebih melek dan mau terbuka ke standar di luar ISO lainnya (bisa dilihat di bab "Bibliography"). Mungkin bahasa Teknologi dimaksud tidak melekat kesebuah Produk tertentu walau masih bingung saya.

Duh ternyata kejauhan langsung loncat, mungkin karena terlalu semangat. Coba kita balik lagi ke awal ISO/IEC 27002:2022:

Information security, cybersecurity and privacy protection — Information security controls

1 Scope:
This document provides a reference set of generic information security controls including implementation guidance.

^Jadi sekarang menyebutnya "this document" bukan seperti yg lalu "this internasional standard". Kemudian dokumen ini ada kontrol keamanan informasi secara generik termasuk petunjuk implementasi walau sifatnya umum. Ini memang saya acungkan jempol terkait penggunaan tata bahasa yang sangat berhati-hati. Kemudian adalagi seperti:

b) for implementing information security controls based on internationally recognized best practices.

^Jadi ketika menerapkan kontrol keamanan informasi yang ada di Annex, itu bisa berdasarkan best practice di luar sana secara internasional. ISO tidak memberikan best practice -nya seperti apa. Duh bisa banget bahasa mereka yang tidak mau menjadi boomerang di kemudian hari.

Sebenarnya masih banyak yang bisa diulas, namun saya malas menuangkan semuanya. Lebih asik kita kopdar dan membahas secara santai.


Mohon maaf jika ada kesalahan dalam penulisan di atas.

Minggu, 26 Juni 2022

Cara install Kali Linux di M1

Pada postingan ini akan membahas bagaimana kita install Kali Linux di M1 dengan menggunakan aplikasi UTM (dapat diunduh di https://github.com/utmapp/UTM/releases/latest/download/UTM.dmg). Aplikasi UTM ini sebagai alternatif yang tidak perlu mengeluarkan uang ^_^

Di aplikasi tersebut juga jika melihat menu gallery maka terdapat beberapa contoh sistem operasi yang dapat digunakan. Berikut ini contohnya:


Kemudian jika aplikasi UTM telah diinstal di M1 anda, maka langkah selanjutnya adalah membaca keterangan isu di url https://github.com/utmapp/UTM/issues/2607. Dari situ ada yang menjelaskan solusinya, yaitu dengan cara mengunduh file QEMU Efi (https://github.com/utmapp/UTM/files/6668347/QEMU.EFI.for.AARCH64.zip). Berikut ini kutipan dari link tersebut:

EFI_Code-AARCH64.img contains the same UEFI BIOS that is included with UTM, but in an uncompressed image. This is required for the EFI size to match what QEMU expects. EFI_VARS.img is the same size (64k x 1024) and contains zeroes (nothing).


Langkah berikutnya, pastikan anda telah download file untuk installer Kali Linux tersebut (bebas mau installer atau yang langsung live). Kemudian ekstrak file QEMU.EFI.for.AARCH64.zip dan nanti import kedua file tersebut dan jadikan interface: PC System Flash. Berikut ini langkah cepat yang sudah di screenshot walau tidak semua ditampilkan pada saat install kali linux nya:









 
Harap pilih yang "Install" untuk gambar di atas.

Sesuaikan dengan keinginan anda. Jika saya seperti biasa ada ext4 dan swap, kemudian lanjutkan seperti biasa.


Oh ya untuk Architecture saya menggunakan ARM64 dan QEMU 7.0 ARM Virtual Machine. Sekian tulisan yang tidak berbobot ini dan sangat tergesa-gesa karena memang tidak niat untuk menulis ^_^

 

Sumber:

https://github.com/utmapp/UTM/issues/2607

http://mirror.labkom.id/kali-images/current/

https://cdimage.kali.org/kali-images/kali-weekly/

 

Kamis, 10 Maret 2022

Iseng Menulis Pengertian DRP BCP #Bagian 1 (Pancingan)

Kutipan dari NIST 800-34r1:

Disaster Recovery Plan (DRP): A written plan for recovering one or more information systems at an alternate facility in response to a major hardware or software failure or destruction of facilities. 

Kutipan dari ISO 22301:

Business Continuity Plan: documented information that guides an organization to respond to a disruption  and resume, recover and restore the delivery of products and services consistent with its business continuity objectives.

^ Sebenarnya perbedaan signifikan keduanya, yaitu DRP memfokuskan dari sisi Disaster dan yang BCP fokus ke arah Business. (Jangan dilempar bata)

Sebenarnya keduanya memiliki persamaan, yaitu ingin menjaga sebuah produk atau layanan agar ketika terjadi hal yang tidak diinginkan masih dapat diakses walau mungkin dengan keterbatasan.

Tulisan ini hanya iseng saja memancing beberapa orang sering membuat sama antara DRP, BCP bahkan BCM. Padahal semuanya memiliki perbedaan jika digali lebih mendalam. Namun ujungnya semua itu terkadang diserahkan kepada teman-teman yang dibidang Teknologi Informasi harus dapat membuat semua perencanaan itu. Pertanyaan berikutnya, apa cuman terbatas dari sisi perencanaan (Plan)?

Yah ga salah ketika teman-teman cuman membuat perencanaan tanpa ada eksekusi, kan jelas namanya cuman DR Plan atau BC Plan!!!

Bahkan banyak juga dilapangan eh di sektor industri/usaha yang masih sulit membedakan antara insiden atau disaster. Ini yang bisa repot dan terlalu fatal jika belum bisa mendefinisikan hal tersebut, karena nanti ketika misal ada insiden satu server terkena malware, mari kita aktifkan perencanaan DR kita dan akhirnya banyak mengeluarkan energi.


Sekian pancingan singkat ini dan semoga tambah membantu kita semua menjadi lebih bingung ^_^

Rabu, 18 Agustus 2021

Catatan Kecil Ketika Membeli VPS Debian

Ini hanya catatan kecil supaya saya tidak lupa ketika baru membeli VPS dengan Sistem Operasi Debian, yaitu harus melakukan sebagai berikut:

1. Melakukan pembaruan terhadap "sources.list" dengan cara:

# sudo nano /etc/apt/sources.list

Lanjut ganti dengan: 

deb http://deb.debian.org/debian buster main contrib non-free 

deb-src http://deb.debian.org/debian buster main contrib non-free 

deb http://security.debian.org/debian-security buster/updates main contrib 

deb-src http://security.debian.org/debian-security buster/updates main contrib 

Kemudian Simpan dengan writeout (CTRL+O) dan keluar (CTRL+X).

2. Lanjut dengan "sudo apt-get update" dan "sudo apt-get upgrade".

3. Biar lebih mudah clone di github, lakukan ini "sudo apt install git".

4. Buat iseng scan direktori web, ada alternatif ini "sudo apt-get install dirb".

5. Kemudian iseng lagi jika mau "sudo apt install dmitry", "sudo apt install gobuster", "sudo apt install nikto"

6. Tarik mang "sudo apt install ruby", paket hemat install semua (lagi ga mau pusing) "sudo apt install build-essential libcurl4-openssl-dev libxml2 libxml2-dev libxslt1-dev ruby-dev  libgmp-dev zlib1g-dev".

7. Install dah "sudo gem install wpscan" dan jalanin deh "./wpscan".


Thanks