MODÜL 2 — Collection Stratejisi, Kaynak Güvenilirliği ve Exposure Odaklı Toplama

Modül Teması

CTI'de "collection", veri çekmekten ibaret değildir; hangi verinin hangi kararı değiştireceğini bilen bir mühendislik disiplinidir. Bu modülde dahili telemetri ile harici sinyalleri tek bir hatta birleştirirken kaynak güvenilirliği-kanıt zinciri-belirsizlik yönetimi birlikte ele alınır. Amaç yalnızca "tehdit var mı?" sorusuna cevap üretmek değil; kurum için riskin nerede gerçek olduğunu (vulnerability + exploit sinyali ile exposure/maruziyet eşleşmesi üzerinden) kanıt standardında gösterebilmektir. İçerik boyunca "bağlamsız IOC" gibi pahalı anti-pattern'ler, noise/FP maliyeti ve etik-hukuki-OPSEC sınırları karar mantığının içine gömülüdür.

1) Collection'u "çok veri"den "yüksek sinyal"e çevirmek

İleri seviyede collection, "ne bulursam alırım" yaklaşımıyla değil; karar değeri ile yönetilir. Bir sinyalin değeri, teknik olarak ilginç olmasından değil; hangi kararı etkilediğinden anlaşılır.

Bir collection tasarımını sağlamlaştıran üçlü, her kaynak için tekrar tekrar sorulmalıdır:

• Bu sinyal hangi kararı değiştiriyor? (izleme mi, uyarı mı, öncelik mi, eskalasyon mu, backlog mu?)
• Yanlış pozitif maliyeti nedir? (iş kesintisi, analist yükü, kural kirliliği, güven kaybı)
• Kanıt standardı nedir? (hangi ek veriyle doğrulanır, hangi karşı kanıtla zayıflar?)

Dikkat: "Çok sinyal" olgunluk göstergesi değildir. Doğrulama kapıları yoksa, çok sinyal yalnızca hızlı yayılan yanlış kararlar üretir.

2) Dahili telemetriyi CTI için konumlandırma

İstihbarat yalnızca dışarıdan gelmez. Kurum içindeki telemetri, çoğu zaman en yüksek bağlam değerine sahiptir; çünkü dış dünyadaki "genel tehdit"i, kurumun gerçek riskine çevirebilen katmandır. Burada hedef, mekanik log okumak değil; "hangi sinyal CTI için stratejik bir anlam taşıyor?" sorusuna yanıt bulmaktır.

Dahili kaynakların CTI'de rolü

• Kuruma özgü imza üretir: Aynı kampanya başka yerde yüksek riskken sizde düşük olabilir; ya da tam tersi.
• Sahadan doğrulama sağlar: Harici iddiayı "bizde karşılığı var mı?" diye test edersiniz.
• Görünürlük boşluğunu ortaya çıkarır: "Sinyal yok" bazen "tehdit yok" değil, "telemetri yok" demektir.

Telemetri türleri (hatırlatma düzeyinde): SIEM olayları, EDR sinyalleri, e-posta ağ geçidi kayıtları, proxy/DNS logları, kimlik sağlayıcı günlükleri, IR bulguları.

İleri seviyede "değerli sinyal" seçerken iki disiplin birlikte yürür:

• Gözlem-yorum ayrımı: Ham kayıt gözlemdir; "bu tehdit" dediğiniz an yorum üretiyorsunuz.
• Kanıt zinciri: Aynı iddiayı destekleyen bağımsız izler (zaman uyumu, farklı sistemlerde uyum, alternatif açıklamaların elenmesi).

Örnek:\ "DNS'te example.org sorgusu arttı" tek başına zayıf bir sinyaldir. Zaman uyumu, hangi varlıklardan geldiği, benzer artışların geçmişte hangi meşru olaylarla örtüştüğü ve alternatif açıklamalar (meşru güncelleme, normal trafik değişimi) birlikte ele alındığında sinyalin "bilgi" katmanına çıkması mümkündür. "İstihbarat" seviyesinde ise hangi kararın değiştiği ve hangi ek kanıtların confidence'ı artıracağı netleşir.

İpucu: Dahili telemetriyi "ham veri deposu" değil, doğrulama motoru olarak kurgulayın. Harici sinyali iç telemetriyle eşleştirdiğiniz anda, çoğu "genel tehdit" ifadesi kurum için ya değer kazanır ya da hızla elenir.

3) Harici kaynaklarda değer üretme: "okumak" değil "test etmek"

Vendor raporları, topluluk paylaşımları, güvenlik blogları, ticari feed'ler ve kamu listeleri harici kaynak ekosistemini oluşturur. İleri seviyede fark yaratan şey, aynı raporu herkes okuyabildiği için, sizin raporu kanıt standardına göre parçalayarak değerlendirebilmenizdir.

Trend ile kopya içerik ayrımı

• Trend içeriği genellikle metodolojisini ve sınırlılıklarını anlatır; çıkarımlarının dayanağı izlenebilir olur.
• Kopya içerik genellikle büyük iddialar üretir; kanıt zinciri zayıftır; belirsizlik dili yoktur; birbirinin IOC listesini yeniden paketler.

Değer üretmek için raporu tüketirken şu sorular akışın içinde sürekli canlı tutulur:

• Bu metin neyi gözlem, neyi yorum olarak sunuyor?
• İddiayı çürütebilecek karşı ihtimaller ele alınmış mı?
• Kuruma uyarlamak için hangi bağlam noktalarına ihtiyacım var? (maruziyet, kritik varlık, kontrol boşluğu, görünürlük eksikleri)

İpucu: Harici raporu "özetlemek" yerine, rapordaki iddiaları test edilebilir parçalara ayırın. Böylece rapor bir metin olmaktan çıkıp, doğrulama listesine dönüşür.

Dikkat: Aynı iddianın üç farklı blogda geçmesi "bağımsız doğrulama" olmayabilir; bazen tek bir kaynağın cümlesi ekosistemde dolaşır. Bu varsayımı test etmeden confidence yükseltmek, misinformation / data poisoning riskini büyütür.

4) Kaynak güvenilirliği, doğrulanabilirlik ve kanıt standardı

İleri CTI'de en pahalı hata, "iyi yazılmış metni iyi kanıt sanmak"tır. Bu yüzden iki kavram ayrılır:

• Kaynak güvenilirliği: Kaynağın geçmiş performansı, şeffaflığı, tutarlılığı
• Bilginin doğrulanabilirliği: İddiayı destekleyen bağımsız kanıt, tekrar üretilebilirlik, zaman uyumu

Bu ayrımı standartlaştırmak için Admiralty Code (A1-F6) yaklaşımı kullanılır: Harf, kaynağın güvenilirliğini; sayı, bilginin doğrulanabilirliğini temsil eder. Buradaki kritik değer şudur: güvenilir kaynaktan bile doğrulanamaz bilgi gelebilir ve bunun dili ayrı olmalıdır.

İddiayı kanıt standardında yönetmek için pratik omurga: Source-Claim-Evidence

• Source: Kim söylüyor?
• Claim: Ne iddia ediyor?
• Evidence: Bu iddia neyle destekleniyor? Bağımsız doğrulama var mı?

Confidence diliniz de bu omurgaya yaslanmalıdır:

• "Yüksek" ancak birden fazla bağımsız iz aynı sonuca işaret ediyorsa...
• "Orta" tek kaynağa yaslanıyorsa veya alternatif açıklamalar güçlü ise...
• "Düşük" doğrulanabilirlik zayıfsa ya da zaman uyumu sorunluysa...

Örnek:\ Tanımadığınız bir platformda "sızıntı" iddiası görüldü. Kaynak güvenilirliği belirlenemiyorsa ve veri örneği doğrulanamıyorsa, bu iddia "yüksek confidence" ile yayılmaz; doğru hamle, kanıt zinciri kurmak (bağımsız sinyal aramak) ve bulunamazsa belirsizliği açık taşımaktır. Buna karşılık geçmişte tutarlı çıkan bir feed'den gelen bir sinyalde kaynak güvenilirliği yüksek olabilir; ama bilgi hâlâ doğrulanamıyorsa, güvenilir kaynağın varlığı tek başına "kesinlik" üretmez.

5) "Contextless IOC" ve noise yönetimi: operasyonel maliyeti görünür kılmak

Bağlamsız IOC, ileri seviyede sadece bir kalite kusuru değil; operasyonel maliyet üretir: yanlış bloklama, analist yorgunluğu, kural kirliliği ve gerçek sinyalin kaçması.

Bağlamsız IOC'nin tipik riskleri:

• Yanlış bloklama → iş sürekliliği riski
• Gereksiz alarm → gerçek sinyali boğma
• Kural borcu → zamanla yönetilemez backlog

Noise'u yönetmek için kullanılan kaldıraçlar (her biri "yöntem seçimi + sınır" içerir):

• Scope (kapsam): "Her yerde engelle" yerine kritik varlık/segment odaklı
• TTL (yaşam süresi): Eski IOC'lerin çöp birikimi yaratmasını önler
• Allowlist/whitelist: Meşru trafiği ayırır; ama bakım yükü getirir
• Confidence gate: Düşük doğrulanabilirlikte sinyali otomatik yaymaz; ama "kaçırma" riskini yönetmek gerekir

Örnek:\ Bir alan adı sinyali tek kaynaktan geliyor ve iç telemetride karşılığı yok. Doğrudan bloklamak, paylaşımlı servis/CDN ihtimali nedeniyle iş kesintisi riski taşır. İleri seviye yaklaşım; sinyali "izle + doğrula" sınıfına alıp TTL ve kapsamla sınırlandırmak, ek kanıt geldikçe aksiyonu yükseltmektir.

6) Etik, hukuk ve denetlenebilirlik: koleksiyonun kırmızı çizgileri

CTI'de sınır, yalnızca teknik kapasite değildir; izinli ve denetlenebilir olmaktır. Yetkisiz erişim, "hack-back" ve benzeri pratikler bu çerçevenin dışındadır. Koleksiyon; izinli/kamusal/kurumsal onaylı kaynaklarla yürütülür.

Bu başlık altında ileri seviyede öne çıkan iki kalite kapısı vardır:

• Denetlenebilirlik: "Kim, neyi, hangi yetkiyle, hangi amaçla topladı?" sorusu her zaman cevaplanabilir olmalı.
• Paylaşım disiplini: Sınıflandırma (ör. TLP yaklaşımı) ve "need-to-know" prensibi; özellikle PII ve hassas veri söz konusuysa, gereksiz yayılımı engeller.

Dikkat: Etik sınır "yapmamak" değil, yaptığını savunabilmek demektir. Denetlenebilirlik yoksa, doğru bilgi bile organizasyonel risk üretir.

7) Vulnerability & exploit intelligence: "hype"ı riskten ayırmak

Zafiyet istihbaratı CTI'de "hangi aktör?" sorusunu tamamlar; ama burada amaç "nasıl istismar edilir?" anlatmak değil, "istismar iddiası gerçek mi ve kurum için anlamı ne?" sorusunu kanıt standardında cevaplamaktır.

Temel prensip: CVSS tek başına yetmez. Çünkü:

• Kurumda o bileşen yoksa veya izole ise "yüksek skor" düşük etki olabilir.
• Sahada istismar sinyali yoksa "acil" etiketi yanlış önceliklendirme doğurabilir.
• "İstismar var" iddiası ile "istismar doğrulandı" aynı sınıf değildir.

Toplama kaynakları (genel çerçeve): vendor advisory'ler, resmi bültenler, kamu listeleri, saha sinyalleri, güvenlik üreticisi telemetrileri. İddialar için kanıt standardı korunur; PoC varlığı gibi unsurlar "kanıt" sayılmadan önce kurum bağlamında değerlendirilir ve belirsizlik diliyle taşınır.

8) Exposure intelligence: "tehdit var"dan "bizde risk var"a

Exposure intelligence, kurumun dışarıdan nasıl göründüğünü (internet-facing servisler, kimlik/erişim yüzeyi, kritik varlıklara giden bağımlılıklar, kontrol boşlukları) tehdit verisiyle birleştirerek istihbaratı soyuttan çıkarır.

Bazen tek cümlelik analoji doğru zemini kurar: "Dışarıda fırtına var" bilgisi, pencereler açıksa değerlidir. Tehdit sinyali, maruziyetle eşleştiği anda yüksek öncelikli bir istihbarat ürününe dönüşebilir.

Exposure verisini üretirken kurumlar, kamu verilerini de referans alabilir (örn. Shodan gibi indeksler). Burada kritik olan "hangi aracı kullandığın" değil; envanter güncelliği, doğrulama kapıları ve yanlış eşleşme riskidir.

Yöntem seçimi (otomatik vs manuel)

• Otomatik eşleştirme hızlıdır; ama yanlış eşleşme riski taşır.
• Manuel inceleme daha doğru olabilir; ama operasyonel yük getirir.\ Olgunluk düzeyi ve noise toleransı, hangi yaklaşımın baskın olacağını belirler.

Örnek:\ Globalde aktif olarak sömürüldüğü iddia edilen bir VPN zafiyeti sinyali, kurum envanterindeki internet-facing VPN sürümüyle eşleşiyorsa risk büyür; fakat envanter güncelliği belirsizse, karar "kesin" diye yazılmaz. Önce eşleşmenin doğrulanacağı bağımsız kanıt noktaları tanımlanır ve confidence buna göre ifade edilir.

9) Digital risk ve ileri OSINT: "etkileşim değil gözlem + doğrulama"

Digital risk sinyalleri (credential leak iddiası, brand monitoring, taklit sayfalar, typosquat örüntüleri) CTI için hem erken uyarı hem de itibar/iş etkisi açısından değerlidir. Ancak bu alan, yanlış yönetilirse hem hukuki hem operasyonel risk doğurur.

Yeraltı ekosistemi sinyalleri dahil, prensip değişmez:

• Etkileşim yok; gözlem ve doğrulama var.
• OPSEC korunur; gereksiz iz bırakılmaz.
• "Tazelik" ve "gerçeklik" doğrulanmadan alarm üretilmez: bazı veri setleri kamuya açık verilerin derlemesi, eski sızıntıların tekrar paketlenmesi veya manipülasyon olabilir.

Örnek:\ example.com'a çok benzeyen bir alan adının (typosquat) görülmesi tek başına "saldırı var" kanıtı değildir. İleri seviye yaklaşım; hedeflenen marka/servis ilişkisini, kullanıcı maruziyetini, gözlenen şikayet/telemetri sinyallerini ve alternatif açıklamaları birlikte değerlendirip confidence'ı buna göre ifade etmektir.

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• Collection, veri toplama değil karar üretme disiplinidir; sinyalin değeri karar etkisiyle ölçülür.
• Dahili telemetri, harici iddialar için doğrulama motoru ve kuruma özgü bağlamdır.
• Harici raporlar “özetlenecek metin” değil; test edilecek iddia seti olarak ele alınmalıdır.
• Kaynak güvenilirliği ile bilginin doğrulanabilirliği ayrılır; kanıt zinciri ve belirsizlik dili güvenin temelidir.
• Contextless IOC ve noise, FP ve iş kesintisi riski üretir; scope/TTL/allowlist/confidence gate birlikte düşünülmelidir.
• Zafiyet ve exploit sinyali, maruziyet ve iş etkisiyle birleşmeden “risk”e dönüşmez; hype ile risk ayrılmalıdır.
• Exposure intelligence, “tehdit var” bilgisini “bizde risk var” kararına çeviren köprüdür; yöntem seçimi maliyet/riske göre yapılır.
• Digital risk ve ileri OSINT’te prensip değişmez: etkileşim değil gözlem + doğrulama; OPSEC ve etik sınırlar karar kalitesinin parçasıdır.

MODÜL 3 — Analysis Tradecraft, Bilişsel Hatalar ve Counter-Intelligence

Modül Teması

CTI'de "analiz", veriyi yorumlayıp bir metne dökmek değildir; kanıt standardında ve denetlenebilir biçimde, karar vericinin riskini azaltacak yargılar üretmektir. Bu modül; bilişsel tuzakların analizi nasıl çarpıttığını, hipotezlerin nasıl yarıştığını, belirsizliğin nasıl profesyonelce ifade edildiğini ve nihayetinde analistin karşısına çıkan deception / mis-disinformation / data poisoning gibi yanıltma problemlerine karşı nasıl dayanıklılık kurulduğunu ele alır.

1) Bilişsel önyargılar ve analitik hijyen

Analiz doğası gereği "insan" işidir; insan zihni ise belirsizlikte kestirme yollar üretir. İleri seviyede mesele, bu kestirmeleri tamamen yok etmek değil; onları görünür kılıp yönetmektir. Çünkü pek çok hatalı çıkarım, veri eksikliğinden çok "zihnin rahat ettiği" bir hikâyeye hızlıca tutunmaktan doğar.

1.1. CTI'de sık görülen bilişsel tuzaklar

• Doğrulama yanlılığı (confirmation bias): İlk açıklamayı destekleyen parçaları seçip, çürütecek parçaları aramamak.
• Çapa etkisi (anchoring): İlk rapor/ilk özet, zihinde "çapa" olur; yeni veriler o çapanın etrafında eğilir.
• Kullanılabilirlik önyargısı (availability bias): En taze okunan raporun veya en çok konuşulan olayın etkisiyle yeni olayı aynı kalıba sokmak.
• Ayna yansıması (mirror imaging): "Ben olsam böyle yapardım, saldırgan da böyle yapar" varsayımıyla hareket etmek.

Bu tuzaklar tek tek "yanlış" değildir; kontrolsüz kaldıklarında kanıt zincirini sessizce bozarlar: yargı, kanıttan önce gelir; kanıt sonra yargıya hizmet edecek şekilde seçilir.

1.2. Hijyenin omurgası: varsayımı görünür kılmak

Analizde saklı varsayım, zamanla "kanıt gibi" davranır. Bu yüzden ileri seviye hijyenin temel refleksi şudur:

• Varsayımları yaz,
• Kanıttan ayır,
• Varsayımı çürütecek sinyali özellikle ara.

Örnek: Bir ekip toplantısında "Bu küme genelde kimlik odaklı ilerler" cümlesi hızlıca kabul görür. Bu, daha sonra gelen "altyapı benzerliği zayıf" gibi kritik bir karşı sinyalin önemini düşürür. Hijyen refleksi, bu cümleyi "varsayım" olarak kayda geçirip şu soruyu zorunlu kılar: "Bu varsayım yanlışsa hangi izleri görmemiz gerekir?"

Dikkat: "Aklıma yatıyor" ifadesi kanıt değildir. Zaman baskısı yükseldikçe en güçlü düşman çoğu zaman saldırgan değil, hızın ürettiği otomatik pilot olur.

Gözlemlenen-değerlendirilen ayrımı\ Analitik yazımda "gözlem" ile "değerlendirme"yi ayırmak, önyargıyı azaltan pratik bir bariyerdir. Gözlem: ölçülebilir/izlenebilir olan; değerlendirme: gözlemden çıkan anlam ve yargıdır. Bu ayrım korunmadığında yorum, geriye dönük olarak gözlemmiş gibi okunur.

İpucu: Her kritik paragrafın sonuna tek cümlelik bir kontrol cümlesi ekleyin:\ "Bu yargı hangi gözlemlere dayanıyor ve hangi gözlem gelirse zayıflar?"\ Bu soru, doğrulama yanlılığını "süreç içinde" yakalar.

1.3. Yöntem seçimi: hız mı, derinlik mi?

Hijyen pratikleri iki uçta çalışır:

• Hızlı tarama: Operasyonel tempo için pratiktir; ancak noise ve yanlış çapa riski artar.
• Yapılandırılmış hijyen (checklist / mini-matris): Daha yavaştır; ama yüksek etkili kararlar için daha güvenlidir.

Kural basittir: Karar maliyeti yükseldikçe yapılandırma artar.

2) ACH ile hipotez testi

Rakip hipotezleri sistematik biçimde yarıştırmak, ileri analizin "sigortasıdır". ACH yaklaşımında amaç, sevdiğin hipotezi parlatmak değil; yanlış hipotezi erken ve denetlenebilir biçimde elemektir.

2.1. ACH mantığı: destek değil, tutarsızlık

ACH'nin kalbinde şu değişim vardır:

• Kanıtı "hipotezi destekliyor mu?" diye değil, "hipotezle ne kadar tutarsız?" diye okumak.
• En güçlü aday, en çok "desteklenen" değil; en az çürütülebilen hipotezdir.

2.2. Tipik hatalar ve nasıl yakalanır?

• Hipotezi dar yazmak: Alternatif açıklamaları daha baştan dışarı atmak.
• Kanıt seçmek: Sadece işe yarayan parçaları toplamak.
• Bağımsızlığı göz ardı etmek: Aynı iddianın farklı yerde görünmesini bağımsız doğrulama sanmak (kopya ekosistemi riski).

Örnek: Bir olayda "neden"i açıklamak için üç hipotez kuruluyor:

• H1: Dış kaynaklı saldırı
• H2: İçeriden kötü niyetli eylem
• H3: Yanlış yapılandırma / süreç hatası\ ACH mantığı, her hipotez için "en çürütücü" kanıt türlerini önceden tanımlar. Örneğin H1 için güçlü çürütücü kanıt: olayın tüm izlerinin yalnızca iç sistem değişiklikleriyle açıklanabilmesi; H3 için güçlü çürütücü kanıt: değişiklik yönetimi kayıtlarıyla tutarsız bir zaman çizgisi gibi.

