"Security" SIEM çözümlerinin asıl amacı. Güvenlik olaylarını yakalayabilmek için SIEM kuruyoruz log toplamak için değil, eğer tek amaç log toplamaksa log yönetimi çözümü mesela ücretsiz ELK kullanabilirsiniz. Bu yazıya devam etmeden önce iki kavramı açıklayalım Parse etme: Logu ayrıştırma demektir. Logun SRC,DST,SRCPORT,DSTPORT,URL,USER vb.. alanlara bölünmesi ve daha sonra da bu alanlar üzerinden arama, tarama ve raporlama yapılabilmesini sağlamak. Eğer bir üründe bir log parse edilemiyorsa kolaylıkla o ürünün sağladığı API, XML formatı veya ara yüz ile parser geliştirilebilir. Taxonomy: Parse edilmiş loga context koyma işi. Yani bu log ne ile ilintili? Neden oluşmuş ? Hangi olayın bir parçası? Gibi bilgileri bulma işine taxonoym diyoruz. Ayrıca diğer log kaynağı ürünlerle tutarlı bir şekilde gruplanması da yine bu modülün işi ve parser yazarak halledilebilecek bir durum değil.

1. SIEM olarak adlandırılan çözümler ve birbirlerine göre
avantaj/dezavantajları nelerdir? Global ürünler (Gartner listesinde
olanlar), ödüllü olanlar ve SureLog
"Security" SIEM çözümlerinin asıl amacı. Güvenlik olaylarını yakalayabilmek için SIEM
kuruyoruz log toplamak için değil, eğer tek amaç log toplamaksa log yönetimi çözümü
mesela ücretsiz ELK kullanabilirsiniz.
Bu yazıya devam etmeden önce iki kavramı açıklayalım
Parse etme: Logu ayrıştırma demektir. Logun SRC,DST,SRCPORT,DSTPORT,URL,USER vb..
alanlara bölünmesi ve daha sonra da bu alanlar üzerinden arama, tarama ve raporlama
yapılabilmesini sağlamak. Eğer bir üründe bir log parse edilemiyorsa kolaylıkla o ürünün
sağladığı API, XML formatı veya ara yüz ile parser geliştirilebilir.
Taxonomy: Parse edilmiş loga context koyma işi. Yani bu log ne ile ilintili? Neden oluşmuş ?
Hangi olayın bir parçası? Gibi bilgileri bulma işine taxonoym diyoruz. Ayrıca diğer log kaynağı
ürünlerle tutarlı bir şekilde gruplanması da yine bu modülün işi ve parser yazarak halledilebilecek
bir durum değil.
Bu iki kavram birbirinden çok farklı ama çokça aynı imiş gibi algılanmakta ve çok önemli iki
kavram olduğu için yazının devamın da da sık sık tekrarlanacaktır.
SIEM çözümü size log yönetimi ile elde edemeyeceğiniz bilgiler sunabilmeli. Bir logu SRC, DST,
SRCPORT, DSTPORT, URL, USER vb.. gibi parçalara neredeyse bütün ücretli/ücretsiz log
ürünleri yapabilir durumda ve bu iş için ücretsiz de pek çok alternatif mevcut. Aşağıda
örneklerini verdiğimiz logların çoğunu bütün ürünler SRC, DST, SRCPORT, DSTPORT, URL,
USER vb.. alanlara başarı ile bölebilmekte ki buna parse işlemi deniyor. Ama esas iş parse
edilmiş loga context koyma işi ki buna taxonomy deniyor. Yani bu log ne ile ilintili? Neden
oluşmuş ? Hangi olayın bir parçası? Onu bulmaya çalışıyorsunuz
SIEM çözümü size log yönetimi ile elde edemeyeceğiniz bilgiler sunabilmeli demiştik. Bu
sunulan bilgiler de her SIEM ürününde aynı derinlikte, kapsamda ve aynı oranda faydalı
değildir. Aşağıdaki örneklerde ürünler logları SRC, DST, SRCPORT, DSTPORT, URL, USER
vb.. alanlara başarı ile ayrıştırabilmekte (ayrıştıramayanları de parser desteği ile parçalamak
kolaylıkla mümkün) ve daha sonra da bu alanlar üzerinden arama, tarama ve raporlama
yapabilmekte ama bu logların ne için oluştuğu mesela “birisi FW a login olmuş” veya “login
olmayı denemiş“ gibi bulamıyor ya da bulduğu durumlarda bu bir SQL injection saldırısıdır
demek yerine bir atak var demekle yetiniyor. Loga bir context eklem işi parser yazmak kadar
kolay değil ve daha sonra danışman veya son kullanıcıların kolaylıkla yapabileceği bir iş değil
çünkü 400 a yakın cihazın 32 000 civarı log formatının yazılımın tasarımında nasıl gruplandığı
da bilinmeli.
Bu bölümde ürünlerin taxonomy özelliklerinden bahsedeceğiz.
İlk log formatımız SSH kullanarak bir fortigate firewall a yönetmek üzere bağlanmaya çalışma
denemesini gösteren bir log. Burada birileri Fortigate a bağlanıp onu yönetmeyi denemiş.

