SIEM ve Log Yönetimi Çözümlerinde Geçmiş Zaman Sorgulama İle İlgili Anlatılmayanlar veya Gözden Kaçanlar

SIEM veya Log Yönetimi çözümleri üzerinden 6 ay önceye gidip bir günü aratmakla son 6 ayın tamamını aramak birbirinden çok farklı şeylerdir. Elasticsearch kullanan sistemleri örnek verirsek ilkinin sonucu birkaç saate gelirken diğerin sonucu birkaç haftaya gelir.

5651, BDDK, TCMB gibi denetimlerden dolayı bir kullanıcı son 12 ay içerisinde belirli bir günü veya random seçilen günleri aramaya alışkın ve geçmişe yönelik ihtiyaçların sadece bunlardan ibaret olduğunu sanmakta. Bu büyük bir yanılgı ve gözden kaçan en önemli unsurlardan biri. Bu konu ile ilgili gerçek dünyadan 3 tane örnek vereceğim:

1. KVKK
2. IBM veri ihlali raporu
3. Solarwinds Case

KVKK

KVKK bir veri ihlali olduğunda en geç 72 saat içinde bildirimde bulunulmasını şart koşuyor. Haber vermeyenlere ceza vermiş durumda.

Bir veri ihlali olduğunda, bu ihlal ile ilgili sorulabilecek yüzlerce sorudan biri olan “Son 1 sene içinde ihlalin oluştuğu kişisel verilerin tutulduğu veri tabanındaki tabloya veya dosyaya erişim yapanlar hangi cihaz ve kullanıcılar?” diye sormak olur. Peki bu soruya 72 saat içerisinde cevap alabilecek misiniz?

Diyelim ki aldınız bu sorunuzun devamı aynı cihaz ve kullanıcılar son 12 ay içerisinde başka hangi sunuculara erişti diye sormak olur. Bu soruya da 72 saat bitmeden cevap bulsanız iyi olur.

Ayrıca ilgili kişi tarafından yapılan başvuruya veri sorumlusunca 30 gün içinde bir cevap verilmesi gerekir. Son 12 ay içerisinde ilgili kişinin kişisel verilerinin bulunduğu veri tabanı, tablo, dosyalara kimler erişti? Bunlar nerelere kopyalandı? Kopyalarına kimler erişti gibi soruların cevabı için en fazla 30 günüz var.

IBM veri ihlali raporu

Bir ihlalin tespit edilip kontrol altına alınması için gerekli minimum ortalama süre 288 gündür!”. [1]

Buradan da anlaşılacağı gibi ihlal, saldırı, şüpheli olayların tespiti için de loglara çok hızlı erişim kritiktir.

Solarwinds Case

Son zamanların en meşhur olaylarından Solarwinds saldırısı saldırı başlangıcı 2019 yılına uzanıyor ve 2021 yılında hala incelemeler devam ediyor. Böyle durumla karşı karşıya kalındığında aşağıdaki soruları en kısa sürede cevap bulmanız kritiktir.

• Bu saldırı ne zaman başladı?
• Hangi kaynaklar etkilendi?
• Saldırganlar kimler?
• Bu saldırganlar başka hangi iç kaynaklara erişti?

Buna benzer onlarca senaryo ile SIEM veya Log yönetimi kullanmaya başladıktan sonraki ilk 3–5 yıl içerisinde mutlaka karşılaşırsınız.

Yukarıda da bahsettiğim gibi geriye 6 ay gidip 1,2 gün veya 1,2 haftalık bir arama işinizi görmeyecektir. Çünkü bu olayları ne zaman olduğunu tam olarak bilemeyeceksiniz.

Burada anlatılmayanlar veya gözden kaçanlar bu son 6 ay, 12 ay hatta 24 ay içindeki tüm olaylara hangi hızda erişebileceğiniz bilgisidir.

Lazım olduğunda iş işten geçmemesi için projede ürün seçim aşamasında tespit ettiğiniz EPS veya günlük log miktarı için

1-Logları sıcak, yani canlıda ne kadar süre ve ne kadar disk ile tutuyorsunuz?
2-Logları soğuk, yani arşivde ne kadar süre ve ne kadar disk ile tutuyorsunuz?

diye sormak lazım. Burada ne kadar disk verirseniz o kadar tutulur veya net rakam hesaplanamayan ürünlerden uzak durmanız faydanıza olur.

Eğer bu tür sorgular her gün lazım değil, yılda bir olursa da olur demek büyük risk almak olur. Eğer bu husus dikkate alınırsa siber güvenlik sigortası yaptırmış olursunuz. Nasıl 10 sene sigorta yaptırır ve sigorta parası öderiz ama başımıza bir şey gelmediği için sigorta parasını yine de boşuna ödemiş hissetmeyiz, bu da öyle bir sigorta. İşiniz düşerse hayat kurtarır.

Türkiye’deki SIEM ürünlerinin bir, iki tanesi hariç ortalama loglara canlıda tutma süresi 15–30 gün civarıdır. Yukarıda açıkladığım gibi 15–30 güne hızlı erişip son 6 ay veya son 12 aya erişmek için haftalarca beklemek iş görmez. Çözüm olarak neden o zaman logları 12 ay canlıda tutmuyoruz derseniz o zaman da ihtiyaç duyulan disk miktarının büyüklüğü ortaya çıkar. Eğer ortalama 3000 EPS bir logu Elasticsearch temelli bir SIEM veya Log Yönetimi yazılımı ile 1 yıl canlıda tutmak isterseniz 100 lerce TB disk alanı gerekir.

Elasticsearch ve Elasticsearch kullanan çözümlerdeki disk kullanımı aşağıdaki formül ile hesaplanabilir

disk space used(original) = 1/3 original for each indexed field + 1 * original for stored + 2 * original per field with term vectors [2]

Bu tür sistemler disk canavarıdır [3].

Ayrıca Gartner SIEM Magic Quadrant 2021 raporunda lider olan Exabeam in 1000 (bin) EPS için bir yıllık disk kullanımı aşağıda gösterilmiştir [4].

Diğer bir SIEM ürünü olan FortiSIEM de elastic kullandığı zaman yukarıdaki formüle göre disk ihtiyacı hesaplanabilir [5]

Yukarıda örnek olarak verilen bilgiler gibi bütün üreticilere aynı soruları somak gerekir. Tespit ettiğiniz EPS veya günlük log miktarı için

1-Logları sıcak, yani canlıda ne kadar süre ve ne kadar disk ile tutuyorsunuz?
2-Logları soğuk, yani arşivde ne kadar süre ve ne kadar disk ile tutuyorsunuz?

Ürünlerin disk kullanımı bilgileri konusunda mühendislik çalışması yapılmaması anlatılmayanlar veya gözden kaçanlar konusunda ikinci husustur.

Referanslar

1. https://www.ibm.com/tr-tr/security/data-breach
2. https://lucidworks.com/post/estimating-memory-and-storage-for-lucenesolr/
3. https://drertugrulakbas.medium.com/elasticsearch-ve-elasticsearch-kullanan-b%C3%BCt%C3%BCn-siem-ve-log-y%C3%B6netimi-%C3%A7%C3%B6z%C3%BCmleri-neden-disk-canavar%C4%B1-24424624d4e5
4. https://www.exabeam.com/siem-guide/siem-architecture/
5. https://docs.fortinet.com/document/fortisiem/6.3.1/elasticsearch-storage-guide/887430/setting-up-elasticsearch-for-fortisiem-event-storage