# Bersiap Menghadapi Insiden Siber: Table Top Exercise (TTX) Pada tahun 2013, perusahaan ritel Target mengalami kebocoran data pelanggan setelah sebuah insiden keamanan siber. Target menyalahkan salah satu vendor mereka, Fazio Mechanical Services, atas kebocoran tersebut. Pada tahun 2017, perusahaan laporan kredit Equifax juga mengalami kebocoran data besar dan menyalahkan seorang teknisi IT yang terlambat menginstal *patch* pada sistem yang terdampak. Capital One menyalahkan *cloud provider*-nya, AWS, akibat kebocoran data pada tahun 2019, meskipun akhirnya terungkap bahwa kebocoran tersebut disebabkan oleh miskonfigurasi pada WAF internal. Baru-baru ini, salah satu organisasi pemerintah -- yang diduga menjadi sumber dari kebocoran data penduduk secara masif -- menyalahkan pemilik data (masyarakat) dan melempar tanggung jawab ke organisasi pemerintah lain di depan publik. Salah satu kemungkinan terjadinya contoh-contoh *blame game* di atas disebabkan oleh kurangnya koordinasi dan kolaborasi secara internal maupun dengan entitas lain yang bekerja sama dengan organisasi saat menjalankan proses tanggap insiden, mulai dari fase *containment* hingga komunikasi kepada publik. Walaupun suatu organisasi memiliki dokumen lengkap termasuk kebijakan, proses, prosedur, dan standar yang sudah mengikuti berbagai sertifikasi dan *framework*, serta memiliki kontrol teknis lengkap berupa *security device* dan *solution* seperti *Firewall, SIEM, WAF,* dan *EDR*, tanpa adanya pengujian terhadap proses tanggap insiden (*Incident Response* atau *IR)*, manajemen krisis, serta kontinuitas bisnis dan pemulihan bencana (*Business Continuity Disaster Recovery* atau *BC DR),* organisasi bisa benar-benar mengalami kesulitan dalam menjalankan proses tanggap insiden ketika insiden tersebut benar-benar terjadi. Di Indonesia sendiri penulis belum menemukan banyak regulasi atau peraturan yang secara eksplisit mewajibkan pengujian tanggap insiden atau pemulihan bencana, walaupun ada beberapa regulasi yang membahas tentang kesiapan dalam menangani situasi darurat (salah satunya adalah SEOJK No 29 dan POJK No 11 Tahun 2022 yang dipublikasi baru-baru ini walaupun hanya terbatas pada Bank Umum). Penulis juga jarang menemukan organisasi di Indonesia yang benar-benar melakukan pengujian secara tepat pada prosedur tanggap darurat. Namun, di beberapa negara lain, organisasi-organisasi terutama terkait finansial, pertahanan, atau infrastruktur kritis diwajibkan secara reguler melakukan pengujian terhadap prosedur tanggap darurat seperti di Singapura (MAS TRM, CSA Singapore, PDPC, atau IMDA), Amerika Serikat (FedRAMP atau NIST), Uni Eropa (NIS Directive), atau standar global (PCI DSS). ## Beragam Pengujian Tanggap Darurat Walaupun tidak diwajibkan secara eksplisit di regulasi, pengujian tanggap darurat sebenarnya sangat penting bagi keberlangsungan bisnis organisasi. Ada beberapa alternatif jenis pengujian tanggap darurat yang dapat dilakukan, seperti: * ***Paper***** atau *****Checklist Test**.* Merupakan jenis pengujian tanggap darurat dengan cara membagikan salinan prosedur ke berbagai departemen internal. Tiap departemen kemudian meninjau dan menyampaikan apabila ada hal yang terlewatkan atau harus dimodifikasi di prosedur. Jenis ini paling mudah dilakukan karena fleksibilitas waktu dan tidak diperlukannya sumber daya yang besar untuk pelaksanaannya. * ***Walkthrough Test**.* Merupakan jenis pengujian di mana perwakilan dari setiap departemen atau area fungsional dapat berkumpul untuk membahas dan meninjau tujuan, ruang lingkup, akurasi, struktur pelaporan, dan asumsi pada prosedur sehingga diperlukan komitmen untuk bertemu di tempat dan waktu yang sama untuk berdiskusi. Jenis ini memerlukan sumber daya yang lebih besar dibanding *paper* atau *checklist test* karena memerlukan komitmen waktu dari departemen yang relevan untuk berdiskusi bersama. * ***Simulation Test***** atau *****Table Top Exercise (TTX)**.* Perbedaan dengan *Walkthrough Test,* selain sama-sama pengujian dengan melibatkan perwakilan dari berbagai departemen, *TTX* juga mencakup simulasi untuk berbagai skenario insiden yang ditentukan dan meninjau bagaimana berbagai departemen merespons skenario yang terjadi sesuai prosedur yang ada. Jenis pengujian ini membutuhkan sumber daya yang lebih besar dari *Walkthrough Test* karena biasanya melibatkan sejumlah elemen dari organisasi termasuk eksekutif, manajemen, dan tim teknis serta memerlukan perencanaan yang matang dan perhatian dari para peserta. * ***Parallel Test**.* Pada pengujian ini, sistem alternatif (misalnya *Disaster Recovery (DR) site*) dan proses pemulihan yang telah dibangun akan diuji untuk melihat apakah sistem atau proses alternatif tersebut dapat memfasilitasi proses bisnis *mission-critical* (misalnya aplikasi yang menjalankan *service* kepada pelanggan) dengan kapasitas yang didefinisikan pada prosedur. Pada jenis pengujian ini, sistem atau proses utama masih tetap diaktifkan untuk menjalankan proses bisnis namun sebagian atau seluruh *service* akan dipindahkan ke sistem atau proses alternatif. Hal ini memungkinkan proses *rollback* ke sistem utama dengan mudah jika terjadi masalah pada sistem alternatif ketika melakukan pengujian proses pemulihan. Hasil dari pengujian ini nantinya akan menunjukkan apakah sistem alternatif dan proses pemulihan benar-benar berfungsi dan dapat dijalankan dengan baik, serta menunjukkan perlu atau tidaknya melakukan perbaikan atau konfigurasi ulang. Jenis pengujian ini membutuhkan sumber daya dan persiapan yang jauh lebih matang dibanding jenis-jenis sebelumnya, karena selain persiapan di atas kertas, pengujian ini juga memerlukan persiapan dan konfigurasi secara teknis di sistem utama dan sistem alternatif. * ***Cutover***** atau *****Full Interruption Test**.* Pada pengujian jenis ini, sistem utama akan benar-benar diputus dan digantikan dengan sistem alternatif untuk menjalankan proses bisnis. Jika dibandingkan dengan jenis pengujian lain, pengujian ini memerlukan sumber daya yang paling besar, persiapan yang jauh lebih matang, sangat intrusif, dan berisiko sangat tinggi. Bahkan ada beberapa kasus pada pengujian ini yang berujung pada insiden atau bencana yang benar-benar terjadi, karena kegagalan dalam memindahkan sistem ditambah tidak dapat melakukan *rollback* kembali ke sistem utama. Namun, keunggulan dari pengujian ini adalah organisasi dapat menguji kapabilitas internal secara maksimal dan memastikan bahwa proses pemulihan dan sistem alternatif benar-benar berfungsi dengan baik dan siap digunakan dalam situasi darurat.