İpucu: Zaman baskısı varsa "tam ACH" yerine mini-ACH kullanın: 2-3 hipotez + her hipotez için bir güçlü çürütücü kanıt arama.\ Bu, hız kazandırırken "tek hikâyeye kilitlenme"yi engeller.

Dikkat: "Kaynak popülerliği" kanıt değildir. Çok tekrar edilen iddialar, bazen sadece iyi çoğaltılmış iddialardır.

3) Belirsizlik ve confidence ifadesi

Belirsizlik, CTI'nin zayıflığı değil; doğasıdır. Zayıflık, belirsizliği saklamak veya belirsizliği "muğlak" kelimelerle geçiştirmektir. "Belki/olabilir" gibi ifadeler karar vericiyi rahatlatmaz; standartlaştırılmış bir confidence dili ve dayanak yapısı rahatlatır.

3.1. Belirsizlik türlerini ayırmak

• Teknik belirsizlik: Veri eksikliği, telemetri kör noktaları, ölçüm hatası, zaman penceresi darlığı.
• İstihbarat belirsizliği: Niyet/motivasyon bilinmezliği, çelişkili göstergeler, deception olasılığı.

Bu ayrım, "neden emin değiliz?" sorusunu netleştirir: ölçemediğimiz için mi, yorum sınırımız olduğu için mi?

3.2. Confidence'ı dayandırmanın üç sütunu

• Kanıt kalitesi: Doğrudan gözlem mi, türetilmiş yorum mu?
• Kaynak bağımsızlığı: Aynı kökten kopyalanmış tekrar mı, farklı ölçüm türleri mi?
• Zaman uyumu: İddia ile gözlem penceresi tutarlı mı?

Örnek: "Aynı aktör" gibi güçlü bir yargı yerine, kanıtın izin verdiği sınırda yazım:\ "Altyapı örüntüsünde benzerlikler var; ancak paylaşımlı servis kullanımı ve commodity yapılandırma olasılıkları nedeniyle çıkarım orta confidence. Bağımsız, zaman uyumlu ek telemetri gelirse confidence artar; ters yönde kanıt görülürse düşer."

3.3. Yöntem seçimi: niteliksel mi, olasılıksal mı?

• Niteliksel confidence: Hızlıdır; ancak öznel kayma riski taşır.
• Olasılıksal modelleme (ör. Bayesçi yaklaşım): Daha disiplinli olabilir; fakat veri ve hesaplama yükü getirir.

İleri seviye pratikte seçim şuna dayanır: kararın geri dönüş maliyeti ve mevcut veri kalitesi. Veri zayıfsa, aşırı matematiksel kesinlik yanıltıcı bir "kesinlik hissi" doğurabilir; veri güçlü ve süreç olgunsa olasılıksal çerçeve, belirsizliği daha tutarlı taşır.

İpucu: Confidence cümlesi, tek başına bir etiket değil; mini bir sözleşme olsun:\ "Şu nedenle şu düzeydeyiz; şu gelirse artar; şu görünürse azalır."

4) Analitik kalite kapıları (quality gates)

Yayınlanabilir CTI üretimi, "iyi analist"e emanet edilen bir şans işi olmamalı; kalite kapılarıyla korunmalıdır. Bu kapılar hem hatayı erken yakalar hem de kurum içinde istihbaratın güvenilirliğini standardize eder.

4.1. Asgari kalite kapıları

• Peer review: İkinci göz, özellikle önyargı ve mantık sıçramalarını yakalar.
• Kaynak izlenebilirliği: "Bu yargı hangi kanıta dayanıyor?" sorusu tek adımda cevaplanabilmeli.
• Kanıt zinciri kontrolü: Gözlem-yorum ayrımı korunmuş mu?
• Mantık hatası/safsata kontrolü: Korelasyonu nedensellik sanma, tek örnekten genelleme, otoriteye dayandırma; hatta bazen tartışmayı "kişiye" indirgeme (ad hominem) gibi hatalar var mı?

4.2. Checklist yaklaşımı: otomatik mi, manuel mi?

• Otomatik checklist/kurallar: Hız kazandırır; ama derin bağlamı kaçırabilir.
• Manuel inceleme: Derindir; ancak yorgunluk ve tutarlılık riski taşır.

En iyi pratik: otomasyonun "hızlı eleme" gücünü kullanıp, kritik yargılarda insan onay kapısını korumaktır.

Örnek: Bir raporda "X artıyor" denmiş olsun. Peer review, şu üç soruyu zorunlu kılar:
* "Artıyor" hangi ölçüme dayanıyor?
* Ölçüm metodu sabit mi?
* Alternatif açıklama (raporlama artışı / görünürlük değişimi) elendi mi?\ Bu sorular net değilse ifade yeniden yazılır: "Gözlenen raporlama sıklığı arttı" gibi.

Dikkat: Otomasyon, doğruyu hızlandırdığı gibi yanlışı da hızlandırır. Zayıf kanıt zinciri, otomasyonla daha geniş alana yayılır.

İpucu: Yayın öncesi kısa bir "kırmızı bayrak taraması" rutini oluşturun:\ En güçlü yargıyı seçin → dayandığı kanıt satırını gösterin → en güçlü alternatif açıklamayı yazın.\ Bu üç adım, birçok hatayı görünür kılar.

5) Deception, data poisoning ve mis/disinformation

İleri seviye tehdit aktörleri sadece sistemlere değil, algıya da saldırır. Bu nedenle CTI, "tehdidi" izlerken aynı zamanda tehdit tarafından üretilen bilgi alanının manipüle edilebileceğini kabul eder.

5.1. Deception: yanıltma tasarımı

Deception; sahte izler, paylaşımlı altyapı üzerinden "başkasına benzetme", commodity araçların "imza" gibi kullanılması veya zaman çizgisini bozacak biçimde eski verinin yeni gibi servis edilmesiyle görülebilir. Burada kritik nokta şudur: Deception, genellikle "kanıt varmış gibi" görünür; ama kanıt zinciri kırılgandır.

5.2. Data poisoning: analiz hattını kirletme

Data poisoning; CTI beslemelerine, açık kaynaklı listelere veya paylaşım kanallarına yanlış/yanıltıcı sinyaller enjekte edilerek savunmanın yanlış yönlendirilmesidir. Amaç bazen "kör etmek", bazen de savunmayı pahalı bir yanlış hedefe koşturmaktır.

Yaygın işaretler

• Tek kaynaktan çıkan büyük iddianın hızla çoğalması (kopya ekosistemi)
• Zaman çizgisi tutarsızlığı
• Kanıtsız "yüksek etki" iddiaları
• Bağımsız doğrulama girişimlerinin sürekli sonuçsuz kalması

Örnek: Aynı iddia farklı kanallarda aynı cümlelerle dolaşıyor; yöntem/kanıt yok. Bu görünüşte "çok kaynak", gerçekte "tek iddia" olabilir. Doğru yaklaşım; iddiayı yaygınlıkla değil doğrulanabilirlikle sınıflamak, etkisini raporda sınırlamak ve güven seviyesini düşürmektir.

5.3. Karşı önlemler: doğrulama stratejisini riskle hizalamak

• Çoklu bağımsız doğrulama: Aynı iddiayı farklı ölçüm türleriyle sınamak.
• Kök kaynak izleme: "İlk nerede çıktı?" sorusunu sistematikleştirmek.
• High-confidence only kapıları: Düşük doğrulanabilir sinyallerin otomatik yayılımını kesmek.
• Kaynak bağımlılığını azaltma: Tek bir kanala aşırı yüklenmemek.

6) Analitik karşı-istihbarat disiplini

Counter-intelligence bakışı, analistin üretiminin de hedef olabileceğini kabul eder: raporlar yönlendirilebilir, algı operasyonlarına alet edilebilir, yanlış önceliklendirme tetiklenebilir. Bu yüzden analistin sorumluluğu yalnızca "doğru yazmak" değil; doğruyu doğru kişiye, doğru ölçüde ulaştırmaktır.

6.1. Motivasyon ve çıkar analizi: "Cui bono?"

Kritik bir refleks şudur: "Kimin yararına?" (Cui bono?)\ Bir bilginin zamanlaması, tonu ve yayılma biçimi; arkasındaki motivasyonu ele verebilir. Bu, komplo üretmek değil; manipülasyon riskini yönetmektir.

Örnek: Bir paydaş "kesin aktör adı" talep ediyor; kanıt ise sınırlı benzerliklere dayanıyor. Analitik karşı-istihbarat refleksi, baskıya boyun eğmek yerine şunu yapar:

• Yargıyı kanıta bağlar (iddia-kanıt ayrımı)
• Alternatif açıklamayı ekler
• Olasılıksal dili ve confidence dayanağını netleştirir\ Böylece rapor, "isteğe" göre değil "kanıta" göre şekillenir.

6.2. Paylaşım disiplini: need-to-know ve minimum bilgi

• Need-to-know: Her bulgu herkese gitmez; tüketici ve karar türüyle sınırlandırılır.
• Minimum bilgi: Savunma duruşunu gereksiz ifşa eden ayrıntılar, saldırganın adaptasyon hızını artırabilir.
• Güvenli iletişim: Kanal seçimi, erişim kontrolü ve denetlenebilirlik, analitik kalitenin parçasıdır.

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• Önyargıların analiz çıktısını nasıl çarpıttığını ve hijyen pratikleriyle nasıl yönetileceğini
• ACH/mini-ACH ile rakip hipotezlerin nasıl kurulup kanıtın “çürütme gücü” üzerinden nasıl tartılacağını
• Belirsizliği saklamadan, confidence dilini kanıt zinciriyle temellendirerek nasıl yazılacağını
• Peer review, izlenebilirlik ve mantık hatası kontrolleriyle kalite kapılarının nasıl işletileceğini
• Deception ve data poisoning risklerinde doğrulama stratejisinin nasıl sıkılaştırılacağını
• Analitik karşı-istihbarat bakışıyla motivasyon analizi, need-to-know ve minimum bilgi disiplininin neden analitik kaliteye dahil olduğunu

MODÜL 4 — Processing, Modelleme ve CTI Platformları

Modül Teması

Bu modül, CTI'de "iyi analiz"in tek başına neden yetmediğini; analizin ölçeklenebilir, denetlenebilir ve tekrar üretilebilir bir üretim hattına dönüşmesi gerektiğini ele alır. Ham sinyallerin (iç/dış) temizlenmesi, anlamlandırılması, doğru veri modeline oturtulması ve platform üzerinde yönetişimle yaşatılması; doğru tasarlanmadığında "yanlış veriyi çok hızlı yayma" riskini büyütür. Bu yüzden odak; veri kalitesi, ilişkilendirmenin maliyeti, STIX/TAXII'nin pratik rolü ve TIP/CTI platformlarının hangi probleme nasıl cevap verdiğini kanıt zinciri, belirsizlik ve yöntem seçimi perspektifiyle düşünmektir.

1) Normalizasyon ve Veri Kalitesi

Farklı kaynaklar aynı kavramı farklı biçimde taşır: alan isimleri, formatlar, zaman mantığı, sınıflandırma dili, hatta "gözlemlendi" ile "raporlandı" zamanları... Normalizasyon, bu heterojenliği ortak bir sözlüğe ve kurala bağlayarak otomasyonun "güvenli çalışacağı zemini" hazırlar. Buradaki ileri seviye fark şudur: normalizasyonu hız için değil, hatanın maliyetini düşürmek için yaparsın.

1.1. Normalizasyonun operasyonel bileşenleri

• Alan tekilleştirme: "domain / fqdn / host" gibi alanların kurumsal sözlükte bir karşılığa bağlanması
• Zaman tutarlılığı: saat dilimi, epoch-ISO dönüşümü, "observed vs reported" ayrımı
• Bağlam tutarlılığı: kaynak, kapsam (scope), sınıflandırma (örn. TLP), kanıt düzeyi/confidence yoksa veri "teknik olarak doğru görünse bile" operasyonel olarak zayıftır
• Deduplikasyon: aynı sinyalin tekrar tekrar akması analist yorgunluğu ve platform şişmesi üretir; ileri seviye deduplikasyon "aynı string"i silmekten çok, bağlamı aynı kayıtları birleştirmektir

1.2. Entity resolution: Güçlü ama riskli karar

Entity resolution, farklı kaynaklardan gelen kayıtların "aynı varlık mı?" sorusuna cevap verir. Bu karar yanlışsa CTI'nin en pahalı hatalarından biri doğar: yanlış ilişkilendirme.

• Aynı alan adı farklı zamanlarda el değiştirmiş olabilir
• Aynı IP paylaşımlı altyapı/çok kiracılı (multi-tenant) olabilir
• Benzer etiketler/isimler "aynı varlık" anlamına gelmeyebilir
• "Eşleştiremedim" de maliyetlidir: tehdit parçalı görünür, kampanya bütünlüğü kaçabilir

Dikkat: "Veriyi temizlemek" ile "veriyi yok etmek" arasındaki çizgi incedir. Aşırı agresif deduplikasyon ve kısa TTL; geçmişte zayıf görünen ama kritik bağ kurduracak sinyalleri kaybettirebilir. Yetersiz deduplikasyon ise platformu çöplüğe çevirir. Doğru seçim, yanlış kararın maliyetine göre yapılır.

1.3. Tazelik (freshness), TTL ve sürümleme (versioning)

CTI verisi yaşlanır. Dün anlamlı olan IOC bugün gürültü olabilir. Bu yüzden:

• Freshness: karar için hâlâ anlamlı mı?
• TTL: ne kadar süre "geçerli sayılacak"?
• Sürümleme: "şu an ne?" kadar "geçmişte neydi?" sorusunu da denetlenebilir kılar (özellikle geriye dönük soruşturma ve kampanya analizi için)

İpucu: Her veri tipi için "minimum alan seti" tanımla. Kaynak + zaman + bağlam/confidence + sınıflandırma yoksa, kaydı "aksiyon verisi" yerine "ham sinyal" olarak tut. Bu küçük ayrım, modül 3'teki kanıt zinciri disiplinini platforma taşır.

Örnek:\ Bir kaynak example.net alan adını "malicious", başka bir kaynak "suspicious" diye işaretliyor. Normalizasyon; bu etiketleri kurumsal ölçeğe çevirir. Eğer "neden/kanıt" alanı boşsa confidence düşürülür ve kayıt otomatik aksiyona değil "kürasyon bekleyen sinyal" havuzuna yönlenir. Böylece platform "etiket kavgası" yerine kanıt kalitesiyle çalışır.

2) CTI Veri Modeli Mantığı

Veri modeli, "depoda ne sakladığını" değil; hangi kararı nasıl desteklediğini tanımlar. Aynı IOC listesi iki farklı modelde iki farklı sonuca gider: biri gürültü üretir, diğeri ilişki kurdurur.

2.1. Nesneler: Ne saklıyorsun, neden saklıyorsun?

• IOC (Indicator): tekil gösterge; kısa ömürlü olabilir. Tek başına değeri sınırlı, bağlamla değer kazanır.
• Sighting: "Bu IOC/varlık nerede, ne zaman, hangi bağlamda görüldü?" kaydıdır. Operasyonel doğrulamanın omurgasıdır.
• Relationship: varlıklar arasında bağ kurar. Doğruysa analizi hızlandırır, yanlışsa hikâyeyi bozar.
• Campaign: belirli zaman penceresinde tutarlı örüntü sergileyen faaliyet kümesi.
• Intrusion Set: daha uzun vadeli ve stabil örüntülerle takip edilen aktör kümesi. Amaç "isim vermek" değil, takip edilebilir tutarlılık üretmektir.

2.2. İlişki türleri: "Bağlantılı" demek yetmez

İlişkinin türü, analizin anlamını değiştirir. Örneğin bir hash ile bir IP arasındaki bağ:

• "iletişim kuruyor" mu,
• "içinden çıkıyor" mu,
• "indiriliyor" mu?

Bu ayrım; capability/motivasyon okumayı, yanlış pozitif riskini ve aksiyonun türünü etkiler.

İpucu: İlişkileri zihninde iki katmanda tut:

1. — Gözlem katmanı (kanıtlanmış bağ)
2. — Hipotez katmanı (benzerlik/örüüntüye dayalı aday bağ)\ Platformda bu ayrım görünür olmalı; aksi halde "hipotezler" sessizce "kanıt" gibi dolaşır.

2.3. Yanlış ilişkilendirmenin maliyeti ve kanıt standardı

İlişki kurmak CTI'nin en güçlü ve en riskli hamlesidir. Yanlış ilişki:

• SOC tarafında yanlış bloklamaya,
• IR tarafında yanlış önceliklendirmeye,
• yönetim tarafında yanlış risk anlatımına dönüşebilir.

Bu yüzden modül 3'teki yaklaşımı platform diline çevir:

• İlişki hangi kanıta dayanıyor? (kaynak-iddia-kanıt ayrımı görünür olsun)
• Karşı kanıt ne olurdu? (hangi bulgu bu bağı zayıflatır/bozar?)
• Zaman uyumu var mı? (aynı anda var olamayacak şeyleri bağlama)
• Confidence: ne kadar eminsin, neden? Hangi koşulda fikrin değişir?

Örnek:\ Aynı sertifika örüntüsünü paylaşan iki domain için "aynı aktör" demek cazip gelebilir. Doğru yaklaşım: bunu "benzerlik sinyali" olarak tutmak; paylaşımlı altyapı/otomasyon gibi alternatif açıklamaları not etmek ve zaman uyumunu kontrol etmeden "aktör bağı"na yükseltmemektir.

3) STIX/TAXII: Pratikte Ne Sağlar, Ne Garanti Etmez?

STIX, CTI nesnelerini ve ilişkilerini standart bir şema ile ifade eder; TAXII ise bu içeriğin standart bir mekanizma üzerinden taşınmasını hedefler.\ Pratik değeri şuradadır: paylaşımı yapılandırır, otomasyonla uyumlu hale getirir, "ne gönderildi/ne alındı" izini tutmayı kolaylaştırır.

3.1. En kritik sınırlama: Format kalite damgası değildir

STIX/TAXII, içeriğin doğruluğunu garanti etmez. Yapılandırılmış yanlış veri, yapılandırılmamış yanlış veriden daha tehlikeli olabilir; çünkü otomasyon onu daha hızlı tüketir.

Dikkat: "STIX ile geldi" ifadesi tek başına güven nedeni olamaz. Özellikle bağlam alanları (kaynak, zaman penceresi, metodoloji, scope, confidence, sınıflandırma) boşsa; veri, aksiyon yerine kürasyon ve doğrulama gerektirir.

3.2. "Context fields" boşsa ne yaparsın?

• İçeriği "doğrudan aksiyon" yerine "ham sinyal" olarak sınıflandır
• Platform içinde ek doğrulama/curation kapısı işlet
• Bağımsız veriyle (kurum içi telemetri, güvenilir ikinci kaynak, geçmiş doğruluk skoru) karşı kanıt ara
• Belirsizliği saklama: "yüksek" demek yerine gerekçeli confidence kullan

Örnek:\ Bir STIX paketinde çok sayıda IOC var; ancak sighting bilgisi, zaman penceresi ve üretim metodolojisi belirsiz. Bu durumda doğru yaklaşım, IOC'leri otomatik engelleme listesine sürmek değil; "doğrulama bekleyen sinyal" olarak işaretleyip, yalnızca yeterli kanıt oluştuğunda dissemination seviyesini yükseltmektir.

4) TIP Yaklaşımı ve Yönetişim

TIP, "araç"tan önce bir işletim modeli gerektirir. Platformu kurmak CTI'yi operasyonelleştirmez; süreç ve yönetişim kurmak operasyonelleştirir. TIP'i, istihbarat üretimini orkestre eden bir merkez gibi düşün: doğru tasarlanırsa hız + kalite birlikte artar; yanlış tasarlanırsa gürültü ve hatayı ölçeklersin.

4.1. Üretim hattı: ingestion → enrichment → correlation → curation → dissemination

• Ingestion: iç/dış kaynaklardan veri içeri alma
• Enrichment: bağlam katma (ör. whois / passive DNS / sandbox sonuçları gibi ek nitelikler; aynı zamanda kaynak skoru, sınıflandırma, ilişki adayları)
• Correlation: kayıtları çakıştırma, örüntü çıkarma, ilişki adaylarını üretme
• Curation: kalite kapısı; insan onayı / yayınlanabilirlik kontrolü
• Dissemination: doğru tüketiciye doğru formatla yayılım (SOC, IR, yönetim, risk vb.)

Buradaki ileri seviye disiplin, her aşamada aynı üç soruyu sormaktır:

1. — Bu veri hangi kararı etkiliyor?
2. — Yanlışsa maliyeti ne? (noise/FP/operasyon yükü)
3. — Bu adım otomatik mi, yoksa insan onaylı mı olmalı?

İpucu: Curation'ı bürokrasi sanma. Curation, modül 3'teki "kanıt standardı"nın platforma gömülmüş halidir. Otomasyonun güvenli çalışması, curation'ın doğru tasarlanmasına bağlıdır.

4.2. RBAC, değişiklik yönetimi ve denetlenebilirlik

