NEDEN SURELOG INTERNATIONAL?

SureLog bir SIEM ürünüdür. Yani amacı korelasyon yapmaktır. KENDİ KORELASYON MOTORUNA SAHİPTİR ve KOLERASYONU MEMORY ÜZERİNDE GERÇEKLEŞTİRİR. YANİ SQL

üzerinde belli aralıklarla sorgu çalıştırıp logları ilişkilendirmeye korelasyon demez.

SureLog ürünümüzün rakiplerine göre avantajlarının ana unsurları:

Tekilleştirme- Taksonomi (Taxonomy) özelliği

(hiçbir yerli rakipte bu özellik yoktur- bazı yabancı rakiplerde mevcut)

Korelasyon yeteneği

(hiçbir yerli rakipte bu özellik yoktur; fakat yerli rakipler yukarıda bahsedilen ve korelasyonla karıştırılan YANİ SQL üzerinde belli aralıklarla sorgu çalıştırıp logları

ilişkilendirmeye veya Hadoop ve elasticsearch temelli sorgulama özelliğini korelasyonmuş gibi gösteriyor - bazı yabancı rakiplerde mevcut)

Geniş parser listesi

(hiçbir yerli rakipte yok- bazı yabancı rakiplerde mevcut)

TAG desteği

(hiçbir yerli rakipte yok- bazı yabancı rakiplerde mevcut)

Kullanıcı temelli rapor, menü, alarm yetkilendirme

Trafik analizi ve güvenlik aktiviteleri istatistiki raporları

(hiçbir yerli rakipte yok- bazı yabancı rakiplerde mevcut)

Dağıtık Mimari

Big-Data altyapısı

Tekilleştirme- Taksonomi (Taxonomy)

Tekilleştirme her ürün tarafından desteklenen bir yetenek değildir. Aşağıda Splunk a paloalto, fortinet, juniper ve netscreen logları gönderdikten sonraki ekran gözükmektedir.

Eğer log ekranını büyüterek bakarsak gönderilen loglar üzerinde arama tarama yapılacak şekilde kullanıcıya sunuluyor. Ama SureLog daki gibi bir TAXONOMY bilgisi YOK

Diğer bir örnek de piyasada çokça mevcut olan arama&tarama ve raporlama ürünlerinden birinin ekran görüntüleri aşağıdadır. Tekilleştirme yerine ayrıştırma yapmıştır. Hatta

Windows için gözüken logon/logooff Events kısmı Firewall, Proxy Server, Network Cihazları (router,switch, load balancer vb..) için BULUNMAMAKTADIR.

Aynı logları SureLog a gönderirsek ekranın en sağında TAXONOMY kolonu oluşur ve bu logların ilişkili oldukları olaylar veya risk dereceleri ile ilgili tekilleştirme sonuçlarının eklendiğini görürsünüz. Bu logların ilişkili oldukları olaylar veya risk dereceleri ile ilgili tekilleştirme sonuçlarının detayları yandaki örnekte görüldüğü gibidir.

Aşağıdaki resimde aynı logları SureLog a gönderdiğimizde (Logların orijinal halleri ve diğer normalleştirilmiş alanlar ekran görüntüsünün sığması adına rapordan kaldırılmıştır)

TAXONOMY içeren rapor örneği görülmektedir.

Taxonomy

Ayrıca tekilleştirme sonucunda aynı kategorideki logları tek bir listede görmek mümkün. Aşağıdaki resim SureLog raporlarında Fortigate ve Windows sunuculara logon olan kullanıcıları

görebileceğiniz rapor gözükmekte. Bu tarz bir rapor ne SPLUNK ne de aşağıda örnek olarak kullandığımız diğer üründe SAĞLANAMAYAN BİR BİLGİDİR

“Informational.Authentication.Succeeded” seçilerek

Windows

Linux

Firewall,

Proxy Server

Network Cihazları (router,switch, load balancer vb..)

Vb..

Bütün sistemlerdeki logon hareketlerini görebilir ve daha da önemlisi KORELASYON kısmında değineceğimiz gibi sisteme yeni bir kullanıcı login olursa haber ver şeklinde kuralı

yazabilirsiniz. Aksi takdirde 1 kural yerine aşağıdaki gibi N tane kural

Windows a yeni bir kullanıcı eklendiğinde haber ver

Linux a yeni bir kullanıcı eklendiğinde haber ver

Firewall a yeni bir kullanıcı eklendiğinde haber ver

Proxy Server a yeni bir kullanıcı eklendiğinde haber ver

Router a yeni bir kullanıcı eklendiğinde haber ver

Switch a yeni bir kullanıcı eklendiğinde haber ver

Load balancer a yeni bir kullanıcı eklendiğinde haber ver

Vb..

Yazmak gerekeceği gibi aynı kullanıcı tarafından firewall ve Linux da dış IP den login olunursa uyar gibi daha gelişmiş kurallar da yazılamaz.

