Ajanlı ve ajansız log toplama
- 1. LOG YÖNETİMİNİNDE AJANLI VE AJANSIZ YÖNTEMLERİN
KARŞILAŞTIRILMASI
Dr. Ertuğrul AKBAŞ
Kelimeler: Bilgi Güvenliği, Log Yönetimi, Log Analizi, Kurumlarda Log Yönetiminin
Gerekliliği, 5651 Sayılı Yasa, Log Yönetimi, Log Normalleştirme, SIEM,SYSLOG,SNMP,Ajanlı
ve Ajansız Log Toplama
Log yönetimi sistemlerinin nihai hedefi güvenlik analizini otomatik olarak yapabilecek sistemi
kurmaktır.
Bu sistemi kurarken logların analiz edilecek merkezi yönerim sistemine aktarımında 2 farklı yöntem
kullanılar
Ajanlı Sistemler
Ajansız Sistemler
Bu iki sistem arasında temel olarak yönetim kolaylığı, sistem kaynaklarının kullanımı,kurulan
sistemin esnekliği konularında temel farklılıklar mevcuttur.
- 2. Yukarıda Gartner 2011 raporunda yansıtılan ürünler görülmektedir.Leader segmentindeki Archsight
,Q1labs, RSA, Symantec, Loglogic, NitroSecurity ve Novell ya %100 ya da büyük oranda java ile
geliştirilmiş ve ajan kullanmayan çözümlerdir.
Aşağıda ajanlı sistemlerle ajansız sistemleri karşılaştıran iki farklı tablo göreceksiniz.
- 3. Temel log analizi Ek işlemci ve Ek trafik yükü Gartner raporunun Akademik Güvenlik
fonksiyonu mu? cpu kullanımı getiriyor mu? liderler sekmesindeki olarak daha zaafiyeti
gerekiyor mu? herhangi bir ürün iyi bir yöntem oluştur mu?
tarafından kullanılan olduğu rapor
bir teknoloji mi? edilmiş mi?
USB, PrintScreen, Hacker Hayır Evet Evet Hayır Hayır Hayır
aktiviteleri
Ağ bağlantısı olmadığında Evet Evet Hayır Hayır Hayır Hayır
veya log sistemi hizmet
veremiyorken oluşan
olayları biriktirme ve sonra
gönderme
Gürültü olaylarını Hayır Evet Hayır Hayır Hayır Evet[1]
kaynağında filtreleme
Tablo:Ajanlı sistemlerin temel log analizi fonksiyonları açısından analizi
Ajanlı Ajansız Açıklama
Gürültü olayları kaynağında filtreleme Evet Hayır Logların filtrelenmemesi gerektiği ile ilgili
Los Alamos National Laboratory de
yapılmış ve daha sonra NSA da kullanılmış
veriler var [1]*.
Yaratacağı network trafiği Çok Az Ajanları yönetmek için de ekstra trafik
oluşacağı için ajanlı sistem daha çok trafik
üretir.
Ağ bağlantısı olmadığında veya log sistemi hizmet veremiyorken oluşan Evet Evet Ajansız sistemler de bu özelliği
olayları biriktirme ve sonra gönderme sağlayabilir. Örnek: Windows işletim
sisteminde logları dosya boyutuna veya
zaman göre biriktirme ve saklama özelliği
mevcut.
Log kayıtları dışındaki olayları yakalayabilme (USB, PrintScreen, Evet Kısmen Ajansız sistemler de bu özelliği
Hacker aktiviteleri, Registry, FileSystem, v.s.) sağlayabilir. Örnek: Windows işletim
sisteminde FileSystem ve Registry i
uzaktan okumak mümkün.
Sisteme getireceği yük Çok Yok
Uygulama kurma gereksinimi Var Yok
Sistemde açılması gereken portlar yüzünden güvenlik açığı Yok Yok Ajanlı sistemin de merkezle konuşmak için
port açmaya ihitiyacı var.
Yönetim Zorluğu Çok Yok Özellikle büyük sistemlerde ajan yönetimi
ciddi bir iş yükü getirmektedir.
Genişleme Esnekliği Yok Çok Ajanlı sistemde her eklenen yeni sisteme
Kolay ajan kurulması zorunluluğu var
Tablo:Ajanlı ve Ajansız sistemlerin karşılaştırması
- 4. Sonuç
Yukarıdaki karşılaştırma tablosuna girmeyen ama ajanlı sistemleri kurup yönetenlerin dikkat
etmesi gereken bazı ufak noktalar da mevcuttur.Mesela ajanların herhangi bir yöntemle
kapatılması durumu ve ajanların lokal makinede açabileceği sorunlardan dolayı helpdesk
ekibindeki iş yükü artışı ve kuruldukları her makinede oluşması ihtimali olan yavaşlatma
senaryoları gibi..
Ayrıca ajanların merkezi yönetiminin ağa yapacağı ekstra trafik yükünün çok çok iyi
hesaplanması gerekir.
Diğer bir husus ise ğer networke geniş açıdan overview yaparsanız ortaya çıkacak bir maaliyet
hesaplaması konusudur. Ajanlı bir sistemde toplam işlem gücünün iyimser bir yaklaşıma %10
nunu bu ajanlı sisteme teslim etme keyfiyetidir. Örnek bir hesaplama yapılırsa 1000 cihazlık bir
ağda eğer ajanlar %10 CPU kullanırsa 100 makineyi de bu ajanlı sisteme tahsis etmiş gibi
olursunuz. Proje maaliyetlerine bunların katılması da isabetli olur.Eğer ajan kayda değer RAM
kullanıyorsa benzer hesaplama onun için de yapılabilir.
Ayrıca yine sistein maaliyet analizinde
-Olası yönetim zorluklarını
-Ne kadar donanım yatırımı yapıldığı?
-Ne kadar Veritabanı lisansı yatırımı yapıldığı?
-Ne kadar extra destek yükü gerektiğinin hesabını da yapmalıdır.
Ayrıca, büyük ağlarda ajanlı sistem beni ne kadar üreticiye yada yetkili çözüm ortağına
muhtaç ediyor? Üreticiye yada yetkili çözüm ortağı olmadan da ben bu sistemi yaşatabiliyor
muyum? diye fizibilite analizi ve hesabı yapılmalıdır.
Fizibilite analizinin temel olduğu özel sektörün bu parametreleri göz ardı etmeleri beklenemez.
Benzer yapının diğer sektörlerde de var olması gerektiği de aşikardır.
Son olarak da belirtmek lazım ki özellikle enterprise sistemlerde log yönetimi çözümü
seçiminde önemli pek çok parametre vardır. En azından bir tanesinden bahsederek konuyu
kapatmak istiyorum.Bu da ürünün korelasyon yeteneği[13]. Aşağıda özelliklerini saydığım
korelasyon özellikleri iyi bir ürünün olmazsa olmazlarındandır.
Hafızada Korelasyon Yapabilme
Tek Kaynak Korelasyon Kuralları
Çoklu Kaynak Korelasyon Kuralları
Negatif Condition Kuralları
- 5. Context Base Korelasyon
Hiyerarşik Korelasyon
Esnek kural oluşturma yapısı-Kural dili
Rule Base
ComplexEventProcessing
ForwardChaning
BackwardChaining
Kaynakça
[1] Dr. Ben Uphoff,[http://people.msoe.edu/~uphoff/
[2] ArielRabkinandRandyKatz.,Chukwa: A SystemforReliableLarge-ScaleLog Collection. At LISA 2010, the USENIX conference
on Large Installation System Administration. San Jose CA, November 2010
[3] http://chuvakin.blogspot.com/2011/07/top-10-criteria-for-siem.html
[4] www.loglogic.com
[5] www.novell.com
[6] http://www.novell.com/promo/slm/slm25.html
[7] www.q1labs.com/products
[8] http://www.trigeo.com/
[9] http://www.tenable.com/products/tenable-log-correlation-engine
[10] http://www.arcsight.com/products/
[11] www.symantec.com/business/security-information-manager
[12] www.java.com