• RBAC: herkes her şeyi görmez/değiştirmez; rol ve sorumluluk ayrımı veri bütünlüğünü korur
• Değişiklik yönetimi: "kim, neyi, ne zaman, neden değiştirdi?" sorusunu cevaplar
• Denetlenebilirlik: bir ürün geri dönüp incelendiğinde kanıt zinciri ve değişim izi görünür olmalıdır

Örnek:\ Bir kaynak "yüksek etkili yeni tehdit" duyurusu yapıyor. Ingestion veriyi alır; enrichment kaynağın geçmiş doğruluk skorunu ve metodoloji bilgisini ekler; correlation kurum içi telemetride karşılık arar; curation yeterli kanıt yoksa dissemination'i "uyarı" yerine "izleme" seviyesine çeker. Böylece yanlış alarm maliyeti kontrol altında kalır.

5) Platform Ekosistemi: Paylaşım mı, Bilgi Grafiği mi?

Bu bölümün amacı "hangi aracı seçmeliyim?" tartışması değil; ekosistemdeki yaklaşımların hangi probleme cevap verdiğini ve doğru tasarım ilkelerinin platformdan bağımsız olduğunu görmektir.

5.1. Konumlandırma: Platformu isimle değil, problemle seç

• Paylaşım/indicator akışı güçlü senaryolarda MISP gibi topluluk ve paylaşım odaklı yaklaşımlar sık tercih edilir.
• İlişki odaklı modelleme, kampanya/aktör takibi ve bilgi grafiği yaklaşımında OpenCTI gibi graf tabanlı sistemler öne çıkabilir.

Bu farklılık "mutlak üstünlük" değil; kurumsal veri modeli ve entegrasyon stratejisi meselesidir.

5.2. Bilgi grafiği (knowledge graph) ne kazandırır, neye mal olur?

Graf yaklaşımı; dolaylı ilişkileri görmeyi, pivoting'i ve kampanya örgüsünü takip etmeyi kolaylaştırır (kampanya/kümelenme mantığını modül 8'de derinleştireceğiz). Bedeli ise karmaşıklıktır: ilişki hijyeni bozulursa graf "hikâye üretir" ama gerçeği taşımaz.

5.3. Tasarım ilkeleri: Platformdan bağımsız sabitler

• Veri modeli uyumu: Platform, kurumsal modelinle kavga etmemeli
• Entegrasyon stratejisi: SIEM/SOAR/EDR gibi tüketicilere giden hatta nerede otomatik, nerede insan onaylı?
• Kalite kapıları: confidence gate + curation politikaları yanlış verinin yayılımını kesmeli
• Yönetişim: erişim, değişiklik yönetimi, denetlenebilirlik "sonradan eklenen özellik" değil, ilk günden zorunluluktur

Dikkat: Model ve süreç olmadan yapılan platform seçimi "araç merkezli CTI" doğurur. Araç merkezli CTI metrikleri şişirebilir; fakat karar kalitesini artırmaz.

Örnek:\ SOC çok hızlı IOC tüketiyor; yönetim ise kampanya eğilimlerini görmek istiyor. Tasarım ilkesi şunu söyler: IOC akışı için hızlı ingestion + sıkı TTL, kampanya takibi için daha güçlü ilişki modeli + daha yüksek curation standardı. Tek platformla da yapılabilir, birden fazla bileşenle de; kritik olan "hangi çıktıya hangi kalite kapısı"nın bağlanacağıdır.

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• Normalizasyon, deduplikasyon ve veri kalitesinin “hijyen” değil karar maliyeti yönetimi olduğunu
• Entity resolution kararlarının neden riskli olduğunu; tazelik/TTL ve sürümlemenin bu riski nasıl büyütüp nasıl kontrol edebileceğini
• IOC–sighting–relationship–campaign–intrusion set gibi kavramların veri modelinde “etiket” değil karar destek yapı taşları olduğunu
• STIX/TAXII’nin paylaşımı yapılandırdığını; fakat doğruluk ve bağlam garantisi vermediğini, bu yüzden kalite kapılarıyla desteklenmesi gerektiğini
• TIP hattının ingestion’dan yayılıma kadar kalite kapıları, denetlenebilirlik ve rol yönetimi ile birlikte tasarlanması gerektiğini
• Platform ekosisteminde seçimin araç isminden çok veri modeli uyumu, entegrasyon ve yönetişim meselesi olduğunu

MODÜL 5 — Gelişmiş Teknik İstihbarat ve Pivoting Teknikleri

Modül Teması

Tek bir göstergeden yola çıkıp saldırgan altyapısını "bulduğunu sanmak" ile, altyapıyı kanıt standardında haritalandırmak arasında büyük fark vardır. Bu modül, teknik sinyaller (DNS, IP/ASN, TLS sertifikaları, sunucu yapılandırmaları ve metaveri izleri) üzerinden pivoting yaparken; zayıf bağları nasıl bulacağını, bu bağları nasıl doğrulayacağını ve en önemlisi yanlış ilişkilendirme (FP) maliyetini yöneterek operasyonel değere çevirmeyi ele alır. Odak, hızla "daha çok şey bağlamak" değil; neden bağladığını, hangi karşı kanıtı aradığını, hangi şartlarda fikrinin değişeceğini açıkça gösterebilen bir analiz disiplinidir. Modül 4'te kurulan veri modeli, normalizasyon ve kalite kapıları, burada "grafiği büyütmek" yerine doğru grafiği üretmenin zeminini oluşturur.

1) Pivoting: Teknik bir refleks değil, iddia-kanıt-karar disiplini

Pivoting, bir "tohum sinyal" (seed) üzerinden arama uzayını genişletmektir. Fakat ileri seviyede pivoting; "tıklayıp bulma" değil, her adımda iddia kurma, kanıt arama ve karar verme işidir:

• İddia: "Bu iki varlık aynı operasyona ait olabilir."
• Kanıt: "Hangi bağımsız sinyaller bunu destekliyor? Zaman uyumu var mı? Alternatif açıklama ne?"
• Karar: "Bunu ilişki olarak modelleyip yayına alacak mıyım, yoksa hipotez olarak mı tutacağım?"

İki uç hata biçimi özellikle yıkıcıdır:

• Yetersiz pivot: Parçalı resim; ilişkiyi kuramadığın için operasyonel değer düşer.
• Aşırı pivot (over-pivoting): İlgisiz varlıkları aynı kümeye alırsın; yanlış hikâye üretir, yanlış aksiyon aldırırsın.

Dikkat: Pivoting'de en tehlikeli an, "bağlantı buldum" hissinin kanıt sanıldığı andır. Bağlantı çoğu zaman yalnızca aday açıklamadır; kanıt ise alternatif açıklamalarla yarışıp ayakta kalabilendir.

1.1. "Kanıta yakın" pivotlar ile "benzerlik" pivotları arasındaki çizgi

Pivotlar kabaca iki sınıfa ayrılır; aralarındaki çizgi, modül 3'te konuştuğumuz bilişsel hataların en sık tetiklendiği yerdir:

• Kanıta yakın pivotlar: Zaman ve bağlamla desteklenmiş, tekrar üretilebilir izler.\ Örnek: Kurum içi DNS loglarında bir domainin aynı zaman penceresinde belirli istemci segmentinde tekrarlanan çözümlemesinin görülmesi (sighting niteliği).
• Benzerlik pivotları: Tek başına yeterli olmayan, "hipotez üretici" sinyaller.\ Örnek: İki farklı domainin TLS sertifika kalıbının benzemesi ya da isimlendirme örüntüsünün benzer görünmesi.

Benzerlik pivotları çöpe atılmaz; ama "ilişki" diye etiketlenmez. Doğru konum, hipotez havuzudur: "Bu benzerlik hangi ek kanıtlarla desteklenirse anlamlı bir bağa dönüşür?"

1.2. Pivot zinciri ve kalite kapıları

Pivot zinciri, "tohum → adaylar → doğrulama → ilişkilendirme" akışıdır. Zincirde kaliteyi korumak için üç pratik ilke işe yarar:

1. — Minimum bağlam eşiği: Kaynak, zaman, kapsam ve confidence alanları eksikse otomatik yayına gitmemek.
2. — Maliyet muhasebesi: Her adım için "Bu adım yanlışsa maliyeti ne?" sorusunu sormak (noise, FP, operasyonel yük, yanlış bloklama riski).
3. — Değişim koşulu: Her halkaya "Hangi şartlarda fikrim değişir?" notunu iliştirmek (yeni sighting, zaman uyumsuzluğu, farklı tenant göstergesi vb.).

İpucu: Pivot zincirini bir "harita" gibi düşün. Bazı yollar seni hedefe götürmez; ama "burada dur" demeyi öğretir. Bu da çıktı kalitesidir.

2) Altyapı analizi: "Şu an" değil, "tarihçe" konuşur

Saldırganların alan adları ve sunucuları boşlukta durmaz; internet ekosistemiyle sürekli etkileşim halindedir. İleri seviye altyapı analizi, yalnızca "şu an ne var?" sorusunu değil, "bu varlık zaman içinde nasıl değişti?" sorusunu merkeze alır.

2.1. Passive DNS (pDNS): Geçmişin izleri ve coverage gap gerçeği

DNS kayıtları geçicidir. pDNS, bir alan adının geçmişte hangi IP'lere çözüldüğünü gösteren tarihsel bir iz seti olarak değerlidir.

• Neden önemli? Bir C2 altyapısı bugün kapalı olabilir; pDNS, geçmiş çözümlemeler üzerinden altyapının rotasyon davranışını (örneğin hızlı değişim örüntüleri) ve kampanyalar arası sürekliliği görünür kılabilir.
• Sınır: pDNS, sensör kapsamasına bağlıdır. "Kayıt yok" bazen "etkinlik yok" değil, coverage gap anlamına gelir.

Örnek:\ example.org alan adının kısa bir dönemde 203.0.113.0/24 bloğunda görüldüğünü varsayalım. Bu, altyapı davranışı hakkında hipotez üretir; fakat "kayıt yok" dönemlerini "temiz" diye yorumlamak yerine, veri kapsamını sorgulamak gerekir.

2.2. WHOIS ve tarihsel WHOIS: GDPR sonrası dünyanın "ilk an" avantajı

Güncel WHOIS kayıtları birçok durumda "Redacted for Privacy" şeklinde sınırlı görünür. Buna rağmen tarihsel WHOIS hâlâ değerlidir; çünkü saldırganlar çoğu zaman "ilk anda" OPSEC hatası yapar.

• Alan adı ilk kaydedilirken gizlilik korumasını açmayı unutmak,
• Kurumsal olmayan bir e-posta kullanmak,
• Tutarlı bir registrar/kimlik izi bırakmak...

Bir kez kayda düşen hata, yıllar sonra bile ilişkilendirmede güçlü bir sinyal olabilir. Buradaki kritik nokta şudur: Bu tür sinyaller bile tek başına "aktör" demek değildir; bağımsız doğrulama ister.

İpucu: Tarihsel WHOIS bir "itiraf" değildir; bir "iz"dir. İz, ancak zaman ve diğer sinyallerle tutarlıysa anlamlı olur.

3) Fingerprinting ve benzerlik analizi: "kimlik" değil, "yapılandırma karakteri"

Fingerprinting, bir sunucunun kimliğini değil; yapılandırma karakterini yakalamaya çalışır. Amaç, iki farklı IP'nin aynı aktör tarafından aynı araç setiyle kurulup kurulmadığına dair örüntü üretmektir. Bu örüntü, doğrulanmadıkça "kanıt" değildir.

3.1. Sertifika ekosistemi sinyalleri: güçlü pivot, kırılgan kesinlik

TLS sertifikaları altyapı takibinde güçlü bir pivot noktası olabilir; fakat sertifikalar taklit edilebilir, yeniden kullanılabilir, hatta kasıtlı olarak karıştırılabilir.

• Serial Number / Subject gibi alanlar bazen birden çok uç noktada tekrar edebilir. Bu, kümelenme için iyi bir başlangıçtır.
• Ancak sertifika sinyali çoğu zaman benzerlik pivotu kategorisindedir: "Benzedi" → "Aynı aktör" demek için yeterli değildir.

Örnek:\ example.net üzerindeki bir hizmetin sertifika izi, başka iki varlıkla benzer görünüyor. Bu, "aynı operasyon olabilir" hipotezini doğurur; fakat kurum içi sighting, zaman uyumu ve başka bağımsız sinyaller olmadan "yüksek güven" ile ilişki kurulmaz.

3.2. JARM ve benzeri yaklaşımlar: benzersizlik sorusunu sormadan pivot yapılmaz

JARM, TLS "handshake" parametrelerinden türetilen bir parmak izi yaklaşımıdır. Pratikte değer üretir; fakat Common Infrastructure Trap (ortak altyapı tuzağı) burada çok yaygındır:

• Eğer parmak izi bir CDN, reverse proxy veya varsayılan bir sunucu kurulumunu temsil ediyorsa, aynı iz çok geniş bir meşru kümeye de ait olabilir.
• Bu yüzden en kritik soru şudur: "Bu yapılandırma ne kadar benzersiz?"\ Benzersizliği düşük bir parmak izini IOC gibi kullanmak, FP ve operasyonel yük üretir.

Dikkat: Fingerprinting, hızlıdır ama "hızlı" olmak bazen gürültüyü hızla büyütmek demektir. Kritik kararlar için otomatik benzerliği, manuel ve bağlamsal kontrolle dengelemeden kanıta yükseltme.

3.3. Multi-tenant etkisi ve yanıltıcı benzerlikler

CDN ve reverse proxy, çok kiracılı (multi-tenant) doğasıyla benzerlikleri "hak etmediği kadar güçlü" gösterebilir. Aynı şey paylaşımlı barındırma ve büyük bulut sağlayıcılarında da görülür.

• Benzerlik varsa, önce "tesadüf/ortak servis" alternatifini sınamak gerekir.
• Benzerlik "aktör" iddiasına değil, "örüntü adayına" hizmet eder.

4) Kanıt standardı: zaman uyumu, bağımsız doğrulama ve tekrar üretilebilirlik

Pivoting'de en sık gözden kaçan doğrulama ekseni zamandır. IP'ler el değiştirir, barındırma rotasyon geçirir, domainler başka amaçla yeniden kullanılabilir. Bu yüzden ilişki iddiasını güçlendiren şey, "aynı şeyi bir yerde daha gördüm" değil; aynı zaman diliminde tutarlı şekilde gördüm demektir.

4.1. Time correlation: ilişkiyi "aynı anda var olma" üzerinden test etmek

Bir varlık, geçmişte zararlı bir kampanyaya hizmet etmiş olabilir; bugün aynı IP'ye masum bir müşteri atanmış olabilir. Bu gerçeklik, iki tür hataya yol açar:

• Tarih bağlamı olmadan yapılan ilişkilendirme → masum altyapıların suçlanması
• Eski izlerin "bugün de geçerli" sanılması → yanlış aksiyon ve iş kesintisi

Örnek:\ 192.0.2.15 adresinin geçmişte example.net altında bir adla ilişkilendirildiğini düşünelim. İlişkiyi raporlamak için "o tarihte birlikte miydiler?" sorusu zorunludur. Co-existence yoksa, ilişki "tarihsel iz" olarak kalır; "aktif bağ" diye etiketlenmez.

4.2. Pivot zincirini paketlemek: gözlem-yorum ayrımı ve değişim koşulu

Kanıt standardında paketleme şu disiplinleri birlikte taşır:

• Hangi veri gözlem (kayıt/telemetri) hangisi yorum (ilişki iddiası)?
• Zincirin hangi halkası hangi kaynağa dayanıyor?
• Confidence neden o düzeyde?
• Hangi yeni veri geldiğinde güven artar/azalır?

Burada "confidence" bir etiket değil, gerekçeli bir cümle olmalıdır.

Örnek:\ "Orta güven: Zaman penceresi uyumlu iki bağımsız sinyal var; ancak paylaşımlı altyapı ihtimali nedeniyle ilişki hipotez seviyesinde tutuluyor. Aynı istemci segmentinde yeni sighting oluşursa güven artar; farklı tenant göstergeleri güçlenirse güven düşer."

5) İlişki grafiğiyle düşünmek: güzel görünen değil, doğru olan

Tabloyla okuduğun veriler, ağ grafiğinde bambaşka bir "hikâye" gibi görünür. Bu iyi bir şeydir; fakat aynı zamanda tehlikeli bir şeydir. Görselleştirme araçları (örneğin Maltego gibi link analysis yaklaşımları) bağlantı kurmayı sever; analistin görevi, bağlantıyı kanıtla terbiye etmektir.

5.1. Cluster, hub ve bağ gücü

• Cluster (küme): Birbiriyle ilişkili olduğu düşünülen düğümler grubu
• Hub (merkez düğüm): Birçok bağlantının birleştiği nokta

Hub görmek, "ana altyapı" bulduğun anlamına gelmeyebilir; bazen yalnızca ortak servis (CDN, büyük hosting, yaygın registrar) bulmuşsundur.

• Zayıf bağ (weak tie): Aynı ASN'de barınmak gibi; açıklayıcılığı düşük, gürültüsü yüksek olabilir.
• Güçlü bağ: Nadir ve tekrar eden bir yapılandırma izi veya bağlamla desteklenen çoklu bağımsız sinyal gibi.

5.2. Chart bias: gözün gördüğünü kanıt sanma

Grafikler "yakın duran" ve "bağlı görünen" şeylere anlam yükletir. Bu, chart bias'ın tipik yüzüdür: Görsel ikna, teknik doğrulamayı gölgeler.

Dikkat: "Güzel görünen grafik" çoğu zaman sunum başarısıdır; "doğru grafik" ise operasyonel güvenilirliktir. Çizginin varlığına değil, çizginin gerekçesine bak.

6) OPSEC ve etkileşim sınırları: gözlem + doğrulama, etkileşim değil

CTI'de "gözlemci etkisi" geçerlidir: Bir şeyi incelediğinde, incelemeye konu olan taraf bunun izini görebilir. Bu yüzden teknik pivoting'de kural basittir: pasif yöntem önceliği.

6.1. Pasif yöntemler neden önce gelir?

Pasif kaynaklar (önbellek/tarihsel veri üreten servisler, raporlar, kayıtlar, üçüncü taraf telemetri özetleri) genellikle kimliğini ifşa etmeden bağlam sağlar. Bu, OPSEC maliyetini düşürür ve "burn" (altyapının yakılıp kapatılması) riskini azaltır.

6.2. Aktif etkileşimin riski ve kurumsal çerçeve

Aktif etkileşim (bir altyapıya doğrudan temas) şu riskleri artırabilir:

• Kurumsal IP/kimlik izinin hedef loglarına düşmesi
• Altyapının kapatılması veya yanıltıcı veri sunulması
• Hukuki gri alanlar ve kurum politikasına aykırılık

Bu nedenle aktif etkileşim, "analizin doğal parçası" değil; kurumsal onay, risk analizi ve açık angajman kuralları çerçevesinde istisnai bir yöntem olarak düşünülür. Çoğu CTI bağlamında hedef, etkileşim değil; gözlem + bağımsız doğrulama ile güven inşa etmektir.

7) Çıktıyı ürünleştirmek: aksiyon listesi ile izleme kümesini ayırmak

Aynı teknik bulgu, farklı tüketiciler için farklı şekilde paketlenir:

• SOC / detection tüketimi: yüksek doğruluk, net bağlam, kısa TTL ve ölçülü otomasyon
• IR / soruşturma tüketimi: izlenebilir pivot zinciri, zaman çizelgesi uyumu, alternatif açıklamalar
• Yönetim / risk tüketimi: teknik detayın etkisi, belirsizlik dili ve "şartlar değişirse" notu

Bu ayrımı yapmadığında iki şey olur: ya SOC gereksiz gürültüyle boğulur ya da IR "bağ kurma" fırsatını kaçırır.

Örnek:\ Bir altyapı kümesi için iki ayrı çıktı üretmek çoğu zaman en sağlıklı yaklaşımdır:
Aksiyon listesi: yalnızca yüksek güven ve doğrudan kanıtlı göstergeler (kısa TTL, sıkı bağlam)
İzleme kümesi: benzerlik pivotları ve zayıf bağlar (açık belirsizlik notu, daha geniş gözlem)

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• Pivoting’in teknik bir refleks değil, iddia–kanıt–karar disiplini olduğunu
• pDNS ve WHOIS/tarihsel WHOIS’in değerini, limitlerini ve coverage gap gerçeğini
• Fingerprinting (sertifika, JARM vb.) sinyallerinin örüntü ürettiğini; ortak altyapı tuzaklarında FP maliyetini
• Time correlation olmadan yapılan ilişkilendirmenin neden güvenilmez olduğunu ve “aynı anda var olma” kontrolünü
• İlişki grafiği düşünürken cluster/hub/zayıf bağ kavramlarını ve chart bias riskini
• OPSEC’te pasif yöntem önceliğini, aktif etkileşimin hukuki/operasyonel risklerini ve kurum politikası uyumunu
• Aksiyon listesi ile izleme kümesini ayırarak çıktıyı tüketiciye göre ürünleştirmenin değerini

MODÜL 6 — TTP Analizi, Frameworks Deep Dive ve Intel Fusion

Modül Teması