2. Log formatı : “date=XXXXX time=00:20:15 devname=ANET_PRIMARY devid=FG200E4Q17901634
logid=0001000014 type=traffic subtype=local level=notice vd=root srcip=##### srcport=63911 srcintf=wan1
dstip=##### dstport=22 dstintf=root sessionid=50693980 proto=6 action=deny policyid=0 policytype=local-in-policy
dstcountry=Turkey srccountry=Latvia trandisp=noop service=SSH app=Console Management(SSH) duration=0
sentbyte=0 rcvdbyte=0 sentpkt=0 appcat=unscanned crscore=30 craction=131072 crlevel=high”
Bu logun Gartner SIEM magic quadrantta olan bir ürün tarafından analizi sonucunda
“Fortigate/Fortigate: Traffic End Local” tipinde olduğunu söylerken
Aynı loga yine Gartner tarafından ödül verilen başka bir ürüne ile bakarsak logu hiç
tanıyamadığını (context ekleyememiş, taxonomy belirleyememiş) hatta parse bile edememiş
(ama bunu bir parser yazarak halledebiliriz ama bu loga taxonomy eklemek için bütün
fortigate FW log kombinasyonunu (çünkü bu üründe başka hangi taxonomy lerin eksik
olduğunu bilmiyoruz) ve parser ile atayacağımız taxonomy lerin SIEM ürününü genel
çerçevesine uygun olması gerekir ki son kullanıcı açısından son derece zor bir durumdur)
olduğunu görürüz.
ANET SureLog bunu “SSH Attack” olarak tanıyabiliyor.
NOT: Bu log SureLog tarafından“Informational.Authentication.Failed” olarak da tanınabilirdi. Ama Üretici veritabanına
bakarak (signature database) ve data mining ile bunun bir SSH Atack olduğuna karar verdi. Yani SureLog bir adım daha
öteye götürdü.