Gambar 1 - Tabel pengujian tanggap darurat beserta karakteristiknya

Di antara semua alternatif, umumnya *Tabletop Exercise (TTX)* yang dipilih sebagai alternatif terbaik karena pertimbangan hal-hal berikut: * **Efisiensi sumber daya**. *TTX* dapat dilakukan secara fleksibel sehingga sumber daya yang digunakan dapat disesuaikan dengan skenario yang akan disimulasikan. *TTX* juga tidak membutuhkan persiapan secara teknis pada sistem karena simulasi yang dilakukan bukanlah scenario secara riil namun lebih kepada simulasi *paper-based*. * **Interaktif dan kolaboratif**. Karena *nature* dari aktivitas *TTX* yang membutuhkan diskusi dan koordinasi dari perwakilan dari berbagai departemen, *TTX* dapat memfasilitasi latihan berkomunikasi dan berkolaborasi dari pemangku kepentingan dari posisi dan tingkat yang berbeda dalam merespon insiden dan bencana. * **Minim risiko**. Jika dibandingkan dengan *Parallel Test* atau *Full Interruption Test* yang tergantung pada situasi dan tingkat kompleksitas dari organisasi, secara umum *TTX* tidak melibatkan sistem atau teknologi yang sebenarnya, sehingga potensial risiko jauh lebih rendah. * **Kecukupan syarat kepatuhan.** Di berbagai regulasi yang mewajibkan pengujian proses tanggap darurat, hasil *TTX* juga dinilai cukup sebagai bukti untuk memenuhi kebutuhan kepatuhan terhadap regulasi dan standar yang diwajibkan terhadap organisasi. Karakteristik inilah yang menyebabkan *TTX* sebagai pengujian yang seimbang (*balanced test)* sehingga banyak dipilih oleh organisasi untuk melakukan pengujian terhadap proses tanggap darurat internal. ## *Table Top Exercise: Balanced Test* Secara definisi, *TTX* sendiri adalah jenis pengujian tanggap darurat yang memfokuskan pada simulasi berbasis diskusi dimana para personel dari berbagai departemen dengan peran dan tanggung jawab yang relevan dalam proses tanggap darurat berkumpul dalam satu sesi atau ruangan (*online* maupun *offline*) untuk mensimulasikan skenario insiden keamanan siber dan memberikan respons terhadap skenario tersebut. Biasanya aktivitas TTX melibatkan fasilitator dan pemantau dari pihak independen (seperti konsultan pihak ketiga atau departemen internal lain yang tidak relevan dengan proses tanggap darurat yang diuji) untuk mendapatkan hasil tinjauan dan *lesson learned* yang independen. Beberapa tujuan spesifik dari *TTX* sendiri antara lain: * Meningkatkan kesadaran dan keahlian peserta *TTX* terkait dengan proses tanggap insiden, pemulihan bencana, atau manajemen krisis; * Menguji respon teknis tim teknis dan respon eksekutif dari manajemen (*leadership*) terhadap insiden keamanan atau bencana; * Melatih keterbukaan, komunikasi, dan kerjasama antar pemangku kepentingan dari tim yang berbeda selama situasi insiden keamanan dan krisis; dan Mengevaluasi kelemahan (*gap*) dari proses yang ada dan mendapatkan rekomendasi untuk meningkatkan kemampuan tanggap darurat di internal organisasi. ## *Best Practices Penyusunan TTX* Langkah-langkah dalam melakukan *TTX* dapat dibagi menjadi 3 fase, seperti gambar berikut:

Gambar 2 - Fase-fase TTX dan aktivitasnya

{% tabs %} {% tab title="1. Fase Perencanaan" %} **a. Tentukan dan desain skenario.** Tentukan garis besar skenario atau situasi yang ingin diuji. Skenario tersebut sebisa mungkin disesuaikan dengan mempertimbangkan kemungkinan situasi serealistis mungkin sesuai dengan bisnis proses dari organisasi. Skenario dapat berupa serangan siber seperti *ransomware*, kebocoran data, atau insiden siber lainnya. Salah satu contoh sumber inspirasi untuk skenario antara lain adalah akun Twitter .

Gambar 3 - Akun Twitter @badthingsdaily

\ Setelah menentukan garis besar skenario, dapat dibuat detail skenario termasuk kondisi awal dan kondisi tambahan di tengah-tengah skenario (dikenal dengan istilah injeksi). Detail skenario ini harus menjelaskan injeksi yang terjadi, pertanyaan apa yang perlu ditanyakan oleh fasilitator kepada responden, peran dan tanggung jawab yang harus diemban oleh masing-masing tim responden, serta tindakan konkret yang harus dilakukan dalam situasi yang terjadi sehingga dapat dijadikan referensi observasi dan *gap analysis* terhadap jalannya *TTX*. Durasi atau lamanya *TTX* dapat bervariasi tergantung pada tujuan dan kompleksitas simulasi yang dilakukan. Pada umumnya, *TTX* dapat berlangsung antara 2-8 jam, tergantung pada berbagai faktor seperti jumlah peserta, berapa banyak tim yang terlibat, skenario yang disimulasikan, dan tujuan. Namun, perlu diingat, *TTX* yang terlalu lama juga tidak disarankan karena sulit mendapatkan perhatian dan fokus seluruh peserta dalam jangka waktu yang lama, sehingga perlu dipertimbangkan untuk dilaksanakan dengan efektif dan efisien untuk mencapai tujuan yang diinginkan.

Gambar 4 - Contoh sederhana sebagian dari detail skenario