Bu modül, siber tehdit istihbaratını "gösterge takibi" (IP, hash, alan adı) düzeyinden çıkarıp davranışsal analiz düzeyine taşır: saldırganın ne kullandığından çok nasıl hareket ettiğini (TTP) anlamaya odaklanır. Amaç, bir tekniği sadece "etiketlemek" değil; kanıt zinciri, belirsizlik yönetimi ve yöntem seçimi üzerinden denetlenebilir, operasyonel değere dönüşen bir analiz üretmektir. Çerçeveler (ATT&CK, Diamond Model, Kill Chain, D3FEND, VERIS ve ilgili düşünce modelleri) "hangisini ne zaman seçerim?" sorusuyla ele alınır; ardından intel fusion ile teknik bulguların iş bağlamına çevrilmesi ve risk anlatısına dönüşmesi öğretilir.

1) IOC'den davranışa: TTP analizi neden "ispat" işidir?

TTP (Tactics, Techniques, Procedures), saldırgan davranışını amaç-yöntem-uygulanış katmanlarında okumanı sağlar. Bu modülde kritik fark şudur: TTP, rapora eklenen bir "etiket" değil; kanıtla taşınan bir iddiadır.

• Tactic: Amaç/evre (niçin?)
• Technique: Yöntem sınıfı (nasıl?)
• Procedure: Sahadaki somut uygulanış (gerçekte nasıl göründü?)

Birçok ekip, procedure düzeyindeki bir gözlemi "technique" diye raporlayıp farkında olmadan kesinlik üretir. İleri seviye yaklaşım, iki soruyu sistematik hale getirir:

1. — "Bu gözlem hangi davranış sınıflarıyla uyumlu olabilir?"
2. — "Bu sınıflardan hangilerini karşı kanıt arayarak eleyebilirim?"

Dikkat: TTP eşlemesi, aktör/attribution iddiası değildir. Aynı teknik birden çok aktör tarafından kullanılabilir; bu ayrım modül 8'deki actor tracking ve attribution tartışmasının omurgasıdır.

1.1. Kanıt hiyerarşisi: doğrudan / dolaylı / negatif kanıt

TTP analizinde kanıtlar eşit ağırlıkta değildir:

• Doğrudan kanıt: Davranışı güçlü biçimde gösteren, tekrar üretilebilir ve zaman uyumlu gözlemler.
• Dolaylı kanıt: Davranışla uyumlu ama alternatif açıklamalara açık sinyaller.
• Negatif kanıt: Beklenen izin yokluğu/uyumsuzluğu; bazı hipotezleri zayıflatır.

Örnek: Kısa süreli "şüpheli kimlik doğrulama denemeleri" gözlemi, kaba bir "zorlamalı deneme" davranışıyla uyumlu olabilir; ancak aynı zaman penceresinde beklenen oturum kalıpları ve yan artefaktlar yoksa "yanlış yapılandırılmış otomasyon" hipotezi güçlenir. Burada doğru çıktı, kesin etiket değil; gerekçeli belirsizliktir.

1.2. "İddia-kanıt-karar" üçlüsü ve confidence dili

Bir TTP eşlemesi üç parçayı birlikte taşır:

• İddia: "Bu olay dizisi şu davranış ailesiyle uyumlu."
• Kanıt: "Hangi kaynakta hangi gözlem var; zaman uyumu ve tekrar üretilebilirlik ne durumda?"
• Karar: "Bunu 'eşleşti' diye mi yayınlıyorum, yoksa 'aday' diye mi tutuyorum? Yanlış olursa maliyeti ne?"

İpucu: Confidence'ı "yüksek/orta/düşük" gibi tek kelimeye indirgemek yerine, fikrini hangi şartlarda değiştireceğini mutlaka yaz. Bu, analizi savunulabilir ve denetlenebilir kılar.

2) MITRE ATT&CK ile ileri haritalama ve Gap Analysis

MITRE ATT&CK, saldırgan davranışları için bir "davranış taksonomisi"dir. İleri seviyede hedef, sadece saldırıyı haritalamak değil; savunmanın kör noktalarını bulmak ve bunu operasyonel çıktıya çevirmektir.

2.1. Doğru eşleme: "metinde geçti" → "eşleşti" değildir

Raporlarda bir anahtar kelime görmek, otomatik eşleme için yeterli değildir. Analist, davranışın nasıl gerçekleştiğini kanıtla ayırmalıdır.

Örnek: Bir raporda "PowerShell" geçmesi, doğrudan "T1059.001 (PowerShell)" etiketini haklı çıkarmaz. Bu kullanım sıradan yönetim otomasyonu da olabilir; davranışın bağlamını, zaman uyumunu ve eşlik eden izleri görmeden alt teknik düzeyinde kesinlemek, savunmayı yanlış yere odaklayabilir.

2.2. Least-commitment: kanıt yetmiyorsa daha genel düzeyde kal

Kanıt alt teknik ayrımını desteklemiyorsa, üst teknik düzeyinde kalmak daha doğrudur. Spesifiklik, doğruluğun garantisi değildir.

Örnek: Bir olay dizisi "valid accounts" gibi bir davranış ailesine uyuyor görünebilir (ör. T1078). Ancak olayın "yetkili hesap mı, yanlış yapılandırma mı, olağan dışı ama meşru erişim mi?" ayrımını yapacak kanıt yoksa, eşlemeyi "aday" olarak tutup ayırıcı kanıtı tarif etmek gerekir.

2.3. Defense coverage ve gap: görünürlük-tespit-müdahale katmanları

Gap analysis, "saldırgan ne yaptı?" ile "biz bunu nerede ve nasıl görebiliriz?" arasındaki farkı ölçer. Burada üç katman kritik hale gelir:

• Görünürlük (visibility): Bu davranış gerçekleşseydi, kurumda kanıt üretmeye yetecek telemetri var mı?
• Tespit (detection): Telemetri varsa, davranışı anlamlı şekilde yakalayan kural/analiz mevcut mu?
• Müdahale (response): Tespit edilse bile, operasyonel süreç bunu etkili biçimde containment/triage akışına sokabiliyor mu?

Bu gap çıktısı, "rapor notu" olarak kalmaz; olgun yapılarda detection engineering backlog'una dönüştürülür: hangi veri kaynağı eksik, hangi korelasyon yanlış, hangi kural aşırı gürültü üretiyor?

Dikkat: "Tespit edebiliriz" ifadesi bir varsayımdır. Kanıt standardında değerli olan, tespit iddiasının hangi gözleme dayandığı ve "hangi koşulda başarısız olacağıdır".

İpucu: Haritalama derinliğini seçerken iki uç arasında bilinçli karar ver:

• Derin haritalama daha doğru ve eyleme dönük olur ama zaman/mühendislik maliyeti yüksektir.
• Hızlı gap taraması pratik olur ama yanlış eşleme ve FP maliyeti artırabilir.\ Aynı problemi çözmenin birden fazla yolu varken, seçim kriterin "zaman baskısı + risk iştahı + mevcut görünürlük" olmalı.

3) TTP tabanlı threat hunting: hipotezi "bulgu üretme makinesi"ne çevirmek

IOC tabanlı avcılık ("şu IP var mı?") çoğunlukla reaktiftir. TTP tabanlı avcılık ise proaktiftir ve hipotez ile başlar. İleri seviyede hipotez; varsayım, beklenen artefakt, veri kaynağı ve doğrulama kriterini birlikte taşır.

3.1. Hipotezin dört bileşeni

• Varsayım: Tehdit profiline dayalı davranış iddiası
• Beklenen artefakt: Bu davranış gerçekleşseydi ne tür izler oluşurdu?
• Veri kaynağı: Bu izi hangi telemetri taşıyabilir?
• Doğrulama kriteri: Ne görürsem hipotez güçlenir; ne görürsem zayıflar?

Örnek: "Kimlik bilgisi odaklı bir davranış ailesi" hipotezinde, beklenen artefaktlar sadece tek bir log türü değildir; olay dizisi, zaman uyumu ve yan izler (ör. süreç etkileşimi, oturum anomalisi, ardışık erişim kalıpları) birlikte değerlendirilir. Artefaktların yokluğu, hipotezi otomatik çürütmeyebilir; görünürlük eksikliği ihtimali ayrıca yazılmalıdır.

3.2. Yöntem seçimi ve sınırlar: davranış avcılığı pahalıdır

Davranış odaklı avcılık, IOC avcılığına göre daha yüksek maliyetlidir: mühendislik eforu, veri hacmi, gürültü (noise) ve alarm yorgunluğu (alert fatigue) riski artar. Bu nedenle "her TTP için av yapılmaz"; yüksek riskli veya tespit kuralı yazılması zor davranışlar önceliklendirilir.

Bu çıktılar modül 9'da detection content lifecycle'a bağlanır: hipotez, sürdürülebilir kural/kapsam tasarımına dönüşmedikçe operasyonel değer üretmez.

4) Diamond Model: olaydan kampanyaya geçerken boşlukları doğru okumak

Diamond Model, bir olayı dört unsurla bağlar: adversary, infrastructure, capability, victim. Modül 5'teki pivoting yaklaşımı burada çerçeveye oturur: altyapı ↔ yetenek, kurban ↔ altyapı gibi ilişkiler "gözleme dayalı bağlar" olarak ele alınır.

4.1. İlişkiler kanıt ister; varsayım görünür olmalıdır

Diamond Model'de çizdiğin her ilişki (ör. capability ↔ infrastructure) bir kanıta dayanmalıdır. Varsayımlar "kesinlik" gibi yazıldığında, model kampanya analizi yerine hikâye üretmeye başlar.

Örnek: İki ayrı olayda aynı capability'ye benzeyen bir davranış kalıbı ve benzer altyapı izi görülebilir; ancak kurban profili tamamen uyumsuzsa (sektör/varlık tipi/erişim yüzeyi), analist "paylaşımlı altyapı" veya "hedef şaşırtma" gibi alternatif hipotezleri açıkça not edip confidence'ı düşürmelidir.

4.2. Boşluklar: veri eksikliği mi, yanlış hipotez mi?

Boşluk her zaman "bilinmiyor" değildir; bazen yanlış yere baktığını söyler. Bu yüzden boşluğu sınıflandır:

• Telemetri yetersizliği (görünürlük boşluğu)
• Kaynakların çelişkisi (fusion boşluğu)
• Hipotezin zayıflaması (alternatif açıklama güçleniyor)

Burada belirsizlik dili, raporun zayıflığı değil; denetlenebilirliğidir.

5) Pyramid of Pain: savunma etkisini yükseltmek ama bedelini bilmek

Pyramid of Pain, savunmanın saldırgana "ne kadar maliyet" çıkardığını anlatır. Hash/IP/domain gibi alt katmanlar hızlı değiştirilebilir; araçlar ve TTP'ler daha kalıcıdır ve saldırgan için değiştirmesi pahalıdır. Bu yüzden stratejik hedef, mümkün olduğunca davranış katmanına yükselmektir.

Örnek: Sadece hash'e odaklı tespit, saldırganın küçük bir değişiklikle kaçmasına izin verebilir; davranışsal desenin yakalanması ise adaptasyon maliyetini artırır. Ancak davranış katmanı daha fazla telemetri ve daha dikkatli yanlış pozitif yönetimi ister.

Dikkat: "Piramidin tepesine çıkalım" hedefi, her zaman en doğru operasyonel seçim değildir. Üst katman yaklaşımı dayanıklıdır ama pahalıdır; düşük olgunlukta veya düşük görünürlükte agresif davranış kuralları, gürültü ve yanlış alarmla ekibi kilitleyebilir.

6) Kill Chain perspektifi: safha farkındalığı, FP maliyeti ve karşı önlem mantığı

Kill Chain, saldırıyı bir süreç olarak ele alır (recon → weaponization → delivery → exploitation → installation → C2 → actions on objectives). Bu çerçeve, "nerede yakaladım?" sorusunu görünür kılar.

• Zincirin başlarında (ör. recon/delivery) bazı sinyallerin FP oranı yüksek olabilir: her anomali saldırı değildir.
• Zincirin sonlarına doğru (ör. C2 / hedefe yönelik aksiyonlar) FP düşebilir; ancak kaçırma maliyeti artar.

Buradaki yöntem seçimi, "en erken yakala" refleksiyle değil; iş sürekliliği, FP maliyeti ve müdahale kapasitesi ile yapılır.

Örnek: Erken safhalarda agresif tespit, yüksek FP ile operasyonu yorabilir; daha geç safhalarda tespit ise düşük FP sağlar ama risk artar. Doğru karar, tek bir "en iyi" nokta değil; kurumun risk iştahına ve kritik süreçlerine göre değişen bir dengedir.

7) D3FEND: savunma dilini standardize etmek ve COA üretimini netleştirmek

ATT&CK "saldırgan ne yapıyor?" sorusunu cevaplar; D3FEND, "savunmacı ne tür kabiliyetlerle karşılar?" sorusuna daha standart bir dil sunar. CTI açısından değer, rapordaki önerilerin (recommendations) "genel temenni" olmaktan çıkıp, ölçülebilir savunma kabiliyeti diline yaklaşmasıdır.

Bu bölüm, COA (Course of Action) mantığını güçlendirir: bulgu → savunma kabiliyeti → uygulanabilirlik → operasyonel maliyet → beklenen etki.

İpucu: D3FEND'i her rapora zorla eklemek yerine, iki durumda özellikle tercih et:
1. Kurum içinde farklı ekiplerin "öneri"yi farklı anladığı ortamlarda (standart dil ihtiyacı).
2. Gap analysis çıktısını kontrol haritalamasına bağlayacağın ortamlarda (ölçülebilir kabiliyet ihtiyacı).\ Standartlaşma faydalıdır; ama öğrenme ve bakım maliyeti de gerçek bir bedeldir.

8) Intel Fusion: tehdit bağlamını iş bağlamına çevirmek

Intel fusion, dış tehdit verisini kurumun iç gerçekleriyle birleştirir: varlık kritiklikleri, iş süreçleri, maruziyet yüzeyi ve operasyonel kapasite... Buradaki hedef, teknik doğruluğu bozmadan iş dilinde risk anlatısı kurmaktır.

8.1. Crown Jewels ve tehdit senaryosu

"Crown jewels" kurumun olmazsa olmaz varlıkları ve süreçleridir. Fusion, her TTP'nin etkisini "kurumumda nerede can yakar?" sorusuyla eşler.

Örnek: "Aktif olarak sömürülen bir zafiyet" haberi tek başına panik nedeni değildir. Fusion bakışı, "bizde var mı, nerede var, ne kadar maruz, hangi süreçleri etkiler, hangi koşulda risk kritikleşir?" sorularıyla senaryoyu kurar ve belirsizlikleri görünür kılar.

8.2. Kaynak ağırlığı ve çelişki çözümü

Fusion'da en büyük tuzak, "çok kaynak = kesin" yanılgısıdır. Kaynağın "kim olduğu" kadar "nasıl bildiği" önemlidir:

• İddia ölçülebilir mi, yoksa yorum mu?
• Kurum içi görünürlük iddiayı test edebilecek kadar güçlü mü?
• Zaman uyumu ve bağlam tutarlılığı var mı?
• Çelişki varsa hangi kanıt daha güçlü?

Bu noktada görselleştirmeler (grafikler/ilişki ağları) ikna edici görünebilir; ancak chart bias riskine dikkat edilir: görsel yakınlık, gerçek ilişki kanıtı değildir.

8.3. Fusion çıktıları: TTP profili, öncelik ve operasyonel aktarım

Fusion çıktısı "teknik liste" değil, karar üreten paket olmalıdır:

• TTP profili: Hangi davranış aileleri öne çıkıyor, hangi kanıtla?
• Önceliklendirme: Kurumda hangi davranışlar daha yüksek risk/etki taşıyor?
• Aksiyon sınıfları: Kural/av/izleme/iyileştirme gibi hangi COA'lar anlamlı?
• Belirsizlik yönetimi: Hangi koşulda karar değişir?

Bu hat, modül 9'da hunting ve detection lifecycle'a, modül 8'de kampanya/kümelenme ve attribution işlerine taşınabilir çıktılar üretir.

9) Zafiyet önceliklendirme: CVSS'in ötesi (tehdit + maruziyet + iş etkisi)

Standart zafiyet yönetimi sadece CVSS'e bakarsa, "teknik ciddiyet"i görür ama "gerçek risk"i kaçırabilir. CTI destekli önceliklendirme üç boyutu birlikte düşünür:

• Severity (CVSS): Teknik ciddiyet
• Threat (tehdit): Sahada aktif istismar sinyali, kampanya ilgisi, exploitability göstergeleri
• Exposure & Impact (maruziyet ve iş etkisi): İnternete açıklık, erişim yüzeyi, veri/süreç kritiklikleri

Bu birleşim, aksiyon sınıflarına dönüşür:

• Patch now: Kritik varlık + yüksek maruziyet + aktif tehdit sinyali
• Mitigate: Yama gecikiyorsa/uygulanamıyorsa riski düşüren önlemler (mimari/konfigürasyon/izleme)
• Accept/Monitor: Düşük maruziyet veya düşük iş etkisi; izleme ve yeniden değerlendirme

Dikkat: CVSS tek başına kullanıldığında iki uç hata oluşur:

• Kritik olmayan yerde "yangın" çıkarıp gereksiz kesinti üretmek,
• Kritik yerde "normal" deyip risk birikimi oluşturmak.\ Bu yüzden belirsizlik ve veri boşluğu (maruziyetin tam bilinmemesi gibi) raporda açıkça yazılmalıdır.

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• TTP analizi, etiketten önce kanıt standardıdır: gözlem–yorum–iddia ayrımı korunur.
• ATT&CK haritalama, doğru yapıldığında gap analysis ve ölçülebilir savunma iyileştirmesi üretir.
• TTP tabanlı hunting, hipotez–artefakt–veri kaynağı–doğrulama kriteriyle kurulur; maliyet/noise/FP sınırlarıyla yönetilir.
• Diamond Model, olayları kampanya resmine bağlarken boşlukları “veri eksikliği mi, yanlış hipotez mi?” diye ayırmayı zorunlu kılar.
• Pyramid of Pain ve Kill Chain, savunma etkisini ve müdahale zamanının maliyetini düşünmeye zorlar.
• D3FEND ve COA mantığı, önerileri standartlaştırır; ama her durumda eklenmesi gerekmeyen bir maliyet taşır.
• Intel fusion, tehdit bilgisini crown jewels ve iş etkisiyle birleştirerek “teknikten karara” köprü kurar.
• Zafiyet önceliklendirme, CVSS’in ötesinde tehdit + maruziyet + iş etkisiyle gerçek riski yakalar.

MODÜL 7 — Malware İstihbaratı (Intel Analysts için)

Modül Teması

Bu modül, "malware'ı satır satır çözmek" ile "malware'dan istihbarat üretmek" arasındaki çizgiyi netleştirir. CTI analisti için hedef; bir örneği (sample) tamamen deşifre etmek değil, örnekten operasyonel değeri olan sinyalleri (altyapı ipuçları, TTP göstergeleri, kampanya/cluster bağları, sınıflandırma işaretleri) kanıt zinciriyle çıkarıp, belirsizlik ve yöntem seçimi disiplinini koruyarak savunma kararlarına dönüştürmektir. Bu nedenle içerik, "nasıl saldırı yapılır?" tarifine girmez; bunun yerine "hangi sinyal ne kadar güvenilir, nasıl doğrulanır, nasıl raporlanır ve nasıl operasyonelleştirilir?" sorularını merkeze alır.

1) Intel için malware analizi: doğru hedef, doğru sınır

Klasik tersine mühendis "Bu fonksiyon nasıl çalışıyor?" sorusunu büyütür; CTI analisti ise "Bu örnek bize kim, nasıl, nereye sorularında hangi savunma kararını güçlendirecek sinyali veriyor?" sorusunu büyütür. Bu fark, analiz derinliğini değil, çıktının doğasını değiştirir.

• Amaç: "Kodu tamamen çözmek" değil, yeterince çözerek (ya da mevcut analiz çıktısını kullanarak) operasyonel sinyal (izleme/engelleme için aday göstergeler, hunting hipotezleri, ilişki adayları) üretmek.
• Sahiplik ve kalite: CTI çıktısında "bulgu" ile "yorum" ayrımı korunur. Bir gözlem (örnekte görülen bir artefakt) ile ondan çıkarılan iddia (kampanya bağı, altyapı ilişkisi, olası TTP) aynı cümlede erimemelidir.
• Belirsizlik dili: Analiz, "kesinlik yarışı" değildir. Bazı sinyallerin taklit edilebilirliği yüksektir; bu sinyaller ancak başka kanıtlarla güçlendiğinde karar kalitesini artırır.

Dikkat: "Politika/OPSEC uyumu" güvenli çalışmanın şartıdır; ama confidence (güven düzeyi) kanıtın gücüyle ilgilidir. Uyumlu bir ortamda çalışmak, bulgunun doğruluğunu otomatik olarak yükseltmez; sadece riskini azaltır.

İpucu: CTI analisti olarak, malware/IR ekibinden alacağın üç net bilgi çıktının kalitesini dramatik artırır:
— Bu sonuç doğrudan gözlem mi, yoksa yorum mu?
— Hangi artefaktlar tekrar üretilebilir ve hangi koşullarda değişir?
— Bu yorum hangi yeni kanıt gelirse geri çekilir / revize edilir?