3. Aşağıdaki log da Fortigate firewall tarafından bir saldırı olarak tespit edilen bir durumda
oluşan bir log.
Log formatı: “date=DATE time=TIME device_id=FG100D3G12812498 log_id=0421073001 type=ips
subtype=anomaly pri=alert vd=root attack_id=285212775 src=SRC dst=DST src_port=SRC_PORT dst_port=DST_PORT
src_int=port4 dst_int=n/a status=detected proto=17 service=2967/udp msg="anomaly: udp_dst_session, 5110 >
threshold 5000, repeated 42 times"”
Test ettiğimiz ve Gartner referansı olan 2. ürün tarafından aşağıdaki Fortigate log formatının
taxonomy bilgisine erişemediğini görüyoruz.
Aynı logu ANET SureLog a gönderdiğimiz zaman “Flow.Fragmentation” olarak tespit ediyor.
Yukarıda örnek log formatları global olarak tanınan ve Gartner SIEM Magic Quadrant’ta
kendine yer bulmuş ürünlerin de logu doğru tanıyamamasına (her ürün src, dst, portlar,
username vs... bulur ama logu tanıma/tanımlama yani taxonomy bu demek değil) örnek
olacak bir durum olarak verildi.
Ayrıca bazı SIEM çözümleri logu tanısa/tanımlasa bile yüzeysel ve basit bir tanıma yapma ve
gerekli derinliği erişememekte
Bu duruma bir örnek vermek gerekirse;
Log formatı : “date=DATE time=TIME devname=FGT100D devid=FG100D3G13809338 logid=0419016384 type=utm
subtype=ips eventtype=signature level=alert vd="root" severity=high srcip=SRC dstip=DST srcintf="PUBLIC"
dstintf="INTERNAL" policyid=183 identidx=0 sessionid=105176668 status=detected proto=6 service=http count=1
attackname="HTTP.URI.SQL.Injection" srcport=SRC_PORT dstport=80 attackid=15621 sensor="default"
ref="http://www.fortinet.com/ids/VID15621" incidentserialno=1362017780 msg="web_misc:
HTTP.URI.SQL.Injection,"”
şeklindeki bir logun 1. Test ettiğimiz ürün tarafından analizi sonucunda “Fortigate: Attack
log - Signature: An attacksignature (TCP/UDP)” tipinde olduğunu söylerken
Aynı loga 2. Test ettiğimiz ürün ile bakarsak taxonomy olarak yukarıdaki ile neredeyse bire bir
aynı tanımlama yaptığı yani “Attack Signature TCP UDP olarak ” bulduğu görülür.

4. Her iki ürün de Taxonomy olarak bir tanıma/tanımlama yaptı ama çok genel bir tanımlama
oldu. Aynı logu ANET SureLog a gönderdiğimiz zaman “Malicious.Web.SQL” olarak tespit
ediyor. Yani çok daha detay ve derin bir anlamlandırma yapıyor.
Örnekleri arttırmak gerekirse
Log formatı: “date=DATE time=TIME device_id=FG100D3G12812498 log_id=0421073001 type=ips
subtype=anomaly pri=alert vd=root attack_id=285212775 src=SRC dst=DST src_port=SRC_PORT dst_port=DST_PORT
src_int=port4 dst_int=n/a status=detected proto=17 service=2967/udp msg="anomaly: udp_dst_session, 5110 >
threshold 5000, repeated 42 times"”
Olan bir log gartner listesindeki ilk üründe Fortigate: Attack Log Anomaly evet olarak
tanımlanıyor
2. test ettiğimiz ürün ise logu sadece SRC, DST, SRCPORT, DSTPORT, URL, USER vb..
alanlara başarı ile bölebilmekte ve daha sonra da bu alanlar üzerinden arama, tarama ve
raporlama yapabilmekte ama bu logların ne için oluştuğunu yani Taxonomy sini
bulamamakta.
Aynı logu ANET SureLog a gönderdiğimiz zaman “Flow.Fragmentation” olarak tespit ediyor.
Aşağıda Fortigate FW un arayüzüne (hhtps) login olan bir kullanıcı logu gözükmekte.
Log formatı : “date=DATE time=TIME devname=ANETFW devid=FGT60C3G10010847 logid=0100032001
type=event subtype=system level=information vd="root" logdesc="Admin logged in successfully" user="mrdgqv"
ui=https(192.168.2.60) action=login status=success reason=none profile="super_admin" msg="Administrator mrdgqv
logged in successfully from https(192.168.2.60)"”
Ama bu log test ettiğimiz 1. Ürün ile incelenirse tanıma/tanımlama( Taxonomy) yapamadığı ve
sadece SRC, DST, SRCPORT, DSTPORT, URL, USER vb. alanlara ayırıp bırakmakta
Aynı loga yine Gartner tarafından ödül verilen başka bir ürün ile bakarsak hiç
tanıma/tanımlama (taxonomy) yapamadığı sadece yine logu SRC, DST, SRCPORT, DSTPORT,
URL, USER vb.. parçalara ayırabildiğini görürüz

5. Aynı log ANET SureLog tarafında “Informational.Authentication.Succesful” olarak
tanınmaktadır.
Bu ürünler arasındaki logu tanıma/tanımlama farkı veri madenciliği (data mining)
kapasitelerinden gelmektedir.
NOT: Yazı dizisine korelasyon ile devam edeceğiz