**b. Pilih Peserta**. Pilih tim yang akan terlibat dalam skenario dan tentukan peserta yang menjadi perwakilan dari tim tersebut. Tim ini harus mencakup anggota departemen yang terkait dengan tanggap darurat yang ingin diuji, misalnya *Helpdesk/Service Desk, Finance, HR, Legal, Public Relation, IT Security, IT Application,* *business user,* serta manajemen senior. Pastikan bahwa semua anggota tim memiliki peran dan tanggung jawab yang jelas dalam proses tanggap darurat. **c. Tentukan dokumen referensi**. Umumnya referensi utama adalah prosedur internal terkait skenario yang akan diuji di *TTX*, misalnya *Incident Response, Disaster Recovery* atau *Crisis Management*. Selain itu, pertimbangkan juga untuk mengacu pada regulasi yang relevan atau *best practice* dari NIST atau *Cybersecurity & Infrastructure Security Agency (CISA)*. **d. Persiapkan logistik**. Adapun logistik yang perlu dipersiapkan antara lain: * **Panduan**. Materi tambahan seperti dokumen yang berisi panduan atau diagram alur aktivitas untuk membantu memvisualisasikan situasi pada *TTX*. * **Lokasi dan waktu**. Perlu dipertimbangkan ketersediaan waktu untuk semua peserta yang relevan untuk berpartisipasi, lokasi yang memadai, atau pertimbangan melakukan *TTX* secara *remote* melalui *Google Meet* atau *Zoom*). * **Infrastruktur dan teknologi**. Seperti konektivitas internet, perangkat lunak (*Google Docs* atau *Microsoft Office*), perangkat keras (Laptop atau PC di lokasi *TTX*), atau alat-alat tulis (seperti kertas dan pulpen). Jika dilakukan secara *onsite* lokasi yang dipilih memiliki infrastruktur dan teknologi yang cukup untuk mendukung *TTX*. {% endtab %} {% tab title="2. Fase Pelaksanaan" %} **a. Briefing.** Dalam *briefing* *TTX*, peserta akan diberikan informasi mengenai skenario yang disimulasikan dan akan diingatkan untuk membahas solusi yang dapat diterapkan dalam mengatasi situasi darurat yang terjadi, serta melakukan evaluasi atas rencana tanggap darurat yang sudah dibuat. Selain itu, di dalam *briefing* akan dijelaskan peran dan tanggung jawab masing-masing peserta. Pada umumnya peserta *TTX* dibagi menjadi peran-peran sebagai berikut: 1. **Fasilitator**. Merupakan pemimpin *TTX* dan pengatur diskusi yang akan memulai dan memfasilitasi *TTX* dengan menyajikan skenario dan seluruh injeksi selama *TTX* berlangsung. Fasilitator bertanggung jawab untuk mengajukan pertanyaan yang relevan untuk menstimulasi jalannya diskusi berdasarkan skenario yang disediakan, memberikan informasi tambahan, atau menjawab pertanyaan yang mungkin muncul selama diskusi. Selain itu fasilitator juga dapat beranggotakan *Subject Matter Expert (SME)* yang dapat memberikan saran dan rekomendasi sebagai ahli di area atau proses tertentu yang akan diuji di dalam *TTX*. 2. **Pemantau (*****Observer*****).** Bertindak sebagai pengamat yang bertugas untuk memantau dan menilai jalannya *TTX*. Biasanya pemantau juga bertindak sebagai *note-taker.* Pemantau umumnya sama sekali tidak terlibat langsung dalam *TTX*. Pemantau bertugas untuk mendokumentasikan diskusi peserta, termasuk apakah diskusi tersebut sesuai dengan rencana, kebijakan, dan prosedur yang telah ditetapkan. 3. **Peserta atau Responden (*****Responder*****).** Merupakan peserta yang secara aktif terlibat dalam diskusi serta membahas and menginisiasi tindakan atau respons terhadap situasi darurat yang disimulasikan sesuai peran dan tanggung jawab posisinya masing-masing di pekerjaannya sehari-hari di organisasi. **b. Execution.** Fasilitator akan memulai *TTX* dengan injeksi pertama sebagai kondisi awal dan menanyakan tindakan awal dari para responden. Responden akan diberikan waktu di antara injeksi untuk merespons dengan tindakan yang menurut responden sesuai dengan prosedur. Fasilitator juga akan memoderasi dan menstimulasi jalannya *TTX*, termasuk memastikan semua responden berpartisipasi, hingga semua injeksi dijalankan dan proses *mission-critical* telah diuji selama *TTX*. Fasilitator dan pemantau perlu memegang detail skenario yang telah dibuat sebelumnya untuk membandingkan dan menganalisis respons dari para peserta berdasarkan ekspektasi dan tujuan yang telah didefinisikan sebelumnya. Beberapa pedoman untuk peserta, terutama responden, saat melakukan *TTX* antara lain: 1. *"What if" mindset:* Sekecil apapun kemungkinan skenario insiden keamanan yang diskenariokan, responden diharapkan untuk merespon dengan prosedur dan tindakan seakan-akan insiden tersebut benar-benar terjadi. 2. Setiap peserta perlu berkomunikasi dan merespons sebagaimana mestinya sesuai dengan peran dan tanggung jawab pada situasi nyata. 3. *TTX* adalah sesi yang terbuka dan bebas dari kesalahan, sehingga disarankan untuk berpikir dan berbicara secara terbuka seperti bermain *game*. Peserta juga harus saling mendukung dan semua pemain harus memiliki kesempatan untuk berpartisipasi. 4. Jika ada personel atau tim penting berhalangan untuk berpartisipasi, peserta dapat mengambil kondisi tersebut untuk diintegrasikan dalam skenario. Misalnya, jika tim *Risk dan Compliance* tidak dapat ikut *TTX*, di dalam skenario, peserta dapat menganggap mereka mereka sedang dalam situasi darurat dan tidak dapat dihubungi. 5. Identifikasi kelemahan dalam proses dan *taking ownership* sebisa mungkin. Jika terdapat situasi atau kondisi yang membutuhkan tindakan di mana tanggung jawab belum didefinisikan atau diformalisasi untuk tim atau bisnis tertentu, peserta disarankan untuk proaktif mengambil alih tanggung jawab dan membuat keputusan pada area tersebut. Dengan begitu, peserta dapat meningkatkan efektivitas latihan dan memastikan bahwa semua aspek penting telah ditangani dengan baik. 6. *Have fun!* Meskipun kegiatan *TTX* mencakup topik yang sangat kritis dan serius, CISA sendiri menyarankan agar para peserta melakukan *TTX* se-*have fun* mungkin karena peserta akan lebih banyak belajar dan mengingat jika atmosfernya menyenangkan dan suportif.

