Performans ve yanlış pozitif ayarı
- Yavaş sorguyu iş denetçisiyle ölçüp hızlandırır, kuralın eşiğini geriye dönük veriyle seçer ve istisnaları süreli bir listede tutarsın.
- Kuralın yaşam döngüsünü ve sağlığını izlemeyi de öğreneceksin.
Puan bütün etkinlikleri cevaplayınca hesaba yazılır. Bu dersi tamamlayınca +60 XP alacaksın. Giriş yapmadan ilerlersen puan yalnız bu tarayıcıda durur.
Doğru sonuç veren bir sorgu bile yavaşsa SOC'ta işe yaramaz. Analist bir soruya dakikalar içinde yanıt almalıdır. Hızlı çalışan bir kural da her saat yüz alarm üretiyorsa işe yaramaz.
Gerçek olay gürültünün içinde kaybolur ve ekip zamanla alarmlara güvenmeyi bırakır. Bu derste iki sorunu birlikte çözeceksin.
Önce Splunk ve KQL'de sorguyu yavaşlatan kalıpları ve iş denetçisiyle ölçmeyi göreceksin. Sonra Altay Kargo'nun kaba kuvvet kuralının eşiğini otuz günlük veriyle seçeceksin. En sonda istisnaları yönetmeyi ve kuralın sağlığını izlemeyi öğreneceksin.
Splunk'ta sorgu neden yavaşlar
Performansın ilk kuralı sırayla ilgilidir. Zaman penceresini, index'i ve sourcetype'ı her zaman ilk satıra yaz. Bu alanlar dizinde durur ve okunacak veriyi ham olaya dokunmadan daraltır.
İkinci kural joker karakterle ilgilidir. *password gibi baştan joker taşıyan bir terim, dizinin önek aramasından yararlanamaz. Splunk bu durumda dizindeki terimleri tek tek dener. Joker sona konursa, yani pass* yazılırsa, arama yine dizinden yararlanır.
Üçüncü kural taşınan veriyi azaltmaktır. fields komutuyla ihtiyacın olmayan alanları erkenden atarsın. stats, sort ve dedup gibi bütün sonucu bekleyen komutlar ise sorgunun olabildiğince sonuna yazılır.
Arama modu da hızı etkiler. Verbose modu her olaydaki bütün alanları çıkarmaya çalışır. Fast modu alan keşfini kapatır ve yalnız sorguda adı geçen alanlarla çalışır. Smart modu, sorgu stats gibi dönüştürücü bir komut içeriyorsa alan keşfini kendiliğinden kapatır.
Kayıt sayımı gibi işler için tstats hâlâ en hızlı yoldur, çünkü ham olaya hiç dokunmaz. transaction yerine stats kullanmak da aynı ilkeye dayanır. Bellekte oturum kurmak yerine sayıyı doğrudan hesaplarsın. Doğru mod seçimi istatistik sonucunu değiştirmez, yalnız oraya daha az iş yaparak ulaşırsın.
# Yavaş index=web "error" | stats count by uri | where count > 100 # Hızlı index=web sourcetype=access status>=500 earliest=-1h | fields uri | stats count by uri | where count > 100 Yavaş: This search has completed and has returned 231 results by scanning 18,437,902 events in 42.317 seconds Hızlı: This search has completed and has returned 214 results by scanning 61,288 events in 1.802 seconds
Hangi sürümün hızlı olduğunu tahminle değil, ölçerek bilirsin. Splunk'ta arama sonucunun üstünde Job menüsü durur; Inspect Job seçeneği iş denetçisini açar. En üstteki satır üç sayı verir: dönen sonuç, taranan olay ve geçen süre.
Yavaş sürüm on sekiz milyondan fazla olay taramış ve 42 saniye sürmüş. Zaman sınırı olmadığı için eski günlerden de URI toplamış.
Hızlı sürüm altmış bir bin olayla 1,8 saniyede bitmiş. Sonuç sayıları yakın, maliyet ise yirmi kattan fazla farklı. Taranan olayla dönen sonuç arasındaki büyük fark, süzgecin geç devreye girdiğini gösterir. Execution costs tablosu sürenin hangi bileşende harcandığını ayrıntılı listeler.
Etkinlik 1 / 6
Aşağıdaki iki sorgudan hangisi aynı sonuca daha hızlı ulaşır?
Önce kodu oku, sonra çıktıyı seç.
A) index=web "error" B) index=web sourcetype=access status>=500 earliest=-1h
KQL'de aynı ilkeler
KQL'de de ilk iş işlenen veriyi azaltmaktır. İlk where zaman sütununa uygulanır; datetime sütunlarındaki dizin ilgisiz veri parçalarını hiç açmadan eler. Ardından seçici metin süzgeçleri gelir. Tam bir terim arıyorsan has kullan; contains alt dizi aradığı için sütunu tarar.
Harfini bildiğin değerde =~ yerine == yaz. Microsoft'un önerisi, hesaplanmış bir sütun yerine tablodaki asıl sütunu süzmektir. Yani önce extend ile alan üretip sonra onu süzmek yerine koşulu doğrudan where içine yazarsın. Tanımadığın bir tabloda yeni bir sorgu denerken sonuna take 10 ekle.
Birleştirmede dört kural vardır. join'de satır sayısı az olan tabloyu sola, yani ilk sıraya koy. Sağ taraf küçük bir başvuru tablosuysa join yerine lookup operatörünü kullan.
Yalnız tek bir sütuna göre süzüyorsan join'e hiç gerek yoktur; in operatörü aynı işi daha ucuza yapar. Aynı alt sorguyu birden çok kez kullanıyorsan materialize() ile bir kez hesaplat. Bu kuralların hepsi tek bir ilkeye dayanır: veri ne kadar erken küçülürse sorgu o kadar hızlı biter.
KQL'in sorgu iyileştiricisi bazı süzgeçleri kendisi öne alabilir, ama bunun her zaman olacağının garantisi yoktur. Sırayı kendin doğru yaz.
// Yavaş SigninLogs | extend Hata = ResultType != "0" | where * has "203.0.113.19" | where Hata | where TimeGenerated > ago(7d) // Hızlı SigninLogs | where TimeGenerated > ago(7d) | where IPAddress == "203.0.113.19" | where ResultType != "0" | project TimeGenerated, UserPrincipalName, AppDisplayName, ResultType
Yavaş sürüm üç hata taşır. Zaman süzgeci en sondadır, bu yüzden yedi günden eski veri de okunur. where * has bütün sütunlarda metin arar, oysa adres yalnız IPAddress sütunundadır.
Hata adlı hesaplanmış sütun da süzgeci tablonun asıl sütunundan uzaklaştırır. Hızlı sürüm zamanla başlar ve adresi doğru sütunda, tam eşitlikle arar.
Başarısızlık koşulunu doğrudan ResultType üstüne yazar. Sonra yalnız gereken sütunları project ile bırakır. Sentinel'de sorgu bitince ekranın altında süre ve dönen kayıt sayısı görünür. İki sürümü aynı pencerede çalıştırıp bu değerleri karşılaştırırsın.
Etkinlik 2 / 6
Her KQL alışkanlığını sorgu hızına etkisine göre ayır.
Önce bir seçeneğe, sonra aşağıdaki uygun kutuya bas. İstersen seçeneği kutuya sürükleyip bırak. Yerini değiştirmek için aynı işlemi tekrarla.
0/6 seçenek yerleşti.
Temel çizgi ve eşik: kararı veriyle vermek
Hızlı çalışan bir kural bile çok alarm üretiyorsa analistin dikkatini yorar. Yanlış pozitif ayarının ilk adımı temel çizgi (baseline) çıkarmaktır.
Kuralı bir süre yalnız günlüğe yazdırırsın, alarm üretmezsin. Böylece hangi davranışın normalde de tetiklendiğini görürsün. Daha hızlı bir yol da vardır: kuralı geçmiş veride geriye dönük çalıştırmak.
Otuz günlük veride farklı eşikleri dener, her birinin kaç alarm üreteceğini sayarsın. Sonra bu alarmları ekibin olay kayıtlarıyla karşılaştırırsın. Gerçek bir olaya karşılık gelen alarm doğru pozitiftir. Karşılığı olmayan alarm ise analistin vaktini alan gürültüdür.
index=guvenlik sourcetype=linux_secure "Failed password" earliest=-30d@d latest=@d | rex "from (?<src_ip>[0-9.]+) port" | bin _time span=10m | stats count AS deneme by _time, src_ip | eval e5=if(deneme>=5,1,0), e10=if(deneme>=10,1,0), e20=if(deneme>=20,1,0) | stats sum(e5) AS alarm_5, sum(e10) AS alarm_10, sum(e20) AS alarm_20 eşik alarm doğru pozitif kaçırılan olay 5 412 6 0 10 58 6 0 20 19 4 2
Sorgu son otuz günü tam gün sınırlarıyla alır. bin _time span=10m olayları on dakikalık dilimlere ayırır. stats her adres için her dilimdeki denemeyi sayar.
eval her eşik için dilimin alarm üretip üretmeyeceğini 1 ya da 0 olarak işaretler. Son stats bu işaretleri toplar ve her eşiğin kaç alarm üreteceğini verir. Doğru pozitif sütunu sorgudan değil, ekibin olay kayıtlarından gelir.
Şimdi tabloyu oku. Eşik 5 bütün olayları yakalıyor, ama ayda 412 alarm üretiyor. Eşik 20 gürültüyü azaltıyor, ama yavaş giden iki saldırıyı kaçırıyor. Eşik 10 altı olayın hepsini 58 alarmla yakalıyor.
Ekip eşiği 10 seçer ve kararı kurala bağlı bir kayda yazar. Kayıt dört şey içerir: denenen eşikler, her birinin sonucu, seçilen değer ve gerekçe. Gerekçe açıktır: altı olayın hepsi yakalanıyor, alarm sayısı yaklaşık yedide birine iniyor.
Eşik 20'nin kaçırdığı yavaş denemeler için ayrı bir kural yazılır. O kural bir günlük pencerede adres başına dc(hesap) sayar. Kayıt olmazsa altı ay sonra kimse eşiğin neden 10 olduğunu hatırlamaz. Bir sonraki ayarda ekip aynı denemeyi sıfırdan yapmak zorunda kalır.
Etkinlik 3 / 6
Doğru mu, yanlış mı?
Bir kuralı doğrudan alarma bağlamadan önce bir süre yalnız günlüğe yazdırmak, temel çizgiyi görmenin standart yoludur.
Eşik SIEM hattında nerede yaşar
Eşiği ayarlamak bir takas kurar. Eşiği yükseltmek gürültüyü azaltır, ama eşiğin altında kalan sessiz denemeleri kaçırma riskini artırır. Eşiği düşürmek tam tersini yapar.
Doğru değer, ortamın normal davranışına ve neyi kaçırmayı göze alabildiğine bağlıdır. Bu karar tek seferlik değildir; ortam değiştikçe yeniden açılır. Ayarın SIEM hattında nerede yapıldığını bilmek de önemlidir. Eşik kuralın bir parçasıdır ve kural korelasyon durağında çalışır.
Hat soldan sağa okunur. Log kaynakları ham veriyi üretir. Toplama katmanı onu ayrıştırır ve ortak bir biçime sokar. Korelasyon durağı kuralı ve eşiği uygular.
Eşik aşılırsa alarm üretilir ve triyaj aşamasında analist karar verir: gerçek bir olay mı, yoksa eşiğin yeniden ayarlanması mı gerekiyor? Triyajda kapatılan her alarmın kapanış nedeni bir sonraki eşik ayarının ham verisidir. Kapanış nedeni yazılmazsa hat kendini düzeltemez.
Etkinlik 4 / 6
Bir kuralın çok fazla yanlış pozitif ürettiğini fark ettin ve eşiğini yükseltmek istiyorsun. Hangi durakta değişiklik yaparsın?
Diyagramda doğru kutuyu tıkla.
Eşik ayarını hazır veriyle de sınayabilirsin. Aşağıdaki günlük parçasında aynı hesaba karşı art arda gelen başarısız girişler var. Bazı satırlar ise sıradan uygulama trafiğidir.
Kuralı yazmadan önce hangi satırların eşiğe girmesi gerektiğini kendin ayırt et. Sonra bu ayrımı karşılayan bir düzenli ifade kur. Eşiğe yanlış satır sayan bir desen, en iyi seçilmiş eşiği bile boşa çıkarır. Çıkış ve yazdırma gibi eylemler sayıma girmemelidir.
Etkinlik 5 / 6
Yalnız aynı hesaba karşı başarısız giriş satırlarını yakalayan düzenli ifade yaz.
Yazdıkça eşleşen satırlar işaretlenir. Hedef: yalnız doğru satırlar eşleşsin.
İstisnalar ve kuralın yaşam döngüsü
Tanıdık istisnaları kuralın içine tek tek yazmak zamanla okunmaz bir sorgu üretir. Daha iyi yol, istisnaları ayrı bir lookup dosyasında tutmaktır. Dosyanın her satırı bir değer, bir neden, ekleyen kişi ve son geçerlilik tarihi taşır. Yedekleme sunucusunun her gece toplu giriş yapması buna örnektir.
Kural lookup ile dosyaya bakar ve geçerli bir nedeni olan satırları dışlar. Süresi geçmiş istisna artık dışlama yapmaz. Böylece bir yıl önce eklenip unutulan bir istisna saldırgana kalıcı bir kör nokta bırakmaz. Sigma kurallarında aynı fikir filter_optional_ ile başlayan seçimlerde yaşar; ortama özgü dışlamalar ana mantıktan ayrı durur.
istisna.csv deger,neden,ekleyen,son_gecerlilik 10.20.40.15,gece yedeklemesi toplu giriş yapar,ege,2026-12-31 ... | stats count AS deneme by src_ip | lookup istisna.csv deger AS src_ip OUTPUT neden son_gecerlilik | eval aktif=if(isnotnull(neden) AND strptime(son_gecerlilik, "%Y-%m-%d") > now(), 1, 0) | where aktif=0 AND deneme >= 10
lookup, istisna dosyasındaki deger sütununu olaydaki src_ip alanıyla eşler. Eşleşme varsa neden ve son_gecerlilik alanları olaya eklenir. eval satırı istisnanın hâlâ geçerli olup olmadığına karar verir.
strptime metin tarihini Unix zamanına çevirir, now() da aramanın başladığı anı verir. İstisna yoksa ya da süresi dolmuşsa aktif sıfır olur ve satır alarm adayı olarak kalır. Son satır eşiği uygular.
Tarihte bir ayrıntıya dikkat et: strptime saat vermediğin tarihi o günün 00.00'ına çevirir. Bu yüzden yedekleme sunucusu 30 Aralık'ın sonuna kadar dışlanır ve 31 Aralık'ta kural onu yeniden görür. Son günün de sayılmasını istersen tarihe bir gün, yani 86400 saniye eklersin. İstisna dosyasını her hafta gözden geçirip süresi yaklaşanları sahibine sormak iyi bir alışkanlıktır.
Bir kural yazıldığı gün bitmez. Sigma'nın status alanı kuralın olgunluğunu beş değerle anlatır. experimental yeni ve gürültülü olabilecek bir kuraldır.
test büyük ölçüde oturmuş, ama ortama göre küçük ayar isteyebilir. stable üretimde ve panolarda güvenle kullanılır. deprecated başka bir kuralla değiştirilmiş, unsupported ise şu anki hâliyle çalışamayan kuraldır.
Durumu değiştirmek için ölçüye bakarsın. Haftalık alarm sayısı, doğru pozitif oranı, son tetiklenme tarihi ve ortalama sorgu süresi kuralın sağlık göstergeleridir. Aylardır hiç tetiklenmeyen bir kural ya ortamda karşılığı olmayan bir tehdidi arıyordur ya da veri kaynağı kopmuştur.
Derinleş:Palantir ADS: kuralın yanına yazılan belge
Palantir'in güvenlik ekibi Alerting and Detection Strategy (ADS) adlı bir çerçeve yayımladı. Çerçeve, her tespit kuralının yanında aynı başlıkları taşıyan bir belge ister. Goal kuralın neyi yakalamak istediğini söyler.
Categorization ATT&CK eşlemesini, Strategy Abstract yöntemin kısa özetini verir. Technical Context analistin bilmesi gereken arka planı anlatır. Blind Spots and Assumptions kuralın neyi göremeyeceğini açıkça yazar.
False Positives bilinen gürültüyü, Validation ise kuralın gerçekten tetiklendiğini gösteren sınama adımını içerir. Priority ve Response alarm geldiğinde ne yapılacağını belirler. Validation bölümü eşik ayarıyla doğrudan ilgilidir: eşik ya da istisna değiştiğinde aynı sınama yeniden koşulur. Böylece kural, ekipten ayrılan kişinin aklında değil, bu belgede yaşar.
Etkinlik 6 / 6
Bir analist yeni bir tespit kuralı yazdı. Kuralı canlıya almadan önce hangi sıra en doğru sonucu verir?
Okumayı istediğin sırayla sürdürebilirsin. Ders, bütün etkinlikleri cevapladığında tamamlanır.