Örnek: Bir olay özetinde "C2 aday alan adı" geçtiğini varsay. Bu bilgiyi "kesin C2" diye paketlemek yerine, "aday altyapı sinyali" olarak raporlayıp; hangi telemetriyle (zaman uyumu, ağ gözlemi, başka örneklerle yakınsama) güçleneceğini yazmak, hem güvenilirliği artırır hem de yanlış bloklama riskini azaltır.

2) Statik sinyaller: hızlı değer, yüksek yanıltma payı

Statik inceleme (dosyayı "çalıştırmadan" elde edilen bilgiler) CTI açısından çekicidir: hızlıdır, bazı durumlarda daha güvenlidir. Ancak statik yüzey, saldırganın analisti yanıltmak için "dekor" bıraktığı yerdir. Bu yüzden statik sinyaller, kanıt değerine göre sınıflanmalı ve karşı kanıt arama refleksiyle ele alınmalıdır.

2.1. String/pattern ve "kanıt eşiği"

String'ler; URL parçaları, dosya yolları, hata mesajları, konfig anahtarları, user-agent kalıpları gibi ipuçları taşır. Fakat iki soru sorulmadan "istihbarat" olamaz:

• Bu artefakt gerçekten yürütülen akışın parçası mı, yoksa decoy/dead code olabilir mi?
• Bu artefakt özgün bir iz mi, yoksa boilerplate/commodity olabilir mi?

Örnek: Bir örnekte "/update/check" gibi sıradan bir path parçası görmek tek başına anlamlı değildir. Ancak aynı örnekte nadir bir konfig anahtarı düzeni, tutarlı bir iletişim ritmi ve zaman uyumlu altyapı sinyalleriyle birlikteyse "sinyal seti" güçlenir.

2.2. PDB yolları: kıymetli ama yanlış okunmaya açık bir parmak izi

Bazı örneklerde PDB (debug sembol) yolu gibi geliştirme ortamından kalma izler görülebilir. Bu, aktör takibinde (modül 8) değerli bir ipucu olabilir; çünkü proje isimleri, klasör yapıları veya alışkanlıklar hakkında bağlam sağlar.

Dikkat: PDB yolu görmek, tek başına "kimlik" kanıtı değildir. Bu tür izler yanlış yönlendirme için bilerek bırakılmış olabilir. Değer kazanması, diğer sinyallerle corroboration (bağımsız doğrulama/ yakınsama) bulmasına bağlıdır.

2.3. Derleme zamanı (compile time) ve zaman tutarlılığı

Derleme zamanı bazen çalışma saatleri veya zaman dilimi hakkında ipucu veriyor gibi yorumlanır; fakat metadata manipüle edilebilir (timestomping). Bu nedenle doğru yaklaşım, derleme zamanını tutarlılık kontrolü ile ele almaktır: kod/bağımlılık işaretleri ve kampanya zaman çizgisiyle uyumlu mu?

Örnek: Dosya zamanı çok eski bir yılı işaret ediyor gibi görünürken, örnek "modern" bir bileşene bağımlılık sinyali taşıyorsa, bu durum tarih bilgisinin manipüle edilmiş olabileceğini düşündürür ve güven düzeyi düşürülür.

Imphash ve benzerlik sinyalleri: hızlı kümeleme, dikkatli yorum

Imphash (import tablosu temelli parmak izi) aynı üretici/builder/derleme hattından çıkan örnekleri hızlıca kümelendirmede işe yarayabilir. Ancak "aynı imphash → aynı aktör" gibi doğrudan bir sıçrama yapılmaz; çünkü ortak kütüphane kullanımı, benzer derleme zincirleri veya commodity bileşenler benzer izler üretebilir.

İpucu: Statik sinyali raporlarken "sinyal kartı" gibi düşün:
Ne gördüm? (gözlem)
Ne iddia ediyorum? (yorum)
Neye dayanıyorum? (kanıt)
Hangi karşı kanıt bunu çürütür?
Hangi koşulda fikrim değişir?\ Bu format, modül 3'teki tradecraft ve modül 9'daki operasyonelleştirme hattıyla doğal uyum sağlar.

3) Konfigürasyon ve altyapı sinyali: "kutsal kase" ama tek örnek tuzağı var

Malware istihbaratında en yüksek değer üreten alanlardan biri, örneğin gömülü konfigürasyonundan çıkan altyapı sinyalidir. Çünkü bu sinyaller modül 5'te pivoting için "seed", modül 8'de kampanya/cluster için bağ dokusu, modül 9'da ise operasyonel içeriğin girdisi olur.

3.1. Ne aranır?

Konfigürasyon ve altyapı sinyali ararken CTI'nin "işe yarayan" alanları genellikle şunlardır:

• Birincil/yedek iletişim uçları (domain/IP adayları, bazen birden çok seçenek)
• Protokol/iletişim biçimine dair ayırt edici öğeler (ör. sabit header kalıpları, user-agent benzeri tanımlayıcı dizgiler)
• Kampanya/bot grup kimliği gibi "operasyon içi" sınıflandırma alanları
• Sürüm ipuçları ve konfig şemasındaki değişimler (drift takibi için)

3.2. Nasıl doğrulanır?

Konfig'den çıkan her alan otomatik olarak "C2 budur" anlamına gelmez. Yanlış yorum, yanlış bloklama ve iş sürekliliği riski doğurur. Bu yüzden:

• Zaman uyumu aranır: sinyal, olay penceresiyle uyumlu mu?
• Bağımsız sinyaller aranır: aynı altyapı izi telemetride görülüyor mu, başka örneklerle yakınsıyor mu?
• Alternatif açıklama yazılır: bu alan telemetri/diagnostic endpoint, test sunucusu veya decoy olabilir mi?

Örnek: Konfig'de "example.com" benzeri bir alan görmek tek başına yeterli değildir. Eğer aynı zaman aralığında kurum telemetrisinde bu alanla ilişkili tutarlı bir iletişim paterni gözlenmiyorsa, "aday altyapı" olarak kalır.

Dikkat: "Sandbox raporu bunu gösterdi" ifadesi, tek başına kanıt standardı değildir. Otomatik raporlar bazen yalnızca görünen ilk davranışı yansıtır; CTI raporu ise sinyali "mutlak" değil "kanıtlı" kılmakla yükümlüdür.

3.3. Statik vs dinamik gözlem: yöntem seçimi ve sınır

• Statik yaklaşım çoğu senaryoda daha güvenli ve tekrarlanabilir bir başlangıç sağlar; ancak eksik kalabilir.
• Dinamik gözlem zengin sinyal sunabilir; fakat OPSEC/etik/politika çerçevesi ve yanlış yorum riski daha yüksektir.

Burada "doğru yöntem" evrensel değil; karar, risk, zaman baskısı, mevcut kanıt ve kurumsal politika ile belirlenir. Önemli olan; seçtiğin yöntemin sınırını raporda açıkça söylemektir.

4) YARA: tespit dili değil, içerik yönetişimi problemi

CTI bağlamında YARA'yı yalnız "kural yazma" olarak görmek, üretim gerçeklerini ıskalar. İleri seviye yaklaşım; kuralın doğruluğunu, performansını, FP/FN dengesini ve yaşam döngüsünü birlikte düşünür.

4.1. Performans/ölçek ve FP-FN dengesi

• Çok genel kurallar geniş kapsama sunar ama FP üretir; analist yorgunluğu, kural kirliliği ve güven kaybı doğurur.
• Çok dar kurallar FP'yi azaltır ama varyant kaçırabilir; sahte güven üretir.

Bu yüzden kuralın "iyi"liği, kullanım amacına bağlıdır: triage için geniş, üretim tespiti için daha kontrollü, avcılık için farklı bir denge gerekebilir.

4.2. Yaşam döngüsü: sürümleme, test, geri çekme

YARA içeriği de "canlıdır": tehdit değişir, kural yaşlanır. Bu nedenle:

• Sürümleme ve değişiklik kaydı tutulur (denetlenebilirlik)
• "Temiz dosya kümesi" benzeri test disiplinleriyle FP riski düzenli ölçülür
• Üretime yayılım kademeli ve geri çekilebilir tasarlanır (modül 9'un content lifecycle yaklaşımı)

İpucu: Kural çıktısını raporlarken "eşleşme"yi nihai hüküm gibi yazma. Eşleşme bir işarettir; karar, başka kanıtlarla doğrulanmadıkça "kesin" değildir. Bu dil disiplini, hem teknik doğruluğu hem de paydaş güvenini korur.

5) Code reuse, benzerlik ve attribution: güçlü sinyal, tehlikeli kesinlik

Code reuse analizinde en sık hata, benzerliği "aynı aktör"e sıçratmaktır. Oysa benzerlik; paylaşım, sızıntı, satın alma, taklit veya commodity ekosistem nedeniyle ortaya çıkabilir. Bu yüzden temel ilke nettir: reuse ≠ aynı aktör.

5.1. Reuse sinyallerini doğru ağırlıklandırma

Reuse bulgusu tek başına "kampanya bağlayan ana kanıt" yapılmaz. Değer kazanması için:

• Altyapı örüntüsü (modül 5) ile yakınsama
• TTP profili ve davranış seti (modül 6) ile uyum
• Zaman çizgisi ve victimology (modül 8) ile tutarlılık\ gibi bağımsız sinyallerle güçlenmesi gerekir.

Örnek: İki olayda benzer bir şifreleme rutini görülüyor olabilir. Eğer birinde altyapı ve TTP de uyumlu, diğerinde uyumsuzsa; birincide bağ güçlenir, ikincide "sınırlı sinyal" olarak kalır. Aynı bulgudan iki farklı sonuç çıkarmak, çelişki değil, kanıt standardının gereğidir.

5.2. Benzerlik araçları ve "hızlı kümeler"

Imphash veya fuzzy hashing benzeri yaklaşımlar (benzerlik parmak izleri) hızlı kümeler üretmede işe yarar; fakat bu kümeler "kanıtın son hali" değil, analizin başlangıç noktasıdır. Kümeyi büyütmek için eşik gerekçesi ve karşı kanıt arama disiplini şarttır.

Dikkat: Sızdırılmış kaynak kodu veya yaygın commodity bileşenler, farklı gruplarda benzer sinyaller üretebilir. Bu durumda doğru rapor dili "olası yakınsama"dır; "kesin attribution" değildir.

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• Malware analizinde CTI’nin hedefi “kod çözmek” değil, karar destekleyen sinyal üretmektir.
• Statik artefaktlar hızlı değer sağlar; fakat yanıltma/decoy/anti-forensics riski nedeniyle karşı kanıt arama refleksi şarttır.
• PDB yolu, imphash ve benzerlik sinyalleri güçlü ipuçlarıdır; tek başına kimlik/attribution sonucu üretmez.
• Konfigürasyon ve altyapı sinyali yüksek değer taşır; ancak tek örnekten genelleme ve “mutlak C2” dili kritik hatalara yol açar.
• YARA “kural yazma”dan öte, performans + yaşam döngüsü + yönetişim işidir; eşleşme “işaret”tir, hüküm değil.
• Code reuse değerlidir ama tehlikelidir: reuse ≠ aynı aktör; yakınsama ve belirsizlik dili raporun omurgasıdır.

MODÜL 8 — Kampanya Analizi, Kümeleme, Actor Tracking ve Attribution

Modül Teması

CTI'ın "büyük resim" tarafı, tekil sinyalleri (TTP parçaları, altyapı izleri, zaman uyumu, hedef profili vb.) bir araya getirip operasyonel bir mantık çıkarmayı gerektirir. Bu modül, olayları bir "liste" gibi değil, zaman çizelgesi üzerinde gelişen bir kampanya olarak okumayı; benzerlikleri rastgele değil gerekçeli eşiklerle kümeyi büyütüp bölmeyi; gerektiğinde de attribution'ı olasılıksal, kanıt-temelli ve sınırlarının farkında bir dille kurmayı ele alır. Teknik analizin stratejik analize dönüştüğü bu eşikte amaç; en iddialı cümleyi yazmak değil, denetlenebilir ve karar destekleyen bir kampanya analizi üretmektir.

1) Kavram hiyerarşisi ve analitik kesinlik seviyeleri

Analistlerin en sık yaptığı hata, benzerlik gördüğü her şeyi aynı kavramla etiketlemek ve kavramları birbirinin yerine kullanmaktır. Oysa bu kavramlar farklı kesinlik seviyeleri taşır; "aynı kelimeyi farklı anlamda" kullanmak, ekip içinde yanlış anlaşılmalara ve yanlış aksiyonlara yol açar.

1.1. Cluster (Küme): benzerlik kapsı, niyet ve kimlik değil

Cluster, teknik benzerlik gösteren olayları aynı sepete koyan analitik bir kaptır. Bu aşamada "niyet" veya "kimlik" iddiası sınırlıdır; cluster, esasen hipotez yönetimi aracıdır.

Örnek: Aynı ay içinde, farklı kurumlarda görülen beş olayın hepsinde benzer bir barındırma paterni ve benzer bir TTP alt kümesi var. Bu tabloyu "Cluster-2026-01" olarak takip etmek; hangi ek kanıt gelirse kümeyi daraltacağınızı ya da intrusion set seviyesine yükselteceğinizi şeffaf biçimde yazmayı kolaylaştırır.

Dikkat: Erken aşamada bir cluster'ı "aktör" diye ilan etmek analitik bir kumardır. Zayıf kriterlerle iki farklı grubu yanlışlıkla tek bir "süper aktör" gibi raporlayabilirsiniz.

1.2. Campaign (Kampanya): zaman + amaç/ hedefleme + operasyon ritmi

Campaign, belirli bir zaman diliminde, ortak bir hedefleme mantığıyla yürütülen koordineli faaliyetler setidir. Campaign'i "IOC listesi" sanmak en tipik hatadır; kampanya çoğu zaman zaman uyumu, dalga yapısı, operasyon ritmi ve hedef profili ile görünür olur.

Örnek: İki haftalık bir periyotta, belirli bir sektör grubuna yönelik benzer sosyal mühendislik temaları görülüyor; altyapı izleri kısmen değişse bile ritim ve hedefleme tutarlı. Bu, campaign hipotezini güçlendiren bir çerçevedir — ancak yine de kanıt zinciri gerekir.

1.3. Intrusion Set (Sızma Kümesi): kalıcılığı olan operasyonel varlık

Intrusion set, birden fazla campaign yürütmüş olabilecek, ortak TTP ve altyapı alışkanlıklarıyla tanımlanan, zaman içinde devamlılık sergileyen operasyonel bir varlıktır. Buradaki kritik nüans şudur: "stabil" demek "değişmez" demek değildir; aktörler TTP değiştirir, altyapı kiralar, araç setini evrimleştirir.

İpucu: Intrusion set seviyesinde yazarken "bu aktör hep böyle yapar" gibi mutlak cümleler yerine, drift ihtimalini baştan kabul eden bir dil kurun: "Şu dönemde şu örüntü baskın; şu tür sinyaller gelirse model güncellenir."

1.4. Threat Actor (Tehdit Aktörü): analitik modelin ötesindeki "fail" iddiası

Threat actor, intrusion set'in arkasındaki gerçek kişi/grup/devlet gibi fail seviyesidir. Bu seviye, yüksek maliyetli ve yüksek riskli bir iddia taşır; çoğu CTI çıktısında pratik hedef, "faili isimlendirmek" değil, operasyonel risk ve savunma önceliği üretmektir.

2) Kampanya analizi: olaydan operasyonel hikâyeye

Kampanya analizi, tekil sinyalleri yan yana dizmekten fazlasıdır. İyi bir kampanya anlatımı üç şeyi aynı anda başarır:

1. 1. "Ne oldu?"yu zaman çizelgesiyle tutarlı kurar,
2. 2. "Neden böyle düşünüyoruz?"u kanıt zinciriyle gösterir,
3. 3. "Ne kadar eminiz ve hangi şartlarda fikrimiz değişir?"i açıkça yazar.

2.1. Zaman çizelgesi: sadece kronoloji değil, tutarlılık testi

Zaman çizelgesi, kampanyanın omurgasıdır; aynı zamanda bir tutarlılık testidir. Tutarsızlıklar her zaman "yanlış" değildir ama mutlaka açıklama ister: veri kaynağı gecikmesi mi var, telemetri boşluğu mu var, yoksa gerçekten farklı bir operasyon dalgası mı?

Örnek: Bir olayda ilk işaret "Pazartesi 09:10" görünürken, diğerinde "Pazartesi 02:30" görünüyor. Bu fark, iki ayrı aktör ihtimali kadar, log gecikmesi veya farklı saat dilimi standardizasyonu (normalize edilmemiş zaman) gibi masum nedenlere de işaret edebilir.

Dikkat: "Aynı hafta oldu" benzerliği, "aynı aktör" kanıtı değildir. Global bir olay (ör. geniş etki alanlı bir zafiyetin duyurulması) saldırıların aynı döneme yığılmasına yol açabilir. Bu, korelasyon-nedensellik karışıklığını tetikler.

2.2. Kanıt zinciri: gözlem-yorum ayrımı ve izlenebilirlik

Kampanya anlatımında en kritik hijyen, gözlem ile yorumu ayırmaktır. Gözlem: "Şu sinyal görüldü." Yorum: "Bu sinyal şunu düşündürüyor." İkisini ayırmak, hem denetim hem de ekip içi güven için şarttır.

Örnek:
* Gözlem: "example.net alan adının sertifika paterni iki olayda benzer."
* Yorum: "Bu benzerlik, ortak altyapı yönetimi ihtimalini artırır; ancak paylaşımlı sertifika otomasyonu olasılığı alternatif açıklama olarak kalır."

2.3. Kampanya sınırları: ne zaman tek kampanya, ne zaman iki dalga?

Kampanyayı tek bir şemsiye altında toplamak bazen gereksiz genelleme üretir. Burada yöntem seçimi devreye girer: kampanyayı dar tutmak doğruluğu artırır ama "büyük resmi" kaçırabilir; geniş tutmak resim verir ama yanlış ilişkilendirme riskini büyütür.

İpucu: Kampanya sınırı çizerken şu soruyu test edin: "Bu parçaları ayırırsam ne kaybederim, birleştirirsem hangi yanlış aksiyonu tetikleyebilirim?" Yüksek maliyetli aksiyon riski varsa, eşiklerinizi yükseltin ve belirsizlik dilinizi güçlendirin.

3) Kümeleme (Clustering): sinyal ağırlıkları, eşikler ve hata modları

Kümeleme, noktaları birleştirme sanatıdır; ama her nokta birleşmez. İleri seviyede fark yaratan şey, "benziyor" hissi değil, hangi sinyalin hangi koşulda ne kadar ayırt edici olduğu bilgisidir.

3.1. Kümelemeyi besleyen sinyal aileleri

Kampanya/cluster kurarken tipik sinyaller:

• Altyapı örüntüsü: domain-IP-sertifika-DNS/NS-barındırma ilişkileri (modül 5'teki pivoting yaklaşımı burada doğrudan işe yarar).
• Benzersiz TTP parçaları: çok spesifik davranış imzaları; ancak telemetri boşluğu ve haritalama hataları (modül 6) değerlendirilmeli.
• Zaman uyumu (temporal): operasyon ritmi; manipüle edilebilir veya fırsatçı dalgalarla karışabilir.
• Victimology: hedeflenen sektör/coğrafya/varlık profili; çoğu zaman destekleyici bağlamdır, tek başına kanıt değildir.
• Malware sinyalleri ve reuse: modül 7 perspektifi geçerlidir; "reuse" değerlidir ama ekosistem/commodity etkisi nedeniyle tehlikelidir.

3.2. Eşik belirleme: bağımsız boyutlarda kesişim

Güçlü bir kümeleme, ideal olarak iki değil üç bağımsız boyutta kesişim arar. "Aynı aracı kullanıyorlar" çoğu zaman yetersizdir; çünkü bazı araçlar/çerçeveler herkesin erişebildiği commodity ekosistemin parçasıdır.

Örnek:
* Zayıf: "İki olayda da yaygın bir uzaktan erişim aracı var."
* Daha güçlü: "Aynı aracın benzer konfigürasyon izleri + benzer altyapı yönetimi paterni + operasyon ritmi kesişiyor."

Dikkat: Hash, dosya adı, basit string gibi artefaktlar kolay değiştirilebilir. Bu tür sinyaller tek başına yüksek ağırlık almamalı; "taklit maliyeti" düşük olduğu için deception'a açıktır.

3.3. Minimum kanıt paketi: cluster gerekçesini denetlenebilir yazmak

Kümelemeyi "benzerlik var" diyerek bırakmak yerine, gerekçeyi küçük ama güçlü bir paket olarak yazmak kaliteyi artırır:

• Ortak sinyaller neler ve her birinin taklit edilebilirlik riski nedir?
• Zaman uyumu ne kadar sağlam; alternatif açıklaması var mı?
• Bu kümeyi büyütmek için hangi yeni veri eşiği yükseltir?
• Hangi yeni veri gelirse kümeyi bölmek gerekir?

Örnek: Üç olay düşünün. İlk ikisi hem altyapı hem TTP hem de zaman penceresinde yakınsıyor; üçüncüde yalnızca TTP benzerliği var. Üçüncüyü "zayıf bağ" olarak ayrı tutmak, over-clustering riskini azaltır.

3.4. Over-clustering ve under-clustering: iki uç hata

• Over-clustering: zayıf ilişkileri güçlüymüş gibi birleştirmek. Sonuç: yanlış öncelik, yanlış av hipotezleri, rapor güven kaybı.
• Under-clustering: bağlantılı olayları ayrı tutup büyük resmi kaçırmak. Sonuç: tekrar eden iş, parçalı savunma, trend kaybı.

Bu ikisi arasında denge, maliyet ve operasyonel yük ile kurulur. "Yanlış birleştirirsem" çıkacak operasyonel zarar yüksekse eşiği yükseltmek gerekir; "yanlış ayırırsam" dalgayı kaçırma riski yüksekse kontrollü şekilde eşiği düşürmek mümkündür — ama belirsizlik dili ve doğrulama kapıları güçlenmelidir.

4) Attribution: pahalı soru, olasılıksal dil ve deception dayanıklılığı

