Log Yönetimi SIEM Demek Değildir!. Türkiyedeki pek çok projede Log Yönetimi ile SIEM aynı şey olarak algılamakta. Hatta Log Yönetimine ufak ve basit bir modül eklenerek SIEM yapıldığı sanılmaktadır. Aslında ise SIEM Log Yönetiminden çok farklı ve kompleks bir sistemdir. SIEM bir log toplama, parçalara bölüp sonra da arama demek değildir.

1. Log Yönetimi SIEM Demek Değildir!
Dr. Ertuğrul AKBAŞ
eakbas@gmail.com
ertugrul.akbas@anetyazilim.com.tr
Maalesef Log Yönetimi ve SIEM aynı şeymiş gibi algılanmaktadır. Hatta SIEM i log yönetiminin bir alt
kümesi veya biraz özelleşmiş hali olarak görenler de çoktur. Bu iki görüş de hatalıdır. Hatta maalesef
bu iki görüş sahipleri bu görüşleriyle kurumsal güvenlik politikalarına negatif etki yaparlar ve güvenlik
politikalarında indirgeyici bir yönetim sergilemiş olurlar. Şöyle ki Log Yönetimi logları toplama,
anlamlandırma (aggregate) ve raporlama içerir SIEM ise güvenlik açısından bu anlamlandırılan verileri
gerçek zamanlı analiz etmeyi ve alarm üretmeyi içerir. SIEM ve log yönetimi farkı:
 Sınıflandırma (Taxonomy)
 Korelasyon
 Alarm
Logları toplamak ve hızlı arama (search) veya raporlama yapabilmek SIEM demek değildir. Log
Yönetimi konusunda onlarca çok iyi ve hızlı açık kaynak kodlu ürün de mevcuttur
• Twitter log Storm (Apache Storm)
• Kibana/elasticsearch/logstash
• Graylog
• http://www.fluentd.org
Bu ürünler twitter , facebook gibi saatte TB larca dayı işleyebilen global firmalar tarafından geliştirilip
sonra da açık kaynak dünyasına sunulmuş sistemlerdir. Bu konuda pek çok açık kaynaklı komponenet
mevcuttur. Mesela Hadoop ve elasticsearch kullanarak çok çok hızlı bir log toplama ve arama
yazılımını çok kolay oluşturabilirsiniz. Bu komponentlere ve kaynak kodlarına hem ticari hem de
akademik erişim mümkündür.
https://hadoop.apache.org/
https://www.elastic.co/

