Akhirnya ada keinginan untuk menulis kembali walau sebenarnya sedikit malas gerak. Jadi sebenarnya tulisan ini akan sedikit membahas tentang ISO/IEC 27001 dan 27002 versi 2022, walaupun saat ini sudah 2023 dan sedikit terlambat. Tidak ada salahnya tetap membahas secara umum karena melihat perkembangan di dunia Cybersecurity khususnya bidang ISO banyak beberapa yang masih melihat bahwa itu hanya sekedar Sistem Manajemen belaka saja.
Sebenarnya dari versi terdahulu saya juga kurang menyukai jika ada segelintir pihak yang memandang Standar tersebut hanya memfokuskan ke aspek Manajemen. Ini pemikiran keliru bahwa mungkin ada beberapa Auditor Badan Sertifikasi serta teman-teman lainnya yang dahulu melihat "Kriptografi" ya sebatas itu dan melihat dari sisi aliran data yang harus di kripto atau enkrip. Memang hal itu tidak salah, tapi menurut saya pribadi masih ada yang kurang.
Dari situlah saya sempat berdiskusi dengan beberapa teman bahwa kenapa penerapan Kriptografi itu diperluas. Misalkan pada data Password yang disimpan di database, itu juga perlu dilihat penerapannya seperti apa. Jika hanya sebatas "Hash", maka sangat tidak dianjurkan dan lebih direkomendasikan menggunakan model Kriptografi secara baik atau memakai Enkripsi.
Kemudian ada juga terkait file di aplikasi seperti "Config, Configuration dan sejenisnya" yang mana biasanya file tersebut menghubungkan antara aplikasi ke database engine. Banyak yang kurang peduli terhadap hal tersebut, padahal ada risiko yang melekat jika server aplikasi telah diambil alih oleh Attacker dan Attacker dapat membaca informasi yang ada di file tersebut untuk loncat ke server database. Apalagi celakanya banyak database yang jalan dengan tingkatan "root, sa, administrator" atau high privilege. Andaikata informasi yang ada di file tersebut, seperti username dan password tidak bersifat plaintext atau menerapkan Kriptografi, maka saya pikir akan sedikit menurunkan risiko atau membuat Attacker bekerja lebih maksimal lagi untuk mengambil alih server database, walau banyak proses yang harus dilakukan penjagaan secara baik.
Memang jadinya jika diperketat, beberapa pihak akan merasa dibebankan dan menjadi tidak nyaman. Ini yang saya dan teman-teman selalu memberikan edukasi kepada semua pihak, jika berbicara Cybersecurity dan sejenisnya, jangan mempunyai tingkat toleransi yang rendah. Mungkin banyak "Oknum" yang hanya sekedar ingin mendapatkan Sertifikasi dan jika berpikir seperti itu, maka saya dapat katakan sama saja menjadi orang bodoh yang mana sebenarnya sudah ada arahan secara jelas dari Standar ISO dan kurang membedah lebih dalam. (Maaf jika menggunakan kata bodoh).
Jadi ketika ruang lingkupnya adalah sebuah layanan yang didukung oleh sebuah sistem, mau tidak mau harus dipaksa menerapkan seperti Firewall (internal & eksternal), Web Application Firewall (jika aplikasi berbasiskan web), Privilege Access Management, Endpoint Detection and Response (EDR) atau AntiVirus yang sedikit pintar bahkan jika ingin menonaktifkan harus menggunakan credentials, menerapkan segmentasi yang berbeda antara workstation dengan server, pembatasan Teleworking (SSH, Remote Desktop, dll), bahkan port yang dibuka harus dibatasi dan tidak ditoleransi port seperti Telnet, FTP, http dan sejenisnya bersifat aktif atau open.
Ada beberapa hal yang patut diperhitungkan lainnya seperti File Sharing dan ini sering kali menjadi ajang penyebaran Ransomware, Malware dan sejenisnya. Jika tidak mau terdampak dari insiden Cybersecurity maka setidaknya fitur tersebut tidak digunakan. Jika mau dipaksa digunakan, pertimbangkan dari sisi risiko yang mungkin terjadi di kemudian harinya.
Tulisan di atas masih pembuka dan intinya saya mencoba mengatakan bahwa dari versi sebelumnya juga sudah membahas detil terkait "Teknologi", tapi dari beberapa pihak untuk menangkap hal tersebut yang masih lemah. Pada akhirnya sekarang terbukti di versi 2022 terdapat kategori khusus "Teknologi" walau dibeberapa kalimat menurut saya masih kurang tegas dan masih ada beberapa Annex yang saya masih kurang sreg masuk ke dalam sebuah kategori Teknologi. Sebagai contoh Threat Intelligence yang masuk ke kategori kontrol "Organizational", walau saya berpikir lebih cocok masuk ke "Teknologi" karena sangat sulit melakukan hal itu tanpa bantuan Teknologi. Memang ini bahasa yang halus dari ISO bahwa bisa jadi "Organziational" itu mirip maknanya dengan "Process". Jadi disiapkan mekanismenya melalui sebuah proses dan tidak memaksa ke arah Teknologi. Jika seperti itu, saya sangat merasa tidak akan efektif penerapan dari Threat Intelligence. Bisa saja saya membantah bahwa seperti "Annex 8.3 Information Access Restriction" jangan masuk ke kategori Teknologi tapi ke Organziational. Akan tetapi kita ikuti saja versi yang sudah terbit ini dan saya mulai menangkap pola pikir para perumus ISO tersebut.
Saya disini tidak akan membahas perubahan Clause, karena bagi saya arahnya sudah ketebak. Jika pembaca melihat ISO/IEC 20000-1:2018 dan ISO 22301:2019, akan terlihat pola dan strukturnya yang sekarang mulai menyeragamkan. Tujuan utama selain menyeragamkan adalah untuk memudahkan ketika ingin melakukan integrasi dengan standar ISO lainnya. Di ISO/IEC 27001 versi 2022 juga akan ada sudut pandang yang sedikit berubah terkait pengelolaan risiko (risk management), walaupun di awal saya katakan tidak tertulis secara jelas. Hal apa itu? Jadi sekarang diusahakan ketika identifikasi risiko, tidak perlu lagi menuliskan risiko positif ke dalam daftar risiko (risk register). Ketika berbicara Cybersecurity, cobalah memfokuskan ke Risiko yang negatif dan jangan membuang tenaga untuk mendaftarkan risiko positif. Saat ini dari tiket insiden Cybersecurity juga bisa naik level menjadi sebuah risiko, tapi perlu dikaji lebih dalam lagi. Ini yang saya senang sebenarnya dan apalagi dari hasil Vulnerability Assessment (VA), Penetration Test (Pentest), itu bisa diintegrasikan ke dalam proses pengelolaan risiko (Risk Management). Mungkin dari dahulu ketika saya berbicara bahwa hasil VA atau Pentest bisa masuk ke Risk Register, beberapa pihak bingung atau berkata dalam hati "ah masa begitu". Sekarang alhamdulillah terbukti bahwa itu hal yang benar. Jadi temuan dari VA atau Pentest itu tidak bisa langsung dikatakan sebuah Risiko tapi perlu dikaji lagi dan saya lebih senang bahwa temuan tersebut hanya baru terlihat dari sisi "dampak (impact)", dan jika tidak percaya coba bedah CVSS. Mereka hanya melihat ke Confidentiality, Integrity dan Availability yang notabennya adalah sebuah Impact. Oh ya apalagi jika hasil temuan masih menggunakan Likelihood X Impact, ini juga masih menjadi ambigu bagi saya pribadi. Namun saya membebaskan pihak lain dalam menerapkan sebuah ilmu itu seperti apa dan wajar jika mempunyai beberapa pemikiran yang berbeda. Saya sangat senang jika alurnya seperti ini: "Vulnerability --> Threat --> Risk".
Wah sudah terlalu panjang basa basinya dan coba kita lihat Annex 8.28 Secure coding:
Control:
Secure coding principles should be applied to software development.
Purpose:
To ensure software is written securely thereby reducing the number of potential information security vulnerabilities in the software.
Other information:
...
Some web applications are susceptible to a variety of vulnerabilities that are introduced by poor design and coding, such as database injection and cross-site scripting attacks. In these attacks, requests can be manipulated to abuse the webserver functionality.
Dari contoh di atas, Annex tersebut masuk ke kategori Teknologi walaupun sebenarnya bisa saja untuk memitigasi tidak memerlukan sebuah Teknologi. Bisa di awali dengan secure coding yang baik, tapi disini saya sudah senang bahwa ISO sekarang lebih melek dan mau terbuka ke standar di luar ISO lainnya (bisa dilihat di bab "Bibliography"). Mungkin bahasa Teknologi dimaksud tidak melekat kesebuah Produk tertentu walau masih bingung saya.
Duh ternyata kejauhan langsung loncat, mungkin karena terlalu semangat. Coba kita balik lagi ke awal ISO/IEC 27002:2022:
Information security, cybersecurity and privacy protection — Information security controls
1 Scope:
This document provides a reference set of generic information security controls including implementation guidance.
^Jadi sekarang menyebutnya "this document" bukan seperti yg lalu "this internasional standard". Kemudian dokumen ini ada kontrol keamanan informasi secara generik termasuk petunjuk implementasi walau sifatnya umum. Ini memang saya acungkan jempol terkait penggunaan tata bahasa yang sangat berhati-hati. Kemudian adalagi seperti:
b) for implementing information security controls based on internationally recognized best practices.
^Jadi ketika menerapkan kontrol keamanan informasi yang ada di Annex, itu bisa berdasarkan best practice di luar sana secara internasional. ISO tidak memberikan best practice -nya seperti apa. Duh bisa banget bahasa mereka yang tidak mau menjadi boomerang di kemudian hari.
Sebenarnya masih banyak yang bisa diulas, namun saya malas menuangkan semuanya. Lebih asik kita kopdar dan membahas secara santai.
Mohon maaf jika ada kesalahan dalam penulisan di atas.