"Bunu kim yaptı?" sorusu CTI'ın en pahalı ve en riskli sorusudur. İleri seviyede attribution, tek bir kanıtla sonuç ilan etmek değil; hipotezleri test etmek, taklit maliyetini tartmak ve confidence dilini disiplinli kullanmaktır.

4.1. Olasılıksal doğa ve confidence dili

Attribution çoğu durumda %100 kesinlik taşımaz. Bu nedenle rapor dili "kesin" yerine, gerekçeli güven taşır: hangi kanıtlar, hangi alternatif açıklamalar, hangi şartlarda fikriniz değişir?

Örnek: "Bu intrusion set ile ilişkilendirilmesi daha olasıdır; çünkü üç bağımsız sinyal yakınsıyor. Ancak commodity ekosistem nedeniyle X sinyali düşük ağırlıktadır. Yeni kanıt olarak Y görülürse değerlendirme güncellenecektir."

4.2. False flag ve deception: "olabilir" demek yetmez, test gerekir

Deception "her şey sahte" değildir; analistin gördüğü yüzeyin hedef alınabileceği gerçeğidir. Burada iki kritik soru vardır:

• Bu kanıtın taklit maliyeti nedir?
• Bu kanıt, alternatif hipotezleri nasıl dışlıyor?

Modül 3'teki alternatif hipotez analizi (ACH mantığı) burada pratik bir emniyet kemeridir: "A hipotezi doğruysa ne görürdüm? B doğruysa ne görürdüm? Şu anki kanıt hangi hipotezle daha uyumlu, hangisini dışlayamıyor?"

Dikkat: "False flag var" ifadesi de kanıt isteyen bir iddiadır. "Yanıltıcı olabilir" riskini yazmak ile "kesin yanıltma yapıldı" demek aynı şey değildir.

4.3. Commodity araçlar ve Living off the Land: imza kıtlığında neye bakılır?

Yaygın kullanılan araçlar, kiralanan altyapı ve "sistemde zaten var olan yönetim araçlarıyla" yürütülen faaliyetler attribution'ı zorlaştırır. Bu durumda odak, aracın adı değil; davranış ve tercih örüntüsü olmalıdır:

• Konfigürasyon/operasyonel tercih izleri (genelleştirilmiş düzeyde),
• Altyapı yönetimi alışkanlıkları,
• Operasyon ritmi,
• Hedefleme seçiciliği,
• Birden fazla kampanyada tekrar eden "ince ama pahalı taklit edilen" örüntüler.

Örnek: Aynı tür commodity çerçeve farklı saldırılarda görülüyor. Aracın kendisi ayırt edici değil; ancak "ne zaman, nasıl bir ritimde, hangi hedef profiline, hangi altyapı paterniyle" kullanıldığı daha ayırt edici hale gelebilir.

5) Aktör profili: motivasyon, davranış imzaları ve genelleme tuzakları

Aktör profili, bir "etiket" değil; savunmaya hizmet eden bir risk anlatımıdır. Teknik sinyallerin yanına "davranış imzası" ve "motivasyon" koymak, gelecekteki muhtemel hareketleri daha iyi çerçeveleyebilir — ama bu katman, kolayca önyargıya dönüşebilir.

5.1. Motivasyon sınıfları: bağlam sağlar, kanıt değildir

Genel motivasyon sınıfları (ör. bilgi toplama odaklı, finansal kazanç odaklı, ideolojik mesaj odaklı) karar vericiler için faydalı olabilir. Ancak bunlar tek başına attribution kanıtı değildir; aktörler zaman içinde motivasyon değiştirebilir, taklit yapabilir veya farklı alt gruplar farklı davranabilir.

5.2. Davranış imzaları: yakınsama ile güçlenir, drift ile değişir

Davranış imzaları; TTP seti, operasyon temposu, tercih edilen erişim yüzeyleri, hedefleme seçiciliği gibi öğelerden oluşur. İleri seviye yaklaşım:

• İmza, tek olayla değil çoklu olay yakınsaması ile güçlenir.
• Drift beklenir. "İmza bozuldu" diye paniklemek yerine, "evrim mi, farklı aktör mü?" sorusu hipotezle test edilir.

İpucu: Profil yazarken iki ayrı cümle disiplini kurun:
* "Gözlenen örüntü ..." (kanıt)
* "Olası açıklama ..." (yorum)\ Bu ayrım, raporu hem daha dürüst hem de daha denetlenebilir yapar.

6) Actor tracking & naming governance: naming chaos'tan kurumsal hafızaya

Sektörde aynı operasyonel varlığın farklı isimlerle anılması, kurum içinde "kim kimdir?" sorusunu büyütür. Bu durum, farklı kaynaklardan gelen istihbaratı birleştirmeyi zorlaştıran bir "Rosetta Stone" problemine dönüşebilir. Çözüm, ad hoc yorum değil; yönetişimtir.

6.1. Actor registry: tek ana kimlik, alias crosswalk ve eşleştirme güveni

Kurum içinde bir actor registry tutmak, şu ihtiyaçları karşılar:

• Aynı varlığın farklı raporlarda farklı isimle geçmesini engeller,
• Alias'ları çapraz referanslayarak fusion süreçlerini güçlendirir,
• Eşleştirmelerin "neden"ini (kanıt + confidence) saklar.

Örnek: Kurum içi "Actor-X" etiketi altında bir intrusion set izleniyor. Dış raporlarda farklı adlar geçiyor. Registry'de "Actor-X ↔ (alias listesi)" tutulur; her alias eşleştirmesine kısa bir gerekçe ve confidence eklenir. Yeni kanıt gelirse eşleştirme güncellenir; değişiklik kaydı tutulur.

6.2. Drift yönetimi: statik profil değil, yaşayan belge

Actor tracking "bir kere yazıp bırakılan" profil değildir. Drift; araç, TTP, hedefleme ve altyapı tercihlerinin zamanla değişmesidir. Governance, drift'i fark etmeyi ve "stabil kimlik" yanılsamasına kapılmamayı sağlar.

Dikkat: "Bu grup sadece şunu yapar" varsayımı, savunmayı körleştirir. İzleme kapsamını daraltan mutlak kurallar yerine, drift'i yakalayacak ölçütler ve kalite kapıları kullanın.

6.3. Standart seçimi ve bakım maliyeti: yöntem seçimi + sınırlar

Registry tabanlı yönetişim tutarlılık sağlar; ancak bakım yükü getirir. Ad hoc yaklaşım hızlıdır; ancak tutarsızlık ve yanlış eşleştirme riski taşır. Burada yöntem seçimi "en şık" olana değil, kurumun operasyonel kapasitesine göre yapılır:

• Yoğun raporlama ve çok kaynaklı fusion varsa: registry şart.
• Kısıtlı kaynak varsa: daha hafif ama disiplinli bir şema (tek ana kimlik + zorunlu alias alanı + değişiklik kaydı) bile büyük fark yaratır.

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• Cluster, campaign, intrusion set ve threat actor kavramlarını kesinlik seviyeleriyle ayırıp doğru yerde doğru iddiayı kurabilme.
• Kümelemeyi tek boyutlu benzerliklerle değil, çok boyutlu yakınsama ve taklit maliyeti düşüncesiyle yapabilme.
• Over/under-clustering hata modlarını tanıyıp, eşikleri maliyet ve operasyonel yük ile yönetebilme.
• Attribution’ı “kesin sonuç” değil, hipotez testi + kanıt zinciri + confidence dili olarak paketleyebilme.
• Jeopolitik bağlamı kanıt yerine koymadan, analizi destekleyen bir katman olarak doğru kullanabilme.
• Actor registry, alias crosswalk, drift ve naming governance ile kurumsal hafızayı güçlendirip rapor tutarlılığını sürdürebilme.

MODÜL 9 — CTI Operasyonelleştirme: Threat Hunting ve Detection Content Lifecycle

Modül Teması

Bu modül, CTI çıktılarının "okunup kenara kaldırılan raporlar" olmaktan çıkıp, tehdit avı (threat hunting) ve tespit içeriği (detection content) üretimini besleyen sürdürülebilir bir üretim hattına dönüşmesini ele alır. İleri seviye olgunluk; "daha çok kural" yazmaktan çok, doğru sinyali doğru yöntemle doğrulayıp kanıt standardında paketlemek, ardından bu içeriği drift/noise baskısı altında bile yönetilebilir bir yaşam döngüsüyle yaşatabilmektir.

Bu dönüşümde asıl değer, bir cümlenin teknik kurala çevrilmesi değil; kaynak-iddia-kanıt ayrımını koruyarak, yanlışlanabilir hipotezlerle doğrulama yapmak; belirsizliği doğru ifade etmek; maliyet/operasyonel yük/etik sınırları gözeterek yöntem seçmektir.

1) CTI → Detection Engineering hattı: sinyalden "tüketilebilir tespit"e

CTI analisti çoğu zaman "ne olduğuna" dair bağlam üretir; detection tarafı ise bunu "nasıl yakalarız?" sorusuna çevirir. Bu geçiş, basit bir çeviri değil, risk yönetimi sürecidir: yanlış sinyali hızlıca üretime taşımak, kurumu "korumak" yerine operasyonu boğabilir.

1.1. Kaynak-iddia-kanıt ayrımı: operasyonelleştirmenin hijyeni

• Kaynak: Sinyalin geldiği yer (dahili telemetri, vaka bulgusu, rapor, paylaşılan feed vb.)
• İddia (claim): "Bu davranış şu tehdit sınıfıyla ilişkilidir" gibi yorum/çıkarım
• Kanıt: Denetlenebilir, izlenebilir ve mümkünse aynı koşullarda yeniden değerlendirilebilir dayanak

İleri seviye hata, iddianın kanıt gibi muamele görmesiyle başlar. Bir raporda geçmesi tek başına kanıt standardı sağlamaz; üretime girecek her içerik, "hangi koşulda yanlış olabilir?" sorusunu da taşır.

Dikkat: "Şu kaynak böyle diyor" çoğu zaman bir iddiadır. Kanıta dönüşmesi için en azından:
(i) bağımsız doğrulama sinyali, (ii) zaman uyumu, (iii) benign alternatif açıklamaların ele alınması gerekir.

1.2. Aynı sinyal, farklı tüketici: SOC, hunting, detection engineering

Aynı CTI sinyali üç farklı ekibe taşınırken aynı biçimde sunulursa sürtünme artar:

• SOC için: Triage'ı hızlandıran bağlam, güven seviyesi, beklenen artefaktlar, yanlış olabileceği durumlar
• Threat hunting için: Hipotez, hangi veri kaynaklarının gerekli olduğu, beklenen anomaliler, doğrulama/yanlışlama kriteri
• Detection engineering için: Davranış mantığı, gerekli veri alanları, test yaklaşımı, izleme metrikleri, TTL/rollback gibi yaşam döngüsü notları

İpucu: CTI'dan detection backlog'a geçerken her maddeyi tek cümlede "ürün tanımı"na çevirin: "Hangi davranışı, hangi veri kaynaklarıyla, hangi risk/etki için izleyeceğiz; yanlış olabileceği koşullar neler?" Bu cümle net değilse, kuralın kaderi de net olmaz.

1.3. Hassasiyet-özgüllük dengesi: "daha çok yakala" ile "daha az gürültü" arasında

Tespit içeriği tasarlarken iki uç arasında seçim yapılır:

• Yüksek hassasiyet (sensitivity): Daha fazla olası vakayı yakalar; FP/noise riski artabilir
• Yüksek özgüllük (specificity): Gürültüyü azaltır; kaçırma (false negative) riski artabilir

Buradaki doğru cevap evrensel değildir. Seçimi belirleyenler: tehditin ciddiyeti, ortamın telemetri kalitesi, SOC kapasitesi, otomatik aksiyonun iş etkisi ve kurumun risk toleransıdır.

1.4. Watchlist / blocklist / enrichment: IOC'nin "doğru kullanım yüzeyi"

IOC'ler çoğu zaman üç yüzeyde operasyonelleştirilir:

• Watchlist: İzleme ve korelasyon için; erken işaretler üretir
• Blocklist: İş sürekliliği maliyeti yüksek olabileceği için en "sert" yüzeydir
• Enrichment: Alarm/olay bağlamını zenginleştirir; karar kalitesini artırır

Bu üç yüzey, aynı IOC için bile farklı kanıt eşiği ister. "Blok" çoğu zaman en yüksek kanıt ve en sıkı geri alma (rollback) disiplinini gerektirir.

2) IOC tabanlı mı, TTP tabanlı mı: yöntem seçimi ve sınırlar

Bu bölüm "hangisi daha iyi?" sorusunu değil, hangi koşulda hangisi daha rasyonel? sorusunu çözer. Modül 6'da ele aldığımız kalıcılık/etki mantığı burada somutlaşır.

2.1. IOC tabanlı yaklaşım: hızlı ama kırılgan

IOC tabanlı tespit/engelleme hızlıdır; özellikle aktif olayda kısa vadeli "korkuluk" etkisi üretir. Ancak kırılgandır: saldırganlar en hızlı değiştirilebilir katmanda (domain/IP/hash vb.) hareket eder. Bağlamsız IOC yönetimi, zamanla "kural çöplüğü" ve FP/noise birikimi üretir.

Operasyonelleştirmeden önce aranması gereken karşı kanıtlar:

• Bu IOC paylaşımlı/çok kiracılı bir ekosistemin parçası olabilir mi?
• Zaman çizelgesi tutarlı mı (ilk görülme/son görülme, kampanya dönemi vb.)?
• Kurum içinde meşru süreçlerle çakışıyor mu?

Örnek: Kamuya açık bir notta "yüksek riskli" denilen bir alan adı, kurum içinde uzun süredir meşru bir iş akışında da görülüyor. Bu durumda "kalıcı blok" refleksi yerine; dar kapsam + kısa TTL + izleme/uyarı ve güçlü belirsizlik notu daha doğru bir denge kurabilir.

Dikkat: IOC'lerin "somut" olması, otomatik olarak "doğru" oldukları anlamına gelmez. Somut olan şey, yalnızca eşleşmedir; niyet/bağlam çoğu zaman ayrıca kanıt ister.

2.2. TTP tabanlı yaklaşım: daha kalıcı ama pahalı

TTP tabanlı yaklaşım, davranış örüntülerini hedeflediği için daha dayanıklıdır; araçlar değişse de davranışın tümden değişmesi her zaman kolay değildir. Bedeli ise açıktır:

• Daha iyi telemetri kapsamı ve veri kalitesi gerekir
• Mühendislik ve bakım (tuning) yükü artar
• Benign faaliyetlerle karıştığında FP üretme potansiyeli yükselir (özellikle yerleşik yönetim araçları/otomasyon süreçleri devredeyse)

TTP tespiti tasarlanırken zorunlu sorular:

• Benign benzerleri ne kadar yaygın?
• FP'yi düşürmek için hangi bağlam alanları şart?
• "Bizde nerede görünür?" (hangi sistemlerde, hangi log/telemetri katmanlarında)
• Telemetri eksikliği varsa, iddia hangi noktada zayıflar?

2.3. Pratik seçim çerçevesi: hız-dayanıklılık-maliyet

• Olay aktif ve zaman baskısı yüksekse: IOC + dar scope + kısa TTL + geri alma planı
• Tekrarlayan tehdit ve stratejik riskse: TTP tabanlı yaklaşım + kapsam/telemetri çalışması + test/izleme planı
• Telemetri zayıfsa: önce görünürlük (coverage) ve veri kalitesi; aksi hâlde "sofistike tespit" sahte kesinlik üretir
• FP'nin iş etkisi yüksekse: kademeli yayılım, otomatik aksiyonu sınırlama, eşiği yükseltme
• SOC kapasitesi sınırlıysa: "daha çok alarm" değil, daha yüksek doğruluk ve daha iyi triage ergonomisi hedeflenir

İpucu: Bir yöntemi seçmeden önce "maliyet"i yalnızca mühendislik zamanı olarak düşünmeyin. FP/noise, analist dikkati tüketerek gerçek olayların kaçmasına yol açan bir güvenlik riskidir.

3) Threat hunting döngüsü: hipotez → kanıt → geri besleme

Threat hunting, otomatik sistemlerin göremediği kör noktaları hedeflediğinde anlam kazanır; "loglara rastgele bakmak" değildir. İleri seviyede hunting; CTI'nın tüketim noktası olduğu kadar, CTI'nın doğrulama motorudur.

3.1. Hipotez tasarımı: yanlışlanabilir ve ölçülebilir

İyi bir hunting hipotezi:

• Aranan davranışı net tanımlar
• Hangi veri kaynaklarında iz bırakacağını belirtir
• Karşı kanıtla yanlışlanabilir
• Çıktıyı aksiyona bağlar (detection backlog, hardening, playbook güncellemesi vb.)

Örnek: "Kritik varlıklarda belirli kimlik kullanım örüntülerinden sapmalar görmeyi bekliyoruz; görülürse oturum bağlamı ve erişim yolu ile ilişkilendirilebilir kanıt paketi çıkaracağız."\ Burada başarı, "alarm sayısı" değil; izlenebilir ve gerekçeli bulgu setidir.

3.2. Kanıt zinciri ve belirsizlik: hunting çıktısını "kural üretilebilir" yapmak

Hunting çıktısı yazılırken iki çizgi korunur:

• Gözlem: Ne görüldü? Nerede, ne zaman, hangi veriyle?
• Yorum: Bu gözlem hangi hipotezle uyumlu olabilir? Hangi alternatifler var?

Belirsizlik dili, şu soruları taşımalıdır: Ne kadar eminiz? Neye dayanıyoruz? Hangi veri gelirse fikrimiz değişir?\ Bu disiplin, bulguyu detection engineering tarafına taşımayı kolaylaştırır.

İpucu: Hunting çıktısını detection backlog'a aktarırken "minimum kanıt paketi" hazırlayın:
- Hangi veri kaynaklarında görüldü?
- Benign alternatif açıklamalar nelerdi, nasıl elendi?
- FP'yi düşürmek için hangi ek bağlam alanları gerekli?
- Başarı ölçütü ne olacak (TP/FP dengesi, tüketim oranı, kapsama hedefi)?

3.3. Geri besleme: CTI pipeline'ına geri yazma

İleri seviye bir programda hunting çıktıları:

• IOC'lerin saha değerini kalibre eder
• TTP eşlemesini düzeltir (modül 6'daki haritalama mantığı)
• Kampanya/küme değerlendirmesine kanıt sağlar (modül 8)
• Collection plan ve öncelikleri etkiler (modül 2)

"Bulgu yok" sonucu da değerlidir; ancak kesin hükme dönüşmesi, görünürlük boşluklarının (coverage gap) dürüstçe ele alınmasına bağlıdır.

4) Detection Content Lifecycle: tespit içeriğini "ürün" gibi yönetmek

Tespit içeriği, yazıldıktan sonra unutulacak bir çıktı değil; zamanla değişen tehdit ve benign davranışlar karşısında yaşayan bir üründür. "Fire and forget" yaklaşımı, bir süre sonra kural setini hem operasyonel hem güvenlik açısından kırılgan hale getirir.

4.1. Tasarım: "ne tespit ediyoruz?" sorusunu kilitlemek

Tasarım aşamasında netleşmesi gerekenler:

• Davranışın tanımı (ne/nerede)
• Zorunlu veri alanları ve telemetri bağımlılıkları
• Beklenen FP sınıfları ve azaltma stratejileri
• Otomatik aksiyon sınırı (uyarı mı, yalnızca zenginleştirme mi, kısıtlı engelleme mi?)
• Kalite kapıları (peer review, kanıt paketi kontrolü, gerekçeli eşik seçimi)

Dikkat: "Kural yazıldı" demek, "risk yönetildi" demek değildir. Kuralın neyi yakalamaması gerektiği (benign alan) tasarımın ayrılmaz parçasıdır.

4.2. Test ve doğrulama: "ne zaman yanlış çalışır?"

Testin hedefi yalnızca çalıştığını görmek değil; hangi koşulda yanlış çalışacağını anlamaktır:

• Temsili vakalarla doğrulama
• "Normalin farklı halleri"ni kapsayan benign varyasyonlar
• Sonuçların tekrar değerlendirilebilirliği (aynı koşullarda tutarlı çıktı beklentisi)

