[{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/governance/vciso-advisory/","section":"Layanan Keamanan","summary":"","title":"Advisory Virtual CISO (vCISO)"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/compliance/pci-dss-qsa-audit/","section":"Layanan Keamanan","summary":"","title":"Audit QSA PCI DSS 4.0.1 \u0026 Atestasi AOC"},{"content":"Pekerjaan kepatuhan dipimpin langsung oleh QSA aktif dan mantan CISO yang telah lulus pemeriksaan bank sentral dari kedua sisi meja, untuk 100+ lembaga keuangan di 12 yurisdiksi APAC.\nKami memvalidasi apa yang benar-benar diminta card brand dan regulator, dan kami memulai dengan memperkecil cakupan yang dinilai, karena kontrol termurah untuk diaudit adalah kontrol yang berada di luar scope. Pilar ini cocok bagi bisnis pembayaran, fintech dan enterprise teregulasi yang butuh atestasi yang dapat dipertahankan tanpa penundaan asesmen berbulan-bulan. #","date":null,"permalink":"https://puresecurity.com/id/services/compliance/","section":"Layanan Keamanan","summary":"","title":"PCI DSS \u0026 Kepatuhan Regulasi"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/technical/penetration-testing/","section":"Layanan Keamanan","summary":"","title":"Penetration Testing Human-Led"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/compliance/pci-dss-gap-assessment/","section":"Layanan Keamanan","summary":"","title":"Gap Assessment PCI DSS \u0026 Pengurangan Scope"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/technical/linux-hardening/","section":"Layanan Keamanan","summary":"","title":"Hardening Linux \u0026 Infrastruktur"},{"content":"Pekerjaan rekayasa dipimpin engineer yang telah mempertahankan infrastruktur kritikal nasional dan menjalankan SOC 24x7, bukan sekadar mengases sistem orang lain.\nSetiap temuan datang dengan bukti terverifikasi, langkah reproduksi, dan otomatisasi yang dibutuhkan agar perbaikan tetap terjaga. Pilar ini cocok bagi organisasi yang dipimpin engineering: mereka ingin hasil keamanan yang bisa mereka jalankan, uji dan rawat sendiri setelah engagement selesai. #","date":null,"permalink":"https://puresecurity.com/id/services/technical/","section":"Layanan Keamanan","summary":"","title":"Keamanan \u0026 Rekayasa Teknis"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/governance/third-party-risk-management/","section":"Layanan Keamanan","summary":"","title":"Third-Party Risk Management (TPRM)"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/technical/api-application-security-review/","section":"Layanan Keamanan","summary":"","title":"Review Keamanan API \u0026 Aplikasi"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/compliance/regulatory-compliance/","section":"Layanan Keamanan","summary":"","title":"Kepatuhan Regulasi \u0026 Keselarasan Framework"},{"content":"Kepemimpinan keamanan yang membawa akuntabilitas: memiliki roadmap, menghadapi audit dan review klien enterprise, serta mewakili fungsi keamanan di hadapan dewan Anda. Sarannya berasal dari mantan CISO yang pernah melapor ke board, mempertahankan anggaran di depan CFO dan menjawab pemeriksa bank sentral, sehingga bahasanya sesuai ekspektasi stakeholder Anda.\nPilar ini cocok untuk scale-up yang butuh kepemimpinan keamanan kredibel demi memenangkan kontrak enterprise, dan organisasi mapan yang butuh pandangan senior independen tanpa biaya dan siklus rekrutmen eksekutif full-time. #","date":null,"permalink":"https://puresecurity.com/id/services/governance/","section":"Layanan Keamanan","summary":"","title":"Kepemimpinan Strategis \u0026 Tata Kelola"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/governance/cyber-crisis-tabletop-exercises/","section":"Layanan Keamanan","summary":"","title":"Manajemen Krisis Siber \u0026 Tabletop Eksekutif"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/technical/configuration-architecture-assessment/","section":"Layanan Keamanan","summary":"","title":"Penilaian Konfigurasi \u0026 Arsitektur"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/technical/vulnerability-management/","section":"Layanan Keamanan","summary":"","title":"Vulnerability Management \u0026 Compliance Scanning"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/services/technical/dfir-retainer/","section":"Layanan Keamanan","summary":"","title":"DFIR Retainer \u0026 Investigasi Internal"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/categories/","section":"Categories","summary":"","title":"Categories"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/incident-response/","section":"Tags","summary":"","title":"Incident Response"},{"content":"Catatan lapangan dari pekerjaan audit dan rekayasa kami di Thailand dan APAC: keputusan scope PCI DSS, ekspektasi regulator, baseline hardening, dan temuan yang paling sering kami angkat. Setiap artikel menyatakan apa yang kami amati, artinya dalam praktik, dan tindakan yang kami rekomendasikan.\n","date":null,"permalink":"https://puresecurity.com/id/posts/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Insight \u0026 Advisori Keamanan"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/categories/insights/","section":"Categories","summary":"","title":"Insights"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/","section":"Keamanan Menyeluruh, Disampaikan dengan Tanggung Jawab","summary":"","title":"Keamanan Menyeluruh, Disampaikan dengan Tanggung Jawab"},{"content":"Tidak ada organisasi yang merencanakan untuk dibobol. Tetapi yang pulih dengan bersih berbagi satu ciri: mereka menyiapkan bukti sebelum membutuhkannya. Ketika insiden datang (serangan ransomware, eksfiltrasi oleh orang dalam, akun yang dikompromikan), perbedaan antara pemulihan dua minggu dan rawan hukum dua bulan hampir selalu ditentukan oleh keputusan yang dibuat berbulan-bulan sebelumnya, dalam ketenangan.\nKesiapan digital forensics and incident response (DFIR) adalah disiplin mengambil keputusan-keputusan itu lebih awal.\nForensik dimulai sebelum insiden #Aturan pertama forensik: Anda tidak bisa menyelidiki apa yang tidak Anda preservasi. Saat insiden ditemukan, bukti yang Anda harapkan ada (log, memori, tangkapan jaringan, metadata file) sudah hilang jika tidak dikonfigurasikan lebih dulu.\nRFC 3227, panduan fundamental pengumpulan bukti, menyatakannya lugas: forensik adalah disiplin perencanaan, bukan keadaan darurat. Kesiapan praktis berarti:\nLogging terpusat, di luar host: agar penyerang yang mengompromikan server tak bisa sekalian menghapus jejaknya sendiri. Retensi yang sesuai kewajiban: PDPA Thailand dan pedoman Bank of Thailand sama-sama menyiratkan jendela retensi realistis, dan retensi yang kurang itu sendiri adalah temuan. Sinkronisasi jam: agar analisis timeline lintas sistem benar-benar mungkin dilakukan. Chain of custody yang teruji: agar apa pun yang Anda kumpulkan dapat dipertahankan dalam proses hukum atau regulasi, bukan ditolak sebagai dimanipulasi. Tak satu pun dari ini glamor. Semuanya menentukan saat insiden terjadi.\nMengapa tim IT Anda tak sanggup menangani ini di bawah tekanan #Saat insiden sedang berjalan, tim internal Anda mengerjakan tiga pekerjaan sekaligus: menahan kerusakan, menjaga bisnis tetap jalan, dan menjawab pimpinan. Forensik adalah pekerjaan keempat yang butuh pola pikir berbeda: lambat, metodis, dan adversarial, karena temuannya bisa berakhir di hadapan regulator atau pengadilan.\nItulah argumen untuk retainer: hubungan yang disusun lebih dulu dengan tim forensik yang mengenal lingkungan Anda, merespons sesuai SLA yang disepakati, dan mempreservasi bukti pada standar yang dapat dipertahankan sementara staf Anda fokus pada pemulihan. Alternatifnya, menelepon firma forensik secara dingin di tengah krisis, memakan waktu yang justru paling Anda butuhkan.\nKecepatan adalah metrik bisnis #Dua angka paling penting dalam incident response:\nMTTD: mean time to detect. Berapa lama penyerang beroperasi sebelum Anda sadar. Sebagian besar breach dihitung dalam minggu atau bulan, bukan menit. MTTR: mean time to respond and recover. Berapa lama dari penemuan hingga containment dan pemulihan. NIST SP 800-61 membingkai seluruh siklus incident response untuk menekan kedua angka itu. Setiap jam dwell time berarti lebih banyak eksfiltrasi, lateral movement, dan paparan hukum. Detection engineering dan rencana respons yang teruji adalah dua tuas yang benar-benar menggerakkan metrik ini.\nflowchart LR A[Deteksi] --\u003e B[Containment] B --\u003e C[Eradication] C --\u003e D[Recovery] D --\u003e E[Pembelajaran pasca insiden] E --\u003e|mengumpan balik| A style A stroke:#0EA5E9,stroke-width:2px style E stroke:#10B981,stroke-width:2px Realitas regulasi di Thailand #Insiden bukan hanya masalah IT; ia masalah notifikasi. PDPA Thailand mewajibkan pengendali data memberitahu pelanggaran, dan Bank of Thailand mengharapkan lembaga keuangan melapor dalam tenggat tertentu untuk insiden siber material. Salah menyampaikan fakta dalam notifikasi tersebut, atau tidak mampu mendukung versi Anda dengan bukti, mengubah satu kegagalan keamanan menjadi kegagalan kepatuhan.\nKesiapan forensik itulah yang memungkinkan Anda membuat notifikasi yang akurat, tepat waktu, dan dapat dipertahankan, alih-alih tebakan panik.\nApakah Anda tahu harus mulai dari mana bila insiden terjadi sore ini? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). DFIR Retainer \u0026amp; Investigasi Internal kami menyiagakan tim respons dengan SLA terjamin dan penanganan bukti yang admissible di pengadilan, dan Cyber Crisis Tabletop Exercises kami menguji ketahanan rencana sebelum Anda membutuhkannya.\n","date":"11 Agustus 2026","permalink":"https://puresecurity.com/id/posts/dfir-readiness-incident-response-thailand/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Kesiapan Digital Forensics \u0026 IR di Thailand"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/","section":"Tags","summary":"","title":"Tags"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/thailand/","section":"Tags","summary":"","title":"Thailand"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/apac/","section":"Tags","summary":"","title":"APAC"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/governance--leadership/","section":"Tags","summary":"","title":"Governance \u0026 Leadership"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/third-party-risk/","section":"Tags","summary":"","title":"Third-Party Risk"},{"content":"Organisasi modern bukan satu perusahaan tunggal; ia adalah jaringan vendor, platform SaaS, penyedia cloud, dan integrator, masing-masing memegang seutas benang data dan reputasi Anda. Ketika salah satunya gagal, Anda mewarisi kegagalan itu: regulator bertanya kepada Anda mengapa vendor itu tidak divet, dan pelanggan bertanya kepada Anda mengapa data mereka bocor lewat pemasok yang Anda pilih.\nThird-party risk management (TPRM) adalah disiplin membuat jaringan itu terbaca: tahu siapa punya akses ke apa, seberapa besar ketergantungan Anda pada mereka, dan apakah kontrol mereka benar-benar bertahan.\nJebakan kuesioner #Sebagian besar program TPRM adalah spreadsheet 200-500 pertanyaan yang dikirim ke setiap vendor, lalu diarsipkan dan dilupakan tiap tahun. Ini menghasilkan pekerjaan kertas tetapi sangat sedikit reduksi risiko, karena dua alasan:\nIa memperlakukan semua vendor sama. Pemasok kopi dan payment processor menerima kuesioner yang sama, meski eksposurnya jauh berbeda. Ia percaya pernyataan sendiri. Vendor yang berkata \u0026ldquo;ya, kami mengenkripsi data\u0026rdquo; tidak sama dengan yang bisa menunjukkannya. Kuesioner mengukur keyakinan, bukan kontrol. Solusinya adalah proporsionalitas dan verifikasi. Kategorikan vendor berdasarkan akses yang benar-benar mereka miliki, lalu habiskan upaya deep-dive di tempat eksposur nyata berada.\nTiering berdasarkan eksposur aktual #Model yang bisa dipakai men-tier vendor berdasarkan apa yang mereka sentuh:\nTier 1, kritikal: menyimpan data pemegang kartu atau pribadi, terintegrasi dalam dengan sistem Anda, atau menjadi single point of failure. Mereka mendapat asesmen teknis, hak audit, dan security schedule kontraktual. Tier 2, signifikan: memproses data bisnis atau punya akses istimewa. Mereka mendapat review teknis lebih ringan dan revalidasi berkala. Tier 3, transaksional: akses data terbatas atau tidak ada. Mereka mendapat due diligence dasar dan tidak lebih. Poinnya bukan lebih banyak proses; melainkan proses yang proporsional. Payment gateway Tier 1 yang gagal adalah insiden. Vendor alat tulis Tier 3 yang gagal hanyalah ketidaknyamanan. Memperlakukan mereka sama membuang tenaga pada risiko yang salah.\nflowchart TD A[Vendor baru] --\u003e B{Level data dan akses?} B --\u003e|Kritikal| C[Tier 1: review teknis mendalam] B --\u003e|Signifikan| D[Tier 2: review ringan] B --\u003e|Transaksional| E[Tier 3: due diligence dasar] C --\u003e F[Security schedule kontraktual + hak audit] style C stroke:#F43F5E,stroke-width:2px style F stroke:#10B981,stroke-width:2px Melampaui kuesioner: verifikasi teknis #Bagi vendor yang penting, pernyataan sendiri tidak cukup. Verifikasi teknis berarti meminta bukti dan, bila hubungan membenarkan, menguji:\nReview bukti: laporan SOC 2, sertifikat ISO 27001, AOC PCI DSS, dan yang paling kritis: scope laporan-laporan itu, bukan sekadar logonya. Review arsitektur: bagaimana vendor benar-benar menangani data Anda di lingkungannya, bukan bagaimana halaman marketingnya mendeskripsikannya. Gigi kontraktual: security schedule yang dapat ditegakkan, tenggat notifikasi breach, dan hak audit yang selamat dari renegosiasi. Framework-framework sepakat soal ini. NIST SP 800-161 tentang risiko supply chain, dan klausa keamanan pemasok ISO 27001 (A.15 dalam pemetaan edisi 2022), keduanya mendorong vendor assurance yang proporsional dan berbasis bukti daripada kuesioner seragam. Panduan outsourcing Bank of Thailand menerapkan logika sama bagi lembaga keuangan dan vendor kritisnya.\nBerkelanjutan, bukan sekali jalan #Risiko vendor tidak statis. Vendor yang lolos review tahun lalu bisa diakuisisi, dibobol, atau diam-diam mengganti sub-prosesornya tahun ini. Model matang melakukan revalidasi siklus berbasis risiko, memantau sinyal (data breach, perubahan kepemilikan, sertifikat kedaluwarsa), dan punya jalur offboarding yang benar-benar mencabut akses, bukan sekadar membatalkan invoice.\nMerasa tertimbun kuesioner vendor yang tak kunjung mengurangi risiko? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Third-Party Risk Management kami membangun model tiering, menjalankan review mendalam, dan menyusun draf security schedule kontraktual yang dibutuhkan tim legal Anda. Padukan dengan Regulatory Compliance untuk memetakan kewajiban vendor ke persyaratan BOT dan ISO 27001.\n","date":"15 Juli 2026","permalink":"https://puresecurity.com/id/posts/third-party-risk-management-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Third-Party Risk Management untuk Enterprise APAC"},{"content":"Sebagian besar sistem Linux produksi berjalan lebih dekat ke konfigurasi default daripada yang mau diakui siapa pun. Dokumen hardening ada, sering ditulis untuk audit bertahun-tahun lalu, tetapi server tidak sesuai dengannya. Celah antara \u0026ldquo;baseline terdokumentasi\u0026rdquo; dan \u0026ldquo;konfigurasi aktual\u0026rdquo; adalah tempat attacker hidup secara konsisten.\nHardening Linux adalah disiplin menutup celah itu, dan melakukannya dengan cara yang bertahan melewati deployment berikutnya.\nDefault adalah titik awal, bukan postur #Instalasi Linux default mengutamakan kompatibilitas, bukan keamanan. Ia membawa layanan yang tak Anda pakai, fitur kernel yang tak Anda perlukan, dan logging yang cukup untuk desktop tetapi tidak untuk host produksi yang dikompromikan. Hardening adalah proses mengubah mesin serba-guna itu menjadi mesin yang dibangun untuk tujuan tertentu.\nPekerjaan beratnya terbagi beberapa kategori:\nPenyetelan kernel dan sysctl: proteksi jaringan (misal mengabaikan ICMP redirect, mengaktifkan source-route filtering), pembatasan filesystem, dan proteksi memori seperti address space layout randomisation. Minimalisasi layanan: menonaktifkan dan menghapus apa yang tidak dijalankan host, sehingga tak ada yang bisa dieksploit dan memang tak digunakan. Mandatory access control: SELinux atau AppArmor untuk membatasi apa yang boleh dilakukan sebuah proses, bahkan saat ia terkompromikan. Systemd dan container hardening: dropping capabilities, memblokir akses raw socket, dan membatasi syscall dengan profile seccomp. Audit dan logging: menangkap peristiwa yang penting, dikirim keluar host agar penyerang tak bisa menghapus jejaknya sendiri. CIS Benchmarks tetap menjadi kodifikasi paling praktis dan paling luas dikenal atas kontrol-kontrol ini, dan OpenSCAP mengotomatisasi penerapan sekaligus auditnya.\nConfig as code, atau tidak ada #Panduan hardening yang hidup di wiki hanyalah daftar harapan. Hardening yang hidup dalam kode (role Ansible, image Packer, admission policy Kubernetes) adalah fakta. Saat baseline menjadi kode, tiga hal berubah:\nIa reproducible. Setiap host baru mewarisi baseline, bukan hanya yang kebetulan diingat untuk dikonfigurasikan. Ia testable. Compliance scan di CI menggagalkan build saat sebuah setting drift. Ia reviewable. Perubahan baseline adalah pull request, dengan disiplin review yang sama seperti kode aplikasi. Inilah beda antara hardening sebagai acara tahunan dan hardening sebagai properti platform.\nImmutability sebagai tujuan akhir #Kesimpulan logisnya adalah immutable infrastructure: host dan container tidak pernah di-patch di tempat, hanya diganti. Image baru dibangun, discan, dan di-deploy; yang lama dimusnahkan. Configuration drift menjadi mustahil karena tak ada yang bisa drift: sistem yang berjalan adalah artefak build.\nImmutable infrastructure berpaduan alami dengan hardening-as-code. Anda tidak merawat baseline; Anda mengompilasi keamanan ke dalam image. Dan saat kerentanan muncul, solusinya adalah rebuild, bukan sesi SSH tengah malam.\nflowchart LR A[Baseline CIS benchmark sebagai kode] --\u003e B[Bangun image hardened di CI] B --\u003e C[Compliance scan di pipeline] C -- lolos --\u003e D[Deploy dan rotasi instance] C -- gagal --\u003e B style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px Melampaui host #Hardening tidak berhenti di sistem operasi. Disiplin yang sama terbentang ke beberapa arah, masing-masing dengan failure mode-nya sendiri.\nContainer mewarisi segalanya, lalu menambah risikonya sendiri. Image container yang dibangun dari base layer yang belum hardened membawa semua kelemahan level host ke setiap pod yang menjalankannya. Solusinya di hulu: base image minimal, discan di CI, dijalankan sebagai non-root dengan read-only filesystem, capabilities dicabut, dan seccomp profile yang membatasi syscall hanya untuk yang workload benar-benar butuhkan. Profil default seccomp sudah memblokir banyak; profil yang di-tune berdasarkan pola syscall yang terobservasi memblokir sisanya. Kubernetes admission policy menegakkan semuanya lintas fleet, sehingga deployment yang tidak patut bahkan tidak berhasil dijadwalkan.\nLingkungan OT menaikkan taruhan. Di lingkungan industri dan operational technology, hardening bertabrakan dengan availability dengan cara yang IT kantor tidak pernah alami. Satu kontrol CIS yang salah diterapkan pada building management system, jaringan PLC production line, atau segmen perangkat rumah sakit tidak menghasilkan finding: ia menghasilkan downtime, kadang-kadang dengan konsekuensi keselamatan jiwa. Karena itu hardening OT membalik urutannya: monitoring pasif dan inventaris didahulukan, perubahan dilakukan di maintenance window dengan rollback plan, dan kontrol dipilot di mirror produksi sebelum menyentuh apa pun yang nyata. IT bertanya \u0026ldquo;apakah sistem ini aman?\u0026rdquo;; OT harus bertanya \u0026ldquo;bisakah kita melindunginya tanpa menghentikannya?\u0026rdquo;\nDrift detection menutup lingkaran. Baseline merosot lewat perubahan rutin: engineer membuka port untuk debug, installer mengaktifkan kembali sebuah service, hotfix tidak pernah masuk kembali ke kode. Tanpa deteksi, host yang hari ini hardened adalah host lunak tahun depan. Pola yang bekerja: pemindaian konfigurasi harian membandingkan live host dan image dengan baseline berkoding, dan temuan dirutekan sebagai alert langsung ke pemiliknya, bukan disimpan dalam laporan kuartalan yang tak dibaca siapa pun. Drift yang terdeteksi dalam sehari adalah tiket; drift yang terdeteksi setahun kemudian adalah investigasi insiden.\nHost yang hardened di balik IAM role cloud yang terlalu longgar, atau di dalam container pipeline yang tidak discan, tetap terekspos. Postur paling tahan lama memperlakukan baseline host, container build chain, konfigurasi cloud, dan batas identitas sebagai satu permukaan berkesinambungan, dan memantaunya demikian.\nBelum yakin server Anda benar-benar sesuai dokumen hardening? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Linux \u0026amp; Infrastructure Hardening kami menyerahkan baseline sebagai kode dan drift detection otomatis, dan Configuration \u0026amp; Architecture Assessment kami mereview lapisan cloud dan identitas di sekitar host. Untuk gambaran utuh, jadwalkan Engineering \u0026amp; Scoping Session.\n","date":"17 Juni 2026","permalink":"https://puresecurity.com/id/posts/linux-infrastructure-hardening-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Hardening Infrastruktur Linux untuk Sistem APAC"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/security-engineering/","section":"Tags","summary":"","title":"Security Engineering"},{"content":"Selama bertahun-tahun, \u0026ldquo;enkripsi data saat transit\u0026rdquo; berarti satu hal: pasang HTTPS. TLS berakhir di load balancer, payload mengalir melintasi jaringan internal dalam plaintext, dan semua orang menyebutnya terenkripsi. Bank of Thailand secara bertahap menutup celah itu, dan arahnya jelas: untuk data finansial sensitif, enkripsi transport saja tidak lagi cukup.\nPerbedaan enkripsi transport dan enkripsi payload #TLS melindungi data antara dua titik pada kabel. Ia tidak melindungi data di dalam aplikasi. Begitu TLS berakhir di reverse proxy, API gateway, atau load balancer, payload didekripsi dan diserahkan ke backend dalam bentuk teks polos.\nPlaintext itu kemudian melintas, dan menetap, di tempat-tempat yang tidak Anda inginkan:\nLog: gateway yang terlalu rajin mencatat request body merekam PAN penuh dan nomor rekening. Service mesh dan hop internal: trafik east-west antar microservices sering kali tanpa enkripsi dengan asumsi jaringan \u0026ldquo;dipercaya\u0026rdquo;. Memori dan cache: objek request in-memory, debug dump, dan trace APM semuanya bisa menyimpan payload hasil dekripsi. Pipeline observability: metrics dan trace yang meneruskan span lintas tim dan pihak ketiga. Enkripsi payload lapisan aplikasi menutup celah ini dengan mengenkripsi pesan itu sendiri, sehingga tetap terlindungi berapa pun banyaknya hop yang dilalui atau apa yang infrastruktur lakukan terhadapnya.\nflowchart LR A[Klien] --\u003e|TLS| B[API Gateway: TLS berakhir] B --\u003e|plaintext| C[Layanan backend] C --\u003e|plaintext| D[Log / trace / cache] subgraph \"Enkripsi lapisan aplikasi\" E[Payload terenkripsi] -.-\u003e|JWE / AES-GCM| B B -.-\u003e E2[Tetap terenkripsi sepanjang transit] end style D stroke:#F43F5E,stroke-width:2px style E2 stroke:#10B981,stroke-width:2px Apa yang direkomendasikan standar #Mekanika enkripsi payload sudah distandardkan dan dipahami dengan baik:\nJSON Web Encryption (JWE) (RFC 7516): standar de facto untuk mengenkripsi payload API terstruktur, membungkus kunci data simetris dengan kunci penerima asimetris. AES-256-GCM: andalan authenticated encryption untuk badan payload, menyediakan kerahasiaan sekaligus integritas. RSA-OAEP atau ECDH: lapisan key encapsulation yang melindungi kunci simetris saat transit maupun tersimpan. Pola ini sama seperti yang dipakai TLS sendiri: cipher simetris cepat untuk data massal, dibungkus pertukaran kunci asimetris, tetapi diterapkan pada level pesan sehingga bertahan melebihi sesi TLS.\nMengapa BOT mendorong ini sekarang #Penalaran regulatornya tidak eksotis. API finansial kini menjadi jaringan penghubung seluruh ekosistem pembayaran Thailand: bank, PSP, fintech, merchant. Satu kesalahan konfigurasi gateway tidak seharusnya membuka data rekening bagi siapa pun yang punya akses log. Enkripsi payload adalah langkah defense in depth: ia berasumsi transport akan diperiksa, dicatat, atau dikompromikan suatu saat, dan memastikan data sensitif tak terbaca saat itu terjadi.\nIni selaras dengan prinsip yang sama di balik kewajiban PCI DSS melindungi data pemegang kartu tersimpan: begitu Anda berhenti mempercayai hop mana pun, Anda berhenti menjadikan \u0026ldquo;jaringannya aman\u0026rdquo; sebagai satu-satunya kontrol.\nImplikasi praktis bagi tim engineering Anda #Mengadopsi enkripsi payload bukan sekadar mengubah satu konfigurasi. Artinya:\nKey management menjadi perhatian utama. Anda butuh rotasi, pemisahan kunci penandatanganan dan kunci enkripsi, serta penyimpanan kunci yang terlindungi. Perubahan gateway dan logging: semua yang membaca atau mencatat request body harus dievaluasi ulang, karena middleware tak lagi bisa membacanya. Perubahan kontrak: konsumen hilir harus bisa mendekripsi, artinya distribusi dan versioning kunci lintas setiap pihak dalam rantai. Pengujian: observability harus bergeser dari \u0026ldquo;dump payload\u0026rdquo; ke \u0026ldquo;autentikasi dan otorisasi dulu, dekripsi hanya bila perlu.\u0026rdquo; Tak satu pun dari ini bersifat opsional jika Anda beroperasi dalam orbit BOT. Ini pergeseran dari \u0026ldquo;enkripsi pipanya\u0026rdquo; ke \u0026ldquo;lindungi pesannya\u0026rdquo;.\nBelum yakin payload API Anda memenuhi ekspektasi Bank of Thailand? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Layanan Regulatory Compliance kami memetakan panduan BOT menjadi persyaratan engineering konkret, dan API \u0026amp; Application Security Review kami memverifikasi bagaimana payload Anda benar-benar dilindungi secara end to end.\n","date":"13 Mei 2026","permalink":"https://puresecurity.com/id/posts/bot-api-payload-encryption-thailand/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Aturan Enkripsi Payload API Bank of Thailand"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/compliance--regulatory/","section":"Tags","summary":"","title":"Compliance \u0026 Regulatory"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/data-protection/","section":"Tags","summary":"","title":"Data Protection"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/penetration-testing/","section":"Tags","summary":"","title":"Penetration Testing"},{"content":"Setiap organisasi punya incident response plan. Kebanyakan belum pernah diuji. Rencananya tersimpan di sistem manajemen dokumen, ditulis oleh orang yang sudah lama keluar, dan tak pernah selamat dari kontak dengan keputusan nyata di bawah tekanan waktu. Kali pertama rencana itu dilatih adalah kali pertama ia penting, dan justru di situlah rencana yang tak terlatih gagal.\nTabletop exercise memperbaiki ini dengan murah: simulasi krisis siber yang difasilitasi dan digerakkan oleh konsekuensi, dijalankan terhadap orang-orang sungguhan Anda, ambang batas sungguhan Anda, dan regulator sungguhan Anda.\nMengapa rencana gagal pada kontak pertama #Insiden nyata tidak linear. Ia ambigu, berisik, dan penuh pertimbangan yang tak bisa sepenuhnya di-skrip oleh playbook mana pun:\nKapan kita memberi tahu board? Terlalu awal Anda dianggap berbohong; terlalu lambat Anda kehilangan kepercayaan mereka. Kapan kita memberi tahu regulator? Di Thailand, Bank of Thailand dan regulator lain menetapkan tenggat notifikasi breach. Raguragu punya konsekuensi hukum. Siapa yang bicara dengan pelanggan, dengan kata-kata apa? Pernyataan pertama yang salah redaksi menimbulkan kerusakan reputasi lebih besar daripada insiden itu sendiri. Siapa yang berwenang mematikan production? Dalam krisis nyata, orang yang punya wewenang sering bukan orang yang punya informasi. Pertanyaan-pertanyaan ini diputuskan oleh manusia, bukan proses. Tabletop memperlihatkan di mana pengambilan keputusan Anda macet, jauh sebelum attacker melakukannya.\nBagaimana wujud latihan yang baik #Tabletop yang dirancang baik berbasis ancaman dan disesuaikan dengan industri Anda. Bukan skrip generik \u0026ldquo;terjadi breach\u0026rdquo;. Ia mengikuti rantai realistis: misalnya kompromi supply chain yang dimulai dari alert vendor dan meningkat menjadi ransomware di sistem kritikal, dan memaksa tim melewati titik-titik keputusan yang meningkat. Tak semua informasi tersedia di awal, dan tak semua orang terlibat sejak awal. Anda harus bekerja dengan sumber daya yang ada, dan siap beradaptasi, berimprovisasi, dan mengatasi saat informasi baru muncul.\nDi lingkungan enterprise yang perubahannya bisa memakan minggu atau bulan, Anda harus mempertimbangkan dampak dari tidak melakukan apa pun selama insiden. Keputusan atau tindakan yang tertunda bisa menghasilkan akibat lebih buruk daripada permintaan \u0026rsquo;estimated change\u0026rsquo; atau \u0026rsquo;emergency change'.\nNilai sesungguhnya ada pada debrief. Latihan yang dinilai baik memakai ukuran:\nKecepatan keputusan: berapa lama dari deteksi hingga keputusan yang dapat dipertahankan? Kejelasan eskalasi: adakah yang tahu siapa sebenarnya pemilik keputusan? Akurasi regulasi: apakah waktu notifikasi Anda memenuhi kewajiban? Konsistensi komunikasi: apakah pesan internal dan eksternal sepakat? NIST SP 800-84 membingkai hal ini sebagai inti program test, training, and exercise: latihan ada untuk menemukan kesenjangan dan memperbaiki, bukan untuk membuktikan Anda siap.\nPola yang paling sering terlewat tim #Temuan terbesar dalam hampir setiap latihan bukan teknis. Yaitu: tim teknis dan tim eksekutif beroperasi dari model mental yang berbeda atas insiden yang sama. Engineer berpikir soal containment dan root cause; eksekutif berpikir soal disclosure, liability, dan kepercayaan pelanggan. Tak ada yang salah, tetapi jika mereka bertabrakan pertama kali di tengah krisis, hasilnya adalah friksi di momen terburuk.\nTabletop memaksa tabrakan itu di ruangan yang aman, tempat friksi menjadi pelajaran alih-alih liabilitas.\nKapan terakhir incident plan Anda benar-benar dilatih? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Cyber Crisis Tabletop Exercises kami adalah simulasi setengah hari terfasilitasi yang disesuaikan dengan infrastruktur dan eksposur regulasi Anda, lengkap dengan laporan kesiapan yang bisa dibawa ke board. Padukan dengan DFIR Retainer agar ketika latihan menjadi kenyataan, Anda tidak berimprovisasi.\n","date":"15 April 2026","permalink":"https://puresecurity.com/id/posts/cyber-crisis-tabletop-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Tabletop Krisis Siber untuk Perusahaan APAC"},{"content":"Aplikasi sudah lama berhenti menjadi \u0026ldquo;situs web\u0026rdquo;. Mereka sekarang adalah API: microservices memanggil microservices, klien mobile di satu ujung dan jalur pembayaran di ujung lainnya. Percakapan keamanan belum sepenuhnya mengejar. Tim masih membeli \u0026ldquo;penetration test aplikasi web\u0026rdquo; yang menghabiskan 80% upaya di front end, sementara API di belakangnya, tempat uang dan data benar-benar mengalir, kurang diuji.\nMengapa API membuat scanner menyerah #Scanner web otomatis dibangun di atas model halaman: merayapi tautan, menemukan formulir, menyuntik payload. API tidak menampilkan halaman. API menampilkan route, method, dan schema, dan perilaku yang menarik hidup dalam logika bisnis di antara semuanya.\nPertimbangkan cacat akses level objek: pengguna mengubah user_id=1024 menjadi user_id=1025 dalam satu request dan membaca catatan orang lain. Tak ada signature yang berbunyi. Tak ada payload jahat. Scanner melihat request normal lalu lanjut. Inilah Broken Object Level Authorisation (BOLA), entri nomor satu di OWASP API Security Top 10, dan ia tak kasat mata oleh hampir semua tool otomatis.\nItulah argumen inti pengujian API human-led: cacat yang paling merusak adalah cacat desain, dan cacat desain butuh analis yang memahami konteks bisnis untuk menemukannya.\nApa saja yang benar-benar dicakup tes API yang efektif #Asesmen API bermakna jauh melampaui menjalankan scanner terhadap spesifikasi OpenAPI:\nAutentikasi dan otorisasi: penanganan token, pemeriksaan scope, dan akses level objek di setiap batas peran. Logika bisnis: bisakah pengguna memberi harga negatif pada pesanan, memutar ulang callback pembayaran, atau melewati langkah workflow dengan memanggil endpoint berikutnya langsung? Paparan data: endpoint mana yang mengembalikan field berlebih, dan mana yang menerima field yang seharusnya tak pernah dikirim klien. Rate limiting dan abuse: enumerasi, credential stuffing, dan jalur account takeover yang menyalahgunakan throttling lemah. Batas integrasi: webhook, callback pihak ketiga, dan message queue, tempat kepercayaan sering diasumsikan dan tak pernah diverifikasi. Karena itulah engagement terbaik memadukan tradecraft ofensif manual dengan recon dan fuzzing berbantuan AI: otomatisasi memperluas cakupan, manusia menilai severity dan konteks.\nBerkelanjutan, bukan tahunan #Tes API sekali setahun adalah snapshot titik-waktu atas sistem yang deploy mingguan. Saat laporan selesai ditulis, endpoint sudah berubah. Pendekatan modern memasukkan pemeriksaan keamanan API ke dalam delivery pipeline:\nShift-left dengan static analysis dan validasi schema di CI. Uji per rilisan: review terfokus saat permukaan API berubah. Deep-dive tahunan: asesmen penuh human-led untuk jejak audit dan logika bisnis yang tak bisa dinilai pipeline. PCI DSS Requirement 6 dan Requirement 11.4 sama-sama mendorong arah ini bagi organisasi yang menyentuh data kartu, demikian pula pedoman keamanan kanal digital Bank of Thailand.\nflowchart LR A[Schema dan SAST di CI] --\u003e B[Review API per rilis] B --\u003e C[Asesmen mendalam yang dipimpin manusia] C --\u003e D[Remediasi dan uji ulang] D --\u003e A style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px Apa yang automated scanner tak bisa lihat #Penting untuk spesifik soal apa saja yang dilewatkan otomasi, karena celahnya tidak acak: mereka berkumpul tepat di tempat uang mengalir.\nBOLA dalam praktik. Scanner menguji endpoint yang ditemukan dan parameter yang ia pahami. Ambil sebuah invoice API: GET /invoices/8842 mengembalikan invoice milik si pemanggil sendiri, scanner mencatat lulus. Tetapi GET /invoices/8843, invoice pelanggan lain, mungkin sama senangnya dikembalikan, dan tak ada scanner yang akan mencobanya, karena paham bahwa 8843 milik orang lain butuh tahu apa artinya kepemilikan dalam bisnis Anda. Setiap object identifier yang melintasi batas tenant adalah potensi BOLA, dan hanya analyst yang mengenumerasi objek lintas account yang akan menemukannya.\nCelah logika bisnis. Scanner menguji apakah request berhasil atau gagal; celah logika hidup di request yang berhasil padahal seharusnya tidak. Contoh nyata dari engagement: kode kupon bisa dipakai dua kali karena validasi redemption terjadi setelah capture pembayaran; transfer booking antar akun tanpa re-authorisation; membatalkan pesanan yang sudah dibayar dan terkirim karena endpoint cancel tak pernah memeriksa status fulfillment. Semua mengembalikan HTTP 200. Semua adalah kerugian finansial tanpa pesan error apa pun.\nAsumsi trust antar service. Di estate microservices, satu service lazimnya memercayai header, token, atau internal endpoint yang disodorkan \u0026ldquo;pemanggil\u0026rdquo;, karena di diagram desain pemanggil selalu service internal juga. Lalu suatu saat satu service dikompromikan, atau satu internal endpoint menjadi reachable dari segmen jaringan yang kurang dipercaya, dan asumsi trust turunan itu menjadi tangga penyerang: authenticate lewat edge service yang lemah dulu, lalu sodorkan identitasnya ke hilir tempat API bernilai tinggi berada. Menemukan pola ini butuh membaca arsitektur sesuai niat desainernya, lalu mengujinya seperti penyerang akan melewatinya.\nTak satu pun dari tiga hal ini muncul di output scanner. Semua muncul di laporan analyst yang meluangkan waktu memahami apa API Anda sebenarnya dibuat untuk.\nIngin tahu bagaimana API Anda terlihat di mata penyerang? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). API \u0026amp; Application Security Review kami memadukan analisis source code manual dengan penetration testing kontekstual dan menyerahkan panduan remediasi yang langsung bisa dipakai developer. Jika yang Anda butuhkan verifikasi lebih luas atas perimeter dan segmentasi, lihat penetration testing human-led.\n","date":"11 Maret 2026","permalink":"https://puresecurity.com/id/posts/api-penetration-testing-thailand/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"API Penetration Testing yang Efektif di Thailand"},{"content":"Ada kesenjangan struktural dalam cara perusahaan bertumbuh memperoleh kepemimpinan keamanan. Scale-up dengan 50 karyawan dan pipeline enterprise serius terlalu kecil untuk membenarkan gaji CISO full-time, tetapi terlalu terekspos untuk beroperasi tanpanya. Mereka mendarat di purgatori keamanan: lead IT yang kelelahan memakai topi keamanan, calon klien enterprise yang mengajukan pertanyaan yang tak bisa dijawab siapa pun di level board maupun investor, dan regulator yang mengharapkan ada yang bertanggung jawab atas programnya.\nFractional CISO hadir persis untuk menutup kesenjangan itu.\nApa yang sebenarnya dilakukan vCISO #Virtual CISO bukan konsultan yang menulis laporan lalu pergi. Perannya adalah kepemimpinan atas kontrak: individu bernama yang bertanggung jawab, memiliki roadmap keamanan, mewakili fungsi keamanan di hadapan board, dan memikul percakapan risiko yang kalau tidak akan jatuh ke orang tanpa wewenang ataupun kosakata untuk itu.\nDalam praktiknya:\nPelaporan board dan komite: menerjemahkan risiko teknis ke bahasa pendapatan, reputasi, dan eksposur regulasi. Pertahanan audit: mendampingi regulator, auditor eksternal, dan tim keamanan pelanggan enterprise menelusuri kontrol Anda. Kuesioner enterprise: menjawab 200 pertanyaan security review yang menghalangi transaksi terbesar Anda, secara kredibel dan cepat. Anggaran dan strategi: roadmap keamanan yang dapat dipertahankan di hadapan CFO, karena disusun orang yang pernah mempertahankannya. Governance insiden: pengambil keputusan yang pernah memimpin insiden nyata, sehingga krisis pertama bukan juga kali pertama pimpinan berlatih. Tak ada yang butuh 40 jam seminggu. Semuanya butuh orang yang pernah melakukannya sungguhan, di level CISO, lebih dari sekali.\nMengapa scale-up kekurangan pembelian kepemimpinan keamanan #Perusahaan lebih kecil cenderung membeli keamanan sebagai produk (lisensi EDR, scanner, firewall) lalu heran kenapa transaksi enterprise masih macet di procurement. Alasannya: tool menjawab \u0026ldquo;apakah Anda punya kontrol?\u0026rdquo; tetapi tidak \u0026ldquo;siapa pemiliknya, bagaimana tata kelolanya, dan bisakah Anda membuktikannya kepada board kami?\u0026rdquo;\nPembeli enterprise dan regulator sebenarnya tidak mengaudit tool Anda. Mereka mengaudit struktur akuntabilitas Anda. vCISO menyediakan struktur itu: kepemilikan bernama, risk register yang dirawat, ritme governance, dan narasi keamanan yang tetap utuh di bawah interogasi.\nItu juga yang diberikan CISO full-time, tetapi dengan gaji yang baru masuk akal di atas jumlah kepala tertentu, serta siklus rekrutmen enam sampai dua belas bulan, waktu yang tidak Anda miliki saat mencoba bergerak dari 0 ke 1 di atas runway pendek.\nKeselarasan dengan engineering #Kepemimpinan keamanan terbaik tidak melawan tim engineering; ia selaras dengannya. vCISO hands-on bicara bahasa yang sama dengan developer Anda, menghormati kecepatan rilisan, dan lebih menyukai kontrol yang hidup di pipeline CI/CD daripada kontrol yang hidup di PDF kebijakan.\nInilah bedanya antara advisor governance semata dan CISO hands-on yang bisa duduk bersama platform team Anda, mereview arsitektur sesungguhnya, dan mengubah persyaratan regulasi menjadi sebuah pull request. Saat orang yang menulis laporan board adalah orang yang memahami threat model Anda, strategi berhenti menjadi teori.\nPerbandingan biaya yang sebenarnya #Cara jujur menilai kepemimpinan keamanan fractional adalah meletakkan kedua opsi di halaman yang sama dan menghitung semuanya, bukan hanya gajinya.\nOpsi full-time. CISO dengan pengalaman enterprise dan regulasi sungguhan di kawasan ini menuntut total paket jauh melampaui gaji pokok: kompensasi tahunan, bonus, tunjangan, dan biasanya komponen ekuiti, karena kandidat serius bergabung dengan perusahaan growth dengan harapan ikut menikmati hasil. Tambahkan recruitment fee 20 sampai 30 persen dari kompensasi tahun pertama serta siklus perekrutan enam sampai dua belas bulan: tahun pertama hire full-time biasanya beberapa kali lipat biaya recurring opsi fractional. Lalu ada risiko yang paling sulit dihargai: senior hire yang ternyata tidak cocok tetap menghabiskan satu siklus severance penuh.\nOpsi fractional. Retainer yang mencakup jumlah hari kerja tertentu per bulan, tanpa recruitment fee, tanpa ekuiti, tanpa notice period melampaui ketentuan kontrak. Untuk scale-up yang butuh perwakilan board, pertahanan audit, dan daya angkut security questionnaire enterprise, jumlah ini biasanya hanya sebagian kecil dari paket full-time, sambil mendapatkan orang yang sudah melakukan pekerjaan ini di beberapa perusahaan, bukan sedang belajar di atas perusahaan Anda.\nTitik impas. Kepemimpinan fractional unggul secara ekonomi murni sampai permintaan kepemimpinan keamanan menjadi sungguh-sungguh kontinu: beban regulasi yang berkelanjutan, organisasi engineering besar yang butuh partner keamanan harian, atau board yang ingin wajah eksekutif permanen. Bagi kebanyakan perusahaan, titik itu datang jauh setelah fase di mana hire full-time masih tak terjangkau, dan kesepakatan fractional yang baik membuat transisinya bertahap: jumlah hari naik seiring bisnis tumbuh, hingga full-time menjadi masuk akal, dan vCISO membantu merekrut serta menyerahkan kepada penggantinya sendiri.\nAritmetika deal enterprise. Satu sudut pandang lagi yang mengubah seluruh perbandingan. Ketika security review prospek enterprise macet, deal itu duduk di procurement, kadang-kadang bernilai lebih per tahun daripada seluruh anggaran keamanan Anda. VCISO yang bisa menjawab review itu secara meyakinkan dalam satu minggu bukanlah biaya: dalam kasus-kasus yang menentukan, retainer hanyalah pecahan kecil dibanding pendapatan yang terbuka. Kepemimpinan keamanan adalah salah satu dari sedikit fungsi yang pengeluarannya bisa dikaitkan langsung dengan deal yang dimenangi, bukan sekadar risiko yang dihindari.\nSedang mempertimbangkan kepemimpinan keamanan fraksional? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Advisory vCISO kami diserahkan oleh mantan CISO yang memiliki roadmap dan relasi board. Ingin memastikan cocok? jadwalkan Engineering \u0026amp; Scoping Session dan kami akan memetakan 90 hari pertama kepemimpinan keamanan Anda.\n","date":"18 Februari 2026","permalink":"https://puresecurity.com/id/posts/fractional-vciso-advisory-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Advisory Fractional vCISO untuk Scale-up di APAC"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/fintech--payments/","section":"Tags","summary":"","title":"Fintech \u0026 Payments"},{"content":"Fakta yang tidak nyaman: hashing bukan sama dengan melindungi. Anda bisa menyimpan hash SHA-256 dari nomor kartu kredit, sepenuhnya patuh PCI DSS, dan tetap praktis tanpa perlindungan sama sekali, karena nilai yang Anda hash tidak mengandung entropi yang cukup untuk menahan brute force.\nIni menjatuhkan tim engineering yang sebenarnya teliti, karena hashing terasa aman. Hash itu satu arah, asalnya tak bisa dipulihkan dengan membalik fungsi, jadi tentu saja datanya terlindungi. Cacatnya bukan pada hash. Cacatnya pada apa yang Anda masukkan ke dalamnya.\nMasalah entropi, dalam angka nyata #Nomor kartu 16 digit bukan angka acak. Strukturnya publik dan tetap:\n4 hingga 6 digit pertama adalah Issuer Identification Number (IIN): prefiks bank, sepenuhnya publik. Digit terakhir adalah checksum, dihitung dengan algoritma Luhn, rumus yang dipublikasikan tahun 1954. Ia bukan rahasia; ia deteksi kesalahan. Sekarang mask PAN seperti yang lazim diizinkan PCI DSS: 4 hingga 6 digit pertama dan 4 digit terakhir terlihat, 6 hingga 8 digit tengah tersembunyi:\n4532 AAXX XXXX 1234 Dengan hanya 4 digit IIN yang diketahui, yang tak diketahui tersisa 8 digit, atau paling banyak 100.000.000 kemungkinan nilai. Terapkan checksum Luhn dan hanya 1 dari 10 yang bertahan. Ruang pencarian Anda yang sesungguhnya: 10 juta nilai. Itu bukan password. Itu daftar yang sangat pendek.\nSeberapa cepat 10 juta hash bisa diuji? #Di sini keadaannya makin buruk. SHA-256 cepat memang by design. Ia dibangun untuk pemeriksaan integritas pada kecepatan gigabit, bukan untuk menyimpan rahasia. Benchmark cracking GPU modern bersifat publik dan reproducible:\nPerangkat keras Perkiraan throughput SHA-256 1× GPU RTX 4090 ~8,5 miliar hash/detik Klaster 4× RTX 4090 ~34 miliar hash/detik Klaster 8× RTX 4090 ~68 miliar hash/detik Sepuluh juta tebakan dibagi 8,5 miliar per detik kira-kira seperseribu detik. Pada satu GPU konsumen. Bahkan komputer ber-GPU tunggal bisa memakai rainbow table untuk \u0026lsquo;membalik\u0026rsquo; hash kartu kredit dalam sekejap mata.\nKesimpulannya tumpul: Patuh bukan berarti aman. Pada field entropi rendah, bahkan SHA-2 (atau SHA-3) tidak aman, bahkan saat patuh. Fungsinya memang satu arah; ia hanya mudah dihabiskan ketika ruang input kecil. Mengganti SHA-256 dengan SHA-512 atau SHA-3 tidak menyelesaikan ini, karena sama cepatnya.\nApa yang benar-benar diizinkan oleh \u0026ldquo;patuh\u0026rdquo; #PCI DSS sebenarnya tidak memerintahkan Anda meng-hash PAN dengan SHA-256. Requirement 3.5 menyatakan Anda harus membuat PAN tak terbaca menggunakan strong cryptography, yang secara eksplisit menyebut keyed hash dan enkripsi, serta mencatat bahwa indeks hashed and salted dapat diterima bila salt dirahasiakan dan hash tidak praktis dibalikkan. Masalahnya: SHA-256 polos tanpa salt atas ruang 10 juta nilai itu, dalam praktik, bisa dibalikkan lewat kehabisan-coba, sehingga ia gagal pada niat persyaratan meskipun kotak centang lolos.\nMasking (menampilkan 4-6 digit pertama dan/atau 4 terakhir) adalah kontrol terpisah: ia melindungi apa yang dilihat operator, bukan apa yang Anda simpan. Keduanya mudah tertukar, dan kekeliruan itulah cara PAN termasked-tapi-hash-polos berakhir di produksi.\nCara melindungi data semacam ini dengan benar #Solusinya: perlakukan field entropi rendah dengan penghormatan yang sama seperti password, karena secara matematis mereka sama lemahnya. Opsinya, urut dari yang terbaik:\nJangan simpan sama sekali. Tokenisasikan PAN dan simpan nomor aslinya di vault atau HSM terpisah. Bila Anda tak pernah menyimpan nilainya, tak ada yang bisa di-brute force. Keyed hashing (HMAC) dengan pepper rahasia. Bila Anda harus mengindeks berdasarkan PAN, gunakan HMAC dengan kunci entropi tinggi yang disimpan di luar database. Tanpa kuncinya, brute force tidak feasible secara komputasional apa pun entropi inputnya. Password hashing memory-hard. Saat Anda hanya bisa melindungi nilai dengan nilai itu sendiri, gunakan Argon2id (RFC 9106) atau scrypt dengan salt acak per nilai dan parameter yang dituning agar setiap tebakan memakan waktu dan memori sungguhan. Argon2id dengan biaya memori misalnya 64 MB mengubah pencarian habis-coba 0,001 detik itu menjadi berbulan-bulan waktu GPU. Salt dan pepper di mana-mana. Salt acak per nilai menaklukkan rainbow table pra-komputasi; pepper rahasia menaklukkan serangan offline sepenuhnya selama tetap rahasia. OWASP Password Storage Cheat Sheet dan NIST SP 800-63B keduanya merekomendasikan fungsi memory-hard untuk rahasia entropi rendah justru karena alasan ini.\nflowchart TD A[PAN disimpan] --\u003e B{Dibutuhkan untuk indexing?} B -- Tidak --\u003e C[Tokenisasi / vault / HSM] B -- Ya --\u003e D{Kunci rahasia tersedia?} D -- Ya --\u003e E[HMAC dengan pepper] D -- Tidak --\u003e F[Argon2id / scrypt + salt] style C stroke:#10B981,stroke-width:2px style E stroke:#10B981,stroke-width:2px style F stroke:#10B981,stroke-width:2px Pelajaran di luar kartu #Ini berlaku untuk setiap pengenal berformat tetap dengan entropi terbatas: nomor identitas nasional, nomor telepon, tanggal lahir, bahkan API key dengan generasi yang buruk. Jika ruang input kecil, kecepatan fungsi hash adalah musuh Anda, dan \u0026ldquo;patuh\u0026rdquo; bukan sinonim \u0026ldquo;aman\u0026rdquo;.\nKhawatir tentang cara Anda saat ini melindungi PAN atau pengenal lain? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). API \u0026amp; Application Security Review kami memeriksa bagaimana kode Anda benar-benar menyimpan dan mengirim nilai sensitif, dan kami akan berkata lugas di titik mana kelulusan checklist masih membiarkan data nyata terekspos.\n","date":"14 Januari 2026","permalink":"https://puresecurity.com/id/posts/hashing-low-entropy-data-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Hashing Data Entropi Rendah \u0026 Kartu Kredit di APAC"},{"content":"Pertanyaan PCI DSS yang paling sering saya dengar bukan \u0026ldquo;bagaimana cara patuh?\u0026rdquo; melainkan \u0026ldquo;apakah saya perlu patuh sama sekali?\u0026rdquo; Jawabannya lebih luas daripada yang diasumsikan kebanyakan organisasi, dan konsekuensi menebak salah tidaklah teoretis: denda, interchange fee yang lebih tinggi, dan saat terjadi breach, biaya forensik serta kerusakan merek yang dihitung dengan uang sungguhan.\nJawaban singkat #PCI Data Security Standard berlaku bagi entitas mana pun yang menyimpan, memproses, atau mengirimkan data pemegang kartu, dan bagi entitas mana pun yang dapat mempengaruhi keamanan data tersebut. Definisinya memang sengaja luas, dan menelan tiga kelompok yang rutin dianggap dikecualikan.\n1. Siapa pun yang menyimpan, memproses, atau mengirimkan data kartu #Ini kasus yang jelas, tetapi mencakup jauh lebih banyak daripada merchant yang men-swipe kartu. Cakupannya:\nSitus e-commerce yang mengambil nomor kartu pada formulir checkout. ERP yang menyimpan PAN \u0026ldquo;hanya untuk rekonsiliasi\u0026rdquo;. Call center yang mengetik nomor kartu ke CRM lewat salinan telepon terekam. Payment gateway, PSP, acquirer, dan issuer yang menyentuh data itu setiap hari. Jika data kartu mendarat di sistem Anda, sesaat pun, di memori saja, Anda masuk scope. \u0026ldquo;Kami hanya menyimpannya sebentar\u0026rdquo; bukan pengecualian; itu adalah scope.\n2. Bahkan ketika Anda memakai pemroses pihak ketiga #Miskonsepsi terbesar adalah \u0026ldquo;kami pakai Stripe / 2C2P / PayPal, jadi PCI DSS bukan urusan kami.\u0026rdquo; Menggunakan pihak ketiga mengecilkan scope Anda; tidak menghapusnya.\nBagi organisasi kecil, ini biasanya berarti Anda memenuhi syarat formulir validasi yang diperkecil: SAQ A atau SAQ A-EP alih-alih SAQ D lengkap, karena data kartu tak pernah menyentuh sistem Anda. Namun Anda tetap punya kewajiban: merawat integrasi skrip dengan benar, menjaga halaman checkout bebas dari skimming, dan mengelola pihak ketiga sesuai Requirement 12.8 standar tersebut. Anda tetap memvalidasi; hanya lebih sedikit.\nPerangkapnya adalah scope creep. Tambahkan satu field kustom yang menangkap nomor kartu di sisi server, atau alihkan pembayaran melalui endpoint milik sendiri, dan tanpa suara Anda pindah dari SAQ A ke SAQ D: kewajiban yang berbeda jauh. Tidak ada yang memberi tahu Anda saat itu terjadi.\n3. Bank dan semua pihak di hulu pemegang kartu #Bank, acquirer, issuer, dan payment facilitator bukan sekadar \u0026ldquo;masuk scope\u0026rdquo;: mereka entitas yang divalidasi paling intensif dalam ekosistem ini. Di Thailand, lembaga keuangan juga bertanggung jawab kepada pedoman Bank of Thailand tentang risiko IT dan kanal digital di atas PCI DSS. Dua rezim itu tumpang-tindih tetapi tidak identik, dan audit BOT tidak menggantikan validasi PCI DSS.\nMengapa scope adalah segalanya #Biaya PCI DSS berskala mengikuti scope. Setiap sistem, jaringan, dan orang di dalam Cardholder Data Environment (CDE) Anda tunduk pada set kontrol penuh. Memperkecil CDE karena itu aktivitas kepatuhan berdaya ungkit tertinggi yang bisa Anda lakukan:\nTokenisasi data kartu agar Anda menyimpan referensi tak berguna alih-alih PAN. Isolasi sistem pembayaran di balik segmentasi sehingga bagian bisnis lainnya keluar dari scope. Outsource secara sadar kepada penyedia layanan tervalidasi untuk bagian yang tidak perlu Anda sentuh. Lingkungan yang scope-nya ditata baik bisa mengubah asesmen enam bulan bernilai enam digit menjadi latihan yang terkendali dan berulang. Lingkungan yang ditata buruk mengaudit seluruh perusahaan tanpa manfaat keamanan tambahan.\nflowchart TD A[Data kartu diterima] --\u003e B{Menyentuh sistem Anda?} B -- Tidak --\u003e C[SAQ A / A-EP: scope diperkecil] B -- Ya --\u003e D[CDE penuh: SAQ D / ROC] D --\u003e E{Tokenisasi dan segmentasi?} E -- Ya --\u003e F[Perkecil CDE sebelum audit] E -- Tidak --\u003e G[Asesmen penuh, setiap sistem] style F stroke:#10B981,stroke-width:2px style G stroke:#F43F5E,stroke-width:2px 4.0.1 mengubah aturan main #PCI DSS 4.0.1 memformalkan banyak hal yang sudah lama dilakukan tim engineering yang baik: memperlakukan kepatuhan sebagai kondisi berkelanjutan alih-alih acara tahunan, dengan persyaratan seputar targeted risk analysis, pendekatan kontrol yang dikustomisasi, dan menjaga keamanan melalui perubahan. Pesannya: sertifikat titik-waktu tidak lagi cukup; standar kini mengharapkan kontrol tetap benar di antara dua asesmen.\nBelum yakin Anda termasuk SAQ A, SAQ A-EP, atau butuh ROC penuh? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Mulai dari mana #Mulailah dengan PCI DSS Gap Assessment \u0026amp; Scope Reduction sebelum berkomitmen pada audit: perkecil CDE, uji segmentasi Anda, baru kemudian validasi. Saat siap, audit kami yang dipimpin QSA akan mendampingi Anda melewati ROC/AOC penuh dengan asesor aktif di Bangkok.\n","date":"10 Desember 2025","permalink":"https://puresecurity.com/id/posts/pci-dss-compliance-thailand/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Siapa yang Perlu Patuh PCI DSS 4.0.1 di Thailand?"},{"content":"Dua puluh tahun lalu, patching adalah kerja rumah bulanan: sebuah spreadsheet, maintenance window, change advisory board, dan doa agar tidak ada yang rusak. Ritme itu berhasil karena penyerang kira-kira selembut pembela. Dunia itu sudah hilang.\nKini kerentanan bisa diumumkan, dimpersenjatai, dan dieksploitasi massal dalam hitungan jam. Jarak antara \u0026ldquo;proof of concept\u0026rdquo; dan \u0026ldquo;in the wild\u0026rdquo; telah runtuh sedemikian rupa sehingga manusia yang mereview spreadsheet sudah terlambat. Vulnerability management harus menjadi pipeline, bukan proses.\nAI sebagai akselerator #Dua tren menjadikan AI variabel dominan dalam persamaan ini.\nPertama, pertahanan berbantuan AI: static analyzer, fuzzer, dan tool code review kini cukup baik untuk memunculkan cacat lebih cepat daripada auditor manusia mana pun. Kabar baik, dan itulah mengapa tim keamanan tenggelam dalam temuan.\nKedua, dan lebih penting, serangan berbantuan AI. Peneliti dan penyerang sama-sama menggunakan language model untuk mentriage advisory, menulis exploit yang berfungsi, dan memutasi teknik serangan yang dikenal untuk melewati signature. Google Project Zero dan karya akademik tentang penemuan kerentanan otomatis telah menunjukkan bahwa yang dulu butuh berbulan-bulan usaha manusia kini dapat dipadatkan secara dramatis.\nEfek bersihnya: jarak penemuan-ke-eksploitasi menyempit setiap bulan, dan antrean patch manual tak lagi sanggup mengejar. Ini bukan spekulasi: tampak jelas dalam katalog CISA Known Exploited Vulnerabilities, di mana time-to-exploit tipikal untuk kerentanan yang tercantum terus menyempit relatif terhadap disclosure.\nTernak, bukan peliharaan #Frasa \u0026ldquo;cattle, not pets\u0026rdquo; lahir di era awal cloud: gagasan bahwa server seharusnya sumber daya yang dapat dipertukarkan dan dibuang, bukan mesin yang di-tuning tangan dengan nama dan kepribadian. Ia berlaku sempurna untuk patching.\nJika server adalah peliharaan, Anda patch dengan lembut: login, terapkan fix, restart, berdoa. Jika ternak, Anda tidak patch sama sekali. Anda menggantinya. Anda membakar image baru yang sudah di-patch di CI/CD, memusnahkan instance lama, dan men-deploy yang baru. Patch adalah artefak build, direview dan diuji sebelum menyentuh produksi.\nflowchart LR A[CVE diterbitkan] --\u003e B[Triase otomatis] B --\u003e C{Bangun image yang di-patch} C --\u003e D[Uji di pipeline] D --\u003e E[Deploy dan rotasi instance] E --\u003e F[Image lama dimusnahkan] style C stroke:#0EA5E9,stroke-width:2px style F stroke:#10B981,stroke-width:2px Immutable infrastructure mengubah patching dari operasi manual berisiko menjadi deployment rutin. Itulah satu-satunya model yang berskala pada kecepatan eksploitasi modern, dan ia mensyaratkan pipeline pengujian serta deployment otomatis yang belum dibangun banyak tim.\nPrioritisasi atas volume #Scanner yang mengembalikan 40.000 temuan bukanlah program keamanan; itu noise. Kemahirannya ada pada triase: mana dari temuan itu yang benar-benar reachable, benar-benar exploitable, dan benar-benar berada di critical path.\nModel CISA SSVC menangkap pola pikir yang tepat: prioritaskan berdasarkan status eksploitasi, exposure, dan dampak misi, bukan skor CVSS semata. CVSS 9.8 pada layanan internal-only non-routable sering kali kurang mendesak dibanding CVSS 6.5 pada endpoint publik dengan exploit yang diketahui beredar.\nLapisan, karena tiap lapisan AKAN gagal #Tak ada satu kontrol pun yang selamat dari kontak dengan penyerang yang gigih. Defence in depth adalah pengakuan bahwa setiap lapisan punya mode kegagalan:\nPatching memperkecil attack surface tetapi tidak bisa instan. Segmentasi jaringan menahan blast radius saat patching tertinggal. Deteksi runtime menangkap yang lolos dari siklus patch. Least privilege membatasi jangkauan aset yang terkompromikan. Backup dan recovery yang teruji adalah garis pertahanan terakhir ketika semua di atas gagal. Tujuannya bukan mencegah setiap eksploitasi. Tujuannya membuat setiap kegagalan tunggal survivable. Saat pipeline patch telat seminggu, segmentasi dan deteksi memberi waktu mengejar. Saat segmentasi gagal, least privilege membatasi kerusakan. Melapiskan adalah cara Anda tetap di depan garis waktu yang tak sepenuhnya bisa Anda kendalikan.\nKesulitan mengejar antrean patch? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Ke mana semua ini berujung #Vulnerability Management \u0026amp; Compliance Scanning kami menyediakan scanning kontinu otomatis dan pelaporan berprioritas untuk PCI DSS, BOT, dan ISO 27001; Linux \u0026amp; Infrastructure Hardening kami mengunci perbaikan ke dalam kode.\n","date":"12 November 2025","permalink":"https://puresecurity.com/id/posts/vulnerability-management-patching-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Vulnerability Management \u0026 Patching Modern di APAC"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/cost--strategy/","section":"Tags","summary":"","title":"Cost \u0026 Strategy"},{"content":"Ada ironi senyap dalam procurement keamanan enterprise: organisasi mau membayar lisensi tujuh digit untuk \u0026ldquo;platform terpadu\u0026rdquo; yang, di balik kap, adalah bundel proyek open source dibungkus dashboard dan gerakan penjualan. Vendornya tidak menciptakan detection engine; komunitaslah yang menciptanya. Anda membayar pengemasan.\nIni bukan argumen menolak membayar perangkat lunak. Ini argumen untuk tahu apa yang Anda beli, dan menyadari bahwa tim engineering kecil sering bisa membangun security stack yang lebih efektif dan lebih bespoke dari komponen open source daripada melisensinya dari vendor.\nSolusi bespoke untuk lingkungan unik #Tak ada dua lingkungan yang sama, tetapi tool komersial dibangun untuk lingkungan rata-rata. Mereka mengasumsikan bentuk jaringan, topologi data center, dan model logging yang mungkin tak cocok dengan realita Anda. Hasilnya: tool yang pas 80% lingkungan Anda dan canggung membiarkan 20% sisanya, biasanya bagian yang justru penting, tetap diserahkan ke skrip kustom.\nOpen source membalik relasi itu. Anda menyusun stack agar cocok dengan arsitektur Anda, bukan sebaliknya. Runtime security dengan Falco, visibilitas jaringan dengan Zeek, host intrusion detection dengan Wazuh, container scanning dengan Trivy, otomatisasi kerentanan dengan Nuclei, static analysis dengan Semgrep. Setiap komponen melakukan satu hal dengan baik, dan mereka saling terhubung.\nInilah filosofi Unix yang diterapkan pada keamanan: tool kecil dan tajam yang berkomunikasi lewat antarmuka standar, bukan satu monolit yang memiliki segalanya.\nTool-tool ini saling bicara #Suite vendor ingin menjadi pusat gravitasi. Semua harus mengalir kepadanya, memakai agent-nya, berbicara bahasa query-nya. Silo itu menjadi langit-langit: begitu Anda butuh sinyal yang tak dihasilkannya secara native, Anda terjebak menunggu roadmap.\nTool open source dibangun di sekitar format dan API terbuka. Zeek mengeluarkan JSON. Falco mengeluarkan event ke stdout. Wazuh mengambil data via API. Karena berkomunikasi lewat antarmuka terbuka, Anda bisa mengarahkan semuanya ke pipeline yang sama, entah klaster OpenSearch, SIEM, atau log sink biasa, dan meng-query keseluruhan gambar dengan satu bahasa.\ngraph LR A[Falco: runtime] --\u003e E[OpenSearch / SIEM] B[Zeek: jaringan] --\u003e E C[Wazuh: host] --\u003e E D[Nuclei: scanning] --\u003e E E --\u003e F[Detection and response playbook] style E stroke:#0EA5E9,stroke-width:2px style F stroke:#10B981,stroke-width:2px Suite komersial meminta Anda melepas composability itu. Stack open source menjadikannya default.\nAnda berinvestasi pada orang, bukan lisensi #Lisensi adalah biaya berulang yang hilang begitu Anda berhenti membayar, beserta kemampuannya. Stack open source adalah investasi berulang pada engineer Anda, yang mempelajari isi tool yang mereka operasikan.\nItu lebih penting daripada barisan anggarannya. Engineer yang membangun detection pipeline memahami kenapa sebuah alert berbunyi, bisa menyetel false positive tanpa membuka tiket support, dan bisa memperluas tool saat ancaman baru muncul. Organisasi Anda memiliki kemampuan itu; tidak menyewanya.\nSaat engineer kunci pergi, proyek tidak mati bersamanya. Perangkat tersebut version-controlled, terdokumentasi, dan reproducible, karena kerja open source secara alami terbuka untuk ditelaah. Itu dinamika yang sama yang dideskripsikan Eric S. Raymond dalam The Cathedral and the Bazaar: banyak mata pada kode membuat bug dangkal, dan menjadikan transfer pengetahuan bagian dari proses, bukan pikirankemudian.\nWaspadai jebakan \u0026ldquo;kami sudah menjual itu\u0026rdquo; #Sebelum membeli apa pun, lihat apa yang sudah Anda operasikan. Jumlah organisasi yang mengejutkan melisensikan SIEM komersial, scanner komersial, dan EDR komersial, lalu menemukan stack open source mereka yang ada sudah memproduksi 90% sinyal yang sama secara gratis.\nPolanya berulang: vendor menjual \u0026ldquo;solusi\u0026rdquo; yang sebenarnya lapisan orkestrasi atas tool yang bisa Anda jalankan sendiri, dengan UI dan kontrak support dilekatkan. Kontrak support itu bernilai nyata saat Anda kekurangan orang mengoperasikan tool. Tetapi jika Anda punya orang, atau ingin membangunnya, jalur open source biasanya lebih murah dan lebih efektif.\nKapan \u0026ldquo;membeli\u0026rdquo; masih tepat #Ini bukan argumen seragam. Tool komersial menang saat:\nAnda tidak punya siapa pun mengoperasikan tool, dan support adalah produknya. Vendor sungguhan memiliki konten deteksi proprietari yang tak bisa Anda replikasi. Diperlukan atestasi regulasi atas vendor itu sendiri (bukan hanya penggunaan Anda). Poinnya adalah mengambil keputusan itu secara sadar, mata terbuka soal apa yang ada di balik kap, bukan default ke lisensi.\nMerasa tooling Anda saat ini layak dengan lisensinya? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Jika Anda ingin komposisinya dikerjakan untuk Anda, Configuration \u0026amp; Architecture Assessment kami mereview apa yang sudah Anda jalankan dan memetakan jalur build-vs-buy untuk celahnya, atau jadwalkan Engineering \u0026amp; Scoping Session untuk merancang stack bespoke sesuai lingkungan Anda.\n","date":"15 Oktober 2025","permalink":"https://puresecurity.com/id/posts/open-source-security-tools-thailand/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Open Source vs Security Tools Komersial di Thailand"},{"content":"Sebagian besar eksekutif merasakan kepatuhan keamanan siber sebagai pajak yang diperlukan: binder yang dirakit setahun sekali, auditor yang dilewati, dan pos anggaran yang tak kunjung menghasilkan pendapatan. Bingkai itu terbalik, dan biayanya melebihi fee audit. Dilakukan dengan benar, kepatuhan adalah business case terkuat yang akan dimiliki program keamanan, karena ia mengubah upaya engineering menjadi sesuatu yang bisa diverifikasi pembeli, mitra, dan regulator.\nKepatuhan memvalidasi belanja, bukan menciptakannya #Anggaran keamanan adalah perdebatan abadi dengan finance. \u0026ldquo;Apa yang kita dapat dari belanja tahun lalu?\u0026rdquo; adalah pertanyaan yang wajar, dan \u0026ldquo;kami memblokir ancaman\u0026rdquo; adalah jawaban yang cepat usang begitu breach terjadi. Framework kepatuhan memberi Anda tolok ukur eksternal yang bisa diverifikasi secara independen atas belanja itu.\nSaat lingkungan Anda selaras dengan ISO/IEC 27001, NIST CSF, atau PCI DSS 4.0.1, setiap kontrol yang Anda danai dipetakan ke persyaratan yang bisa diuji asesor. Itu mengubah \u0026ldquo;kami rasa kami aman\u0026rdquo; menjadi \u0026ldquo;pihak ketiga berkualifikasi telah membuktikan kami memenuhi standar internasional.\u0026rdquo; Bagi board, itulah beda antara investasi keamanan berbasis iman dan berbasis bukti.\nKebalikannya juga penting: tanpa framework, belanja melayang ke vendor dengan tim penjualan paling keras. Kepatuhan memaksa prioritisasi. Sulit membenarkan tool gengsi saat gap analysis Anda menyatakan risiko sesungguhnya adalah batas identitas yang belum di-patch.\nTrust dan assurance kini kriteria procurement #Pembeli enterprise di APAC tak lagi menerima paragraf \u0026ldquo;kami serius soal keamanan\u0026rdquo; di deck penjualan. Mereka mengirim security questionnaire, lalu hak audit, lalu penetration test. Di sektor teregulasi, mereka mengirim asesor.\nArtefak kepatuhan adalah mata uang percakapan itu:\nSertifikat ISO 27001 memotong berminggu-minggu bolak-balik kuesioner. Report on Compliance (ROC) atau AOC PCI DSS adalah gerbang wajib bagi siapa pun yang menyentuh data kartu, dan semakin sering menjadi syarat di hulu rantai nilai pembayaran. Keselarasan Bank of Thailand (BOT) IT Risk Guideline memberi sinyal kepada lembaga keuangan dan vendornya bahwa Anda memahami lensa regulasi lokal. Masing-masing mengurangi biaya menjadi pemasok. Itu dampak pendapatan, bukan sekadar reduksi risiko. Semakin cepat prospek meloloskan Anda, semakin cepat transaksi tuntas, dan semakin sedikit tim engineering Anda ditarik menjawab kuesioner alih-alih mengirim produk.\nKepatuhan membuka pintu ke sektor lebih besar dan pelanggan lebih besar #Manfaat kepatuhan yang paling kurang dibahas adalah akses. Tender pemerintah, layanan keuangan, kesehatan, dan procurement enterprise besar di Thailand dan seluruh APAC rutin menjadikan standar internasional sebagai syarat ikut tender, bukan bonus.\nPerusahaan software bertumbuhan yang meraih ISO 27001 tiba-tiba memenuhi syarat kontrak yang sebelumnya menyaringnya keluar. Fintech yang menjaga kepatuhan PCI DSS 4.0.1 bisa meng-onboard acquirer dan mitra PSP yang tadinya menolak hubungan. Perusahaan regional yang selaras NIST CSF bisa menjawab secara kredibel induknya yang berkedudukan di AS yang terus bertanya \u0026ldquo;Anda beroperasi terhadap framework apa?\u0026rdquo;\nKepatuhan, pada dasarnya, adalah kunci akses pasar. Setiap framework membuka kelas pelanggan baru yang memperlakukan sertifikat sebagai batas minimum sebelum pertemuan pertama.\nLayanan yang tangguh dan aman itulah produk sesungguhnya #Inilah bagian yang hilang dalam narasi \u0026ldquo;kepatuhan itu pekerjaan kertas\u0026rdquo;: sebagian besar kontrol framework hanyalah engineering yang baik, yang dituliskan.\nAccess control dan least privilege mengurangi lateral movement. Change management dan patching memperpendek jendela eksploitasi yang diketahui. Logging dan monitoring mengubah outage buta menjadi insiden yang dapat didiagnosis. Backup dan uji pemulihan adalah beda antara gangguan dan peristiwa yang mengakhiri bisnis. Riset IBM Cost of a Data Breach konsisten menemukan prediktor terkuat biaya breach yang lebih rendah adalah incident response yang matang dan lingkungan kontrol yang teruji: tepat hal-hal yang framework paksa Anda rawat. Verizon DBIR menyampaikan hal yang sama dari sisi penyerang: sebagian besar insiden mengeksploit kelemahan yang diketahui dan dapat di-patch, yang sudah seharusnya ditangani program patch berbasis kepatuhan.\nDengan kata lain, kepatuhan adalah cara organisasi melembagakan resiliensi. Itu beda antara satu engineer berbakat yang meng-hardening sebuah server dan organisasi yang meng-hardening semua server, secara default, saat rilisan dan selamanya.\nMembingkainya untuk board #Jika Anda yang membela anggarannya, berhenti menawarkan kepatuhan sebagai biaya berbisnis. Tawarkan sebagai:\nAssurance: kontrol yang dibuktikan independen, mempercepat penutupan transaksi enterprise. Akses: kualifikasi untuk procurement teregulasi dan enterprise yang tidak bisa Anda masuki sebaliknya. Bukti: imbal hasil belanja keamanan yang terukur, alih-alih janji samar. Resiliensi: disiplin engineering yang dilembagakan, bertahan melewati pergantian staf. Itu business case yang bisa dibaca CFO dan didukung CISO.\nAda pertanyaan singkat soal ISO 27001, NIST CSF, atau pedoman Bank of Thailand? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Mulai dari mana #Kebanyakan organisasi tak perlu merebus lautan. Mulailah dengan gap assessment terhadap satu framework yang benar-benar ditanyakan pelanggan terbesar Anda, tutup celah yang dipetakan ke eksposur nyata, dan biarkan sertifikat mengikuti engineering, bukan sebaliknya.\nJika Anda lebih suka memetakannya ke roadmap spesifik Anda, jadwalkan Engineering \u0026amp; Scoping Session dan kami akan menerjemahkan framework itu menjadi daftar tugas engineering konkret.\n","date":"17 September 2025","permalink":"https://puresecurity.com/id/posts/roi-cybersecurity-compliance-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"ROI Bisnis Kepatuhan Keamanan Siber di APAC"},{"content":"Fintech yang berkembang melintasi Southeast Asia menghadapi patchwork regulator, masing-masing dengan prioritas, tenggat dan definisi sendiri. Apa yang lolos Monetary Authority of Singapore bisa meninggalkan celah di bawah pengawasan Bangko Sentral ng Pilipinas. Lingkungan kontrol yang dirancang untuk Bank Negara Malaysia mungkin tak memuaskan pemeriksa Bank of Thailand tanpa rework besar.\nIni bukan teori. Kami pernah melihat organisasi menemukan di tengah audit bahwa masa retensi log mereka memenuhi satu regulator tapi bukan yang lain. Kami pernah menyaksikan tim compliance membangun fungsi DPO yang memenuhi ekspektasi MAS hanya untuk tahu BSP mensyaratkan kualifikasi berbeda. Kesalahan mahal lahir dari asumsi bahwa \u0026ldquo;regulasi Asia\u0026rdquo; itu saling menggantikan.\nTidak.\nEmpat Regulator Sekilas # Bank of Thailand (BOT) Monetary Authority of Singapore (MAS) Bank Negara Malaysia (BNM) Bangko Sentral ng Pilipinas (BSP) Arah utama Pedoman Risiko IT / Keamanan Kanal Digital Pedoman Manajemen Risiko Teknologi Manajemen Risiko dalam Teknologi (RMiT) Kerangka Manajemen Risiko IT Cakupan Bank, PSP, penerbit e-money, fintech di bawah pengawasan BOT Bank, asuransi, entiti pasar modal, layanan pembayaran Berlisensi bank, bank Islam, penerbit e-money Bank, lembaga keuangan non-bank, penerbit e-money, VASP Retensi log Minimal 1 tahun (90 hari hot) Rekam transaksi 5 tahun; log sistem sesuai penilaian risiko Minimal 1 tahun, jejak audit disarankan 7 tahun Minimal 3 tahun untuk semua log relevan keamanan Notifikasi breach Dalam 24 jam ke BOT (insiden material); individu terdampak 72 jam per PDPA Insiden severe dalam 1 jam; laporan akar masalah 14 hari Dalam 1 jam ke BNM via email; laporan tertulis 7 hari Dalam 2 jam ke BSP; laporan rinci 14 hari Penetration testing Tahunan, atau setelah perubahan signifikan Tahunan; scope ditentukan Pedoman TRM Tahunan; mencakup sistem internet-facing dan internal kritikal Tahunan; pengujian tambahan setelah perubahan material Di Mana Persyaratannya Bertabrakan #Retensi Log: Jebakan Tiga Tahun #Kejutan lintas-yurisdiksi paling umum adalah retensi log. Organisasi yang membangun infrastruktur logging untuk memenuhi syarat satu tahun BOT akan gagal pemeriksaan BSP yang menuntut tiga tahun log relevan keamanan. Selisih biayanya tidak linear: menyimpan tiga tahun log yang dapat dicari butuh arsitektur berbeda dari mengarsipkan satu tahun lalu menghapus.\nSebaliknya, organisasi yang dibangun sekitar tiga tahun BSP mungkin over-provision untuk Singapura, tempat fokusnya lima tahun rekam transaksi menurut MAS Notice 826 tetapi log sistem mengikuti pendekatan berbasis risiko, bukan durasi tetap.\nSaran praktis: Rancang pipeline logging Anda untuk masa retensi terpanjang di antara semua yurisdiksi tempat Anda beroperasi. Lebih murah memuaskan banyak regulator sekaligus daripada retrofit nanti.\nData Protection Officer: Siapa, Bukan Sekadar Ada atau Tidak #PDPA Malaysia secara eksplisit mensyaratkan DPO warga Malaysia atau penduduk tetap (Pasal 12, Personal Data Protection Act 2010). PDPA Thailand tidak punya persyaratan eksplisit seperti ini, tetapi dalam praktiknya pemeriksaan BOT dilakukan dalam bahasa Thai dan menuntut jawaban yang menunjukkan pengetahuan regulasi lokal. Ini menciptakan preferensi tidak langsung bagi personel berbahasa Thai meski undang-undang tidak mewajibkan kewarganegaraan.\nSingapura mengambil pendekatan berbasis prinsip: Pedoman TRM MAS menuntut akuntabilitas level board atas risiko teknologi tapi tidak meresepkan kualifikasi DPO. BSP Circular 1105 Filipina mensyaratkan Chief Information Security Officer atau setaranya namun tidak menentukan kewarganegaraan.\nBagi organisasi regional, ini berarti:\nDPO grup yang berbasis di Singapura mungkin tidak memenuhi persyaratan Malaysia DPO warga negara Thailand mungkin kurang kemampuan bahasa Inggris untuk pelaporan MAS Filipina mungkin menerima pelantik regional dengan delegasi otoritas lokal Saran praktis: Petakan persyaratan DPO sebelum menstrukturkan tim compliance regional Anda. Dalam beberapa kasus, menunjuk wakil lokal yang melapor kepada kepala regional memenuhi sekaligus pengawasan pusat dan ekspektasi regulator lokal.\nNotifikasi Breach: Kecepatannya Beda Lebih Jauh dari Dugaan #Jendela notifikasi berkisar dari satu jam (MAS, insiden severe) hingga tujuh puluh dua jam (Thai PDPA, individu terdampak). Ini bukan perbedaan kecil: proses respons yang dikalibrasi untuk jendela 24 jam BOT akan melewatkan tenggat satu jam MAS jika insiden severe terjadi di luar jam kerja.\nSkenario BOT MAS BNM BSP Ransomware terdeteksi di test server terisolasi Wajib lapor jika material Wajib lapor dalam 1 jam apa pun isolasinya Wajib lapor dalam 1 jam Wajib lapor dalam 2 jam Data pelanggan terekspos via storage salah konfigurasi Ya + PDPA notifikasi individu Ya + PDPA notifikasi individu Ya + PDPA notifikasi individu Ya + NPC (Philippine DPO) notifikasi individu Breach vendor pihak ketiga memengaruhi data Anda Tanggung jawab Anda laporkan BOT Tanggung jawab Anda laporkan MAS Tanggung jawab Anda laporkan BNM Tanggung jawab Anda laporkan BSP Tabel di atas mengilustrasikan kenapa rencana respons insiden harus sadar-yurisdiksi, bukan one-size-fits-all. Peristiwa ransomware yang sama memicu jam berbeda bergantung entitas mana yang menemukannya dan regulator mana yang mengawasi sistem terdampak.\nDi Mana Keselarasan Mungkin #Meski beda-beda, tumpang-tindihnya besar. Keempat regulator mengharapkan:\nAkuntabilitas level board atas risiko teknologi, dibuktikan lewat struktur governance terdokumentasi Penetration testing berkala atas sistem internet-facing dan internal kritikal Program vulnerability management dengan tenggang remediasi berdasarkan severity Kerangka access control yang menerapkan least privilege dan segregation of duties Rencana respons insiden yang terdokumentasi, diuji, dan diperbarui Third-party risk management mencakup vendor yang mengakses data atau sistem sensitif Lingkungan kontrol yang dirancang baik bisa memuaskan banyak regulator sekaligus. Kuncinya mendesain kontrol terhadap persyaratan paling ketat yang berlaku, lalu mendokumentasikan bagaimana ekspektasi spesifik tiap regulator dipenuhi.\nContohnya, program vulnerability management yang mem-patch kerentanan critical dalam tujuh puluh dua jam melampaui ekspektasi setiap regulator. Mendokumentasikan tenggat ini sekali memuaskan BOT, MAS, BNM dan BSP tanpa modifikasi.\nDokumen Sumber Utama # Pedoman Risiko IT Bank of Thailand Notifikasi BOT tentang Layanan Keamanan Kanal Digital Pedoman Manajemen Risiko Teknologi MAS Notice Cyber Hygiene MAS MAS Notice 826: Pencegahan Pencucian Uang dan Pendanaan Terorisme BNM Risk Management in Technology (RMiT) BSP Memorandum M-2020-022: Kerangka Manajemen Risiko Teknologi Informasi BSP Circular 1105: Pedoman Tata Kelola Korporat yang Ditingkatkan Undang-Undang Perlindungan Data Pribadi Thailand (PDPA) Personal Data Protection Act Singapura Personal Data Protection Act Malaysia Data Privacy Act Filipina Jurang Penegakan #Ekspektasi regulasi satu hal; intensitas penegakan hal lain. Memahami jurang ini membantu memprioritaskan investasi compliance.\nMAS luas dianggap regulator paling canggih secara teknis di kawasan ini. Pemeriksaannya menggali kedalaman implementasi, bukan sekadar keberadaan kebijakan. MAS punya catatan penegakan publik termasuk denda dan pembatasan bisnis atas kegagalan risiko teknologi, termasuk penalti S$3,8 juta terhadap OCBC pada 2023 atas kontrol anti-pencucian uang yang tidak memadai.\nBOT meningkatkan penegakan signifikan sejak pedoman digital banking diterbitkan. Pemeriksaan kini mencakup pengujian teknis, bukan hanya review dokumen. Namun regulator memberi lebih banyak panduan implementasi dibanding MAS, yang bisa mengurangi ambiguitas interpretasi.\nBNM menjaga penegakan kuat didukung persyaratan preskriptif RMiT. Sifat preskriptifnya berarti lebih sedikit interpretasi dibutuhkan tetapi juga lebih sedikit fleksibilitas menerapkan pendekatan alternatif.\nBSP aktif memperkuat kapasitas pengawasannya. Inisiatif terbaru menunjukkan intensitas penegakan akan naik ke arah level MAS, membuat gap compliance hari ini menjadi temuan pemeriksaan masa depan.\nSaran Praktis # Rancang untuk persyaratan paling ketat. Kalau Anda beroperasi di Filipina, bangun retensi log tiga tahun. Otomatis memuaskan semua yang lain. Dokumentasikan pemetaan kontrol-ke-regulasi. Rawat matrix yang menunjukkan kontrol spesifik mana memenuhi persyaratan regulasi mana. Ini tak ternilai saat audit multi-yurisdiksi. Jangan asumsikan resiprositas. Regulator tidak menerima sertifikasi satu sama lain. Lolos inspeksi MAS tidak mengecualikan Anda dari pemeriksaan BOT. Lokalkan playbook respons insiden. Rawat templat notifikasi, daftar kontak, dan jalur eskalasi per yurisdiksi. Saat krisis, Anda tak semestinya sedang mencari-cari tenggat notifikasi. Libatkan regulator baru lebih awal. Masuk pasar baru, mulai dialog dengan regulator lokal sebelum deployment, bukan sesudah. Keterlibatan awal memunculkan ekspektasi yang pedoman terpublikasi mungkin belum menangkap penuh. Beroperasi lintas beberapa yurisdiksi ASEAN? Mari bicara lugas soal memetakan kontrol Anda ke ekspektasi tiap regulator. Hubungi kami di LINE (@PureSecurity) atau email (hello@puresecurity.com). Layanan Regulatory Compliance kami memetakan kontrol eksisting Anda terhadap persyaratan spesifik tiap regulator, mengidentifikasi gap dan overlap, serta menghasilkan bukti dokumentasi yang diminta pemeriksaan multi-yurisdiksi.\n","date":"14 Mei 2025","permalink":"https://puresecurity.com/id/posts/asean-cyber-regulations-comparison/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Membandingkan Regulasi Siber ASEAN: BOT vs MAS vs BNM vs BSP"},{"content":"Cloud memberi imbalan pada kecepatan. Satu tim bisa mendirikan environment production lengkap dalam satu sore: compute, storage, database, load balancer, semuanya dari CLI atau satu file Terraform. Kecepatan yang sama juga berlaku untuk kesalahan. Storage bucket yang dibuat publik untuk demo dan tidak pernah dikembalikan, security group yang dibuka ke 0.0.0.0/0 demi \u0026ldquo;memperbaiki\u0026rdquo; masalah konektivitas menjelang deadline, admin credential yang di-paste ke channel Slack: masing-masing hanya butuh beberapa detik, dan masing-masing bisa mengekspos seluruh bisnis.\nItulah asimetri inti cloud security. On-premises, satu kesalahan biasanya memengaruhi satu server di satu jaringan. Di cloud, satu pengaturan sering kali secara default dapat dijangkau global, dan ada scanner otomatis di setiap benua yang mencari pengaturan seperti itu sepanjang waktu. Penyerang zaman sekarang jarang membobol lagi, begitu kata pepatahnya: mereka log in, lewat pintu yang seseorang tinggalkan terbuka tanpa sadar.\nMengapa misconfiguration mendominasi insiden cloud #Pelajari catatan publik breach dan polanya jelas. Mayoritas eksposur data cloud bukan hasil eksploitasi baru. Mereka hasil pengaturan yang dikenal, terdokumentasi, namun ditinggalkan dalam kondisi tidak aman:\nObject storage terekspos publik. Bucket yang menyimpan data pelanggan, backup, atau dump database, terbuka ke internet karena satu flag. IAM terlalu longgar. Policy seperti Action: \u0026quot;*\u0026quot; pada Resource: \u0026quot;*\u0026quot;, diberikan untuk kenyamanan proyek dan tak pernah dippersempit setelahnya. Management console bisa dijangkau dari mana saja. Tanpa pembatasan IP, tanpa penegakan MFA, credential bekerja dari negara mana pun. Data store tanpa enkripsi. Snapshot dan volume yang bisa dibaca siapa pun yang memperoleh identifier-nya. Secrets di dalam kode. API key yang di-commit ke repository, ditemukan automated scraper dalam hitungan menit. Tak satu pun butuh kecanggihan untuk dieksploitasi. Semua hanya butuh perhatian wajar untuk dicegah. Persis itulah mengapa hal ini penting: mereka berada di celah antara apa yang platform dokumentasikan dan waktu yang dimiliki tim engineering yang sibuk.\nYang tidak terlihat tidak bisa diperbaiki #Langkah pertama yang jujur di sebagian besar engagement adalah mengakui seberapa luas permukaannya sebenarnya. Organisasi berukuran menengah rutin memiliki ribuan resource cloud tersebar lintas account, region, dan subscription, terkumpul dari tim berbeda selama bertahun-tahun. Tidak ada yang menyimpan gambar utuhnya di kepala, dan spreadsheet basi dalam hitungan minggu.\nDi sinilah continuous monitoring membuktikan nilainya. Prinsipnya sederhana: perlakukan configuration state seperti application health, sesuatu yang diamati terus-menerus alih-alih diaudit setahun sekali.\ngraph LR A[Cloud APIs\nconfig state] --\u003e B[Continuous assessment] C[IaC repos\nTerraform etc] --\u003e B D[Identity \u0026\naccess logs] --\u003e B B --\u003e E{Severity triage} E --\u003e|Critical exposure| F[Fix now:\nautomated where possible] E --\u003e|Drift and noise| G[Tune, baseline,\nscheduled remediation] style B stroke:#0EA5E9,stroke-width:2px style F stroke:#EF4444,stroke-width:2px style G stroke:#10B981,stroke-width:2px CSPM: tooling berguna, dengan catatan #Cloud Security Posture Management hadir untuk mengotomatisasi pengamatan itu. Alat-alat ini membandingkan konfigurasi live Anda dengan benchmark seperti CIS Foundations Benchmark dan framework best practice vendor, lalu menaikkan temuan dengan severity rating. Setiap cloud besar kini punya opsi native (AWS Security Hub, Azure Secure Score, Google Security Command Centre), dan tool pihak ketiga menambah coverage multi-cloud serta konteks lebih dalam.\nDipakai dengan baik, benar-benar bernilai. Dipakai naif, ia menciptakan masalah lain: antrean temuan sepanjang itu sampai tim berhenti membacanya. Tiga kebiasaan membedakan kedua hasil:\nMulai dari eksposur yang menghadap internet. Storage publik, port manajemen terbuka, dan service tanpa autentikasi didahulukan. Inilah temuan yang menjadi insiden minggu ini, bukan kelak. Perbaiki sumbernya, bukan sekadar resource-nya. Jika temuan diperbaiki manual tetapi modul Terraform masih membuatnya secara tidak aman, Anda baru membeli satu siklus pembersihan. Ubah modulnya, dan temuan itu hilang permanen di semua tempat modul itu dipakai. Tuning tanpa henti. Suppress temuan yang tidak relevan dengan arsitektur Anda, lengkap dengan justifikasi tertulis. Antrean yang hanya berisi temuan yang akan ditindak lebih bernilai daripada antrean lengkap yang tak dibaca siapa pun. Catat apa yang CSPM tidak lakukan: ia mengamati, bukan menegakkan. Guardrail seperti service control policy yang langsung menolak bucket publik, atau policy organisasi yang memblokir region sprawl, mencegah kesalahan sejak saat pembuatan. Program terkuat menggabungkan keduanya: guardrail untuk yang sudah diketahui buruk, monitoring untuk sisanya.\nKontrol terbaik adalah engineer yang paham #Setiap lapisan teknis di atas pada akhirnya bergantung pada orang yang memahami mengapa pengaturan itu penting. Engineer yang paham bahwa ACL object storage independen dari network routing akan ragu sebelum membuat bucket world-readable demi demo kilat. Yang tidak pernah ditunjukkan akan klik melewatinya.\nLangkah praktis yang cocok dengan culture engineering nyata:\nJadikan jalur aman sebagai jalur termudah. Golden Terraform module, pola arsitektur pre-approved, dan internal module dengan encryption serta logging aktif secara default mengalahkan dokumen policy sebanyak apa pun. Sesi singkat hands-on. Sembilan puluh menit bersama environment Anda sendiri, membahas temuan CSPM Anda sendiri bersama-sama, mengajarkan lebih banyak daripada satu hari slide cloud security generik. Post-mortem blameless untuk near miss. Bucket yang terekspos tapi diselamatkan rekan kerja sebelum ditemukan penyerang adalah pelajaran gratis. Tuliskan, bagikan luas, lalu ubah modul yang memungkinkannya. Libatkan engineer sejak awal dalam percakapan scoping. Security review saat desain biayanya hitungan jam. Setelah launch, harganya rework. Admin education bukan alternatif lunak dari tooling: ia pengali atas setiap kontrol lain yang Anda beli.\nMulai kuartal ini #Kalau hanya satu hal yang Anda ambil dari artikel ini: Anda tidak perlu transformasi platform untuk menekan risiko misconfiguration cloud secara material. Urutan sembilan puluh hari yang realistis:\nMinggu 1 sampai 2: Enumerasi setiap account, subscription, dan project. Aktifkan posture tooling native jika belum. Minggu 3 sampai 6: Triage dan perbaiki semua eksposur yang menghadap internet. Daftar ini biasanya pendek dan selalu bernilai. Minggu 7 sampai 12: Perbaiki temuan yang paling sering berulang di sumbernya di IaC, tambahkan guardrail untuk kategori yang ingin dicegah sepenuhnya, dan jalankan sesi edukasi engineering pertama memakai temuan Anda sendiri. Organisasi yang lolos dari insiden cloud jarang yang paling banyak tooling. Mereka yang engineernya paham arti tiap pengaturan, dan pipeline mereka menjadikan pilihan aman sebagai default.\nTidak yakin akun cloud Anda sedang mengekspos apa hari ini? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Ingin sudut pandang dari pihak luar? Configuration \u0026amp; Architecture Assessment kami meninjau estate cloud Anda terhadap benchmark CIS dan niat arsitektur Anda sendiri, atau schedule an Engineering \u0026amp; Scoping Session untuk merencanakan urutan remediasi bersama tim Anda.\n","date":"16 April 2025","permalink":"https://puresecurity.com/id/posts/cloud-misconfiguration-security-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Cloud Misconfiguration: Risiko yang Bersembunyi di APAC"},{"content":"","date":null,"permalink":"https://puresecurity.com/id/tags/cloud-security/","section":"Tags","summary":"","title":"Cloud Security"},{"content":"Setiap anggaran keamanan akhirnya bertemu pertanyaan yang sama dari finance: kenapa kita mengeluarkan segini untuk pencegahan padahal tidak terjadi apa-apa? Pertanyaan yang wajar, dan layak jawaban bernomor. Cara menjawabnya secara jujur adalah memberi harga pada alternatifnya, karena di seluruh Southeast Asia biaya data breach sudah bukan hal abstrak. Ia tertulis dalam undang-undang, jadwal penalti regulator, dan aturan card brand yang langsung berlaku bagi bisnis di Bangkok, Singapura, Kuala Lumpur, dan seterusnya.\nKetika dua kolom itu diletakkan bersebelahan, kesimpulannya konsisten: perlindungan hanya berbiaya sebagian kecil dari insiden, bahkan sebelum menghitung kerugian yang tak akan pernah muncul di invoice mana pun.\nRegulator menetapkan lantai, bukan plafon #Rezim perlindungan data di kawasan ini matang dengan cepat, dan masing-masing kini punya taring:\nYurisdiksi Rezim Eksposur maksimum Thailand PDPA Denda administratif hingga THB 5 juta, plus liabiliti pidana untuk pelanggaran data sensitif Singapura PDPA Penalti hingga 10% pendapatan tahunan di Singapura bagi organisasi dengan omzet lokal di atas SGD 10 juta Malaysia Personal Data Protection (Amendment) Act 2024 Denda lebih tinggi dan pidana penjara atas kegagalan notifikasi breach; kewajiban langsung diperluas ke data processor Indonesia UU PDP No. 27 Tahun 2022 Denda administratif hingga 2% pendapatan tahunan, plus pemusnahan data yang diproses ilegal Australia Amandemen Privacy Act Penalti hingga AUD 50 juta, tiga kali manfaat yang diperoleh, atau 30% turnover disesuaikan Filipina Data Privacy Act 2012 Denda hingga PHP 5 juta per pelanggaran, dengan penjara bagi pejabat yang bertanggung jawab Tiga hal tentang tabel ini lebih penting daripada angkanya sendiri.\nPertama, ini angka maksimum, dan regulator membuktikan mereka mau memakainya. PDPC Singapura menerbitkan setiap putusan penegakan, termasuk penalti enam dan tujuh digit bagi organisasi yang gagal langkah dasar seperti dua faktor autentikasi pada akun admin. PDPC Thailand mulai mengeluarkan perintah koreksi. Pola seluruh kawasan hanya satu arah: naik.\nKedua, amendment act Malaysia adalah pergeseran struktural, bukan sekadar ganti angka. Notifikasi breach yang wajib, kewajiban statutory langsung bagi processor, dan pengangkatan DPO yang diwajibkan berarti vendor dan penyedia layanan kini menanggung liabilitasnya sendiri. Jika Anda menjual layanan ke Malaysia, atau membelinya dari provider yang begitu, kontrak Anda terdampak.\nKetiga, model Indonesia yang menghitung persentase pendapatan berarti dendanya ikut skala kesuksesan Anda. Bagi bisnis Indonesia yang sedang tumbuh, breach lima tahun lagi bisa jauh lebih mahal daripada breach yang sama hari ini.\nDenda jarang jadi item terbesar #Eksekutif sering berlabuh pada penalti regulasi karena ia publik dan bisa dikutip. Praktiknya, organisasi yang pernah melalui insiden melaporkan bahwa semua di sekitar denda justru lebih mahal:\nInvestigasi dan respons. Forensic investigator, pengacara darurat, dan incident response eksternal tidak murah, dan mereka menagih dengan tarif krisis di bawah tekanan waktu. Persis inilah belanja yang DFIR retainer ubah dari harga panik menjadi relasi yang direncanakan.\nNotifikasi berskala besar. Undang-undang notifikasi breach di kawasan ini mewajibkan menghubungi individu terdampak dalam tenggat tetap. Untuk basis pelanggan ratusan ribu, itu call centre, surat keluar, tawaran credit monitoring, semuanya dikirim saat tim Anda masih memulihkan layanan.\nGangguan operasi. Sistem yang dimatikan saat containment tidak menghasilkan pendapatan. Insiden ransomware secara rutin mematikan operasi berhari-hari sampai berminggu-minggu, dan biaya pemulihan, infrastruktur yang dibangun ulang, overtime, hardware darurat, mendarat jauh sebelum regulator mana pun mengeluarkan putusan.\nChurn pelanggan dan partner. Laporan Cost of a Data Breach IBM menelusuri ini bertahun-tahun: sebagian besar biaya breach muncul dalam satu sampai dua tahun setelah insiden, didorong bisnis hilang saat pelanggan pindah ke kompetitor. Studi regional konsisten menemukan organisasi emerging market butuh lebih lama untuk mengidentifikasi dan menahan breach, yang mendongkrak biayanya.\nKonsekuensi kontraktual. Pelanggan enterprise semakin banyak menyematkan klausa keamanan dengan hak audit dan trigger terminasi. Satu breach sama saja menyerahkan keputusan yang Anda harap tak pernah harus mereka buat.\nPCI DSS: regulator swasta dengan penalti nyata #Jika organisasi Anda memegang cardholder data, ada lapisan penegakan kedua di atas regulator privasi. Card brand tidak mendenda merchant langsung: mereka menilai penalti kepada acquiring bank, yang diturunkan lewat merchant agreement. Angka yang lazim dilaporkan berkisar ribuan sampai ratusan ribu dolar per bulan untuk non-compliance yang berlanjut, meningkat hingga pencabutan hak menerima kartu bagi organisasi yang mengalami breach sementara tidak compliant.\nHilangnya kemampuan menerima kartu bukanlah sebuah denda. Bagi banyak bisnis ritel dan hospitality di kawasan ini, itu peristiwa eksistensial. Itulah justifikasi bisnis melakukan scope reduction dan gap assessment PCI DSS secara benar alih-alih memperlakukannya sebagai pekerjaan administratif: biaya assessment adalah pecahan dibanding eksposur yang ditutupnya.\nMeletakkan angka berdampingan #Bayangkan fintech Thailand ukuran menengah, 200 staf, memproses pembayaran, menyimpan record KYC pelanggan:\nPencegahan (annualised): waktu satu security engineer paruh waktu, DFIR retainer, vulnerability scanning dan disiplin patching, tabletop exercise setahun sekali, serta penilaian berkala terhadap persyaratan PDPA dan PCI DSS. Untuk organisasi sebesar itu, totalnya biasanya jatuh di kisaran ratusan juta rupiah setahun.\nSatu breach: denda administratif maksimum THB 5 juta, berminggu-minggu forensik dan biaya hukum, biaya notifikasi ke seluruh basis pelanggan, pelanggan enterprise yang menggunakan klausa terminasi, dan kepercayaan komersial yang dibangun ulang berbulan-bulan dan tidak pernah kembali penuh.\nAnda tidak butuh presisi untuk melihat bentuk perbandingannya. Pencegahan itu subscription; breach itu lawsuit dengan bunga. Sekalipun probabilitas insiden dalam satu tahun tertentu rendah, asimetri antara dua kolom membuat argumen expected value sudah cukup jelas.\nApa yang benar-benar menurunkan biaya #Belanja keamanan tidak semuanya sama-sama efektif menekan biaya breach. Riset industri yang sama terus mengidentifikasi daftar pendek kontrol berdampak terukur:\nDeteksi dan containment yang cepat. Setiap hari antara compromise dan containment menambah biaya. Monitoring dengan jalur eskalasi yang sudah diuji adalah investasi leverage tertinggi. Rencana respons yang sudah dilatih. Organisasi yang sudah rehearse 48 jam pertamanya membuat keputusan lebih baik daripada yang memutuskan real time. Sebuah cyber crisis tabletop exercise menemukan celah saat masih gratis diperbaiki. Jejak data yang lebih kecil. Yang tidak Anda pegang tidak bisa bocor. Batas retensi dan enkripsi mengecilkan kemungkinan breach sekaligus blast radius-nya. Segmentasi dan least privilege. Insiden yang tertahan lebih murah daripada yang menyebar; itulah kenapa kami terus kembali ke network segmentation sebagai kontrol yang menurunkan risiko sekaligus biaya remediasi. Tak satu pun butuh teknologi eksotis. Semua butuh perhatian engineering, diterapkan konsisten, dimulai sebelum insiden, bukan sesudahnya.\nIngin pandangan realistis soal eksposur organisasi Anda versus biaya menutupnya? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Layanan Regulatory Compliance kami memetakan kewajiban Anda di bawah PDPA, PCI DSS dan framework regional, vCISO advisory membantu membangun business case untuk belanja yang terukur menurunkan biaya insiden. Atau schedule an Engineering \u0026amp; Scoping Session dan kita olah angkanya bersama tim Anda.\n","date":"19 Maret 2025","permalink":"https://puresecurity.com/id/posts/data-breach-cost-southeast-asia/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Biaya Sebenarnya Data Breach di Southeast Asia"},{"content":"Setiap organisasi yang menangani pembayaran di Southeast Asia cepat atau lambat bertemu kedua framework ini, sering kali dalam kuartal yang sama. Bank meminta sertifikat ISO 27001 saat vendor onboarding. Acquiring bank Anda meminta bukti kepatuhan PCI DSS di waktu bersamaan. Dua percakapan itu terdengar mirip, sama-sama melibatkan auditor, kontrol, dan siklus tahunan, jadi menganggapnya saling menggantikan memang menggoda.\nTidak. Memahami bedanya penting, karena memperlakukan salah satunya sebagai pengganti yang lain berarti baik membayar sertifikasi yang tak diperlukan, atau terpapar penalti dari card brand. Artikel ini menjelaskan apa yang masing-masing framework sebenarnya syaratkan, di mana mereka tumpang-tindih, dan kenapa menjalankan keduanya bersama lebih murah daripada terpisah.\nISO 27001: framework tata kelola untuk mengelola keamanan informasi #ISO/IEC 27001 mendefinisikan bagaimana organisasi mengelola keamanan informasi, apa pun bisnisnya. Intinya adalah information security management system (ISMS): siklus penilaian risiko, pemilihan kontrol, operasi, pengukuran, dan perbaikan yang terdokumentasi.\nDua karakteristik mendefinisikannya:\nBerbasis risiko. Standarnya tidak memberi tahu firewall merek apa yang harus dibeli atau seberapa sering patch. Ia mensyaratkan Anda mengidentifikasi risiko, memilih kontrol dari katalog Annex A (dan di luarnya) untuk menghadapinya, dan memjustifikasi setiap keputusan. Dua organisasi bisa sama-sama memegang sertifikat valid sambil menjalankan set kontrol yang sangat berbeda, karena risiko mereka berbeda.\nDisertifikasi badan akreditasi. Sertifikasi diterbitkan certification body terakreditasi setelah audit Stage 1 dan Stage 2. Setelah tersertifikasi, Anda masuk siklus tiga tahun dengan surveillance audit tahunan, lalu rekam medis ulang. Sertifikatnya diakui internasional; itulah alasan tim procurement menyukainya: satu PDF menjawab puluhan baris kuesioner vendor risk.\nHarga dari fleksibilitas itu adalah abstraksi. Sertifikat ISO 27001 memberi tahu partner bahwa Anda mengelola keamanan secara sistematis. Ia tidak memberi tahu bahwa ada langkah teknis spesifik tertentu pada tingkat yang ditentukan.\nPCI DSS: persyaratan operasional preskriptif untuk data kartu #PCI DSS hadir untuk satu tujuan: melindungi data kartu pembayaran. Card brand (Visa, Mastercard, Amex, JCB, UnionPay, dll.) menerbitkannya lewat PCI Security Standards Council, dan kepatuhannya ditegakkan secara kontraktual lewat acquiring bank dan payment processor.\nKarakternya hampir sepenuhnya berlawanan dengan ISO 27001:\nPreskriptif. Versi saat ini v4.x merinci persyaratan konkret dalam dua belas keluarga: network security control, konfigurasi sistem aman, perlindungan stored account data, enkripsi transit di jaringan publik, pertahanan malware, access control, keamanan fisik, logging dan monitoring, serta pengujian keamanan berkala. Di mana ISO berkata \u0026ldquo;kelola risiko akses tidak sah\u0026rdquo;, PCI berkata hal seperti \u0026ldquo;render all systems untrusted for authentication at 15 minutes of inactivity\u0026rdquo; lengkap dengan interval pengujian yang eksplisit.\nScopenya terikat cardholder data environment (CDE). Semuanya dimulai dari memetakan di mana data kartu hidup, mengalir, dan tersambung. Sistem yang tersambung ke CDE masuk scope; sistem yang disegmentasi dengan benar bisa saja tidak. Scope reduction karena itulah aktivitas bernilai tertinggi dalam sebagian besar program PCI: semakin sedikit sistem dalam scope, semakin sedikit bukti, jam assessment, dan biaya berjalan.\nValidasi tahunan dan bergantung peran. Bergantung volume transaksi dan aturan card brand, validasi lewat Report on Compliance (ROC) yang ditandatangani Qualified Security Assessor, atau lewat Self-Assessment Questionnaire didukung quarterly ASV vulnerability scan. Tidak ada \u0026ldquo;sertifikat\u0026rdquo; dalam arti ISO: ada attestation of compliance yang terikat satu titik waktu.\nBerdampingan # Dimensi ISO 27001 PCI DSS Tujuan Mengelola risiko keamanan informasi seluruh organisasi Melindungi data kartu pembayaran spesifik Pendekatan Berbasis risiko, pemilihan kontrol dijustifikasi Preskriptif, persyaratan teknis dan proses eksplisit Berlaku bagi Organisasi apa pun, jenis data apa pun Entitas yang menyimpan, memproses, atau mentransmisikan data kartu Validasi Sertifikat dari badan terakreditasi, siklus 3 tahun + surveillance audit ROC atau SAQ tahunan, scan kuartalan, ditegakkan lewat kontrak acquirer Scope Seluruh ISMS, batas ditentukan organisasi Cardholder data environment, ditentukan aliran data Konsekuensi gagal Kehilangan sertifikat, kerugian kontrak Denda lewat acquiring bank, hilang hak menerima kartu Titik tumpangnya #Meski filosofinya berbeda, porsi besar pekerjaan dasarnya sama. Kedua framework mensyaratkan:\nAccess control least privilege dan identifikasi unik Enkripsi data sensitif saat transit, dan rahasia saat disimpan Logging, monitoring, dan sinkronisasi waktu Manajemen kerentanan dan disiplin patching Segmentasi lingkungan sensitif Kesadaran keamanan dan kebijakan tertulis dengan siklus review Perencanaan respons insiden dan pengujian Dalam praktik, kontrol yang dibangun baik sekali biasanya memuaskan kedua auditor, asalkan Anda sengaja memetakannya. Yang kesulitan adalah organisasi yang membangun kontrol dua kali, sekali per auditor, karena tak ada yang merawat pemetaan antar framework.\nCara praktis menjalankan keduanya #Untuk fintech Thailand atau bisnis regional mana pun yang menerima kartu sambil mengejar klien enterprise, urutan yang bekerja:\nJadikan ISO 27001 anchor tata kelola. Bangun ISMS, risk register, set kebijakan, dan ritme management review. Itu menjadi sistem operasi untuk segala hal lain. Overlay PCI DSS pada CDE. Petakan scope dengan ketat, terapkan persyaratan preskriptif di dalam batas itu, dan dokumentasikan pemetaan tiap persyaratan PCI balik ke kontrol ISMS. Bagikan pipeline bukti. Satu platform logging, satu proses vulnerability management, satu kalender access review yang menyuplai kedua program. Assessment kemudian menjadi latihan verifikasi, bukan proyek. Atur kedua kalender. Surveillance audit ISO dan annual attestation PCI bisa jatuh di titik berbeda dalam setahun jika direncanakan; gunakan jaraknya untuk memperbaiki temuan dari satu sebelum yang lain datang. Dibuat begini, marginal cost menambahkan PCI DSS di atas program ISO 27001 yang sudah ada (atau sebaliknya) jauh di bawah biaya membangun salah satunya dari nol. Dilakukan buruk? Anda bayar dua kali dan tetap ada gap.\nJadi mana yang Anda butuhkan? #Tanyakan dua hal. Apakah Anda menyentuh payment card data? Maka PCI DSS berlaku, titik: itu bukan opsional, dan acquirer Anda akan menegaskannya secara tertulis di momen paling tidak nyaman. Apakah pelanggan enterprise, bank, atau regulator mengharapkan governance keamanan yang bisa dibuktikan? Maka ISO 27001 menghapus satu kategori gesekan procurement.\nMayoritas organisasi industri pembayaran akhirnya butuh keduanya. Kabar baiknya mereka saling menguatkan: ISO memberi disiplin manajemen, PCI memberi kedalaman operasional tepat di tempat uang bergerak.\nMasih belum pasti butuh ISO, PCI, atau keduanya, dan scope aslinya sampai mana? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Sebagai praktik QSA aktif, kami menyediakan gap assessment dan QSA audit PCI DSS bersama advisory compliance regulasi, termasuk mapping program gabungan agar Anda memenuhi kedua framework dari satu set kontrol. Atau schedule an Engineering \u0026amp; Scoping Session untuk membahas situasi spesifik Anda.\n","date":"19 Februari 2025","permalink":"https://puresecurity.com/id/posts/iso-27001-vs-pci-dss/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"ISO 27001 vs PCI DSS: Bisnis Anda Butuh yang Mana?"},{"content":"Kalau saya boleh memilih tepat satu perubahan arsitektur untuk organisasi yang ingin menurunkan risiko breach sekaligus biaya keamanannya, itu bukan produk atau platform baru. Itu network segmentation. Tak ada kontrol lain yang saya kenal menurunkan dua masalah termahal Anda dengan anggaran yang sama.\nSebabnya sederhana. Hampir setiap masalah keamanan mahal berakar pada satu hal sama: jaringan datar membuat masalah kecil tumbuh menjadi besar. Segmentasi memutus hubungan itu. Ia menahan apa yang bisa dijangkau penyerang setelah kesalahan pertama, mengecilkan sistem yang diperhatikan framework compliance Anda, dan mengubah sprawl yang tak terkelola menjadi sesuatu yang tim kecil benar-benar bisa dipahami.\nKenapa jaringan datar gagal secara senyap #Jaringan datar adalah jaringan tempat mayoritas sistem bisa bicara dengan mayoritas sistem lain. Itu kondisi default jaringan, karena kerataan itu nyaman: tidak perlu negosiasi firewall rule saat server baru butuh database, tidak ada yang perlu di-update saat laptop developer butuh test system.\nHarganya datang kemudian. Lihat bagaimana intrusi nyata berlangsung. Foothold awal biasanya kecil: credential yang ter-phish di satu laptop, appliance VPN bermasalah, server ujian yang terlupakan dengan port manajemen menghadap internet. Berdiri sendiri, foothold itu bernilai sedikit. Yang membuat breach mahal adalah lateral movement: dari mesin pertama yang dikompromikan, penyerang menjelajah jaringan, memanen credential, mencapai server yang tak seharusnya terjangkau dari perangkat pengguna, dan meningkat hingga memegang sesuatu berharga.\nJaringan datar membuat setiap langkah perjalanan itu gratis. Jaringan tersgmentasi membuat setiap langkah menghabiskan usaha, waktu, dan kebisingan yang tampak oleh penyerang. Penetration tester akan bilang bedanya dramatis: di environment datar, kami secara rutin bergerak dari satu laptop ke kompromi seluruh domain dalam hitungan hari; melawan segmentasi yang dirancang baik, engagement yang sama macet di hop pertama dan tetap di sana.\nApa yang dibelikan segmentation #1. Membatasi dampak breach awal #Ketika zona dipisahkan batas yang benar-benar ditegakkan, kompromi satu workstation tidak memberi akses ke sistem pembayaran, domain controller, atau kontrol industri. Penyerang memegang satu segmen, bukan bisnis. Itulah bedanya antara insiden yang pulih dalam satu sore dengan pengumuman breach.\n2. Menghentikan lateral movement #Trafik timur-barat antar workload semestinya jarang, punya tujuan, dan teramati. Di kebanyakan environment ia bukan ketiga-tiganya. Segmentasi membuat penyerang yang mendarat menabrak jalan buntu alih-alih koridor terbuka, dan jalur yang memang harus ada cukup sempit untuk dimonitor.\n3. Mengecilkan scope compliance #Di sinilah pengurangan biaya menjadi konkret. PCI DSS berlaku untuk cardholder data environment (CDE) beserta semua yang tersambung dengannya. Dengan segmentasi yang benar dan diverifikasi lewat penetration testing, CDE mungkin hanya segelintir sistem, bukan ratusan. Lebih sedikit sistem dalam scope berarti lebih sedikit pengumpulan bukti, jam assessment, validasi tahunan yang lebih murah, dan permukaan yang harus di-patch dan dimonitor lebih kecil. Logika yang sama juga menguntungkan risk treatment ISO 27001 dan percakapan regulator soal containment.\nKami pernah melihat effort assessment berkurang separuh semata-mata karena klien menyelesaikan proyek segmentasinya lebih dulu. Biaya pekerjaan segmentasi biasanya lebih murah daripada satu tahun penghematan assessment yang diciptakannya.\n4. Menjadikan jaringan bisa dikelola #Manfaat yang paling jarang dihargai: jaringan yang tersgmentasi adalah jaringan yang bisa diketahui. Ketika aliran trafik dibatasi pada jalur yang terdokumentasi, anomali langsung menonjol. Workload yang tiba-tiba menyentuh database yang tak pernah ia ajak bicara adalah insiden atau salah konfigurasi, dan keduanya layak diperhatikan. Di jaringan datar, sinyal yang sama tenggelam dalam noise, karena semua bicara dengan semua sepanjang waktu. Segmentasilah yang membuat monitoring bermakna.\nPrinsip desain yang bertahan #Segmentasi yang baik adalah arsitektur, bukan belanja appliance. Prinsip yang penting:\nMulai dari data, bukan kotak. Identifikasi di mana data sensitif hidup dan mengalir: data kartu, credential, informasi pribadi, catatan finansial. Zona terbentuk dari apa yang perlu dilindungi, bukan diagram tahun lalu.\nDefinisikan tier berdasarkan trust dan fungsi. Baseline praktis bagi kebanyakan organisasi:\ngraph TD I[Internet] --\u003e DMZ[DMZ / edge services] U[User networks] --\u003e APP[Application tier] DMZ --\u003e APP APP --\u003e DB[(Data tier:\ndatabases, CDE, secrets)] MGMT[Management network] -.-\u003e|admin access only| APP MGMT -.-\u003e DB U -.-\u003e|no direct access| DB style DB stroke:#EF4444,stroke-width:2px style MGMT stroke:#0EA5E9,stroke-width:2px Layanan yang menghadap internet, perangkat pengguna, application tier, data tier, dan management network out-of-band. Setiap batas punya allow-list eksplisit; sisanya ditolak.\nDefault deny, lalu tambahkan dengan sengaja. Setiap aliran lintas zona yang diizinkan harus punya pemilik dan alasan tertulis. Kalau tak ada yang bisa menjelaskan kenapa sebuah rule ada, itu finding yang menunggu dieksploitasi.\nSegmentasi juga di dalam cloud. Security group, VPC, dan service policy adalah segmentasi; platform cloud hanya menerapkannya dengan cara berbeda. Disiplinnya sama: production terpisah dari non-production, database tak terjangkau dari internet, admin plane di jalur terpisah.\nUji segmennya, jangan asumsikan. Segmentasi hanya dihitung jika bertahan di bawah serangan. Untuk PCI DSS khususnya, standarnya mensyaratkan penetration testing yang memverifikasi isolasi minimal tahunan dan setelah perubahan besar. Penetration test yang mencoba lateral movement dari setiap zona memberi tahu apakah desain Anda bekerja atau sekadar bagus di atas kertas.\nJalur realistis menuju sana #Tidak ada yang membangun ulang live network dalam satu akhir pekan. Urutan yang bekerja:\nDiscover. Petakan aliran trafik nyata selama beberapa minggu. Jaringan nyata selalu berbeda dari dokumennya. Declare. Definisikan zona target dan tuliskan aliran yang harus melintasi tiap batas. Dapatkan persetujuan bisnis atas daftar itu. Pagar mahkota dulu. Sistem pembayaran, infrastruktur domain, dan penyimpanan data sensitif didahulukan sebelum apa pun kosmetik. Migrasi bertahap. Pindahkan sistem ke dalam zona bergelombang, mulai dari yang menghadap internet. Perbaiki kerusakan di area berisiko rendah selama pelajarannya masih murah. Verifikasi dan rawat. Uji batas tahunan, review rule kuartalan, perlakukan setiap aliran lintas zona tanpa dokumentasi sebagai insiden sampai terbukti sebaliknya. Mayoritas organisasi mencapai baseline yang defensible dalam satu-dua kuartal kerja konsisten, dan fase-fase awal membayar dirinya sendiri lewat scope audit yang mengecil.\nIntinya #Belanja keamanan biasanya melibatkan trade-off: turunkan risiko atau turunkan biaya. Network segmentation adalah pengecualian tetap. Ia menutup kerugian percobaan breach yang berhasil, membuat penyerang kelaparan dari lateral movement yang membuat insiden mahal, mengecilkan scope setiap framework yang Anda jawab, dan menghasilkan jaringan yang bisa dipikulkan tim Anda. Tempat kedua tidak layak diperdebatkan.\nPenasaran jaringan Anda saat ini akan menahan intrusi atau menyebarkannya? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Configuration \u0026amp; Architecture Assessment kami memetakan aliran trafik nyata dan mendesain roadmap segmentasi yang bisa dieksekusi tim, penetration testing kami memverifikasi segmentasi benar-benar bertahan. Atau schedule an Engineering \u0026amp; Scoping Session untuk membahas titik awalnya.\n","date":"15 Januari 2025","permalink":"https://puresecurity.com/id/posts/network-segmentation-design/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Desain Network Segmentation: Turunkan Risiko dan Biaya Sekaligus"},{"content":"Anggota board mengajukan pertanyaan yang wajar saat menerima laporan keamanan kuartalan: apa yang harus saya lakukan dengan ini? Terlalu sering jawaban jujurnya adalah: tidak ada. Laporannya berisi jumlah email yang diblokir, persentase penyelesaian pelatihan, dan satu slide lanskap ancaman hasil daur ulang materi vendor. Itu pelaporan aktivitas, bukan jaminan, dan meninggalkan direksi tepat di posisi awal: tak bisa menilai apakah organisasi tangguh atau sekadar sibuk.\nMetrik yang menggerakkan jarum bagi board berbagi satu sifat. Mereka mengukur kemampuan di bawah tekanan, bukan usaha yang dikeluarkan. Board tidak perlu tahu berapa banyak email phishing difilter bulan lalu. Yang perlu mereka tahu adalah: kalau ransomware mendarat besok, apakah bisnis bertahan minggu ini.\nKenapa sebagian besar pelaporan keamanan gagal #Tim keamanan biasanya melaporkan apa yang alat mereka hitung, karena itu paling mudah diekstrak. Hasilnya dashboard penuh angka yang terus naik tanpa makna:\nAncaman yang diblokir. Angka yang lebih besar lebih banyak berarti Anda menerima spam lebih banyak. Setiap platform email memblokir jutaan pesan; pertanyaan menariknya adalah apa yang lolos, dan tak ada alat yang menghitungnya dengan jujur. Persentase penyelesaian pelatihan. Penyelesaian mengukur kehadiran, bukan perilaku. Organisasi dengan 100% penyelesaian tetap bisa gagal uji social engineering nyata pekan berikutnya. Hitungan kerentanan dalam ribuan. Hitungan mentah tanpa konteks eksposur tak bermakna. Sepuluh ribu temuan low severity di sistem ujian internal kurang penting daripada dua critical di infrastruktur pembayaran yang menghadap internet. Volume alert. Lebih banyak alert berarti lebih banyak noise, bukan lebih aman. Volume tinggi dengan triage lambat justru menunjukkan lawan dari kesiapan. Tak satu pun menjawab pertanyaan fidusiari direktur: apa kami siap, dan bagaimana kami tahu?\nBagaimana resiliensi tampak sebagai angka #Board mengelola outcome: kontinuitas, eksposur hukum, reputasi. Metrik yang layak memakan waktu board mengukur itu secara langsung.\nKecepatan deteksi dan respons #Berapa lama antara compromise dan containment? Mean time to detect (MTTD) dan mean time to respond (MTTR), diukur dari insiden nyata dan skenario latihan, adalah yang paling mendekati tanda vital keamanan. Riset industri konsisten mengaitkan biaya breach dengan kecepatan containment: organisasi yang menahan dalam beberapa minggu membayar jauh lebih sedikit daripada yang butuh beberapa bulan. Kalau angka ini tidak diketahui, ketidaktahuannya sendiri itulah finding untuk board.\nBukti pemulihan #Backup yang belum pernah dipulihkan adalah harapan, bukan kontrol. Metrik yang penting: kapan terakhir kita memulihkan satu layanan production penuh dari backup, dan berapa lama? Tambahkan cakupan immutable backup untuk sistem yang pertama disasar ransomware. Satu restore teruji dalam recovery time objective yang disepakati bernilai lebih bagi direktur daripada statistik ancaman apa pun, karena itu bukti langsung bahwa bisnis selamat dari serangan destruktif.\nRehearsal dan temuannya #Kapan terakhir tim eksekutif melatih krisis siber, dan celah apa yang terekspos? Tabletop exercise menghasilkan temuan: otoritas pengambilan keputusan yang hilang, vendor yang tak bisa dihubungi, kepemilikan komunikasi pelanggan yang kabur. Lacak seperti audit finding: teridentifikasi, ditugaskan, ditutup. Board yang melihat temuan latihan tertutup sesuai jadual tahu organisasinya belajar lebih cepat daripada evolusi penyerang.\nEksposur yang benar-benar penting #Ganti hitungan kerentanan dengan metrik eksposur terkait konsekuensi:\nKerentanan critical/high pada sistem berhadapan internet, dipatch dalam SLA: persentase dan tren. Usia critical tertua yang belum dipatch pada sistem mana pun yang berhubungan dengan pendapatan. Persentase akun privileged yang dicakup MFA dan just-in-time access. Angka-angka ini tersambung langsung ke kemungkinan breach, yang tersambung ke headline yang sedang dikelola direksi.\nEksposur pihak ketiga #Bagi banyak organisasi, breach berikutnya datang lewat vendor. Board semestinya melihat: berapa supplier kritikal yang sudah dinilai, berapa penilaian yang lewat tenggat, dan adakah klausul notifikasi insiden kontraktual dengan setiap provider kritikal. Ini memetakan bersih ke governance vendor-risk yang sudah dipahami direksi.\nMenjaga bisnis keluar dari berita #Direksi kerja menggambarkan tujuan keamanan secara lugas: jangan menjadi kisah breach berikutnya. Tujuan itu terurai menjadi komponen terukur, tanpa satu pun perlu kefasihan teknis untuk ditafsir:\nOutcome yang pedulikan board Metrik yang membuktikannya Intrusi akan terdeteksi cepat Tren MTTD; coverage monitoring sistem kritikal Akan ditahan sebelum kerusakan besar Tren MTTR; lateral movement berhasil ditahan dalam tes Bertahan ransomware Waktu restore teruji vs RTO; cakupan immutable backup Memenuhi kewajiban hukum Prosedur notifikasi breach terlatih; obligasi regulator terpetakan Partner percaya Penilaian vendor kritikal masih berlaku; attestation framework valid Laporan kuartalan yang hanya memuat tabel ini, lengkap tren dan pengecualiannya, memberi board jaminan sungguhan melebihi empat puluh slide statistik alat.\nCara mendapat angka yang jujur #Metrik ini mensyaratkan kejujuran engineering, sebagian alasan ia langka:\nUkur lewat latihan, bukan asumsi. Waktu restore datang dari restore nyata. Waktu respons datang dari intrusi simulasi. Kalau tak ada yang pernah menjalankan tesnya, laporkan \u0026ldquo;belum diketahui\u0026rdquo;, dan ketidaktahuannya sendiri adalah informasi yang actionable untuk board. Laporkan tren, bukan snapshot. Nilai tunggal mengundang rekayasa; lintasan yang menunjukkan program membaik atau tidak. Pasangkan setiap angka merah dengan permintaan keputusan. Board mengelola dengan mengalokasikan resource. \u0026ldquo;Restore testing gagal mencapai RTO; kami butuh dua engineer enam minggu\u0026rdquo; adalah kalimat governance. \u0026ldquo;Risiko tetap tinggi\u0026rdquo; bukan. Singkat saja. Satu halaman metrik dengan tren, satu halaman keputusan yang diminta. Kalau paketnya butuh pre-briefing, terlalu rumit. Organisasi yang mengadopsi gaya pelaporan ini biasanya menemukan hal berguna: percakapan bergeser dari \u0026ldquo;apakah IT cukup belanja?\u0026rdquo; menjadi pertanyaan spesifik yang bisa diputuskan soal recovery objective, staffing, dan risiko pihak ketiga. Pergeseran itulah yang seharusnya dirasakan governance.\nIngin membangun ulang paket board Anda dengan metrik yang benar-benar membuktikan resiliensi? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). vCISO advisory kami membangun pelaporan level board yang bisa ditindaklanjuti, cyber crisis tabletop exercise menghasilkan temuan latihan yang membuat laporan itu jujur. Atau schedule an Engineering \u0026amp; Scoping Session untuk memulai percakapan.\n","date":"18 Desember 2024","permalink":"https://puresecurity.com/id/posts/board-security-metrics/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Security Metrics yang Board Sebenarnya Butuhkan"},{"content":"Ransomware bukan tren yang akan lewat. Ia sebuah industri, dan menguntungkan: kelompok kriminal menjalankannya dengan tim sales, program afiliasi, meja support, dan bagi hasil yang dinegosiasikan. Mereka berinvestasi dalam kemampuan karena itu andal membuahkan uang, yang berarti mereka investasi ulang, merekrut developer berbakat, dan beradaptasi lebih cepat daripada kebanyakan defender memperbarui apa pun. Pencegahan penting, tetapi titik mulai yang jujur adalah ini: anggap suatu hari nanti, meski sudah melakukan segalanya, payload enkripsi tetap berjalan di sistem Anda. Kesiapan adalah apa yang terjadi setelah asumsi itu.\nArtikel ini membahas kedua sisi realita tersebut: kenapa ransomware begitu sulit dihentikan total, dan seperti apa kesiapan sesungguhnya di lingkungan modern yang terhubung cloud, termasuk strategi backup yang bisa disentuh penyerang tapi tak bisa dimusnahkan.\nKenapa ransomware begitu sulit dihentikan #Ransomware awal bersifat oportunistik: enkripsi semua yang terjangkau mesin terinfeksi, minta beberapa ratus dolar. Model modern bersifat terarah dan sabar. Kelompok mendapat akses lewat phishing, remote access terekspos, atau credential yang dibeli, lalu menghabiskan hari hingga berminggu-minggu bergerak masuk diam-diam, meningkatkan hak istimewa, memetakan backup, dan mengekfiltrasi data sebelum memicu apa pun yang tampak.\nEvolusi itu menciptakan dua masalah yang tidak bisa diselesaikan defender dengan sekadar membeli:\nDouble extortion mencabut pintu darurat backup. Memulihkan dari backup dulu bisa mengakhiri krisis. Sekarang data curian dipublikasikan atau dijual jika Anda menolak membayar, sehingga walau restore bersih, Anda masih menghadapi data breach, kewajiban notifikasi di bawah PDPA dan padanannya, serta paparan publik. Backup perlu; tapi tak lagi cukup.\nFoothold awal hanya butuh berhasil sekali. Defender harus menang melawan setiap email phishing, setiap appliance yang belum di-patch, setiap kebocoran credential, setiap koneksi pihak ketiga. Penyerang hanya butuh satu kesuksesan pada satu hari Selasa. Asimetri semacam ini tidak berbalut memenangkan pembela hanya dengan harapan.\nIni bukan berarti pertahanan sia-sia; ia mengubah peluang terkena. Tapi ia tidak mengubah hasil setelahnya. Hanya persiapan yang mengubah itu.\nBagaimana rasanya sebenarnya #Board cenderung membayangkan ransomware sebagai peristiwa teknis. Organisasi yang pernah mengalaminya menggambarkan lebih dekat ke bencana alam dengan faktur:\nDowntime berminggu-minggu. Bahkan organisasi yang menolak bayar dengan backup baik rutin butuh waktu berminggu untuk memulihkan layanan production sepenuhnya, karena rebuild harus diurutkan, divalidasi, dan lebih lambat dari rencana siapa pun. Biaya datang dari semua arah sekaligus. Forensik dan incident response dengan tarif krisis, pengacara darurat, overtime lintas IT dan operasi, hardware dibangun ulang, pendapatan hilang bertambah tiap hari, dan kemudian investigasi regulator di atasnya. Keputusan di bawah tekanan tanpa otoritas. Siapa memutuskan membayar atau tidak? Siapa memberi tahu staf? Siapa bicara dengan pelanggan, regulator, jurnalis? Perusahaan yang tak pernah melatih pertanyaan-pertanyaan itu menjawabnya buruk, lambat, dan sering secara publik. Ekor panjang ketidakpercayaan. Pelanggan churn, kontrak enterprise diaktifkan klausulnya, dan insiden muncul kembali di setiap percakapan procurement selama bertahun-tahun. Memahami bentuk ini penting karena setiap langkah persiapan di bawah langsung memetakan ke pengurangan salah satu biaya ini.\nImmutable backup: kontrol yang mengubah hasil #Kalau ada satu investasi teknis yang mengubah ransomware dari bencana menjadi minggu buruk, itu backup yang tak bisa diubah atau dihapus penyerang. Backup tradisional gagal tepat di sini karena reachable: penyerang dengan domain credential secara rutin menghapus atau mengenkripsi backup job dulu, baru memicu peristiwa utama terhadap organisasi yang tak tersisa apa-apa.\nObject storage modern menyelesaikannya dengan immutability:\nObject Lock / WORM storage menulis backup dalam bentuk yang tak bisa diubah maupun dihapus selama masa retensi, oleh siapa pun, termasuk admin Anda sendiri. AWS S3 Object Lock, Azure immutable blob storage, dan produk serupa di cloud lain semuanya menerapkan pola ini. Masa retensi menciptakan jendela bertahan. Atur window immutability agar versi-versi sebelum akses penyerang bertahan sampai lock kadaluarsa. Di sinilah detail desain spesifik cloud-nya penting: batasi semua akses tulis/hapus ke salinan yang dilindungi sampai file menua keluar dari retensi. Bukan cuma akun penyerang: semua akun. Credential yang dikompromikan saat intrusi adalah credential Anda sendiri, jadi proteksi harus bertahan terhadap mereka. Identitas backup sepenuhnya terpisah. Infrastruktur backup seharusnya pakai credential khusus, domain autentikasi terpisah, dan jalur jaringan yang tak terjangkau environment pengguna production. Kalau satu admin account mengelola produksi sekaligus backup, immutability bekerja sendirian, dan ia pantas dapat bantuan. Uji restore sesuai jadwal. Backup yang belum pernah diuji adalah hipotesis. Pulihkan satu layanan production penuh secara berkala, ukur waktunya, dan perbaiki apa yang tes ungkapkan selama taruhannya masih rendah. Membatasi akses di luar backup #Immutability melindungi jalur pemulihan. Prinsip sama, membatasi segala akses sampai trust diperoleh, berlaku di tempat lain:\nPrivileged access just-in-time. Hak administratif permanen berarti intruder mewarisinya. Elevation dengan approval dan expiry mempersempit apa yang satu akun terkompromi bisa buka. Lingkungan recovery bertahap. Enclave manajemen yang bersih, dibangun atau diverifikasi offline, dari situlah rebuild dilakukan. Membangun ulang dari management plane yang terkompromi berarti memasang ulang penyerang. Pemisahan segmen kritikal. Sistem pembayaran, domain controller, dan kontrol industri di balik batas yang benar-benar ditegakkan membatasi seberapa jauh satu workstation terenkripsi bisa merantai. Checklist kesiapan #Menjadikannya urutan yang tim kecil bisa eksekusi dalam dua kuartal:\nBackup dulu: salinan immutable object-lock untuk sistem kritikal, identitas backup terpisah, retensi terdokumentasi, uji restore penuh pertama. Latih keputusannya: sebuah cyber crisis tabletop exercise yang mencakup pertanyaan bayar atau tidak, kewajiban notifikasi, dan pembagian peran komunikasi. Celah yang ditemukan sekarang murah; nanti mahal. Bangun kapasitas respons lebih dulu: sebuah DFIR retainer membuat forensik dan containment mulai dalam hitungan jam dengan syarat yang disepakati, alih-alih dimulai dengan procurement saat krisis berjalan. Kecilkan privileged access permanen lintas platform identitas. Verifikasi batas tahunan: klaim segmentasi dan isolasi diuji lewat penetration testing, bukan diasumsikan. Kesiapan tidak membuat ransomware mustahil. Ia mengubah peristiwa eksistensial menjadi yang mahal namun bisa diselamatkan, dan bedanya antara dua hasil itu diputuskan hampir seluruhnya sebelum insiden dimulai.\nIngin tahu apakah organisasi Anda akan selamat dari ransomware pekan depan? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). DFIR retainer kami menempatkan kapasitas respons sebelum Anda membutuhkannya, Configuration \u0026amp; Architecture Assessment meninjau arsitektur backup, model privilege, dan segmentasi Anda terhadap skenario persis ini. Atau schedule an Engineering \u0026amp; Scoping Session untuk menyusun checklist di atas bersama tim Anda.\n","date":"20 November 2024","permalink":"https://puresecurity.com/id/posts/ransomware-preparedness-apac/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Kesiapan Ransomware di APAC: Anggap Ia Lolos Masuk"},{"content":"Zero trust punya masalah pemasaran. Istilahnya selalu datang bersama pitch platform dan program transformasi bertahun-tahun, menciptakan kesan bahwa mengadopsi zero trust berarti mengganti seluruh identitas, jaringan, dan endpoint dalam satu usaha heroik. Hampir setiap organisasi yang mencoba begitu macet: program terlalu besar untuk didanai, terlalu mengganggu untuk dijalankan, lalu mati diam-diam di steering committee.\nOrganisasi yang benar-benar sampai melakukan sesuatu kurang glamor. Mereka memperlakukan zero trust architecture (ZTA) sebagai arah perjalanan, bukan pembelian produk, dan bergerak ke arah itu dengan langkah kecil konsisten yang masing-masing memberi nilai mandiri. Dan di hampir setiap environment, langkah pertamanya sama: singkirkan protokol akses legacy yang diam-diam meruntuhkan setiap kontrol modern yang Anda miliki.\nApa sebenarnya yang diminta zero trust #Singkirkan branding dan idenya sederhana: berhenti memberi akses berdasarkan dari mana request datang, mulai memberikannya berdasarkan apa request itu dan siapa pengirimnya, diverifikasi setiap kali.\nKeamanan tradisional memercayai interior jaringan. Berada di dalam perimeter berarti dipercaya, jadi laptop di LAN kantor, atau di VPN, bisa menjangkau banyak hal dengan pengecekan minim. Zero trust membalik asumsi itu:\nVerifikasi eksplisit. Setiap request diautentikasi dan diautorisasi memakai identitas, kondisi perangkat, dan konteks, tanpa peduli lokasi jaringan. Least privilege. Pengguna dan workload mendapat akses minimum yang dibutuhkan, dibatasi waktu bila mungkin. Asumsikan breach. Desainlah seolah penyerang sudah di dalam, membatasi apa yang satu kompromi bisa buka. Prinsip terakhir itulah yang tersambung langsung ke alasan protokol legacy menjadi target pertama paling alami.\nLangkah satu: usir protokol legacy #Protokol akses legacy adalah anti-zero-trust. Ia lahir sebelum pemikiran identitas modern, membawa asumsi yang tak bisa diperbaiki tooling secanggih apa pun:\nSMBv1 dan dialek file sharing lama lain yang masih aktif karena kelalaian, dieksploitasi penyerang untuk masuk maupun lateral movement. NTLMv1 dan skema autentikasi lemah lain, tak sanggup mendukung verifikasi modern dan rutin direlay atau diretas. Telnet dan FTP tanpa enkripsi, mengirim credential cleartext melintasi jaringan yang Anda klaim tersgmentasi. HTTP basic auth dan LDAP bind tanpa tanda tangan, memaparkan kata sandi reusable kepada siapa saja yang bisa mengamati trafik. Protokol ambil email legacy (POP3/IMAP tanpa enkripsi) melewati MFA yang Anda tegakkan di semua tempat lain. Setiap satu adalah undangan tetap yang berkata: bawa credential era 1990-an dan kami anggap sah. Selama masih aktif, mereka adalah pintu belakang di sekeliling pemeriksaan identitas, device posture check, dan conditional access policy. Anda tak bisa membangun arsitektur zero trust di atas protokol yang desainnya mengasumsikan trust by location.\nPenghapusannya juga salah satu dari sedikit proyek keamanan dengan imbal hasil hampir langsung dan biaya rendah. Kebanyakan environment menemukan, lewat logging bukan tebakan, bahwa yang masih bergantung pada tiap protokol legacy hanya segelintir sistem atau alur kerja: armada printer tua, satu integrasi vendor, satu aplikasi terlupakan. Tiap dependensi dapat rencana remediasi pendek; sisanya dimatikan. Satu kuartal kerja fokus biasanya menghapus mayoritas eksposurnya.\nLalu tingkatkan ke luar, konsisten #Dengan lantai legacy bersih, perjalanan tersisa adalah rangkaian upgrade bertumpuk. Tak satu butuh big bang, dan tiap langkah membuat berikutnya lebih mudah:\ngraph LR A[Remove legacy\nprotocols] --\u003e B[MFA everywhere:\nusers \u0026 admins] B --\u003e C[Identity-based access:\nreplace implicit trust] C --\u003e D[Device posture \u0026\nconditional access] D --\u003e E[Per-application micro-segmentation] style B stroke:#10B981,stroke-width:2px style E stroke:#0EA5E9,stroke-width:2px Coverage MFA dulu, terutama akun privileged. Kontrol dengan value-per-dollar tertinggi dalam urutan ini, sekaligus fondasi identitas bagi semuanya. Metode tahan phishing untuk administrator bila memungkinkan. Ganti trust implisit jaringan dengan pemberian eksplisit. Alihkan remote access dari VPN datar ke akses per-aplikasi yang dimediasi identitas. Tiap aplikasi yang termigrasi mengecilkan blast radius laptop curian. Tambahkan device health ke keputusan. Begitu akses mengalir lewat identitas, aplikasi sensitif bisa mensyaratkan perangkat terkelola dan ter-patch. Perangkat tidak sehat dapat jalur karantina, bukan data production. Micro-segment workload secara progresif. Mulai dari layanan paling kritikal: sistem pembayaran, infrastruktur domain, penyimpanan data sensitif. Daftarkan pemanggil yang diizinkan secara eksplisit. Ini zero trust diterapkan pada trafik east-west, dan saling menguatkan dengan disiplin segmentasi yang sudah kita bahas. Instrumen dan iterasikan. Catat setiap keputusan akses, review penolakan cari false positive, perluas scope dengan ritme yang bisa dicerna tim. Kenapa konsistensi mengalahkan kecepatan #Mode gagal program zero trust bukan memilih teknologi salah; itu memulai antusias lalu berhenti setengah jalan. Arsitektur setengah jadi sering lebih buruk daripada tidak ada: dua model akses paralel berarti dua set aturan dirawat, dan pengguna menyiasati sisi yang lebih menjengkelkan.\nRollout konsisten menang karena:\nTiap fase selesai dalam kondisi usable. Pengguna merasakan satu perubahan dalam satu waktu, saluran support siap, alih-alih dinding migrasi. Gain keamanan datang awal dan berbunga. Hapus protokol legacy langsung terbayar; MFA langsung terbayar. Anda tak pernah memegang risiko yang belum dibangun sambil menunggu garis finis yang jauh. Anggaran bertahan kenyataan. Fase kecil yang terdanai lolos review finance berkali-kali; satu program raksasa biasanya lolos sekali lalu dipotong. Pengetahuan arsitektur tim ikut tumbuh. Saat sampai micro-segmentation, tim Anda sudah melewati upgrade identitas dan conditional access, dan mengenal pola trafik nyata environment-nya sendiri. Timeline realistis organisasi ukuran menengah: penghapusan protokol legacy dalam satu-dua kuartal, MFA universal seiring, per-application access dalam dua-tiga kuartal berikutnya, segmentasi workload berlanjut sebagai praktik tetap. Dua tahun dari sekarang, tanpa pernah menjalankan sebuah \u0026ldquo;transformasi\u0026rdquo;, Anda mendongak dan mendapati diri menjalankannya.\nIngin roadmap zero trust pragmatis yang mulai dari aset yang sudah ada? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Configuration \u0026amp; Architecture Assessment kami mengidentifikasi protokol legacy dan jalur implicit trust yang tersembunyi hari ini, vCISO advisory menyusun rollout menjadi fase terdanai yang sanggup dijalani tim. Atau schedule an Engineering \u0026amp; Scoping Session untuk mulai dari langkah pertama.\n","date":"16 Oktober 2024","permalink":"https://puresecurity.com/id/posts/zero-trust-implementation/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Implementasi Zero Trust: Mulai dari Langkah Kecil yang Bertahan"},{"content":"Kebanyakan organisasi melindungi server seolah serverlah yang berharga. Mereka membuat image, backup, patch dengan cemas, dan saat satu mati atau dikompromikan, mencurahkan jam untuk memulihkannya persis seperti semula. Sementara datanya, bagian yang benar-benar bernilai, hidup di server-server itu dengan perlindungan apa pun yang kebetulan diterimanya.\nBalikkan hubungan itu dan banyak hal keamanan jadi lebih sederhana. Perlakukan sistem sebagai sekali pakai dan data sebagai permata. Bangun server dari kode agar bisa diganti dalam hitungan menit alih-alih dipulihkan dalam hitungan hari. Lalu konsentrasikan upaya proteksi sungguhan ke tempatnya: pada data itu sendiri, dilacak sepanjang siklus hidupnya, dibackup dengan sengaja, dan semakin sering disimpan di tempat yang bahkan bukan sistem yang memprosesnya.\nSistem untuk redeploy, bukan repair #Model lama memperlakukan server seperti hewan peliharaan. Tiap satu punya nama, kepribadian, dan riwayat perbaikan manual yang tak pernah terdokumentasi lengkap. Saat pet-server mati, recovery berarti arkeologi: merekonstruksi bertahun-tahun perubahan dari ingatan, catatan, dan harapan.\nModel modern memperlakukan server seperti sapi, meminjam istilah DevOps yang bertahan lebih lama dari banyak tren lain. Anda tidak menghidupkan kembali sapi yang sakit parah; Anda menggantinya dan melanjutkan. Dalam praktik ini berarti:\nInfrastructure as code. Setiap server, container, dan konfigurasi didefinisikan secara deklaratif: Terraform untuk platform, Ansible atau cloud-init untuk host, image container untuk workload. Instans yang berjalan hanyalah satu materialisasi dari definisi itu, tak bisa dibedakan dari instans lain mana pun.\nImmutable deployment. Alih-alih log masuk ke server untuk mengubah atau mem-patch, Anda membangun versi baru, mengujinya, lalu roll out, mengganti seluruh instance lama. Tak ada yang menumpuk. Configuration drift, penumpukan senyap perubahan manual yang membuat tiap environment unik dan tak terjelaskan, menjadi mustahil secara konstruksi.\nRedeployment menggantikan restoration. Inilah payoff yang mengejutkan orang: armada sapi yang dibangun dengan benar nyaris tidak butuh backup sama sekali. Jika server dikompromikan, rusak, atau hilang, Anda tidak merestorasinya. Anda redeploy dari kode dalam hitungan menit, karena definisi itulah backup-nya. Percakapan pemulihan berhenti jadi \u0026ldquo;bagaimana mengembalikan mesin ini?\u0026rdquo; dan menjadi \u0026ldquo;seberapa cepat kita bisa menyalakan penggantinya?\u0026rdquo;, percakapan yang jauh lebih baik di tengah insiden.\nIni juga menyusut permukaan ransomware secara dramatis. Enkripsi hanya merugikan jika benda yang dienkripsi sulit direproduksi. Mesin sekali pakai yang dibangun dari repositori Git murah direproduksi.\nSemua perhatian beralih ke data #Begitu sistem sekali pakai, segala yang tak tergantikan ada di dalam data. Itu layak mendapat disiplin tersendiri, dan dimulai dari pertanyaan yang belum pernah dijawab presisi oleh kebanyakan organisasi: data apa yang kita pegang, di mana, siapa yang menyentuhnya, dan apa yang terjadi padanya seiring waktu?\nLacak data sepanjang siklus hidup. Dibuat, diproses, disalin, diarsipkan, dimusnahkan: setiap tahapan harus diketahui dan disengaja. Pelacakan lifecycle membayar berkali-kali. Ia memberi tahu di mana kewajiban regulasi Anda menempel, karena PDPA dan padanannya mengikuti data, bukan mesin. Ia mengekspos salinan yang dilupakan dan tak terhitung, tempat breach sungguhan terjadi. Dan ia memberi tahu apa yang bisa dihapus besok, sering kali pengurangan risiko termurah yang tersedia: data yang tak lagi ada tak bisa bocor.\nBackup data dengan sengaja, bukan mesin dengan tak sengaja. Ketika sistem terdefinisi sebagai kode, backup menjadi fokus dan jujur: dump database, replikasi object storage, repositori konfigurasi, vault secret. Set kecil hal-hal yang benar-benar penting dan bisa diverifikasi, bukan image malam-hari atas semua termasuk sampahnya.\nPertimbangkan menyimpan data di luar sistem pemroses sepenuhnya. Aplikasi bisa hampir tak menyimpan apa pun lokal: state di database managed, file di object storage, secret di vault. Tier pemrosesan lalu tak berisi apa pun yang layak dicuri, artinya application server yang dikompromikan adalah gangguan operasional, bukan acara yang wajib dilaporkan. Bonusnya, layanan data yang dirancang khusus menyimpan biasanya menawarkan proteksi bawaan lebih kuat, versioning, opsi immutability, access control granular, daripada server umum mana pun yang akan pernah Anda dapatkan.\nJalankan satu armada, bukan tiga #Ada penyederhanaan kedua yang tersembunyi di balik ini, soal armadanya sendiri. Lihat struktur biaya organisasi mana pun yang menjalankan estate campuran Windows-Linux dan hitung duplikasinya:\nDua set keterampilan. Administrasi Windows dan administrasi Linux adalah dua profesi berbeda. Mendukung keduanya berarti merekrut spesialis masing-masing atau menerima cakupan dangkal keduanya. Secara kasar: tim dua kali lipat untuk jumlah mesin yang sama. Dua toolchain. Patching, monitoring, configuration management, baseline hardening, deployment agent: masing-masing ada dua, masing-masing dilisensikan, dirawat, dan di-upgrade terpisah. Anggaran dua kali, attack surface infrastruktur manajemen dua kali, dan dua set benda yang bisa tertinggal diam-diam. Dua set mode gagal. Playbook respons insiden, kemampuan forensik, dan prosedur disaster recovery semuanya bercabang per platform. Saat insiden, cabang itu menghabiskan tepat waktu yang tidak Anda punya. Analogi maskapai penerbangan layak dipakai di sini. Tak ada maskapai sukses yang menerbangkan semua jenis pesawat: tiap tambahan jenis melipatgandakan program perawatan, inventori suku cadang, sertifikasi kru, pipeline pelatihan, dan kelengkapan hanggar, dan biayanya itu berulang selamanya, jauh setelah keputusan pembelian pudar dari ingatan. Maskapai karena itu menstandardisasi tanpa ampun ke set jenis terkecil yang melayani rutenya. Estate IT pantas aritmetika yang sama. Memilih sistem operasi standar Anda, dan mempertahankan garis itu, mengubah semua \u0026ldquo;dua\u0026rdquo; menjadi \u0026ldquo;satu\u0026rdquo;, dan penghematannya berbunga tiap tahun.\nStandardisasi juga langsung menguatkan keamanan. Satu armada berarti satu baseline hardening yang dipahami mendalam; satu pipeline patch yang ter-tuning dan dipercaya; satu set aturan deteksi yang pas dengan estate nyata. Kedalaman mengalahkan cakupan setiap kali.\nDari mana memulai # Pilih satu workload dan jadikan disposable. Bangun ulang dari kode sampai penggantian penuh hanya beberapa menit dan tak ada satu pun yang dikonfigurasi manual. Inventarisasi data Anda dengan jujur. Di mana, di sistem apa, di bawah kendali siapa, dan apa yang bisa dihapus esok. Pindahkan state keluar dari application server ke storage tujuan khusus dengan access control dan opsi immutability yang tepat. Hitung biaya split armada Anda dengan jujur. Jumlahkan lisensi, tool, dan headcount yang diduplikasi versus harga konsolidasi. Presentasikan ke pimpinan seperti maskapai menilai rute: biaya berulang versus pendapatan berulang. Tetapkan standar ke depan: sistem baru bergabung ke armada standar, didefinisikan sebagai kode, stateless sebisa mungkin. Pengecualian mensyaratkan alasan tertulis. Pemisahan urusan adalah pelajaran tua engineering, dan keamanan bisa mengambil manfaatnya secara literal: system itu sementara, data itu permanen, dan melindungi masing-masing sesuai hakikat aslinya lebih murah daripada melindungi keduanya buruk-buruk.\nPenasaran apakah data kritikal Anda akan selamat jika semua server yang menyentuhnya hilang? Hubungi kami untuk sanity check yang lugas. Kontak saya via LINE (@PureSecurity) atau email (hello@puresecurity.com). Configuration \u0026amp; Architecture Assessment kami memetakan lokasi data versus lokasi pemrosesan dan merancang jalur pemisahan, Linux hardening kami membangun baseline single-fleet yang membuat standardisasi terbayar. Atau schedule an Engineering \u0026amp; Scoping Session untuk merencanakannya bersama tim Anda.\n","date":"18 September 2024","permalink":"https://puresecurity.com/id/posts/separating-data-from-systems/","section":"Insight \u0026 Advisori Keamanan","summary":"","title":"Memisahkan Data dari Sistem: Immutable by Design"},{"content":"Siapa kami #Pure Security Company Limited (\u0026ldquo;Pure Security\u0026rdquo;, \u0026ldquo;kami\u0026rdquo;) menyediakan layanan managed security, tata kelola dan assurance bagi organisasi di Thailand dan kawasan APAC yang lebih luas.\nApa yang kami kumpulkan # Data permintaan: nama, organisasi, alamat email dan isi pesan Anda saat menghubungi kami Data engagement: kontak personel klien yang diperlukan untuk mengeksekusi layanan Data teknis: data permintaan server standar. Situs ini tidak menggunakan analitik, iklan atau pelacakan pihak ketiga, dan font di-host sendiri alih-alih dimuat dari CDN pihak ketiga. Bagaimana kami menggunakannya #Data permintaan kami gunakan untuk merespons permintaan Anda, dan data engagement untuk mengeksekusi layanan yang telah disepakati dengan organisasi Anda.\nBerapa lama kami menyimpannya #Data permintaan disimpan 24 bulan sejak kontak terakhir. Catatan engagement disimpan selama periode yang diwajibkan kontrak dan kewajiban statutori yang berlaku, lalu dimusnahkan secara aman.\nPembagian data #Kami tidak menjual data pribadi. Kami tidak membagikannya kepada pihak ketiga kecuali diwajibkan hukum, atau bila sub-pemroses diperlukan untuk mengeksekusi layanan dan terikat kewajiban setara.\nHak Anda #Anda dapat meminta akses, koreksi, penghapusan, pembatasan pemrosesan, portabilitas, atau menolak pemrosesan data pribadi Anda. Untuk menggunakan hak tersebut, hubungi hello@puresecurity.com.\nPerubahan #Perubahan material pada kebijakan ini akan ditampilkan di sini dengan tanggal revisi yang diperbarui.\n","date":null,"permalink":"https://puresecurity.com/id/privacy/","section":"Keamanan Menyeluruh, Disampaikan dengan Tanggung Jawab","summary":"","title":"Kebijakan Privasi"},{"content":"Bicara langsung dengan CISO berpengalaman atau QSA aktif.\nMulai percakapan #Sampaikan hasil yang Anda butuhkan dan Anda akan berbicara langsung dengan orang yang akan mengeksekusinya. Setiap permintaan diperlakukan rahasia, baik maupun tidak berlanjut menjadi engagement, dan tidak ada kewajiban apa pun dari percakapan awal.\nSaluran #hello@puresecurity.com\nLINE: @PureSecurity\n+66 88 788 8600\nYang perlu disertakan #Membagikan informasi ini sejak awal biasanya menghemat satu putaran balik:\nHasil yang Anda butuhkan, dan tenggat apa pun yang mendorongnya Pilar tempat pekerjaan berada: kepatuhan, keamanan teknis atau tata kelola Framework dalam scope (PCI DSS 4.0.1, ISO 27001, NIST CSF, pedoman BOT) Waktu respons #Kami menjawab permintaan baru dalam satu hari kerja, waktu Bangkok (UTC+7). Klien retainer DFIR memiliki waktu respons kontraktual yang mengesampingkan angka ini, dijamin tertulis.\nSudah retainer DFIR? #Klien retainer langsung melewati antrean: waktu respons kontraktual, engineer bernama, dan panduan preservasi bukti sejak panggilan pertama. Lihat DFIR Retainer \u0026amp; Investigasi Internal untuk cakupan retainer.\nInsiden sedang berlangsung? #Menangani insiden aktif? Tuliskan pada baris subjek dan kami akan memprioritaskan respons.\n","date":null,"permalink":"https://puresecurity.com/id/contact/","section":"Keamanan Menyeluruh, Disampaikan dengan Tanggung Jawab","summary":"","title":"Kontak Pure Security"},{"content":"Pure Security tersusun di atas tiga pilar: kepatuhan regulasi yang divalidasi QSA aktif, rekayasa keamanan teknis yang dihasilkan sebagai konfigurasi siap pakai, dan tata kelola strategis yang membawa akuntabilitas nyata.\nModel ini sengaja lugas: ahli yang menentukan lingkup pekerjaan Anda adalah orang yang mengerjakannya, sehingga tidak ada yang hilang antara asesmen dan remediasi, dan setiap rekomendasi datang dari orang yang pernah menjalankan kontrol tersebut sendiri.\nBagi enterprise, itu berarti asesor yang pernah duduk di pihak Anda: mantan CISO yang pernah berbicara dengan direksi, regulator dan pemeriksa bank sentral. Bagi perusahaan yang bertumbuh, artinya kapabilitas level senior pada skala yang sesuai anggaran Anda, dengan lingkup dikunci tertulis sebelum pekerjaan dimulai.\nBila kami mendesain atau mengoperasikan sebuah kontrol, kami memisahkan assurance independen atas kontrol itu, sehingga saran yang Anda terima tetap objektif. #","date":null,"permalink":"https://puresecurity.com/id/services/","section":"Layanan Keamanan","summary":"","title":"Layanan Keamanan"},{"content":"Orang yang menentukan lingkup engagement Anda adalah orang yang mengerjakannya.\nDibangun di atas eksekusi langsung, bukan serah terima #Pure Security dirancang agar orang yang menentukan lingkup pekerjaan Anda adalah orang yang mengeksekusinya. Anda mendapat akses langsung ke judgment level CISO dan rekayasa keamanan praktis, tanpa serah terima antara orang yang memahami lingkungan Anda dan orang yang bekerja.\nPekerjaan itu ditopang 20+ tahun kepemimpinan keamanan: mantan CISO payment processor APAC yang melayani 100+ lembaga keuangan di 12 yurisdiksi, head of information security untuk unit data dan AI grup perbankan Thailand, enterprise GRC lead untuk platform teknologi global, dan lead security operations 24x7 untuk infrastruktur kritikal lalu lintas udara Australia.\nFondasi karier awal dibangun di Australian Signals Directorate, menyusun kebijakan defensif nasional termasuk Information Security Manual dan memimpin operasi defensif melawan ancaman negara, dilanjutkan site reliability engineering untuk platform pemerintah dan enterprise high-assurance.\nDi mana kami bekerja # Thailand: pasar utama kami, mendukung sektor teregulasi di bawah ekspektasi Bank of Thailand (BOT) dan Thai SEC APAC lebih luas: program lintas negara untuk grup yang beroperasi di banyak wilayah. Kami telah mendesain dan mengimplementasikan program siber yang selaras dengan 10+ yurisdiksi dan framework kontrol unik di kawasan ini, dan memahami ekspektasi regulasi serta operasional masing-masing. Engagement mencakup kepatuhan regulasi, rekayasa keamanan teknis dan tata kelola strategis. Visa Pre-cleared: Kami bisa bergabung dengan tim Anda besok juga. Kami memegang visa bisnis pre-cleared untuk sebagian besar negara APAC, termasuk Australia, Brunei Darussalam, Tiongkok, Hong Kong SAR, Indonesia, Jepang, Korea, Malaysia, Selandia Baru, Papua Nugini, Filipina, Singapura, Chinese Taipei, Thailand dan Vietnam: China Australia Indonesia Japan New Zealand Philippines Papua New Guinea Malaysia Thailand Vietnam South Korea Taiwan Hong Kong SAR Brunei Singapore Hasil yang jelas dan bisa dieksekusi #Setiap temuan kami membawa penanggung jawab, jalur remediasi, dan estimasi biaya. Laporan menyatakan apa yang diuji, apa yang tidak diuji, dan apa arti gap dalam bahasa bisnis, termasuk temuan yang tidak nyaman bagi kami sendiri.\nHarga transparan dan adil #Tarif dibagikan sebelum proposal dan lingkup dikunci tertulis, sehingga gambaran komersial sudah jelas sebelum pekerjaan dimulai.\nKami juga berkata tidak saat kami bukan pihak yang tepat untuk sebuah pekerjaan. Jika engagement akan mengorbankan independensi kami, misalnya mengaudit secara independen kontrol yang kami desain atau operasikan, kami akan memberitahu Anda dan bila memungkinkan merekomendasikan vendor tepercaya lainnya.\nMulai percakapan # Perlu pengecekan cepat? Sampaikan hasil yang Anda butuhkan dan Anda akan bicara langsung dengan ahli yang mengerjakan pekerjaan tersebut.\nTerhubung via LINE Email Engineer ","date":null,"permalink":"https://puresecurity.com/id/about/","section":"Keamanan Menyeluruh, Disampaikan dengan Tanggung Jawab","summary":"","title":"Tentang Pure Security"}]