Apa yang umum antara kalori dan nomor insiden? Dan lagi tentang metrik IB (pengumuman saluran telegram baru)

Anonim
Apa yang umum antara kalori dan nomor insiden? Dan lagi tentang metrik IB (pengumuman saluran telegram baru) 20193_1

Setiap tahun, banyak, saya pikir begitu, menetapkan beberapa tujuan ambisius, misalnya, untuk menurunkan berat badan. Oh, ini aku, kita berbicara tentang keamanan. Jadi tujuan IB dimasukkan. Misalkan mengurangi jumlah insiden per hari dari 23 menjadi 18 atau 17%. Tampaknya menjadi tujuan yang indah dan perlu, tetapi untuk mencapainya, perlu untuk membuat sejumlah langkah. Dan karena saya menyebutkan penurunan berat badan, maka mari kita coba bandingkan kedua proses ini di antara mereka sendiri.

Jadi, kami ingin menurunkan berat badan. Jika Anda percaya banyak pakar kebugaran, langkah pertama di jalur ini akan dihitung kalori. Ya, tidak menyenangkan melihat bahwa sandwich makan sandwich dengan sosis doktoral mengandung hampir setengah dari seluruh norma kalori harian. Diyakini bahwa ini tidak hanya membentuk kebiasaan kita, tetapi juga memainkan peran psikologis, yang tampaknya melihat banyak kalori ekstra, kita akan mulai mengkhawatirkannya dan mencoba mengurangi jumlah mereka. Tetapi perlu.

Masalah dan metrik IB yang sama. Ketika kami mulai menghitung semua beting kami, merindukan spam, melewatkan phishing, kerentanan yang tidak dikenakan, mengakui kebocoran, waktu henti, desain berbahaya dalam kode aplikasi, port tidak terkunci pada ITU, dll., Kemudian kita mulai membentuk kompleks inferioritas bersyarat. Dan jika kita masih memutuskan untuk memvisualisasikan semua insiden dalam bentuk dasbor dan laporan tentang IB, maka situasinya akan menjadi lebih buruk. Intinya, kita akan ditanya dalam keseragaman kita. Dan jika hasil dari aplikasi untuk kontrol daya hanya melihat Anda (entah bagaimana beberapa orang menggunakan fungsi "Bagikan" dalam aplikasi tersebut), laporan IB melihat panduan Anda dan mulai mengajukan pertanyaan, kami sangat takut.

Saya pikir itu sebabnya saya tidak sering melihat proyek yang diterapkan dengan baik untuk pengukuran dan visualisasi IB (dan buruk juga). Dan tahun lalu saya ambil bagian dalam sepuluh proyek teratas untuk merancang atau mengaudit Socos (Cisco secara aktif terlibat dalam proyek-proyek tersebut). Mereka tidak suka menunjukkan hasil pekerjaan mereka, yang di IB tidak selalu positif.

Tetapi kembali ke pengukuran "perilaku buruk" Anda (dalam apakah makan, atau di IB). Tidak menyenangkan untuk menyadari bahwa kita melakukan sesuatu yang salah, tetapi itu perlu dan dari ini bahwa implementasi program pengukuran IB dimulai. Namun, penting juga untuk mengetahui apa dan bagaimana mengukur. Mari kita kembali ke penurunan berat badan. Di sini kita mempertimbangkan kalori, tetapi apakah itu penting? Penting untuk berasumsi bahwa secara khusus kita makan dan seberapa banyak kalori ini "buruk" atau "baik". Dan juga kondisi di mana kami makan semuanya. Misalkan kita mengurangi 500 kalori diet kita. Baik? Sepertinya ya. Anda dapat menulisnya ke aset Anda. Dan jika kita memiliki aktivitas berkurang pada "500 kalori" yang sama? Ternyata tidak ada yang pada dasarnya dan tidak berubah. Pada grafik, itu akan terlihat indah, tetapi pada kenyataannya ... dan saya belum mengambil situasi dalam perhitungan ketika seseorang secara sadar memanipulasi angka.

Dengan insiden semua sama. Dengan sendirinya, penurunan jumlah insiden tidak berarti apa-apa. Alasan untuk ini mungkin:

  • Mengurangi Pemantauan Zona Lapisan
  • Revisi konsep insiden
  • Menyembunyikan insiden.

Dan Anda juga dapat mengalami penurunan jumlah total insiden, tetapi pertumbuhan insiden kritis. Dan akhirnya, Anda mungkin hanya menyerang Anda, yang menunjukkan penurunan aktivitas penyerang, tetapi tidak tentang kualitas sistem perlindungan Anda. Dan ya, itu mungkin hasil dari pekerjaan Anda dan outsourcing SOC, serta divisi perusahaan lainnya (misalnya, itu). Oleh karena itu, hanya satu digit tidak berarti apa-apa - perlu untuk memahami lingkungannya, serta membandingkannya dengan angka yang dikumpulkan atau dihitung lainnya.

Dan oleh karena itu sangat penting untuk mengukur cukup banyak indikator berbeda, yang kemudian memilih yang diinginkan - untuk tugas yang berbeda, pada periode waktu yang berbeda, untuk audiens target yang berbeda. Bagaimanapun, metrik berbeda - operasional, taktis dan strategis. Dan dalam beberapa kasus, dengan sejumlah besar tingkat hierarki IB dalam organisasi, mungkin ada metrik eksekutif, dll. Oleh karena itu, peluncuran program pengukuran IB harus diingat bahwa itu perlu

  1. Ukur semuanya. Kemudian
  2. Mengukur hal yang benar. Kemudian
  3. Ambil hal-hal yang benar

Tetapi mulai dengan pengukuran segalanya (baik, atau banyak).

Dan di sini saya mendekati waktu untuk dicatat panjang ini. Saya memutuskan untuk menyerah pada referensi yang trendi, yang disebut hitabization IB (dalam bahasa Rusia), dan meluncurkan saluran telegram baru dengan metrik IB (metrik keamanan cyber). Saya akan berbagi satu metrik IB setiap hari dengan deskripsi singkat, formula, sumber data, batasan, dll. Bahkan, ini, tentu saja, bukan guitabization, tetapi bagaimana menyebutnya, saya tidak tahu. Awalnya saya berpikir untuk menutup katalog metrik segera dan meletakkannya di GitHub, tetapi waktu untuk melakukannya segera dan semuanya, tidak. Tetapi di beberapa bagian itu bagiku cukup mengangkat tugas. Pada hari pada metrik - pada akhir tahun akan ada 250 metrik berbeda dari domain yang berbeda IB - respons terhadap insiden, pengelolaan kerentanan, tim merah, privasi, manajemen keuangan, pemantauan IB, Kepatuhan, dll. Tidak seperti saluran saat ini "Post Lukatsky", yang baru saya telah memasukkan kesempatan untuk komentar dan diskusi sehingga Anda dapat membahas setiap metrik, berbagi pengalaman, dll.

Jadi selamat datang di saluran telegram baru, yang akan menjadi katalog metrik yang diisi secara teratur pada IB.

Sumber - Blog Alexei Lukatsky "Bisnis Tanpa Bahaya."

Bahan yang lebih menarik di cisoclub.ru. Berlangganan AS: Facebook | VK | Twitter | Instagram | Telegram | Zen | Messenger | ICQ Baru | YouTube | Nadi.

Baca lebih banyak