Gambar 5 - Pedoman umum TTX untuk peserta

**c. Debrief (After Action Review)** Setelah semua injeksi selesai, fasilitator akan memberikan kesempatan kepada pemantau atau *observer* untuk mengelaborasi hasil observasi dari jalannya *TTX* termasuk kelebihan dan kekurangan. Selain itu, peserta lain juga akan diberikan kesempatan untuk menyampaikan ide dan saran yang dimilikinya sehingga semuanya dapat digunakan sebagai *lesson learned* untuk perbaikan prosedur yang ada. {% endtab %} {% tab title="3. Fase Laporan dan Tindak Lanjut" %} Setelah menyelesaikan semua tahapan dalam *TTX*, semua hasil observasi dan *lesson learned* akan didokumentasikan dalam laporan dan tindak lanjut termasuk peningkatan kapabilitas dan perbaikan prosedur akan direncanakan dan dimonitor. Dengan menerapkan perbaikan tersebut organisasi dapat meningkatkan kesiapannya dalam menghadapi situasi darurat yang sebenarnya, sehingga dapat mengurangi risiko dan meminimalkan dampak dari kejadian yang tidak diinginkan. Frekuensi melakukan *TTX* bervariasi tergantung kebutuhan dan kondisi organisasi. Ada beberapa faktor yang perlu dipertimbangkan seperti ukuran organisasi, kompleksitas sistem dan infrastruktur, dan tingkat risiko yang dihadapi. Namun, sebagai *best practice*, disarankan melakukan *TTX* setidaknya setahun sekali atau jika terjadi perubahan signifikan pada sistem atau organisasi (misalnya pada susunan manajemen atau eksekutif) untuk membantu memastikan tim yang relevan dengan proses tanggap insiden siap dan memahami tugas dan tanggung jawab mereka dalam situasi darurat. {% endtab %} {% endtabs %} ## TL:DR Tidak semua organisasi memiliki kesempatan untuk berlatih dalam menghadapi insiden yang terkendali di dunia nyata. Seringkali, ketika situasi darurat benar-benar terjadi, tingkat keparahan sangat tinggi dan mengatasinya bisa sangat sulit dan membingungkan. Itulah sebabnya *Table Top Exercise* (*TTX*) bisa dipertimbangkan sebagai salah satu solusi terbaik untuk organisasi anda dalam persiapan situasi darurat. *TTX* adalah jenis pengujian tanggap darurat yang difokuskan pada simulasi berbasis diskusi di mana para personel dari berbagai departemen dengan peran dan tanggung jawab yang relevan dalam proses tanggap darurat berkumpul dalam satu sesi di satu ruangan untuk mensimulasikan skenario insiden keamanan siber atau bencana dan memberikan respons terhadap skenario tersebut. Meskipun saat ini di Indonesia tidak banyak diwajibkan secara eksplisit oleh regulasi, *TTX* sebenarnya sangat penting untuk diuji oleh organisasi untuk memastikan keberlangsungan bisnis pada saat terjadinya insiden. *TTX* merupakan pengujian yang seimbang karena mencakup proses yang ingin diuji, efisien terhadap sumber daya, interaktif dan kolaboratif, dan minim risiko. Pada umumnya *TTX* dipilih sebagai alternatif terbaik karena sifatnya yang seimbang dan memfasilitasi latihan berkomunikasi dan berkolaborasi dari pemangku kepentingan dari posisi dan tingkat yang berbeda dalam merespon insiden dan bencana. *TTX* dianjurkan dilakukan setidaknya 1 (satu) tahun sekali atau jika ada perubahan signifikan dalam sistem, proses atau susunan organisasi. Langkah-langkah persiapan dan pelaksanaan harus dilakukan dengan baik untuk mencapai hasil pengujian yang maksimal. ## Referensi 1. Association of Information Security Professionals. “White Paper on Data Breach Tabletop Exercise.” *AiSP*, 2 November 2020, . Diakses pada 15 Februari 2023. 2. “CISA Tabletop Exercise Packages.” *CISA*, . Diakses pada 15 Februari 2023. 3. CIS Center for Internet Security. “Six Scenarios to Help Prepare Your Cybersecurity Team.” *CIS Center for Internet Security*, 18 October 2018, . Diakses pada 15 Februari 2023. 4. “Cybersecurity Tabletop Exercise Tips.” *CISA*, . Diakses pada 15 Februari 2023. 5. Krebson Security. “Target Hackers Broke in Via HVAC Company – Krebs on Security.” *Krebs on Security*, 5 February 2014, . Diakses pada 22 Februari 2023. 6. “NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities.” *NIST Technical Series Publications*, . Diakses pada 15 Februari 2023. 7. “NIST SP 800-84, Technical guide to information security testing and assessment.” *NIST Technical Series Publications*, . Diakses pada 15 Februari 2023. 8. TechCrunch. “Former Equifax CEO says breach boiled down to one person not doing their job.” *TechCrunch*, 3 October 2017, . Diakses pada 22 Februari 2023. 9. TechCrunch. “Security breach? Don't blame your employees.” *TechCrunch*, 14 February 2023, . Diakses pada 22 Februari 2023. 10. USA Today. “Amazon's AWS unit says its not responsible for Capital One data breach.” *USA Today*, 30 July 2019, . Diakses pada 22 Februari 2023. 11. Wlosinski, Larry G. “Cybersecurity Incident Response Exercise Guidance.” 2022. *ISACA*, . Diakses pada 15 Februari 2023. ### Tentang Penulis ![](https://1897137542-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FNbk8bFw3pJck0jgXywso%2Fuploads%2FqLVQx7DGRDFp2BAx7ik2%2Fimage.png?alt=media\&token=50ee3e63-8525-4fbb-abc1-867f1e0e94bb) #### M. E. Adideswar *S.Kom, CISSP, CISM, CCSP, CCSK, CISA, CC, Google PCSE, ISO 27001 LA, Implementor SMPI (BSSN), ECSP* [www.adideswar.com](http://www.adideswar.com) Adi adalah seorang profesional keamanan siber dengan pengalaman lebih dari 13 tahun sebagai *end-user* dan konsultan di beberapa perusahaan global*.* Pengalaman Adi bervariasi mulai dari manajemen keamanan siber, audit keamanan informasi, manajemen risiko hingga *cloud security* untuk klien dari berbagai industri termasuk perusahaan *start-up* dan teknologi *(e-commerce, fintech, hail riding,* dan *health tech),* asuransi dan perbankan, telekomunikasi, BUMN, pusat data, migas, dan juga sejumlah Kementerian di Indonesia. Selain bekerja sebagai konsultan, Adi juga aktif berkontribusi pada beberapa program dan acara keamanan siber sebagai pembicara, *podcaster*, mentor, atau juri diantaranya seperti pada Ask a CISO Podcast, Tech in Asia Conference, FS-ISAC, InfraDigital Foundation, Div0, dan ScaleUp Mentorship. Saat ini Adi tinggal dan bekerja di Singapura sebagai *Principal Consultant* di salah satu perusahaan keamanan siber dengan fokus utama di *cloud security* dan *CISO as a Service.*