Diğer bir örnek de piyasada çokça mevcut olan arama&tarama ve raporlama ürünlerinden birinin ekranı yandadır. Tekilleştirme yerine ayrıştırma yapmıştır. Hatta Windows için gözüken logon/logooff Events kısmı Firewall, Proxy Server, Network Cihazları (router,switch, load balancer vb..) için BULUNMAMAKTADIR.

Tekilleştirme ile ilgili daha detaylı teknik bilgiler içeren aşağıdaki çalışmaya bakılabilir

http://www.slideshare.net/anetertugrul/surelog-siem-ve-log-ynetimi-zm-stnlkleri

Korelasyon

Arama tabanlı log çözümleinin korelasyon olarak tanımladığı aslında korelasyon değildir. Bir arama sorgusudur. Aşağıdaki resimde Splunk ürününün korelasyon ekranı gözükmektedir.

Dezavantajları:

Kullanıcı bir sorgu (query) yazmak zorundadır. Bunu öğrenmek zorunda kalır. Örnek sorgu : `authentication(failure)` | stats count,dc(user) as user_count,dc(dest) as dest_count by app,src | where count>=6<

Bu sorgular zamanlanmış görevlerle (Schedule) çalışır. Dolayısı gerçek zamanlı değildir.

Zaman aralığını kaydıramaz (Time Range). Dolayısı ile olaylar bu zaman aralığına sıkışmazsa yakalayamaz. Örnek : 5 dakikada 5 failed logon yakalamak istiyoruz. Eğer bu failed logonların 3 ü 1. time range aralığında 2 si de 2. time range aralığında oluşursa yakalayamaz

Kurallar (Aslında scriptler [SQL veya NoSQL]) periyodik çalıştırıldığı için bu periyod içindeki olaylar anında yakalanamaz

SQL veya NoSQL DB ler üzerinde yüzlerce scriptin belli periyotlarla çalıştırılması bir performans problemine sebep olur

Kurallar Hafızada çalışmadığı için olaylar anında yakalanamaz

Scriptler [SQL veya NoSQL]) bağımlı olduğu için gelişmiş kurallar yazılamaz. Örnek: “Bir kullanıcı Herhangi bir sunucuya login olamayıp authentication failure a sebep olduktan sonra 2 saat içerisinde aynı kullanıcının aynı sunucuya başarılı oturum açmadığı takdirde uyar” şeklindeki kuralları yazamazsınız

Diğer bir örnek de piyasada çokça mevcut olan arama&tarama ve raporlama ürünlerinden birinin ekranı yandadır. Bu ürün de aynı splunk gibi aslında bir arama&tarama ürünüdür. Ama korelasyon da yaptığını iddia etmektedir. Splunk ile benzer mantık güttüğü için yukarıda sayılan handikapların hepsi mevcuttur.

Korelasyon özelliğinin diğer ürünlere göre üstünlüğü aşağıdaki kurallardan anlayabilirsiniz. SIEM çözümü ortalama bir korelasyon yeteneğine sahip ise aşağıdaki kuralı destekler:

Aynı IP den birbirinden farklı iç IP lere ve birbirinden farklı portlara 15 dakikada 100 paket blokanıyor ve daha sonra 1 saat içinde bu bloklanan iç IP lerden birinde yeni bir

process ayağa kalkıyorsa uyar.

Eğer, içerideki bir PC potansiyel zararlı alan adına DNS sorgusu yaparsa, daha sonra aynı PC sonraki 24 saat içinde internete 1024’ten büyük TCP portlarından çıkmaya

çalışıyorsa ve/veya sonraki 1 hafta içerisinde aynı PC mesai saatleri dışında internet istekleri yapıyorsa uyar,

Aynı kullanıcı önce Linux sunucuda oturum açıyor daha sonra da windows sunucuda oturum açıyor ve ardından bu iki sunucudan birinde servis kapatılıyor ise bildir.

Bir kullanıcı kullanıcısı herhangi bir sunucuya sunucusuna login olamayıp authentication failure a sebep olduktan sonra 2 saat içerisinde aynı kullanıcının aynı sunucuya başarılı

oturum açmadığı takdirde uyar

UnusualUDPTraffic üreten kaynak IP yi bildir (Taxonomy modülü gerektirir)

IPReputation Listesindeki bir kaynaktan veya o kaynağa bir trafik oluşursa uyar

Bir IP den tarama yapıldı ise ve sonrasında aynı IP den başarılı bir bağlantı kuruldu ise ve ardından bağlantı kurulan IP den tarama yapılan IP ye geriye bağlantı kuruldu ise uyar.

Korelsayon ile ilgili daha detaylı teknik bilgiler içeren aşağıdaki çalışmaya bakılabilir

http://www.slideshare.net/anetertugrul/log-korelasyon-siem-kural-ornekleri-ve-korelasyon-motoru-performans-verileri