Bu doğrulama, kontrollü senaryolarda kırmızı/mavi ekiplerin işbirliğiyle yürütülen "purple teaming" yaklaşımından da beslenebilir.\ Bazı ekipler, doğrulama için küçük ve tekniklere eşlenmiş test kataloglarından da yararlanır (ör. Atomic Red Team yaklaşımı).\ Bu modülde kritik olan, araç adı değil; doğrulamanın kanıt zincirine oturtulmasıdır.

4.3. Kademeli yayılım: "log-only" ile güvenli devreye alma

Üretime bir anda "bırakmak", en hızlı şekilde alert fatigue üretmenin yollarından biridir. Bu nedenle kademeli yayılım yaygındır:

• Önce yalnızca kayıt/izleme ("log-only" veya "alert üretmeyen" mod)
• Gürültü seviyesi ve FP sınıfları ölçümü
• Eşik ve filtrelerin iyileştirilmesi
• Ardından uyarı; gerekiyorsa ve kanıt eşiği sağlanıyorsa sınırlı otomatik aksiyon

İpucu: Kademeli yayılımı iki eşikle yönetin:\ Güven eşiği (kanıt olgunluğu) + Operasyon eşiği (SOC kapasitesi, playbook hazırlığı, iş kesintisi toleransı).\ İkisi aynı anda sağlanmadan otomatik aksiyona geçmek, "hız"ı güvenlik riskine dönüştürür.

4.4. İzleme ve iyileştirme: FP/noise, drift ve performans

Üretimde izlenmesi gereken ana boyutlar:

• FP/TP oranı ve FP'nin kök neden sınıfları
• Drift sinyalleri: tehdit davranışının değişmesi, yeni benign örüntüler, veri alanlarının değişmesi
• Performans/ölçek: gecikme, maliyet, sistem yükü
• Tüketim: kural gerçekten işe yarıyor mu, yoksa "alert çöplüğü" mü üretiyor?

Burada "metrik" seçimi önemlidir: ölçüm, gerçek operasyonel değeri göstermeli ve manipülasyona dayanıklı olmalıdır. Sadece "kaç alarm ürettik?" ölçümü, kaliteyi ters yönde teşvik edebilir.

4.5. TTL / emeklilik: kural çöplüğünü önlemek

IOC'ler ve bazı kampanya-bağlı tespitler zamanla değer kaybeder. Bu nedenle:

• IOC'ler için TTL/expiration
• Kampanya bazlı içerikte doğal emeklilik
• Uzun süre tetiklenmeyen veya sürekli düşük değer üreten içerikte kapanış/temizlik

program sağlığı için şarttır.

Dikkat: Süresi dolmuş içerik sadece FP/noise üretmez; analistin güvenini aşındırarak gerçek alarmların kaçmasına zemin hazırlar.

4.6. Deconfliction ve rollback: çakışmaları yönetmek, geri almayı tasarlamak

Birden fazla sistem aynı davranışı farklı biçimde hedefleyebilir (SIEM/EDR/ağ katmanı). Deconfliction yapılmazsa:

• Mükerrer alarmlar triage'ı zorlaştırır
• Aynı olay farklı isimlerle görünür, tutarsızlık artar
• Analist yorgunluğu büyür

Deconfliction; birleştirme, rol ayırma (biri triage hızlandırır, diğeri davranışın çekirdeğini yakalar) veya gereksizi emekliye ayırma kararlarını sistematik hale getirir.

Rollback ise üretimde hasar veren içeriği "emniyet kemeri" gibi geri almayı sağlar: sahiplik, karar eşiği ve iletişim yolu net değilse, rollback kâğıt üzerinde kalır.

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• CTI sinyalini tespit içeriğine taşırken kaynak–iddia–kanıt ayrımının, karşı kanıt aramanın ve izlenebilirliğin neden kritik olduğunu
• IOC’nin hız avantajını, ancak kırılganlık/FP/noise maliyetini; TTP’nin daha kalıcı olabileceğini, fakat telemetri ve bakım yükünü nasıl yöneteceğimizi
• Threat hunting’in hipotez odaklı bir doğrulama döngüsü olduğunu; “bulgu yok” sonucunun bile doğru kurgulanırsa anlamlı kanıt üretebildiğini
• Detection content’in yaşayan bir ürün olduğunu; tasarım, test, kademeli yayılım, izleme, TTL/emeklilik ve rollback disiplinleriyle sürdürülebilir kılınması gerektiğini
• Deconfliction, tuning ve doğru metriklerle, alert fatigue ve operasyonel kaosu azaltarak karar kalitesini yükseltmeyi

MODÜL 10 — İstihbarat Mühendisliği ve Otomasyon

Modül Teması

Bu modül, CTI programını "iyi analiz yapan birkaç kişinin emeği" olmaktan çıkarıp, ölçülebilir ve ölçeklenebilir bir mühendislik disiplinine dönüştürmenin prensiplerini ele alır. Veri akışlarının (pipelines) tasarımı, otomasyonun getirdiği hız ile yarattığı riskler arasındaki denge ve Tehdit İstihbaratı Platformlarının (TIP) kurumsal mimarideki stratejik konumu, modülün omurgasını oluşturur.\ İleri seviyede asıl mesele "saniyede kaç olay işledik?" değil; yanlış veriyi ne kadar hızlı ve geniş yayabileceğimiz gerçeğiyle yüzleşmektir. Bir algoritma saniyede on binlerce kaydı işleyebilir; fakat CTI'da ölçekleme sorunu çoğu zaman "hız" değil, güven ve kanıt standardı sorunudur.

Dikkat: Kötü tasarlanmış bir süreci otomatize etmek, sadece daha hızlı hata yapmanızı sağlar. Yanlış bir sinyali otomatik olarak yaymak, yangına benzin dökmek gibidir.

1) CTI süreçlerini ölçekleme mantığı

CTI ölçekleme, "daha fazla feed eklemek" değildir. Ölçekleme; standart veri modeli + kalite kapıları + izlenebilirlik + doğru otomasyon sınırları demektir. Bu yaklaşım, modül 4'teki modelleme disiplinini üretim hattına taşır; modül 9'daki yaşam döngüsü mantığını ise "dağıtım ve geri alma" gerçekliğiyle birleştirir.

1.1. Ölçekleme ön koşulları: standart, sahiplik, değişiklik yönetimi

Ölçeklenebilir CTI'da her şeyin bir "sahibi" bulunur:

• Veri sahipliği: Hangi kaynağın (iç/dış) doğrulama eşiği, tazelik beklentisi ve yaşam süresi kim tarafından tanımlanır?
• Model sahipliği: IOC, sighting, ilişki, kampanya, küme (cluster) gibi nesnelerin "doğru tanımı" ve alanların anlamı kimde?
• İçerik sahipliği: Tüketiciye giden çıktı (bülten, uyarı, watchlist, enrichment, detection backlog girdisi) hangi kalite kapılarından geçer?

Sahiplik net değilse otomasyon, hızlandırmak yerine karmaşayı büyütür: çünkü hatalar sessizce çoğalır ve geriye dönük düzeltme maliyeti yükselir.

İpucu: Bir istihbarat ürününü "dosya" gibi değil, "yazılım paketi" gibi düşünün: sürümü, sahibi, doğrulama testi ve dağıtım kuralları olmalı. Bu zihniyet, CTI'da sürdürülebilirliği dramatik biçimde artırır.

1.2. Kalite kapıları: otomasyonda insan onayı nerede zorunlu?

Kalite kapısı "insan mutlaka görsün" demek değildir; doğru yerde doğru kontrolü koymaktır. Pratikte üç katmanlı bir yapı etkilidir:

1. 1. Makine kapısı (otomatik kontroller): format doğrulama, deduplikasyon, TTL, temel tutarlılık
2. 2. Analist kapısı (kanıt değerlendirme): kaynak-iddia-kanıt ayrımı; bağımsız doğrulama sinyali var mı; hangi karşı kanıt aranmalı?
3. 3. Operasyon kapısı (etki değerlendirme): tüketim yüzeyi ne; yanlış pozitif (FP) maliyeti ne; operasyonel yük ve iş etkisi ne?

Bu kapılar, modül 3'teki bilişsel hatalara karşı "analitik hijyen" yaklaşımının mühendislik karşılığıdır.

Dikkat: Aynı sinyali "izleme" yerine "yüksek etkili aksiyon" yüzeyine taşımak; kanıt eşiği, belirsizlik ve geri alma prosedürü net değilse kurumsal risk üretir.

1.3. Kanıt zinciri ve belirsizlik: hız-doğruluk dengesinin gerçek formülü

Otomasyon arttıkça sistemler gri alanı sevmediği için "kesinlik dili" yükselir. Oysa CTI gri alanla yaşar. Bu nedenle belirsizlik yönetimi, veri alanına ve akışa tasarımsal olarak gömülmelidir:

• Bir nesnenin "doğruluğu" değil, güven seviyesi (confidence) ve hangi koşulda değişeceği izlenebilir olmalı
• Bir iddia, kanıtı gelmeden "kalıcı gerçek" gibi modelde yer edinmemeli
• İlişkilendirme (correlation) çıktıları çoğu zaman hâlâ iddiadır; kalıcılaştırmadan önce curation kapısından geçmelidir

Örnek: Dış bir raporda, belirli bir IOC kümesi veriliyor; kurum telemetrisinde hiç görülmüyor. "Görülmedi" bilgisi tek başına "yoktur" demek değildir. Bu durumda mühendislik kararı, kalıcı engelleme yerine sınırlı süreli izleme/enrichment ve açık belirsizlik notuyla tüketilebilir bir kayıt üretmek olabilir.

İpucu: Ölçeklenebilirlik "her şeyi otomatik yapmak" değil; hangi veriyi hangi tüketiciye, hangi kanıt eşiğiyle ileteceğini standartlaştırmaktır. Otomasyon, doğru eşiklerle değer üretir.

2) TIP operasyonları: rol, süreç, kalite kapıları

TIP, veri ambarı değil; bir rafineri tesisidir. Ham veriyi alır, temizler, bağlamlandırır, ilişkilendirir ve uygun tüketim yüzeyine dağıtır. TIP'i "her şeyi yutan depo" yapmak veri çöplüğüne; "sihirli doğruluk makinesi" sanmak ise format ile doğruluğu karıştırmaya götürür.

2.1. Üretim hattı: ingestion → enrichment → correlation → curation → dissemination

• Ingestion (giriş): Her feed platforma alınmaz. Kaynağın güvenilirliği ve iddianın doğrulanabilirliği daha girişte sınıflanmalıdır. Bazı kuruluşlar, kaynak ve bilginin güvenilirliğini ifade etmek için istihbarat dünyasında kullanılan kodlama yaklaşımlarını (ör. Admiralty Code mantığı) referans alır; önemli olan "tek bir skor" değil, skoru hangi karara bağladığınızdır.
• Enrichment (zenginleştirme): Amaç "daha çok veri" değil, daha doğru yorum üretmektir. Otomasyon burada çok faydalıdır; fakat enrichment çıktısı, iddiayı kanıta çevirdiği varsayımıyla kullanılmamalıdır.
• Correlation (ilişkilendirme): En tehlikeli hata yanlış ilişkiyi kalıcılaştırmaktır. Korelasyon, hipotez üretmede güçlüdür; kanıt standardı olmadan "gerçek" gibi yayılırsa itibar yıpratır.
• Curation (kürasyon): Burada amaç veri azaltmak değil, kanıt standardını korumaktır.
• Dissemination (yayılım): Aynı veri, farklı tüketiciler için farklı yüzeylerde değer üretir: watchlist/enrichment, triage desteği, hunting ipuçları, detection backlog adayı gibi.

Dikkat: Korelasyon çıktısı çoğu zaman "iddia"dır. Kanıtı ve karşı kanıtı olmayan ilişkiyi gerçek gibi yaymak, otomasyonla çarpan etkisi yaratır.

2.2. Ingestion kuralları: karantina mantığı ve "GIGO" gerçeği

"Çöp içeri, çöp dışarı" (GIGO) CTI'da özellikle acımasızdır. Bu nedenle ingestion aşamasında şu kararlar net olmalıdır:

• Kaynak güven skoru belli eşiğin altındaysa veri karantinaya alınır (ana üretim hattına girmez)
• Normalizasyon ve deduplikasyon, daha ilk aşamada zorunludur
• Tazelik (freshness) ve yaşam süresi beklentisi etiketlenmeden veri "genel havuz"a düşmemelidir

Örnek: Bir feed, 203.0.113.0/24 içinden birkaç adresi şüpheli diye işaretliyor. Bu veriyi doğrudan "yüksek etkili" yüzeye taşımak yerine, karantina + sınırlı süreli izleme/enrichment hattına almak; yanlış pozitif maliyetini düşürür.

2.3. Yetkilendirme ve denetlenebilirlik: RBAC, ağırlık (weight) ve audit log

CTI'da "kim neyi değiştirdi?" sorusu lüks değildir. Özellikle otomasyon devredeyken:

• Rol bazlı erişim (RBAC): Kim veri ekleyebilir, kim ilişki kurabilir, kim yayımlayabilir?
• Ağırlıklandırma (weight): Deneyimsiz bir kullanıcının girdiği iddia ile kıdemli analistin doğruladığı kaydın sistemdeki etkisi aynı olmamalıdır. Bu, kişiye kutsiyet atfetmek değil; hata maliyetini yönetmek demektir.
• Denetim izi (audit log): Değişiklikler, gerekçesi ve kaynağıyla izlenebilir olmalı.
• Sürümleme: Kayıtların değişim geçmişi korunmalı; çünkü önceki hâl, kanıt zincirinin parçasıdır.

İpucu: Denetlenebilirlik, yalnızca "uyum" için değil, kalite için de gereklidir. Bir ilişki yanlış çıktığında, nerede bozulduğunu bulamadığınız her gün otomasyon riskini büyütür.

2.4. Veri yaşam süresi: TTL, emeklilik ve geri alma (rollback)

TIP içinde "ölmeyen veri" zamanla risktir:

• IOC'ler için TTL/expiration politikaları
• Kampanya/cluster gibi nesnelerde "son görülme" ve "durum" yönetimi
• Yanlış veri yayıldığında geri alma (rollback) ve düzeltme prosedürleri

Burada ana fikir şudur: CTI verisi "tarihsiz gerçek" değildir; zamana bağlı bir iddia/kanıt setidir. Yaşam süresi yönetimi yapılmazsa bayat veri FP üretir ve operasyonel güveni aşındırır.

3) STIX/TAXII ile mimari düşünme: veri sözleşmesi yaklaşımı

STIX ve TAXII, sadece format/protokol değil; kurumlar arası "dil birliği"nin teknik zemini olarak düşünülmelidir. STIX, bir veri sözleşmesi gibi ele alındığında anlam kazanır: üretici ve tüketici, alanların yalnızca varlığında değil anlamında uzlaşır.

3.1. Söz dizimi (format) ≠ anlam (semantic) uyumluluk

Teknik uyumluluk, anlamsal uyumluluğu garanti etmez.

• Üretici "confidence: 80" ifadesini "kesin aksiyon" gibi yorumluyorsa
• Tüketici aynı değeri "izle, temkinli ol" diye anlıyorsa\ ...mimari çöker; çünkü aynı veri, iki farklı operasyonel karara dönüşür.

Bu yüzden alanların anlamı ve karar bağlamı dokümante edilmelidir: "confidence hangi kanıt türlerine dayanır?", "hangi aralık hangi tüketim yüzeyine gider?" gibi.

Dikkat: "STIX geldi" demek "doğru geldi" demek değildir. Doğrulama kapıları, STIX/TAXII ile ortadan kalkmaz; sadece daha iyi yapılandırılmış hâle gelir.

3.2. Sürümleme ve geriye dönük uyumluluk (backward compatibility)

Veri sözleşmesi, zaman içinde değişir: alanlar eklenir, bazı alanların anlamı genişler veya daralır. Bu değişiklikler yönetilmezse iki risk doğar:

• Şema kırılması: Alanlar/nesneler değişir, tüketici yanlış parse eder veya veri kaybeder
• Anlam kırılması: Alan aynı kalır ama ölçüt değişir; tüketici aynı değeri eski anlamıyla yorumlar

Bu nedenle "hangi sürüm hangi tüketiciyle uyumlu?" sorusu bir tasarım gereksinimidir; test mantığıyla ele alınmalıdır.

3.3. Paylaşım sınırları: minimum bilgi, sınıflandırma ve güven

Paylaşım, teknik olduğu kadar yönetişim konusudur:

• İç/dış paylaşımda sınıflandırma ve etiketleme disiplini
• Gereksiz ayrıntıyı yaymama (need-to-know)
• Yanlış paylaşımın sonucu: itibar ve güven erozyonu, sözleşmesel risk, yanlış operasyonel aksiyon zinciri

Örnek: Bir ortakla IOC seti paylaşılırken kurum içi hassas bağlam (müşteri/varlık detayı) taşınmamalı; ancak tüketicinin "neden önemli?" sorusunu yanıtlayacak asgari bağlam (zaman aralığı, kanıt türü, confidence mantığı) korunmalıdır. Burada doğru yöntem, güvenlik ile fayda arasında ölçülü seçim yapmaktır.

4) SOAR senaryoları: hız-risk-etki dengesi

SOAR, CTI'ın aksiyona dönüştüğü yerdir. Bu noktada iki risk özellikle belirginleşir:

• Gürültü riski: düşük kaliteli veri otomasyonla alarm seline dönüşür
• Etki riski: yanlış veri, yanlış otomatik aksiyonla iş kesintisi doğurur

Bu yüzden soru "ne otomatikleşir?" değil; hangi eşiğin üzerinde otomatikleşir ve hangi frenlerle? sorusudur.

4.1. Tipik senaryolar: enrichment, skorlama, iş akışı

• SIEM/SOC olayına TIP'ten bağlam eklemek (en düşük riskli otomasyon sınıflarından)
• Risk/etki/kanıt gücüne göre önceliklendirme
• Ticket/iş akışı yönlendirme (doğru ekibe, doğru formatta, doğru SLA ile)
• Değişiklik yönetimiyle uyum (modül 9'daki yaşam döngüsüne bağlanır)

Örnek: Bir olay kaydı, otomasyonla "bilinen benign servisler" (allowlist) kontrolünden geçer or; kritik iş servislerini etkileme ihtimali varsa otomatik aksiyon yerine triage desteği ve kontrollü escalation üretilir. Böylece hız kazanılırken iş sürekliliği riski sınırlanır.

4.2. Human-in-the-loop: hangi kararlar mutlaka insan onayı ister?

İnsan onayı genellikle şu karar sınıflarında kritik hâle gelir:

• İş kesintisi riski yüksek aksiyonlar
• Kanıtı zayıf ama etkisi büyük sinyaller
• Üretim ortamını etkileyecek geniş kapsamlı değişiklikler

Dikkat: İnsan onayı koymak otomasyonu "bozmak" değildir; yanlış otomasyonun maliyeti, doğru otomasyonun getirdiği hız kazancını kolayca siler.

4.3. Otomasyon maliyeti: API limitleri ve işlem yükü

Otomasyon "bedava hız" değildir. Enrichment çağrıları, korelasyon işleri, sürekli sorgular; API limitleri ve sistem yükü doğurur. Mühendislik yaklaşımı burada şunu sorar:

• "Her alarm mı zenginleştirilecek, yoksa belirli öncelikler mi?"
• "Geri dönüş değeri düşük olan enrichment nerede durdurulmalı?"
• "Tüketiciye gereksiz yük bindiren veri nerede filtrelenmeli?"

Bu seçimler, operasyonel verimlilik ile güvenilirlik arasında gerçekçi bir denge kurar.

5) Feed yönetimi ve gürültü azaltma

Daha fazla feed, daha fazla güvenlik demek değildir; çoğu zaman daha fazla gürültü demektir. Tehdit değişir, benign davranışlar değişir, altyapılar el değiştirir, veri kaynakları kayar. İleri seviye hedef; kaliteyi sürdürülebilir biçimde koruyan filtreleme ve geri besleme düzeni kurmaktır.

5.1. Kaliteli feed kriterleri: bağlam, benzersizlik, tazelik

Kaliteli feed genellikle:

• Bağlam taşır: yalnız IOC değil, zaman aralığı, ilişki mantığı ve kullanım önerisi
• Benzersizlik sağlar: diğer feed'lerle örtüşme düzeyi bilinir
• Tazedir: gecikmesi (latency) düşükse operasyonel değer üretir
• Tutarlıdır: aynı tür veri aynı anlamla gelir

5.2. Overlap (örtüşme) analizi ve bütçe/iş yükü optimizasyonu

Aynı veriyi 5 farklı kaynaktan almak "güvenlik" değil, çoğu zaman kaynak israfıdır. Overlap analizi, feed portföyünü rasyonelleştirir:

• Hangi feed gerçekten benzersiz değer katıyor?
• Hangileri aynı veriyi farklı ambalajla tekrar ediyor?
• Hangileri daha çok gürültü üretiyor?

5.3. Gürültü azaltma stratejileri: confidence gate, TTL, alaka düzeyi

