School of Information Systems

The Outsystems Sentry Monitoring

OutSystems Sentry menghadirkan sebuah layanan pengawasan atau monitoring yang merupakan sebuah tantangan besar karena tidak hanya Outsystem memantau ancaman di dunia maya atau cyber threat, tetapi Outsystem juga memantau platform di mana pelanggan dapat membangun ekosistem aplikasi yang beragam tanpa sepengetahuan Outsystem. Beberapa dari aplikasi ini memiliki ratusan ribu pengguna di seluruh dunia, sementara yang lain hanya melayani segelintir pengguna di negara atau kota tertentu, yang berarti apa yang dirasakan oleh satu pelanggan OutSystems sebagai sesuatu yang normal dapat dianggap ancaman bagi pengguna lain.

Sehingga Outsystems perlu memastikan bahwa sistem pengawasan yang diaplikasikan dapat mengenali da beradaptasi dengan pola pemanfaatan baru unruk setiap pelanggan Outsystems Sentry, sambil tetap melakukan pemantauan seperti biasanya. Pokok pembahasan mengenai monitoring yang dilakukan oleh Outsystems Sentry akan dibagi menjadi dua bagian besar. Pertama, menggambarkan pendekatan Outsystems untuk mengindentifikasi, mengimplementasi, dan mengoperasi peringatan atau alerts.

  1. Building, Testing, and Operating Alerts
    Computer Response Incident Response Team (CSIRT) adalah tim yang bertanggung jawab untuk bereaksi terhadap peringatan dan menjaga Outsystems Sentry pelanggan aman dari ancaman. Untuk mencapai tujuan ini, Outsystems perlu memastikan bahwa list berikut diterapkan:

    • Semua peringatan harus memiliki prioritas.
    • Angka peringatan positif palsu mendekati 0 persen.
    • Setiap peringatan memiliki dokumentasi yang tepat dan prosedur reaksi yang jelas.

Agar sistem terlindungi secara benar,Outsystems memutuskan untuk mengambil pendekatan IT Infrastructure Library (ITIL) untuk merancang, mengimplementasikan, menguji, mengoperasikan, dan memastikan peningkatan lansiran yang berkelanjutan.

Setiap kali Outsystems menambahkan peringatan baru ke sistem pemantauan Outsystems (Outsystems menyebutnya alert catalogue atau Katalog Peringatan), langkah pertama adalah menentukan prioritasnya (Mendesak, Tinggi, Sedang atau Rendah).

Jadi, Outsystems menciptakan pendekatan objektif di mana Outsystems menetapkan bobot pada sifat-sifat utama keamanan (kerahasiaan, integritas, ketersediaan, dan keaslian). Dari sana, Outsystems mencocokkan taksonomi internal Outsystems dengan properti-properti ini dan menentukan dampaknya jika ancaman terwujud. Kami kemudian dapat membuat matriks penilaian yang melintasi taksonomi dengan properti dan memberi kami dampak dan prioritas awal.

Perigatan tersebut kemudian ditugaskan untuk satu atau lebih taksonomi untuk menentukan prioritas akhirnya. Misalnya, peringatan yang mendeteksi gangguan konfigurasi inti platform OutSystems cocok dengan tiga taksonomi: “Penyalahgunaan atau penggunaan sumber daya yang tidak sah,” “Akses yang tidak tepat ke data atau sistem,” dan “Modifikasi informasi yang tidak sah.” , Outsystems kemudian dapat memperoleh prioritas peringatan akhir.

Setelah menentukan prioritas, tiba saatnya untuk merancang dan mendokumentasikan prosedur tanggapan Outsystems sehingga CSIRT akan tahu persis apa yang harus dilakukan dan bagaimana bereaksi jika peringatan dipicu. Oleh karena itu, langkah selanjutnya adalah mengidentifikasi informasi mana yang Outsystems perlukan untuk mengimplementasikan peringatan tersebut. Biasanya, setiap informasi diubah menjadi temuan atom tunggal yang disebut blok bangunan, yang kemudian dikorelasikan untuk membangun lansiran.

Setelah prioritas ditetapkan, prosedur respons didokumentasikan, dan informasi yang diperlukan diidentifikasi, Outsystems memasuki fase Transisi Peringatan, tempat Outsystems menerapkan, menguji, dan menyetel peringatan.

