Tulisan ini bisa dibilang lanjutan dari tulisan sebelumnya tentang berkarir dalam industri IT security. Bagi yang belum membaca bisa dilihat pada link berikut ini.
MR Sahputra
IT Security Solution Architect saya rasa masih cukup jarang di Indonesia. Role tersebut kurang lebih mirip dengan Solution Architect (SA) namun untuk ranah IT / Cyber Security. IT Security Solution Architect mutlak dibutuhkan baik bagi pihak penyedia solusi (Principle, Solution Integrator), ataupun end-user.
Untuk Principle — IMHO, cukup mudah. Bagi yang belum tau terminologinya, Principle berarti pihak pembuat produk seperti contohnya Cisco, IBM, Palo Alto, dsb. Karena requirement yang datang biasanya sudah ditetapkan. Contohnya, seorang arsitek solusi yang bekerja di Cisco tentu hampir tidak pernah mendapatkan permintaan solusi terkait Anti Virus. Karena Cisco memang bukan penyedia produk Anti Virus. Sehingga seorang arsitek solusi yang bekerja pada perusahaan Principle akan fokus pada produk-produk yang dimiliki oleh perusahaannya saja. Fitur-fitur yang harus dikuasai sesuai dengan yang dimiliki oleh produk perusahaan tersebut.
Beda dengan Solution Integrator (SI). Perusahaan yang memberikan servis SI cukup berat karena harus mampu membangun solusi untuk permasalahan security yang dihadapi oleh client dengan menjahit beberapa produk sekaligus.
Setidaknya ada 3 jenis batasan yang harus dihadapi oleh seorang Architect — dalam tulisan ini scopenya adalah Security Architect,
- Kondisi postur keamanan jaringan atau sistem calon pengguna serta goal yang diinginkan
- Produk yang tepat
- Budget yang tersedia
Seorang Security Architect yang baik harus mampu melakukan assessment yang komprehensif terkait kebutuhan calon client. Harus mampu menentukan postur keamanannya seperti apa, kebutuhan bisnis prosesnya seperti apa, prioritas pengguna seperti apa, dsb. Setelah melakukan assessment, maka mulai melakukan proses menjahit solusi. Solusi disini sangat variatif tergantung kondisi yang dihadapi, ada yang bisa menggunakan produk berbasis opensource, ada yang harus produk jadi, ada juga yang mixing.
Solusi yang dibuat harus sesuai juga dengan budget yang tersedia. Dari sudut pandang calon pengguna (user) tentu ingin mendapatkan solusi terbaik dengan harga terendah. Nah disinilah letak pinter-pinternya seorang Security Architect membangun solusi sesuai dengan budget user. Harus bisa mempertimbangkan mana solusi terbaik untuk di implementasikan.
Karena dinamika serta faktor-faktor variable dilapangan maka cukup sulit untuk menjadi seorang Security Architect yang ideal dari sisi SI. Hal ini dipersulit juga dengan kondisi dimana calon user biasanya tidak paham dan tidak mau paham terkait security itu sendiri. Tidak mau dibuat ribet dengan proses assessment macem-macem namun ingin agar sistem atau jaringannya dibuat seaman mungkin.
Biasanya Security Architect akan mengeluh, “mau aman tapi gak mau ribet, gimana sih”. Jangan berburuk sangka dulu. Kita perlu sadari bahwa setiap pihak memiliki tantangannya masing-masing. Bisa jadi calon client tersebut rutinitas kesehariannya sudah padat karena menghandle tugas-tugas operasional perusahaan tempat dia bekerja sehingga sulit untuk ditambah lagi harus urusin kebutuhan security. Sebagai seorang Architect yang baik tentu kita harus mampu mengakomodir kondisi tersebut bukan? Dan sebagai seorang Architect yang baik kita harus bisa deliver hasil se-optimal mungkin.
Masalahnya lainnya kemudian, menjadi seorang Security Architect (atau Solution Architect) yang baik butuh experience. Bagi yang sudah pengalaman mudah saja membuatkan solusi karena mungkin sudah pernah membuatkan sebelumnya.
Pertanyaanya, bagaimana dengan yang belum pengalaman menjadi Security Architect? Bagaimana cara memulainya?
Nah, untuk itu dibutuhkan suatu mekanisme serta alat bantu sehingga yang belum berpengalaman sekalipun bisa mulai berlatih menjadi Security Architect, setidaknya bisa mulai mempelajari hal-hal yang dibutuhkan untuk membuat solusi yang baik.
Untuk bisa membuatkan solusi maka seorang SA perlu memahami postur keamanan suatu sistem dan jaringan. Pemahaman tersebut tentu harus memiliki dasar atau standarisasi tertentu sesuai dengan kaidah yang baik. Tanpa standarisasi tertentu maka statement terkait postur keamanan akan menjadi bias.
Contohnya, ketika suatu sistem telah memiliki firewall, apakah sudah bisa dibilang postur keamanannya cukup? Jawabannya bervariasi, bisa jadi sudah cukup, bisa jadi belum cukup. Tergantung kondisi sistemnya kan?
Untuk itulah saya coba mencari standarisasi mana yang sekiranya mudah digunakan, sesuai best practices, dan bisa dengan mudah dikorelasikan dengan produk. Selain mencari sendiri, saya coba untuk konsultasikan dengan beberapa rekan, salah satunya kemudian memberikan rekomendasi untuk menggunakan CIS Security Control (thanks Digit 😊). Saya coba gali lebih dalam dan memang benar, cukup mudah di implementasikan dan juga dipelajari oleh para pendatang baru di dunia IT security. Untuk lebih detailnya, bisa baca dari link berikut ini ya.
![]("https://cdn-images-1.medium.com/fit/c/320/320/0*NCz9aqmQ6sGnitqi")
Intinya, CIS membuat 20 security control yang terbagi dalam 3 kategori: Basic, Foundational, dan Organizational.
Idealnya, organisasi harus mengimplementasikan semua security control diatas. Namun kondisi ideal tersebut tentu sulit untuk ditemukan pada kondisi nyata sehingga seorang SA bisa memaksimalkan solusi dengan menerapkan satu atau beberapa kontrol saja.
Sebagai contoh pada salah satu kasus yang sempat saya alami baru-baru ini, ada sekumpulan sistem dan jaringan yang harus dilindungi. Sistem tersebut terdiri dari berbagai jenis perangkat, berada dalam jaringan internal, namun memiliki akses pada beberapa jaringan eksternal diluar organisasi melalui internet.
Seperti biasa, “pokoknya harus diamankan deh, budgetnya sekian”. Oke, tentu saya melihat kondisi yang ada mulai dari basic, foundational, dan juga organisational. Hasilnya? Belum ada satupun yang diimplementasikan hehehe…
Ketika rekomendasinya mengacu pada “effort” untuk mengamankan seperti melakukan “continuous vulnerability management” (CSC-3) langsung dipotong, “kita ndak punya resource untuk melakukan hal tersebut loh. langsung beli produk aja untuk mengamankan”. Oke, tidak punya resource, ketika coba ditawarkan untuk Managed Service Security agar memenuhi CSC-6 (Maintenance, Monitoring, and Analysis of Audit Logs) langsung dijawab lagi, “enggak bisa juga mas, itu ranahnya divisi lain, sudah ada aturannya, kita enggak boleh urusin monitoring”.
Bagaimana? Bagi yang sudah terbiasa membuatkan solusi untuk calon client tentu sudah biasa menghadapi hal diatas, bagi yang belum, kondisi diatas bisa menggambarkan realita dilapangan. Mau protes kepada calon user? Balik lagi seperti yang saya sampaikan sebelumnya, kita harus berpikir positif dan menempatkan diri didalam ‘sepatuh’ calon user, kita tidak tau kondisi disana bagaimana, tidak bisa men-’judge’ lingkungan kerja usernya gak bagus sehingga harus dirapihkan dari awal. Ini adalah contoh salah satu tantangan bagi seorang SA dalam merajut solusi.
Sayangnya, banyak kejadian SA main asal pilih produk. Mentang-mentang sudah tau budgetnya berapa, langsung pilih produk tertentu, apalagi jika produknya sudah berpartner dengan perusahaan SI sehingga menjadi prioritas. Padahal bisa jadi tidak sesuai dengan yang dibutuhkan oleh calon user.
Dengan memahami ke-20 konsep security control dari CIS tersebut, dan kemudian disesuaikan dengan batasan-batasan yang ada dilapangan maka seorang SA bisa lebih tepat memilih produk mana yang hendak ditawarkan.
Dalam contoh kasus yang saya hadapi, pada akhirnya diputuskan security control yang sesuai adalah CSC-12 (Boundary Defense).
Nah, dari situ baru pindah ke segmen berikutnya, yaitu mencari produk-produk mana saja yang comply dengan CSC-12.
Setelah mengetahui bahwa solusi yang tepat sesuai standard best practices untuk segera di-implementasikan pada calon user adalah CSC-12 maka berikutnya adalah mencari apa saja produk-produk yang memiliki fitur comply dengan CSC-12. Pada contoh diatas bisa kita lihat ada Google Shield, Cloudflare Athenian Project, Snort IDS, Zeek, F5 Advanced WAF, F5 Firewall, Palo Alto Network NGF, dsb.
Dari sekian banyak produk, perlu ditelaah lagi mana yang sekiranya tepat bagi calon user. Untuk itu pindah ke segmen berikutnya.
Pada segmen diatas, dijabarkan mapping lebih detail terkait fitur untuk masing-masing produk. Sebagai contoh, F5 Networks Advanced Firewall Manager, ada fitur Protocol Anomaly Detection, DoS and DDoS Protection, Remotely Trigger Black Hole Filtering, IP Reputation and Geolocations, dsb.
Disinilah letak pembeda kualitas seorang SA, yaitu kemampuan memahami konsep fitur-fitur setiap produk dengan baik. SA tidak perlu detail seperti harus tau bagaimana command-command nya, bagaimana proses instalasi, dsb. Itu kerjaannya IT Security Engineer. Role SA lebih kepada high-level concept, namun harus tetap bisa drill down masing-masing fitur secara mendalam.
Ambil contoh fitur Remotely Trigger Black Hole Filtering, fitur tersebut cukup asing di telinga sebagian besar masyarakat IT security. Salah satu penjelasan singkatnya bisa dilihat disini,
RTBH
Intinya, RTBH merupakan fitur yang dimanfaatkan untuk menangkal serangan DoS atau DDoS melalui mekanisme perubahan tabel routing memanfaatkan skema protokol routing tertentu (contoh: BGP).
Dari pemahaman singkat itu saja bisa ditarik kesimpulan calon user mana saja yang tepat untuk memanfaatkan fitur tersebut? Apakah end-user biasa, atau ISP?
Paham kan ya arahnya kemana?
Dengan memahami fitur-fitur produk maka seorang SA akan memiliki wawasan yang jauh lebih dalam sehingga bisa mempersempit pertimbangan produk-produk mana saja yang sesuai dengan kebutuhan peningkatan postur security calon pengguna.
Jangan sampai terjadi kondisi dimana wawasan terkait produk seorang SA perusahaan SI hanya pada satu atau dua jenis produk saja sehingga solusi yang ditawarkan menjadi overkill bagi calon pengguna. Butuhnya hanya fitur sederhana mengamankan perusahaan kecil startup yang baru mulai tapi karena scope penguasaan produknya sempit maka yang ditawarkan produk Firewall untuk mengamankan satu negara, misalnya. Overkill.
Melalui mapping diatas kemudian bisa dibandingkan juga terkait harga. Biar bagaimanapun seorang SA harus mampu mempertimbangkan nilai bisnis bagi perusahaanya. Produk mana yang mampu memberikan diskon lebih dalam misalnya. Atau mungkin juga melihat apabila budget calon user masih bisa dikompromikan maka disarankan membeli produk dengan fitur lebih banyak dengan mempertimbangkan bisnis mereka yang terus berkembang sehingga ketika tiba saatnya bisnis mereka membesar tidak perlu beli lagi.
Memiliki daftar produk yang lebih luas juga membuat perusahaan SI bisa cover target market yang lebih luas. Bayangkan saja jika perusahaan hanya membatasi diri pada produk-produk tertentu yang bisa jadi mahal maka ketika ada potensial client dengan nilai lebih kecil, namun jumlahnya di Indonesia ada banyak, terpaksa tidak dapat dilayani.
Padahal apabila bisa dilayani, 20 client berukuran kecil dalam satu tahun bisa jadi lebih besar profitnya dibandingkan dengan 1–2 client berukuran besar.
Bagaimana dengan end-user? Bisa digunakan juga. Contohnya, untuk tim IT security ataupun IT planner bagian security. Meskipun ada paradigma end-user fokus pada operasional sehingga besar kemungkinan membutuhkan support dari vendor penyedia produk ataupun perusahaan SI untuk membantu membuatkan solusi IT security, pihak end-user yang memiliki pemahaman cukup dalam terkait produk serta security control dapat mengkomunikasikan kebutuhannya dengan lebih akurat.
Efeknya apa? Salah satu contohnya adalah untuk penentuan budget. Pihak manajemen biasanya akan menentukan berapa besar budget buat keamanan setiap tahunnya. Jika memiliki katalog produk seperti diatas maka tim internal bisa diminta untuk menentukan security control apa saja yang dibutukan untuk diimplementasikan pada tahun tersebut, dan kira-kira butuh budget berapa. Sehingga tidak ada istilah budget-nya tidak terserap karena sudah direncanakan dengan matang.
IT Security itu gak harus pentest aja, gak harus SOC / analyst aja, gak selalu cuma sekedar hardening. Bagi pembaca yang saat ini merasa karirnya mentok didunia IT security, entah itu sebagai pentester, ataupun sebagai IT security engineer, boleh dicoba untuk mempelajari security control dan juga produk-produk IT security yang notabene bisa ditemukan dengan mudah di internet.
Metode yang digunakan dalam produk katalog diatas bisa dikustomisasi sesuai dengan kebutuhan masing-masing. Saya hanya menunjukan komponen-komponen yang dibutuhkan sebagai alat bantu membuat solusi dengan melakukan mapping antara standarisasi security dengan product. Apabila ternyata ada yang tidak setuju dengan CIS security control dan memilih menggunakan standarisasi lain, ya silahkan saja 🙂
Ilmu IT security itu masih luas banget dan saya percaya akan semakin luas loh. Seiring dengan semakin canggihnya teknologi IT maka kebutuhan akan IT security yang baik semakin bertambah. Menjadi IT Security Architect, Pre-Sales, bisa dimulai dari seorang security consultant ataupun seorang IT security engineer.
Bagi rekan-rekan yang berposisi sebagai senior atau leader di perusahaan, bisa dan penting sekali loh untuk menunjukan jenjang karir yang lebih baik bagi tim dibawahnya sehingga mereka lebih semangat lagi karena tahu tidak terkurung pada role yang itu-itu saja didunia IT security. Awalnya IT security engineer, dengan mempelajari ragam produk melalui katalog mapping seperti diatas bisa dikemudian hari diarahkan menjadi pre-sales.
Dan satu hal lagi, menjadi Security Architect berarti berubah dari specialist menjadi generalist. Apabila ada individu yang senaaang sekali belajar hal-hal baru, tehnik-tehnik baru, dan bagaimana tehnik-tehnik tersebut di implementasikan oleh sebuah produk, pasti akan betah membaca lebih dalam terkait fitur-fitur produk. Apalagi jika kemudian bisa bermanfaat bagi bisnis, mulai belajar itung-itungan bisnis, nah, menjadi SA bisa jadi pintu masuk ke ranah bisnis dan naik ke jenjang karir yang lebih tinggi lagi.
Semoga tulisan ini bermanfaat bagi siapapun yang membacanya, ya 😊
Member discussion