İdeal Bir SIEM’den Beklentiler Nelerdir? Korelasyon Duyduğunuz veya Uyguladığınız Kadar Mıdır?
Bir SIEM için kurulum ve Log toplama gibi temel konularının zaten olmazsa olmaz olduğundan dolayı doğrudan geçip ideal bir SIEM için aşağıdaki konuların incelenmesi gerekir.
•Log Kaçırma
•CPU&RAM ve Disk Gereksinimleri
•Canlı Log
•Arşiv Yönetimi
•Korelasyon
•UEBA
•Açık Kaynak Çözümler ve Ticari Ürünlere Kalıtsal Etkileri
•SOC Yanılsamaları
Log Kaçırma Problemi
- Aramızda log kaçırdığını fark edenler vardır. Bir kısmımız da test etmediği ve başımıza gelmediği için fark etmemiş olabiliriz ama bu kronik bir sıkıntıdır.
- Bunun sebebi seçilen ürünün CPU, RAM ve Disk ihtiyaçlarının mühendislik çalışmasının doğru yapılmamasıdır.
- Ayrıca log kaçırma problemine sebep önemli konulardan biri de seçilen, kullanılan SIEM çözümlerinin kullandığı açık kaynak bileşenlerden gelen kalıtsal avantaj ve dezavantajlardır. Elasticsearch en yaygını olduğu için Elasticsearch üzerine bina edilen Elasticsearch den gelen gereksinimlerin iyi bilinmesi gerekir.
- Bir SIEM ürünün log kaçırıp kaçırmadığını test edebilirsiniz. Aşağıda bunun için kullanabileceğiniz bir açık kaynak araç linki var https://sourceforge.net/projects/syslog-slogger/
- Bunun için öncelikle yaklaşık EPS değerinizin ne olması gerektiğini bilmelisiniz. Bunun için SANS ın aşağıdaki tablosunu kullanabilirsiniz. Bu tablo aynı zamanda Gartner SIEM Magic Quadrant 2021 lider olan Exabeam de kullanıyor.
- Daha sonra bu tabloya göre bulunan maksimum EPS değeri ile SIEM çözümünüzü test edebilirsiniz. Testin nasıl yapılacağı ile ilgili detayları aşağıdaki makalede bulabilirsiniz.
Canlı Log
- Son 6 ay içinde X,Y kullanıcılarının internet ve intranet aktivitelerinin lazım olduğu kritik bir durumda beklediğiniz her saat size para ve itibara mal olabilir. KVKK ile ilgili veri ihlali veya denetim durumunda, saldırı olduğunda, şüpheli durumlarda bu ve benzeri sorgular yapmanız gerekecektir.
- Burada kritik işlem indeks oluşturmadır.
- Bazı üreticiler canlı log ve gereken disk miktarı arasındaki üstel fonksiyon ilişkisinden dolayı logları çok kısa sürelerle canlıda tutar sonra arşive atar. Bu süreler genelde 15, 30 gün, nadiren de 90 gündür.
- Bazı üreticiler ise canlıda tutabilme süresini uzatmak için indexledikleri alanların sayısını kısıtlar. Böyle olunca indexlenmeyen alanlardaki sorgular çok yavaşlar.
- PoC, Demo ve proje başlangıç toplantılarında bu konun gündeme gelmemesi son kullanıcıda ciddi bir yanılmasa olmasına yol açar.
- Buradaki büyük yanılsama eski tarihli aramayı, arşivden dönmeyi küçük bir senaryo içine sığdırmak. Burada “Son 6 ay içerisinde veri ihlalinin gerçekleştiği veri tabanı ya da eğer kişisel veriler dosya olarak duruyorsa dosyaya kimler erişti?” gibi bir sorguya ihtiyaç olacağı akla gelmiyor, sanılıyor ki ihtiyaçlar hep “6 ay önceki salı günü yani 01–04–2021 günü içinde veri ihlalinin gerçekleştiği veri tabanı ya da eğer kişisel veriler dosya olarak duruyorsa dosyaya kimler erişti? ”. Bu büyük bir “YANILSAMA” . Çok büyük olasılıkla hiçbir zaman o günü veya o haftayı hatta o ayı bilemeyeceksiniz. Bu yanılsamanın sebebi sanırım 5651 sayılı yasa alışkanlıkları. Çünkü orada sorular hep şu gün, bu hafta diye bilinen zaman dilimi için geliyordu.
- Diğer bir yanılsama da hiç denemeden son 6 ay, son 12 aylık zaman dilimleri içerisindeki verilere makul zamanlarda erişebileceğini varsaymak. Bu bir varsayım. En azından ayda bir kendi kullanıcınızın son 6 aylık firewall aktivitelerinin tamamını almayı deneyip gerçekle yüzleşebilirsiniz.
- Örnek vermek gerekirse: Elasticsearch ve Elasticsearch üzerine bina edilmiş bir SIEM kullanıyorsanız Maksimum 3000 EPS ve Ortalama 1500 EPS trafiğiniz varsa ve logları 1 ay canlıda tutuyor sonrasını arşivde tutuyorsanız seçtiğiniz 2 kullanıcının internette yaptığı bütün aktivitelerin listesi yaklaşık 30 günde gelir.
- Ama bu 1 yılı canlıda tutabilseniz bu süre yaklaşık 4–5 saattir.
- Elasticsearch neden bu kadar büyük disk kullanıyor? Sebebi aşağıdaki formül:
disk space used(original) = 1/3 original for each indexed field + 1 * original for stored + 2 * original per field with term vectors
- SIEM ve Log Yönetimi Çözümlerinde Geçmiş Zaman Sorgulama İle İlgili Anlatılmayanlar veya Gözden Kaçanlar
Arşiv Yönetimi
- Logları arşivlediniz. Bu arşivlerden logları aramak ne kadar iş yükü çıkarıyor? Ayrıca arşivden geri dönmek ne kadar iş yükü çıkaracak. Bazı çözümlerde
– Önce tarih aralığını belirlemek,
– Sonra ziplenmiş bu log dosyalarını açmak (Bunun için disk de ayarlamanız gerekir, ya da işi biteni silmesini bekleyip sonra yenisini silinen disk alanına açmasını bekleyeceksiniz).
– En son index oluşturmak gerekir (En çok vakit alan işlem).
- Bazı çözümlerde ise indexler de arşivlenir. Dolayısı ile o tarihe gidip dosyaları sisteme geri yüklemek yeterlidir.
Korelasyon
Bir SIEM için en önemli özellik korelasyondur.
- Ayrıca Korelasyon doğrudan performansı da ilgilendiren ama başlı başına değerlendirilmesi gereken bir konudur. Korelasyonun performansa etkileri, kuralların yapı, format ve tipi ile ilgili ilk makaleyi 2015 yılında slideshare de yayınlamışım.
- Domain admin grubuna bir kullanıcı eklendi
- Firewall da policy değişti
- Virüs tespit edildi
- Sahte DHCP sunucusu tespiti
- Kullanıcı haklarında değişiklik oldu
Tipinde, yapısında yüzlerce kuralı gerçek zamanlı çalıştırmakla
- Too Many Fail Logon Activity
- Brute Force Detected
- Http flood atak tespiti
- DDoS Attack Event Detected
Tipinde, yapısında yani X Sürede Y adet olay olursa formatında 100 adet kuralın CPU, RAM gereksinimi çok başkadır.
Eğer aşağıdaki gibi daha gelişmiş kurallara gelirsek
•Ertuğrul Akbaş son 6 aydır hiç bu SAP sunucuya öğleden sonra login olmamıştı şimdi oldu, bu onun için anormal bir durum
Veya
•Ertuğrul Akbaş bugün Türkiye içindne VPN yapmıştı 4 saat sonra ABD den VPN yaptı fiziksel olarak mümkün değil, anormal bir durum
Bu tip, yapı ve formattaki 100 adet senaryonun ihtiyaç duyacağı CPU, RAM ve Disk çok farklıdır.
Korelasyon performansı ile ilgili ilk bakacağımız EPS değerimiz veya günlük log miktarımıza göre 50 basit alarm için CPU&RAM ihtiyacımız ne olur? Bu 50 orta seviye korelasyon kuralı olsa ne olur? 50 adet gelişmiş kural olsa ne olur? Bunu kural sayısını 100,200 yaparak CPU&RAM gereksinimini bulabilirsiniz.
Korelasyon konusunda dikkat edilecek diğer bir husus ise bazı global ürünlerde logların raporlama hızı ile korelasyon hızının farklılığıdır. Örnek olarak maksimum 5000 EPS hızında toplarım ama korelasyonda maksimum 1500 EPS e çıkabilirim diye dokümanlarında yazar. O zaman hangi 3500 EPS i çöpe atıyor?
Elasticsearch ve onun üzerine bina edilmiş SIEMlerin neredeyse tamamı korelasyon olarak Elasticsearch sorgularını periyodik çalıştırma yöntemini kullanır, burada da sistem eğer yeteri kadar kaynak bulamazsa veya rahat çalışabildiği EPS değerlerinin üstünde bir log akışı olduğunda alarmları bekletmeye, çok geç alarm üretmeye veya tamamen alarm üretmemeye başlar.
Diğer önemli bir konu gerçek zamanlı korelasyondur.
- Domain admin grubuna bir kullanıcı eklendiğinde,
- Firewall’da yetkisiz birisi değişiklik yaptığında
- Disable edilen bir hesapla ağa erişmek istenirse
- Aynı process 5 dakikada içinde onlarca dosya silerse
Gibi onlarca kritik olayı anında bilmek isteriz. Bunun gibi yüzlerce durumda 15 dakika bile çok geç olabilir.
Korelasyonla ilgili en önemli konu SIEM korelasyon piramidinde nerelere kadar çıkabildiğimizdir. Ne tür korelasyonalar yapabiliyoruz?
İleri Korelasyon örneklerine devam:
- DGA detection (ML)
- Hunting malware and viruses by detecting random strings
- Ağınızda güvenli olması gereken kritik processlerle (winlogon.exe, svchost.exe, explorer.exe, lsm.exe, lsass.exe, csrss.exe, taskhost.exe, wininit.exe, smss.exe, smsvchost.exe) isim benzerliği açısından yanıltıcı olabilecek (insan gözü tarafından aynıymış gibi algılanabilecek) processler ayağa kalkarsa ve bu ayağa kalkan processler izin verilen processler içerisinde değil ise uyar
- Orijinal mail adresine benzer mail adreslerinden mail gelirse uyar. Örnek : ertugrul.akbas@anetyazilim.com.tr olan mail adresinden errtugrul.akbas@anetyazilim.com olarak mail geliyor ise uyar(bir oltalama yöntemi)
- Sysmon Event ID 1 kullanarak son kullanıcının mail ile gelen bir linki tıklayıp tıklamadığını anlayabiliriz.
Sysmon dan gelen bu url eğer aynı anda URL Proxy loglarında da varsa tespit et.
Peki Bu Gelişmiş Korelasyonları Neden Çoğu Ürün Desteklemezken Sadece Bazıları Destekler?
Bunun önemli sebeplerinden biri korelasyon motorunun performansıdır. Bunu uyarı şeklinde bazı global ürünlerin detay teknik dokümanlarını okursanız görürsünüz.
Bunun önemli sebeplerinden diğeri SIEM çözümünün desteklediği operatörlerdir. Örnek:
- Windows Event loglarını topluyoruz ve EventID lerin ardışık olup olmadığını kontrol etmek istiyorsunuz bunun için bir operatör lazım
- Bir kullanıcının yaptığı bir işlemi dün aynı saat dilim içinde yapıp yapmadığını kontrol etmek istiyorsunuz bunun için bir operatör
- İki olayın aynı anda olup olmadığını kontrol için «aynı anda» operatörü lazım
Bunun önemli sebeplerinden diğeri listeler ve liste operatörleridir. Örnek
- Çok boyutlu listeler oluşturulabiliyor mu?
- Oluşan iki listelinin kesişim noktasını bulabiliyor musunuz?
- Oluşan iki listenin birleşimini bulabiliyor musunuz?
- Listeler üzerinde fark, elemanların toplamı gibi operatörler destekleniyor mu?
- Listelerin elemanları üzerinde matematiksel ve mantıksal işlemler yapılabiliyor mu?
- Mesela benim çok boyutlu listem var. Burada Ali kaç farklı Source IP almış, Kaç farklı Destination IP ye gitmiş, iki işlem arasındaki zaman farkı nedir gibi işlemler yapabiliyor muyum?
Çoğu üründe liste yetenekleri, listeye ekle, listeden çıkar, listede var mı yok mu ? dan öteye gitmez. Hatta bazı ürünlerde çok boyutu liste bile desteklenmez.
Diğer bir sebep korelasyon ara yüzü veya konsol kullanılarak geliştirilebilecek algoritmaların çeşitliliği, derinliği ve esnekliğidir. Örnek olarak birden çok adımdan oluşan olayları arasında çapraz ilişkiler, mantıksal bağlar ve ilişkilendirmeler kurulabiliyor mu?
Ayrıca yenilikçi yöntemler geliştirip geliştiremediği ve öncü olup olmadığı diğer önemli bir faktördür
Son olarak da istatistiksel yöntemler, yapay öğrenme kullanıp kullanamadığıdır. Bu konuyu bir sonraki slaytta UEBA konusunda değineceğiz ama UEBA olmadan da SIEM çözümlerinin bir kısmı istatistiksel yöntemler ve yazılım algoritmalarını kural olarak çalıştırabilir.
UEBA
UEBA kullanıcı ve cihazların kullanım modellerinin profillerini çıkarıp ( yapay öğrenme teknolojisi kullanılır (Machine learning )) daha sonra anormal davranışların sergilenmesinde durumunda bunların tespitini sağlar.
UEBA ürünlerinin faydası yadsınamaz. UEBA ürünlerini projelendirirken dikkat edilecek ilk kritik parametre şeffaflıktır.
UEBA ürünlerinin faydası yadsınamaz. UEBA ürünlerini projelendirirken dikkat edilecek ikinci kritik parametre sistem isterleridir.
Gartnerdaki lider ürünlerden biri için yaptığım yazışma.
EBA ürünlerini projelendirirken dikkat edilecek üçüncü kritik parametre de lisans maliyetleridir.
Açık Kaynak Çözümler ve Ticari Ürünlere Kalıtsal Etkileri — Elasticsearch
Popüler açık kaynak çözümlerden Wazuh un kurucusunun bu konu İle ilgili paylaşımına beğenisi
SOC Yanılsamaları
SOC hizmeti alınca eğer anlatılan özelliklere sahip bir SIEM olmasa bile kısıtlarını aşabileceğini sanmak. Burada SOC hizmeti için kullanılan SIEM çözümünün kısıtları başına 7X24 insan koyarak giderilemez. Zaten olayın felsefesine de ters. Biz araçların insanın işini kolaylaştırıp otomatikleştirmesini beklerken, insanların araçların eksik ve hatalarını gidermesini bekler hale getiriyoruz.
SOC- Bulut Yanılsamaları:
•Logların yurt dışına gönderilmesi KVKK açısından riskli
•Logları şirketinizden dışarı gönderirseniz, loglar sizin olmaktan çıkar,
•Hizmet bitince logları alıp alamayacağınız belirsizdir,
•Alabildiğini varsayarsak hangi formatta alacağınız belirsizdir,
•CSV veya text formatında alabilirseniz işinize yaramaz,
- Hizmet aldığınız SIEM formatında alırsanız da hizmet sonrasında eski logları kullanmaya (arama, tarama ve rapor) devam etmek için bu SIEM i lisanslamanız gerekir ki bu durumda maliyet avantajlarınız kaybolur.
Bu makalenin webinar kaydı
