Eğer Ciddi Matematiksel Hesaplamalar Yapılıp, Net Rakamlar Ortaya Çıkmadıysa Kurumsal Ortamlarda Elasticsearch Temelli Çözümleri Değerlendirirken En Az İki Kere Düşülmeli
Elasticsearch dünyanın en hızlı log arama motorlarından biridir. Aynı zamanda ücretsiz ve açık kaynak sürümleri de olduğu için öğrenciler, akademisyenler, log&siem konularına yeni başlayanlar, meraklılar yani konu ile ilgili kim var kim yoksa herkesin kurcaladığı dolayısı ile çok yaygın, internette yüzbinlerce kaynak bulabileceğiniz bir çözümdür. Ama bu çözümün bu hızı sağlayabilmesi için bazı şartların sağlanması gerekir.
Elasticsearch ile ilgili ilk dezavantaj olabilecek husus disk kullanımının çok yüksek oluşudur. Bunun birkaç yapısal sebebi olmakla birlikte en temel husus Elasticsearch Apache Lucene ile geliştirilmiştir ve Apache Lucene disk kullanımının matematiksel formülü aşağıdadır [1]
disk space used(original) = 1/3 original for each indexed field + 1 * original for stored + 2 * original per field with term vectors
Görüldüğü gibi indekslenen her alan kullanılan disk miktarını ciddi arttırmaktadır.
Dolayısı ile ilk matematiksel hesaplama bu noktada kılı kırk yararcasına yapılmalı. Aksi takdirde saldırı, kanuni bir gereklilik, KVKK ile ilgili bir soruya muhatap olma, KVKK denetimi, GDPR tarafından istenen bir bilgi gibi pek çok durumda aşağıdaki sorulara zamanında, hatta kabul edilebilir bir zaman zarfında ve çoğu zaman hiçbir şekilde cevap verilemeyeceği durumlarla karşılaşılır.
✅ Bugün itibari ile 180 gün önceye gidip, o gün içinde firewall a yapılan başarısız oturumların listesini 3–5 dakika içinde alamaz,
✅ Son 180 gün içerisindeki bütün firewall a yapılan başarısız oturumların listesini en fazla birkaç saatte alamaz,
✅ Son 6 ay içerisinde X hedef IP sine erişen cihazların listesini en fazla birkaç saatte alamaz,
✅ Kendi kullanıcınızın son 6 ay içerisindeki bloklanan ve tehdit istihbaratı listesinde olmayan ve UDP protokolu kullanan hedef IP lerin listesi en fazla birkaç saatte alamaz,
✅ Kendi kullanıcınızın son 6 ay içerisindeki Firewall tarafından bloklanmayan ama tehdit istihbaratı listesinde olan kullanıcı erişim raporunuzu logun orijinal hali (Firewalldan çıktığı hali) ile birlikte listesini en fazla birkaç saatte alamaz,
✅ Son 6 ay içinde SA hangi databaselere login olmuş ve hangi queryleri çalıştırmış raporunu en fazla birkaç saatte alamaz,
✅ X servis hesabının son 6 ay içerisinde yaptığı bütün işlemler (Firewall dahil) raporunu en fazla birkaç saatte alamaz,
✅ Son 1 aydır hiç trafik üretmeyen makinelerin listesini en fazla birkaç saatte alamaz,
✅ Son 6 ay içerisinde X veya Y tablolarına (kişisel veri içeren tablolar) veya dosya sunucusundaki A veya B dosyasına (kişisel veri içeren dosyalar) erişenlerin listesi, daha sonra bu listedeki kullanıcıların son 6 ayda eriştiği bütün URL ve IP lerin port bilgileri dahil listesi ve en son olarak da son 6 ay içerisinde bu listedeki IP veya URL lere erişen diğer kullanıcıların listesine en fazla birkaç saatte alamaz,
✅ Saldırı için kullanıldığı çok sonra ortaya çıkan/deşifre olan bir siteye örnek: deftsecurity[.]com (Solarwinds olayında olduğu gibi) son 6 ay içinde kendi sisteminizden erişenlerin listesini en fazla birkaç saatte alamaz,
✅ Son 6 aydır kullanılmayan firewall kurallarının listesini en fazla birkaç saatte alamaz,
✅ Örneğin SolarWinds hack ile ilişkili avsvmcloud.com sitesine şirketinizden son 6 ay içinde erişen var mı sorusu kritiktir. Bugün solarwinds yarın başka bir şey. Bu listeyi en fazla birkaç saatte alamaz,
✅ Son 6 ay içerisinde solarwinds sunucularına DNS sorgusu yapanların listesini en fazla birkaç saatte alamaz,
✅ Son 6 ay içinde AV veya Endpoint Security de exception isteyen hep aynı kullanıcılarsa şüphelidir, listesini en fazla birkaç saatte alamaz,
✅ Son 6 ay içinde güncellemeleri alırken problem çıkan hep aynı kullanıcılarsa şüphelidir, listesini en fazla birkaç saatte alamaz,
✅ Şüphelendiğiniz bir kullanıcının son 6 ay içerisindeki aktivitelerin listesini en fazla birkaç saatte alamaz,
✅ Herhangi bir kullanıcı son 6 ay içerisinde kaç defa mov dosyası indirdi raporunu en fazla birkaç saatte alamaz,
✅ Son 6 aydır dosya sunucusuna erişim yapmayan kullanıcıların listesini en fazla birkaç saatte alamaz,
✅ Son 6 ay içerisinde kapanan sunucu listesini en fazla birkaç saatte alamaz,
✅ Son 6 ay içinde aylık tehdit istihbarat listesine takılma sayıları nedir raporunu en fazla birkaç saatte alamaz,
✅ Son 6 ay içinde aylık tehdit istihbarat listesine en çok takılma kullanıcıların listesini en fazla birkaç saatte alamaz,
✅ Son 6 ay içinde aynı hedef domain e erişirken firewall tarafından bloklanan kullanıcılar hangileri? sorusuna en fazla birkaç saat içinde cevap veremez,
✅ Son 6 ay içerisinde örnek olarak avsvmcloud[.]com hedef IP sine erişen cihazların listesini kaynak port ve kullanıcı adı ile birlikte listesini en fazla birkaç saatte alamaz,
Kurumsal bir ortamda yukarıdaki veya benzeri senaryoları göz ardı edemeyeceğimize göre bu senaryoların gerektirdiği disk miktarlarını hesap etmeden yola çıkmak büyük bir risktir.
Bu noktada ikinci büyük risk bu kaynak ihtiyacı log birikmesi ve yüke bağlı olduğu için kaynak yetersizliği ortaya çıkana kadar elasticsearch ve elasticsearch kullanarak ürün geliştiren markaların şöyle avantajları oluyor:
🔻 İlk bir yıl içinde problemin anlaşılması aşağıdaki vereceğim rapor örneklerine benzer raporlara ihtiyaç duymazsanız anlaşılması neredeyse imkansız,
🔻 Zaman geçip loglar birikmeden anlaşılması uzun zaman alıyor,
🔻 Özellikle geçmiş zamanda ve geniş zaman aralıklı (>15 gün) raporlama ve log arama ihtiyacı olmadığı durumda bu tür ihtiyaç olana kadar en azından
3–5 yıl anlaşılamıyor. Örnek rapor ve sorgular:
➖ 1,5 yıl önceki bir aylık bir dönem içinde raporlama ve log arama . Örnek 1 Mart 2021 ile — 1 Nisan 2021 arasında “mit.edu” ye erişen kaynak IP ler
➖ Son 6 ay içinde x olayını yapan kullanıcılar,
➖ Son 12 ay içinde Y olayını yapan kaynak IP ler,
➖ Son 6 veya 12 ay içinde A kullanıcısı neler yaptı
Eğer siz aktif olarak ürünü son 15 gün veya 30 günden daha önceki logları kullanacak şekilde aktif olarak kullanmıyorsanız yukarıdaki mayınlardan birine basana kadar sizin için her şey günlük gülistanlık olur.
Elasticsearch altyapısı ile ilgili diğer dikkat edilmesi gereken kritik husus yüksek EPS değerleridir. Elasticsearch ün veri indeksleyip kaydetme (insert time) süresi nispeten uzundur. Yüksek EPS değerlerinde diske kaydetmek için yüksek IOPS ve kaynak istemektedir. Bu konuda da da elasticsearch kullanmayı deneyip sonra çok disk kullandığı ve kayıt süresi uzun olduğu için vaz geçen Fortinet ürünü FortiSIEM’in karşılaştırma tablosu olarak yayınladığı bir veriyi paylaşayım [2].
Eğer yüksek EPS değerleriniz var ve community edition temelli bir ürün kullanıyorsanız bu da sizin için ne zaman basacağınızın belli olmadığı bir mayındır. Bu mayına basmamak için IOPS ve atadığınız kaynakların kaç EPS e kadar kaldırabileceği çok iyi hesap edilmeli.
Bu matematiksel hesaplamalar gayet kolay olmalarına rağmen ortaya çıkan sonuçlar çoğu durumda son kullanıcıyı ürküttüğü için bu hesaplamalardan çoğu zaman kaçılır. Kurumsal bir ortamda yapılabilecek en büyük hata bu hesaplamalardan kaçınmak veya bu hesaplamaların sonuçlarını içeren bir veri olmadan projeye başlamaktır.
Çok hızlı bir log arama altyapısı olan Elasticsearch kullanmak istiyorsanız ya yukarıdaki hesaplamaları yapın ya da kendinizi 20–30 günlük veri ve düşük EPS lerde kalmaya alıştırın.
Aşağıda bu durumu özetleyen bir anket sonucunu göreceksiniz.
Referanslar