Setelah pengujian dan penerimaan berhasil, Outsystems memindahkannya ke Operasi Peringatan, tempat CSIRT Outsystems menerima peringatan dan mengambil tindakan sesuai dengan prosedur yang ditentukan.

Setiap kali tim ini menemukan kesalahan positif atau masalah lain dengan prosedur peringatan atau respons, mereka mendokumentasikannya dan mendiskusikannya dalam pertemuan mingguan untuk mencari atau memperbaiki peringatan atau prosedur dalam siklus peningkatan peringatan berkelanjutan.

Dengan mengadopsi pendekatan ini, Outsystems dapat terus menambahkan peringatan baru tanpa lupa memperbaiki yang sudah Outsystems miliki.

  1. Adaptable Predictive Alerts

Contoh terbaik tentang Adaptable Predictive Alerts yang mengikuti metodologi peningkatan peringatan berkelanjutan yang dijelaskan sebelumnya adalah peringatan deteksi penolakan layanan atau distributed denial of service (DDoS) Outsystems yang didistribusikan, yang saat ini sedang dalam iterasi ketiga.

Saat ini, Outsystems memiliki 237 sensor yang tersebar di seluruh planet ini; hasilnya banyak informasi untuk diproses. Namun, ini tidak selalu terjadi. Ketika OutSystems Sentry dimulai, kami hanya memiliki beberapa sensor di Eropa, yang memberi Outsystems informasi yang Outsystems gunakan untuk membangun peringatan DDoS pertama Outsystems.

Dalam iterasi pertama dari peringatan yang Outsystems terapkan, Outsystems mulai dengan mengidentifikasi pola lalu lintas yang Outsystems terima dan membuat alarm untuk memicu ketika lalu lintas menunjukkan pola yang akan mengalihkan dari yang diidentifikasi, selama periode yang ditentukan dan dengan perbedaan 50%. Peringatan ini berfungsi dengan baik untuk beberapa waktu dengan tingkat kesalahan positif palsu hampir 0%.

Namun, seiring berjalannya waktu, Outsystems menambahkan lebih banyak sensor dan mulai menerima lebih banyak informasi. Outsystems mulai melihat peningkatan tingkat peringatan positif palsu. Pada saat itu, Outsystems masih mendeteksi ancaman tetapi dengan biaya positif palsu yang tinggi. Dalam pertemuan mingguan, salah satu analis Outsystems berbagi masalah, dan Outsystems kembali ke papan gambar.

Dalam iterasi kedua, Outsystems memutuskan tidak hanya untuk mengidentifikasi pola saat ini tetapi juga untuk memahami bagaimana pengguna menggunakan aplikasi yang dibangun oleh pelanggan Outsystems Sentry. Dari masing-masing itu, Outsystems membuat satu blok bangunan untuk menggabungkan pola lalu lintas abnormal dan lainnya untuk mengagregasi perilaku pengguna yang tidak normal. Ini memungkinkan kami untuk mengkorelasikan keduanya dalam suatu periode dan untuk mendeteksi potensi ancaman terlebih dahulu. Setelah pengujian, kami menyebarkan peringatan ke dalam operasi dan mengamati penurunan positif palsu ke tingkat hampir 0%, yang cukup bagus.

Sekali lagi, seiring berjalannya waktu, Outsystems menambahkan lebih banyak sensor ke lapangan dan mendapatkan lebih banyak informasi yang menunjukkan peningkatan tingkat positif palsu. Untuk ketiga kalinya, Outsystems kembali ke papan gambar.

Kali ini Outsystems memutuskan untuk membuatnya sehingga sistem pemantauan beradaptasi secara otomatis dengan pola lalu lintas yang berkembang seiring waktu alih-alih memetakan pola lalu lintas saat ini. Dengan mengambil pendekatan ini, kami bertujuan menciptakan set blok bangunan baru yang terus-menerus menyesuaikan dengan pola lalu lintas baru.

  1. The Great Achievement
    Pengawasan lingkungan dimana pelanggan Outsystems dapat membangun beragam ekosistem aplikasi adalah tantangan besar yang tidak dapat dipecahkan sendiri oleh teknologi. Dengan mengadopsi strategi peningkatan peringatan berkelanjutan, Outsystems menjamin bahwa Outsystems memiliki sistem pemantauan yang terus berkembang tanpa ada peringatan yang tertinggal.

Sumber: https://www.outsystems.com/blog/posts/sentry-monitoring/

Inggried Kurniawan