Güvenlik projelerinde SIEM projelerinin sonunda başarıyı hedefliyoruz muyuz yoksa yapmış olmak için mi yapıyoruz? Pratiklerle Analiz Yaklaşımı
Günümüz dünyasında denetim, bilgi güvenliği, risk, uyum, iç kontrol veya BT profesyonellerinin gerçekleştirmiş olduğu denetimlerin, tutarlı, kanıtlarla ve çoklu kaynaklarla beslenmesi, teyit edilebilir olması, anlaşılabilir sonuçlar üretmesi, inkar edilemez dayanaklar üzerinde durması kriterleri, bu denetimlere güvence vererek güvenilir kılar. Bu bağlamda, bir denetimin günümüzde bu vasıflara sahip olmasında en güçlü destek, silah ve vektörlerden biri de SIEM ürünleridir diyebiliriz.
SIEM (security information and event management) projeleri UEBA (User and Entity Behavior Analytics) veya diğer eklentilerin popülerliğine rağmen hala siber güvenlik projelerinin göbeğinde oturmaktadır. Değişik eklentilerin çıkması bu gerçeği değiştirmemektedir.
Peki, bu projelerden ne amaçladığımızı projeye başlarken biliyor muyuz? SANS bir SIEM projesinde enerji, konsantrasyon ve vaktin %80 inin korelasyona ayrılmasını tavsiye ediyor[9]. Yine SANS “SIEM projelerini log yönetimi olarak düşünmeyin, ilk etapta korelasyonda kullanmayacağınız logları da hemen almayın, filtreleyin, sonra isterseniz parça parça logları arttırın” diye belirterek çok pratik ve gerçekçi tavsiyelerde bulunuyor.
Nedir korelasyon? Korelasyon; kısaca sistemler için haberdar olmanızda fayda olan olayları değişik algoritmalar kullanarak otomatik olarak ve gerçek zamanlı olarak tespit edebilmeye ve sizin için ne önem arz ediyorsa bunu çıktı olarak manalı hale getirmeye denir. Buna SIEM jargonunda korelasyon kuralları denir ve genelde ürünler hazır bir korelasyon kuralları kütüphanesi ile gelir. Bu kurallar arasında yetenek ve yöntem olarak çok büyük farklılıklar vardır. Dolayısı ile bu kuralların adedi veya adları değil, gerçekte neleri tespit edebildiği önemlidir.
SIEM projelerinde ürünün yeteneğine göre çok çeşitli senaryolar bulabilirsiniz. “DDOS agains single host” gibi “5 dakikada 50 defa aynı makinaya TCP veya UDP trafiği oluyorsa uyar” gibi çok basit ve false pozitife çok açık basit alarmlar da korelasyon olarak tanımlanır. “Bruteforce attack” şeklinde çekici ismi olan ama aslında plugin yani log kaynağı bağımlı (mesela pam_unix gibi sadece o kaynağa bağımlı) alarmlar da korelasyon olarak tanımlanıyor. Burada kullanıcının seçici olabilmesi gerekiyor.
Daha üst seviye ürünlerde “Aynı kullanıcı, Aynı makinada, 3 dakikada 3 den fazla oturum açmayı deneyip başarısız olursa, sonraki 3 dakikada aynı kullanıcı aynı makinada oturum açmazsa uyar” gibi daha insan üretimi mantık içeren kurallar bulunabilir.Daha gelişmiş ürünlere bakıldığında “Eğer rastgele olarak oluşturulmuş bir domaine trafik veya o domain den bize doğru bir trafik oluşursa bizi uyar” gibi senaryolar da mevcuttur.
Eğer ürün yeterince kuvvetli ve ekip gerekli tecrübe ve bilgiye sahip ise, kuralların kalitesi ve adedi çok daha fazla genişleyebilir. Peki ama bu bizi ne kadar ilgilendiriyor veya projede umduğumuz başarı ile bu tür analizler arasında nasıl bir ilişki var?
SIEM projelerinin tatmin edici bir sonuç üretmesi veya en azından ortalama bir başarı elde edebilmesi için son kullanıcının doğru soruları sorabilmesi gerekiyor. Aksi durumda pek çok projede görüldüğü gibi, SIEM adlı ve bütçeli bir proje ile Log Yönetimi yapılıyor.
Genelde PoC aşamasında çok detaylı analizden ziyade karar vermeyi kolaylaştıracak yöntemler bulmaya çalışırız.
GÜNÜMÜZDE LOG İLE İLGİLİ BÜTÜN ÜRÜNLER SIEM VE BÜTÜN SIEM ÜRÜNLERİ DE KORELASYON HARİKASI. O ZAMAN BAŞARI NEDEN AZ?
Ülkemizdeki log projeleri hep SIEM projeleri olarak pazarlanıyor. Aslında bu doğru bir yaklaşım olmayıp SIEM ile log yönetimi aynı şey demek değildir. Dünyada bu ayrım net iken Türkiye’de yapılan projelerde bu nüans gözden kaçıyor. Genelde olan, birşeyleri tespit etme konusuna hiç bulaşmayan SIEM projeleri veya 500 kişilik bir şirkette günde 50–100 tane alarm ile mail kutusuna bakılmamaya giden başarısız SIEM projeleri. Peki, bunun sebebi nedir?
1. Ürününün korelasyon yeteneği pazarlama amaçlı olup, satış sürecinden sonra çalıştırmak gibi bir hedef yok,
2. SIEM projesini bir lisans alımı veya “must” varlık olarak görüp projelendirmeyi hızlı geçmek.
Üreticilerin hepsinde hazır senaryolar (use case) değişik adlarla veya aynı adla ya da çok benzer adlarla bulunmakta. Peki, bu senaryoların tespit kabiliyeti aynı mı? Örnek olarak “Aynı kullanıcı, aynı makinada, 3 dakikada 3 den fazla oturum açmayı deneyip başarısız olursa, sonraki 3 dakikada aynı kullanıcı aynı makinada oturum açmazsa uyar” ile “Aynı kullanıcı, 3 dakikada 3 den fazla oturum açmayı deneyip başarısız olursa, sonraki 3 dakikada farklı Y kullanıcısı oturum açarsa uyar” senaryoları tamamen farklı iki senaryodur. Hatta 2. kuralın listede kalabalık yapmaktan ve false/pozitif çıktılar üretmekten başka bir işlevi yoktur.
Dolayısı ile SIEM projelerinde son kullanıcılar; senaryolar arasındaki farkları veya eşlenikleri algılamak zorunda kalmalıdır, bu gözden kaçar ise elma elma karşılaştırması yaptığını sanıp elma ile çürük elma karşılaştırması kararı verebilmekteler. Bu tür durumlarda nasıl bir analiz yapılabileceğine örnek olarak, bu iki senaryonun birbirinin aynısı veya eşleniği olmadığını, bu iki senaryoyu analiz ederek tespit etmeye çalışalım.
İki senaryo kesinlikle birbirinin aynı değildir. Burada kritik durum oturum açmazsa uyar kısmıdır. Öteki türlü senaryonun “farklı Y kullanıcısı oturum açarsa” senaryoya ek hiçbir katkı sağlamaz. Başarısız oturum açan kullanıcının gerçek niyetini size bildirmez. Ayrıca false pozitif oluşmasına sebep olur ki bu yaklaşım silsilesi ile birkaç ay sonra fuzuli loglarla dolmuş ve körlük oluşturmaya başlayan mail kutunuzun ilgili kısımlarına bakmaz istemeyebilirsiniz.
“Aynı kullanıcı, aynı makinada, 3 dakikada 3 den fazla oturum açmayı deneyip başarısız olursa, sonraki 3 dakikada aynı kullanıcı aynı makinada oturum açmazsa uyar” senaryosunun amacı GERÇEKTEN OLAYI ANLAYABİLMEKTİR. Bir insan yanlışlıkla, harf hatalarından dolayı, anımsamadığı için 3 veya daha fazla yanlış yapabilir ama bu yanlışlardan sonra 3 dakika içerisinde doğru şifreyle oturum açarsa her şey yolunda demektir. Bu doğru kural tanımıyla false pozitif oluşumunu da engeller. Ama 3 deneme yapıp çekip giderse bu denemelerden kuşkulanmak lazım.
Bu senaryoyu “Aynı kullanıcı, 3 dakikada 3 den fazla oturum açmayı deneyip başarısız olursa, sonraki 3 dakikada farklı Y kullanıcısı oturum açarsa şeklinde” kural seti ile denerseniz false pozitiften başka bir şey üremez. Şöyle ki birileri 3 başarısız deneme yaparken ve sonraki 3 dakika içerisinde başka birileri (Y kullanıcısı) doğru şifreyi girerse — ki bu yüzlerce kullanıcının olduğu bir networkde çok olağan bir durumdur — siz yine, körlük oluşturacak ve aslında tehdit olmayan, hem SIEM’i hem de sizi yoran yüzlerce false pozitif mail alırsınız.
Dolayısı ile üreticiler tarafından verilen senaryoların; adetlerinden ve kuralların nasıl isimlendirildiğinden çok faydaları ve yetenekleri önemlidir. Kullanıcının bu konuda dikkatli olmaması durumunda işin özü olması gereken elma elma karşılaştırması yapması imkânsızlaşır.
SIEM SENARYOLARININ (KURALLARININ) TUTARLILIK ANALİZİ NASIL YAPILIR?
SIEM projelerindeki; senaryoların ne anlam ifade ettiği, neyi tespit ettiği veya edemediği ve sizin bünyenizin ihtiyaç duyuduğu terzilik, projenin en önemli kısmıdır. Bununla birlikte son kullanıcı senaryoları iyi analiz etmelidir ve kendi senaryo sepetini damıtarak oluşturmalıdır, yoksa görünüşte her ürün bir SIEM’dir, her ürün korelasyon yapmaktadır ve her üründe taahüthere göre gelişmiş binlerce senaryo vardır.
Örneğin şu senaryoyu analiz edelim: “Mesai saatleri dışında 3'ten fazla virüslü dosya bildirimi oldu. 1 saat içerisinde VPN ile hatalı deneme yaptıktan sonra başarılı giriş yaptı. Critical serverlardan birine uzak masaüstü bağlantısı kurdu ve tehdit/threat listesindeki birden fazla IP adresi ile haberleşti.”
Bu senaryoda birden çok problem olduğu görülmektedir. Son kullanıcı olarak analiz ederken dikkat etmemiz gereken hususlar:
1. Bu senaryonun birden fazla noktasında zaman kavramı muğlak. Örnek:
· “1 saat içerisinde VPN ile hatalı deneme yaptıktan sonra başarılı giriş yaptı”. İfadede sadece “sonra başarılı giriş yaptı” ibaresi var. Bu “sonra”; 5 dakika sonra, 1 saat sonra veya 1 yıl sonra olabilir.
· “Başarılı giriş yaptı. Critical serverlardan birine uzak masaüstü bağlantısı kurdu.” Başarılı giriş ile Critical serverlardan birine uzak masaüstü bağlantısı kurdu arasındaki zaman bağlantısı yine yok.
· “Critical serverlardan birine uzak masaüstü bağlantısı kurdu ve tehdit/threat listesindeki birden fazla IP adresi ile haberleşti.” Critical serverlardan birine uzak masaüstü bağlantısı kurdu” ile “tehdit/threat listesindeki birden fazla IP adresi ile haberleşti” arasındaki zaman ilişkisi yine yok. [ve] kullanılmış. Mesela tehdit/threat listesindeki birden fazla IP adresi ile haberleşti ve Critical serverlardan birine uzak masaüstü bağlantısı kurdu şeklinde senaryoyu tam tersi çevirsek bir şey fark etmeyecek mi?
2. Aynı kullanıcı ve/veya aynı IP mi olduğu belirtilmemiş ama bundan daha kritik olanı bu aynı makinada mı kastedilmektedir yoksa sadece aynı IP ve/veya aynı kullanıcı yeter mi?
Yukarıdaki noktalar aydınlatıldıktan sonra bir de bu senaryoyu geliştirmek/tespit etmek için kullanılan teknoloji yeterli mi incelemek gerekmektedir.
“SIEM PROJELERİNDEKİ EN ÖNEMLİ HANDİKAPLARDAN BİRİ: FALSE POZİTİFLER”
SIEM çözümlerinin en temel zorluklarından biri false pozitifleri ayıklamaktır. Mail kutunuzu gereksiz veya can sıkıcı sayıda mail ile dolduran bir çözümü bir süre sonra verimli olarak kullanamazsınız, kullanmak istemezsiniz. False pozitifleri azaltmak için senaryo analizlerini iyi yapabilmek elzemdir. Bu bağlamda öncelikle kuralların adına değil içeriğine bakmak gerekir.”Excessive Firewall Denies” adlı veya benzeri bir kurala göz atalım. Adı çok güzel duruyor ama false pozitif üretme ihtimalini anlamak için kuralın tanımını incelememiz gerekmektedir. Örnek vermek gerekirse “Firewall Aynı makinaya gelen -hedef IP si aynı- trafik paketlerini 5 dakikada 50 tane bloklarsa” formatındaki kuralları kullanırken dikkatli olmak lazım.
Şimdi çok daha basit bir kural düşünelim “Bir kullanıcı makinası, C&C/Botnet sunuculardan biri ile iletişime geçti ise ise uyar.” Bu kural dikkatli kullanılmazsa false pozitif oluşturabiliz zira botnet serverların listesi, firewall tarafından da bilinebilir ve takip edilebilir. Eğer firewall bu iletişimi blokladı ise bunun alarmdan ziyade sadece raporlarda görünmesi mantıklıdır. Diğer türlü oluşan alarmlardan başımızı kaldıramaz duruma gelebiliriz. Dolayısı ile kuralı “Bir kullanıcı yasaklı listelerde mevcut olan ülkelerden biri ile iletişime geçmeye çalışıp firewall tarafından da bloklanmadı ise uyar.” şeklinde düzenlersek daha faydalı ve etkin formata getirmiş oluruz.
Yine çokça SIEM ürününü hazır kütüphanesinde olan “VPN kullanıcısı, birden fazla dosyayı değiştirirse uyar” veya bu anlama gelen kural mevcut ama bu kurala yine false pozitifleri azaltmak amaçlı bakılırsa VPN kullanıcısının logoff oldugu zaman ile senkron olması gerektiğini bulabiliriz.
Senaryolar haricinde false pozitiflerle boğuşmanın diğer bir yolu; ilk başta alarmları mail ile göndermek yerine takip edilebilecek bir alarm monitoring modülü — her üründe olmayabilir — ile takip edip her şey olgunlaşınca, mail veya SMS ile anında bildirim almak veya aksiyon almayı aktif edebiliriz. Örnek alarm monitoring ekranı:
“SIEM PROJESİNDEN NASIL FAYDALANABİLİRİZ?” BEYİN FIRTINASI ÖRNEĞİ
Öncelikli olarak üründe temel yeteneklerin var olduğunu kabul ediyoruz ki burada bile ürünlerin yarısı zorlanmaktadır. Konu ile ilgili kısa bir endüstri araştırma yapmak gerekir;
Kaynaklar:
· SANS [1]
· Gartner[2]
· Web Search
· Bloglar
· OWASP[10]
Vs..
Kurallar sadece “X olayı Y sürede (saniye,dakika,saat) T adet olursa, ardından da A sürede, K olayı olursa ve B sürede de C olayı olmazsa ” gibi formatlar içermezler. SIEM projelerinde güvenliği toptan düşünmek lazım. Dolayısı ile derde deva olmayan bir SIEM, log toplamadan öteye geçemez.
O halde nasıl bir yol izleyelim?
Bilindiği gibi Spam mesajlar günümüzde dünya günlük Internet posta trafiğinin %59 ‘unden fazlasını oluşturmaktadır. Bu maillerin önemli tehlikelerinden biri de Cryptolocker ve benzeri saldırıların bu yolla gerçekleşmesidir. Spam ve oltalama (phishing) saldırılarında rasgele domain oluşturma algoritmaları[4] kullanılır. Şirketlerin %85 i bu oltalama saldırılarına maruz kalır [6]. Bir SIEM çözümümüz var ise ve yeterli önem veriliyorsa bu Cryptolocker saldırılarından korumasını ve oltalama işlerinden de korumasını beklemeli miyiz?
Eğer cevabımız “Evet” ise bu bizim biraz daha vakit ve kaynak ayırmamız anlamına gelecek ama nihayetinde bu efora değecektir.
Bu örnekten devam edecek olursak bize lazım olan senaryo aşağıdaki gibi olsun:
Ø Eğer rasgele olarak oluşturulmuş bir domaine trafik veya o domain den bize doğru bir trafik oluşursa bizi uyar.
o Şimdi senaryomuzu nasıl test edeceğimizi görelim:
Örnek olarak “rlvukicfjceajm.ru” domain i test için kullanalım
Aşağıda test için hazırlanan log formatı mevcut:
date=2017–09–11 time=12:45:15 devname=BANET_SECONDARY devid=FG200E45Q17900950 logid=1059028704 type=utm subtype=app-ctrl eventtype=app-ctrl-all level=information vd=root appid=40568 user= srcip=10.10.3.14 srcport=50308 srcintf=port2 dstip=2.3.4.77 dstport=443 dstintf=wan1 profiletype=applist proto=6 service=HTTPS policyid=1 sessionid=164774801 applist=anet appcat=Web.Client app=HTTPS.BROWSER action=pass hostname=rlvukicfjceajm.ru url=/ msg=Web.Client: HTTPS.BROWSER, apprisk=medium
Bunu bir syslog simülatör ile SIEM e göndermek gerekecek. Bunun için bir dizi alternatifler mevcuttur [8]. Destination Host, port ve yukarıdaki logu kaydettiğimiz test.txt dosyasını ayarladıktan sonra logu SIEM a gönderebiliriz.
Eğer çıktı olarak bir uyarı alabiliyorsak, sistem bunu anlayabilmiş demektir.
Yine benzer şekilde domin bazlı atakların önlenmesini tamamlamak için, başka bir yönteme daha ihtiyacımız var. Onu da aşağıdaki gibi bir kural ile tamamlıyoruz
Ø Eğer son 24 saat içinde oluşturulmuş ve Alexa da ilk 1 milyona girmeyen veya bizim White liste aldığımız listede olmayan bir domaine trafik veya o domainden bize doğru bir trafik oluşursa bizi uyar
o Bu senaryonun testine göz atacak olursak:
Burada Son 24 saatte oluşan bir site bulmakla vakit kaybetmek istemeyiz. O zaman yukarıdaki senaryonun algoritmasının çalışıp çalışmadığını test etmeliyiz.
Kuralı test edebileceğimiz şekilde değiştirelim. “sans.org” u deneyelim
Oluşma tarihi: 1995–08–04 04:00:00
Alexa daki yeri : 25646
O zaman test kuralımız
Ø Eğer son 24 saat içinde oluşturulmamış ve Alexa da ilk 10000 girmeyen veya bizim White liste aldığımız listede olmayan bir domain e trafik veya o domain den bize doğru bir trafik oluşursa bizi uyar
Eğer bir uyarı alıyorsak sistem bunu anlayabilmiş ve hedeflerimizden birine ulaşmışız demektir.
Sonuç olarak; bir SIEM çözümünden faydalanmak ve projede başarıyı yakalamak için üzerinde düşünülmüş, çalışılmış ve tecrübe ve bilgi birikimi ile yoğrulmuş bir süreç işletilmesi gerekir. SIEM ürünleri çeşit çeşit yetenekte ve kabiliyettedir. Buna karşılık bu ürünleri kullanacak proje ekibi de değişik yetenek, bilgi birikimi ve tecrübeler de olabilir. Başarıyı son kullanıcı tanımlamadığı ve onaylamadığı sürece proje ucu açık kalabilir.
Referanslar
1. https://www.sans.org/course/siem-with-tactical-analytics
2. https://blogs.gartner.com/anton-chuvakin/2017/01/05/on-ueba-uba-use-cases/
4. http://blog.trendmicro.com/domain-generating-algorithms-dgas/
5. https://securelist.com/spam-and-phishing-in-q1-2017/78221/
6. https://blog.barkly.com/phishing-statistics-2016
7. http://blogs.cisco.com/security/talos/detecting-dga
8. http://www.oidview.com/snmp-syslog-simulator.html
9. https://cyber-defense.sans.org/blog/2017/10/31/your-siem-questions-answered
10. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
Bu yazı ilk defa ISACA İstanbul Chapter tarafından yayınlanmıştır.
