Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Log Yönetimi SIEM Demek Değildir!

1.009 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Log Yönetimi SIEM Demek Değildir!

  1. 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. 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. 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. 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. 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

×