• Confidence gate: Belirsiz sinyaller doğrudan yüksek etkili yüzeye gitmez; uygun yüzeye yönlenir (izleme/enrichment gibi)
• TTL: Bayat verinin otomatik temizlenmesi FP ve performans sorunlarını düşürür
• Alaka (relevance): Kurumsal maruziyet/varlık bağlamına uymayan feed'ler filtrelenir

İpucu: Feed'i "mutlak doğru listesi" gibi değil, "hipotez üreticisi" gibi düşünün. Hipotezi üretmek kolay; hipotezi kanıt standardında test etmek zordur—ama değer de oradan gelir.

6) Metrikler ve program sağlığı: doğru şeyi ölçmek

"Neyi ölçerseniz onu yönetirsiniz." Yanlış metrikler, CTI programını yanlış davranışa iter: daha çok alarm, daha çok rapor, daha çok IOC... ama daha az değer.

6.1. Kaçınılması gereken "kibir metrikleri" (vanity metrics)

• "Bu ay 1 milyon IOC topladık." (Çöp veri de olabilir.)
• "500 rapor okuduk." (Sonuç ne?)
• "Alarm sayımız arttı." (Kalite/etki söyler mi?)

Bu metrikler kolay ölçülür ama karar kalitesini doğrudan artırmayabilir.

6.2. Etki odaklı "eyleme dönüştürülebilir" metrikler (actionable metrics)

• Time-to-consumption: İstihbaratın sisteme girişinden savunma tüketimine (kural/backlog/triage) dönüşmesine kadar süre
• False positive oranı ve trendi: Üretilen istihbaratın ne kadarı yanlış alarm üretiyor? Kök neden dağılımı nasıl değişiyor?
• MTTD/MTTR katkısı: CTI, tespit ve müdahale süresini hangi senaryolarda ne kadar etkiliyor?
• Paydaş memnuniyeti: SOC/IR/CISO gibi tüketiciler raporları gerçekten kullanıyor mu, kararlarını kolaylaştırıyor mu?
• Geri besleme oranı: Hunting/detection/IR döngüsünden CTI'a doğrulama ve düzeltme dönüşü düzenli mi?

Dikkat: Kolay ölçülen şeyler (IOC sayısı gibi) çoğu zaman en az anlam taşıyan şeylerdir. "Sayaç iyileşti ama güvenlik kötüleşti" tuzağına düşmemek için metrik seti dengeli kurulmalıdır.

6.3. Manipülasyona dayanıklı KPI tasarımı (Goodhart etkisi)

Bir ölçüm hedefe dönüştüğünde anlamını yitirebilir. "Aylık IOC sayısı" hedefi, ekibi bağlamsız IOC üretmeye iter. Daha sağlıklı bir yaklaşım:

• Üretim hacmini tek başına hedeflemek yerine tüketim oranı + time-to-consumption + FP trendi gibi bir seti birlikte izlemek
• Hedefleri, kalite kapıları ve belirsizlik yönetimiyle uyumlu seçmek
• "Ne zaman fikrim değişir?" sorusunu, metriklerin yorumuna da taşımak

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• CTI ölçeklemenin hızdan çok güven, kanıt standardı ve yönetişim meselesi olduğunu
• Otomasyonun riskini kalite kapıları, belirsizlik yönetimi ve geri alma disiplinleriyle kontrol etmeyi
• TIP’i “depo” değil rafineri/üretim hattı olarak konumlandırıp süreç sahipliği ve denetlenebilirliği kurmayı
• STIX/TAXII’yi format değil veri sözleşmesi olarak ele alıp anlamsal uyumluluk ve sürümleme risklerini yönetmeyi
• SOAR entegrasyonlarında human-in-the-loop ve allowlist kontrolleriyle iş sürekliliği riskini azaltmayı
• Feed portföyünü TTL, confidence gate ve overlap analiziyle sürdürülebilir biçimde optimize etmeyi
• “Kibir metrikleri” yerine operasyonel değeri ölçen, manipülasyona dayanıklı KPI setleri kurmayı

MODÜL 11 — Yayılım, Raporlama, Warning Intelligence ve Paydaş Yönetimi

Modül Teması

CTI döngüsünde "son kilometre", çoğu ekibin en çok hata yaptığı yerdir: Analiz doğru olsa bile doğru kişiye, doğru formatta, doğru zamanda ve doğru güven diliyle ulaşmadığında istihbaratın değeri hızla sıfıra yaklaşır. Bu modül; teknik sinyali karar girdisine dönüştüren raporlama standardını, erken uyarı tasarımını (warning intelligence) ve paydaş yönetimini aynı çerçevede ele alır. İleri seviyede başarı, sadece ne bildiğinizle değil; kanıt zincirini koruyarak neyi, nasıl ve hangi belirsizlikle söylediğinizle ölçülür.

1) İstihbarat ürün portföyü ve tüketici matrisi: "kime, ne zaman, hangi derinlikte?"

İleri seviye bir CTI programında "tek tip rapor" yaklaşımı verimsizdir. Aynı bulgu; SOC için kısa bir teknik bülten, IR için kampanya/tehdit profili, üst yönetim için ise iş riski odaklı bir özet olabilir. Buradaki temel fikir şudur: Ürün, tüketicinin karar mekanizmasına göre şekillenir.

1.1. Ürün tipleri ve karar ufku

• Taktik ürünler (kısa vadeli): Teknik bülten, IOC/artefakt listesi, hızlı uyarı notu. Hedef: operasyonel aksiyonun hızlanması (ama her zaman "blokla" değildir; çoğu zaman doğru çıktı, kanıt paketli önceliklendirmedir).
• Operasyonel ürünler (orta vadeli): Tehdit profili, kampanya raporu, SitRep (durum raporu). Hedef: avcılık hipotezi kurdurmak, IR kararını gerekçelendirmek, kaynak tahsisini yönlendirmek.
• Stratejik ürünler (uzun vadeli): Yönetici özeti, eğilim/öngörü raporu, yatırım/risk notu. Hedef: iş riski, hukuki/uyum etkisi, savunma yatırımı kararları.

Örnek: Bir fidye yazılımı vakası sırasında CISO'ya 20 sayfalık teknik analiz göndermek çoğu durumda yanlıştır. O an ihtiyaç duyulan ürün, kısa bir SitRep + seçenekler (COA) ve belirsizlik notudur; teknik ayrıntı eklerde kalır.

İpucu: Metni yazmadan önce tek cümlelik "karar mesajı" üretin: "Bu çıktı, hangi kararı değiştirmeli?" Karar tanımı yoksa ürünün hedefi de yoktur.

1.2. Tüketici segmentasyonu: aynı mesajın farklı ambalajı

• SOC/SIEM mühendisliği: kısa, makine/deteksiyon tüketimine uygun; bağlam "az ama doğru".
• IR/Threat hunting: TTP bağlamı, zaman çizgisi mantığı, alternatif açıklamalar ve doğrulama ipuçları.
• Yönetim: teknik jargonu azaltan, risk/etki ve seçenek odaklı anlatım.
• Hukuk/uyum/iletişim: paylaşım sınırları, doğrulanabilir ifade, dış iletişim riskleri.

Dikkat: "Herkese aynı raporu" göndermek iki uç hatayı büyütür: Operasyon ekibi için fazla soyut kalıp eyleme dönüşmez; yönetim için fazla teknik kalıp güven yerine karmaşa üretir.

1.3. Ürün portföyü tasarımı: brief-rapor-uyarı-ek

• Brief: hızlı hizalama; kanıtın tamamı değil "kanıt omurgası" gerekir.
• Analitik rapor: kalıcı kayıt; yöntem seçimi ve karşı kanıt arayışı görünür olmalıdır.
• Warning (uyarı): zaman kritik risk; eşik yanlışsa alarm yorgunluğu üretir.
• Teknik ek (appendix): derinlik isteyen ekip için izlenebilirlik; ana metni boğmadan ayrıntıyı taşır.

2) Yayılım kanalları ve ritim: push-pull dengesi, hız-risk takası

Yayılım kanalı yalnız iletişim tercihi değildir; risk tercihidir. Aynı içerik, farklı kanallarda farklı hasar/katma değer üretir.

2.1. Push ve pull kanalları

• Push: bülten/uyarı/pager/duyuru — hızlıdır; gürültü üretme riski taşır.
• Pull: portal/TIP arama/knowledge base — daha az gürültü; kaçırılma riski taşır.
• Karma model: kritik uyarılar push, diğerleri pull; "yüksek görünürlük ama düşük gürültü" hedeflenir.

Örnek: "Erken işaret" seviyesindeki bir uyarı tüm şirkete push edilmez; ilgili ekipler pull üzerinden erişir veya sınırlı bir dağıtımla paylaşılıp doğrulama geldikçe genişletilir.

Dikkat: Hız, yanlışsa daha hızlı itibar kaybıdır. "Doğruyu geç söylemek" bazen yönetilebilir; "yanlışı hızlı söylemek" çoğu zaman kalıcı güven erozyonudur.

2.2. Yayılım ritmi ve güncelleme disiplini

İleri olgunlukta iki şey standarda bağlanır:

1. 1. Güncelleme tetikleri: yeni kanıt, karşı kanıt, kapsam değişimi, risk seviyesinde kayma
2. 2. Değişim özeti: "ne değişti ve neden değişti?" (özellikle uyarılarda)

İpucu: Yayınlanan her önemli ürün için "geri alma/düzeltme" yolu tanımlı olsun. Hata sıfırlanmaz; yönetilir.

3) Yazılı rapor standardı: BLUF, kanıt-yorum ayrımı ve güven dili

İyi bir istihbarat raporu polisiye roman değildir; sonucu en sonda söylemez. Raporun dili, kanıt zincirinin taşıyıcısıdır.

3.1. BLUF: "en kritik yargı en başta"

BLUF (Bottom Line Up Front), ana mesajı ilk paragrafta verir. Bu, özellikle yönetici tüketiminde karar hızını artırır.

Örnek:\ Kötü: "İncelemeler sonucunda farklı sistemlerde çeşitli aktiviteler..." (hikâye anlatımı)\ İyi: "Kritik bir sistemde yetkisiz erişim sinyali var; veri sızıntısı riski orta-yüksek. Şu iki seçenekle ilerlenebilir..." (karar odaklı)

3.2. Kanıt-yorum ayrımı: Fact vs Assessment

Okur, neyin "gözlem" neyin "analist değerlendirmesi" olduğunu ayırt edebilmelidir.

• Kanıt (Fact/Gözlem): log/telemetriyle doğrulanabilir olay (zaman, kaynak türü, görülen davranış).
• Değerlendirme (Assessment/Yorum): kanıttan çıkarım; alternatif açıklamalarla birlikte sunulmalıdır.

Örnek:\ Kanıt: "192.0.2.10 üzerindeki uç noktada kimlik bilgisi dökümlemeye işaret eden bir süreç davranışı görüldü."\ Değerlendirme: "Bu davranış, ayrıcalık yükseltme hazırlığına işaret edebilir; ancak meşru yönetim aracı yanlış pozitif olasılığı dışlanmalı."

Dikkat: Değerlendirme cümlelerini dilinizle de ayırın: "muhtemelen/olasıdır/gösterebilir" gibi yüklemler, kesinlik izlenimi yaratmayı engeller; fakat kanıt gücünü artırmıyorsa "kesin" yazmak pahalıdır.

3.3. Kanıt zinciri ve izlenebilirlik: "fikrim ne zaman değişir?"

İleri raporlama, belirsizliği saklamaz; paketler:

• Confidence (güven seviyesi): neden bu seviyede? hangi bağımsız doğrulamalar var?
• Karşı kanıt arayışı: hangi bulgu iddiayı zayıflatır?
• Değişim koşulu: hangi şartta değerlendirme güncellenir?

Örnek: "Orta güven: altyapı benzerliği mevcut; bağımsız doğrulama sınırlı. 203.0.113.0/24 bloğundan kuruma tutarlı trafik görülmesi ilişkilendirmeyi güçlendirir; görülmemesi tek başına çürütmez çünkü telemetri boşluğu ihtimali var."

3.4. Stratejik yazım: Key Judgments, senaryo düşünme ve olasılıksal dil

Stratejik ürünler, geleceğe bakar; %100 kesinlik nadirdir. Bu yüzden:

• Key Judgments (temel yargılar): raporun omurgasıdır; kanıta dayanır, belirsizliği taşır.
• Senaryolar: "en olası" ve "en tehlikeli" senaryo gibi çerçeveler, karar vericiye risk iştahını ayarlama imkânı verir.
• Estimative Language: "olacaktır" yerine olasılık aralığı ve gerekçe.

Örnek: "Mevcut eğilimler ve geçmiş TTP benzerlikleri dikkate alındığında, önümüzdeki 90 gün içinde hedefli kimlik avı girişimi olasılığı orta-yüksek (%55-%75). Bu aralığın üst bandına çıkması için şu iki sinyalin görülmesi beklenir..."

4) Paylaşım disiplini ve OPSEC: TLP, sanitizasyon ve need-to-know

Bilgi paylaşımı, bir risk yönetimidir. Kurum içinde bile "herkes bilsin" yaklaşımı çoğu zaman gereksiz maruziyet (exposure) üretir.

4.1. TLP (Traffic Light Protocol) ile alıcı sınırı

• TLP:RED: yalnız belirtilen kişiler; paylaşım yok.
• TLP:AMBER: kurum içinde need-to-know ile sınırlı.
• TLP:GREEN: belirli iş ortakları/sektör paydaşlarıyla paylaşılabilir.
• TLP:CLEAR: kamuya açık.

Dikkat: TLP:RED ihlali, sadece "fazla paylaşım" değildir; kaynağın ifşası ve istihbarat akışının kesilmesi gibi ikinci derece riskler doğurur.

4.2. Sanitizasyon / redaksiyon: fayda-risk dengesini korumak

Dış paylaşım (veya geniş iç dağıtım) öncesi hassas veriler temizlenir:

• iç varlık adları, kullanıcı kimlikleri, müşteri bağlamı
• gereksiz ayrıntılı telemetri parçaları
• kurum topolojisini açığa çıkaran referanslar

Örnek: TLP:GREEN bir notta "example.org ile ilişkili risk sinyali" paylaşılır; kurum içi sistem adları ve olayın hassas bağlamı çıkarılır. Buna karşılık zaman aralığı, belirsizlik sınırı ve doğrulama koşulları korunur.

İpucu: Dış paylaşımda "asgari gerekli bağlam + net belirsizlik" kuralı iyi çalışır. Aşırı detay OPSEC'i zedeler; aşırı soyutluk ise güven kaybettirir.

5) Warning intelligence: eşik tasarımı, "yalancı çoban" etkisi ve doğrulama zinciri

Warning intelligence, "her sinyali alarm yapmak" değildir; zaman kritik riskte hazırlık kazandıran bir tasarımdır.

5.1. Eşik (threshold): kanıt gücü × etki × geri alınabilirlik

Uyarı eşiği tek bir sayı değil, üç bileşenli karardır:

• Kanıt gücü: bağımsız doğrulama, kaynak çeşitliliği, karşı kanıt araması
• Etki: iş kesintisi, güvenlik/uyum riski, kritik varlık etkisi
• Geri alınabilirlik: yanlışsa güven kaybı ve operasyonel maliyet

Yüksek etki ama düşük kanıt durumunda en olgun yaklaşım çoğu zaman "kesin hüküm" değil; koşullu uyarı + sınırlı yayılım + net doğrulama planıdır.

5.2. "Crying Wolf" sendromu ve korelasyon mantığı

Eşik çok düşükse herkes duyarsızlaşır; gerçek kriz anında uyarı görünmez olur. Bu nedenle uyarı mekanizması:

• tek bir sinyal yerine zincirleme sinyaller (korelasyon)
• zamanlama ve bağlam tutarlılığı
• karşı kanıt arayışı\ üzerine kurulmalıdır.

Örnek: "Yeni alan adı gözlemi" tek başına alarm üretmez; buna ek olarak "kurumdan bu alana beklenmeyen trafik" gibi ikinci bir bağımsız sinyal oluştuğunda öncelik artar.

$ threat-hunting # Sinyal-1: Yeni alan adı ilk kez görüldü
$ jq '.domain,.first_seen,.reputation' signals/new-domain.json
"login-secure-example.org"
"2026-04-28T14:05:11Z"
"unknown"

$ threat-hunting # Sinyal-2: Aynı alana beklenmeyen iç trafik var mı?
$ tshark -r edge_proxy.pcap -Y "dns.qry.name==\"login-secure-example.org\"" -T fields -e frame.time -e ip.src -e dns.qry.name
Apr 28, 2026 17:06:04.112233  10.20.4.17  login-secure-example.org
Apr 28, 2026 17:06:05.008921  10.20.9.44  login-secure-example.org

$ threat-hunting # İki bağımsız sinyal bir arada: öncelik yükseltilir
$ python score_signal.py --domain login-secure-example.org
priority=high  confidence=medium  decision=escalate_to_triage

5.3. Zaman baskısı ve belirsizlik notu

Erken uyarıda veri eksik olabilir. Analist, bunu saklamak yerine doğru paketler: "Elimizdeki veri sınırlı; ancak riskin büyüklüğü nedeniyle şu kapsamda uyarıyoruz. Şu sinyaller gelirse değerlendirmeyi güncelleyeceğiz."

Dikkat: Warning metninde "ne yapmalı?" kısmı seçenek ve öncelik diliyle yazılmalı; adım adım operasyon tarifi verilmemelidir. Yanlış ayrıntı seviyesi, hem güvenlik riskini hem de operasyonel yükü artırır.

6) Karar desteği, geri besleme ve etki ölçümü: CTI ürünleri "yaşayan" sistemdir

İstihbarat, sadece "sorunu anlatmak" değildir; kararı kolaylaştırmaktır. Bu noktada (modül 9'daki operasyonelleştirme yaklaşımıyla uyumlu biçimde) ürünlerin geri besleme döngüsü ve etkisi ölçülmelidir.

6.1. COA (Courses of Action): seçenekler ve takaslar

COA; alternatif hareket tarzlarını, her birinin iş etkisini ve riskini şeffaf sunar. Tek bir "doğru cevap" dayatmak yerine, karar vericinin risk iştahına göre seçim yapmasını sağlar.

Örnek:
- COA-1: Kapsam daraltma (etki düşük, risk orta)
- COA-2: Sıkı izleme ve doğrulama (etki çok düşük, risk orta-yüksek)
- COA-3: Agresif izolasyon (etki yüksek, risk düşük)

$ cti-decision # Seçenekleri etki/risk/maliyet ile karşılaştır
$ python evaluate_coa.py --incident INC-2026-104 --format table
COA      impact_score  risk_reduction  ops_cost  recommendation
COA-1    2/5           3/5             2/5       viable
COA-2    1/5           4/5             2/5       preferred_now
COA-3    5/5           5/5             5/5       reserve_for_escalation

$ cti-decision # Yönetim özeti için kısa karar notu üret
$ python coa_brief.py --incident INC-2026-104
BLUF: COA-2 uygulanmalı, COA-3 sadece ek doğrulama sonrası devreye alınmalı.
next_review: 2h
owner: SOC-Lead

Bu yaklaşım; "beklemenin maliyeti" ile "yanlış alarmın maliyeti" arasındaki dengeyi görünür kılar.

6.2. Geri besleme döngüsü: doğrulama-düzeltme-değer sinyali

• Doğrulama: "kurumda görüldü/görülmedi"
• Düzeltme: yanlış ilişkilendirme/sınıflandırma düzeltmesi
• Değer: "hangi karar hızlandı/hangi yük azaldı?"

Bu döngü kurulmazsa CTI ekibi "kendi kendine konuşan" bir yapıya dönüşür; ürünler çoğalır ama etki artmaz.

6.3. Metrikler ve Goodhart riski

Sadece "ayda kaç rapor" gibi hacim metrikleri, yanlış teşvik üretir. Daha dayanıklı metrikler:

• tüketim oranı (kim gerçekten kullanıyor?)
• time-to-consumption (ürün ne kadar hızlı karara dönüyor?)
• uyarı FP trendi (uyarı kalitesi zamanla artıyor mu?)
• paydaş geri bildirimi (karar kolaylığı ve yük etkisi)

İpucu: Ölçümü "kendinizi iyi hissettirmek" için değil, "hangi ürün hangi kararı gerçekten değiştiriyor?" sorusunu yanıtlamak için tasarlayın. Aksi halde metrik hedefe dönüşür ve anlamını yitirir.

Terimler Sözlüğü

Kendini Değerlendir

Bu Modülde Kazanılan Yetkinlikler

• CTI yayılımının “iletişim” değil, karar yüzeyi tasarımı olduğunu
• Ürün portföyünü tüketici matrisi ve zaman ufkuna göre yapılandırmayı; tek tip rapor tuzağından çıkmayı
• BLUF ile mesajı öne alıp, kanıt–yorum ayrımı ve izlenebilirlikle raporu kanıt standardına taşımayı
• TLP, need-to-know, sanitizasyon/redaksiyon ve OPSEC sınırlarıyla paylaşımı güvenli yönetmeyi
• Warning intelligence’ta eşik ve korelasyon mantığıyla “yalancı çoban” etkisini azaltmayı; belirsizliği dürüstçe paketlemeyi
• COA ve etki metrikleriyle CTI’ın değerini ölçmeyi; Goodhart riskine karşı dayanıklı ölçüm kurmayı