2. Sınıflandırma (Taxonomy)
Peki log toplama, arama ve raporlama ürünleri ile neleri yapamazsınız.
Aşağıdaki NetScreen logunu
Feb 15 22:01:35 [xx] ns5gt: NetScreen device_id=ns5gt [Root]system-alert-00016: Port scan! From
1.2.3.4:54886 to 2.3.4.5:406, proto TCP (zone Untrust, int untrust). Occurred 1 times. (2014-02-15
22:09:03)
logunu kaynak IP şu, Hedef IP bu, hedef ve kaynal portlar da bunalar gibi ayırmak için onlarca ücretsiz
log yönetim ürünü mevcut. Hatta bunların içerisinde twitter ve facebook tarafından geliştirilip
kendileri tarafından da kullanılan ve de ücretsiz dağıtılanlar da mevcut
Ama aynı logu kaynak IP şu, Hedef IP bu, hedef ve kaynal portlar da bunalar dedikten sonra bu logu
"Reconnaissance->Scan->Host" şeklinde kategorize edip bunu korelasyona sokmalıyım ve alarm
üretmeliyim diyebilmek ayrı bir boyuttur. Bu sınıflandırma (Taxonomy) ile yapılabilir ve SIEM
ürünlerinden belirli bir seviyenin üstündekilerde mevcuttur.
Benzer şekilde
Aşağıdaki Sonıcwall logunu
id=firewall sn=0017C5598622 time="2015-02-13 16:20:31" fw=xxx.xxxx.xxx.xxx pri=6 c=1024 m=537
msg="Connection Closed" n=0 src=xxx.xxx.xxx.xxx:4854:X1:
dst=yyy.yyy.yyy.yyy:53:X1:ttdns40.ttnet.net.tr proto=udp/dns sent=75 rcvd=414
Kaynak IP, Hedef IP, Kaynak port ve Hedef portlar şeklinde ayırabiliriz. Sonrasında Kaynak IP ye veya
URL e göre listeleme yapabiliriz.
Ama aynı logu "NamingTrafficAudit" şeklinde kategorize etmek ayrıştırıcı bir özelliktir. Bu
Sınıflandırma (Taxonomy) ile yapılabilir ve SIEM ürünlerinden belirli bir seviyenin üstündekilerde
mevcuttur.
Benzer şekilde
... type=utm subtype=ips eventtype=signature level=alert vd="root" severity=high srcip=xx
attackname="HTTP.URI.SQL.Injection" srcport=a dstport=80 attackid=15621 sensor="default"
ref=.. incidentserialno=... msg="web_misc: HTTP.URI.SQL.Injection,"
şeklindeki bir logu IP ler şunlar, portlar da bunalar gibi ayırmak için onlarca ücretsiz log yönetim
ürünü mevcut.
Ama aynı logu "Malicious->Web->SQL" şeklinde kategorize etmek ayrıştırıcı bir özelliktir. Daha sonra
da eğer Malicious->Web->SQL olursa kaynak IP yi mail at gibi korelasyona sokabilmek çok üstün bir
özelliktir.

3. Bir örnek daha vermek gerekirse
Aşağıdaki logu
.. type=ips subtype=anomaly pri=alert vd=root attack_id=285212775 src=xxx dst=yyy src_port=12
dst_port=2967 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"
IP ler şunlar, portlar da bunalar gibi ayırmak için onlarca ücretsiz log yönetim ürünü mevcut. Ama
aynı logu "Flow->Fragmentation" şeklinde kategorize etmek ayrıştırıcı bir özelliktir. Daha sonra da
eğer Flow->Fragmentation olursa kaynak IP yi mail at gibi korelasyona sokabilmek çok üstün bir
özelliktir.
Ayrıca bir firewall login işlemi yapıldığında oluşan
Administrator XXXXX logged in successfully from https(XXX.XXX.XXX.XXX)
HealthStatus->Informational->Session->Start şeklinde kategorize etmek için geniş bir Taxonomy
kütüphanesi gerekir.
Dolayısı ile logları
Reconnaissance->Scan->Host
Malicious->Web->SQL
Flow->Fragmentation
NamingTrafficAudit
httpproxy - >TrafficAudit accept
HealthStatus->Informational->Session->Start
gibi binlerce kategori altında birleştirmek çok az üründe olan üstün bir özelliktir.

4. Korelasyon
Korelasyon sınıflandırma (taxonomy) ile birlikte SIEM sisteminin en can alıcı 2 yapısal taşından biridir.
Bir SIEM çözümünün gerçek manada korelasyon motorunun olup olmadığını anlamak için verinin
indekslenmiş olmasına ihtiyaç duymaması gerekir. Çok nadiren ürünlerin bazıları indekslenmiş veri
üzerinde periyodik sorguları çalıştırıp adına korelasyon demektedir. Bu global bir yöntem olmadığı
gibi dünyada uygulaması da genel kabul görmüş değildir.
Temel olarak sorguların veri tabanı veya indekslenmiş veri üzerinde çalışmasından kaynaklanan
zaaflar 3 adettir
1. SQL/ NoSQL DB , indekslenmiş veriler üzerinde yüzlerce scriptin belli periyotlarla çalıştırılması
bir performans problemine sebep olur. Çok sayıda kural yazılamaz
2. Kurallar Hafızada çalışmadığı için olaylar anında yakalanamaz
3. Script veya sorgu [SQL/ NoSQL] veya diğer ) bağımlı olduğu için gelişmiş kurallar yazılamaz
Ayrıca bu yöntem global olarak kullanılan bir yöntem de değildir. Bu yöntemin global referansları
yoktur.
Bir korelasyon motorundan beklenen özellikler:
 Görsel bir editör e sahip olması
 Gelişmiş kurallar yazılabilmesi:
o Önce A olayı olursa ve Aynı kaynak ve Kullanıcı 15 dakika içerisinde B olayını
gerçekleştirmez ise ve sonrasında D olayı olursa uyar
o Sadece öğle yemeği sırasında A olayı olursa uyar
o Sadece hafta sonu D olayı olursa uyar
o Bir olay olduysa 1 saat bir daha uyarma
o Birbirinden farklı kaynak ve portlardan ama yanı kullanıcı tarafından dakikada X olay
olursa uyar.
 Sınıflandırma modülü ile entegrasyon
o Port taraması olduğunda haber ver
 Gerçek zamanlı olması ve hafızada çalışması. İndekslenmiş veri üzerinden sorgu şeklinde
çalışmaması.

5. Yukarıdaki resimde de görüldüğü gibi en fazla saldırı alan ilk 5 ülkeden biriyiz. Çoğu zaman aldığımız
saldırının bile farkında olamayabiliriz. SIEM güvenlik yönetiminde en önemli bilişenlerden biridir.
Gerçek bir korelasyon motoruna ve bir korelasyon editörü/sihirbazına sahip olup olmamasının
kontrolü ise öncelikli olarak korelasyonu gerçek zamanlı ve hafızada (in memory) mi yapıyor yoksa
belli periyotlarla çeşitli yöntemlerle üretilen sorgu/scripti çalıştırarak sonuç üretmeye mi çalışıyor
ayrımından geçiyor.
Ayrıca herhangi bir özel sorgu, script, sql vb.. genelde son kullanıcıya hitap etmeyen yöntemlere mi
ihtiyaç duyuyor yoksa kolay bir korelasyon sihirbazına mı sahip bakmak gerekir.
Son olarak da güvenlik yönetimi için gerekli gelişmiş korelasyon kuralları geliştirilebiliyor mu ona
bakmak lazım. Örnek
• A kullanıcısı X sunucusuna login olamayıp authentication failure a sebep olduktan sonra 2
saat içerisinde aynı A kullanıcısının aynı X sunucusuna başarılı oturum açmadığı takdirde uyar
• Bir dakika içerisinde 60 adet birbirinden farklı portlardan ama aynı kaynaktan A olayı
olduktan sonra aynı kaynaktan 5 dakika içerisinde B olayı olup ardından yine aynı kaynaktan C olayı
gerçekleşmez ve ardından yine aynı kaynaktan D olayı gerçekleşirse uyar
• Saat 12:00 13:30 arasında A olayı X adet olursa uyar
• Mesai saatleri dışında A olayı olursa uyar ama uyarı miktarı X i geçerse artık uyarma
• UnusualUDPTraffic üreten kaynak IP yi bildir
• UnusualTCPTraffic üreten kaynak IP yi bildir
Konu ile ilgili aşağıdaki dokümanlara da incelenebilir.
http://www.slideshare.net/anetertugrul/log-ynetimi-ve-siem-fark
http://www.slideshare.net/anetertugrul/surelog-largescale-siem-implementation-in-a-distributed-it-
security-world
http://www.slideshare.net/anetertugrul/korelasyon-gstermelk-deldr
http://www.slideshare.net/anetertugrul/surelog-applying-the-lockheed-martin-cyber-kill-chain
http://www.slideshare.net/anetertugrul/sure-log-context-sensitive-scalable-siem-solution
http://www.slideshare.net/anetertugrul/siniflandirma-temell-korelasyon-yaklaimi
http://www.slideshare.net/anetertugrul/log-yonetimi-ve-siemkontrol-listesi