Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Log yonetimi korelasyon ve SIEM

1 115 vues

Publié le

Korelayon yöntemleri, bunların SIEM ürünlerindeki uygulamaları ve avantaj/dezavantajları
ile birlikte QRadar, SureLog, Splunk gibi uygulamalardaki kullanımları nelerdir?

Publié dans : Technologie
  • Soyez le premier à commenter

Log yonetimi korelasyon ve SIEM

  1. 1. Log Yönetimi, Korelasyon ve SIEM Dr. Ertuğrul AKBAŞ eakbas@gmail.com SIEM çözümünün Log Yönetimi çözümlerine göre en temel farkı Korelasyon ve ürettiği alarmlardır. SIEM ürünlerinde Korelasyon özelliği temelde 2 ana gruba ayrılır.  Korelasyon Motoru Olan Çözümler o ANET SureLog o AlianVault o BlackStratus o EMC(RSA) o EventTracker o FortiSIEM (AccelOps) o HP (ArcSight) o IBM (QRadar) o Intel Security (McAfee) o LogRhythm o NetIQ (Novel) o Solarwinds o TrustWave  Periyodik arama sorgusu çalıştıran ürünler o Elastic-Alert(Watcher) o ElasTalert o Loggly o LogPoint o LogSign o SumoLogic o Splunk
  2. 2. Korelasyon Motoru Olan Çözümler Bu gruptaki ürünlerin hepsi ayrı bir modül olarak ayrı bir korelasyon motoru içerir. İyi veya kötü bir korelasyon geliştirme sihirbazına sahiptir. Ürünlerin korelasyon motorlarının avantaj ve dezavantajlarına ayrı bir çalışmada değinileceği için burada bahsedilmeyecektir. Buradaki ürünleri de korelasyon motorları üçüncü parti (3rd party) yazılımlardan mı oluşmakta yoksa kendi AR-GE leri mi diye ayırmak mümkün. Bu ayarımın temel amacı da motorların esnekliği hakkında fikir sahibi olmaktır.  Kendi AR-GE Çalışmaları o ANET SureLog o AlianVault o BlackStratus o EMS(RSA) o EventTracker o Fortinate (AccelOps) o HP (ArcSight) o Intel Security (McAfee) o LogRhythm o NetIQ (Novel) o Solarwinds o TrustWave  Üçüncü Parti (3rd Party) o IBM (QRadar)  http://www.eventgnosis.com/ Aşağıdaki AR-Ge sini kendi yapan ve gelişmiş bir kural editörüne sahip bir çözümün kural editörü gözükmektedir.
  3. 3. Periyodik Sorgu Çalıştıran Ürünler Bu gruptaki ürünlerin hiçbirinde ayrı bir modül olarak bir korelasyon motoru yoktur. Örnek ürünler:  Elastic-Alert(Watcher)  ElasTalert  Loggly  LogSign  SumoLogic  Splunk Bu tarz ürünler filtreleme ve arama için kullandıkları sorgu formatın ekrandaki text alanlarına sorgu , arama dili veya özel notasyonlu cümlecik yazmak şeklinde kuralları oluşturup belli periyotlarda ve belli veri kümeleri üzerinde çalıştırırlar. Bu tür korelasyon özelliklerinin temel bazı handikapları bulunur. Bunlar 1- Gelişmiş senaryolar oluşturulamaz 2- Bu yöntemi iyi kullanmak için biraz geliştirici (developer) olmak ve biraz da log kaynağını iyi bilmek ve logu tanımak gerekir. https://xiom.com/2016/11/29/understanding-siem-structured-search/
  4. 4. 3- Birden fazla kural arasında kural özellikleri (arribute) de kullanılarak cross correlation yapılamaz 4- Kurallar Hafızada çalışmadığı için olaylar anında yakalanamaz. Kurallar (Aslında Filtereleme ve arama için kullandıkları sorgu formatın ekrandaki text alanlarına sorgu , arama dili veya özel notasyonlu cümlecik yazmak şeklinde veya scriptler [SQL veya NoSQL]) periyodik çalıştırıldığı için bu periyod içindeki olaylar anında yakalanamaz 5- Sorgu veya filtrenin belli periyotlarla çalıştırılması bir performans problemine sebep olur 6- Kural yazmak son kullanıcı için hiç de kolay değildir. 7- Kurallar arttıkça ve/veya biraz karmaşıklaşınca CPU ve RAM ihtiyacı ciddi artmaktadır. Korelasyon kural sayısı, kuralların ne kadar kompleksliği ve EPS değerleri performansı çok ciddi etkileyen unsurlardır. Buna aşağıdaki çalışma değinmektedir. https://www.linkedin.com/pulse/siem-korelasyon-%C3%A7%C3%B6z%C3%BCmlerinde- aktif-kural-say%C4%B1lar%C4%B1-ve-gerekli-akbas Bu ürünler aslında bir korelasyon ürünü değildir, çünkü: 1- Ayrı bir korelasyon motoruna sahip değildir 2- Alarm modülü tamamen log arama sorgularını periyodik olarak çalıştırma üzerine kuruludur
  5. 5. Periyodik Sorgu Temelli Alarm Modülü Alarm modülü tamamen log arama sorgularını periyodik olarak çalıştırma üzerine kuruludur: Aşağıda yukarıdaki uygulamalardan birinden alınan bir ekran görüntüsü gösterilmiştir. Resme bakarsanız run this alert every ve check events in last alanlarını görürsünüz. Bu alanların anlamı bu ekranda hazırladığınız sorguyu hangi periyotta çalıştıracağınızı size soruyor ve daha kötüsü check events in last alanında da yakalamak istediğiniz olayın oluştuğu zaman dilimini bilmeniz isteniyor. Örnek vermek gerekirse; her 5 dakikada 1 son 10 dakikaya bak deseniz bile 10 dakikada 2 veya daha fazla login failed oluşturan kullanıcıyı bulamama ihtimaliniz olur. Aşağıdaki resimde açıklamaya çalıştığım gibi siz T10 anında geriye doğru 10 dakikayı taradınız sonra 5 dakika beklediniz ve T15 anında geriye doğru taradınız ama olaylar T3 ve T11 de olmuştu ve T3 ile T11 iki farklı taramanın içinde kaldığı için yakalanamadı. Aklınızı o zaman ben de her 30 saniyede tararım veya 10 saniye tararım gelebilir o zaman da öncelikli olarak her 10 saniyede arkada bir sorgu çalışacağı için CPU ve RAM kullanımımınız artacak hem de hala bu 5 dakikada bir mi çalışsın 10 saniyede bir mi çalısın geriye doğru 10
  6. 6. dakikaya mı baksın 20 dakikaya mı vb.. parametreleri siz manuel set etmek ve bilmek zorundasınız. Benzer şekilde gerçek zamanlı (realtime) seçeneği de içeren diğer bir ürünün alarm hazırlama ekranları. Yukarıda ekran görüntüleri paylaşılan ürüne göre realtime alarm özelliğine sahip. Bunula birlikte real time özelliğinin hem çeşitli kısıtları hem de performansı zorlayıcı etkileri vardır. https://help.sumologic.com/Dashboards_and_Alerts/Alerts/Create_a_Real_Time_Alert
  7. 7. Ayrıca arama modülü yukarıdaki yapıyı kullansa bile çok temel analizleri yapmaktan uzaktır: Önemli bazı güvenlik kontrolü kuraları yazılamaz. Yazılamayacak Örnek Kurallar: 1. Aynı dış IP den birbirinden farklı iç IP lere ve birbirinden farklı portlara 15 dakikada 100 den fazla paket bloklanıyor ve daha sonra 1 saat içinde bu bloklanan iç IP lerin tamamından yeni bir process ayağa kalkıyorsa uyar 2. FW tarafından bir Dış IP’den aynı İç IP ye gelen trafik 1 dakikada 50 den fazla bloklanıyorsa ve daha sonra aynı İç IP den aynı Dış IP ye 2 saat içerisinde trafik isteği oluşursa uyar 3. 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, Aşağıdaki SIEM kural örnekleri bölümünde verilen kuralların önemli bir kısmını sorgu ile yazmak imkânsızdır. Alarm yazmak son kullanıcı için hiç de kolay değildir: Aşağıdaki ekrandaki bütün alanları ve özellikle 2 adet query alanını sizin doldurmanız gerekir. Son olarak da bu yöntemi iyi kullanmak için biraz geliştirici (developer) olmak ve biraz da log kaynağını iyi bilmek ve logu tanımak gerekir. https://xiom.com/2016/11/29/understanding-siem-structured-search/ . Bu da her son kullanıcının yapabileceği bir şey değildir.

×