MODÜL 1 — Engagement Governance, Etik Çerçeve & Operasyon Tasarımı

Modül Teması

Yetki & Kapsam

ROE, RoE istisnaları, sözleşme ve yasal sınırlar.

Etik Çerçeve

Zarar verme, gizlilik, açıklama ve tırmandırma kuralları.

Operasyon Tasarımı

Hedef→aksiyon→kanıt zinciri ve geri çekilme planı.

İleri seviye Red Team & Pentest çalışmasında "teknik icra", çoğu zaman en görünür parçadır; ama sonucu belirleyen asıl katman yönetişim, sınırlar ve kanıt standardıdır. Bu modül; bir operasyonun meşru, ölçülebilir, denetlenebilir ve minimum zarar ilkesiyle yürütülmesini sağlayan temel çerçeveyi kurar. İleri seviyede başarı, "ne kadar çok şey denedim?" sorusuyla değil; neyi neden seçtim, hangi karşı kanıtı aradım, neyi hangi kanıtla ispatladım ve hangi koşulda durmayı bildim sorularıyla ölçülür.

Engagement — üç sütun

RoE yazarken ve teknik seçerken bu kartları masa üstünde açık tutun.

Yetki & kapsam

Yazılı yetki + in/out of scope + zaman penceresi. Sözlü “tamam” yerine sürümlü belge ve imza hattı.

Minimum zarar

Yoğunluk limiti, kill-switch, deconfliction. “Ne kadar ileri?” sorusunun önceden cevabı yoksa dur.

Kanıt zinciri

Her iddia için ham çıktı + yorum ayrımı ve belirsizlik dili. Denetimde kişi değil paket konuşur.

Bu Modülde Hedeflenen Kazanımlar

Red Team ve Pentest'i; amaç, çıktı, başarı metriği ve uygunluk koşulları üzerinden ileri seviye düzeyde ayrıştırmak
Yetkilendirme, hukuki/etik sınırlar, NDA ve veri işleme yükümlülüklerini "kâğıt üstü" değil, operasyon tasarımının girdisi olarak kullanmak
RoE'yi (Rules of Engagement) kapsam/kapsam dışı, zaman penceresi, izinli teknik sınıflar, deconfliction ve kill-switch ile profesyonel bir operasyon anayasasına dönüştürmek
Risk yönetimini "rapor sonu notu" olmaktan çıkarıp, yöntem seçimi ve kalite kapılarına bağlamak
Bulguları kanıt zinciri + belirsizlik yönetimi + güven dili ile paketleyerek denetlenebilir hale getirmek

1) Engagement governance: Operasyonun iskeleti

Engagement governance; operasyonun başından sonuna kadar kim, neyi, hangi sınırlar içinde ve hangi denetimle yapacak sorusunu cevaplayan yönetim katmanıdır. Yönetişim zayıfsa iki şey kaçınılmaz olur: (1) kapsam kendiliğinden kayar, (2) doğru teknik bulgu bile yanlış kararları tetikleyebilir.

Bu katmanda ileri seviye fark şu şekilde görünür: Sözlü mutabakatların yerine izlenebilir kararlar koyarsın; "kim dedi?" yerine "hangi kanıta dayanıyoruz?" sorusunu işletirsin. Böylece operasyon, kişilere değil dokümana ve kanıta dayanır.

1.1. Paydaşlar, roller ve karar hatları

İleri seviye bir çalışmada paydaşları "listeden ibaret" görmezsin; paydaş haritası, operasyonun risk yüzeyi ve karar hızıdır.

İş sponsoru / yetki sahibi: Operasyonun "neden yapıldığını" ve kabul edilebilir risk düzeyini belirler.
Teknik sahiplik (IT/Platform/Uygulama): Kapsamın gerçekliği, bakım pencereleri, iş sürekliliği hassasiyetleri buradan gelir.
SOC/IR ve güvenlik liderliği: Deconfliction ve "ölçümün bozulmaması" buradaki koordinasyona bağlıdır.
Hukuk/uyum ve gizlilik (varsa): Yetkilendirme, veri işleme ve üçüncü taraf sınırları bu katmanda netleşir.
Hakem/"güvenilir temas" rolü (Trusted Agent): Red Team gerçekçiliğini bozmadan, kriz anında doğrulama ve durdurma kararlarını hızlandıran kişi/rol.

Örnek: Büyük bir kurumda operasyon boyunca tek bir kişiyle yürümek, karar hızını artırabilir ama "tek noktada tıkanma" riski doğurur. Bu yüzden bazı kurumlar küçük bir yönlendirme kurulu (steering committee) ile ilerler: kararlar daha şeffaf ve dayanıklı olur; fakat toplantı/koordinasyon maliyeti artar. Küçük ekiplerde ise daha dağıtık model hız sağlar; ama belirsizlik ve yanlış anlaşılma riski yükselir.

İpucu: Governance modelini seçerken "en hızlı" olanı değil, en az belirsizlik üreten ve kill-switch kararını en hızlı çalıştıran modeli tercih et. Hız, ancak sınırlar netse değerlidir.

1.2. Onayın doğrulanması: "Kimin yetkisi var?" sorusu

Yetkilendirme, sadece "onay var" demek değildir; kimin hangi sınırlar için onay verdiğinin kanıtıdır. İleri seviyede burada iki kalite kapısı vardır:

— Yazılılık ve zaman uyumu: Onay, operasyon penceresi ve kapsam ile uyumlu olmalı; "eski bir onay" bugünün kapsamını otomatik meşrulaştırmaz.
— Bağımsız doğrulama: "Bu varlık bizim" beyanı tek başına yeterli kabul edilmez; mülkiyet/işletim/üçüncü taraf ilişkisi, operasyon başlamadan doğrulanır.

Örnek: Bir varlığın üçüncü taraf barındırma hizmeti üzerinde çalıştığı ortaya çıkarsa, müşterinin onayı "her koşulda yeterli" sayılmayabilir; üçüncü taraf sözleşmeleri ve sağlayıcı politikaları sınır koyabilir. Bu yüzden doğrulama, yalnızca teknik değil sözleşmesel bir gerçeklik kontrolüdür.

Dikkat: Yetkilendirme belirsizse teknik doğruluk "başarı" sayılmaz. Belirsizlik, hukuki ve etik riski büyütür; en doğru hamle çoğu zaman durmak ve netleştirmektir.

2) Red Team ve Pentest: Aynı sahne, farklı oyun

Temel seviyede "biri zafiyet bulur, diğeri sızar" gibi kısa tanımlar duyarsın; ileri seviyede ayrım genişlik-derinlik, keşif-simülasyon ve çıktının kim tarafından nasıl kullanılacağı üzerinden yapılır.

2.1. Amaç ve odak

Pentest genellikle genişlik odaklıdır: belirlenen kapsam içinde zafiyet/yanlış yapılandırma sınıflarını bulur, doğrular, önceliklendirir ve iyileştirmeye bağlar. Bu, güvenlik hijyeninin ölçümüdür.
Red Team derinlik ve hedef odaklıdır: amaç "her şeyi bulmak" değil; belirli bir tehdit davranışını veya iş hedefini simüle ederek kurumun insan-süreç-teknoloji bütününde savunma kapasitesini ölçmektir.

2.2. Başarı kriterleri: neyi ölçtüğünü bilmek

Pentest'te başarı çoğu zaman kapsam içi risklerin doğru tespiti ve bulguların eyleme dönüştürülebilirliğidir. Red Team'de ise başarı; hedefe ulaşmak kadar, savunmanın neyi ne zaman gördüğü ve yanıtın kalitesi ile ölçülür. Bazı kurumlar "hedefe ulaşma süresi" (time-to-compromise gibi) veya "tespit/müdahale süresi" (time-to-detect/respond gibi) metrikleri de izler; ama ileri seviye yaklaşım, metrikleri "gösteriş" değil iyileştirme hattının girdisi yapar.

Örnek: Aynı "erişim kontrol zayıflığı" Pentest'te bir bulgu olarak raporlanır. Red Team'de aynı durum ayrıca şu sorularla değerlendirilir: Bu davranış nerede görünür olmalıydı? Hangi kontrol boşluk verdi? Hangi ekip neyi yanlış yorumladı? Bu sorular, modül 17'deki rapor ve purple teaming çıktılarının iskeletini oluşturur.

Dikkat: Güvenlik olgunluğu düşük bir kurumda (temel zafiyet yönetimi oturmamışken) Red Team çalışması, çoğu zaman yanlış sırayla seçilmiş bir yatırımdır. İleri seviye uzmanlık; "hemen Red Team yapalım" demek değil, gerektiğinde önce Pentest ve temel iyileştirme önermek demektir.

3) Hukuki/etik çerçeve: sınırlar, veri ve sorumluluk

Teknik bir saldırı ile meşru bir güvenlik değerlendirmesi arasındaki ayrım "niyet" değil, izin, sınır ve kanıttır. İleri seviyede etik; soyut bir iyi niyet beyanı değil, operasyon tasarımına gömülü güvenlik frenleridir.

3.1. NDA ve sözleşmesel yükümlülükler: paylaşım, saklama, imha

NDA ve sözleşme hükümleri çoğu zaman şu soruların yanıtını belirler:

Kanıtlar kimlerle paylaşılır? (need-to-know)
Kanıtlar nerede saklanır, ne kadar tutulur, nasıl imha edilir?
Üçüncü taraflarla (alt yüklenici, sağlayıcı) sorumluluk zinciri nasıl işler?

İleri seviye pratikte buradan çıkan temel ilke şudur: kanıt üret, ama gereksiz risk üretme. Kanıtın değeri; ayrıntı miktarıyla değil, iddiayı destekleme gücüyle ölçülür.

3.2. Veri işleme ve gizlilik: kanıt yeterliliği ile veri minimizasyonu

Operasyon sırasında kişisel veriler (PII), ticari sırlar veya regülasyon kapsamındaki verilerle temas riski oluşabilir. İleri seviye yaklaşım; "kanıt için ne gerekiyorsa alırım" refleksini kırar.

Veri minimizasyonu: İddiayı destekleyen en az veriyle yetinmek
Amaç sınırlılığı: Toplanan kanıtı yalnızca sözleşmedeki amaç için kullanmak
İzlenebilirlik: Kanıtın kim tarafından, ne zaman, hangi bağlamda üretildiğini kayıt altına almak
Güvenli saklama ve imha: Kanıtın kendisinin yeni bir risk haline gelmesini engellemek

Örnek: "Yetkisiz erişim mümkün" iddiasını kanıtlamak için gerçek kişisel veriyi rapora taşımak yerine, erişimin varlığını gösteren temsili/maskelemiş kanıt üretmek çoğu zaman daha doğru ve daha güvenlidir.

İpucu: Kanıt stratejisini "fazla veri = güçlü kanıt" diye düşünme. Çoğu durumda güçlü kanıt; doğru bağlam + izlenebilirlik + gereksiz veri teması olmadan ispat demektir.

3.3. Etik karar verme: belirsizliği yönetmek

Bazı kurumlar etik kararları daha kural-bazlı (deontolojik) bir çerçevede yürütür: "RoE'de yoksa yapılmaz." Bu yaklaşım belirsizliği azaltır. Bazı kurumlar ise fayda/zarar dengesi (faydacı yaklaşım) ile düşünür: "Toplam fayda, riskten büyükse..." Bu yaklaşım esnektir ama daha fazla yorum ve daha fazla gerekçe ister.

İleri seviye olgunluk, hangi yaklaşım seçilirse seçilsin şunu korur: Belirsizlik yükseliyorsa, kararın gerekçesi ve durdurma koşulları daha net yazılmalıdır.

4) RoE (Rules of Engagement): operasyonun anayasası

RoE; teknik ekiple iş birimi arasındaki beklentiyi yönetir ve operasyonel felaketleri önler. İyi bir RoE iki uç hatayı engeller: kapsam kayması (scope creep) ve operasyonel zarar.

4.1. Kapsam / kapsam dışı: liste değil mantık

Kapsam; yalnızca ağ aralığı veya uygulama listesi değildir. İleri seviye kapsam tanımı şunları da içerir:

Ortam türleri (üretim/test/geliştirme) ve kritik dönemler
Kimlik kapsamı (test rolleri, SSO bağları, dizin ilişkileri)
Veri sınıfı temas sınırları
Etki temelli yasaklar (kesinti riski yüksek davranışlar gibi)

Örnek: "203.0.113.0/24 kapsam içi, 198.51.100.0/24 kapsam dışı" gibi teknik sınırların yanında, "iş sürekliliğini riske atacak davranış sınıfları kapsam dışı" gibi etki temelli sınırlar yer alabilir. Bu, teknik sınırların yetmediği yerde minimum zarar ilkesini korur.

4.2. Zaman penceresi ve izinli teknik sınıflar: yöntem seçimi burada başlar

Zaman penceresi yalnızca "mesai saatleri" değildir; bakım aralıkları, değişiklik yönetimi, SOC/IR vardiya gerçekliği ve eskalasyon kanallarıyla birlikte düşünülür. İzinli teknik sınıflar ise "hangi şeyler yapılır?" listesinden çok şunları netleştirir:

Hangi risk sınıfına girilmez?
Hangi kanıt standardı sağlanmadan iddia kurulmaz?
Hangi koşulda yöntem değişir veya durulur?

Bu bölümde yöntemi seçerken "en etkili" yerine genellikle "en kontrol edilebilir ve geri döndürülebilir" yol öne çıkar. Çünkü ileri seviyede hedef "girmek" değil; ölçmek, öğretmek ve iyileştirmeye çevirmektir.

4.3. Deconfliction: gerçekçilik ile güvenli koordinasyonun dengesi

Deconfliction, "yakalanmamak" için değil; kurumun kendi savunma süreçleriyle operasyonun çarpışmasını ve yanlış kriz tetiklenmesini önlemek içindir. Red Team gerçekçiliğini korurken; kriz anında "tatbikat mı gerçek mi?" sorusunun güvenli bir kanaldan sorulabilmesi gerekir.

Hakem rolü (Trusted Agent): Kritik anlarda hızlı doğrulama ve karar hattı
Güvenli iletişim: İzlenen ağın dışından, operasyonu tehlikeye atmayacak bir kanal
Bilgi ifşası yönetimi: Operasyonun gerçekçiliğini bozacak erken ifşalardan kaçınmak

Örnek: Savunma ekibi bir aktiviteyi tespit ettiğinde, bunu engellemeden önce "tatbikat doğrulaması" yapabilmeli; fakat bu doğrulama, operasyonun tüm detaylarını açığa çıkaracak şekilde tasarlanmamalıdır. Aksi halde ölçüm "yanar" ve gerçekçilik kaybolur.

İpucu: Deconfliction'ı trafik polisliği gibi düşün: amaç hız kesmek değil, çarpışmayı engellemek. Aynı zamanda aşırı bilgi paylaşımıyla "oyunu bozmayacak" kadar ölçülü olmalıdır.

4.4. Kill-switch: acil durdurma, geri dönüş ve teslim

Kill-switch; tek bir cümle değil, önceden tanımlı bir emniyet frenidir:

Hangi tetikleyicilerle durulur? (kesinti sinyali, beklenmeyen sistem davranışı, veri sınıfı riski, üçüncü taraf etkisi, hukuki/etik şüphe)
Kim durdurma yetkisine sahiptir?
Hangi kanaldan bildirilir?
Durdurma sonrası hangi erişimler kaldırılır, hangi geçici değişiklikler geri alınır, hangi kanıtlar nasıl teslim edilir?

İleri seviyede "durmak", başarısızlık değil; profesyonel sınır disiplinidir.

5) Risk yönetimi ve minimum zarar: seç-kanıtla-dur

İleri seviye yaklaşımın etik iddiası basittir: Güvenliği ölçerken güvenliğe zarar vermemek. Bunun pratik karşılığı, riskin yöntem seçimine girdi olmasıdır.

5.1. Risk sınıfları: neyi yönetiyorsun?

Operasyonel risk (kesinti, performans, iş sürekliliği)
Veri riski (gizli veri teması, kanıtın yanlış saklanması)
Hukuki/uyumluluk riski (yetki sınırı, üçüncü taraf, regülasyon)
İtibar riski (yanlış alarm, yanlış anlaşılma)
Güvenlik riski (kurum kontrollerini bozan veya kalıcı iz bırakan davranışlar)

5.2. Kanıt zinciri ve belirsizlik yönetimi

Bir iddiayı güçlü yapan şey "sert" konuşmak değil, gerekçeli konuşmaktır. İleri seviyede kanıt paketi şu ayrımları korur:

Gözlem: Doğrudan görülen veri/iz
Yorum: Gözlemden çıkan anlam ve risk
Varsayım: Etkiyi büyüten/sınırlayan koşullar
Karşı kanıt: Seni yanlışlayabilecek alternatif açıklama
Güven dili (confidence): "Ne kadar eminim, neden; hangi koşulda değişir?"

Örnek: "Yüksek etki" demek yerine, "Şu gözlemler nedeniyle orta-yüksek güvenle değerlendiriyorum; şu kontrol/telemetri görülürse değerlendirmem düşer" demek, hem denetlenebilir hem de dürüst bir standarttır.

Dikkat: "İleri seviye" = daha agresif olmak değildir. İleri seviye; kanıt yeterliliğini bilmek ve gereksiz risk üretmeden doğru noktada durabilmektir.

Terimler Sözlüğü

Terim	Açıklama
Engagement	Yetkilendirilmiş güvenlik değerlendirmesi/operasyon; kapsamı ve çıktıları tanımlı çalışma
Governance	Yönetişim; roller, sorumluluklar, karar hatları ve denetim mekanizmaları
RoE (Rules of Engagement)	Operasyonun kuralları; kapsam, sınırlar, iletişim, durdurma koşulları
Scope / Out-of-scope	Kapsam / kapsam dışı; hangi varlıkların, yöntemlerin ve verilerin dahil olmadığı
Scope creep	Kapsam kayması; operasyonun kontrolsüz biçimde kapsam dışına taşması
Deconfliction	Çakışma yönetimi; operasyonun kurum süreçleriyle çarpışmasını önleme ve doğrulama
Kill-switch	Acil durdurma mekanizması/prosedürü; tetikleyici koşullar + yetki + geri dönüş
OPSEC	Operasyon güvenliği; bilgi sızıntısı ve ilişkilendirilebilirlik risklerini azaltma disiplini
Need-to-know	Bilginin yalnızca gerekli kişilere ve gerekli düzeyde paylaşılması ilkesi
Data minimization	Veri minimizasyonu; ispat için gereken en az veriyle yetinme
Chain of custody	Kanıt zinciri; kanıtın üretimi, saklanması, erişimi ve tesliminin izlenebilirliği
Deliverable	Teslim edilebilir çıktı; rapor, brief, ölçüm seti, iyileştirme önerileri vb.
Confidence	Güven düzeyi; iddianın eminliği ve gerekçesi
PII	Kişisel tanımlayıcı bilgi; bir kişiyi doğrudan/dolaylı tanımlayan veri
Out-of-band communication	Test edilen/izlenen ağın dışından yapılan güvenli iletişim
Trusted Agent	Operasyondan haberdar hakem/temas rolü; kriz anında doğrulama ve karar hızlandırma
Steering committee	Yönlendirme kurulu; karar ve risk yönetimini kolektif yürüten küçük kurul
RBAC	Rol tabanlı erişim kontrolü; erişimlerin rollerle sınırlandırılması yaklaşımı
Time-to-Compromise	Hedefe ulaşma süresi; bazı red team senaryolarında izlenen performans metriği
Time-to-Detect/Respond	Tespit ve müdahale süresi; savunma performansını ölçmekte kullanılan metrikler

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Operasyon sırasında kapsam listesinde açıkça belirtilmeyen ama hedef sisteme doğrudan bağlı bir veritabanı sunucusu fark ediliyor. “Profesyonel/ileri seviye” yaklaşım hangisidir?

A) Zafiyeti hemen doğrulayıp ilerlemek; sonra raporda “kapsam dışıydı” demek

B) Sunucuyu pasifçe inceleyip riskini tahmin etmek ve sessizce devam etmek

C) Operasyonu durdurmadan, veri temasını artırmadan ilerlemek; çünkü “bağlı sistem” sayılır

D) Durdurmak, hakem/Trusted Agent üzerinden kapsam netleştirme onayı veya talimatı almak

E) Sunucunun sahibini bulmak için doğrudan dış iletişime geçmek

Doğru: D
Kısa gerekçe: Kapsam belirsizken ilerlemek scope creep ve hukuki/etik risktir. A/B/C “kapsam dışına temas”ı normalleştirir. E yanlış kanallarla yeni risk üretir.

2) Red Team ve Pentest ayrımını ileri seviye düzeyde en doğru kuran ifade hangisidir?

A) Red Team yalnızca iç ağda; Pentest yalnızca dış ağda yapılır

B) Pentest genişlik ve bulgu hijyeni; Red Team hedef/derinlik ve savunma kabiliyeti ölçümü odaklıdır

C) Red Team için kanıt gerekmez; Pentest için gerekir

D) Pentest yalnızca web için; Red Team yalnızca sosyal mühendislik içindir

E) Red Team yasal izin gerektirmez; Pentest gerektirir

Doğru: B
Kısa gerekçe: B amaç ve ölçüm mantığını doğru kurar. Diğerleri ya yanlış geneller ya da temel güvenlik prensiplerine aykırıdır.

3) Deconfliction süreci, yanlış kurgulanırsa en çok hangi riski büyütür?

A) Savunma ekibinin motivasyon kaybı

B) Operatörün teknik başarısının artması

C) Operasyonun “gerçekçilik” ölçümünün bozulması ve bazı göstergelerin erken ifşası

D) Raporun daha kısa yazılması

E) Kapsamın otomatik daralması

Doğru: C
Kısa gerekçe: A ikincil olabilir ama ana risk ölçümün bozulmasıdır. B/D/E alakasız veya ters yöndedir.

4) Üçüncü taraf altyapı üzerinde barınan bir varlık için “bağımsız doğrulama” neden kritiktir?

A) Teknik ekip daha hızlı çalışsın diye

B) Müşterinin beyanı her zaman yeterlidir

C) Müşteri onayı, üçüncü taraf sözleşme/politikalarını otomatik olarak kapsamayabilir; hukuki ve operasyonel risk doğar

D) Sadece raporun uzunluğu artsın diye

E) Sadece OPSEC için; hukukla ilgisi yoktur

Doğru: C
Kısa gerekçe: Üçüncü taraf sınırları sözleşmesel ve uyumluluk boyutu taşır. A/D/E konuyu saptırır; B tehlikeli bir varsayımdır.

5) Kill-switch tasarımında olgun yaklaşım hangisidir?

A) “Bir şey olursa dururuz” demek

B) Durdurma yetkisini yalnızca tek bir kişiye bağlamak ve operatörü yetkisiz bırakmak

C) Tetikleyiciler + yetki + güvenli iletişim + geri dönüş/teslim adımlarını önceden tanımlamak

D) Kill-switch’i sadece rapor tesliminde konuşmak

E) Kill-switch’i teknik bir detay sayıp RoE’den çıkarmak

Doğru: C
Kısa gerekçe: Kill-switch belirsizliği operasyon öncesinde azaltır. A/D/E yetersiz; B karar tıkanması riskini artırabilir.

6) Kanıt üretimi ile veri minimizasyonu dengesi için en doğru ifade hangisidir?

A) Ne kadar çok veri, o kadar güçlü kanıt

B) İspat için gerçek kişisel veri mutlaka rapora konmalıdır

C) İddiayı destekleyen asgari kanıt, gereksiz veri temasını artırmadan üretilmelidir

D) Veri minimizasyonu yalnızca hukuk ekibinin işidir

E) Kanıt zinciri tutulursa veri yönetimine gerek yoktur

Doğru: C
Kısa gerekçe: İleri seviye standardın kalbi “yeterli kanıt + minimum risk” dengesidir. A/B risk üretir; D/E sorumluluk kaçırır.

7) Aşağıdaki ifadelerden hangisi “güven dili (confidence)”ni doğru kullanır?

A) “Kesin böyledir, çünkü tecrübem var.”

B) “Yüksek güven: şu gözlemler var; şu karşı kanıt görülürse değerlendirmem düşer.”

C) “Düşük güven ama raporda yüksek yazalım.”

D) “Güven düzeyi gereksiz; herkes anlar.”

E) “Orta güven: çünkü daha fazla veri toplamadım ama toplayabilirdim.”

Doğru: B
Kısa gerekçe: B, kanıt + falsifiye edilebilirlik (karşı kanıt) içerir. A dogmatik, C etik dışı, D yanlış, E gerekçeyi zayıf kurar.

8) Bir kurum Red Team talep ediyor; ancak temel zafiyet yönetimi ve iyileştirme döngüsü olgun değil. İleri seviye danışman tavrı ne olmalıdır?

A) Hemen Red Team; “gerçekçilik” her şeyden önemli

B) Red Team’i reddedip hiçbir hizmet vermemek

C) Önce Pentest/temel iyileştirme ve ölçülebilir olgunluk hedefleri önerip, Red Team’i doğru sıraya almak

D) Kapsam dışı sistemlerde de test yapıp “tam resim” çıkarmak

E) Yalnızca araç çıktısı üretmek yeterlidir

Doğru: C
Kısa gerekçe: Red Team, olgunluğun üst katmanıdır; doğru sırayı kurmak profesyonelliktir. A/D risk üretir; B gereksiz keskin; E kalite standardını düşürür.

9) Governance model seçiminde “merkezi kurul” ile “dağıtık model” arasındaki en doğru trade-off hangisidir?

A) Merkezi kurul her zaman daha hızlıdır

B) Dağıtık model her zaman daha güvenlidir

C) Merkezi model denetlenebilirliği ve tutarlılığı artırabilir ama koordinasyon maliyetini yükseltir; dağıtık model hız sağlayabilir ama belirsizlik/yanlış anlaşılma riskini artırır

D) İkisi arasında pratik fark yoktur

E) Seçim sadece rapor formatını değiştirir

Doğru: C
Kısa gerekçe: Yönetim tasarımı bir maliyet-risk dengesi taşır. A/B genelleme, D/E yanlış indirgeme.

10) RoE’de “izinli teknik sınıflar” bölümünün en kritik işlevi hangisidir?

A) Operatörün daha yaratıcı olmasını sağlamak

B) Hangi koşulda yöntem değişeceğini/durulacağını ve hangi risk sınıflarına girilmeyeceğini netleştirerek belirsizliği azaltmak

C) Yalnızca raporda güzel görünmek

D) Kapsamı operasyon sırasında genişletmeyi kolaylaştırmak

E) Deconfliction ihtiyacını ortadan kaldırmak

Doğru: B
Kısa gerekçe: İleri seviye RoE’nin amacı belirsizliği öldürmektir. A/C/D/E hedefi saptırır veya yanlış vaat eder.

Bu Modülde Kazanılan Yetkinlikler

Yönetişim; operasyonun “kağıt işi” değil, başarıyı belirleyen iskeletidir.
Red Team ve Pentest ayrımı, teknik farktan çok amaç–ölçüm–çıktı farkıdır.
Yetkilendirme, üçüncü taraf sınırları ve veri işleme; operasyonun meşruiyetini ve güvenliğini belirler.
RoE; kapsam disiplini, deconfliction ve kill-switch ile ölçülebilir, kontrollü ve denetlenebilir bir operasyon sağlar.
İleri seviye kalite; kanıt zinciri + belirsizlik yönetimi + yöntem seçimi üçlüsünde görünür.

MODÜL 2 — Metodolojiler, Tehdit Modelleme & Senaryo Kurgusu

Modül Teması

Metodoloji

PTES, OSSTMM, NIST ve TIBER çerçeveleri.

Tehdit Modeli

STRIDE, kill chain, ATT&CK eşlemesi.

Senaryo Kurgusu

Tehdit aktörü taklidi ve hedef-odaklı planlama.

Bu modül, Red Team & Pentest çalışmalarını "tek tek tekniklerin toplamı" olmaktan çıkarıp uçtan uca tasarlanmış, ölçülebilir ve denetlenebilir bir güvenlik değerlendirmesine dönüştürür. Modül 1'de kurduğunuz yönetişim/RoE iskeletini burada metodoloji seçimi, tehdit modelleme ve hedef odaklı (objective-based) senaryo kurgusu ile "iş hedefi + ölçüm" diline taşır; belirsizliği yönetmeyi, iddiaları kanıt standardında paketlemeyi ve yöntem seçimini trade-off'larıyla gerekçelendirmeyi merkezine alır.

İleri seviyede fark yaratan şey "doğru aracı bilmek" değil; hangi yaklaşımı neden seçtiğinizi, hangi varsayımlar altında geçerli olduğunu, hangi karşı kanıtın fikrinizi değiştireceğini ve sonucun nasıl denetlenebilir bir çıktıya dönüşeceğini gösterebilmektir.

Bu Modülde Hedeflenen Kazanımlar

Standart metodolojileri (PTES, NIST vb.) "kontrol listesi" değil, belirsizliği yöneten bir süreç iskeleti olarak tasarlamak; gerektiğinde bağlama göre sıkıştırıp genişletebilmek.
Tehdit modellemeyi "tehdit listesi" olmaktan çıkarıp varlıklar, veri sınıfları, güven sınırları ve kontrol varsayımları üzerinden iş riski haritasına dönüştürmek.
MITRE ATT&CK'yi ortak TTP dili olarak kullanıp davranış-kontrol-telemetri bağını kurarak kapsama/boşluk (coverage gap) çıktıları üretebilmek.
Objective-based senaryoları crown jewels odağıyla yazıp ölçülebilir başarı kriterleri, sınırlar (minimum zarar/veri minimizasyonu) ve "durma koşulları"yla denetlenebilir hale getirmek.
Alternatif patika, "assume breach" bakışı ve başarısızlık planlarıyla belirsizliği panikle değil tasarımla yönetmek; noise/FP/operasyonel yük/OPSEC maliyetlerini kararın içine katmak.

1) Metodoloji: "işi yapmak" değil, "işi denetlenebilir yapmak"

Metodoloji, operasyonu süsleyen bir şablon değildir; karar kalitenizi ve çıktının denetlenebilirliğini taşıyan iskelettir. İyi bir iskelet, belirsizlik yükseldiğinde sizi "kanıtsız hız" ile "gösterişli ama ölçümsüz hareket" arasında kaybolmaktan korur.

1.1. Yaşam döngüsü tasarımı: planlama → icra → raporlama → iyileştirme

Birçok çerçeve aynı omurgayı paylaşır: planla, uygula, sonucu kanıta bağla, iyileştirmeye çevir. NIST'in test ve değerlendirme yaklaşımı da bu döngüyü yapılandırmaya yarar; kritik nokta, her fazın "kanıt + karar kaydı" ile taşınmasıdır.

Planlama: hedefler, başarı ölçütleri, risk/yan etki sınırları, iletişim-deconfliction düzeni ve "durma koşulları".
İcra: hipotez temelli ilerleme; her iddiayı bağımsız kanıtla destekleme; gereksiz gürültü ve gereksiz veri temasından kaçınma.
Raporlama: gözlem-yorum ayrımı; varsayımlar ve karşı kanıt arayışı; güven düzeyi (confidence) diliyle tutarlı anlatım.
İyileştirme: bulguyu savunma kontrollerine bağlayıp yol haritasına dönüştürme; bir sonraki döngü için ölçüm metriklerini taşıma.

Örnek: "Erişim kontrolü zayıf" tek cümlelik bir iddia olarak kalırsa, yönetilebilir bir karar üretmez. Aynı iddia; hangi iş sürecini etkilediği, hangi kontrol varsayımının kırıldığı, hangi gözlemle desteklendiği, hangi şartlarda değişeceği ile paketlenirse, rapor "iddialar listesi" olmaktan çıkar, denetlenebilir bir karar dokümanına dönüşür.

Dikkat: Metodoloji, belirsizlik yükseldiğinde "daha çok dene" refleksini değil, "yanlış yola erken dur" disiplinini tetiklemelidir. Hızın bedeli kanıt zinciri kırılıyorsa, o hız genellikle borçtur.

1.2. Kalite kapıları: ileri seviyenin ayrıştırıcısı

İleri seviye süreç, "devam etmek" üzerine değil, yanlışı büyümeden kesmek üzerine kurulur. Bu yüzden her önemli dönemeçte kalite kapıları tanımlanır:

Kapsam kapısı: Bu adım/varlık RoE içinde mi, onaylı mı? (Modül 1 ile uyum)
Kanıt kapısı: Bu iddia hangi gözleme dayanıyor? Alternatif açıklamalar ve karşı kanıt arandı mı?
Risk kapısı: Aynı sonuca giden daha düşük yan etkili/ daha düşük veri teması içeren yöntem var mı?
Belirsizlik kapısı: Varsayımlar yazılı mı? Varsayım kırılırsa plan nasıl değişecek?
Ölçüm kapısı: Bu faaliyet neyi ölçüyor? Başarı/başarısızlık neye göre okunacak?

İpucu: Kalite kapılarını "bürokrasi" gibi değil, maliyet sigortası gibi düşünün. Bir karar "kanıt kapısı"ndan geçmiyorsa, raporda "kesin" cümle kurmak yerine gözlemi doğru tarif ederek güven dilini koruyun.

1.3. Ölçüm planı: senaryonun omurgası

Objective-based bir çalışmada ölçüm, sonradan eklenen süslü bir tablo değil; senaryonun omurgasıdır. Sağlam bir ölçüm planı şunları netleştirir:

Başarı kriteri: "Neyi başardık?" sorusunun ölçülebilir karşılığı
Başarısızlık kriteri: "Neyi başaramadık, bu neyi gösterir?"
Gözlenebilirlik: Sonuç hangi telemetriyle görülecek? (SOC/EDR gerçekliği - modül 12 ile doğal bağ)
Zaman uyumu: ölçüm penceresi, vardiya/operasyon saatleri, deconfliction gerçekliği
Confidence dili: Bu sonuca ne kadar güveniyoruz, hangi koşulda değişir?

İpucu: Ölçümü "not tutma" değil, deney tasarımı gibi kurun. Deneyin ölçümü bozuksa, en doğru teknik hareket bile yanlış sonuca bağlanabilir.

2) Tehdit modelleme: teknik liste değil, iş hedefi haritası

Tehdit modelleme "hangi saldırılar var?" sorusundan önce "neyi koruyoruz, neden değerli?" sorusunu cevaplar. Buradaki hedef, saldırganı romantize etmek değil; saldırı patikalarını iş etkisi ile hizalamaktır.

2.1. Crown jewels, veri sınıfları ve güven sınırları

Crown jewels: kaybı en yüksek iş etkisini doğuracak varlıklar (veri/sistem/süreç).
Veri sınıfı: gizlilik/bütünlük/erişilebilirlik beklentisi farklı olan veri kategorileri.
Güven sınırı (trust boundary): güvenin/yetkinin değiştiği geçiş noktaları; bu sınırlar tehdit modellemede "dikkat" bölgeleridir. Microsoft'un tehdit modelleme rehberleri, güven sınırlarının veri akışları üzerinde özellikle işaretlenmesini ve bu sınırları geçen çağrıların kimlik doğrulama/yetkilendirme gereksinimlerinin düşünülmesini vurgular.

Örnek: Bir üretim tesisinde "üretim sürekliliği" kritik olabilir; ama modellemede asıl değer "hangi rol/akış üzerinden hangi güven sınırları aşılınca" bu kritikliğe erişildiğini görmektir. Senaryo, tek bir "hedef sistem" etrafında değil; yetki zinciri + veri akışı + güven sınırı etrafında yazılır.

2.2. Modelleme yaklaşımı seçimi: bağlama göre çerçeve

İleri seviyede tek bir "doğru" model yoktur; doğru bağlama doğru çerçeve vardır. Aynı problem için farklı çerçevelerin maliyeti/riski değişir:

STRIDE: tehdit kategorilerini sistematik düşünmeye yardımcı olur; özellikle veri akış diyagramı ve güven sınırları üzerinden tehditleri sınıflandırmayı kolaylaştırır.
PASTA: süreç odaklı, saldırı simülasyonu ve analiz hattını yapılandırmaya çalışan bir threat modeling yaklaşımıdır; "analizi adımlara bölerek" tutarlılık sağlar, ancak kurumdan veri/katılım/operasyonel zaman ister.
OCTAVE: kurumun siber risk yönetimine yaklaşım sağlayan, varlık-tehdit-zafiyet ilişkisini organizasyon bağlamında ele alan bir yaklaşımdır.
DREAD (ve benzeri skorlamalar): hızlı önceliklendirme sağlar; ancak sayısal skorun "kesinlik" hissi üretmesine dikkat etmek gerekir-skor, kanıt değildir; kanıtı özetleyen bir araçtır.

Burada kritik olan, çerçeve adını ezberlemek değil; şu üç soruya cevap vermektir:

Bu çerçeve, hangi tür belirsizliği yönetmeme yardım ediyor?
Bu çerçeve, kanıt zincirini daha mı güçlendiriyor yoksa "etiketleme" kolaylığı mı sağlıyor?
Operasyonel yük/noise/FP maliyeti ve paydaş koordinasyonu açısından en az yan etkiyle hangi seçimi yapabilirim?

2.3. Kontrol varsayımları: "kontrol var" bir iddiadır

Kurumlar çoğu zaman farkında olmadan "varsayımlar" taşır:

"MFA varsa hesap ele geçirilmez."
"Segmentasyon varsa yatay hareket olmaz."
"Log var, görüyoruz."

Bu cümleler şartlı olabilir. İleri seviye yaklaşım, şartları görünür kılar ve ölçer:

Kontrol hangi davranışı engellemeli/tespit etmeli?
Bu davranışın hangi telemetride görünmesi beklenir?
Görünmüyorsa boşluk nerede: log üretimi mi, toplama mı, korelasyon mu, triage mı?

Dikkat: "Kontrol var" demek, doğrulanmamış bir iddiadır. İleri seviye dil, kontrolün adını değil; kontrolün beklenen etkisini ve bu etkinin gözlenebilirliğini taşır.

2.4. Hipotez temelli ilerleme: karşı kanıtı arayan plan

Tehdit modelleme iyi bir senaryoda "tek doğru yol" üretmez; hipotezler üretir. Hipotez, doğrulanabilir bir iddiadır: "Şu güven sınırında şu kontrol boşluğu olabilir."

Hipotezi kanıt standardına çeviren akış:

Gözlem: Ne gördük?
Yorum: Bu ne anlama geliyor?
Varsayım: Hangi şartlarda geçerli?
Karşı kanıt: Bunu yanlışlayacak ne olabilir?
Güven düzeyi: Neden bu seviyede; hangi koşulda değişir?

İpucu: "Doğru çıkarsa ne olur?" kadar "yanlış çıkarsa ne öğrenirim?" sorusunu da yazın. Bu, başarısızlık planlarını güçlendirir ve operasyonu teknik şovdan ölçüme çeker.

3) MITRE ATT&CK: ortak TTP dili, kapsama boşluğu ve zincirleme düşünme

MITRE ATT&CK, gerçek dünyadaki saldırgan davranışlarını "taktikler ve teknikler" olarak sınıflayan, savunma planlama ve ölçüm için kullanılan bir bilgi tabanıdır. İleri seviye kullanımı "hangi kutucuklar işaretli?" sorusundan çok "bu davranışlar nasıl bağlanıyor, hangi kontrol katmanı test ediliyor, kanıt nerede?" sorusuna dayanır.

3.1. Taktik-teknik-prosedür ayrımı

Taktik: amaç kategorisi (neden?)
Teknik: davranış sınıfı (ne tür davranış?)
Prosedür: bu ortamda davranışın gözlenen tezahürü (kuruma özgü)

İleri seviyede ATT&CK, raporda "etiket süsü" değil; gözlem → sınıflandırma → kontrol/telemetri bağı kuran bir çeviri katmanıdır (modül 17'de raporlama diliyle birleşir).

3.2. Coverage gap ve "ısı haritası" mantığı

Haritalama iyi yapıldığında şu çıktıları üretir:

"Bu davranış nerede görünmeliydi?"
"Hangi kontrol devreye girmeliydi?"
"Görünmediyse boşluk nerede: üretim mi, toplama mı, korelasyon mu?"

ATT&CK Navigator gibi araçlar, katman (layer) mantığıyla coverage/gap analizlerini görselleştirmeyi kolaylaştırır; aynı zamanda "hangi davranış ailesi hiç test edilmemiş?" sorusuna hızlı yanıt verir.

Dikkat: Navigator katman dosyaları, içerikleri itibarıyla hassas olabilecek veriler taşıyabilir; hassas dosyaları paylaşma/saklama politikaları ve çalışma biçimi senaryo tasarımının bir parçası olmalıdır.

3.3. Kanıt standardı: etiketlemek kolay, doğrulamak zor

ATT&CK etiketleri "kesinlik" hissi üretebilir. Bu yüzden disiplin şudur:

Bir tekniği "uygulandı" diye yazmadan önce kanıtını ve alternatif açıklamaları düşün.
Kesin değilse, etiketi "dayatmak" yerine gözlemi doğru kur:
"Şu davranış gözlendi; şu teknik ailesiyle tutarlı olabilir; şu karşı kanıt görülürse değerlendirme değişir."

4) Objective-based senaryo kurgusu: iş riskini merkeze alan tasarım

Geleneksel testlerde "yetki kazanmak" başarı gibi algılanabilir; objective-based yaklaşımda yetki çoğu zaman araçtır, amaç değildir. Pusula, crown jewels ve iş etkisidir.

4.1. Senaryo ile "attack plan" arasındaki fark

Senaryo: iş hedefi, tehdit hikâyesi, ölçüm, sınırlar, varsayımlar ve kanıt standardını taşıyan üst seviye kurgudur.
Teknik icra planı: senaryonun nasıl uygulanacağına dair ayrıntıların alanıdır; bu eğitim formatında operasyonel "how-to" verilmez.

Bu ayrım, hem etik sınırı korur hem de raporlamada "neden/neyi ölçtük?" anlatısını güçlendirir.

4.2. Objective tanımı: ölçülebilirlik + sınır disiplini

İyi objective tanımı şu parçaları taşır:

Hedef varlık/süreç: neyi test ediyoruz?
Başarı kriteri: nasıl anlayacağız?
Sınırlar: minimum zarar, veri minimizasyonu, kapsam çizgileri
Ölçüm: hangi sinyallerle/telemetriyle ölçüyoruz?
Belirsizlik: hangi varsayımlarda geçerli, hangi durumda revize?

Örnek: "Kritik verilere erişim mümkün mü?" fazla geniştir. Daha iyi bir kurgu, belirli bir iş rolü/iş akışı üzerinden "yetkisiz görüntüleme riskinin" ölçülmesine odaklanır; kanıt üretimi veri içeriğini taşımadan, yalnızca gerekli minimum göstergelerle yapılır (ör. erişimin gerçekleştiğini gösteren izlenebilir kayıtlar ve maskeleme ilkeleri).

4.3. Başarı kriteri: metrik + ispat + yorum

İleri seviyede başarı kriteri üç katmanda ayrıştırılır:

İspat (kanıt): gözlemler ve izlenebilirlik
Metrik: süre, kapsama, tespit/yanıt kalitesi gibi ölçüler (kuruma göre)
Yorum: iş etkisi ve öncelik (varsayımlar ve karşı kanıtla birlikte)

Bu ayrım "ölçtüm" ile "yorumladım" çizgisini netleştirir; raporun denetlenebilirliğini artırır.

4.4. Senaryo paketi: denetlenebilirlik için asgari parçalar

Objective + başarı/başarısızlık kriterleri
Varsayımlar + değişim şartları
Ölçüm planı + zaman penceresi
İletişim/deconfliction düzeni (Modül 1'e uyum)
Kanıt standardı, gizlilik ve veri minimizasyonu kuralları
Durma koşulları (risk kapısı tetikleyicileri)
Rollback/temiz bırakma planı

5) Alternatif patikalar, "assume breach" ve başarısızlık planları

Gerçek hayatta planlar nadiren kusursuz işler. Bu modülde ileri seviye bakış, "tek yol" yerine patika portföyü üretmek; belirsizliği panikle değil tasarımla yönetmektir.

5.1. Aynı hedef, farklı maliyetler: yöntem seçimi

Bir hedefe giden yolların maliyetleri farklıdır:

Noise: savunmayı gereksiz alarm bombardımanına boğma riski
Yan etki: iş sürekliliği ve veri teması riski
Operasyonel yük: koordinasyon, iz yönetimi, raporlama karmaşıklığı
OPSEC/etik sınır: ölçümü bozacak veya riski büyütecek davranışlar
FP riski: yanlış pozitif sinyallerin "başarı" gibi yorumlanması

İleri seviye seçim çoğu zaman "en hızlı" değil, en az yan etkili ve en denetlenebilir yoldur; çünkü hedef yalnız sonuç değil, sonucu öğretilebilir bir çıktıya dönüştürmektir.

5.2. Başarısızlık planı: başarısızlık da veri üretmelidir

Başarısızlık planı "başaramazsak bitti" değildir; "başaramazsak hangi kontrolün güçlü çıktığını veya hangi varsayımın yanlış olduğunu kanıtlayacağız?" demektir:

Varsayım kırılırsa senaryo nasıl revize edilir?
Hangi noktada durulur ve kapsam yeniden netleştirilir?
Ölçümü korumak için hangi alternatif objective/ölçüm devreye girer?
Kanıt zinciri bozulmadan nasıl devam edilir?

Örnek: Bir patika erken "dur" gerektiriyorsa bu her zaman başarısızlık değildir; çoğu zaman RoE ve minimum zarar disiplininin doğru çalıştığını gösterir. Asıl çıktı, durma kararının kanıtı, gerekçesi ve ölçüm etkisidir.

5.3. "Assume breach": savunma dayanıklılığı için gerçekçi varsayım

"Assume breach", tek bir çevre kontrolüne aşırı güvenmek yerine katmanlı savunma düşüncesini besleyen bir ilkedir; "bazı kontrollerin aşılabileceğini varsayarak" iç katmanların tespit/yanıt kabiliyetini de ölçmeye zorlar. Bu, özellikle dış çevrenin beklenenden güçlü çıktığı veya zaman penceresinin daraldığı durumlarda, onaylı başlangıç noktaları ile senaryonun ölçüm hedefini korumaya yarar-ama her durumda RoE, paydaş onayı ve minimum zarar ilkeleri belirleyicidir.

Terimler Sözlüğü

Terim	Açıklama
PTES	Penetration Testing Execution Standard; sızma testini fazlara ayıran yürütme yaklaşımı
NIST SP 800-115	Bilgi güvenliği test ve değerlendirmesi için teknik rehber (fazlar, raporlama ve değerlendirme yaklaşımı)
MITRE ATT&CK	Saldırgan davranışlarını taktik/teknik olarak sınıflayan bilgi tabanı
ATT&CK Navigator	ATT&CK üzerinde kapsama/boşluk (coverage/gap) analizini katmanlarla görselleştirmeye yarayan araç
TTP	Taktik, teknik ve prosedür; davranışı ortak dille anlatma biçimi
Tactic	Taktik; amaç kategorisi (neden?)
Technique	Teknik; davranış sınıfı (ne tür davranış?)
Procedure	Prosedür; davranışın belirli ortamda gözlenen tezahürü
Threat model	Tehdit modeli; varlıklar, güven sınırları ve kontrol varsayımlarıyla risk resmini kurma
Trust boundary	Güven sınırı; yetki/güvenin değiştiği geçiş noktası
Crown jewels	Kritik varlıklar; kaybı en yüksek iş etkisini doğuran varlık/süreç/veri
STRIDE	Tehditleri kategorize eden yaklaşım: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege
PASTA	Process for Attack Simulation and Threat Analysis; süreç odaklı threat modeling yaklaşımı
OCTAVE	Operationally Critical Threat, Asset, and Vulnerability Evaluation; risk yönetimi odağında yaklaşım
DREAD	Risk puanlama yaklaşımı; hızlı önceliklendirme için kullanılır (kanıtın yerine geçmez)
Objective-based	Hedef odaklı; senaryoyu iş hedefi ve ölçüm üzerinden kurma yaklaşımı
Coverage gap	Kapsama boşluğu; beklenen kontrol/telemetri ile gerçekteki kapsama arasındaki fark
Heatmap	Isı haritası; kapsama/boşlukların görsel temsili
Baseline	Başlangıç çizgisi; ölçümün kıyaslanacağı referans durum
Hypothesis	Hipotez; doğrulanabilir iddia/varsayım seti
Confidence	Güven düzeyi; sonucun eminliği ve gerekçesi, hangi şartlarda değişeceği
Deconfliction	Çakışma önleme; operasyon sırasında paydaşlar arası koordinasyon ve güvenli sürdürme
OPSEC	Operasyon güvenliği; bilgi/sinyal sızıntısı ve yan etki risklerini sınırlama
Noise	Gürültü; gereksiz dikkat/alarm üretimi maliyeti
False Positive (FP)	Yanlış pozitif; “bulgu” gibi görünen fakat doğrulanmayan sinyal
Rollback	Geri alma/temiz bırakma; operasyonun ortamı hijyenik ve güvenli bırakacak şekilde sonlandırılması
Assume breach	İhlal kabulü; kontrollerin aşılabileceğini varsayarak katmanlı savunma dayanıklılığını ölçme yaklaşımı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Uçtan uca metodoloji tasarımında “kalite kapıları” yaklaşımının ileri seviye gerekçesi hangisidir?

A) Operasyonu yavaşlatıp daha az çıktı üretmek

B) Belirsizlik yükseldiğinde kanıtsız kararları ve scope creep’i erken kesmek

C) Yalnızca rapor formatını standartlaştırmak

D) Süreci karmaşıklaştırarak “daha profesyonel görünmek”

E) Teknik derinliği azaltmak

Doğru: B
Gerekçe: Kapılar, belirsizlik ve risk yükseldiğinde yanlış maliyet büyümeden durmayı sağlar. A/C/E hedefi ıskalar; D hem etik hem de ölçüm kalitesi açısından yanlıştır.

2) Tehdit modellemenin “tehdit listesi” olmaktan çıkıp “iş hedefi haritası”na dönüşmesini en iyi anlatan ifade hangisidir?

A) Saldırı türlerini alfabetik listelemek

B) Varlık, veri sınıfı ve güven sınırlarını iş etkisiyle birlikte modellemek

C) Sadece zafiyet tarama çıktısını sınıflandırmak

D) ATT&CK teknik isimlerini rapora eklemek

E) “Her şey kritik” varsayımıyla tek senaryo yazmak

Doğru: B
Gerekçe: İleri seviye modelleme “ne/nerede/neden değerli?” sorusuna güven sınırları üzerinden cevap verir. A/C/D yüzeysel kalır; E ölçümü bozar.

3) “Kontrol var” iddiasını ileri seviye doğrulama mantığına en doğru bağlayan yaklaşım hangisidir?

A) Kontrolün adını yazmak yeterlidir

B) Kontrolün hangi davranışı hangi telemetriyle yakalaması beklendiğini tanımlayıp gözlenebilirlik üzerinden doğrulamaya çalışmak

C) Kontrol üreticisinin broşürünü referans almak

D) Belirsizliği azaltmak için raporda kesin konuşmak

E) Kontrolün varlığını “güvenilir varsayım” saymak

Doğru: B
Gerekçe: Kanıt standardı, davranış–telemetri–kontrol bağını kurmayı gerektirir. A/C/E kanıt üretmez; D doğruluk ve güven dili disiplinini bozar.

4) MITRE ATT&CK’yi raporda “etiket” olmaktan çıkaran en kritik disiplin hangisidir?

A) Mümkün olduğunca çok teknik etiketi eklemek

B) Etiketleri yalnızca gözlem–kanıt–alternatif açıklama ayrımı netse kullanmak; değilse gözlemi doğru dille ifade etmek

C) Sadece taktik seviyesinde yazmak, teknikleri hiç anmamak

D) Prosedürü ayrıntılandırıp operasyonel “how-to” vermek

E) Etiketleri raporun başına tek tabloda koyup açıklama yapmamak

Doğru: B
Gerekçe: ATT&CK’nin değeri kanıtla taşındığında artar. A/E yüzeysel; C eksik; D eğitim/etik sınırlarla uyumsuzdur.

5) Objective-based senaryoda başarı kriterinin “metrik + ispat + yorum” diye ayrıştırılmasının temel faydası hangisidir?

A) Raporu daha uzun yapmak

B) Ölçüm ile yorumu karıştırmayı önlemek ve varsayımları görünür kılmak

C) Sadece teknik ekibin ilgisini çekmek

D) Başarısızlığı gizlemek

E) Operasyonu daha agresif yapmak

Doğru: B
Gerekçe: Denetlenebilirlik ve doğruluk disiplinini artırır. A/C/E alakasız; D etik dışıdır.

6) Aşağıdaki objective tanımlarından hangisi ölçülebilirlik + sınır disiplini açısından en güçlü yaklaşıma en yakındır?

A) “Sisteme girilecek.”

B) “Kritik verilere erişim test edilecek.”

C) “Belirli bir iş rolü/akış üzerinden kritik varlık temas riski, veri minimizasyonu ve kanıt standardıyla değerlendirilecek; başarı kriteri ve ölçüm penceresi tanımlı olacak.”

D) “Ne olursa olsun hedefe ulaşılacak.”

E) “Kapsam operasyon sırasında netleşecek.”

Doğru: C
Gerekçe: C; hedef–ölçüm–sınır–kanıt dengesini birlikte taşır. A/B belirsiz; D RoE/minimum zarar mantığına aykırı; E scope creep’i teşvik eder.

7) Alternatif patika tasarımında doğru trade-off yaklaşımı hangisidir?

A) En hızlı yol her zaman en iyisidir

B) En gürültülü yol savunmayı test ettiği için her zaman tercih edilir

C) Gürültü/yan etki/operasyonel yük/etik sınır maliyetleri ile ölçüm değeri birlikte değerlendirilir

D) Alternatif patika, başarısızlığın kanıtıdır

E) Alternatif patikalar yalnızca “araç çeşitliliği” için yazılır

Doğru: C
Gerekçe: İleri seviye seçim, “sonuç” kadar “ölçüm kalitesi ve risk” dengesidir. A/B kör optimizasyon; D yanlış; E yüzeyseldir.

8) Başarısızlık planının doğru rolü hangisidir?

A) Başarısızlık olursa raporu yazmamak

B) Başarısızlığı, kontrol gücü/varsayım doğruluğu hakkında kanıt üreten bir çıktıya çevirmek

C) Başarısızlık ihtimalini sıfırlamak için kapsamı genişletmek

D) Belirsizliği azaltmak için her sonuca “yüksek güven” yazmak

E) Deconfliction’ı tamamen kaldırmak

Doğru: B
Gerekçe: Başarısızlık planı, belirsizliği yönetir ve öğrenmeyi sürdürür. A/C/D/E ölçüm, etik ve yönetişim hedefleriyle uyumsuzdur.

9) Dış çevreyi aşma varsayımı beklenenden güçlü çıktı; zaman penceresi daralıyor. Objective hâlâ kritik. İleri seviye, yönetişimle uyumlu sonraki adım hangisine en yakındır?

A) Aynı yolu daha agresif denemek ve paydaşlara söylememek

B) Amaç ne olursa olsun gürültüyü artırmak; “savunma test olur” diye düşünmek

C) RoE ve paydaş onayıyla, ölçüm hedefini koruyacak onaylı alternatif başlangıç yaklaşımını (assume breach benzeri) devreye almayı değerlendirmek; kabul edilmezse durma koşulunu işletmek

D) Kapsamı tek taraflı genişletip yeni hedefler eklemek

E) Operasyonu “başarısız” sayıp kanıt üretmeden kapatmak

Doğru: C
Gerekçe: C; amaç–ölçüm–yönetişim dengesini korur ve belirsizliği dürüstçe yönetir. A/B/D etik ve RoE açısından sorunludur; E ölçüm ve kanıt üretimini yarım bırakır.

10) Aşağıdakilerden hangisi “senaryo” ile “teknik icra planı” arasındaki farkı en iyi açıklar?

A) Senaryo, iş hedefleri/varsayımlar/ölçüm ve sınırları içeren üst seviye kurgudur; teknik icra planı bu kurgunun uygulanmasına dair ayrıntıların alanıdır

B) Senaryo teknik, plan idari belgedir; aralarında değer farkı yoktur

C) Teknik icra planı müşteriden tamamen gizlenmelidir

D) Senaryo yalnız sunumlarda kullanılır; operasyonle ilgisi yoktur

E) İkisi tamamen aynıdır; farklı isimlerdir

Doğru: A
Gerekçe: Senaryo “ne ve neden”i taşır; icra planı “nasıl” ayrıntılarına iner. B/C/D/E, denetlenebilirlik ve iletişim hedefini kaçırır.

Bu Modülde Kazanılan Yetkinlikler

Metodolojinin, belirsizlik yükseldiğinde kararları kanıt standardında tutan bir "süreç iskeleti" olduğunu; kalite kapılarıyla yanlış maliyeti büyümeden kesmeyi.
Tehdit modellemenin, crown jewels ve güven sınırları üzerinden iş hedefi + kontrol varsayımı dilinde kurulması gerektiğini.
STRIDE/PASTA/OCTAVE gibi çerçeveleri ezberlemekten çok, bağlama göre yöntem seçmenin trade-off'larını (noise/FP/operasyonel yük/etik) düşünmeyi.
ATT&CK'nin TTP dilini kanıtla birleştirip coverage/gap analizine dönüştürmeyi; etiketi "kesinlik" yerine "izlenebilirlik" için kullanmayı.
Objective-based senaryoda hedef-ölçüm-sınır-belirsizlik yönetimini tek pakette tutmayı; alternatif patika ve başarısızlık planlarıyla öğrenmeyi sürdürmeyi.

MODÜL 3 — Gelişmiş Recon ve OSINT

Modül Teması

Pasif Keşif

DNS, sertifika, leak ve metadata madenciliği.

Aktif Keşif

Subdomain, port ve hizmet topolojisi.

Pivotlama

Kişi → kurum → varlık ilişkisinin haritalanması.

Recon ve OSINT, ileri seviye Red Team & Pentest'te "daha çok veri toplama" yarışı değildir; doğru soruyu doğru kanıtla cevaplama disiplinidir. Modül 2'de kurulan senaryo, tehdit modelleme ve hedef odaklı yaklaşım; bu modülde pasif sinyaller üzerinden doğrulanmış, izlenebilir ve raporlanabilir bir saldırı yüzeyi envanterine dönüşür. Amaç, sonraki aşamalara (özellikle modül 4'teki scanning/enumeration kararlarına) gürültü üretmeden yön verebilen, belirsizliği doğru yöneten ve savunma iyileştirmesine bağlanabilen bir keşif çıktısı üretmektir.

Bu Modülde Hedeflenen Kazanımlar

Ham sinyali, çok kaynaklı doğrulama ve karşı kanıt arayışıyla kanıt standardında bulguya dönüştürmek.
Bir varlığın gerçekten hedefle ilişkili olup olmadığını "etiketlemek" yerine kanıt zinciriyle ilişkilendirmek (asset attribution).
Yatay/dikey keşif mantığıyla; iştirakler, birleşme/satın alma izleri, kampanya alan adları ve gölge BT gibi genişletilmiş yüzeyi kapsayan bir harita kurmak.
Sızıntı verisi ve kimlik izlerini "sisteme girmek" için değil, risk varsayımlarını modellemek için kullanmak; tazelik ve kalite değerlendirmesi yapmak.
Tedarik zinciri / üçüncü taraf bağımlılıklarını (SaaS/PaaS dahil) görünür kılıp dolaylı risk vektörlerini çıkarmak.
Bulut ayak izini aktif tarama yapmadan pasif göstergelerle anlayıp, yöntem seçimi + sınırlar (noise/FP/OPSEC/etik) dengesini kurmak.

1) Recon'u ileri seviyeye taşıyan zihniyet: "bulgu" değil, "kanıtlanmış iddia"

İleri seviye Recon, küçük bir araştırma projesi gibi yürür: hipotez kurarsın, veri toplarsın, karşı kanıt ararsın, ardından sonucunu gerekçeli bir confidence diliyle paketlersin. Burada kritik ayrım şudur:

Kaynak: Sinyalin geldiği yer (kamu kaydı, arşiv, sertifika izi, ilan, teknik doküman vb.)
İddia: "Şu varlık hedefe aittir / şu bağımlılık vardır / şu risk varsayımı zayıftır" gibi yorum
Kanıt: İddiayı destekleyen ve denetlenebilir şekilde izlenebilen sinyaller bütünü

Örnek: "Müşteri portalı kritik" ise soru "neresi açık?" değildir. Daha olgun soru şudur: "Bu portalın kimlik akışı ve üçüncü taraf bağımlılıkları dışarıdan hangi kanıtlarla anlaşılabilir; hangi güven sınırları var; bu varsayımlar hangi riskleri doğuruyor?"

Dikkat: "Bir yerde okudum" ileri seviyede kanıt değildir. Eski/bağlamı kopmuş içeriklerle yanlış pozitif üretmek kolaydır; yanlış pozitif, sonraki modüllerde gereksiz aktivite, gereksiz görünürlük ve güven kaybı demektir.

2) Kalite kapıları: Recon'u gürültüye boğmadan yönetmek

İleri seviyede en büyük risk, Recon'un "sonsuz araştırma"ya dönmesidir. Bunu engelleyen şey, her adımda çalışan kalite kapılarıdır:

İddia kapısı: "Tam olarak ne iddia ediyorum?"
Kanıt kapısı: Aynı iddia en az iki bağımsız sinyalle destekleniyor mu?
Karşı kanıt kapısı: Bu iddiayı yanlışlayacak alternatif açıklamalar neler, aradım mı?
Tazelik kapısı: Sinyal güncel mi, bağlamı bugüne taşınıyor mu?
Yan etki kapısı: Bu bilgiye ulaşmanın daha düşük riskli yolu var mı?
Sınır kapısı: Scope / etik / OPSEC çizgisi korunuyor mu?

İpucu: "Zaman damgası" refleksini bir alışkanlık gibi uygula. Tarihi belirsiz sinyaller, en fazla düşük confidence ile taşınır; aksi halde rapor "kesin" konuşur ama dayanağı zayıf kalır.

3) Pasif-yarı pasif-aktif çizgisi: yöntem seçimi ve sınırlar

Recon/OSINT, çoğu zaman "pasif" diye düşünülür; oysa pratikte bir spektrum vardır. Bu spektrum, sadece teknik değil operasyonel bir karardır:

Tam pasif: Arşivler, kamu kayıtları, indeksler, daha önce toplanmış veri setleri üzerinden çalışma. Hedef altyapıyla doğrudan etkileşim beklenmez.
Yarı pasif: Normal internet trafiğine benzeyen, düşük yoğunluklu etkileşimler (ör. sıradan isim çözümleme davranışına benzeyen sorgular). Burada kritik kırılma noktası yoğunluk ve desendir: normalin dışına çıktıkça iz bırakma/noise artar.
Aktif: Hedefle doğrudan etkileşimi artıran, savunma ekiplerince kolay etiketlenebilen faaliyetler. Bu tür adımların tradecraft'i modül 4'te strateji düzeyinde ele alınır; bu modülde amaç, aktif taramaya "ne zaman ve neden" karar verileceğini temellendirmektir.

Örnek: Bir teknolojiyi anlamak için iki yol düşün:

Bir yol, hedefe dönük daha görünür teknik etkileşimler gerektirebilir (yüksek noise/OPSEC maliyeti).
Diğer yol, geçmiş kayıtlar, kamu metaverileri veya bağımlılık izleri üzerinden çıkarım yapabilir (daha sessiz ama bazen daha az derin).

İleri seviye yaklaşım, "en hızlı"yı değil, en doğru maliyet/riski seçer.

İpucu: Yöntem seçimini bir "maliyet tablosu" gibi düşün: doğruluk kazancı ↔ operasyonel yük ↔ false positive riski ↔ noise/OPSEC maliyeti. En iyi seçenek, her hedefte aynı olmaz.

4) Dış saldırı yüzeyi envanteri: liste değil, ilişki grafiği

Bu modülde amaç, varlıkları "tek tek saymak" değil; varlıklar arasında ilişki kurmaktır. Çünkü modern kurumlar izole adalar değildir: birleşme/satın alma, taşeronlar, SaaS/PaaS ve kampanya varlıkları yüzeyi sürekli genişletir.

4.1. Yatay ve dikey keşif: sadece "alt alan adı" değil

Geleneksel yaklaşım dikey keşfe (ör. api.example.com, dev.example.com) takılı kalabilir. İleri seviyede buna ek olarak yatay keşif de gerekir:

İştirak/bağlı şirket alan adları
Satın alınmış şirketlerin kalıntı varlıkları
Kampanya/mikrosite alan adları
Departmanların BT onayı dışında kullandığı gölge BT izleri

Bu, "saldırı yüzeyi büyüdü" demekten daha önemlidir: savunmanın kontrol varsayımlarını test eder. Örneğin, merkez BT sıkıysa bile bir kampanya varlığı zayıf süreçle açılmış olabilir.

4.2. Varlık ilişkilendirme (asset attribution): iddiayı kanıtla bağlamak

Bir alan adı, IP veya servis izi bulmak tek başına bir şey ispatlamaz. İleri seviye disiplin, "bu hedefe ait" iddiasını kanıt zinciriyle kurar. Kullanılan kanıt sınıfları şunlardır (tamamı "tek başına değil", birlikte anlamlıdır):

Ağ sahipliği/rota kümelenmesi (ASN gibi) göstergeleri: İpucu verir ama özellikle bulut/CDN çağında tek başına güçlü kanıt değildir.
Sertifika kimliği (SSL/TLS): Sertifika alanları (ör. SAN) bazen bir servisin hangi alan adlarıyla ilişkilendiğine dair güçlü sinyal üretir; yine de bağlam/tazelik kontrolü gerekir.
Kayıt/tescil ilişkileri (reverse WHOIS/DNS mantığı): Ortak tescil temaları veya yönetim izleri ilişkilendirmeyi güçlendirebilir; ancak gizlilik/proxy kullanımında zayıflayabilir.
Uygulama parmak izi benzerliği (ör. favicon hash gibi): Tek başına "kesin" değil; tutarlılık göstergesi olarak değerlidir.

Dikkat: Bulut ve CDN dünyasında "IP adresine dayalı ilişkilendirme" yüksek hata oranına açıktır. Aynı IP bloğu farklı müşterilere dinamik tahsis edilebilir. İleri seviye uzman, IP'yi değil servisin kimliğini ve ilişkilendirme kanıtlarını tartar.

4.3. Pasif teknoloji izleri: port taraması olmadan çıkarım (kavramsal)

Bir kurumun teknoloji ekosistemi bazen dışarıdan "sistemle doğrudan etkileşmeden" de anlaşılabilir:

İş ilanları, içerideki süreçler ve kullanılan platformlar için güçlü sinyal üretir; ama "%100 kesin" diye raporlamak yerine, ilanların tazeliği ve kapsamıyla confidence ayarlanmalıdır.
Geliştirici topluluk izleri (ör. kod ekosistemi, teknik yazılar) teknoloji tercihleri hakkında ipucu verir; ancak kişisel veri minimizasyonu ve yanlış çıkarım riskine dikkat edilmelidir.

5) OSINT kaynakları: birincil-ikincil sinyal, tazelik ve çapraz doğrulama

OSINT'te sorun çoğu zaman "kaynak yokluğu" değil, fazla kaynaktır. Bu yüzden iki refleks sürekli çalışır:

— Birincil sinyali aramak: resmî metinler, kamu kayıtları, mekanik izler (sertifika şeffaflığı kayıtları gibi).
— İkincil sinyali "ipucu" olarak görmek: blog derlemeleri, haber tekrarları, yorumlar. Bunlar tek başına bulgu sayılmaz; doğrulama ister.

5.1. Arşiv ve tarihsel izler: bugün görünmeyeni dün gösteren pencere

Arşiv kaynakları, kurumların "silsek de iz kalır" gerçeğini yansıtır. Burada ileri seviye değer; güncel açık aramak değil, tarihsel yüzey üzerinden süreç zafiyetlerini anlamaktır.

Örnek: Bir arşiv kaydında görülen eski bir sayfa/rehber, bugün yayında olmayabilir; ancak kurumun geçmişte hangi varsayımlarla hareket ettiğini ve hangi kontrolleri ihmal etmiş olabileceğini gösterebilir. Bu, savunma için "kontrol sürekliliği" dersidir.

6) Sızıntı verisi ve kimlik izi analizi: "girmek için değil, riski kanıtlamak için"

Sızıntı verileri saldırganlar için fırsat olabilir; profesyonel ve izinli değerlendirmede ise amaç kimlik ve erişim riskini modellemektir. İleri seviyede üç şey birlikte ele alınır:

6.1. Veri kalitesi: gerçek mi, güncel mi, bağlamı ne?

Tazelik: Eski bir sızıntıdaki parolanın bugün geçerli olma olasılığı düşebilir; ama parola politikası ve kullanıcı alışkanlıkları hakkında sinyal üretebilir.
Yapı: Parola verisi düz metin mi, hash mi? Hash ise tuzlama (salt) var mı? Bu, kurumun geçmiş kriptografik hijyenine dair çıkarım üretir; fakat "kırılamaz" gibi kesin sonuçlar yazılmaz.
Karşı kanıt: Veri seti manipüle edilmiş olabilir; örneklem tutarlılığı, format ve kaynak soyu sorgulanır.

6.2. Kimlik izi (identity pattern): standartlar ve risk varsayımları

Kurumların kullanıcı adı/e-posta standartları çoğu zaman tahmin edilebilir kalıplara sahiptir. Bu, profesyonel raporda "saldırıya nasıl çevrilir" diye anlatılmaz; bunun yerine şu şekilde değerlendirilir:

Kurumsal kimlik standardı dışarıdan kolay çıkarım üretiyor mu?
Bu standardın görünürlüğü, kimlik doğrulama kontrolleri ve kullanıcı eğitimleriyle dengelenmiş mi?
Aynı kullanıcıların farklı ekosistemlerde tekrar eden alışkanlıkları, hangi risk varsayımlarını zayıflatıyor?

Örnek: <ad.soyad@example.com> gibi bir standardın dışarıdan görünür olması tek başına "zafiyet" değildir; risk, bunu dengeleyen kontroller (MFA zorunluluğu, anomali tespiti, parola hijyeni) zayıfsa artar. Bu bağ, modül 12'deki tespit perspektifine de doğal köprü kurar.

Dikkat: Sızıntı verisiyle ilgili her ifade, etik ve yasal sınırlar içinde kalmalı; kişisel veri minimizasyonu yapılmalı ve gereksiz detay rapora taşınmamalıdır.

7) Tedarik zinciri ve üçüncü taraf bağımlılıkları: dolaylı risk vektörleri

Modern kurumun saldırı yüzeyi, kendi alan adının dışına taşar. Bu modülde hedef; "hangi sağlayıcıyı kullanıyorlar?" listesinden çok, hangi akışlar üçüncü tarafa dayanıyor ve hangi varsayımlar riskli? sorusunu kanıt zinciriyle cevaplamaktır.

7.1. Bağımlılık haritalama: işaretler ve yorum disiplini

E-posta altyapısı, isim sunucuları ve web üzerindeki üçüncü taraf kaynak çağrıları; kurumun tedarik zinciri bağımlılıklarına dair ipuçları üretebilir.
Bu ipuçları "kanıt" değildir; iddiayı güçlendirmek için farklı sınıftan sinyallerle doğrulanır.

Örnek: Bir bağımlılık iddiasını "yüksek confidence" seviyesine taşımak için, tek bir işaret yerine (örn. bir yönlendirme izi) bunu destekleyen başka sinyallerin de tutarlı olması beklenir.

7.2. Neden önemli: kontrol sınırı nerede bitiyor?

Üçüncü taraf bağımlılıklar, kontrolün bir kısmını kurum dışına taşır. Bu durum:

olay müdahalesi/iletişim süreçlerini,
kimlik yönetimi varsayımlarını,
izleme/telemetri erişimini doğrudan etkiler.

Bu nedenle Recon çıktısı, savunmaya "hangi bağımlılıklar için hangi iz/telemetri şart?" diye geri besleme vermelidir.

8) Bulut ayak izi OSINT: tenant izleri ve pasif misconfiguration sinyalleri (kavramsal)

Bulut sağlayıcıları IP bloklarını yayımlar; fakat hangi IP'nin hangi müşteriye ait olduğunu doğrudan söylemez. İleri seviye yaklaşım, aktif tarama yapmadan tenant izlerini anlamaya çalışır ve yalnızca anlamlı sinyaller üzerinde doğrulama kurar.

8.1. İsimlendirme ve doğrulama: "varlık var mı?" sorusuna temkinli yaklaşım

Bulut depolama ve servis uçları bazen kurumsal isimlendirme kalıpları taşır. Burada kritik nokta şudur: isim kalıbı tek başına kanıt değildir; ancak bazı yanıt sınıfları "varlık mevcut olabilir" sinyali verebilir.

Örnek: Yetkisiz bir isteğin "varlık yok" ile "varlık var ama yetki yok" arasında farklı yanıt ürettiği senaryolarda, bu ayrım salt teknik bir ayrıntı değil; varlık keşfi ile yetki analizi arasındaki sınırın nerede başladığını gösterir. Yetki analizi ve operasyonel takip, kapsam gereği daha sonraki modüllerin karar alanıdır.

8.2. Federasyon ve doğrulama kayıtları: kimlik yönetimi nerede?

Bazı kurumlar bulut kimlik/federasyon doğrulaması için DNS üzerinde doğrulama kayıtları bırakabilir. Bu tür izler, kimlik yönetiminin buluta taşınmış olabileceğine dair birincil sınıfa yakın sinyal üretir; yine de tazelik ve bağlam doğrulamasıyla rapora girer.

8.3. Sertifika şeffaflığı (CT) kayıtları: erken sinyal, erken hata riski

Sertifikalar çoğu zaman servisler tam görünür hale gelmeden önce alınabilir. CT kayıtları bu nedenle "erken uyarı" sinyali üretebilir; ama erken sinyal, aynı zamanda erken yanlış pozitif riskini de taşır. İleri seviye yaklaşım:

sinyali tek başına "bulgu" yapmaz,
başka sinyallerle tutarlılık arar,
confidence'ı buna göre ayarlar.

İpucu: Bulut izlerinde en sessiz yaklaşım, "geniş arama" yerine "bulunan sinyali doğrulama"dır. Böylece gürültü (noise) artmaz, iş yükü kontrol edilir ve rapor denetlenebilir kalır.

9) Yanıltma, gürültü ve veri zehirleme: OSINT'in "karşı taraf gerçekliği"

OSINT alanı temiz değildir: eski altyapı kalıntıları, kopyalanmış içerikler, sahte profiller ve kasıtlı yanlış bilgi; Recon'u kolayca yanlış yöne sürükleyebilir. Bu yüzden iki refleks hayati:

Alternatif açıklama üret: "Bu sinyal başka ne anlama gelebilir?"
Karşı kanıt ara: "Hangi işaret bunu yanlışlar?"

Örnek: Bir sertifika izi "servis var" gibi görünebilir; ancak bu, test ortamı kalıntısı, devre dışı bir uç nokta veya üçüncü taraf otomasyonunun yan ürünü de olabilir. Bu alternatifler elenmeden "kritik yüzey" diye raporlamak, raporu zayıflatır.

Dikkat: OSINT'te en pahalı hata yalnızca yanlış negatif değildir; yanlış pozitif de operasyonel yükü şişirir, gereksiz risk yaratır ve güven aşındırır.

10) Çıktıyı sonraki aşamalara bağlamak: modül 4'e temiz girdi, modül 12'ye telemetri, modül 17'ye rapor dili

Bu modülün "başarılı" çıktısı, şu üç şeye aynı anda hizmet eder:

— Modül 4 için karar filtresi: Hangi hipotezler aktif doğrulamaya değer, hangileri daha fazla pasif kanıt istiyor?
— Savunma için iyileştirme hattı: Hangi varsayımlar zayıf ve hangi telemetri/izlenebilirlik eksik?
— Rapor standardı: Gözlem-yorum ayrımı, izlenebilirlik, tazelik ve confidence gerekçesi.

10.1. Kanıt paketi şablonu: basit ama sert bir standart

Her bulgu, aşağıdaki bileşenlerle taşınır:

Gözlem: ham sinyal + zaman bağlamı
Yorum: risk varsayımıyla ilişkilendirilmiş çıkarım
Varsayımlar: hangi şartlarda geçerli?
Karşı kanıt: fikri ne değiştirir?
Confidence: neden bu seviyede?

10.2. Durma ve yeniden çerçeveleme: olgunluğun işareti

Recon'un durması gerektiği anlar vardır:

Objective ile bağ kopuyorsa
Yeni veri yalnız gürültü üretiyorsa
Etik/OPSEC riski artıyorsa
Varsayımlar kırıldıysa ve senaryo yeniden kurulmalıysa (modül 2'deki yaklaşımı hatırla)

Terimler Sözlüğü

Terim	Açıklama
Recon	Keşif; hedef/ortam hakkında sinyal toplayıp saldırı yüzeyini ve varsayımları anlamlandırma süreci
OSINT	Açık Kaynak İstihbaratı; kamuya açık kaynaklardan doğrulanabilir bulgu üretme disiplini
Attack surface	Saldırı yüzeyi; dışarıdan etkileşime açık varlıklar ve bu varlıkların ilişkileri
Asset discovery	Varlık keşfi; dış yüzeyde görülebilen varlıkları bulma yaklaşımı
Asset attribution	Keşfedilen varlığın hedefle ilişkisini kanıt zinciriyle doğrulama süreci
Yatay keşif	Hedefle dolaylı ilişkili yüzeyi kapsayan keşif (iştirak, satın alma, kampanya varlıkları vb.)
Dikey keşif	Ana alan adı etrafındaki alt bileşenlerin keşfi (alt alan adları gibi)
Shadow IT	Gölge BT; BT onayı dışında kullanılan/kurulan sistem ve hizmetler
Birincil sinyal	Doğrudan kaynaktan gelen, mekanik/izlenebilir işaret (kayıt/teknik iz)
İkincil sinyal	Yorumlanmış/yeniden yazılmış içerik; ipucu olabilir, doğrulama ister
Triangulation	Bağımsız doğrulama; aynı iddiayı farklı türden kaynaklarla teyit etme yaklaşımı
Cross-validation	Çok kaynaklı doğrulama; sinyali birden fazla bağımsız veri noktasıyla sınama
Provenance	Kaynak soyu; bilginin nereden geldiği, nasıl üretildiği, güvenilirlik bağlamı
Freshness	Tazelik; bilginin güncelliği ve bugünü temsil etme olasılığı
Confidence	Güven düzeyi; sonucun gerekçeli eminliği ve hangi şartlarda değişeceği
Trust boundary	Güven sınırı; yetki/güvenin değiştiği geçiş noktası
OPSEC	Operasyon güvenliği; görünürlük, iz bırakma ve yan etki risklerini sınırlama disiplini
Noise	Gürültü; gereksiz görünürlük/iş yükü ve tespit riskini artıran etki
False Positive (FP)	Yanlış pozitif; gerçek olmayan veya yanlış ilişkilendirilmiş sinyalin bulgu sanılması
Deconfliction	Çakışma önleme; paydaş koordinasyonu ile operasyonel riskleri azaltma
Supply chain	Tedarik zinciri; üçüncü taraf bağımlılıklarının oluşturduğu risk alanı
SaaS / PaaS	Hizmet olarak yazılım / platform; kurumsal bağımlılık ve kontrol sınırı bağlamı
Certificate Transparency (CT)	Sertifika şeffaflığı; yayımlanan sertifikaların log kayıtları üzerinden iz üretme mekanizması
Passive DNS (pDNS)	Geçmiş DNS kayıtlarını tutan veri kümeleri; tarihsel altyapı izleri için kullanılır
Breach/Leak data	Sızıntı verisi; kimlik ve erişim riskini modellemek için değerlendirilen dışa sızmış veri setleri
Credential Stuffing	Sızmış kimlik bilgilerinin farklı servislerde yeniden kullanılmasına dayalı risk sınıfı
Tenant	Bulutta bir müşteriye ayrılmış mantıksal alan/kiracı yapısı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir ekip, Recon çıktısında “Kurum X şu hizmeti kullanıyor” diye bir ifade yazmak istiyor. En doğru yaklaşım hangisidir?

A) Tek bir blog kaynağı yeterliyse “kesin” yazmak

B) İfadeyi yazıp doğrulamayı modül 4’e bırakmak

C) Kaynak–iddia–kanıt ayrımı kurup en az iki farklı sınıftan sinyalle doğrulayıp confidence belirtmek

D) Popüler kaynaklara dayanıp kaynak linki vermemek

E) Doğrulama yerine daha çok veri toplayıp cümleyi güçlendirmek

Doğru: C
Kısa gerekçe: C, denetlenebilirlik ve belirsizlik yönetimini sağlar. A/B/D kanıt standardını zayıflatır; E hacmi artırır ama doğruluğu garanti etmez.

2) Bir varlığın hedefle ilişkisini kurarken “en olgun” hata türü hangisidir ve neden tehlikelidir?

A) Yanlış negatif; çünkü rapor uzar

B) Yanlış pozitif; çünkü gereksiz faaliyet ve gereksiz risk/noise üretir

C) Yanlış pozitif; çünkü her zaman saldırı başarısına yol açar

D) Yanlış negatif; çünkü her zaman regülasyon cezası doğurur

E) İkisi de aynı; çünkü ikisi de raporu kısaltır

Doğru: B
Kısa gerekçe: Yanlış pozitif, kaynak israfı ve gereksiz görünürlük doğurur. C/D kesinlik içerir ve genelleyicidir; A/E mantıksal olarak zayıftır.

3) “Tazelik” değerlendirmesi neden sadece tarih bakmak değildir?

A) Çünkü tarih her zaman yanlıştır

B) Çünkü aynı sinyal farklı bağlamlarda farklı anlama gelebilir; bugünle ilişkisi kanıtlanmalıdır

C) Çünkü tazelik yalnızca teknik belgelerde geçerlidir

D) Çünkü tazelik sadece OSINT’te önemlidir

E) Çünkü eski veriler hiçbir zaman işe yaramaz

Doğru: B
Kısa gerekçe: B, bağlam ve geçerlilik ilişkisini kurar. A/C/D/E aşırı genellemedir.

4) Pasif–yarı pasif–aktif çizgisi açısından, “sınırı” belirleyen en kritik ölçüt hangisidir?

A) Kullanılan aracın ücretli olup olmaması

B) Etkileşim miktarı/deseni ve bunun hedefte iz/noise üretme olasılığı

C) Çalışmanın gündüz yapılması

D) Kullanılan işletim sistemi

E) Toplanan verinin uzunluğu

Doğru: B
Kısa gerekçe: B, operasyonel gerçekliği yakalar. Diğerleri sınırın doğasını açıklamaz.

5) Asset attribution için en doğru ifade hangisidir?

A) “Bulduk; demek ki hedefindir.”

B) “IP buluta aitse hedefindir.”

C) “Tek bir güçlü sinyale dayanıp kesin konuşmak gerekir.”

D) “İlişkilendirme, bir iddiayı farklı sınıftan kanıtlarla destekleyip alternatif açıklamaları eleme işidir.”

E) “İlişkilendirme, yalnızca alan adı tesciline bakmaktır.”

Doğru: D
Kısa gerekçe: D, kanıt zinciri ve karşı kanıt mantığını içerir. A/B/C/E tek boyutlu ve hata üretmeye açıktır.

6) Sızıntı verisi değerlendirmesinde en doğru hedef nedir?

A) Sisteme giriş yolunu hızlandırmak

B) Kurumun parola politikasını kesin olarak ispatlamak

C) Kimlik ve erişim risk varsayımlarını modelleyip savunma kontrollerinin yeterliliğini tartmak

D) Kullanıcıların kişisel davranışlarını ifşa etmek

E) Sızıntıyı üreten tarafın kimliğini bulmak

Doğru: C
Kısa gerekçe: C, izinli ve savunma odaklı çerçeveye uyar. A/D kötüye kullanım ve etik dışı yöne kayar; B “kesinlik” iddiası taşır; E kapsam dışı olabilir.

7) Üçüncü taraf bağımlılıklarını haritalarken “yüksek confidence”a yaklaşmanın doğru yolu hangisidir?

A) Tek bir işareti bulur bulmaz sonuca varmak

B) Bağımlılık iddiasını en az iki farklı kanıt sınıfıyla desteklemek ve tazeliği kontrol etmek

C) Sadece çalışan profillerine bakmak

D) Sadece arşiv kayıtlarını temel almak

E) Bağımlılıkları raporda hiç anmamak

Doğru: B
Kısa gerekçe: B, triangulation ve tazelik kapısını birlikte taşır. A/C/D tek kaynağa yaslanır; E savunma değerini düşürür.

8) Bulut ayak izi OSINT’inde “olgun yöntem seçimi”ni en iyi anlatan ifade hangisidir?

A) Geniş arama yapıp olabildiğince çok sinyal üretmek

B) Bulutta her zaman IP temelli ilişkilendirme yapmak

C) Bulunan pasif sinyali doğrulayıp gürültüyü artırmadan kanıt zinciri kurmak

D) Belirsizliği rapordan çıkarmak

E) Tüm bulut sinyallerini “kritik risk” diye yazmak

Doğru: C
Kısa gerekçe: C, hedefli doğrulama ve OPSEC/noise dengesini anlatır. A/B/D/E yanlış pozitif ve risk üretir.

9) OSINT’te yanıltma/gürültü/data poisoning riskine karşı en iyi refleks hangisidir?

A) İlk bulduğun sinyali rapora eklemek

B) Alternatif açıklama üretmek ve karşı kanıt aramak

C) Her sinyali otomatik yüksek confidence yapmak

D) OSINT’i tamamen bırakmak

E) Sadece popüler kaynaklara güvenmek

Doğru: B
Kısa gerekçe: B, doğrulama ve belirsizlik yönetiminin özüdür. A/C/E kolay yanılgı üretir; D yöntem seçimini dogmatik yapar.

10) Recon çıktısını modül 4’e taşırken “doğru paketleme” hangisidir?

A) Ham veriyi ekleyip yorum yazmamak

B) Yorum yazıp kanıt ve zaman bağlamını eklememek

C) Gözlem–yorum ayrımı + varsayım + karşı kanıt + confidence gerekçesiyle, aktif doğrulama için net hipotezler üretmek

D) Her şeyi “kesin” yazmak

E) Sadece teknolojileri listelemek, karar filtresi kurmamak

Doğru: C
Kısa gerekçe: C, denetlenebilirliği ve karar kalitesini taşır. A/B/D/E rapor standardını ve operasyonel değeri düşürür.

Bu Modülde Kazanılan Yetkinlikler

Recon/OSINT'in değeri "çoklukta" değil; kanıt zinciri, karşı kanıt ve confidence gerekçesi ile üretilen doğrulukta yatar.
Saldırı yüzeyi, yalnızca ana alan adının etrafında değil; yatay ilişkilerde (iştirak/satın alma/kampanya/gölge BT) büyür ve bu büyüme savunma varsayımlarını doğrudan etkiler.
Pasif-yarı pasif-aktif çizgisi teknik bir sınıflama değil; noise/FP/OPSEC/etik maliyeti olan bir yöntem seçimi problemidir.
Sızıntı verisi ve kimlik izleri, izinli ve savunma odaklı yaklaşımda "giriş" için değil; risk modellemek ve kontrol yeterliliğini tartmak için değerlendirilir.
Üçüncü taraf ve bulut bağımlılıkları, kontrol sınırını değiştirir; Recon çıktısı bunu savunma telemetrisine ve rapor diline bağlayabildiği ölçüde değerlidir.

MODÜL 4 — Scanning ve Enumeration Stratejisi

>

Modül Teması

Hedefli Tarama

Gürültü/hız/doğruluk dengesi ve OPSEC.

Servis Fingerprint

Sürüm, banner ve davranış parmak izleri.

Enumeration

Kullanıcı, paylaşım, politika ve yapılandırma çıkarımı.

Modül 3'te pasif sinyallerle kurduğun saldırı yüzeyi haritası ve hipotezler, bu modülde kontrollü, ölçülebilir ve denetlenebilir doğrulama faaliyetlerine dönüşür. İleri seviyede scanning/enumeration; bir aracı çalıştırıp çıktı beklemek değil, ağ trafiğini, servis yanıtlarını ve protokol davranışlarını yorumlayarak hedef ortamın "dijital parmak izini" güvenilirlik (confidence) diliyle ortaya koyma disiplinidir. Buradaki başarı ölçütü, kapsamı rastgele büyütmek değil; doğru kapsamı doğru yöntemle seçmek, yanlış pozitifleri erken ayıklamak, belirsizliği dürüstçe yönetmek ve çıktıyı modül 5-7'deki kararları besleyecek şekilde kanıt standardında paketlemektir.

Bu Modülde Hedeflenen Kazanımlar

Modül 3'ten gelen hipotezleri, doğrulanabilir test sorularına çevirip kapsam-yöntem-risk dengesini kurmak
Gürültü (noise) ve OPSEC gerçekliği altında "sessiz / gürültülü" tarama stratejilerini bağlama göre tasarlamak
Sinyali kaynak-iddia-kanıt ayrımıyla ele alıp, bağımsız doğrulama ve karşı kanıt arayışıyla confidence dilini kurmak
Otomatik tarama çıktılarındaki false positive / false negative riskini kalite kapılarıyla yönetmek; "durma koşulları" ve yeniden çerçeveleme refleksi geliştirmek
Enumeration bulgularını saldırı yüzeyi grafiğine dönüştürerek modül 9-10 (segment/kimlik patikaları) ve modül 12-17 (tespit/raporlama) hattına taşımak

1) Scanning ve enumeration'ı "keşif" değil "kanıt üretimi" olarak kurgulamak

İleri seviyede scanning/enumeration, "ne bulursam kâr" yaklaşımıyla ilerlemez. Önce soruyu netleştirir, sonra soruyu cevaplayacak kadar veri toplar, ardından bu veriyi kanıt zinciri içinde taşır. Burada kilit ayrım şudur: bulgu dediğin şey, yalnızca bir işaret değil; o işaretin nasıl doğrulandığı, hangi koşulda yanlışlanabileceği ve hangi risk varsayımlarına bağlandığıdır.

1.1. Objective → hipotez → test sorusu dönüşümü

Modül 3'te üretilen her güçlü hipotez, bu modülde "test sorusu"na çevrilir. İleri seviye test sorusu şu parçaları doğal biçimde içerir:

Sinyal: Ne arıyorum (ne görürsem "var" derim)?
İddia: Bu sinyal neyi gösteriyor olabilir?
Karşı kanıt: Neyi görürsem iddiam zayıflar / çöker?
Maliyet: Bu doğrulamanın noise/OPSEC ve operasyonel yük maliyeti nedir?
Durma koşulu: Hangi eşikte "yeter" deyip ilerleyeceğim veya yeniden çerçeveleyeceğim?

Örnek: Modül 3'te "dış yüzeyde kimlik akışının bir aracı katmana dayandığına dair izler var" hipotezi çıktıysa, hedef "hangi ürün?" merakı değil; "kimlik akışı hangi güven sınırına dayanıyor, bu sınır hangi savunma varsayımlarını gerektiriyor ve elimdeki kanıt bunu ne ölçüde destekliyor?" sorusudur.

1.2. Kapsamı matris gibi yönetmek: genişleme/daralma uçlarına düşmemek

İleri seviyede iki yaygın hata:

Kör genişletme: Her yere bakmak → noise artar, değerlendirme yükü patlar, kanıt kalitesi düşer.
Aşırı daraltma: Sadece bildiğine bakmak → kritik yüzey kaçabilir.

Bunu yönetmek için kapsamı "liste" gibi değil, öncelik kuyruğu gibi düşünmek işe yarar. Kuyruğa giriş ölçütleri görünür olmalı:

Varlık sınıfı (alan adları, uygulama uçları, ağ segmentleri, aracı katmanlar, üçüncü taraf bağımlılık izleri)
Yöntem sınıfı (düşük yan etkili geniş görünüm ↔ hedefli derin doğrulama)
Risk maliyeti (OPSEC/noise, minimum zarar)
Beklenen değer (objective'e katkı)

İpucu: "Kapsam kayması (scope creep)" genelde meraktan değil, kanıt kalitesinin zayıflamasından doğar. Yeni bir alt yüzeye geçmeden önce "bu veri, hangi kararı değiştirecek?" sorusunu kendine sordur.

1.3. Kalite kapıları ve durma koşulları

Olgun scanning/enumeration, "daha çok denemek" değil doğru anda durabilmek demektir:

Objective ile bağ koptuysa dur; modül 2'deki senaryo/tehdit modeliyle yeniden hizalan.
Yeni veri yalnız gürültü üretiyorsa dur; yöntemi veya kapsamı değiştir.
OPSEC/etik/minimum zarar sınırı geriliyorsa dur; daha düşük yan etkili yaklaşıma dön.
İddia güçlü bir karşı kanıtla zayıfladıysa ısrar etme; hipotezi güncelle.

2) Yöntem seçimi: aynı sorunun birden fazla cevabı vardır; maliyetini bilmeden seçemezsin

İleri seviyede yöntem seçimi bir "araç seçimi" değil, bir tradecraft kararıdır: doğruluk kazancı ↔ görünürlük/noise ↔ false positive maliyeti ↔ operasyonel yük ↔ OPSEC/etik sınır

2.1. "Sessiz tarama yoktur": OPSEC gerçekliği

Her paket bir iz bırakabilir; "sessizlik" iddiası çoğu zaman gerçeği yansıtmaz. Daha doğru çerçeve şudur: belirli bir faaliyetin normal trafiğe benzerliği ve savunma sistemlerinin korelasyon kabiliyeti.

Yoğunluk ve desen, tespit riskini çoğu zaman "hangi teknik"ten daha fazla etkiler.
Tek bir kaynaktan sürekli, düzenli ve yüksek hacimli davranış; korelasyon için davetiyedir.
Dağıtık yaklaşım bazı durumlarda görünürlüğü azaltabilir; ancak aynı zamanda yönetişim/izlenebilirlik ve "minimum zarar" denetimini zorlaştırabilir.

Dikkat: "İzinli çalışıyoruz" ifadesi, "sınırsız görünürlükle hareket edebiliriz" anlamına gelmez. İzinli olmak çerçeveyi kurar; kaliteyi sağlayan şey, OPSEC, minimum zarar ve ölçülülük prensipleridir.

2.2. Geniş görünüm mü, derin doğrulama mı?

Geniş görünüm (coverage): yüzeyi hızlı çerçeveler; ama false positive ve gürültü riski artabilir.
Derin doğrulama (depth): doğruluğu artırır; ama maliyet (zaman/OPSEC/iş yükü) büyür, ayrıca dar kalma riski doğurabilir.

Olgun yaklaşım bunu bir "ya/ya da" değil, aşamalı doğrulama olarak kurar:

— Düşük yan etkili geniş görünüm
— Kalite kapılarıyla eleme (yanlış pozitifleri ayıklama)
— Kalan hipotezlerde hedefli derin doğrulama

Bu, herkese aynı tetkiki istemek yerine, bulgu ihtimaline göre hedefli doğrulama yapan doktor yaklaşımına benzer.

İpucu: "Yan etki bütçesi" belirlemek kararları otomatikleştirir: kabul edilebilir alarm riski, kabul edilebilir operasyonel yük, kabul edilebilir tekrar sayısı. Bütçeyi aşınca yöntem değişir veya durulur.

2.3. Karmaşık ağ gerçekliği: firewall/IPS/VLAN ve "sonuç çıkmıyor" yanılgısı

Gerçek ortamlarda segmentasyon ve güvenlik cihazları nedeniyle scanning sonuçları "eksik" görünebilir. Buradaki ileri seviye refleks:

"Yanıt yok" → "yok" demek değildir.
"Gördüğüm IP" → "hedefin gerçek bileşeni" demek olmayabilir (özellikle bulut/CDN/ara katman etkisi).
"Tek ölçüm" → "kesin hüküm" değildir: zaman uyumu, farklı koşullarda tutarlılık ve karşı kanıt arayışı gerekir.

Örnek: 198.51.100.0/24 bloğunda görülen bir uç nokta, hedefin gerçek uygulaması değil; bir aracı katmanın parçası olabilir. Bu durumda iddia "hedefin uygulaması" ise, o iddiayı güçlendiren/çürüten bağımsız işaretler aranır; aksi halde confidence düşürülür.

3) Servis tabanlı enumeration: Port "kapı"dır, içeride kim var?

Port taraması yalnız "kapı açık mı?" sorusunu cevaplar. Enumeration ise "kapının arkasında ne var, hangi kimlik ve yetki varsayımlarıyla çalışıyor, hangi bağımlılıklara dayanıyor?" sorusunu netleştirir. Buradaki stratejik akış şudur: Servis → Kimlik → Yetki

3.1. Banner'ın ötesi: davranışsal sinyaller ve yanıltıcı parmak izleri

Bir servis kendini belirli bir yazılım/sürüm olarak tanıtabilir; ama bu bilgi değiştirilebilir, yanıltıcı olabilir. Bu yüzden ileri seviyede:

Banner gibi sinyaller gözlem olarak kaydedilir.
Servisin protokol davranışı, hata biçimi, yanıt tutarlılığı gibi unsurlar daha güvenilir davranışsal işaretler üretebilir.
Aynı iddiayı farklı sınıftan kanıtla desteklemeden "yüksek confidence" yazılmaz.

Örnek: Bir web servisi kendini belirli bir ürün ailesi gibi tanıtıyor görünürken, hata sayfalarının yapısı ve yanıt tutarlılığı başka bir aileye işaret edebilir. Bu durumda "etiketleme" yerine, iki olasılığı da taşıyan ve hangi kanıtın hangisini güçlendirdiğini açıklayan bir paket hazırlanır.

3.2. Kimlik ve yetki ayrımı: "giriş var mı?" ile "neye izin var?" aynı şey değildir

Enumeration sırasında en sık yapılan hata, kimliği (identity) yetkiyle (authorization) karıştırmaktır. İleri seviyede şunlar ayrıştırılır:

Kimlik doğrulama akışı hangi güven sınırında gerçekleşiyor?
Yetkilendirme hangi katmanda, hangi varsayımla uygulanıyor?
Bağımlılıklar (harici kimlik sağlayıcı, ara servisler, API katmanı) hangi riskleri taşıyor?

Bu ayrım, modül 5 (initial access) ve modül 6 (web/API) için "saldırı patikası" modellemesinde kritik girdi üretir; ancak burada amaç "nasıl yapılır"a gitmek değil, risk ve doğrulama standartlarını inşa etmektir.

3.3. Minimum zarar ve "Safe Checks" zihniyeti

Bazı servisler-özellikle eski/özel amaçlı sistemler-beklenmedik şekilde kırılgan olabilir. İleri seviye yaklaşım:

Doğrulama yaparken sistemi bozma olasılığını ayrıca risk olarak ele alır.
"Güvenli kontroller" prensibiyle, agresif doğrulamaları sınırlı ve ölçülü tasarlar.

Dikkat: Üretim benzeri yüzeylerde "doğru bulgu" kadar "doğru süreç" de önemlidir. Bulguyu doğrularken hizmet kesintisi doğurmak, testin güvenilirliğini ve kurumsal güveni zedeler.

4) Otomatik tarama çıktısını doğrulanabilir bulguya dönüştürmek

Otomatik tarayıcılar vazgeçilmezdir; ama çıktıları çoğu zaman birer iddiadır. İleri seviye profesyonellik, bu iddiayı rapora taşımadan önce kanıt standardına yükseltmeyi gerektirir.

4.1. False positive / false negative dengesi

False positive (yanlış pozitif), erken dönemde en pahalı hatadır: yanlış yöne yatırım, gereksiz risk/noise, paydaş güveni kaybı.
False negative (kaçırma), uzun vadede risk taşır: görünmeyen yüzeyler, eksik saldırı patikası.

Bu yüzden standart refleksler:

Otomatik çıktı → manuel akıl süzgeci
Tek sinyal → bağımsız doğrulama
Benzerlik → alternatif açıklama üretimi

İpucu: "Tek sınıftan kanıtla hüküm verme" alışkanlığı, yanlış pozitifi büyütür. Aynı iddiayı farklı türde kanıtlarla (farklı kaynak tipi) destekleyemiyorsan iddiayı küçült; confidence'ı düşür; hangi kanıtla yükseleceğini açıkça yaz.

4.2. "Sürüm eski" bulgu değildir: risk odaklı kanıt

Bir bileşenin eski sürümde olması, tek başına yayınlanabilir bulgu kalitesine yetmez. Yayınlanabilir bulgu:

iddianın kapsamını açıklar (hangi bileşen, hangi bağlam),
etki varsayımını belirtir (hangi şartlarda risk),
doğrulama yaklaşımını ve belirsizliği yönetir,
savunma iyileştirmesine bağlanır (hangi kontrol/telemetri, hangi sertleştirme ilkesi).

4.3. Otomasyonun göremediği yer: bağlamsal ve iş mantığı riskleri

İmzaya dayalı otomasyon, bağlam gerektiren hataları kaçırabilir. İleri seviye enumeration çıktısı, yalnız "bilinen imza"ya değil; akış, yetki ayrımı ve güven sınırlarının tutarlılığına bakarak risk modellemesini derinleştirir. Bu, modül 6'daki ileri web/API değerlendirmesine "kör noktalar" listesi üretir.

5) Dizin servisleri ve yönetim protokolleri: görünmeyen yüzeyleri kaçırmamak

Kurumsal ağlarda değerli bilgiler çoğu zaman "dosya"dan çok dizin servisleri ve yönetim protokolleri etrafında toplanır. Bu modülde odak, "sızmak" değil; yanlış yapılandırmaların hangi tür bilgi sızıntısı riskleri doğurabileceğini görmek ve bunu kanıt standardında rapora dönüştürmektir (modül 10'a sağlam zemin).

Bazı ortamlarda, kimlik doğrulama olmadan veya düşük yetkili bağlamda, sınırlı dizin/varlık metaverisi açığa çıkabilir.
Yönetim protokolleri yanlış yapılandırıldığında, topolojiye dair çıkarımlar yapılmasını kolaylaştıran veriler üretebilir.
Bu yüzeyler, "standart web bakışıyla" kolay kaçabilir; çünkü protokole özel davranış ve izler taşır.

Örnek: Bir kurumda yanlış yapılandırılmış bir yönetim arayüzü, ağ bileşenleri arasındaki ilişkilere dair ipuçları veriyorsa, bulgu "şu protokol var" diye değil; "bu yapılandırma, şu tür topoloji bilgisinin açığa çıkmasına yol açabilir; şu kontrol varsayımlarını zayıflatır; tespit/telemetri şuralarda güçlendirilmeli" biçiminde paketlenir.

Dikkat: Bu sınıf yüzeylerde doğrulama yaklaşımı özellikle ölçülü olmalıdır. "Bilgi toplamak" ile "operasyonel riski büyütmek" arasındaki çizgi ince olabilir; minimum zarar ilkesi burada daha da kritik hale gelir.

6) Kanıt paketi ve saldırı yüzeyi grafiği: veriyi karara dönüştürmek

Bu modülün çıktısı, "ham tarama raporu" değildir. Çıktı, modül 5-7'deki zincirleme düşünmeyi ve modül 12-17'deki tespit/raporlama hattını besleyecek şekilde saldırı yüzeyi grafiği üretir:

Düğümler: varlıklar, servisler, kimlik akışları, aracı katmanlar, kritik bağımlılıklar
Kenarlar: güven sınırları, bağımlılık ilişkileri, erişim/akış varsayımları
Ağırlık/etiket: confidence seviyesi, belirsizlik notu, karşı kanıt koşulları
Savunma bağlantısı: hangi telemetri/log bu varsayımı doğrular; hangi sertleştirme/segmentasyon ilkesi riski düşürür (modül 12'ye köprü)

Bu yapı, "bulgu listesi"ni karar destek çıktısına çevirir.

Terimler Sözlüğü

Terim	Açıklama
Scanning	Tarama; yüzeydeki varlık ve servis işaretlerini kontrollü biçimde toplama
Enumeration	Numaralandırma/derinleştirme; servisleri bağlam, akış ve bağımlılıklarla anlamlandırma
OPSEC	Operasyon güvenliği; görünürlük, korelasyon ve yan etki risklerini yönetme
Noise	Gürültü; gereksiz alarm/iz ve veri kirliliği üreten davranış
False Positive	Yanlış pozitif; gerçekte olmayan bir durumun var sanılması
False Negative	Yanlış negatif; gerçekte olan bir durumun kaçırılması
Coverage	Kapsama genişliği; ne kadar yüzey görüldüğü
Depth	Derinlik; görülen yüzeyin ne kadar doğru ve bağlamsal doğrulandığı
Fingerprinting	Parmak izi çıkarma; servis kimliğine dair işaretleri yorumlama
Banner Grabbing	Banner alma; servisin kendini tanıttığı metaveri işaretlerini toplama
Davranışsal analiz	Protokol/servis davranışından kimlik ve tutarlılık çıkarımı yapma
Safe Checks	Güvenli kontroller; hedefi bozma riski olan doğrulamaları ölçülü sınırlama yaklaşımı
Trust boundary	Güven sınırı; yetki/güvenin değiştiği geçiş noktası
Evidence chain	Kanıt zinciri; gözlem–yorum ayrımıyla izlenebilir bulgu üretme
Confidence	Güven düzeyi; kanıtların gücüne bağlı olarak eminlik derecesi
Telemetry	Telemetri; tespit ve izlenebilirlik için üretilen log/sinyal bütünü
Deconfliction	Çakışma önleme; paydaş koordinasyonuyla istenmeyen etkileri azaltma
Scope creep	Kapsam kayması; objective dışı kontrolsüz genişleme
Directory Services	Dizin servisleri; kimlik ve kaynak dizinlerini yöneten servis sınıfı
Unauthenticated enumeration	Kimlik doğrulama olmadan (veya düşük yetkiyle) bilgi sızıntısı doğurabilen keşif sınıfı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Modül 3’ten gelen hipotez: “Dış yüzeyde kimlik akışı bir aracı katmana dayanıyor olabilir.” İleri seviye yaklaşımda en doğru ilk adım hangisidir?

A) Hipotezi doğru kabul edip modül 5’e taşımak

B) En görünür ve hızlı yöntemi seçip “kesin” sonuca gitmek

C) Hipotezi test sorularına bölmek; karşı kanıtı tanımlamak; düşük yan etkili doğrulamayla confidence üretmek

D) Tek bir sinyal sınıfıyla doğrulayıp yüksek confidence vermek

E) Hipotezi görmezden gelip kapsamı rastgele genişletmek

Doğru: C
Kısa gerekçe: C, kaynak–iddia–kanıt ayrımını ve belirsizlik yönetimini kurar. A/B/D erken kesinlik üretir; E objective’ten kopar.

2) Bir ekip kapsamı hızla büyütüyor; sonuçlar artıyor ama değerlendirme yükü patlıyor ve bulguların doğruluğu düşüyor. En olgun müdahale hangisidir?

A) Daha da genişletmek; çok veri her zaman iyidir

B) Otomatik çıktıları doğrudan bulgu saymak

C) Kalite kapısı koyup yanlış pozitifleri elemek; objective’e katkısı zayıf alanlarda durma koşulu çalıştırmak

D) Her şeyi rapora koyup müşterinin filtrelemesini beklemek

E) Tüm taramayı tamamen durdurup yalnız pasif kalmak

Doğru: C
Kısa gerekçe: C, kanıt standardı ve yöntem seçimi disiplinidir. A/B/D kaliteyi düşürür; E bağlama göre aşırı tepkidir.

3) “Sessiz tarama” iddiası için en doğru teknik-olmayan çerçeve hangisidir?

A) Sessiz tarama mümkündür; sadece doğru araç gerekir

B) Sessizlik yoktur; yalnızca normal trafiğe benzerlik ve korelasyon riskinin yönetimi vardır

C) Gece yapılan her tarama sessizdir

D) Tek kaynaktan hızlı tarama sessizliği artırır

E) Sessizlik, yalnız şifreli trafik kullanmakla sağlanır

Doğru: B
Kısa gerekçe: B, OPSEC gerçekliğini doğru kurar. A/C/D/E tek boyutlu ve yanıltıcı genellemeler yapar.

4) Bir servis kendini belirli bir yazılım/sürüm olarak tanıtıyor; ancak davranışsal işaretler bununla tutarsız. En doğru sonuç yönetimi hangisidir?

A) Banner kesin doğrudur; davranışsal işaretleri yok saymak gerekir

B) Davranışsal işaretleri tek başına kesin kabul etmek gerekir

C) İki olasılığı da taşıyıp, hangi kanıtın hangisini güçlendirdiğini yazmak; tutarsızlığı belirsizlik olarak yönetmek

D) Tutarsızlık varsa bulguyu rapordan tamamen çıkarmak gerekir

E) Tutarsızlık varsa otomatik “honeypot” kararı verilmelidir

Doğru: C
Kısa gerekçe: C, karşı kanıt ve belirsizlik yönetimiyle yayınlanabilir doğruluk üretir. A/B tek kanıta aşırı güvenir; D bilgi kaybı doğurabilir; E gereksiz kesinliktir.

5) “Geniş görünüm” ile “derin doğrulama” arasında seçim yaparken en doğru strateji hangisidir?

A) Her zaman maksimum coverage

B) Her zaman maksimum depth

C) Aşamalı doğrulama: düşük yan etkili geniş görünüm → eleme → hedefli derin doğrulama

D) Coverage artarken kanıt zinciri gereksizdir

E) Depth yapılırken karşı kanıt aramaya gerek yoktur

Doğru: C
Kısa gerekçe: C, trade-off’ları yönetir. A/B bağlamı yok sayar; D/E kanıt standardını bozar.

6) Otomatik tarayıcı bir zafiyet iddiası üretti. İleri seviye raporlama standardına göre ilk doğru yaklaşım hangisidir?

A) İddiayı “kritik” diye etiketleyip doğrudan rapora almak

B) İddia doğru olmasa da rapora almak; “araç söyledi” demek yeterlidir

C) İddiayı kanıt paketine çevirmek: bağımsız doğrulama, alternatif açıklama ve karşı kanıt koşullarını yazmak; confidence’ı gerekçelendirmek

D) İddiayı saklamak; rapor karmaşık olmasın

E) İddiayı doğrulamak yerine kapsamı genişletmek; belki başka şey çıkar

Doğru: C
Kısa gerekçe: C, iddiayı bulguya dönüştüren süreçtir. A/B doğruluk riskini büyütür; D şeffaflığı zedeler; E odak kaybettirir.

7) “Sürüm eski” tespiti için en doğru bulguya dönüştürme yaklaşımı hangisidir?

A) Sadece “güncelleyin” yazmak yeterlidir

B) Sürüm eskiyse etki ve bağlam önemli değildir

C) Bileşen–bağlam–varsayım–etki–belirsizlik–telemetri/iyileştirme bağlantısı ile kanıt standardında yazmak gerekir

D) Sürüm tespiti yapılmışsa confidence her zaman %100’dür

E) Sürüm eskiyse otomatik olarak en kritik bulgudur

Doğru: C
Kısa gerekçe: C, yayınlanabilir risk odaklı bulgu standardıdır. A/B/D/E aşırı basitleştirir veya yanlış kesinlik üretir.

8) “Filtered” gibi belirsiz durumların en doğru yorumu hangisidir?

A) Port kesin kapalıdır

B) Port kesin açıktır

C) Durum belirsizdir; aracı katmanlar/filtreleme/tutarsız yanıtlar nedeniyle iddia sınırlandırılmalı ve karşı kanıt aranmalıdır

D) Bu her zaman yanlış pozitif demektir

E) Bu her zaman hedefin boş olduğu anlamına gelir

Doğru: C
Kısa gerekçe: C, belirsizlik ve karşı kanıt yaklaşımını uygular. A/B/D/E bağlamı ve ağ gerçekliğini yok sayar.

9) Dizin servisleri / yönetim protokolleri bağlamında “en kritik” risk çerçevesi hangisidir?

A) Bu protokoller her zaman güvenlidir; rapora gerek yoktur

B) Bu protokoller yalnız saldırganlar içindir; savunma açısından değersizdir

C) Yanlış yapılandırmaların bilgi sızıntısı doğurabileceği; bunun topoloji ve güven sınırı modellemesini etkileyebileceği; doğrulamanın ölçülü yapılması gerektiği

D) Bu protokoller sadece eski sistemlerde vardır; modern yapılarda yoktur

E) Bu protokoller varsa mutlaka kesinti yaratmak gerekir; yoksa doğru test olmaz

Doğru: C
Kısa gerekçe: C, risk–kanıt–minimum zarar üçlüsünü doğru kurar. A/B/D genelleme; E ise etik/operasyonel kaliteyi bozar.

10) Modül 4 çıktısını modül 12 (tespit perspektifi) ve modül 17 (raporlama) hattına en iyi bağlayan yaklaşım hangisidir?

A) Ham tarama verisini aynen eklemek

B) Yalnız yorum yazmak, kanıtı atlamak

C) Saldırı yüzeyi grafiği + kanıt paketi + confidence gerekçesi + hangi telemetri/iyileştirme ile kapatılacağı bağlantısını kurmak

D) Belirsizliği gizlemek; rapor güçlü görünsün

E) Tüm bulguları aynı önem derecesinde yazmak

Doğru: C
Kısa gerekçe: C, karar destek çıktısı üretir ve denetlenebilirlik sağlar. A/B kanıt standardını zayıflatır; D güvenilirliği bozar; E önceliklendirmeyi yok eder.

Bu Modülde Kazanılan Yetkinlikler

Scanning/enumeration'ı "keşif" değil, kanıt üreten doğrulama hattı olarak tasarlamayı
Kapsamı "öncelik kuyruğu" ve kalite kapılarıyla yöneterek scope creep riskini azaltmayı
Yöntem seçimini OPSEC/noise, operasyonel yük ve doğruluk kazancı arasında trade-off olarak yönetmeyi
Servis kimliğini "etiketlemek" yerine davranışsal işaretler ve bağımsız doğrulamayla confidence dili kurmayı
Otomatik tarama çıktısını, belirsizlik ve karşı kanıt dahil yayınlanabilir bulgu standardına yükseltmeyi
Çıktıyı saldırı yüzeyi grafiğiyle modül 5-7'ye, telemetri ve raporlama bağlantılarıyla modül 12-17'ye taşımayı

MODÜL 5 — Initial Access Tradecraft (Yüksek Seviye)

Modül Teması

Phishing & Pretext

Senaryo, alan adı, içerik ve hedefleme.

Payload Tasarımı

Loader, stager ve evasion mimarisi.

Foothold

İlk yürütme, sandbox-aware ve sessiz başlangıç.

Modül 4'te çıkardığın saldırı yüzeyi grafiği ve kanıt paketleri, burada "ilk temas" kararlarına dönüşür: Hangi giriş hipotezi hangi maliyetle test edilmeli, hangi sinyal yalnızca olasılık düzeyinde kalmalı, hangisi kanıt standardına yükseltilebilir? Bu modülde initial access'i "bir yerden içeri girmek" anlatısından çıkarıp; kimlik/erişim mimarisindeki güven sınırlarını ölçen, minimum zarar ve izinli kapsam içinde doğrulanan, belirsizliği dürüstçe yöneten ve çıktısı modül 6-7 (web/API ve zincirleme tasarım), modül 12 (tespit perspektifi) ve modül 17 (raporlama) hattına denetlenebilir biçimde bağlanan bir disiplin olarak ele alacağız.

Bu Modülde Hedeflenen Kazanımlar

Modül 4 bulgularını kullanarak initial access için hipotez tabanlı vektör seçimi yapmak ve kapsam-risk-değer dengesini kurmak
İddia-kanıt-karşı kanıt ayrımıyla, kimlik ve güven sınırı varsayımlarını "kanıt standardına" taşımak
Noise/false positive maliyeti, OPSEC, operasyonel yük ve "minimum zarar" ilkesiyle uyumlu go/no-go kapıları tasarlamak
Initial access bulgularını savunma kontrolleri ve telemetriyle ilişkilendirip iyileştirme önerisine dönüştürmek (modül 12-17 hattı)
Belirsizliği confidence diliyle yönetip izlenebilir, tekrar üretilebilir bir karar dosyası üretmek

1) Initial access'in ileri anlamı: "vektör" değil, "varsayım testi"

Temel seviyede initial access çoğu zaman "hangi açık var?" sorusuyla ilerler. İleri seviyede ise asıl soru şudur: Hangi savunma varsayımı zayıf olabilir ve bunu ölçülebilir sinyallerle nasıl doğrularım?

Bu yüzden iyi bir initial access planı üç parçayı birlikte taşır:

İddia: "Şu giriş yolu, şu güven sınırı varsayımına dayanıyor."
Kanıt: "Bu iddiayı destekleyen/çürüten bağımsız işaretler neler?"
Sınırlar: "Bu iddiayı test etmenin noise/OPSEC/etik/minimum zarar maliyeti nedir?"

1.1. Modül 4'ten Modül 5'e: test sorusunu "giriş hipotezi"ne çevirmek

Modül 4'teki çıktılar (envanter, yüzey haritası, sinyaller) burada hipotez cümlelerine dönüşür. İyi bir hipotez:

Hangi varlık/akış üzerinden konuştuğunu net söyler (kimlik akışı, uzak erişim, üçüncü taraf entegrasyon izi, public-facing servis vb.).
"Ne görürsem fikrim değişir?" sorusunu içerir (karşı kanıt).
Teknik işaretleri, operasyonel maliyetle birlikte değerlendirir (üretime yakınlık, alarm riski, iş kesintisi riski, koordinasyon ihtiyacı).

Örnek: example.com altında tek bir portal sinyalinden "ürün X var" diye kesinlemek yerine, "kimlik akışındaki güven sınırı şu noktada daralıyor olabilir; bunu doğrulamak için şu kanıt sınıflarına ihtiyaç var; şu karşı kanıt çıkarsa iddia zayıflar; testin minimum zarar profili budur" şeklinde yazarsın.

1.2. Başarı kriteri: "erişim" değil, "doğru karar dosyası"

İleri seviyede başarıyı yalnız "erişim elde etmek" ile ölçmek yanıltıcıdır. Daha güçlü kriterler:

Yanlış pozitif üretmeden, bir güven sınırı varsayımını kanıt standardında doğruladın mı?
Belirsizliği saklamadan, "şu şartlarda fikrim değişir" diyebildin mi?
Çıktı savunma tarafında telemetri + kontrol aksiyonuna dönüşebilir mi (modül 12 ve 17'ye taşınabilir mi)?

Dikkat: İzinli kapsam "her şeyi dene" serbestliği değildir. Initial access'te küçük bir yanlış seçim (yanlış zaman, yanlış yüzey, yanlış yoğunluk) hem üretim riskini artırır hem de ölçümün güvenilirliğini bozar. Minimum zarar ilkesi burada sadece etik değil, aynı zamanda ölçüm kalitesi meselesidir.

2) İlk erişim vektörlerini sınıflandırmak: "ne"den önce "neden"

Bu modül bir tekniği adım adım uygulatmaz. Bunun yerine, initial access vektörlerini sınıflandırır ve her sınıf için karar mantığını, sınırları ve doğrulama yaklaşımını görünür kılar.

2.1. Public-facing uygulama / servis yüzeyi: "zafiyet sinyali" ≠ "giriş yolu"

Modül 4'te görülen sürüm işaretleri, konfigürasyon izleri veya zafiyet şüpheleri doğrudan "giriş vektörü" değildir. İleri seviye disiplin:

Sinyali önce iddia düzeyinde tutar,
Alternatif açıklamaları listeler (ara katman, reverse proxy/WAF davranışı, yanlış eşleşen sürüm izi, yanıltıcı banner vb.),
Kanıt kalitesi yükselmeden riskli doğrulama kararlarına koşmaz.

Bu yaklaşım, modül 6'daki web/API değerlendirmesine "temiz girdi" sağlar; modül 7'de zincir kurarken de yanlış patikaya yatırım riskini düşürür.

2.2. Kimlik tabanlı giriş: kimlik ≠ yetki

Modern kurumsal dünyada çevre duvarları kadar kimlik katmanı da "sınır"dır. Bu nedenle initial access çoğu zaman kimlik akışları etrafında şekillenir. Kritik ayrım şudur:

Kimlik doğrulama (identity) başka, yetkilendirme (authorization) başkadır.
"Giriş oldu" sinyali otomatik olarak "yüksek etki" demek değildir; etki, yetki kapsamı ve güven bölgeleri ile ölçülür.

Doğrulama yaklaşımında güçlü olan, tek bir işarete yaslanmamak ve farklı kanıt sınıflarıyla tutarlılık aramaktır: oturum politikası izleri, hata davranışları, adım yükseltme (step-up) noktaları, istisnalar, cihaz/konum koşulları, telemetri tutarlılığı.

Örnek: Bir uzaktan erişim yüzeyinde ek doğrulama katmanları görülüyorsa "güvenli" diye kapanış yapmak yerine, "step-up hangi koşulda devreye giriyor, hangi istisnalar var, bunu bağımsız olarak hangi log/telemetri doğrular?" soruları kanıt paketine girer.

2.3. İnsan etkileşimi ve istemci tarafı riskleri: "kullanıcı hatası" yerine "kontrol derinliği"

İnsan etkileşimi içeren patikalarda ileri seviye rapor, odağı "kullanıcı tıkladı" cümlesine sıkıştırmaz. Asıl soru şudur: Kullanıcı hatası varsayımı gerçekleştiğinde, bunu telafi edecek teknik kontroller zinciri çalıştı mı?

Burada değerlendirme; e-posta/mesajlaşma geçitleri, tarayıcı/OS kontrolleri, uç nokta koruması, web proxy, içerik izolasyonu, kimlik politikaları gibi katmanların "derinlik" kalitesine bağlanır. (Bu bakış modül 12 ve modül 17'de özellikle değerlidir.)

2.4. Konfigürasyon ve dış uzak servisler: "gölge BT" gerçeğini hesaba katmak

Kurumsal yüzey sadece "bilinen" sistemlerden ibaret değildir. Özellikle gölge BT (envantere girmemiş uzaktan erişimler, unutulmuş yönetim yüzeyleri, geçici test ortamları) initial access riskini büyütür. Burada tradecraft'in görevi:

Önce kapsam ve sahiplik çizgisini netleştirmek,
Sonra sinyali kanıt standardına taşımak (envanter/CMDB tutarlılığı, DNS/sertifika/akış izleri, log korelasyonu vb.).

2.5. Üçüncü taraf / tedarik zinciri izi: kontrol alanı ve koordinasyon

Kimlik sağlayıcılar, yönetilen hizmetler, CDN'ler, e-posta altyapısı, dış destek firmaları gibi bağımlılıklar initial access kararını doğrudan etkiler. Burada kritik olan:

Kapsam netliği: Hangi varlık, hangi kontrol alanı?
Deconfliction: Aynı anda yapılan testlerin çakışmasını önleme, yanlış alarm üretmeme
Veri minimizasyonu: Toplanan kanıtın sahipliği, saklama sınırları ve mahremiyeti

İpucu: Üçüncü taraf izi gördüğünde ilk refleks "derine gitmek" değil; "bu iz hangi kontrol alanına ait, hangi paydaşla koordine edilmeli, hangi kanıt eşiği 'yeterli' sayılır?" sorularını netleştirmektir. Bu, hem etik/hukuki uyumu hem de karar kalitesini yükseltir.

3) "Kimlik yeni sınır" gerçekliği: MFA, oturum ve legacy akışlar

Çok faktörlü doğrulama (MFA) güvenlik maliyetini artırır; fakat "aşılmaz duvar" değildir. Risk; çoğu zaman mimarideki istisnalar, legacy akışlar ve oturum yaşam döngüsü üzerinden şekillenir.

3.1. MFA ekosisteminde tipik kırılganlık sınıfları (how-to olmadan)

İleri seviye analiz, "MFA var/yok" ikiliğine sıkışmaz; şu tür mimari boşlukları sorgular:

Legacy authentication akışları: Modern koşullu erişim/MFA politikalarının tam uygulanmadığı eski protokoller veya temel kimlik doğrulama modelleri, kurumsal politikaya rağmen bir "arka kapı hissi" yaratabilir. Bu nedenle modern kimlik mimarileri, mümkünse legacy akışları azaltmayı veya modern doğrulamaya taşımayı hedefler.
MFA istem yorgunluğu (push fatigue) gibi sosyal-teknik riskler: Sürekli doğrulama istemleri, kullanıcı davranışını zayıflatabilir; savunma tarafında sayı eşleştirme, oran sınırlama, anomali tespiti ve kullanıcının doğrulama bağlamını görmesi gibi kontroller önem kazanır.
Araya giren kimlik avı (AiTM) benzeri proxy tabanlı senaryolar: Bazı modern oltalama türleri, kullanıcıdan yalnız parola değil, oturum açma sürecinden çıkan oturum belirteçlerini ele geçirip "oturum ele geçirme" riskini yükseltebilir. Bu nedenle "parola değişti → risk bitti" varsayımı her zaman geçerli değildir; oturum ve token hijyeni kritik olur.

3.2. Oturum ve token yaşam döngüsü: "erişim"in etkisi buradan okunur

Bir kimlik sinyali gördüğünde, ileri seviye soru şudur: Bu sinyal ne kadar süre, hangi kapsamla ve hangi koşullarda geçerli?

TTL / ömür: Oturumların ne kadar yaşadığı, yeniden doğrulama gereksinimi, riskli oturumların iptali
Scope / yetki kapsamı: Erişim belirtecinin hangi kaynaklara, hangi işlemlere izin verdiği
Koşullu erişim: Cihaz durumu, konum, risk skoru, uygulama türü gibi bağlam sinyalleri

Burada amaç "daha derine inmek" değil; güven sınırı varsayımlarını kanıtlayacak telemetriyi ve iyileştirme kaldıraçlarını netleştirmektir (modül 12'ye köprü).

İpucu: "Giriş sinyali" gördüğünde hemen "etki büyük" yazma. Önce şu ayrımı yap: kimlik doğrulama sinyali mi görüyorum, yoksa yetkilendirme sınırı mı aşılıyor? Bu iki şey aynı cümlede birleştiğinde raporlar genellikle yanlış kesinlik üretir.

4) İstemci tarafı kontrol gerçekliği: MOTW ve "konteyner" davranışları

İstemci tarafı risklerde savunma dünyası, dosyanın "ne olduğu" kadar "nereden geldiğini" de önemser. Bu bağlamda Mark of the Web (MOTW) gibi işaretler, bazı uygulamalarda daha kısıtlayıcı güvenlik davranışlarını tetikler; örneğin internet kökenli dosyalarda makro gibi riskli yeteneklerin varsayılan olarak kısıtlanması, kurumların saldırı yüzeyini azaltmayı hedeflediği önemli bir eksendir.

İleri seviye tradecraft açısından kritik nokta şudur:

"Kontrol var" demek için kontrolün tüm zincirde tutarlı çalıştığını göstermelisin (geçit → dosya işaretleme → uygulama davranışı → uç nokta tespiti).
Bazı "konteyner"/paket formatları ve taşıma yöntemleri, organizasyondan organizasyona değişen tarama/politika boşlukları üretebilir. Bu, bir "bypass reçetesi" değil; savunma açısından standardizasyon ve politika sertleştirme ihtiyacıdır.

Örnek: Bir organizasyonda e-posta geçidi belirli ek türlerini içeriğine kadar inceleyemiyor veya riskli dosya işaretlerinin zincirde kaybolduğu gözleniyorsa, raporda "kullanıcı tıkladı" cümlesi yerine "geçit-istemci-uç nokta kontrol zincirinde şu halkada doğrulanabilir bir zayıflık var" ifadesi değer üretir.

5) Kontrollü doğrulama: zarar vermeden "kanıt" üretmek

Red Team/pentest bağlamında "başarı" zarar vermek değildir; zarar verebileceğini, güvenli ve denetlenebilir şekilde kanıtlamaktır. Bu yüzden ileri seviye doğrulama tasarımı:

Gerçek zararlı davranışı taklit etmek yerine, zararsız ve tek amaçlı sinyallerle (ör. yalnızca "çalıştı" bilgisini üreten, veri taşımayan) ölçüm yapmayı tercih eder,
Üretim etkisini sınırlayacak fail-safe prensiplerine dayanır (zaman penceresi, etki yarıçapı, paydaş koordinasyonu).

Buradaki kritik zihniyet değişimi: "daha güçlü teknik" değil, daha güçlü kanıt standardı.

5.1. "Antivirüs engelledi" bir başarısızlık mı?

Hayır. Bu, çoğu durumda savunmanın çalıştığına dair değerli bir bulgudur: hangi katman engelledi, ne kadar sürede tespit edildi, hangi telemetri üretildi? İleri seviye raporlar bu tür sonuçları "boşa gitti" diye silmez; aksine ölçüm kalitesinin parçası yapar (modül 12 ve 17'ye doğrudan bağlanır).

5.2. Kanıt paketi şablonu: "nasıl bildin?"

Her kritik bulgu için şu ayrım net olmalıdır:

Gözlem: Ne görüldü? (ham sinyal, zaman bağlamı, kaynak notu)
Yorum: Bu sinyal ne anlama gelebilir? (risk ve güven sınırı ilişkisi)
Varsayım: Hangi koşullarda geçerli?
Karşı kanıt: Neyi görürsen yorum zayıflar/değişir?
Confidence: Neden bu seviyede? Hangi boşluklar var?
İzlenebilirlik: Hangi log/telemetri ile doğrulanır? (modül 12)

İpucu: "İddiayı büyütme" ile "kanıtı büyütme" farklıdır. Kanıt büyümüyorsa iddiayı büyütme; confidence'ı düşür, hangi ek kanıtın gerektiğini yaz ve doğru zaman/zeminde geri dön.

6) Go/No-Go kapıları: ne zaman ilerlenir, ne zaman durulur?

Initial access'te yöntem seçimi, modül 4'teki tarama kararlarının daha hassas bir versiyonudur; çünkü yanlış kararın bedeli daha ağır olabilir: yanlış alarm, kullanıcı etkisi, üretim riski, güven kaybı.

İleri seviyede her hipotez, en az şu üç kapıdan geçmeden "ilerleme" kararı almamalıdır:

— Kapsam kapısı: İzinli scope ve RoE ile tam uyum var mı? (modül 1'e bağ)
— Kanıt kapısı: İddia, en az iki bağımsız işaretle destekleniyor mu? Karşı kanıt listesi var mı?
— Risk kapısı: Minimum zarar profili kabul edilebilir mi? Üretim etkisi ve operasyonel yük bütçesi tanımlı mı?

Örnek: 203.0.113.0/24 içinde üretime yakın bir yüzeyde belirsiz bir sinyal varsa, "hemen doğrula" refleksi yerine; bakım penceresi, paydaş koordinasyonu ve telemetri hazırlığı gibi şartlar sağlanmadan ilerlememek ileri seviye olgunluktur.

6.1. False positive'in initial access'e özel maliyeti

False positive burada yalnız zaman kaybı değildir:

Savunma ekiplerini yanlış yöne sürükleyebilir,
Paydaş güvenini zedeler,
Modül 7'de yanlış zincire yatırım yaptırır.

Bu yüzden initial access'te çoğu zaman profesyonel olan, iddiayı büyütmek değil iddianın sınırlarını doğru çizmek ve kanıt standardını yükseltmektir.

6.2. OPSEC ve görünürlük: test, sonucu bozmasın

Bazı test türleri savunma sistemlerini "olağanüstü moda" sokabilir: erişimler kapanır, kullanıcı davranışı değişir, tespit sistemleri farklı eşiklerle çalışmaya başlar. İleri seviye yaklaşım:

Görünürlük maliyetini "kabul edilebilir etki" bütçesine bağlar,
Sonucun "normal koşullarda mı, test koşullarında mı" geçerli olduğunu kanıt paketinde ayırır.

7) Savunma iyileştirmesine bağlamak: modül 12 ve 17 hattı

Initial access çıktısı savunma tarafında şu üç soruya cevap vermelidir:

Hangi güven sınırı varsayımı zayıf görünüyor?
Bunu doğrulamak/izlemek için hangi telemetri nerede güçlendirilmeli? (modül 12)
Önceliklendirme nasıl yapılmalı; hangi hipotezler modül 6-7'ye taşınmalı?

Bu bağ kurulmadığında initial access, "kırmızı takım başarısı" hikâyesi olarak kalır. Bağ kurulduğunda ise kurum için kalıcı güvenlik çıktısına dönüşür: politika sertleştirme, izleme kapsamı, tespit kuralı, kontrol boşluğu kapatma, risk kabul gerekçesi.

Terimler Sözlüğü

Terim	Açıklama
Initial Access	İlk erişim; izinli değerlendirmede ilk temas/giriş hipotezlerinin test edilmesi aşaması
Tradecraft	Mesleki uygulama disiplini; yöntem seçimi, kalite kapıları ve operasyonel karar kalitesi
Hypothesis	Hipotez; kanıtla test edilebilir iddia
Go/No-Go	İlerleme/durma kararı; kapsam–kanıt–risk kapılarıyla verilen karar
Deconfliction	Çakışma önleme; paydaş koordinasyonuyla istenmeyen etkileri azaltma
Blast radius	Etki yarıçapı; bir testin potansiyel yan etkisinin yayılım alanı
Triangulation	Çapraz doğrulama; farklı sınıftan kanıtlarla tutarlılık arama
Counter-evidence	Karşı kanıt; iddiayı zayıflatacak/yanlışlayacak işaret
Confidence	Güven düzeyi; kanıt gücüne bağlı eminlik derecesi
OPSEC	Operasyon güvenliği; görünürlük, korelasyon ve yan etki risklerini yönetme
Telemetry	Telemetri; tespit ve izlenebilirlik için üretilen log/sinyal bütünü
Legacy authentication	Eski kimlik doğrulama akışları; modern koşullu erişim/MFA ile her zaman aynı biçimde örtüşmeyebilen yöntemler
AiTM (Adversary-in-the-Middle)	Kullanıcı ile servis arasına giren proxy tabanlı senaryolarla oturum ele geçirme riskini artıran modern oltalama sınıfı
Push fatigue	MFA istem yorgunluğu; tekrar eden doğrulama istemlerinin kullanıcı davranışını zayıflatması riski
MOTW (Mark of the Web)	Dosyanın internet kökenli olduğuna dair işaret; bazı uygulamalarda kısıtlayıcı güvenlik davranışlarını tetikler
Defense in Depth	Savunma derinliği; bir katman başarısız olsa bile diğer katmanların riski telafi etmesi yaklaşımı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Modül 4’ten gelen bulgu paketi, üretime yakın bir yüzeyde “kimlik akışı tutarsız” sinyali taşıyor; ancak yalnız tek sınıftan kanıt var. En olgun initial access kararı hangisidir?

A) Hemen ilerlemek; üretimde denemek en gerçekçisidir

B) Sinyali “kesin zafiyet” kabul edip kritik bulgu yazmak

C) İddiayı daraltıp karşı kanıtı tanımlamak; ikinci bağımsız kanıt sınıfı aramak; risk kapısı sağlanmadan ilerlememek

D) Sinyali yok sayıp kapsamı başka yerlere genişletmek

E) Görünürlüğü artırmak; alarm çıkarsa güvenilir kanıt saymak

Doğru: C
Kısa gerekçe: C kanıt zinciri + belirsizlik yönetimi + risk kapısı disiplinidir. A/E üretim etkisi ve OPSEC maliyetini büyütür; B yanlış kesinliktir; D bilgi kaybı doğurur.

2) Bir hipotez için “go” kararı alınmasını en iyi tanımlayan eşik hangisidir?

A) Hipotez ilginç görünüyorsa

B) Tek bir araç çıktısı “olası” diyorsa

C) Kapsam uyumu + en az iki bağımsız işaret + kabul edilebilir minimum zarar profili birlikte sağlanıyorsa

D) Paydaş “bir şey gösterin” diye baskı yapıyorsa

E) Sinyal üretime yakınsa; değerli olduğu için ilerlenmelidir

Doğru: C
Kısa gerekçe: C üç kapıyı birlikte taşır. A/B/D/E tek boyutlu karar mantıklarıdır ve ölçümü bozar.

3) Initial access’te false positive’in maliyeti neden “erken ve görünür” hasar üretebilir?

A) Çünkü false positive teknik olarak hiç olmaz

B) Çünkü yanlış bulgu, yanlış zincire yatırım ve gereksiz görünürlük yaratarak güven kaybı doğurur

C) Çünkü false positive sadece raporlama hatasıdır; operasyonu etkilemez

D) Çünkü false positive her zaman güvenlik cihazlarının hatasıdır

E) Çünkü false positive yalnız dış ağda oluşur

Doğru: B
Kısa gerekçe: B karar kalitesi ve itibar/operasyon maliyetini yakalar. C etkisini küçültür; D/E yanlış genellemedir; A gerçekçi değildir.

4) “Kimlik doğrulama başarılı” sinyali ile “etki yüksek” iddiasını ayırmanın en doğru gerekçesi hangisidir?

A) Kimlik doğrulama her zaman yetkiyle aynı şeydir

B) Etkiyi belirleyen, yetkilendirme sınırları ve güven bölgeleridir; kimlik sinyali tek başına yeterli değildir

C) Etki yalnız kullanılan yazılım sürümüyle belirlenir

D) Etki yalnız ağ segmentiyle belirlenir; kimlik önemsizdir

E) Etkiyi burada konuşamayız; yalnız modül 11’e bırakılmalıdır

Doğru: B
Kısa gerekçe: B identity ≠ authorization ayrımını doğru kurar. A yanlıştır; C/D tek boyutludur; E modül kapsamını gereksiz kısıtlar.

5) Üçüncü taraf bağımlılık izi görüldüğünde ilk doğru refleks hangisidir?

A) Hemen daha agresif doğrulamaya geçmek

B) Bağımlılığı görmezden gelmek; sorumluluk üçüncü taraftadır

C) Kontrol alanını ve paydaş koordinasyonunu netleştirmek; kanıt toplamanın “yeter” eşiğini belirlemek; deconfliction yapmak

D) Bağımlılığı rapora koymamak; yanlış anlaşılır

E) Bağımlılığı otomatik “kritik” etiketlemek

Doğru: C
Kısa gerekçe: C yönetişim, kapsam ve veri minimizasyonu açısından doğru kapıyı açar. A/E riskli varsayımdır; B/D bilgi kaybıdır.

6) Bir bulgu paketinde belirsizliği “doğru yönetme” örneği hangisidir?

A) “Kesin böyledir” yazmak; kaynak/bağlam vermemek

B) Sadece gözlemi yazıp yorumu tamamen dışarıda bırakmak

C) Gözlem–yorum ayrımı yapmak; varsayımları ve karşı kanıtı belirtmek; confidence’ı gerekçelendirmek

D) Yalnız yorum yazmak; ham sinyali atlamak

E) Sadece ekran görüntüsü/araç çıktısı eklemek; açıklama yapmamak

Doğru: C
Kısa gerekçe: C denetlenebilirlik sağlar. A/D/E kanıt standardını düşürür; B karar değerini azaltır.

7) OPSEC açısından “testin sonucu testin kendisiyle bozulmasın” uyarısı en çok neyi hedefler?

A) Ne kadar görünür olursak ölçüm o kadar doğru olur

B) Savunma sistemleri davranışı değiştirebilir; bu yüzden görünürlük maliyeti ve koşul etkisi kanıtta ayrıştırılmalıdır

C) OPSEC yalnız gizli iletişim demektir

D) OPSEC sadece araç seçimiyle sağlanır

E) OPSEC yalnız dış ağda geçerlidir

Doğru: B
Kısa gerekçe: B ölçüm bozulması riskini doğrudan adresler. A tersidir; C/D/E aşırı dar yorumdur.

8) Bir hipotez için ikinci bağımsız kanıt sınıfı bulunamıyor; sinyal de tamamen çürütülemiyor. En olgun çıktı hangisidir?

A) Yüksek confidence yazmak; rapor güçlü görünsün

B) Hipotezi doğru kabul etmek; sonraki modülde açığa çıkar

C) Hipotezi dar kapsamla düşük/orta confidence olarak taşımak; hangi kanıt bulunursa yükseleceğini yazmak; risk kapısını korumak

D) Hipotezi hiç rapora koymamak

E) Alarm almak için görünürlüğü artırmak; alarmı kanıt saymak

Doğru: C
Kısa gerekçe: C dürüst belirsizlik yönetimidir. A/B/E yanlış kesinlik üretir; D gereksiz bilgi kaybı olabilir.

9) Initial access bulgusunu modül 12’ye (tespit perspektifi) en doğru bağlayan ifade hangisidir?

A) “Savunmayı ilgilendirmez; erişim yeterlidir.”

B) “Bulguyu doğrulamak ve izlemek için hangi telemetri/logların nerede toplanması gerektiğini belirtmeliyim.”

C) “Telemetri yalnız olay sonrası gerekir.”

D) “OPSEC nedeniyle hiçbir şey yazmamak gerekir.”

E) “Tespit savunmanın işi; rapora gerek yok.”

Doğru: B
Kısa gerekçe: B bulguyu iyileştirmeye çeviren köprüdür. A/C/D/E operasyonel değeri düşürür.

10) Bir farkındalık testinde tıklama oranı yüksek çıkıyor. İleri seviye raporlama bunu nasıl çerçevelemelidir?

A) “Kullanıcılar hatalı; sorun budur.”

B) “Başarı = tıklama; erişim kanıtıdır.”

C) “İnsan hatası varsayımı gerçekleştiğinde, teknik kontrollerin (geçit, tarayıcı/OS, uç nokta, proxy) hangi halkada yetersiz kaldığı kanıtla gösterilmeli; iyileştirme buna bağlanmalıdır.”

D) “Veri anlamsız; rapordan çıkarılmalı.”

E) “Yalnızca eğitim önerisi yeterlidir; teknik kontrol gerekmez.”

Doğru: C
Kısa gerekçe: C savunma derinliği yaklaşımıyla ölçülebilir kontrol boşluğunu hedefler. A suçlayıcıdır; B yanlış eşlemedir; D bilgi kaybıdır; E tek katmanlı çözümdür.

Bu Modülde Kazanılan Yetkinlikler

Initial access'i "teknik deneme" değil, varsayım testi + karar dosyası üretimi olarak kurgulamayı
Modül 4 bulgularını hipoteze çevirirken karşı kanıt, bağımsız doğrulama ve confidence dili kullanmayı
Kapsam-kanıt-risk üçlüsüyle go/no-go kapıları kurarak ölçülü ilerlemeyi
Kimlik sinyali ile etki iddiasını ayırıp, yetkilendirme sınırları üzerinden değerlendirmeyi
False positive maliyetini azaltmak için "iddiayı büyütme" yerine kanıtı büyütme refleksini
Çıktıyı telemetri ve kontrol önerileriyle modül 12-17 iyileştirme hattına bağlamayı

MODÜL 6 — İleri Web Uygulama ve API Pentest

Modül Teması

Modern Saldırı Yüzeyi

SPA, GraphQL, gRPC ve WebSocket.

Auth & Session

OAuth/OIDC, JWT, SSRF ve federation hataları.

Business Logic

İş mantığı, race ve workflow zafiyetleri.

Bu modül, web ve API güvenliğini "tek tek zafiyet yakalama" refleksinden çıkarıp yetki sınırları, akış tutarlılığı ve zincir kurulabilir tasarım kusurları üzerinden okumayı öğretir. İleri seviyede hedef; bir sinyali aceleyle "yüksek etki" diye etiketlemek değil, kanıt standardında doğrulamak, belirsizliği doğru yönetmek ve bulguyu iş etkisine bağlayacak şekilde paketlemektir. Bu bakış, Modül 7'deki zincirleme saldırı tasarımının temelini; Modül 12'deki tespit perspektifinin ise "ne görünür, ne görünmeli?" köprüsünü oluşturur.

Bu Modülde Hedeflenen Kazanımlar

Yetkilendirme kırılmalarını (özellikle nesne/işlem düzeyi erişim kontrolü hataları) gözlem-yorum ayrımıyla doğrulayıp kanıt standardında raporlamak
SSRF/XXE/deserialization gibi modern risk sınıflarını "nasıl yapılır"a girmeden risk modeli + doğrulama kalitesi çerçevesiyle değerlendirmek
API'lerde authn/authz ayrımı, abuse (iş mantığı istismarı) senaryoları ve ölçülebilir kanıt üretimini birlikte düşünmek
OAuth/OIDC dünyasında yanlış konfigürasyonları "protokol ezberi" yerine yetki modeli + token bağlamı + belirsizlik yönetimi ile analiz etmek
Thick client ve modern istemci yüzeylerinde güven sınırını doğru kurup bulguları minimum zarar + OPSEC ilkeleriyle zincirlenebilir biçimde paketlemek

1) Yetkilendirme kırılmaları: "Kimsin?" değil "Ne yapabilirsin?"

Web/API değerlendirmelerinde en pahalı kusurların önemli bir kısmı, kodun "teknik hatası"ndan çok tasarım kusuru kaynaklı Broken Access Control sınıfında toplanır; OWASP Top 10'da bu risk alanı uzun süredir en üst sıralarda yer alır.

1.1. Nesne düzeyi erişim kontrolü: IDOR/BOLA mantığı (object boundary)

API dünyasında klasik "IDOR" refleksi, daha genel bir dille BOLA (Broken Object Level Authorization) olarak düşünülür. OWASP API Security Top 10'da bu konu en kritik risklerden biri olarak ayrı ele alınır. İleri seviye bakışta mesele "ID'nin tahmin edilebilirliği" değil; sunucu tarafında sahiplik/rol/tenant gibi kuralların tutarlı uygulanıp uygulanmadığıdır.

İddia kurma (dar ve test edilebilir): "Bu nesneye erişim, bağlama göre tutarlı bir policy enforcement ile korunmuyor olabilir."
Kanıt üretimi (minimum veri): İddiayı; farklı rol/bağlamlarda aynı kuralın aynı sonucu üretip üretmediğini gösteren minimal kanıtlarla güçlendirirsiniz. Kanıt, "ne gördüm?" kısmını (gözlem) "ne anlama geliyor?" kısmından (yorum) ayırır.
Karşı kanıt arama: Tutarlı "access denied" davranışı, policy enforcement log izleri, farklı istemci türlerinde (web/mobil) aynı kararın üretilmesi gibi sinyaller iddianızı zayıflatabilir.
UUID yanılsaması: Nesne kimlikleri tahmin edilemez formatta olsa bile, eğer kimlik başka bir akıştan sızıyor veya yanlış bağlamda yeniden kullanılabiliyorsa nesne düzeyi yetkilendirme yine kırılabilir. "UUID var → erişim kontrolü var" sonucu çıkarılmaz.

Örnek: example.org üzerinde "sipariş detay" akışında bir tutarsızlık sezdiğinizde, "veri sızıntısı" iddiasını büyütmek yerine; farklı rol bağlamlarında aynı nesneye ilişkin kararın tutarlılığını gösteren, kişisel veri minimizasyonu gözeten bir kanıt paketi üretirsiniz (gözlem: davranış; yorum: kural tasarımı zayıf olabilir; karşı kanıt: policy enforcement tutarlıysa iddia daralır).

1.2 İşlem/fonksiyon düzeyi yetkilendirme: BFLA (action boundary)

Bazı sistemlerde "nesneye erişim" doğruyken, aksiyon sınırları yanlış çizilir: onay/iptal/iade/rol atama gibi işlemler doğru rol + doğru durum (state) koşullarına bağlanmamış olabilir.

İleri seviye doğrulama yaklaşımı şunları arar:

State machine tutarlılığı: Aksiyonun hangi ön koşullarla mümkün olduğu, hangi sırayla ilerlediği, hangi adımda hangi yetki kontrolünün devreye girdiği
Belirsizliği yönetme: "Bazen oluyor" gibi sinyallerde; cache, replica, eventual consistency veya yarış durumlarını alternatif açıklama olarak düşünmek
İzlenebilirlik: İsteğin zamanı, bağlamı, rol bilgisi ve karar noktalarının kanıt zincirine bağlanması

Dikkat: Yetkilendirme bulgularında en büyük hata, tek gözlemi doğrudan "yüksek etki" ilan etmektir. İleri seviye bulgu; kanıt + etki argümanı + tekrar üretilebilir doğrulama mantığı ister. Etkiyi ölçemiyorsanız iddiayı daraltın ve confidence seviyesini gerekçeli biçimde düşürün.

1.3. Erişim kontrolü matrisi: dikey/yatay düşünme

Yetkilendirme testini "endpoint listesi" gibi değil, bir yetki matrisi gibi düşünmek kaliteyi yükseltir:

Dikey erişim: Düşük yetkili rolün yüksek yetkili fonksiyonlara erişimi
Yatay erişim: Aynı seviyedeki roller arasında izolasyonun bozulması (kullanıcılar arası sınır)

İpucu: Yetkilendirmeyi bir "yetki grafı" olarak modelleyin: Rol → kaynak → aksiyon ilişkisini çizdiğinizde, hangi kontrolün nerede eksik olabileceği görünür hale gelir. Bu kas, Modül 10'daki kimlik/graf düşüncesiyle aynıdır.

1.4. Kalite kapıları: false positive maliyeti ve minimum zarar

Yetkilendirme hatalarında false positive maliyeti yüksektir: ürün ekibini yanlış iyileştirmeye iter, güven kaybettirir. Bu yüzden:

Tek seferlik sapmaları (geçici tutarsızlıklar) "kanıt" diye şişirmeyin
Kanıt paketine "fikrim hangi koşulda değişir?" bölümünü ekleyin
Veri minimizasyonu uygulayın: kanıt, gereksiz ifşa yaratmamalı

2) SSRF / XXE / Deserialization: "tek bug" değil "güven sınırı kırılması"

Bu risk sınıflarının ortak paydası, uygulamanın girdi, erişim veya işleme sırasında yanlış bir "güven varsayımı" yapmasıdır. İleri seviye raporlama dili "tekniği yaptım" değil; hangi varsayım kırılıyor, iş etkisi ne, hangi kontrol önlemeli, hangi telemetri yakalamalı şeklinde olmalıdır (Modül 12'ye köprü).

2.1. SSRF: uygulamanın "kendi adına istek atması" risk modeli

SSRF değerlendirmesinde odak:

Uygulamanın erişebildiği ağ bölgeleri (iç servisler, yönetim arayüzleri, bulut servislerine ait link-local uçlar vb.)
Egress kontrolü ve allowlist/proxy politikaları
"İstek gerçekten uygulama adına mı çıktı?" sorusuna yanıt veren izlenebilir kanıt (uygulama/ağ telemetrisiyle ilişkilendirilebilir)

Bazı SSRF türlerinde uygulama yanıtı doğrudan görünmeyebilir (kör/blind davranışlar). Bu durumda ileri yaklaşım, "sonuç gördüm" demek yerine, sistemin dış dünyayla kurduğu etkileşimi zararsız ve izinli doğrulama sinyalleriyle kanıt standardına taşımayı hedefler (RoE ve OPSEC sınırları içinde).

2.2. XXE: XML işleme zincirinde "girdi güveni" yanılgısı

XXE riski, modern JSON ağırlıklı sistemlerde daha az görünse de; legacy entegrasyonlar, belge işleme, eski servis protokolleri gibi alanlarda hâlâ çıkabilir. İleri seviye yaklaşım:

XML işleme nerede devrede (yükleme, entegrasyon, dönüşüm hattı)?
Parser konfigürasyonu ve dış kaynak çözümleme politikası nasıl?
Doğrulama, saldırı adımı üretmeden; davranışı ölçen ve telemetriye bağlanabilen kanıtlarla yapılır.

2.3. Deserialization: "veri nesneye dönüşürken sınır kaybı"

Güvensiz deserialization'da risk, güvenilmeyen verinin bütünlük/bağlam doğrulaması olmadan "çalışan nesne" formuna taşınmasıyla doğar. İleri seviye doğrulama ve raporlama:

Veri hangi katmanda nesneye dönüşüyor?
İmzalama/bağlam doğrulaması var mı?
Üretimde yan etki riski nedeniyle kanıt üretimi non-destructive olmalı; amaç "zarar vermeden doğrulama"dır.

İpucu: SSRF/XXE/deserialization bulgularını yazarken "RCE olabilir" gibi genellemeler yerine, varsayım → kontrol boşluğu → ölçülebilir kanıt → olası iş etkisi hattını kurun. Bu, savunma ekiplerinin doğru kontrolü doğru yere koymasını sağlar.

3) API güvenliği: authn/authz, abuse senaryoları ve ölçülebilir kanıt

API'lerde en pahalı problemler çoğu zaman klasik enjeksiyonlardan değil; iş mantığı abuse, yetkilendirme kırılması ve tasarımsal yüzey özelliklerinden gelir.

3.1. Authn ≠ Authz: "token var" demek "yetkili" demek değildir

Kimlik doğrulama başarılı olabilir; ancak yetkilendirme yanlış tasarlanmışsa risk büyür. İleri seviye doğrulamada:

Token'ın varlığından çok bağlamına bakılır: scope, audience, tenant, client türü
"İstek kabul edildi" gözlemi, otomatik olarak "policy'ye uygun" yorumu haline getirilmez
Farklı rol/tenant/istemci bağlamlarında tutarlılık ve karşı kanıt aranır

3.2. REST / GraphQL: yüzey farkı, riskin şekli

Burada amaç "şu kötü" ezberi değil; yüzeyin risk profilini okumaktır.

REST: Endpoint sınırları belirgindir; risk çoğunlukla kaynak/aksiyon düzeyinde yetkilendirme ve iş akışı tutarlılığında yoğunlaşır.
GraphQL: Tek uçtan çoklu veri seçimi; risk çoğunlukla aşırı veri ifşası, alan bazlı yetki tutarsızlığı ve sorgu karmaşıklığının doğurduğu kaynak tüketimi senaryolarında belirginleşir (tasarıma bağlı).
Keşif özellikleri: Bazı şema keşif mekanizmaları doğru yönetilmezse saldırı yüzeyini görünür kılabilir; bu "doğrudan exploit" değil ama savunma için önemli bir maruziyettir.

3.3. Mass Assignment ve model bağlama riskleri (tasarım kusuru)

Bazı sistemlerde gelen alanlar "nesne modeline" kontrolsüz bağlanabilir. İleri seviye analizde odak:

Hangi alanlar kullanıcı girdisi olmalı, hangileri sunucu tarafından türetilmeli?
Yetki/rol gibi alanlar istemci girdisiyle taşınabiliyor mu?
Kanıt, gereksiz zarar vermeden "model bağlama kontrolü eksik" iddiasını doğrular.

3.4. Abuse senaryoları: oran/akış/iş kuralı kırılması

İleri API değerlendirmesi "tek istek"ten çok akış okur:

Rate limiting / kota politikaları, iş hedefiyle uyumlu mu?
Idempotency, tekrar deneme ve hata durumları iş etkisini artırıyor mu?
HTTP seviyesinde "1 istek" görünen ama uygulama seviyesinde "N operasyon"a dönüşebilen desenlere karşı kontrol noktaları doğru mu?

İpucu: Abuse analizinde başarı, yüksek gürültüyle "bir şeyler oldu" demek değil; düşük gürültüyle iş kuralı zayıflığını kanıt standardında gösterebilmektir. OPSEC ve minimum zarar bütçesini en başta tanımlayın.

4) OAuth / OIDC yanlış konfigürasyonları: protokol ezberi değil güven varsayımları

OAuth/OIDC doğru tasarlanırsa güçlü bir kimlik çerçevesi sunar; yanlış tasarlanırsa kimlik ve yetki çizgilerini bulanıklaştırır. İleri seviye yaklaşım, tipik yanlışları kategori olarak tanır ve doğrulama mantığını kanıt zincirine bağlar.

4.1. Sık görülen yanlış konfigürasyon kategorileri

Audience / scope modelleme hataları: Token "kime" ve "neye" yetkili?
Redirect URI ve client policy tutarsızlıkları: Güven sınırı nerede başlar/nerede biter?
Token yaşam döngüsü: süre, yenileme, iptal, oturum yönetimi
Çoklu tenant / çoklu ortam sızıntıları: dev/stage/prod arası politika bulaşması

4.2. State parametresi ve oturum bağlama: belirsizliği azaltan kontrol

OAuth/OIDC akışlarında "state" gibi mekanizmalar, istemci isteğiyle yanıtı ilişkilendirerek bazı saldırı sınıflarına karşı koruma sağlar; pratikte özellikle CSRF riskini azaltmak için yaygın bir kontrol olarak kullanılır. İleri seviye raporlama dili:

Gözlem: Hangi bağlamda hangi token/claim davranışı görüldü?
Yorum: Hangi yanlış varsayıma işaret ediyor olabilir?
Karşı kanıt: Enforcement logları ve farklı istemcilerde tutarlılık var mı?
Confidence: Hangi veri eksik, hangi koşulda fikrim değişir?

5) Thick client ve modern istemciler: saldırı yüzeyi okuryazarlığı (zincir düşüncesiyle)

Modern sistemlerde istemci yalnız tarayıcı değildir: mobil uygulamalar, masaüstü istemciler, embedded webview, background sync ve offline cache yüzeyi genişletir.

İleri seviye bakış:

İstemci tarafını "güven sınırı" olarak değil, kanıt kaynağı olarak konumlandırır
Yetkilendirme kararının nerede verildiğini netleştirir (sunucu mu, istemci mi?)
Yerel depolama alanlarında token/secret gibi varlıkların tutulması riskini, iş etkisi ve savunma kontrolüyle birlikte değerlendirir
Trafik görünürlüğünü engelleyen mekanizmalar (ör. certificate pinning) söz konusuysa, bunun yönetimi RoE, test ortamı ve minimum zarar ilkeleriyle ele alınır; amaç "bypass tarifi" değil, görünürlük gereksinimi ve savunma iyileştirmesi çıkarmaktır.

Örnek: example.net'in mobil istemcisinde iki farklı akışın aynı backend kaynağına farklı güven varsayımlarıyla eriştiği şüphesinde; iddiayı büyütmeden, akış tutarlılığı ve rol/tenant bağlamını kanıt zincirine bağlayıp zincirlenebilir risk olarak paketlemek.

Terimler Sözlüğü

Terim	Açıklama
Broken Access Control	Erişim kontrolünün tasarım/uygulama hataları nedeniyle kırılması (yetkisiz erişim/aksiyon)
IDOR	Nesne düzeyi erişim kontrolünün zayıf tasarlanması (nesne sahipliği/rol kontrolü tutarsızlığı)
BOLA	API bağlamında nesne düzeyi yetkilendirme kırılması (OWASP API Top 10’da kritik risk)
BFLA	İşlem/aksiyon düzeyinde yetkilendirme kırılması (fonksiyon sınırlarının yanlış çizilmesi)
Access Control Matrix	Rol/kaynak/aksiyon ilişkisini matriste modelleme yaklaşımı
State machine	İş akışlarının “durumlar ve geçişler” olarak modellenmesi (ön koşul/sonuç tutarlılığı)
Eventual consistency	Dağıtık sistemlerde geç tutarlılık; geçici tutarsızlıkların FP üretme riski
SSRF	Sunucunun, uygulama adına istek atma kabiliyetinin güven sınırını kıracak risk üretmesi
OOB (Out-of-Band)	Doğrulama sinyalinin doğrudan yanıt kanalından değil, ayrı bir etkileşim kanalından gözlemlenmesi
XXE	XML işleme sırasında dış varlık çözümleme varsayımlarından doğan risk sınıfı
Insecure Deserialization	Güvenilmeyen verinin nesneye dönüştürülmesi sırasında kontrol kaybı riski
Authn	Authentication; kimlik doğrulama
Authz	Authorization; yetkilendirme
Scope	Token’ın yetki kapsamını ifade eden sınır
Audience	Token’ın hangi hedef servis için üretildiğini ifade eden bağlam
Mass Assignment	İstemciden gelen alanların kontrolsüz biçimde model nesnesine bağlanması riski
GraphQL Introspection	Şema keşfi özelliği; yanlış yönetilirse saldırı yüzeyini görünür kılabilir
Query depth/complexity	Sorgu derinliği/karmaşıklığı; kaynak tüketimi riskini etkileyen faktör
Batching	Tek istek içinde çoklu operasyon taşıma deseni; rate limiting tasarımını etkileyebilir
Rate limiting	Oran sınırlama; belirli süre içinde istek/operasyon sayısını sınırlayan kontrol
OAuth 2.0	Yetkilendirme çerçevesi
OIDC	OAuth üzerine kimlik katmanı ekleyen yapı
Redirect URI	Kimlik akışı tamamlanınca yönlendirme yapılan geri dönüş adresi politikası
State parameter	İstek-yanıt ilişkilendirme; özellikle CSRF riskini azaltmada kullanılan mekanizma
Thick client	İş mantığının kayda değer kısmı istemci tarafında çalışan modern istemciler
Certificate pinning	İstemcinin belirli sertifikalara sabitlenmesi; görünürlük yönetimini zorlaştırabilir
OPSEC	Operasyon güvenliği; gürültü, izlenebilirlik, zarar minimizasyonu disiplinleri

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Düşük yetkili bir kullanıcı bağlamında “başkasına ait nesneye erişim” şüphesi, yalnızca tek bir bölgede ve aralıklı biçimde gözleniyor. En olgun doğrulama ve raporlama yaklaşımı hangisidir?

A) Bulguyu “kritik veri sızıntısı” diye kesinleyip önceliği en üste yazmak

B) Tek gözleme dayanıp etkiyi maksimum varsayarak zinciri genişletmek

C) İddiayı daraltıp alternatif açıklamaları (tutarlılık, cache/replica, state) yazmak; karşı kanıt aramak; confidence’ı kanıtla gerekçelendirmek

D) Belirsizlik varsa rapora hiç almamak

E) Üretimde test yoğunluğunu artırarak “her yerde oluyor mu”yu zorlamak

Doğru: C
Kısa gerekçe: C, kanıt standardı ve belirsizlik yönetimini uygular. A/B yanlış kesinlik üretir; D bilgi kaybına yol açar; E minimum zarar/OPSEC riskini büyütür.

2) Aşağıdakilerden hangisi IDOR/BOLA riskini “kimlik doğrulama” probleminden ayıran en doğru ifadedir?

A) Yalnızca oturum açılmadan gerçekleşir

B) Authn doğru olsa bile, nesne sahipliği/rol/tenant kontrolünün sunucu tarafında tutarlı uygulanmamasıyla doğar

C) Yalnızca istemci tarafı hatasıdır

D) Sadece veritabanı sürümüyle ilgilidir

E) Sadece API’de olur; web’de olmaz

Doğru: B
Kısa gerekçe: B, authn–authz ayrımını doğru kurar. Diğerleri kavramı yanlış daraltır/geneller.

3) Bir API’de “token var ve istek kabul edildi” gözlemi var. Bunun “yüksek etki” iddiasına dönüşmesi için en kritik ek bilgi hangisidir?

A) Token’ın varlığı yeterlidir

B) Token’ın scope/audience/tenant/client bağlamının yetki modeliyle uyumu ve karar tutarlılığı

C) İsteğin hızlı dönmesi

D) İstemcinin mobil olması

E) Sunucunun işletim sistemi

Doğru: B
Kısa gerekçe: Etki, bağlam ve policy uyumu ile kanıtlanır; diğer seçenekler ikincildir.

4) SSRF/XXE/deserialization risklerini ileri seviyede ortaklaştıran kök problem hangisidir?

A) Hepsi sadece eski sistemlerde görülür

B) Hepsi kullanıcı hatasına dayanır

C) Uygulamanın güven varsayımlarının (girdi/erişim/işleme) yanlış olması ve bunun izlenebilir kanıtla doğrulanması gereği

D) Hepsi yalnızca WAF ile çözülür

E) Hepsi yalnızca ağ segmentasyonu ile çözülür

Doğru: C
Kısa gerekçe: C, “güven sınırı” perspektifini doğru kurar; D/E tek kontrol genellemesidir.

5) GraphQL yüzeyinde ileri seviye risk değerlendirmesinde en doğru yaklaşım hangisidir?

A) GraphQL her zaman güvensizdir; otomatik kritik yazılır

B) Endpoint sayısı azsa güvenlidir

C) Şema/alan bazlı yetki tutarlılığı, aşırı veri ifşası ve sorgu karmaşıklığı riskleri kanıt standardında değerlendirilir

D) Sadece performans ölçülür; güvenlikle ilgisi yoktur

E) Sadece istemci kodu incelenir; sunucu davranışı önemsizdir

Doğru: C
Kısa gerekçe: C tasarım odaklıdır ve kanıt standardına uygundur.

6) OAuth/OIDC tarafında “state” mekanizmasını güvenlik açısından en doğru konumlandıran ifade hangisidir?

A) Sadece kullanıcı deneyimi için vardır; güvenlikle ilgisi yoktur

B) İstek-yanıt ilişkilendirmesiyle bazı saldırı sınıflarına karşı korumaya katkı sağlayan bir kontrol mekanizmasıdır

C) Tek başına tüm hesap ele geçirme risklerini ortadan kaldırır

D) Sadece sunucu tarafında anlamlıdır; istemci uygulaması için gereksizdir

E) Sadece mobil uygulamalarda kullanılır

Doğru: B
Kısa gerekçe: B doğru rolü tarif eder; C aşırı genellemedir; diğerleri yanlış kısıtlamadır.

7) Bir “abuse” (iş mantığı istismarı) şüphesinde minimum zarar ilkesiyle uyumlu yöntem seçimi hangisidir?

A) Üretimde maksimum yoğunlukla denemek

B) Belirsizlik varsa daha agresif olmak

C) Operasyonel etki bütçesi belirleyip, düşük gürültüyle akış tutarlılığı ve kontrol davranışı üzerinden ölçülebilir kanıt üretmek

D) Kullanıcıları işlem yapmaya yönlendirerek kanıt toplamak

E) Belirsizlik varsa rapora hiç almamak

Doğru: C
Kısa gerekçe: C, OPSEC + kanıt standardı + minimum zarar dengesidir. A/B/D riskli ve etik açıdan sorunlu olabilir; E bilgi kaybıdır.

8) “Kanıt standardında paketleme” aşağıdakilerden hangisini zorunlu kılar?

A) Sadece ekran görüntüsü

B) Sadece etki tahmini

C) Gözlem–yorum ayrımı, izlenebilir bağlam/zaman, tekrar üretilebilir doğrulama mantığı ve karşı kanıt koşulları

D) Sadece araç isimleri listesi

E) Sadece CVSS skoru

Doğru: C
Kısa gerekçe: Denetlenebilirlik C ile sağlanır; diğerleri tek başına yetersizdir.

9) Thick client/modern istemcilerde ileri seviye “saldırı yüzeyi okuryazarlığı” çıktısı hangisidir?

A) İstemciyi tamamen tersine mühendislik yapmak

B) Sunucuyu önemsiz görüp istemciyi suçlamak

C) Yetkilendirme kararının nerede verildiğini ve akış tutarlılığını netleştirip, zincirlenebilir riskleri minimum zarar ile kanıtlayacak şekilde paketlemek

D) Sadece UI hatalarını raporlamak

E) “Mobil risklidir” diye genellemek

Doğru: C
Kısa gerekçe: C, zincir düşüncesi + kanıt standardı + yöntem seçimi üçlüsünü taşır.

10) Yetkilendirme kırılmalarında false positive’i azaltmak için en etkili ileri seviye refleks hangisidir?

A) Tek gözleme dayanıp bulguyu büyütmek

B) Etkiyi maksimum varsaymak

C) Alternatif açıklamaları (tutarlılık, state, dağıtık mimari etkileri) değerlendirip karşı kanıt aramak; iddiayı kanıt büyüdükçe genişletmek

D) Belirsizlik varsa tüm bulguları atmak

E) Üretimde daha fazla deneme yapmak; ne olursa olsun kanıt saymak

Doğru: C
Kısa gerekçe: C, “iddiayı değil kanıtı büyütme” disiplinidir; diğerleri ya yanlış kesinlik ya da operasyonel risk üretir.

Bu Modülde Kazanılan Yetkinlikler

Web/API'de en kritik alanın yetkilendirme sınırları olduğunu ve etkiyi bu sınırlar üzerinden okuma disiplinini kurdun.
IDOR/BOLA ve BFLA sınıflarında, sinyali gözlem-yorum-karşı kanıt zinciriyle kanıt standardına taşımayı öğrendin.
SSRF/XXE/deserialization risklerini "how-to"ya girmeden, güven varsayımı ve ölçülebilir doğrulama perspektifiyle değerlendirdin.
API'lerde authn/authz ayrımı, REST/GraphQL yüzey farkları, abuse senaryoları ve rate limiting tasarımının kritik noktalarını minimum zarar çerçevesinde ele aldın.
OAuth/OIDC yanlış konfigürasyonlarını "protokol ezberi" yerine yetki modeli + token bağlamı + belirsizlik yönetimi ile raporlayabilir hale geldin.
Thick client ve modern istemci yüzeyinde bulguları, zincir düşüncesine uygun biçimde ve savunma iyileştirmesine bağlayarak paketlemeyi pekiştirdin.

MODÜL 7 — Exploitation Stratejisi & Zincirleme Saldırı Tasarımı

Modül Teması

Exploit Seçimi

Güvenilirlik, gürültü ve etki dengesi.

Chain Tasarımı

Düşük etkili zafiyetlerin kritik etkiye birleşimi.

Reliability

Stabilite, idempotency ve geri alınabilirlik.

Bu modül, "exploitation"ı tek bir teknik hamle olarak değil; karar kalitesi, iş sürekliliği, operasyonel sınırlar (RoE), kanıt standardı ve zincir tasarımı üzerinden ele alır. Modül 6'da web/API kaynaklı bulguların nasıl üretildiğini konuşmuştuk; burada odak, bu bulguları kanıta dayalı bir patikaya dönüştürmek, her adımın yan etkisini ve tespit maliyetini ölçmek ve sonucu Modül 17'deki raporlama standardına uygun şekilde iş etkisine bağlamaktır. Bir sonraki adım olan Modül 8'de (post-exploitation) "erişimden sonra" neyin nasıl değerlendirileceğini ele alacağız; bu modül ise o kapıya girmeden önce, kapıyı hangi şartlarda ve hangi kanıtla açtığını olgunlaştırır.

Bu Modülde Hedeflenen Kazanımlar

Exploitation kararını "çalışır mı?" düzeyinden çıkarıp go/no-go mantığıyla (güvenilirlik-yan etki-geri dönüş-öncelik) yönetebilmek
Düşük riskli görünen bulguları birleştirerek zincirleme saldırı patikası tasarlamak; zinciri "uzun" değil kanıtlanabilir ve iş hedefiyle ilişkili kurmak
Kaynak-iddia-kanıt ayrımını görünür kılıp karşı kanıt arayarak belirsizliği doğru yönetmek; confidence dilini gerekçelendirmek
Noise/false positive/OPSEC/etik sınırları birlikte değerlendirerek yöntem seçimini olgunlaştırmak
Teknik bulguyu "shell başarısı" gibi iç jargonla bırakmayıp iş etkisine ve savunma iyileştirmesine çevirmek; "minimum zarar" prensibini korumak

1) Exploitation kararını stratejiye çevirmek: go/no-go mantığı

İleri seviyede exploitation, "zafiyet var → deneriz" refleksi değildir. Canlı (production) ortamlarda doğru yaklaşım, bir tetiği çekmeden önce merminin nereye gideceğini ve namlunun ısınıp ısınmayacağını hesaplamaktır: aynı teknik hamle, bir ortamda masum bir doğrulama iken başka bir ortamda kesinti riski yaratabilir.

1.1. Karar matrisi: güvenilirlik, yan etki, geri dönüş, hedef önceliği

Bir sinyali değerlendirmeden "ilerlemek" yerine, kararını şu eksenlerde kurarsın:

Doğrulama kalitesi: Sinyal gerçekten neye dayanıyor? "Sürüm/baner" gibi tekil ipuçları yerine davranışsal kanıt aramak, yanlış yönlenmeyi azaltır.
Güvenilirlik (stability/reliability): Aynı koşullarda tekrarlanabilir mi, yoksa zamanlama/bağlam değişince kırılıyor mu?
Yan etki (blast radius): Servisi bozma, veri tutarsızlığı, alarm fırtınası, operasyonel ekiplerle çakışma riski var mı?
Geri dönüş (rollback): Beklenmeyen bir etki olursa zarar büyümeden durdurma ve sistemi stabilize etme planın var mı?
Hedef önceliği: Bu adım, senaryonun iş hedefiyle gerçekten bağlantılı mı; yoksa sadece "yapılabiliyor" diye mi cazip?

Dikkat: "İzin var" demek, "kesinti riski kabul edilebilir" demek değildir. İleri seviye disiplin, teknik merakı iş sürekliliğinin altına koyar; aksi, bulguyu güçlendirmek yerine itibarsızlaştırır.

1.2. Exploit olgunluğu: tek atımlık mı, tekrarlanabilir mi?

Bazı yöntemler "bir kere" çalışsa bile operasyonel kumar olabilir: koşullar değişince çalışmayan, çalışmadığında hizmeti kararsızlaştıran veya tek denemede ortamı bozup tekrar denemeyi anlamsızlaştıran yaklaşımlar, özellikle kritik sistemlerde tercih edilmez. Burada olgunluk ölçütü, "etkiyi maksimize etmek" değil; en az gürültüyle en güçlü kanıtı üretmektir.

Örnek: Kamuya mal olmuş bazı kritik zafiyetlerde, teorik olarak çok yüksek etki mümkün olsa bile, pratikte "deneme"nin servis kesintisi riski taşıdığı bilinir. İleri yaklaşım, bu riski büyütmek yerine zafiyetin varlığını zararsız doğrulama sinyalleri ve laboratuvar/benzer ortam kanıtı ile raporlamaya odaklanır.

1.3. Karar ağaçları: karmaşık sistemlerde kontrolü kaybetmemek

İleri ortamlar tek tip değildir: farklı node'lar, farklı konfigürasyonlar, trafik yükü, cache davranışları... Burada "tek adımlı karar" yetmez; karar ağacı yaklaşımı gerekir.

Karmaşık sistemlerde dallı karar ağaçları, confidence'ı artırır; çünkü her düğüm, "bunu görürsem şuna inanırım" mantığını zorlar.
Basit senaryolarda lineer akış operasyonel yükü azaltır; ancak esneklik düşer.

İpucu: Karar ağacında her düğüme şu soruyu ekle: "Beni yanlış çıkaracak karşı kanıt nedir?" Bu küçük alışkanlık, FP'yi dramatik biçimde azaltır.

2) Zincirleme saldırı tasarımı: küçük kırılmadan iş etkisine giden patika

Zincirleme düşünme, tek bir "büyük açık" bulamadığında yapılan teselli değildir; çoğu gerçek olayda etki, birden fazla küçük zayıflığın doğru sırayla birleşmesiyle doğar. İleri seviye tasarımın hedefi, zinciri "havalı" yapmak değil; kanıtlanabilir, kapsam içinde, minimum zararla ve iş hedefiyle ilişkili kurmaktır.

2.1. Zincirin anatomisi: misconfig → kimlik → yetki → hedef varlık

Zincirler çoğunlukla şu kontrol düzlemleri arasında akar:

Konfigürasyon düzlemi: yanlış güven varsayımları, eksik kısıtlar
Kimlik düzlemi: oturum/rol/tenant bağlamı, token sınırları
Yetki düzlemi: erişim kontrolü matrisi, ayrıcalık sınırları
Varlık düzlemi: kritik süreç ve "crown jewel" varlıklar

Bu ayrım "teori" değildir; doğrudan şu soruyu netleştirir: "Bu geçişi mümkün kılan güven varsayımı neydi ve bunu engellemesi gereken kontrol hangisiydi?"

Örnek: example.net üzerinde "düşük risk" görünen bir yapılandırma kusuru, tek başına sadece bilgi sızıntısı gibi görünebilir. Ancak bu sızıntı kimlik bağlamına (ör. yanlış kapsamlandırılmış bir erişim anahtarı) temas ediyorsa, zincirin ikinci halkası doğar. Ardından yetki sınırlarının zayıf olduğu bir noktaya bağlandığında, "küçük" bir bulgu, iş hedefiyle ilişkili bir patikaya dönüşebilir. Bu dönüşümün değerini belirleyen şey, iddia değil kanıt zinciridir.

2.2. Zinciri kurarken kalite kapıları: kanıt büyüdükçe iddia büyür

Zincirlemede en tehlikeli hata, ilk sinyali görünce "sonuca varmak"tır. Olgun yaklaşım tersidir:

Önce dar iddia (ne biliyorum?)
Sonra bağımsız doğrulama (bunu başka ne destekliyor?)
Sonra etki argümanı (bu neden önemli?)
Her adımda karşı kanıt (hangi bulgu çıkarsa bu halka düşer?)

Burada "kaynak-iddia-kanıt" ayrımı kritik bir temizlik sağlar:

Kaynak: log, telemetri, uygulama davranışı, konfigürasyon gözlemi
İddia: bunun ne anlama geldiği (hipotez)
Kanıt: hipotezi destekleyen ve tekrarlanabilir biçimde gösterilebilen doğrulama

İpucu: Zinciri tasarlarken "Bu bağlantıyı hangi değişken kırar?" sorusunu sor. Konfigürasyon değişikliği mi, ağ sınırı mı, rol ayrımı mı? Cevap, hem belirsizliği yönetir hem de savunma iyileştirmesine doğrudan girdi olur.

2.3. Sıralı mı paralel mi? Yöntem seçimi ve sınırlar

Aynı zinciri modellemenin birden fazla yolu olabilir:

Sıralı model: OPSEC açısından daha kontrollüdür; fakat derinlik ve hız sınırlanabilir.
Paralel model: ilişkileri daha görünür kılar; ancak noise ve FP riski artabilir, etik yük yükselir.

Seçim, "hangisi daha güçlü?" değil; "hangisi bu ortamda daha az riskle daha net kanıt üretir?" sorusuyla yapılır.

2.4. Modüler entegrasyon: zinciri parçalarla yönetmek

Zincir bileşenlerini modüler düşünmek (her halkayı ayrı doğrulama paketi gibi ele almak) esneklik sağlar: bir halka düşerse tüm zincir "çöp" olmaz; fail-soft yaklaşımıyla daha düşük riskli doğrulama adımlarına geri dönersin. Entegre/akış bazlı yaklaşım ise operasyonel yükü düşürebilir; fakat uyarlama esnekliği azalır.

3) Doğrulama, belirsizlik ve "confidence" dili

İleri seviye bir uzmanı ayırt eden şey, "doğruyu bulmak" kadar, doğruyu hangi eminlikle söylediğini yönetmesidir. Burada amaç belirsizliği saklamak değil; belirsizliği kontrollü bir değişken haline getirmektir.

3.1. Gözlem-yorum ayrımı ve izlenebilirlik

Kanıt paketinde şu disiplin görünür olmalı:

Gözlemi, yorumdan ayırmak
Zaman uyumunu korumak (hangi olay ne zaman oldu?)
İzlenebilir bağlam sunmak (hangi rol/tenant, hangi akış adımı?)
Tekrarlanabilirliği mümkün kılmak (aynı koşullarda aynı sinyal)

Zaman uyumsuz sinyaller (ör. farklı katmanlardan gelen tutarsız zaman damgaları) confidence'ı düşürür; ileri yaklaşım bunu "görmezden gelmek" yerine, iddiayı daraltarak ve ek doğrulama arayarak yönetir.

3.2. Tekil vektör mü çoklu kombinasyon mu?

Tekil vektör, operasyonel yükü azaltır; ancak yanlış pozitif riski büyüyebilir.
Çoklu kombinasyon, confidence'ı yükseltir; fakat OPSEC ve erken tespit riski artar, ayrıca etik sınırların yönetimi zorlaşır.

Bu nedenle "daha çok dene" değil, "daha iyi doğrula" yaklaşımı tercih edilir.

4) Kanıt üretimi ve raporlama hattı: teknik başarıdan iş etkisine

Birçok teknik bulgu, yönetim tarafında "anlam" üretmez. Bu, bulgunun değersiz olduğu anlamına gelmez; çeviri eksiktir. Exploitation sonrasında doğru iş, "ne kadar ileri gidebilirim?" değil, "neyi ispatladım ve bu neden önemli?" sorusunu kanıtla cevaplamaktır.

4.1. PoC ve silahlaştırma ayrımı: minimum kanıt, maksimum netlik

İzinli değerlendirme bağlamında çoğu senaryoda hedef, zafiyetin kullanılabilir olduğunu kanıtlamaktır; sistemi "tam ele geçirme" yönünde agresifleşmek, gereksiz risk doğurabilir. Kanıt, şu nitelikleri taşıdığında güçlüdür:

Gereksiz veri ifşası yok (minimum veri)
İnkar edilemezlik (bağlam net, tutarlılık yüksek)
Tekrar üretilebilirlik (koşullar tarif edilebilir)
Etik sınırlar korunur (veriyi "görmek" ile "yaymak/değiştirmek" ayrılır)

Örnek: example.com üzerinde kritik bir veri alanına erişim riskini göstermek için, gerçek kişisel veriyi topluca çekmek yerine; yalnızca erişim kontrolünün kırıldığına dair asgari ve bağlamsal kanıt üretmek, hem etik hem operasyonel olarak daha olgundur.

4.2. İş etkisini kurmak: risk dili + kontrol hedefi

İş etkisi, "felaket senaryosu" yazmak değildir. İleri seviye etki anlatımı şunları netleştirir:

Etkilenen iş süreci (yetkisiz işlem, yanlış karar, uyum riski vb.)
Etkinin koşulları (hangi rol/bağlam, hangi ön koşullar)
Etkiyi azaltan/engelleyen mevcut kontroller (varsa karşı kanıt)
Önerinin biçimi: "şunu çalıştır" değil, kontrol hedefi + doğrulama kriteri

Bu hat, Modül 17'deki profesyonel raporlama ve paydaş iletişimiyle doğrudan birleşir.

4.3. Zincir diyagramı mı, özet tablo mu?

Raporlamada yöntem seçimi de tradecraft'tır:

Detaylı zincir diyagramları, belirsizliği azaltır ve yanlış anlaşılmayı önler; ancak hazırlama maliyeti ve operasyonel yük artabilir.
Özet risk tabloları, karar vericiyi hızlandırır; fakat derinlik kaybı riski taşır.

Olgun yaklaşım, ikisini birlikte kullanır: "hikâyeyi" diyagramla kurar, "kararı" tabloda kolaylaştırır.

5) Güvenli durdurma ve kapsam koruma: disiplinin asıl testi

Exploitation başarılı olduğunda adrenalin artar ve "scope creep" riski büyür. Bu an, ileri seviye olgunluğun en net ölçüldüğü andır.

5.1. İlk dakikalar: dur, bağlamı doğrula, stabilize et

Nerede olduğunu ve bunun RoE kapsamına ait olup olmadığını netleştir
Ortam kararlı mı, beklenmeyen yan etki var mı?
Gerekirse yetkili irtibat (white card) üzerinden kontrollü koordinasyon sağla
Kapsam dışı yüzeylere (iş ortağı ağları, üçüncü taraf sistemler gibi) "görünüyor" diye ilerleme: kapsam dışı her adım, teknik olmaktan çıkar, hukuki probleme dönüşür

5.2. Temiz bırakma ve izlerle ilişki: loglar "düşman" değil kanıttır

Test sonunda ortam "temiz" bırakılmalıdır; fakat bu, savunma verisini tahrip etmek anlamına gelmez. İleri seviye pratikte:

Operasyon sırasında bırakılmış geçici artefaktlar ve değişiklikler kontrol altında geri alınır
Sistem kayıtları/izleri kurcalanmaz; aksine tespit değerlendirmesi için hangi sinyallerin nerede oluştuğu raporlanır (Modül 12 ile uyum)

Dikkat: İzleri "silmek", izinli değerlendirmede sahte bir başarı hissi üretir. Asıl değer, savunmanın neyi görüp neyi kaçırdığını kanıtla göstermek ve iyileştirmeyi tetiklemektir.

Terimler Sözlüğü

Terim	Açıklama
Exploitation	İstismar; bir zayıflığın etkisini kontrollü biçimde doğrulama ve kanıt standardında gösterme yaklaşımı
Attack Chaining	Birden fazla düşük/orta riskli bulguyu birleştirerek yüksek etkili bir saldırı patikası oluşturma
Karar matrisi (Go/No-Go)	İlerleme kararını doğrulama kalitesi, güvenilirlik, yan etki, geri dönüş ve hedef önceliğiyle değerlendirme
Stability / Reliability	Aynı koşullarda tekrarlanabilirlik; sonucun bağlama duyarlı veya kırılgan olup olmaması
Side effect / Blast radius	Servis kesintisi, veri tutarsızlığı, alarm fırtınası gibi yan etkiler ve bunların yayılma kapsamı
Rollback	Beklenmeyen etki oluştuğunda güvenli durdurma ve sistemi stabilize etme yaklaşımı
Counter-evidence	İddiayı zayıflatacak karşı kanıt; FP riskini düşürür, confidence’ı gerekçelendirir
Confidence	Bulgudaki eminlik seviyesi; kanıta dayalı gerekçe ve hangi şartlarda değişeceğiyle birlikte ifade edilir
Noise	Log/telemetri/alarm gürültüsü; operasyonel yükü ve erken tespit riskini artırabilir
False Positive (FP)	Yanlış bulgu; kaynak israfı ve yanlış iyileştirme riskine yol açar
OPSEC	Operasyon güvenliği; gereksiz görünürlük ve ilişkilendirilebilirliği azaltma disiplini
Scope Creep	Operasyonun izinli sınırların dışına istemli/istemsiz taşması
Proof of Concept (PoC)	Zafiyetin pratikte kullanılabilir olduğunu gösteren, minimum riskli kanıt üretimi yaklaşımı
Weaponization	Zafiyeti kalıcı/etkisi yüksek senaryolara dönüştürme; izinli değerlendirmede çoğu zaman gereksiz risk doğurur
Exploit Primitive	Tam bir exploit değil; etkiyi mümkün kılan temel “yapı taşı” türündeki yetenek/işlem (kavramsal düzey)
Race Condition	Zamanlama/sıralama hatalarından doğan zafiyet; dış koşullara bağlı olduğundan güvenilirlik düşebilir
Memory Corruption	Belleğin beklenmedik şekilde bozulması; kararlılık ve yan etki riskleri doğurabilir
CVSS	Ortak zafiyet puanlama sistemi; teknik riskin standartlaştırılmış bir ifadesi
Business impact matrisi	Etkiyi iş süreci üzerinden değerlendirme yaklaşımı; bağlama uygun ama subjektiflik riski taşıyabilir
IDOR	Nesne referansına dayalı yetkisiz erişim; erişim kontrolü boşluklarıyla ilişkilidir

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Aynı bulguyu doğrulamak için iki yolun var: Yol-1 hızlı ama bağlama göre “bazen” çalışıyor; Yol-2 daha yavaş ama tekrarlanabilirliği yüksek ve bağlamı daha net. İleri seviye yaklaşım hangisidir?

A) Hızlı olanı seçmek; zaman her şeydir

B) İkisini de aynı anda ve agresif yoğunlukla yapmak

C) Tekrarlanabilirliği yüksek olanı ana doğrulama yolu yapmak; hızlı olanı hipotez düzeyinde tutup confidence’ı buna göre yönetmek

D) Belirsizlik varsa raporlamamak

E) Hızlı olanı seçip “kritik” yazmak; detay sonra gelir

Doğru: C
Kısa gerekçe: C, kanıt standardını ve güvenilirliği önceler. A/E yanlış kesinlik üretir; B noise/OPSEC riskini yükseltir; D bilgi kaybıdır.

2) Kritik bir üretim sisteminde, bir exploitation yaklaşımının “servisi kararsızlaştırma” ihtimali anlamlı düzeyde. RoE’de iş sürekliliği vurgulanmış ve hedef yedekli değil. En doğru karar nedir?

A) Trafik az diye yoğunluk düşürüp denemek

B) Denemeyi ertelemek; zafiyet varlığını davranışsal ve düşük riskli kanıtlarla doğrulayıp raporlamak, gerekiyorsa benzer ortam kanıtıyla desteklemek

C) Etkiyi görmeden raporlamak; kanıt gereksiz

D) Mutlaka denemek; izin varsa risk kabul edilir

E) Sadece hedef sahibine söyleyip rapora koymamak

Doğru: B
Kısa gerekçe: B, minimum zarar ve go/no-go disiplinidir. A/D kesinti riski taşır; C kanıt standardını zayıflatır; E denetlenebilirlik üretmez.

3) Zincirleme saldırı tasarımında ilk halka olarak en sık “düşük riskli” görünen ama zinciri başlatan bulgu sınıfı hangisidir?

A) Tek başına zaten “oyun bitti” sayılabilecek kritik zafiyetler

B) Bilgi ifşası veya hatalı yapılandırma gibi küçük kırılmalar

C) Hizmet dışı bırakma odaklı durumlar

D) Fiziksel erişim gerektiren senaryolar

E) Yalnızca kimlik doğrulama mekanizması olmayan paneller

Doğru: B
Kısa gerekçe: B, zincirleme düşünmenin tipik başlangıcıdır. A zincire ihtiyaç bırakmayabilir; diğerleri genelleme açısından tutarsızdır.

4) Hassas bir veri alanına erişim riskini etik biçimde kanıtlamak için en uygun yaklaşım hangisidir?

A) Veri setini topluca dışarı aktarıp kanıtlamak

B) Veride değişiklik yaparak “yapılabiliyor” göstermek

C) Minimum veri prensibiyle, erişim kontrolünün kırıldığına dair bağlamsal ve inkâr edilemez kanıt üretmek; veriyi ifşa etmeden kanıtlamak

D) Kanıt üretmeden “olabilir” diye yazmak

E) Sistemi kararsızlaştırma pahasına daha güçlü kanıt üretmek

Doğru: C
Kısa gerekçe: C, minimum zarar + kanıt standardı dengesidir. A/B/E etik ve operasyonel risk; D zayıf rapordur.

5) Zamanlamaya bağlı zafiyetlerde güvenilirlik neden çoğu zaman düşüktür?

A) Her ortamda deterministik çalıştıkları için

B) Ağ gecikmesi, sistem yükü ve eşzamanlılık gibi dış değişkenlere bağlı oldukları için

C) Sadece belirli bir işletim sisteminde görüldükleri için

D) Tespit edilemedikleri için

E) Yeni bir teknik oldukları için

Doğru: B
Kısa gerekçe: B, kırılganlığı doğuran temel faktörleri açıklar. Diğer şıklar genellemeci veya alakasızdır.

6) Dışa açık bir uygulama davranışı, iç ağdaki bir servise “beklenmedik erişim” sonuçları doğuruyor ve iç servis ayrıca zayıf doğrulama/izolasyona sahip. Bu zincirde kök neden (root cause) en doğru nasıl ifade edilir?

A) İç servisin var olması

B) Uygulamanın iç ağa sınırsız konuşabilmesi + iç servisin “güvenli bölge” varsayımıyla yeterli kontrol uygulamaması kombinasyonu

C) Kullanıcıların güçlü şifre seçmemesi

D) Sistemlerin güncel olması

E) Logların tutulması

Doğru: B
Kısa gerekçe: Zincir, iki kontrol düzlemi boşluğunun birleşimiyle doğar: sınır/segment varsayımı ve servis tarafı kontrolleri. Diğer şıklar asıl nedeni yakalamaz.

7) Operasyon sonunda ortamı “temiz bırakmak” ile “kanıt/tespit sinyallerini korumak” arasındaki doğru denge hangisidir?

A) İzleri silmek; böylece daha başarılı görünür

B) Sadece artefaktları kaldırmak; logları kurcalamamak ve tespit sinyallerini raporlamak

C) Hiçbir şeyi geri almamak; her şey kalsın

D) Sadece sözlü anlatmak; yazılı kanıt gereksiz

E) Logları da temizlemek; aksi halde etik değildir

Doğru: B
Kısa gerekçe: B, izinli değerlendirme için doğru dengeyi kurar. A/E denetlenebilirliği bozar; C operasyonel risktir; D kaliteyi düşürür.

8) “Exploit primitive” kavramı ileri seviyede hangi düşünme biçimini güçlendirir?

A) Hazır araçları ezberlemeyi

B) Tek hamlede maksimum etki aramayı

C) Karmaşık etkiyi mümkün kılan temel yapı taşlarını ayırıp zincir mantığıyla değerlendirmeyi (kavramsal)

D) Kapsam dışına çıkmayı normalleştirmeyi

E) Kanıt yerine yorumu artırmayı

Doğru: C
Kısa gerekçe: C, zincirleme tasarım ve kanıt standardıyla uyumludur. Diğer şıklar modül hedefiyle ters düşer.

9) “Scope creep” riski en çok hangi aşamada artar ve en doğru önlem nedir?

A) Recon aşamasında; daha çok veri toplamak

B) İlk erişim/sonrasında; her yeni görünür yüzeyde RoE ve kapsam kontrolü yaparak dur-kontrol et disiplinini işletmek

C) Raporlama aşamasında; riskleri küçümsemek

D) Sözleşme aşamasında; teknik ekip karışmasın

E) Eğitim öncesinde; ekipman seçmek

Doğru: B
Kısa gerekçe: Erişim sonrası “yeni yollar” görünür olur; disiplin kaybı hukuki/etik sorun doğurur. B bunu doğrudan yönetir.

10) Raporlamada zincir diyagramı ve özet tablo seçimi için en olgun yaklaşım hangisidir?

A) Sadece diyagram; tablo gereksiz

B) Sadece tablo; diyagram fazla teknik

C) Diyagramla hikâyeyi ve kanıt bağlarını netleştirip; tabloyla karar vericiye hızlı risk/öncelik görünürlüğü sağlamak

D) İkisini de kullanmamak; sözlü anlatım yeter

E) Diyagramı büyütmek; daha “etkileyici” görünür

Doğru: C
Kısa gerekçe: C, belirsizliği azaltır ve operasyonel iletişimi güçlendirir. A/B tek boyutlu; D/E kaliteyi düşürür.

Bu Modülde Kazanılan Yetkinlikler

Exploitation'ı "teknik hamle" değil go/no-go kararı olarak ele almayı; güvenilirlik-yan etki-geri dönüş dengesini kurmayı
Zinciri "uzatmak" yerine, misconfig → kimlik → yetki → hedef varlık hattını kanıtla kurmayı; karşı kanıt aramayı alışkanlık haline getirmeyi
Belirsizliği saklamadan yönetmeyi: gözlem-yorum ayrımı, izlenebilirlik, zaman uyumu ve confidence dili
Tekil vektör / çoklu kombinasyon ve sıralı / paralel model tercihlerini noise-FP-OPSEC-etik sınırlarla birlikte değerlendirmeyi
Kanıtı minimum zarar prensibiyle üretip, çıktıyı Modül 12 (tespit perspektifi) ve Modül 17 (raporlama/iletişim) hattına bağlamayı

MODÜL 8 — Post-Exploitation: Privilege, Credential, Persistence

Modül Teması

Privilege Escalation

Token, misconfig ve kernel yolları.

Credential Access

LSASS, DPAPI, ticket ve cache madenciliği.

Persistence

Service, scheduled task, COM hijack ve WMI.

İlk erişim ve exploitation sonrası "içeride olmak", otomatik olarak yetkili, kalıcı ya da operasyonel hedeflere hazır olmak demek değildir. Bu modül, post-exploitation aşamasını bir "yapılacaklar listesi" gibi değil; kanıt standardı, kapsam disiplini, minimum zarar ilkesi, OPSEC/noise yönetimi ve savunma iyileştirmesine dönüşen çıktılar olarak ele alır. Modül 7'de kurduğun zincir mantığı burada devam eder; Modül 9 (lateral movement/pivoting) ve Modül 10 (kurumsal kimlik patikaları/AD) için güvenli ve denetlenebilir bir köprü kurar. Modül 12'deki tespit perspektifi ve Modül 17'deki raporlama/purple teaming hattına "temiz" veri taşımayı hedefler.

Bu Modülde Hedeflenen Kazanımlar

Post-exploitation'da go/no-go kararlarını kapsam, yan etki, izlenebilirlik ve savunma değeri üzerinden yönetebilmek
"Yetki yükseltme"yi refleks olmaktan çıkarıp güven sınırı ihlali ve iş etkisi odağıyla anlamlandırmak
Kimlik materyallerini (parola, hash, ticket, token, servis kimliği vb.) neye karşılık geldikleri üzerinden sınıflandırıp belirsizliği doğru yönetmek
Persistence'ı "kalıcı kalma" değil, süre/kapsam sınırlı ve geri dönüşü planlı bir kontrol simülasyonu olarak tasarlamak
Bulguları gözlem-yorum ayrımı, karşı kanıt, zaman uyumu ve confidence dili ile denetlenebilir paketlere dönüştürmek

1) Post-exploitation zihniyeti: "İçeri girdim" değil, "Neyi kanıtladım?"

Post-exploitation'da en yaygın sapma, erişim sağlanınca hedefin flu hale gelmesi ve "mümkün olanı yapmak" ile "gerekli olanı kanıtlamak"ın karışmasıdır. İleri seviye yaklaşımda her adımın:

bir amacı,
bir kanıt çıktısı,
bir de durdurma/geri dönüş kriteri

olur. Bunlardan biri yoksa, adım çoğu zaman operasyonel risk üretir.

Sürekli masada kalan üç soru:

Doğrulama: Bu iddia/sinyal hangi gözleme dayanıyor? Bunu en az yan etkiyle nasıl doğrularım?
Karşı kanıt: Beni yanlış çıkaracak işaret ne olur? Hangi kontrol/koşul iddiayı düşürür?
Sınırlar: Noise/FP maliyeti, etik-RoE sınırı, OPSEC riski ve operasyonel yük ne?

Dikkat: Post-exploitation sırasında "scope creep" en hızlı bu aşamada büyür. Yeni yüzeyler göründüğünde her görünen "hedef" değildir; disiplin zayıflarsa teknik hata olmaktan çıkar, yönetişim/etik ihlale dönüşebilir.

1.1. Kanıt zinciri: gözlem-yorum ayrımı, izlenebilirlik ve zaman uyumu

Denetlenebilirlik için "kanıt"ı doğru paketlemek gerekir:

Gözlem: sistem davranışı, yetki bağlamı, politika etkisi, erişim denemelerinin sonucu
Yorum: gözlemin ne anlama geldiğine dair hipotez
Karşı kanıt: alternatif açıklamalar, çevresel etkiler, kısıtlar
Confidence: ne kadar eminsin, neden; hangi koşul değişirse fikrin değişir?

Dağıtık ortamlarda zaman uyumu kritik bir kalite kapısıdır. Log gecikmeleri, saat farkları ve farklı katmanların zaman damgaları, yanlış kesinlik üretmeye çok elverişlidir. Çoklu kaynaktan korelasyon yapabilmek için sistem saatlerinin senkron tutulmasının önemi, adli ve olay inceleme bağlamında özellikle vurgulanır.

Örnek: example.org üzerinde "yetki genişledi" iddian varsa, tek bir ekran görüntüsü yerine; rol/oturum bağlamını, zaman çizelgesini ve iddiayı çürütebilecek kısıtları gösteren bir kanıt paketi kurarsın. Zaman damgaları çelişiyorsa "kesin" dili yerine, iddiayı daraltıp hangi şartlarda güçleneceğini yazarsın.

1.2. "İlk 10 dakika" disiplini: stabilize et, sonra derinleş

İleri pratikte ilk refleks "devam etmek" değil, stabilize etmektir:

Bulunduğun varlık gerçekten kapsamda mı?
Yan etki var mı? Servis/iş sürekliliği etkileniyor mu?
Minimum ama yeterli kanıt üretildi mi?
Bir sonraki adım Modül 9'daki hareketliliğe mi gidiyor, yoksa burada durmak mı daha doğru?

İpucu: Post-exploitation'ı "merdiven" değil, kalite kapıları olan kontrol noktaları zinciri gibi düşün. Her kapıda şu üçlü yoksa geçme: (1) doğrulanmış iddia, (2) karşı kanıt değerlendirmesi, (3) stop/geri dönüş kriteri.

2) Privilege: yetkiyi büyütmek değil, yetkiyi anlamlandırmak

Yetki (privilege) konusu "daha yüksek hak" hedefiyle daraltılırsa hem savunma çıktısı zayıflar hem de risk büyür. İleri seviyede privilege; hangi güven sınırının nerede ihlal edilebildiğini, bunun iş etkisine nasıl bağlandığını ve hangi kontrollerin bunu engellemesi gerektiğini netleştirmek için ele alınır.

2.1. Yetki türleri ve güven sınırları: "hak" her zaman aynı şey değildir

Yerel (local) yetki bağlamı: tek varlıkta etki; kanıt üretimi net, blast radius sınırlı
Kimlik/rol yetkisi: uygulama/kimlik sağlayıcı bağlamı; iş etkisine bağlamak daha doğrudan
Kurumsal (domain/tenant) etki: kapsam genişler; yanlış adımın blast radius'u büyür (Modül 10'da derinleşir)

Bu noktada yöntem seçimi devreye girer: Aynı hedefi iki yolla gösterebiliyorsan, çoğu senaryoda daha düşük blast radius + daha yüksek izlenebilirlik sunanı seçmek olgun yaklaşımdır.

2.2. Yetki iddiasını doğrulama: "göründü" ile "sahip oldum" ayrımı

Yetki iddiası yanıltıcı sinyallerle karışabilir: arayüzde görünen rol etiketi, cache'lenmiş oturum, bağlama duyarlı kısıtlar... İleri seviye doğrulama:

Yetkinin hangi eylem sınıflarını mümkün kıldığını zarar üretmeden kanıtlamayı,
İddiayı düşürecek karşı kanıtları (koşullu politika, ikinci kontrol katmanı, ağ/segment kısıtı) aramayı,
Sonucun bağlama duyarlı olup olmadığını (bazı oturumlarda var, bazılarında yok) raporlamayı hedefler.

Örnek: example.com üzerinde "yönetici yetkisi" iddiasını, gerçek kullanıcı verisine dokunmadan; sadece "kritik eylem sınıfı"na dair izin/engel mantığını denetlenebilir biçimde göstererek doğrularsın. Aynı rol bazı bağlamlarda işe yarıyor bazı bağlamlarda yaramıyorsa, "deterministik" diye yazmak yerine bağlamı tarif edip confidence'ı buna göre kurarsın.

2.3. OS perspektifiyle privilege modelleme: Windows/Linux prensip farkları

Bu modül "nasıl yapılır" tarifine girmez; ama modelleme dili doğru kurulmazsa rapor da iyileştirme önerileri de zayıflar.

Windows: Yetkilendirme bağlamı çoğu zaman "erişim belirteci/token" mantığıyla okunur; ayrıcalıklar, süreçlerin ve hesapların hangi güven sınırlarını aşabileceğini belirler. Bu tür iddialarda kanıt üretimi, çoğu zaman "hangi izin/ayrıcalık + hangi kısıt" çerçevesinde paketlenir.
Linux: Yetki modeli büyük ölçüde dosya izinleri ve çekirdek yetenekleri/capabilities üzerinden anlaşılır; "konfigürasyon ve izin ilişkisi" kanıtlanabilirliği artırır.

İpucu: Üretim ortamlarında yüksek riskli ve istikrarsız sonuç üretebilecek yollar (ör. sistem kararlılığını etkileyebilecek çekirdek düzeyi senaryolar) genelde son çaredir. Önce daha düşük yan etkili, daha denetlenebilir konfigürasyon/izin boşlukları üzerinden kanıt üretmek hem etik hem de operasyonel olarak daha sağlıklıdır.

2.4. "Devam etmek" her zaman doğru değil: durdurma kriterleri

Yetki artışı sinyali görüldüğünde olgun hareket bazen durmaktır:

Kapsam dışı yüzeye geçiş riski doğuyorsa
Yan etki (performans, kesinti, alarm fırtınası) ihtimali yükseliyorsa
Kanıt kalitesi düşüyor, belirsizlik artıyorsa
RoE/etik sınır, "kanıt" üretimini "zarar" üretimine yaklaştırıyorsa

3) Credential access: kimlik materyalini anlamak, belirsizliği yönetmek

Credential access, kötüye kullanıma en açık alanlardan biridir. Bu modülde odak "nasıl elde edilir" değil; hangi kimlik materyalleri vardır, neyi temsil eder, hangi riskleri taşır, nasıl doğrulanır ve nasıl raporlanır sorularıdır.

3.1. Kimlik materyali türleri: aynı şey değiller

Parola/secret (cleartext): doğrudan kimlik doğrulama malzemesi; risk/etki yüksek
Hash/türev değer: her zaman "parolanın kendisi" değildir; bağlama göre risk değişir
Ticket (Kerberos bağlamı): süre/kapsam/yenilenebilirlik gibi parametreleri vardır; bazı senaryolarda parola değişse bile mevcut biletler ömürleri boyunca etkisini koruyabilir (ortam politikasına bağlı)
Token / session artefact: oturum yetkisini taşır; süre, kapsam ve iptal edilebilirlik değişkendir (özellikle bulut/SSO bağlamı)
API key / servis kimliği: insan hesabı gibi davranmayabilir; erişim kapsamı konfigürasyona bağlıdır

Bu ayrım yöntem seçimini belirler: Aynı iş etkisini göstermek için en hassas veriye koşmak yerine, çoğu senaryoda en az hassas ama en net kanıt üreten yol seçilir.

3.2. "Geçerli" demek ne demek? Doğrulama + karşı kanıt

Bir materyalin varlığı tek başına sonuç değildir. İleri seviye doğrulama soruları:

Bu materyal hangi kapsamda geçerli? (rol/tenant/servis/segment)
Süresi ve iptal edilebilirliği nedir?
İş etkisi iddiasını destekliyor mu, yoksa yanlış bağlam mı?
Karşı kanıt: materyal gerçek olsa bile kullanılamaz kılan kontrol var mı? (ağ kısıtı, koşullu politika, ikinci doğrulama, kaynak kısıtı)

Örnek: example.net üzerinde bir servis anahtarına dair sinyal gördüğünde, bunu "kritik ele geçirme" diye etiketlemek yerine; anahtarın kapsamını, hangi eylem sınıflarına izin verdiğini ve hangi kontrollerin bunu sınırladığını kanıta dayalı değerlendirirsin. Ağ kısıtı nedeniyle doğrulama yapılamıyorsa, iddiayı "geçersiz" diye kapatmak yerine belirsizliği doğru kurar; hangi koşul sağlanırsa görüşünün değişeceğini yazarsın.

3.3. Minimum zarar ve veri minimizasyonu: "kanıt" ile "ifşa" çizgisi

Kimlik materyalleri konusunda en kritik sınır, kanıt üretiminin veri ihlaline dönüşmemesidir:

Gereksiz materyal toplamayı reddet
Kanıtı "kontrol boşluğu ve kapsam aşımı" üzerine kur
Hassas veriyi çoğaltma; raporda maskelenmiş/özetlenmiş bağlam kullan
"Ne buldum?" yerine "Hangi güven varsayımı kırıldı?" sorusunu merkeze al

Dikkat: Kimlik materyali üretim/taşıma/çoğaltma riskinin yükseldiği yerde, en doğru profesyonel karar çoğu zaman kanıtı daraltmak ve "savunma kontrol doğrulaması" seviyesinde bırakmaktır.

4) Persistence: kalıcılığı "kontrollü simülasyon" olarak tasarlamak

Persistence, izinli değerlendirmede yanlış anlaşılmaya en açık konulardandır. Bu modülde persistence; "uzun süre kalmak" değil, savunmanın dayanıklılığını ölçen, süre/kapsam sınırlı, geri dönüşü planlı bir simülasyondur.

4.1. Neden persistence? Savunma değerini netleştirmek

Persistence'in savunma açısından değeri:

Yetkisiz kalıcılık girişimlerinin tespit edilebilirliği (Modül 12'ye bağlantı)
Kimlik/rol yönetimi boşluklarının görünürleşmesi (Modül 10'a köprü)
IR/DFIR olgunluğu: geri alma, iz sürme, etki analizi
"Tek seferlik ihlal" ile "süreğen risk" ayrımının kanıtlanması

4.2. Dosyalı-dosyasız modeller: tespit yüzeyi ve adli karşılığı

Kalıcılık mekanizmaları, pratikte iki uç arasında düşünülür:

Dosya tabanlı yaklaşımlar: klasik ve genellikle daha görünür; tespit yüzeyi geniş
Dosyasız (fileless) yaklaşımlar: yapılandırma depoları ve sistem bileşenleri üzerinden kalıcılık kurguları; tespiti çoğu zaman daha uzmanlık gerektirir

Windows Management Instrumentation (WMI) üzerinden kalıcılık gibi örüntüler, literatürde ayrı bir teknik aile olarak ele alınır ve savunma tarafı için özel görünürlük/denetim gerektirir.

İpucu: Persistence tasarımında "Bu mekanizma hangi güncelleme/politika değişikliğinde etkisizleşir?" sorusunu erkenden sor. Bu, belirsizliği doğru yönetir ve raporu aksiyonlanabilir yapar.

4.3. Sınırlı ve geri dönüşlü tasarım: süre, kapsam, stop koşulları

Olgun persistence simülasyonunda üç şey net olmalı:

Süre sınırı: ne kadar yaşayacak, ne zaman bitecek?
Kapsam sınırı: hangi varlıklarda, hangi rol/hak bağlamında?
Stop koşulları: beklenmeyen etki veya kapsam riski doğduğunda nasıl durdurulacak?

Buradaki kanıt standardı "kuruldu" iddiasından çok, kurulabilirliği mümkün kılan kontrol boşluğu ve bunun savunma telemetrilerinde nasıl göründüğüdür.

4.4. "Stealth" yanılgısı: görünmez olmak başarı değildir

İzinli değerlendirmede başarı "hiç iz bırakmamak" değildir. Doğru başarı metriği:

gereksiz gürültü üretmeden,
denetlenebilir kanıtla,
savunma iyileştirmesine dönüşen çıktı üretmektir.

5) Living-off-the-land: araç değil, risk ve kontrol perspektifi

"Living off the land", dışarıdan yeni araç taşımak yerine, işletim sisteminde zaten bulunan imzalı/yerleşik bileşenlerin kötüye kullanılabilmesidir. Bu, savunma açısından kritik bir gerçektir: yerleşik bileşenleri tamamen engellemek çoğu zaman iş süreçlerini kırar; bu yüzden tespit çoğunlukla davranış ve bağlam üzerinden yapılır.

Örnek: Bir ortamda PowerShell'in varlığı tek başına "kötü" değildir; fakat çalıştırma bağlamı, komut içeriğinin kaydı, süreç ilişkileri ve zaman çizelgesi, şüpheyi belirleyen parçalar olur. PowerShell Script Block Logging gibi mekanizmalar, yürütülen içeriklere dair görünürlük sağlayabilir.

İpucu: LOL/LOLBins tartışmasını "hangi binary kötü?" seviyesinde değil, "hangi davranış/bağlam anomali?" seviyesinde kur. Böylece rapor, savunmanın uygulayabileceği gerçek kontrol hedeflerine (log politikası, allowlist/denetim, korelasyon kuralları) bağlanır.

6) Artifact/iz yönetimi ve adli görünürlük: "iz bırakmamak" değil, izleri yönetmek

İleri seviye bir red teamer, attığı her adımın sistemde nerede iz bırakacağını bilir. Ama hedef "iz bırakmamak" değil; gereksiz ve anomali üreten izlerden kaçınmak, elde ettiği bulguyu da bu telemetri gerçekliğiyle birlikte paketlemektir.

Windows tarafında kimlik doğrulama ve log silme gibi olaylar, denetim kayıtlarında belirli event'lerle izlenebilir (ör. başarılı/başarısız oturum açma ve audit log temizlenmesi). Ayrıca Sysmon gibi telemetri kaynakları süreç oluşturma, ağ bağlantısı, süreç erişimi ve dosya zaman damgası değişiklikleri gibi davranışları olaylaştırarak korelasyon imkânı sağlar.

6.1. Timestomping: zaman çizelgesini yanıltma girişimlerine dair sınırlar

Zaman damgası manipülasyonu (timestomping) bir teknik aile olarak bilinir; ancak dosya sistemi metaverisinin birden fazla kaynakta tutulması nedeniyle "naif" manipülasyonlar çoğu zaman tutarsızlık üretir ve derin analizde yakalanabilir.

6.2. Log silme neden "yüksek gürültü"dür?

Log temizleme, savunma açısından doğrudan bir alarm tetikleyicisi olarak ele alınır ve saldırgan davranışları arasında sınıflandırılır. İzinli bir çalışmada bile bu tür eylemler, hem etik/uyum riskini büyütür hem de değerlendirmeyi "savunma kontrol testi" çizgisinden çıkarabilir.

Dikkat: "İzleri temizlemek" çoğu zaman bulguyu güçlendirmez; tam tersine, savunmanın en kolay korele ettiği davranışlardan birini üretir. İleri seviye yaklaşım, izleri yok etmek değil; kanıtı denetlenebilir ve minimum yan etkili tutmaktır.

7) Bulguyu rapora dönüştürmek: minimal ama güçlü kanıt paketi

Modül 7'deki zincir mantığını sürdür: privilege / credential / persistence bulguları, tek tek "başlık" olmak yerine bir risk patikasının halkalarıdır. Her halka için minimal ama güçlü bir paket:

Bağlam: varlık sınıfı, rol/oturum/tenant, zaman uyumu
Gözlem: ne görüldü?
Yorum: ne anlama gelebilir?
Karşı kanıt: hangi koşulda düşer?
Confidence: neden; hangi şartlarda değişir?
Savunma çıktısı: hangi kontrol hedefi güçlenmeli; Modül 12 perspektifinde tespit/iyileştirme önerisi
Sınırlar: kapsam, yan etki, noise/FP riski, geri dönüş kriteri

Bu paket, Modül 9'da hareketlilik başladığında "hangi doğrulanmış hakla nereye gidilebilir?" sorusuna cevap verir; Modül 10'da ise kimlik patikalarının güven sınırlarını netleştirmeye hizmet eder. Modül 17'de raporlama ve purple teaming oturumlarında ise tartışmayı "kanıt" üzerinden yürütülebilir kılar.

Terimler Sözlüğü

Terim	Açıklama
Post-exploitation	İlk erişim sonrası; yetki, kimlik materyali ve kalıcılık sinyalleri üzerinden etkiyi ve savunma boşluklarını değerlendirme aşaması
Privilege	Yetki; bir hesap/rol/oturumun izin verdiği eylem sınıfları ve güven sınırları
Privilege escalation	Yetki bağlamının genişlediği iddiası; mutlaka karşı kanıt ve bağlamla doğrulanır
Credential / credential material	Kimlik doğrulama/yetkilendirme materyali; parola, hash, ticket, token, API key vb.
Hash	Özet/türev değer; bağlama göre risk ve kullanılabilirlik değişebilir
Ticket	Kimlik/yetkilendirme akışında süre ve kapsamı olan bilet (örn. Kerberos bağlamı)
Token / session artefact	Oturum belirteci; süre/kapsam/iptal edilebilirlik özellikleriyle risk taşır
API key / servis kimliği	İnsan hesabı gibi davranmayabilen, konfigürasyona bağlı erişim veren anahtar/kimlik
Persistence	Kalıcılık; izinli çalışmada süre/kapsam sınırlı, geri dönüşü planlı kontrol simülasyonu
Fileless persistence	Dosya yerine sistem yapılandırma depoları/bileşenleri üzerinden kalıcılık örüntüleri
WMI Event Subscription	WMI temelli tetikleyicilerle kalıcılık örüntüsü; özel görünürlük/denetim gerektirir
Living-off-the-land (LotL)	Yerleşik/imzalı bileşenlerin kötüye kullanılabilmesi gerçeği
LOLBins	“LotL” bağlamında sık kötüye kullanılan yerleşik ikililer/kabileler (kavramsal sınıf)
OPSEC	Operasyon güvenliği; gereksiz görünürlük ve ilişkilendirilebilirliği azaltma disiplini
Noise	Telemetri/alarm/günlük yükü; gereksiz gürültü operasyonel riski artırır
False Positive (FP)	Yanlış pozitif; yanlış iyileştirme ve güven kaybı doğurur
Traceability	İzlenebilirlik; kanıtın bağlamının (zaman/rol/akış) denetlenebilir olması
Dwell time	İçeride kalma süresi; savunma dayanıklılığını ölçmede kullanılan metrik
Timestomping	Zaman damgası manipülasyonu; zaman çizelgesi analizini yanıltmayı hedefleyen örüntü

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Post-exploitation’da “devam etme” kararını en iyi yöneten yaklaşım hangisidir?

A) Erişim sağlandıysa her zaman derinleşmek gerekir

B) Teknik merak önceliklidir; iş hedefi raporda sonradan yazılır

C) Her adımı doğrulama–karşı kanıt–yan etki–geri dönüş kriterleriyle değerlendirip, kanıt çıktısı yoksa durmak

D) Alarm oluşmadıysa güvenlidir; devam edilir

E) En yüksek yetkiye ulaşıldıysa geri kalan önemsizdir

Doğru: C
Gerekçe: C, ileri seviye kalite kapısı yaklaşımıdır. A/B amaç kaydırır; D yanlış güven hissi üretir; E kanıt standardını bozar.

2) “Yetki yükseldi” iddiasını olgunlaştıran en kritik fark hangisidir?

A) Rol etiketini görüp kesin yazmak

B) En geniş kapsama geçerek “etkiyi büyütmek”

C) Yetkinin izin verdiği eylem sınıfını minimum zarar ile doğrulamak ve iddiayı düşürebilecek kısıtları aramak

D) Daha çok ekran görüntüsü eklemek

E) Belirsizliği saklayıp tek cümle sonuç yazmak

Doğru: C
Gerekçe: C, doğrulama + karşı kanıt + sınır yönetimini birlikte taşır. A/D bağlamı zayıf; B scope creep riskini büyütür; E denetlenebilirliği yok eder.

3) Aşağıdakilerden hangisi “yöntem seçimi + sınırlar” bakışını en doğru ifade eder?

A) Daha agresif yaklaşım her zaman daha kesin kanıt üretir

B) Blast radius büyüdükçe kanıt kalitesi otomatik artar

C) Aynı riski göstermek için düşük yan etkili ve izlenebilir yolu seçmek çoğu zaman daha olgun bir tercihtir

D) OPSEC izinli çalışmada gereksizdir

E) Noise’un artması raporu güçlendirir

Doğru: C
Gerekçe: C, operasyonel yük/yan etki/izlenebilirlik dengesini kurar. A/B genelleme hatası; D yanlış; E kaliteyi düşürür.

4) Bir kimlik materyalinin “var olması” neden tek başına yeterli değildir?

A) Çünkü raporda teknik terim kullanmak yasaktır

B) Çünkü materyalin kapsamı, süresi, iptal edilebilirliği ve kısıtları iş etkisini belirler

C) Çünkü belirsizlik her zaman görmezden gelinir

D) Çünkü yalnızca parolalar değerlidir

E) Çünkü token/ticket her zaman aynı anlama gelir

Doğru: B
Gerekçe: B, doğrulama ve karşı kanıt ihtiyacını açıklayan çekirdek ilkedir. C kaliteyi bozar; D/E sınıflandırmayı yok sayar; A alakasızdır.

5) Bir token bazı bağlamlarda çalışıyor, bazılarında çalışmıyorsa en doğru confidence yönetimi hangisidir?

A) “Kesin ele geçirme” demek; tutarsızlık önemsiz

B) İddiayı bağlamla daraltıp hangi koşullarda güçlenip zayıfladığını yazmak; görüşünün hangi değişkende değişeceğini belirtmek

C) Tutarsızlığı rapordan çıkarmak

D) Tek tutarsızlık gördüğünde iddiayı tamamen çöpe atmak

E) Belirsizliği artırmak için daha fazla riskli deneme yapmak

Doğru: B
Gerekçe: B, belirsizliği dürüst ve denetlenebilir yönetir. A/C yanlış kesinlik; D erken hüküm; E gereksiz risk/noise üretir.

6) Persistence’ı izinli değerlendirmede “olgun” yapan temel tasarım ilkesi hangisidir?

A) En uzun süre kalmak

B) İz bırakmamak ve görünmez olmak

C) Süre/kapsam/stop koşulları net, geri dönüşü planlı ve savunma ölçümüne hizmet eden kontrollü simülasyon

D) Kimseye söylemeden sürpriz yapmak

E) Persistence varsa raporlama gereksizdir

Doğru: C
Gerekçe: C, minimum zarar ve yönetişimle uyumludur. A/B yanlış metrik; D etik/RoE riski; E aksiyonlanabilirliği yok eder.

7) Fileless persistence ile ilgili savunma perspektifinden en doğru ifade hangisidir?

A) Dosyasız kalıcılık tespit edilemez

B) Dosyasız kalıcılık her zaman daha güvenlidir

C) Dosyasız kalıcılık, farklı telemetri ve denetim yüzeyleri gerektiren bir modelleme ihtiyacı doğurur

D) Dosyalı kalıcılık asla tespit edilemez

E) Fileless yaklaşım etik açıdan otomatik olarak uygundur

Doğru: C
Gerekçe: C, “tespit yüzeyi” ve görünürlük ihtiyacını doğru çerçeveler. A/D kesin ve yanlış; B genelleme; E yönetişimden bağımsız değildir.

8) Living-off-the-land riskini savunma açısından en doğru yöneten yaklaşım hangisidir?

A) Yerleşik bileşenleri tamamen yasaklamak

B) Sadece “kötü araç listesi” tutmak

C) Davranış + bağlam + korelasyon üzerinden tespit ve politika tasarlamak

D) Loglamayı azaltmak; gürültü düşer

E) Tespiti tamamen manuel incelemeye bırakmak

Doğru: C
Gerekçe: C, pratikte uygulanabilir kontrol hedeflerine bağlanır. A iş sürekliliğini kırabilir; B kolay atlatılan bir model; D görünürlüğü öldürür; E ölçeklenmez.

9) “Log temizleme” davranışı neden ileri seviye değerlendirmede genellikle kötü bir karardır?

A) Çünkü çok uzun sürer

B) Çünkü denetlenebilirliği düşürür ve yüksek öncelikli anomali üreterek savunmaya net sinyal verir

C) Çünkü loglar zaten hiç kullanılmaz

D) Çünkü sadece eski sistemlerde olur

E) Çünkü rapor formatını bozar

Doğru: B
Gerekçe: B, OPSEC/noise ve denetlenebilirlik boyutlarını birlikte ele alır. A ikincil; C/D/E yanlış veya alakasızdır.

10) Timestomping iddiasını raporlamada en olgun yaklaşım hangisidir?

A) Zaman damgası değiştiyse kesin “iz kaybı” yazmak

B) Tek bir göstergeye dayanıp sonucu kesinleştirmek

C) Çoklu zaman damgası kaynakları arasındaki tutarlılığı ve karşı kanıtları değerlendirerek iddiayı sınırlarıyla yazmak

D) Zaman uyumsuzluğunu görmezden gelip risk puanı vermek

E) Zaman çizelgesi yerine yalnızca özet yazmak

Doğru: C
Gerekçe: C, kaynak–iddia–kanıt ayrımı ve belirsizlik yönetimini taşır. A/B yanlış kesinlik; D/E denetlenebilirliği düşürür.

Bu Modülde Kazanılan Yetkinlikler

Post-exploitation'ı "daha çok ilerleme" değil, kanıt standardı + kapsam disiplini olarak yönetmeyi
Privilege konusunu "daha fazla güç" yerine güven sınırı + iş etkisi odağıyla okumayı; iddiaları karşı kanıt ve stop kriteriyle olgunlaştırmayı
Kimlik materyallerini türlerine göre sınıflandırıp kapsam/süre/iptal edilebilirlik üzerinden belirsizliği yönetmeyi
Persistence'ı kontrollü simülasyon olarak tasarlayıp süre/kapsam/geri dönüş planı kurmayı
LotL/LOLBins ve artefact gerçekliğini "araç" değil, davranış-telemetri-korelasyon ekseninde raporlamayı

Modül 9 — Lateral Movement, Pivoting ve Segment Geçişi

Bu modül, "yatay hareket"i araç/teknik listesi olarak değil; kimlik-yetki-güven ilişkileri üzerinden okunan bir patika modelleme problemi olarak ele alır. Modül 8'de elde edilen post-exploitation çıktıları burada "hareket edilebilir yol"a dönüştürülür; Modül 10'da derinleşecek kurumsal kimlik patikaları (özellikle dizin servisleri) için zemin hazırlanır. Yazılı formatın sınırlarına sadık kalarak, doğrulama disiplini, kanıt standardı ve yöntem seçiminin maliyetleri (noise/FP, operasyonel yük, etik/OPSEC sınırı) üzerinde durulur.

Bu Modülde Hedeflenen Kazanımlar

Lateral movement ve segment geçişi iddialarını kaynak-iddia-kanıt ayrımıyla kurabilmek, bağımsız doğrulama ve karşı kanıt arayışıyla daraltabilmek
Pivoting (jump noktası) kararlarını kapsam, blast radius, izlenebilirlik, rollback ve noise/FP dengesiyle yönetebilmek
"Ulaşılabilirlik" ile "yetkili erişim/iş etkisi" arasındaki farkı netleştirip yanlış kesinlikten kaçınmak
Tünelleme ve tali kanalları "nasıl yapılır" düzeyine inmeden, görünürlük ve kontrol noktaları açısından modelleyebilmek
Segmentasyonun gerçekte neyi engellediğini, nerede kimlik/yönetim düzlemi istisnaları nedeniyle zayıfladığını kanıta dayalı tartışabilmek

1) Lateral movement mantığı: kimlik, yetki ve güven ilişkileri

Lateral movement, bir ortamda bir varlıktan diğerine ilerleme ihtimalini ifade eder; ileri seviyede kritik soru "hangi port açık?"tan önce gelir: Hangi kimlik bağlamıyla, hangi aksiyon sınıfı mümkün? Ağ yolu açık olsa bile, kimlik politikaları, koşullu kurallar, rol kapsamı ve yönetim düzlemi ayrıştırması bu ihtimali ya sınırlar ya da büyütür.

1.1. Ulaşılabilirlik ≠ Kimlik ≠ Yetki/iş etkisi

İleri seviye değerlendirmede iddia türünü baştan netleştirmek, raporun omurgasını belirler:

Ulaşılabilirlik iddiası: İki nokta arasında trafik mümkün görünüyor.
Kimlik iddiası: Belirli bir kimlik/rol ile bir servise erişim mümkün görünüyor.
Yetki/iş etkisi iddiası: Bu erişim, iş açısından anlamlı bir aksiyon sınıfını (ör. yapılandırma değişikliği, veri bütünlüğü etkisi) mümkün kılıyor.

Burada en sık hata, "dokunabildim" sinyalini "ele geçirdim" iddiasına çevirmektir. Olgun yaklaşım, iddiayı en küçük gerekli kanıt ile sınırlar ve "iş etkisi"ni ancak kanıt taşıyorsa büyütür.

İpucu: İddianı tek cümlede kur: "Şu kimlik bağlamıyla, şu varlık sınıfında, şu zaman penceresinde, şu aksiyon sınıfı mümkün görünüyor." Bu cümlede dolduramadığın her alan, confidence'ı düşüren bir boşluktur.

1.2. Güven ilişkilerini haritalama: "kim kime, neden güveniyor?"

Güven ilişkileri çoğu zaman "gizli arka kapılar" değil, meşru operasyonel bağımlılıklar üzerinden doğar. Lateral patikaları anlamlandırırken özellikle şu sınıflar öne çıkar:

Ortak kimlik kullanımı: servis hesapları, otomasyon kimlikleri, paylaşılan yönetim rolleri
Yönetim düzlemi bağımlılıkları: merkezi izleme, yedekleme, dağıtım, uzaktan yönetim kanalları
Yetkilendirme zincirleri: bir sistemdeki rolün başka bir sistemde dolaylı yetki doğurması
Hijyen ve tekrar kullanımlar: aynı yerel yönetici parolasının/rol kapsamının geniş yüzeye yayılması gibi mimari borçlar

Bu haritalama, "hangi varlıklar kritik?" sorusuna ek olarak "hangi varlıklar geçiş düğümü?" sorusunu da cevaplar.

Örnek: 192.0.2.0/24 içindeki "Uygulama Sunucuları" segmentinde çalışan bir otomasyon kimliği, 198.51.100.0/24 içindeki "Dosya Hizmetleri" üzerinde belirli bir role sahiptir. Olgun raporlama "dosya sunucusu ele geçirilir" demez; rolün kapsamını (hangi işlemler, hangi kaynaklar, hangi zaman penceresi) ve bunun hangi iş etkisine bağlanabileceğini dar bir çerçevede kanıtlamayı hedefler.

1.3. Doğrulama: "göründü" ile "gerçekten mümkün" ayrımı

Lateral movement iddialarında doğrulama iki katmanlıdır:

— Bağımsız doğrulama: Tek bir sinyale yaslanma. Bir katmanda gördüğünü (ör. kimlik/rol ilişkisi) mümkünse farklı bir katmanda (farklı log kaynağı, farklı telemetri, farklı zaman penceresi) çapraz kontrol et.
— Karşı kanıt arama: İddiayı çürütecek koşulları bilerek ara. Örneğin:

Ağ yolu var ama politika/koşul engelliyor olabilir.
Kimlik geçerli görünüyor ama aksiyon "read-only" sınıfında kalıyor olabilir.
Zaman uyumsuzluğu/telemetri boşluğu, "kesinlik" iddiasını taşımayabilir.

Belirsizlik varsa saklamak yerine daralt: "Kesin geçiş" yerine "bu koşullarda olası/kanıtlı" dilini kullan; hangi veri gelirse fikrinin değişeceğini açık yaz.

Dikkat: "Yeni bir hedef gördüm" refleksi, scope creep'in başlangıcıdır. Kapsam dışına taşan hareket, teknik hata olmaktan çıkar; hukuki/etik ihlale dönüşür. İleri seviye disiplin, kanıt üretmeyen adımları reddedebilmektir.

1.4. Kanıt zinciri: bulguyu denetlenebilir paketlemek

"Yaptık/yapamadık" ikiliği, lateral movement bulgularını taşımaya yetmez. Denetlenebilir bir paket şunları içerir:

Bağlam: segment/varlık sınıfı, kimlik bağlamı, zaman uyumu
Gözlem: hangi sinyal görüldü?
Yorum: bunun olası anlamı nedir? (patika hipotezi)
Karşı kanıt: hangi koşulda hipotez düşer?
Confidence: neden bu seviyede? hangi veri gelirse değişir?
Savunma çıktısı: hangi kontrol hedefi güçlenmeli?

Bu yapı, Modül 12'deki tespit perspektifine de temiz bağ kurar: savunma tarafı "neyi loglamalı / neyi korele etmeli?" sorusunu doğrudan buradan çıkarır.

2) Pivoting: jump noktasıyla erişim kapsamını genişletmek

Pivoting, iki güven bölgesi arasında doğrudan erişim yokken (veya doğrudan erişim uygun değilken) ara bir nokta üzerinden gözlem/erişim kapsamını genişletme fikridir. İleri seviyede pivot, "tünel açma marifeti" değil; jump noktasının risk profili ve kanıt üretim kalitesi ile değerlendirilir.

2.1. Jump noktası seçimi: karar matrisiyle düşün

İyi pivot noktası "en güçlü sistem" değil, en yönetilebilir risk demektir. Değerlendirmen gereken temel eksenler:

Kapsam uyumu: gerçekten scope içinde mi?
Blast radius: hata olursa kaç sistemi etkiler?
Operasyonel yük: izleme, geri dönüş, koordinasyon maliyeti
Noise/FP riski: normal dışı trafik/oturum hareketi ne kadar görünür?
İzlenebilirlik: sonradan "ne oldu?" sorusunu net cevaplayabilir misin?
Rollback: beklenmeyen etki oluşursa güvenli durdurma/geri alma planın var mı?

İpucu: Pivot seçimini bir "kredi" gibi düşün. Noise ve riskle harcadığın krediyi takip etmiyorsan, borç birikir; en kötü anda "alarm faizi" ödersin.

Örnek: 192.0.2.0/24'teki bir yönetim sunucusu ile 198.51.100.0/24'teki uygulama segmenti arasında meşru bir yönetim akışı vardır. Burada amaç "geçişi büyütmek" değil; akışın neden var olduğunu, hangi koşullarda çalıştığını ve savunmanın bunu nasıl ölçebileceğini (hangi kontrol noktaları, hangi kayıtlar) kanıt standardında netleştirmektir.

2.2. "Dar kanıt" mı "geniş kapsama" mı? Yöntem seçimi ve sınırlar

Pivoting tasarımlarının ortak riski şudur: Kapsam genişledikçe karmaşıklık ve belirsizlik artar; bu da hem izahı hem geri dönüşü zorlaştırır.

Dar kapsamlı yaklaşım: belirli bir servis/akıș için daha ölçülebilir, daha kolay açıklanır; kanıt zinciri daha nettir.
Geniş kapsamlı yaklaşım: daha esnek görünür; fakat gecikme, korelasyon zorluğu ve görünürlük maliyeti artar.

Bazı ağ ölçüm/doğrulama yaklaşımları "tam TCP bağlantısı" mantığıyla yürürken, bazıları ham paket üretimi gibi daha düşük seviyeli yeteneklere dayanır. Ham paket gerektiren yaklaşımlar, araya uygulama-katmanı bir yönlendirme/proxy girdiğinde doğasını kaybeder; dolayısıyla "gördüğüm sonuç ne kadar güvenilir?" sorusu daha kritik hale gelir.

2.3. Pivot iddiasını doğrulamak: koşullar + görünürlük

Pivoting iddiası iki soruyu birlikte cevaplamalıdır:

Hangi koşullarda çalışır? (zaman penceresi, politika, kimlik kapsamı, segment kuralı)
Savunma görünürlüğü nedir? (hangi telemetri katmanlarında iz bırakır; hangi kontrol bunu engeller/tespit eder)

Burada "çalışmıyor/engelleniyor" sinyali de değerlidir: segmentasyonun nerede gerçekten işe yaradığını kanıtlar ve raporu daha dürüst kılar.

2.4. Stop/rollback: pivot "kalıcı köprü" değildir

İzinli değerlendirmede pivot, geçici ve geri alınabilir bir değerlendirme aracı olmalıdır. Stop kriterleri örneğin şunlara bağlanabilir:

beklenmeyen performans/kararlılık etkisi
kapsam dışı yüzeye temas riski
kanıt kalitesinin düşmesi (belirsizlik artışı)
RoE/etik sınırın "kanıt"tan "zarar"a kayma riski

3) Tünelleme ve tali kanallar: görünürlük ve kontrol noktaları

Bu başlık, tekniğin "nasıl"ına değil, savunma görünürlüğüne ve kontrol noktalarına odaklanır. Tünelleme genel olarak trafiği bir taşıyıcı içinde kapsülleyerek farklı bir yoldan taşıma fikridir; tali kanallar ise kurumsal süreçler nedeniyle açık kalan ikincil iletişim yollarını (proxy/çıkış altyapısı, uygulama katmanı akışları, DNS vb.) kapsar.

3.1. Nerede iz bırakır, nerede kaybolur?

Bir kanalın riski sadece "açık" olması değildir; izlenebilirlik kalitesi belirleyicidir:

Egress kontrolleri: çıkış kuralları, izin listeleri, proxy zorlamaları
Kimlik bağlamı: trafik bir kimlikle/varlıkla ne kadar ilişkilendirilebilir?
Şifreli trafik: içerik görünmeyebilir; ama meta-veri (sıklık, hedef, hacim) çoğu zaman görünür kalır
Meşru gürültü etkisi: bazı kanallar, normal iş trafiği içinde anomaliyi saklamaya daha elverişli olabilir; bu savunma için tasarım borcudur

3.2. DNS üzerinden anomali düşünmek: "içerik değil, davranış"

DNS tünelleme riskinde savunmanın en pratik kaldıraçlarından biri, içerikten çok davranışsal anomali aramaktır. Tipik göstergeler; olağandışı yüksek sorgu hacmi, çok sayıda benzersiz alt alan adı, uzun/entropisi yüksek etiketler, sıra dışı kayıt türlerinin yoğunluğu ve başarısız çözüm oranlarındaki artış gibi örüntülerdir.

İpucu: "Görünmez olmak" başarı metriği değildir. Doğru hedef, gereksiz gürültü üretmeden savunmanın hangi kontrol boşluğunu kapatması gerektiğini gösterecek kadar denetlenebilir kanıt üretmektir.

3.3. Yöntem seçimi: basit yol varken karmaşığı seçmemek

Aynı "segment geçişi" iddiasını göstermek için birden fazla yol tasarladığında şunu unutma:

Karmaşıklık arttıkça belirsizlik artar (neden-sonuç zor açıklanır).
Karmaşıklık arttıkça operasyonel yük artar (iz sürme, geri dönüş, koordinasyon).
Bazı kanallar RoE/etik açıdan daha hassas sayılabilir (iş süreçlerine etki riski).

Bu yüzden ileri seviye karar, çoğu zaman "en zekice" değil; en ölçülebilir, en düşük riskli ve en iyi izah edilebilir olanı seçmektir.

4) Ağ segmentasyonu ve güvenlik sınırları: neyi gerçekten engeller?

Segmentasyon, pratikte bir "duvar"dan çok bir kontrol hedefleri setidir: yetkisiz doğu-batı trafiğini azaltmak, kritik varlıkların etki alanını daraltmak, kimlik temelli erişimi kısıtlamak ve görünürlüğü artırmak. Ancak kimlik ve yönetim düzlemi doğru ayrıştırılmadıysa, "firewall var" cümlesi gerçek koruma kalitesini tek başına anlatmaz.

4.1. Segmentasyonun tipik kör noktaları

Kimlik temelli geçiş: ağ yolu kısıtlı olsa bile, yetkili kimlik yanlış yerde fazla güçlü olabilir
Yönetim düzlemi istisnaları: "her yere erişmesi gereken" servisler/araçlar segmentasyonu delik deşik edebilir
Dual-homed (çift bacaklı) sistemler: iki güven bölgesine aynı anda bağlı varlıklar, tasarım gereği geçiş düğümü olur
İzleme boşluğu: kontrol var ama kayıt yoksa, doğrulama zayıflar; rapor da zayıflar

Örnek: Kritik veri segmenti ağ kuralı ile korunur; fakat yedekleme altyapısı bu segmente geniş erişim taşır. Bulgu "segmentasyon yok" değildir; segmentasyonun istisnalarının kimlik ve yetkiyle nasıl risk büyüttüğüdür.

4.2. "Geçiş var" iddiasını nasıl kanıt standardında daraltırsın?

Ulaşılabilirlik kanıtını, yetki/aksiyon sınıfı kanıtıyla karıştırma.
Zaman uyumsuzluğu veya kayıt gecikmesi varsa, iddiayı daralt ve belirsizliği yönet.
Karşı kanıt olarak "engellendi" sinyallerini de topla: segmentasyonun nerede işe yaradığını gösterir.

Dikkat: Segmentasyon doğrulamasında geniş, rastgele denemeler "daha çok veri" üretir gibi görünse de çoğu zaman sadece noise üretir ve denetlenebilirliği düşürür. İleri seviye yaklaşım, iddiayı taşıyacak minimum ve ölçülebilir kanıta odaklanır.

4.3. Savunma iyileştirmesine bağlamak: kontrol hedefi dili

Bu modülün çıktısı teknik "hareket anlatısı" değil; savunmanın aksiyona dökebileceği kontrol hedefleridir:

yönetim düzlemi ayrıştırması, asgari yetki
segment istisnalarının azaltılması ve gerekçelendirilmesi
kimlik hijyeni (servis hesapları/rol kapsamı/tekrar kullanım riskleri)
doğu-batı görünürlüğünün artırılması (kimlik + ağ telemetrisi korelasyonu)
kritik varlıklar için ikinci kontrol katmanı (koşullu erişim, ek doğrulama, sıkı egress)

Terimler Sözlüğü

Terim	Açıklama
Lateral movement	Yatay hareket; aynı ortam içinde başka varlıklara ilerleme olasılığı ve bunun patika olarak modellenmesi
Pivoting	Pivotlama; bir ara nokta üzerinden erişim/gözlem kapsamını genişletme yaklaşımı
Segment	Ağ/güven bölgesi; farklı güven kurallarıyla ayrılmış alan
Trust relationship	Güven ilişkisi; bir kimliğin/rolün/servisin başka bir alanda yetki doğurması
Trust boundary	Güven sınırı; geçildiğinde riskin büyüdüğü kontrol çizgisi
Jump host / jump point	Sıçrama noktası; pivot için kullanılan ara varlık
East–west traffic	Doğu-batı trafiği; iç ağ içinde sistemler arası yatay trafik
Blast radius	Etki yarıçapı; bir hatanın/olayın yayılabileceği alan
Reachability	Ulaşılabilirlik; ağ yolunun varlığı (tek başına yetki anlamına gelmez)
Authorization (authz)	Yetkilendirme; “ne yapabilir?” sorusunun cevabı
Tunneling	Tünelleme; trafiği kapsülleyerek farklı bir taşıyıcı üzerinden iletme fikri
Covert channel	Örtük kanal; beklenmeyen iletişim yolu üzerinden kontrol/veri akışı riski (kavramsal)
Egress control	Çıkış kontrolü; dışa doğru trafik kuralları ve izin listeleri
Traceability	İzlenebilirlik; iddianın bağlamının denetlenebilir olması
Noise	Gürültü; log/telemetri/alarmlarda operasyonel yük ve görünürlük maliyeti
False Positive (FP)	Yanlış pozitif; hatalı bulgu/yanlış alarm üretimi
Dual-homed	Çift bacaklı; birden fazla güven bölgesine aynı anda bağlı sistem
Management network/VLAN	Yönetim ağı; operasyonel gerekliliklerle geniş istisnalar taşıyabilen yönetim düzlemi segmenti

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir ekip “segment geçişi mümkün” iddiasını raporlamak istiyor. En olgun kanıt yaklaşımı hangisidir?

A) Yalnızca ağ diyagramında iki segment arasında rota olduğunu göstermek

B) Tek bir log kaydını “kesin geçiş” diye yorumlamak

C) Ulaşılabilirlik + kimlik bağlamı + aksiyon sınıfı ayrımı yapıp, iddiayı karşı kanıt arayışıyla daraltarak paketlemek

D) “Muhtemelen geçilir” deyip kanıtı karşı tarafa bırakmak

E) “Erişim varsa her şey olur” varsayımıyla en kritik segmente gidildiğini kabul etmek

Doğru: C
Gerekçe: C, kaynak–iddia–kanıt ayrımını, bağımsız doğrulamayı ve karşı kanıt disiplinini birlikte taşır. A/B tek sinyale dayanır; D denetlenebilirlik üretmez; E yanlış kesinliktir.

2) Lateral movement analizinde “yöntem seçimi” en çok hangi trade-off’u yönetir?

A) Yalnızca hız–maliyet

B) Noise/FP – izlenebilirlik – operasyonel yük – etik/OPSEC sınırı dengesi

C) Kullanılan aracın popülerliği

D) En yüksek yetkiyi en hızlı ele geçirme hedefi

E) Yalnızca ağ bant genişliği

Doğru: B
Gerekçe: Bu modülün omurgası karar kalitesi ve maliyetlerdir. Diğerleri tek boyutludur.

3) Farklı kaynaklardan gelen zaman damgaları uyuşmuyor. En doğru yaklaşım hangisidir?

A) Çelişkiyi yok saymak, “zaten geçiş oldu” demek

B) Zaman uyumsuzluğunu rapordan çıkarmak

C) İddiayı daraltıp belirsizliği açıkça ifade etmek; hangi veri gelirse fikrin değişeceğini yazmak

D) Zaman uyumsuzluğu varsa bulguyu tamamen iptal etmek

E) Zaman uyumsuzluğunu “kesin saldırı var” diye yorumlamak

Doğru: C
Gerekçe: C, belirsizlik yönetimi ve denetlenebilirliktir. A/B şeffaflığı bozar; D gereksiz erken hüküm; E hatalı çıkarımdır.

4) Pivot (jump noktası) seçerken en doğru ilke hangisidir?

A) En güçlü makineyi seçmek

B) En az iz bırakacağını düşündüğün noktayı seçmek

C) Scope uyumu + blast radius + izlenebilirlik + rollback kriterleriyle en yönetilebilir riski seçmek

D) Sadece “kimse fark etmesin” hedefine göre seçmek

E) Ağ topolojisinde en merkezi noktayı seçmek

Doğru: C
Gerekçe: C, profesyonel pivot kararının çekirdeğidir. A/E “güç/merkezilik” yanılgısı; B/D yanlış metriklerdir.

5) “Ulaşılabilirlik” ile “yetkili erişim/iş etkisi” ayrımı neden kritiktir?

A) Ulaşılabilirlik her zaman daha tehlikelidir

B) Yetkili erişim her zaman ağ yoluna ihtiyaç duymaz

C) Ulaşılabilirlik kanıtı tek başına iş etkisi iddiasını desteklemez; yanlış kesinliğe yol açar

D) İkisi aynı anlama gelir; ayrım gereksizdir

E) Yetkilendirme yalnızca uygulama katmanında olur; ağla ilgisi yoktur

Doğru: C
Gerekçe: Modülün ana kazanımı budur: “yol var” ≠ “etki var”. A/D/E genellemeleri hatalı; B bazı durumlarda doğru olsa da sorunun odağı C’dir.

6) Uygulama-katmanı yönlendirme/proxy araya girdiğinde bazı ağ ölçümlerinin güvenilirliği neden düşer?

A) Proxy’ler tüm protokolleri aynı doğrulukla taşır

B) Proxy’ler yalnızca şifreli trafik taşıdığı için

C) Bazı yaklaşımlar ham paket düzeyinde kontrol gerektirir; araya katman girdiğinde bu özellik kaybolur ve sonuçlar yorumlanması zorlaşır

D) Proxy gecikmesi her zaman sıfırdır

E) Çünkü segmentasyon otomatik olarak devre dışı kalır

Doğru: C
Gerekçe: Ham paket/bağlantı semantiği farkı, kanıtın doğasını değiştirir.

7) DNS tünelleme riskini savunma açısından “davranışsal anomali” ile yakalamaya çalışırken en güçlü gösterge kümesi hangisidir?

A) DNS’in hiç kullanılmaması

B) Çok sayıda benzersiz alt alan adı + anormal sorgu hacmi + uzun/entropisi yüksek etiket örüntüsü

C) Sadece tek bir TXT kaydı görülmesi

D) Yalnızca ping yanıtlarının gecikmesi

E) Sadece kullanıcı şikâyetleri

Doğru: B
Gerekçe: Davranışsal göstergeler (hacim/benzersizlik/entropi) tünel benzeri örüntülerde daha ayırt edicidir.

8) Segmentasyonun pratikte en sık “yanlış güven” üreten kör noktası hangisidir?

A) Yönetim düzlemi istisnalarının genişliği ve kimlik/rol kapsamının gereğinden güçlü olması

B) Ağ cihazlarının markası

C) Fiziksel kablo düzeni

D) Sunucu kasasının modeli

E) Kullanıcı ekran çözünürlüğü

Doğru: A
Gerekçe: Segmentasyon çoğu zaman kimlik ve yönetim istisnalarından delinmektedir; diğerleri alakasızdır.

9) “Dar kapsamlı” pivot yaklaşımını tercih etmek hangi durumda en rasyoneldir?

A) Kanıt zincirinin net olması ve geri dönüş planının kritik olması gerektiğinde

B) Sadece daha heyecanlı görünmesi için

C) Kapsam belirsizken daha fazla yüzeye dokunmak için

D) Zaman uyumsuzluğu varken iddiayı büyütmek için

E) Noise maliyeti önem taşımıyorken bile

Doğru: A
Gerekçe: Dar kapsam, izah edilebilirlik ve denetlenebilirlik sağlar; diğerleri kalite/etik açısından zayıf motivasyonlardır.

10) Lateral movement sırasında “go/no-go” kararını en doğru tetikleyen durum hangisidir?

A) Yeni bir servisin keşfedilmesi

B) “Daha derine inmek” hissi

C) Kanıt üretmeyen adımların artması, belirsizlerin büyümesi ve kapsam dışına taşma riskinin yükselmesi

D) Raporun kısa kalması endişesi

E) Karşı tarafın daha fazla bulgu istemesi

Doğru: C
Gerekçe: Olgun stop kriteri; kalite, etik ve kapsam disiplinini birlikte korur.

Bu Modülde Kazanılan Yetkinlikler

Yatay hareketi "daha çok sistem" hedefiyle değil, kimlik-yetki-güven ilişkileri üzerinden okunan bir patika olarak kurma
Segment geçişi iddialarında ulaşılabilirlik / kimlik / yetki-iş etkisi ayrımını yapma ve iddiayı bağımsız doğrulama + karşı kanıtla daraltma
Pivoting kararlarını kapsam, blast radius, izlenebilirlik, rollback, noise/FP kriterleriyle yönetme
Tünelleme ve tali kanalları "yöntem tarifi" yerine görünürlük ve kontrol noktaları üzerinden savunma odaklı modelleme
Bulguları gözlem-yorum ayrımı, izlenebilirlik ve confidence diliyle denetlenebilir ve aksiyonlanabilir hale getirme

MODÜL 10 — İleri Active Directory & Kurumsal Kimlik Patikaları

Modül Teması

Trust & Forest

Trust türleri, SID history, forest sınırları.

Kerberos

Kerberoasting, AS-REP, delegation, S4U abuse.

Hibrit Kimlik

Azure AD Connect, PHS/PTA, federation saldırıları.

Kurumsal ortamlarda "yayılma" çoğu zaman kablo ve portlardan değil, kimlik ve yetki mimarisinden geçer. İleri seviye Red Teaming'de Active Directory (AD), zafiyeti aranan tekil bir yazılım gibi değil; nesneler, izinler, güven ilişkileri ve kontrol düzlemlerinden oluşan dinamik bir ilişki grafı gibi ele alınır. Bu modül, "Domain Admin olma" gibi tek hedefli düşünmenin ötesine geçerek; ACL tabanlı patikaları, Kerberos ve delegasyon mimarisinin risk geometrisini, sertifika altyapısındaki (AD CS) tasarım hatalarını, trust/forest sınırlarının gerçek etkisini, GPO'nun kontrol düzlemi rolünü ve SQL/uygulama bağımlılıklarının kimlik grafına nasıl "gizli köprü" eklediğini tutarlı bir çerçevede birleştirir. Odak, araç ezberi değil; doğrulama, kanıt zinciri, belirsizlik yönetimi ve yöntem seçimi ile "karmaşık yetki matrisini" savunma değeri üreten bir bulgu setine dönüştürmektir.

Bu Modülde Hedeflenen Kazanımlar

AD'yi statik bir kullanıcı listesi değil, nesneler ve izinlerden oluşan dinamik bir graf olarak analiz etmek
Bir patika iddiasını kaynak--iddia--kanıt ayrımıyla kurmak; karşı kanıt arayarak doğrulamak
Kerberos bilet yaşam döngüsü ve delegasyon modellerinin (unconstrained / constrained / resource-based constrained) risklerini kavramsal düzeyde sınıflandırmak
AD CS şablonlarında ve yetkilendirmesinde doğan kimlik risklerini koşullarına bağlı ve denetlenebilir şekilde ifade etmek
Trust/forest ve GPO gibi kontrol düzlemlerinde, "güvenlik sınırı" varsayımlarını ölçülebilir kanıtlarla test etmek
Uygulama/SQL bağımlılıklarının kimlik grafına eklediği "güven köprülerini" görünür kılıp, Modül 12 (tespit perspektifi) ve Modül 17 (raporlama) çıktısına bağlamak

1) Kimlik grafı bakışı: Nesneler, izinler ve "gizli patikalar"

Geleneksel soru "Domain Admin grubuna kim üye?" iken, ileri seviye soru şudur: "Bu üyeliği kim dolaylı olarak etkileyebilir?" veya "Bu yetkili kimliğin oturum açtığı yüzeyler nereler?". Çünkü AD'de güç, sadece "rollerde" değil; ACL/ACE gibi ince taneli izinlerde, iç içe gruplarda, servis hesaplarında, politika bağlarında ve topoloji kararlarında birikir.

1.1. Düğümler ve kenarlar: grafın sözlüğü

Düğümler: kullanıcılar, gruplar, bilgisayar hesapları, servis hesapları, GPO'lar, sertifika şablonları, yönetim sunucuları, kritik uygulama/DB sunucuları
Kenarlar: üyelikler (nested dahil), ACL yetkileri, delegasyon ilişkileri, trust ilişkileri, "uygulama bağımlılığı" (kim hangi servise hangi bağlamda erişir)

Bu bakış, tek bir zayıflığı "tek başına kritik" diye etiketlemek yerine, onu graf içinde konumlandırır: "Hangi kombinasyonlar Tier-0'a yaklaşan kısa yollar üretir?"

1.2. ACL/ACE analizi: "yetki" nerede saklanır?

AD'de yetki çoğu zaman şu bileşenlerin bileşimidir:

Kimlik tanımlayıcıları ve grup üyelikleri (doğrudan + iç içe)
Nesne izinleri (ACL/ACE)
Etkili izinler (effective access): bir kimliğin, tüm üyelikleri ve devralınan izinleriyle toplamda ne yapabildiği

İleri seviye değerlendirmede sık görülen kritik izin sınıfları şunlardır (tek başına "sömürü talimatı" değildir; risk ve kontrol hedefi anlatımı için bir dil sağlar):

Tam kontrol / geniş yazma yetkisi (nesnenin davranışını kökten değiştirebilen)
İzinleri değiştirme yetkisi (bir nesnenin güvenlik modelini yeniden yazabilen)
Parola etkisi üreten yetkiler (kimliği "devralma"ya giden kapılar)

Örnek: Düşük yetkili bir kullanıcı, bir grup nesnesi üzerinde geniş yazma yetkisine sahiptir. Bu grup, bir politika nesnesini yönetebiliyor; o politika da kritik bir OU'ya bağlı. Burada tek tek parçalar "maksimum yetki" gibi görünmeyebilir; ama zincir halinde, kontrol düzlemine yaklaşan bir patika üretir. Bu iddia raporda ancak kapsam (hangi OU/hangi varlık sınıfı) ve sınırlayıcı koşullar (tiering, link kapsamı, izleme, değişiklik yönetimi) ile birlikte anlam kazanır.

AD Path Evidence - Example

PS> AD-Audit # Düşük yetkili kullanıcıdan başlayan ilişki zinciri
PS> Get-ADUser -Identity user.helpdesk -Properties MemberOf | Select-Object -ExpandProperty MemberOf
CN=Ops-Support,OU=Groups,DC=example,DC=local

PS> AD-Audit # Grup nesnesindeki etkili yazma yetkilerini özetle
PS> Get-Acl "AD:\CN=Ops-Support,OU=Groups,DC=example,DC=local" | Select-String "WriteProperty|WriteDacl"
Allow  EXAMPLE\user.helpdesk  WriteProperty

PS> AD-Audit # Grup ile kritik OU etkisini bağlayan kısa kanıt
PS> .\path-summary.ps1 -Source user.helpdesk -TargetOU "OU=Tier0,DC=example,DC=local"
path_found=True  hops=3  confidence=medium  note="requires change-control bypass"

İpucu: Bir "patika" cümlesini rapora yazmadan önce, aynı paragrafta üç şeyi birlikte ver:

Kaynak sinyal: hangi izin/ilişki gözlemlendi?
İddia: bu sinyal hangi etkiye yol açabilir?
Karşı kanıt: hangi koşullarda bu etki doğmaz veya sınırlanır?

1.3. Doğrulama: graf çıktısı "bulgu" değildir

Graf görselleştirme araçları (ör. BloodHound gibi) güçlü bir başlangıç sağlar; ama ileri seviye kalite kapısı şudur: Grafın söylediğini, dizinin "yetki gerçeği" ile çakıştırmak.

İddia "X, Y üzerinde etkili" ise: bu etki hangi izinlerden geliyor?
Bu izinler doğrudan mı, yoksa nested üyelik/OU mirası gibi dolaylı mekanizmalarla mı?
Bu etki operasyonel olarak anlamlı mı, yoksa "kâğıt üzerinde" kalıyor mu? (örn. uygulanmayan politika, izole edilmiş yönetim sunucusu, kısıtlı erişim yolu)

Dikkat: "Bir izin ilişkisi var" ile "bu ilişki iş etkisine dönüşür" arasına kanıt koymadığında, raporun en büyük riski yanlış kesinlik olur. Yanlış kesinlik, yanlış güvenlik kararına dönüşür.

2) Kerberos ve delegasyon: meşru akışların risk geometrisi

Kerberos'u ileri seviyede önemli kılan, "bilet hilesi" anlatısı değil; bilet yaşam döngüsü ve delegasyonun tasarım varsayımlarıdır. Burada hedef; teknikleri öğretmek değil, hangi tasarım kararının hangi riski doğurduğunu ve bu riske dair kanıt standardını kurmaktır.

2.1. Bilet yaşam döngüsü: neden risk üretir?

Kerberos'ta biletler, kimliğin belirli bir süre ve bağlamda "yetki taşımasına" aracılık eder. Risk çoğunlukla şuralardan doğar:

servis hesaplarının gereğinden yüksek yetkiyle çalışması,
biletlerin/oturum bağlamlarının beklenmedik sistemlere taşınması,
kritik anahtarların/hesapların güvenlik varsayımının zayıflaması (bilet temelli "sahte kimlik" senaryolarını mümkün kılan sınıf riskler)

Bu noktada doğru dil, "şu yapılır" değil; "şu koşullar oluşursa bilet güvencesi zayıflar" dilidir.

2.2. Delegasyon modelleri: aynı hedef, farklı maliyetler

Delegasyon, bir servisin kullanıcı adına başka bir servise erişebilmesi için tasarlanmıştır. Ancak kapsam genişledikçe kimlik sınırları bulanıklaşır:

Kısıtlamasız delegasyon (unconstrained): risk genellikle en yüksektir; çünkü servis üzerinde oluşan oturum bağlamı, beklenmeyen kimlikleri "taşıyabilir".
Kısıtlı delegasyon (constrained): erişim hedefleri belirli servis kimlikleriyle sınırlandığında risk geometrisi değişir; doğrulama, "sınır gerçekten sınır mı?" sorusuna odaklanır.
Kaynak tabanlı kısıtlı delegasyon (RBCD): yetkilendirme mantığı "merkez" yerine hedef kaynağın kendisine yakın bir yerde tanımlandığında, kontrol noktaları da değişir; patika analizi, yetkiyi kimin nerede tanımlayabildiği sorusuna yoğunlaşır.

Örnek: Aynı iş ihtiyacını (web → DB) üç farklı delegasyon modeliyle çözen iki kurum düşün. Kağıt üzerinde "iş çalışıyor" aynıdır; ama denetim izi, yanlış yapılandırma ihtimali ve "beklenmedik kimlik taşınması" riski bambaşka bir profile dönüşür.

Delegation Comparison - Example

PS> Kerberos-Review # Delegasyon yapılarını özetle
PS> .\compare-delegation.ps1 -Service "WEBAPP01$" -Backend "MSSQL01$"
model=unconstrained   audit_visibility=low    identity_spill_risk=high
model=constrained     audit_visibility=medium identity_spill_risk=medium
model=rbcd            audit_visibility=high   identity_spill_risk=medium

PS> Kerberos-Review # Kanıt paketi için kısa karar satırı üret
PS> .\delegation-brief.ps1 -System WEBAPP01
decision="prefer constrained or RBCD with strict scope"
preconditions="tiering discipline + monitored service accounts"
next_review="30d"

2.3. Önkoşullar ve belirsizlik: risk "kendiliğinden" doğmayabilir

Delegasyon temelli risklerde sık yapılan hata, bulguyu önkoşulları yazmadan "kritik" ilan etmektir. Örneğin, bazı senaryolarda riskin gerçekleşmesi için:

belirli kimliklerin belirli servislere gerçekten bağlanması,
yönetim sunucularının tiering prensibine aykırı şekilde kullanılması,
izleme/uyarı kontrollerinin yetersiz kalması gibi koşullar gerekebilir.

İpucu: Delegasyon bulgusunu yazarken şu cümleyi zorunlu gör: "Bu riskin etkili olabilmesi için şu önkoşullar gerekir; şu kontrol/alışkanlıklar varsa etkisi düşer." Bu, hem doğruluğu artırır hem Modül 12'de tespit stratejisini doğrudan besler.

Dikkat: Kimliği "bağlanmaya zorlayan" davranış sınıfları, gerçek hayatta yüksek anomali üretme ve kurum operasyonunu etkileme riski taşır. İzinli çalışma çerçevesinde bile, bu tür yaklaşımlar OPSEC/etik sınır ve "minimum zarar" ilkesiyle değerlendirilmeden masaya konmamalıdır.

3) AD CS ve sertifika temelli kimlik: görünmeyen ikinci kontrol düzlemi

Birçok kurum AD'yi sıkılaştırırken, PKI/sertifika altyapısını "varsayılanlar" ile uzun süre yaşatır. Oysa sertifika temelli kimlik, yanlış tasarlandığında yetki grafında beklenmeyen kısa yollar üretebilir.

3.1. Şablonlar ve yetkiler: riskin iki kilidi

Sertifika riskleri çoğu zaman iki parçanın birlikte oluşmasıyla anlam kazanır:

Şablonun neye izin verdiği (hangi kullanım amaçları/kimlik doğrulama senaryoları)
Kimin talep edebildiği (enrollment/başvuru yetkisi ve bunun kapsadığı gruplar)

Bu nedenle "şablon tehlikeli" demek yetmez; şablon özellikleri + yetkilendirme kapsamı birlikte kanıtlanmalıdır.

Örnek: Bir şablon, kimlik doğrulamada kullanılabiliyordur; fakat bu şablonu yalnızca çok dar bir yönetim grubunun talep edebilmesi sağlanmıştır. Burada risk profili, "geniş kitle açık" senaryosundan tamamen farklıdır. Aynı şablon özelliği, farklı yetki kapsamıyla bambaşka sonuç verir.

3.2. Kanıt zinciri: "sömürülebilirlik" iddiası nasıl güvenli ifade edilir?

Bu modülün dili, "nasıl yapılır" dili değildir. Ama güvenli ve denetlenebilir bir rapor dili şunları içerir:

Şablonun kritik özelliklerinin özeti
Yetkilendirme kapsamı (hangi gruplar/hangi prensipler)
Olası etki (hangi kimlik senaryolarında risk büyür)
Karşı kanıtlar (ek kontroller, izleme, kısıtlar)
Confidence gerekçesi (konfigürasyonun deterministik oluşu, replike olma, log/denetim izleri vb.)

4) Trust ve forest: "sınır" sandığın şey gerçekten sınır mı?

Trust'lar çoğu zaman organizasyonel ihtiyacın sonucudur: birleşme, satın alma, iş ortaklığı, hizmet ayrımı... Ancak trust, yanlış varsayımlarla kurulursa kimlik grafını beklenmedik şekilde büyütür.

4.1. Trust türleri: aynı isim, farklı sonuçlar

Parent-child ilişkileri: genellikle geçişken güven varsayımları taşır; sınır algısı kolay bozulur.
External trust: kapsam ve geçişkenlik tercihleri risk geometrisini belirler.
Forest trust: iki orman arasında kimlik akışı doğurur; burada "güvenlik sınırı" tartışması en kritiktir.

İleri seviye yaklaşım, "trust var → kritik" gibi ezberlemez; şunu sorar: "Trust, hangi kimliklerin hangi kaynaklara hangi koşullarla erişim varsayımı taşımasına izin veriyor?"

4.2. SID History ve filtreleme: geçiş kolaylığı mı, yetki enflasyonu mu?

SID History gibi mekanizmalar, göç/migrasyon süreçlerinde yardımcı olabilir; ama yanlış yönetildiğinde "yetki enflasyonu" riskini büyütebilir. Bazı trust senaryolarında filtreleme/karantina mekanizmaları bu riski azaltmayı hedefler; ancak kurumun tasarım ve ayarlarına göre görünüm değişebilir. Bu yüzden rapor dili varsayım değil kanıt üretmelidir: "Filtreleme vardır/yoktur" iddiası, gözlemlenebilir konfigürasyon kanıtıyla desteklenmeden kesinleştirilmemelidir.

Dikkat: "Domain sınırı güvenlik sınırıdır" varsayımı çoğu ortamda yanıltıcıdır. Gerçek izolasyonun nerede başladığı, trust topolojisi, yönetim modeli ve tiering disiplininin birlikte değerlendirilmesiyle anlaşılır.

5) GPO: merkezi rahatlık, merkezi risk

Group Policy Objects (GPO), AD'nin sinir sistemidir: binlerce sistemin güvenlik duruşunu tek yerden şekillendirir. Bu güç, yanlış delegasyon veya zayıf değişiklik yönetimiyle birleştiğinde çok geniş etki alanına sahip bir kontrol düzlemi riskine dönüşür.

5.1. "GPO'yu kontrol eden neyi kontrol eder?"

Bir GPO'nun risk değeri iki şeyin çarpımıdır:

Yazma/yönetim yetkisi (kim değiştirebiliyor?)
Etkilediği kapsam (hangi OU/site/domain'e bağlı, nerede uygulanıyor?)

Bu yüzden "GPO üzerinde yetki var" bulgusu tek başına yetmez. Aynı yetki, etkisiz bir GPO'da düşük; kritik OU'ya bağlı bir GPO'da yüksek risk doğurur.

5.2. Kanıt standardı: "bağlı mı, uygulanıyor mu?"

Denetlenebilir rapor şu unsurları birlikte taşır:

GPO üzerindeki yetki ilişkisi (somut)
Link/kapsam bilgisi (somut)
Etkilenen varlık sınıfı (DC'ler, yönetim sunucuları, kullanıcı uç noktaları vb.)
Sınırlayıcı kontroller (tiering, değişiklik onayı, izleme, ayrı yönetim hesapları)

6) Uygulama ve SQL bağımlılıkları: kimlik grafına eklenen gizli köprüler

AD, sadece Windows sunucularından ibaret değildir. Uygulamalar ve veri katmanı, kimlik grafına "gizli kenarlar" ekler: servis hesapları, entegre kimlik doğrulama, sunucular arası güven tanımları...

6.1. Linked Server ve zincirleme güven: "kolaylık" maliyeti

Veritabanları arası bağlantılar, operasyonel kolaylık sağlar; fakat yüksek yetkili kimliklerle kurulmuş güven tanımları, bir noktadaki bozulmanın başka noktalara taşınmasına zemin hazırlayabilir. Burada ileri seviye analiz:

bağlantının hangi kimlik bağlamıyla çalıştığını,
yetkinin nerede "şiştiğini",
izleme/denetim eksikliği olup olmadığını

kanıt standardında ortaya koyar.

6.2. SPN'ler ve servis hesapları: kimlik kırılganlığı nerede büyür?

Servis hesapları genellikle SPN'lerle ilişkilidir ve bu hesapların parola politikaları/rotasyonu zayıfsa risk artar. Bazı Kerberos senaryolarında, meşru bilet mekanizmasının doğası gereği, servis hesabı parolalarına yönelik çevrimdışı tahmin riskleri gündeme gelir. Bu konu, Modül 8'deki "credential access" çerçevesiyle kesişir; bu modülde ise asıl hedef şudur:

"Hangi servis hesabı yüksek yetkiye yakın?"
"Parola hijyeni ve rotasyon disiplininde zayıflık var mı?"
"Bu riskin savunma çıktısı nedir?" (asgari yetki, ayrı servis kimlikleri, güçlü parola/rotasyon, izleme)

Terimler Sözlüğü

Terim	Açıklama
Active Directory (AD)	Kurumsal dizin; kimlik, grup, cihaz ve yetki ilişkilerinin merkezi
Relationship Graph / Yetki grafı	Kimlik ve nesneler arasındaki ilişkilerin “patika” üretecek şekilde modellenmesi
Domain	AD yönetim alanı; politika ve kimlik kapsamı
Forest	Birden çok domaini kapsayan üst yapı; trust varsayımlarının en geniş sınırı
ACL (Access Control List)	Bir nesneye kimin hangi izinle erişebileceğini tanımlayan liste
ACE (Access Control Entry)	ACL içindeki tekil izin kaydı
Effective Permissions	Üyelikler ve mirasla oluşan toplam (etkili) yetki
Kerberos	Bilet tabanlı kimlik doğrulama protokolü
TGT / TGS	Kerberos’ta kimlik doğrulama ve servis erişimi için bilet türleri
SPN (Service Principal Name)	Kerberos’ta servis kimliğini tanımlayan kayıt; servis hesabıyla ilişkilidir
Delegation	Bir servisin kullanıcı adına başka servislere erişmesini sağlayan mekanizma
Unconstrained / Constrained / RBCD	Delegasyon kapsamını belirleyen farklı model sınıfları
AD CS	Active Directory Certificate Services; sertifika altyapısı/PKI bileşeni
Certificate Template	Sertifika şablonu; kimlerin hangi amaçlarla sertifika alabileceğini tanımlar
PKI	Açık anahtar altyapısı; sertifika/anahtar yaşam döngüsü yönetimi
SID History	Göç süreçlerinde eski kimlik izlerini taşıyabilen; yanlış yönetilirse risk doğurabilen mekanizma
SID Filtering / Quarantine	Trust üzerinden taşınan bazı yetki bileşenlerini sınırlamayı hedefleyen filtreleme yaklaşımı
GPO	Merkezi politika nesnesi; yapılandırma ve güvenlik duruşu kontrol düzlemi
SYSVOL	GPO içeriklerinin dağıtıldığı alan; politika bütünlüğü açısından önemlidir
Linked Server	SQL sunucuları arasında güven/erişim köprüsü kurabilen yapılandırma
Least Privilege	İş için gereken minimum yetkiyle çalışma prensibi
Tiering Model	Yönetim ve kimliklerin katmanlara ayrıldığı güvenlik yaklaşımı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) “AD üzerinde kritik bir patika var” iddiasını raporda en olgun şekilde kuran yaklaşım hangisidir?

A) Tek bir grup üyeliğini gösterip “tam yetki” demek

B) Sadece bir graf çıktısını ekleyip “kanıt tamam” demek

C) İlişki sinyalini bağlama oturtup, önkoşulları ve karşı kanıtları yazarak iş etkisi iddiasını daraltmak

D) Etkiyi kanıtlamadan “en kötü senaryo”yu kesin gerçek gibi yazmak

E) Belirsizlik varsa bulguyu tamamen dışarıda bırakmak

Doğru: C
Gerekçe: C; kaynak–iddia–kanıt, önkoşul ve karşı kanıt disiplinini birlikte taşır. A/B kanıtı zayıflatır, D yanlış kesinlik üretir, E riskin görünür olmasını engelleyebilir.

2) Graf düşüncesinin AD analizinde temel avantajı nedir?

A) Tek bir zayıflıkla tüm resmi açıklaması

B) Farklı ilişkilerin birleşiminden doğan “kısa yolları” görünür kılması

C) Sadece ağ topolojisini göstermesi

D) Raporu uzatmayı kolaylaştırması

E) Operasyon adımlarını otomatikleştirmesi

Doğru: B
Gerekçe: Risk çoğu zaman ilişkilerin kombinasyonunda saklıdır. C, grafı yanlış tanımlar; D/E amaç dışıdır; A gerçekçi değildir.

3) Bir analizde “yetki sinyali” var ancak “iş etkisi” gösterilemiyor. En doğru raporlama dili hangisi olur?

A) Etkiyi varsaymak ve kesin yazmak

B) İddiayı “yetki sinyali var” düzeyine indirip, hangi şartlarda etkiye dönüşeceğini ve hangi şartlarda düşeceğini belirtmek

C) Bulguyu kesinlikle rapordan çıkarmak

D) Etkiyi kanıtlamak için kapsam dışına taşmak

E) Gerekçe yazmadan “kritik” etiketi koymak

Doğru: B
Gerekçe: B belirsizlik yönetimi ve kanıt standardıdır. A/E yanlış kesinlik; D kapsam disiplini ihlali; C her zaman doğru değildir.

4) Delegasyon risklerinde “önkoşul” kavramını en iyi açıklayan ifade hangisidir?

A) Risk, her zaman ve otomatik oluşur

B) Riskin etki üretmesi için belirli kimliklerin belirli bağlamlarda devreye girmesi gerekebilir; bu koşullar yazılmadan etki kesinleştirilemez

C) Sadece araç seçimiyle ilgilidir

D) Sadece ağ bant genişliğiyle ilgilidir

E) Sadece kullanıcı sayısıyla ilgilidir

Doğru: B
Gerekçe: Delegasyon riskleri bağlama duyarlıdır. A aşırı genelleme; C/D/E konu dışıdır.

5) AD CS/sertifika riskini değerlendirirken “iki kilit” yaklaşımı neyi anlatır?

A) Sadece şablon özellikleri önemlidir

B) Sadece kimin talep edebildiği önemlidir

C) Şablonun izin verdiği kullanım + bu şablonu talep edebilenlerin kapsamı birlikte değerlendirildiğinde risk anlam kazanır

D) Sertifikalar yalnızca cihaz yönetimi içindir

E) Sertifikalar risk üretmez

Doğru: C
Gerekçe: Risk, özellik + yetkilendirme kapsamı birleşiminde doğar. A/B tek taraflıdır; D/E yanlıştır.

6) Trust/forest analizinde “yanlış kesinlik” riskini azaltan en iyi yaklaşım hangisidir?

A) Trust varsa her zaman kritik demek

B) Trust görünmüyorsa kesin risk yok demek

C) Trust’ın yön/kapsam varsayımlarını, sınırlayıcı kontrolleri ve kanıtlanabilir konfigürasyonu birlikte değerlendirmek

D) Sadece topoloji diyagramı eklemek

E) “Detay veremem ama eminim” demek

Doğru: C
Gerekçe: C ölçülebilir kanıta dayanır. A/B genelleme; D tek başına yetersiz; E denetlenemez.

7) Bir GPO bulgusunun risk değerini en doğru belirleyen iki unsur hangisidir?

A) GPO’nun adı ve yaşı

B) GPO’ya yazma/yönetim yetkisi + GPO’nun uygulandığı kapsam (link/etki alanı)

C) GPO’nun renk teması ve sayfa sayısı

D) Kullanıcı sayısı ve ofis büyüklüğü

E) Sunucu markası ve model yılı

Doğru: B
Gerekçe: Yetki (kim değiştirebilir?) ve kapsam (nerede uygulanır?) birlikte risk üretir. Diğerleri anlamsızdır.

8) “Etkili izinler (effective permissions)” neden kritik bir kavramdır?

A) Çünkü izinler yalnızca teoriktir

B) Bir kimliğin doğrudan izni olmasa bile grup üyelikleri/miras ile toplamda hangi yetkilere sahip olduğunu gösterir

C) Sadece parola süresini gösterir

D) Sadece firewall kuralıdır

E) Dosya boyutunu gösterir

Doğru: B
Gerekçe: AD’de yetki kümülatiftir; gerçek risk “toplam yetki”de saklanır. A/C/D/E yanlış.

9) Linked Server benzeri veri katmanı “güven köprüleri” neden zincirleme risk doğurabilir?

A) Aynı IP bloğunda oldukları için

B) Bağlantılar yüksek yetkili kimlik bağlamlarıyla tanımlandıysa, bir noktadaki bozulma başka noktaya taşınabilir

C) SQL her zaman internete açıktır

D) Veriler şifreli olduğu için

E) Windows hiç kullanılmadığı için

Doğru: B
Gerekçe: Asıl risk, kimlik bağlamının/yetkinin taşınmasıdır. A/C/D/E genelleme veya alakasızdır.

10) “Forest sınırı” tartışmasında en doğru güvenlik yaklaşımı hangisidir?

A) Domain her zaman kesin güvenlik sınırıdır

B) Forest her zaman tek başına yeterli sınırdır; başka şeye bakılmaz

C) Sınırın nerede başladığı trust topolojisi + yönetim modeli + tiering + kanıtlanabilir kontrollerle birlikte değerlendirilir

D) Sınır tartışması gereksizdir

E) Sınır sadece firewall ile belirlenir

Doğru: C
Gerekçe: Sınır, mimari varsayımların toplamıdır; kanıt ve kontrol bağlamı olmadan kesin hüküm verilmez. A/B aşırı genelleme; D/E yetersizdir.

Bu Modülde Kazanılan Yetkinlikler

AD'yi "kullanıcı dizini" değil, yetki ve kontrol düzlemlerinin grafı olarak okuyabilme
Patika iddiasını kanıt standardında yazma: kaynak-iddia-kanıt + karşı kanıt + confidence
Kerberos ve delegasyonu "teknik numara" değil, meşru akışların risk geometrisi olarak değerlendirme
AD CS/PKI dünyasında riskin şablon + yetkilendirme kapsamı birleşiminde doğduğunu netleştirme
Trust/forest ve GPO gibi alanlarda, "sınır" varsayımlarını ölçülebilir kontrollerle test etme

MODÜL 11 — C2 Mimarisi, Altyapı Tasarımı & OPSEC

Modül Teması

C2 Mimarisi

Beacon, P2P, async ve katmanlı altyapı.

Redirector & Fronting

Trafik gizleme ve atfedilebilirlik yönetimi.

OPSEC

Kayıt, izleme, atfetme yüzeyi ve geri çekilme.

İleri seviye Red Team çalışmalarında C2 (Command & Control), "bir bağlantı almak"tan çok daha fazlasıdır: operasyonun kontrol düzlemidir. Süreklilik, minimum zarar ilkesi, tespit gerçekliğiyle uyum ve kanıt üretimi; bu düzlemin ne kadar iyi tasarlandığına bağlıdır. Bu modülde C2'yi "şunu kur, bunu çalıştır" gibi uygulanabilir talimatlara indirgemeden; mimari kararlar, trade-off'lar, OPSEC disiplini, doğrulama mantığı ve savunmaya çevrilebilir çıktılar üzerinden ele alıyoruz. Modül 10'daki kimlik/izin patikaları ile Modül 12'deki tespit perspektifini aynı resmin içine alıp, C2 ve altyapı kararlarının nasıl kanıt standardında raporlanacağını ve nasıl iyileştirme backlog'una dönüşeceğini konuşuyoruz.

Bu Modülde Hedeflenen Kazanımlar

C2'yi bileşenlerine ayırıp bir kontrol düzlemi olarak modellemek; mimari seçimlerin risk/maliyetlerini açıklayabilmek
Altyapı (alan adı/IP/hosting/sertifika/erişim yönetimi) kararlarını OPSEC ve minimum zarar ilkelerine göre çerçevelemek
"Görünürlük-gürültü-etki" dengesini kurmak: bir C2 davranışının hangi telemetriyi tetikleyebileceğini öngörmek ve doğrulamak
Bulguları gözlem-yorum ayrımıyla paketlemek; izlenebilirlik, zaman uyumu ve confidence diliyle raporlamak
Kapsam ve etik sınırları korumak için deconfliction ve acil durdurma (kill-switch) gibi güvenlik freni mekanizmalarını kavramsal olarak kurgulamak
C2 bulgularını Modül 12 (tespit) ve Modül 17 (raporlama/purple teaming) hattına bağlayarak savunma iyileştirmesine çevirmek

1) C2: "bağlantı" değil, kontrol düzlemi

C2; sahadaki ajan/implant ile operatör arasındaki iletişimi sağlayan mimaridir. İleri seviyede mesele "iletişim var mı?" değil; iletişim nasıl yönetiliyor, risk nasıl kontrol ediliyor, ölçüm nasıl yapılıyor? sorularıdır.

1.1. C2'nin bileşenleri ve roller

İleri seviye pratikte C2, çoğunlukla şu roller etrafında düşünülür:

Agent / Implant: Uç sistemde çalışan, komutları alıp sonuçları ileten bileşen.
Listener / Endpoint: Agent'ın konuştuğu, dışarıya açık veya erişilebilir iletişim ucu.
Team Server: Operasyon yönetimi, görevleme ve kayıtların tutulduğu merkez; "beyin" rolündedir.
Redirector / Relay: Trafiği araya alıp yönlendiren katman; görünürlük ve risk yönetiminde "kalkan" görevi görür.
Operatör yüzeyi: Konsol/arayüz ve insan süreçleri; OPSEC hatalarının en sık üretildiği yer burasıdır.

Bu modülde amaç, bu parçaları tek tek "kurmayı" öğretmek değil; her parçanın hangi güvenlik varsayımına dayandığını, hangi telemetri izlerini üretebileceğini ve hangi sınırlar içinde kullanılması gerektiğini netleştirmektir.

1.2. Kontrol düzlemi ve veri düzlemi: denetlenebilirlik nerede başlar?

Kontrol düzlemi (control plane): "Kim, neyi, ne zaman, hangi yetkiyle yaptı?" sorusunun cevabını üreten katmandır.
Veri düzlemi (data plane): Taşınan içerik ve iş sonuçlarıdır (çıktılar, kanıtlar, envanter parçaları vb.).

İleri seviye profesyonellik; kontrol düzlemini izlenebilir, denetlenebilir ve asgari veri ilkesiyle yönetilebilir tutmaktır: kritik kararlar gerekçelendirilir, beklenmeyen davranışlar için güvenlik freni düşünülür, kanıtlar "yeniden okunabilir" ve "tartışılabilir" formatta paketlenir.

Dikkat: "Kolaylık" refleksi çoğu zaman iki risk üretir: (1) gereksiz gürültü ve yanlış pozitif yükü, (2) kapsam/etik sınırların fark edilmeden aşılması. İleri seviye başarı, daha çok şey yapmakta değil; daha doğru, ölçülebilir ve kanıtlı şey yapmakta ölçülür.

1.3. Gereksinim çıkarımı: C2 tasarımı senaryodan doğar

Modül 1'deki RoE ve yönetişim çerçevesi burada belirleyicidir. C2 mimarisi senaryonun hedefleriyle uyumsuzsa ya risk üretir ya ölçümü bozar. Örneğin hedef "SOC korelasyon kabiliyetini ölçmek" ise "tam görünmezlik" saplantısı yanlış ölçüm doğurabilir; hedef "minimum operasyonel etki" ise gereksiz gürültü yanlış olur. Doğru soru şudur:

"Bu mimari, hangi savunma kontrolünü ölçmeme ve hangi kanıtı üretmeme yardım ediyor?"

2) İletişim kanalı tasarımı: yöntem seçimi ve trade-off'lar

C2 mimarisinde tek doğru yoktur; ancak her seçimin bir bedeli vardır: gürültü, tespit, operasyonel yük, etik/OPSEC riski ve raporlanabilirlik.

2.1. Short-haul ve long-haul: hız mı, sessizlik mi?

Short-haul (kısa menzil / interaktif): Düşük gecikme, yüksek etkileşim ihtiyacına uygun düşünülür. Avantajı hız; riski görünürlük ve gürültüdür.
Long-haul (uzun menzil / süreklilik): Düşük bant genişliği, daha seyrek temas mantığıyla ele alınır. Avantajı daha düşük "ritim izi"; riski gecikme ve sınırlı etkileşimdir.

Burada ileri seviye yaklaşım, "hangisi daha gizli?" değil; "hangi hedef için hangi risk kabul edilebilir?" sorusudur. Modül 13'teki "zarar vermeden etki" yaklaşımıyla uyumlu olarak, uzun menzil kanallar çoğu zaman minimum etki hedefiyle daha kolay hizalanır; ancak ölçüm hedefi (ör. tespit/korelasyon) farklı bir seçimi gerektirebilir.

Örnek: Kurgusal bir kurumda egress filtreleri sadece belirli iş kategorilerine izin veriyor. Bir kanal seçimi yapılacaksa "başarı ihtimali" ile "operasyonel iz" birlikte değerlendirilir; daha pahalı/zahmetli olan seçenek bazen daha yüksek güvenilirlik (confidence) üretebilir, bazen de ölçümü bulanıklaştırır. Bu nedenle karar, senaryodaki ölçüm hedefleriyle birlikte yazılı gerekçeye bağlanır.

Channel Trade-off Notes - Example

$ pt-c2-review # Egress kısıtlarını ve aday kanalları karşılaştır
$ python compare_channels.py --policy egress-policy.yaml
channel=http-short   success_prob=0.68  opsec_risk=0.52  detection_noise=high
channel=https-long   success_prob=0.74  opsec_risk=0.31  detection_noise=medium
channel=dns-fallback success_prob=0.41  opsec_risk=0.60  detection_noise=high

$ pt-c2-review # Ölçüm hedefine göre öneri üret
$ python channel_decision.py --goal "soc-correlation-quality"
recommended=https-long
rationale="lower noise + better traceability for correlation testing"

2.2. Beaconing davranışı ve "ritim izi": düzenlilik çoğu zaman alarm üretir

Ağ trafiği içerik olarak şifreli olsa bile; zamanlama aralıkları, paket boyutları ve iletişim ritmi "makine düzenliliği" üretebilir. Bu yüzden ileri seviyede "beaconing behavior" şöyle okunur:

Düzenlilik arttıkça tespit edilebilirlik artabilir (özellikle davranışsal/anomali odaklı sistemlerde).
Rastgelelik (jitter) arttıkça düzenlilik azalır; ancak komut gecikmesi ve operasyonel kontrol maliyeti artabilir.
Aşırı karmaşıklık, doğrulama ve raporlama kalitesini düşürebilir: "ne oldu?" sorusu zorlaşır.

İpucu: Zamanlama kararlarını "operasyon ritmi" ile eşleştir. Kurumun çalışma saatleri, haftalık yoğunluk döngüleri ve değişiklik pencereleri; tespit açısından çoğu zaman protokolden daha belirleyicidir.

2.3. Trafik profili ve "normal davranış taklidi": taklit edilebilir olanla edilemeyeni ayır

"Malleable C2 profile" yaklaşımı, trafiğin görünüşünü kurumda yaygın olan örüntülere benzetmeyi hedefler. Burada kritik nüans şudur: bazı yüzeyler taklit edilebilir, bazıları ise doğrulama için 'sabit' kalır.

Taklit edilebilir yüzeyler: bazı HTTP başlık örüntüleri, istek biçimleri, içerik türleri gibi "kozmetik" katmanlar.
Doğrulama için sabit kalan yüzeyler: hedefin gerçekten kim olduğu, sertifika/alan adı bağlam tutarlılığı, ağ topolojisindeki "olması mümkün mü?" sorusu gibi unsurlar.

Örnek: Bir trafik, yüzeyde popüler bir içerik dağıtım servisini andırabilir; ancak analist "gidebileceği yer" ve "bağlam tutarlılığı" üzerinden ayrıştırma yapar. Raporda doğru ifade şu şekildedir: "Şu benzerlikler gözlendi" (gözlem) ve "Şu tutarsızlıklar ayrıştırdı" (karşı kanıt).

Dikkat: "Tespit edilemez profil" diye bir güvence dili kullanmak ileri seviye raporlama için zayıftır. En doğru yaklaşım: hangi koşullarda daha az sinyal ürettiğini, hangi koşullarda riskin arttığını ve hangi veriler gelirse fikrinin değişeceğini açıkça yazmaktır.

2.4. "Kavramsal teknikler"in ömrü: değişen savunma gerçekliği

Bazı yaklaşımlar zaman içinde sağlayıcılar ve güvenlik kontrolleri tarafından kısıtlanır veya davranışsal olarak daha görünür hale gelir. Bu nedenle ileri seviyede amaç, tek bir "hile"ye bel bağlamak değil; rotasyon, doğrulama ve ölçüm disiplinini kurmaktır. Modül 12'de göreceğiniz gibi, savunma tarafı sadece "imza" ile değil; bağlam ve davranış ile de çalışır. Bu yüzden her mimari karar, "bugün çalışıyor gibi görünse bile" yarın değişebilir varsayımıyla ele alınır.

3) Katmanlı (tiered) altyapı: dayanıklılık ve izolasyon

Profesyonel bir kurguda hedef sistem, doğrudan Team Server ile konuşacak şekilde tasarlanmaz. Arada feda edilebilir katmanlar bulunur; amaç "her şeyi gizlemek" değil, riskin dağıtılması ve ana varlıkların korunmasıdır.

3.1. Redirector neden "sigorta"dır?

Team Server operasyonun kalbidir: kayıtlar, görevleme ve kontrol burada toplanır.
Redirector ise "feda edilebilir" katmandır: bir engelleme/bloklama durumunda kaybı daha yönetilebilir olur; ana varlıklar doğrudan görünür olmaz.

Bu, Modül 9'daki pivot/segment geçişi düşüncesine benzer bir prensibi altyapıya uygular: tek nokta kırılganlığını azaltmak.

3.2. Burn & build (kullan-at) zihniyeti: süreklilik için yeniden üretilebilirlik

"Burned infrastructure" (tespit edilmiş/engellenmiş altyapı) gerçeği, Red Team operasyonlarında kaçınılmaz bir risk olarak görülür. Burada olgunluk ölçütü şudur: "Bir parça yandığında, bunu yönetilebilir şekilde değiştirip ölçümü sürdürebiliyor musun?"

Bu nokta, otomasyon (IaC) yaklaşımıyla doğrudan bağlantılıdır (bir sonraki bölüm).

İpucu: "Yedek altyapı" fikrini yalnızca operasyonel devamlılık için değil; kanıt zinciri için de kullan. Bir değişiklik yapıldığında, değişikliğin etkisini ayrı bir zaman diliminde ölçmek rapor kalitesini yükseltir.

3.3. Doğrulama: "İddia-kanıt-karşı kanıt" diliyle çalışmak

Katmanlı altyapıda sık yapılan hata, "çalışıyor" hissini kanıt yerine koymaktır. İleri seviye doğrulama şu çerçevede ilerler:

İddia: "Redirector, Team Server'ı doğrudan görünür olmaktan koruyor."
Kanıt arayışı: Dış yüzeydeki servis parmak izleri, beklenen/istenen görünürlük, gereksiz açıkların olmadığını gösteren gözlemler.
Karşı kanıt arayışı: "Bir şey ters yapılandırılmış olabilir mi? Yanlış bir işaret/iz sızıyor mu? Farklı bir telemetri kaynağı bunu doğruluyor mu?"

Bu yaklaşım, Modül 17'deki raporlama standardına doğrudan taşınır: gözlem-yorum ayrımı netse, bulgu tartışılabilir ve denetlenebilirdir.

4) Altyapı otomasyonu: IaC zihniyeti ve tekrar üretilebilirlik

Manuel kurulumlar, insan hatasına açıktır; üstelik "yanan" bir parçayı hızlı değiştirmek gerektiğinde operasyonel yük artar. "Infrastructure as Code (IaC)" yaklaşımı, bu riski azaltan bir mühendislik refleksidir.

4.1. IaC neden OPSEC ile ilgilidir?

IaC'nin OPSEC'e katkısı "hız"dan çok standartlaştırmadır:

Her kurulumda aynı güvenlik önlemlerinin tutarlı uygulanması
Konfigürasyon sapmalarının azalması
Denetlenebilirlik: "ne değişti?" sorusuna daha net yanıt üretme

Dikkat: Otomasyon, kötü kararları da hızlı uygular. Bu yüzden IaC; RoE, deconfliction ve güvenlik freni kararlarıyla birlikte ele alınmadıkça "risk çarpanı"na dönüşebilir.

4.2. Erişim yönetimi ve sır yönetimi: operatör hatası en büyük risk

Altyapı erişiminde olgun yaklaşım; ayrı kimlikler, asgari yetki, oturum kayıtları, MFA gibi ek kontroller ve sır yönetimi disiplinleriyle ilerler. Burada kritik olan teknik detay değil, operasyon kalitesidir:

"Kim, hangi amaçla, hangi süreyle erişti?" sorusunun izlenebilir olması
Operatör yüzeyinin (konsol/erişim noktaları) risklerinin bilinçli yönetilmesi
Gereksiz yetkilerin ve gereksiz kalıcılığın azaltılması

4.3. Hosting / coğrafi / hukuki çerçeve: sadece teknik değil

Altyapı kararı; performansın ötesinde uyumluluk ve delil yönetimi konusudur:

Kayıtların nerede tutulduğu (log saklama, erişim yetkileri)
Üçüncü taraf riskleri (servis kesintileri, politika değişimleri)
RoE ile uyum ve gerektiğinde operasyonu durdurma mekanizması

5) OPSEC: görünmezlik değil, iz yönetimi ve minimum zarar disiplini

OPSEC çoğu zaman "saklanmak" gibi anlatılır; oysa ileri seviye OPSEC; izlerin bilinçli yönetimi, sınırların korunması ve kanıt üretiminin sağlıklı yapılması demektir.

5.1. Attribution (ilişkilendirilebilirlik) ve izolasyon: korelasyon riskini yönetmek

En ciddi OPSEC kazaları, teknik bir zafiyetten değil; ilişkilendirilebilirlikten doğar:

Aynı altyapının farklı müşterilerde/engagement'larda yeniden kullanılması, IOC korelasyonu riskini artırır.
Bir yerde "yanan" gösterge, başka bir yerde operasyonu başlamadan bitirebilir.
Bu nedenle izolasyon, "konfor" değil; güvenlik gereğidir.

Bu konu, Modül 1'deki yönetişim ve Modül 17'deki raporlama sorumluluğuyla birleşir: izolasyon kararları raporda "risk kaydı" ve "gerekçe" olarak izlenebilir olmalıdır.

5.2. Alan adı itibarı ve kategorizasyon: "uncategorized" neden sorun?

Kurumsal güvenlik kontrolleri çoğu zaman "bilinmeyen/kategorisiz" alanları daha riskli görür. Bu yüzden alan adı itibarı ve kategorizasyon, yalnızca "görünüm" değil; erişilebilirlik ve ölçüm güvenilirliği konusudur.

Örnek: Kurgusal bir senaryoda, example.net altında bir alt alan kullanıldığında kurum proxy'si "kategorisiz" etiketiyle trafiği kısıtlayabilir. Bu durumda rapor, "başarısızlık" diye kestirmeden yazmak yerine; kontrol politikasının ölçüme etkisini ve bu etkinin hangi telemetriyle doğrulandığını anlatır.

Proxy Category Impact - Example

$ opsec-check # Alan kategorisi ve proxy kararını doğrula
$ jq '.domain,.category,.policy_action' proxy_events/example-net.json
"node1.example.net"
"uncategorized"
"restricted"

$ opsec-check # Aynı zaman aralığında egress etkisini ölç
$ python traffic_diff.py --before 15m --after 15m --domain node1.example.net
blocked_requests=42
allowed_requests=3
confidence=medium

$ opsec-check # Rapor notu üret
$ echo "policy impact confirmed: category-based restriction affected channel reliability"
policy impact confirmed: category-based restriction affected channel reliability

Not: Kurumlar, alan adı itibarı/kategorisi için çeşitli kaynaklar kullanabilir (ör. VirusTotal, IBM X-Force, Symantec Site Review gibi). Bu tür kaynaklar "kanıt" değil; bağlam sinyali olarak ele alınmalı ve mümkünse kurum içi telemetriyle çapraz doğrulanmalıdır.

5.3. Zamanlama: kurum ritmine aykırı davranış çoğu zaman en güçlü sinyaldir

Bir kurumun çalışma saatleri ve operasyon ritmi, anomali üretiminde belirleyicidir. Aynı davranış mesai içinde "gürültüye karışırken", gecenin bir vakti "bıçak gibi keskin" görünebilir. Bu yüzden yöntem seçimi; hız/etki kadar zaman uyumu üzerinden de değerlendirilir.

6) Tespit gerçekliği: doğrulama döngüsü ve belirsizlik yönetimi

C2 kararları, ancak "gözlenebilir çıktılar" üretiyorsa değerlidir. Bu bölümde, Modül 12'ye giden köprüyü kuruyoruz: savunma ekipleri neyi, nereden görür?

6.1. Savunma C2'yi nerede görür?

Genellikle görünürlük üç katmanda toplanır:

Ağ: DNS, proxy, firewall, TLS inceleme, IDS/IPS
Uç nokta: süreç davranışı, bağlantı örüntüleri, imza/heuristic sinyaller
Kimlik: oturum açma örüntüleri, yetki değişimleri, koşullu erişim politikaları

Şifreli trafik bile "el sıkışma" ve parmak izi benzeri izler bırakabilir (ör. JA3 gibi TLS istemci parmak izleri). Burada önemli olan, bir terimi bilmekten çok şu ayrımı yapmaktır: "Varsayıyorum" mu diyorsun, yoksa "gözledim" mi diyorsun?

6.2. Hipotez-gözlem-karşı kanıt-confidence: olgun doğrulama dili

İleri seviye raporlama dili şu sırayı doğal biçimde taşır:

Hipotez: "Şu davranış şu loglarda şu tip sinyal üretir."
Gözlem: "Şu zaman aralığında şu sinyaller görüldü."
Karşı kanıt: "Bu sinyal normal trafikle de açıklanabilir mi? Alternatif açıklamalar test edildi mi?"
Confidence: "Kaç bağımsız kaynaktan destek var? Hangi veri gelirse fikrim değişir?"

Dikkat: "Alarm yoktu" tek başına başarı değildir. Alarm yokluğu; telemetri eksikliği, yanlış ölçüm tasarımı, tespit kuralı boşluğu veya yanlış varsayım gibi birçok anlama gelebilir. Bu nedenle "alarm yok" ifadesi ancak karşı kanıt arayışıyla güçlenir.

6.3. Metrikler: "derinlik" değil, "ölçüm kalitesi" takip edilir

Bu modülde metrikler, saldırı başarısını yüceltmek için değil; ölçüm kalitesini göstermek için kullanılır:

Tespit kapsaması: hangi katmanda kör nokta var?
Gürültü maliyeti: hangi davranış SOC/IT yükünü artırıyor?
Gecikme ve zaman pencereleri: korelasyon ne kadar sürede çalışıyor?
Operasyonel sınırlar: minimum zarar ilkesi nerede devreye girdi?

7) Savunmaya çevrilebilir çıktılar: C2 bulgusu iyileştirmeye nasıl dönüşür?

İleri seviye çıktı, "hangi aracı kullandık?" değil; "hangi kontrol hedefi güçlenmeli?" sorusuna yanıt verir. C2 ve altyapı bulguları genellikle şu iyileştirme başlıklarına bağlanır:

Egress kontrolü ve segmentasyon (nereden nereye çıkış olmalı?)
DNS/proxy görünürlüğü ve anomali kuralları (hangi ritimler, hangi eşikler?)
TLS görünürlüğü politikaları (kurumsal denge ve mahremiyet sınırlarıyla)
Uç nokta telemetri kalitesi ve davranış temelli tespit
Değişiklik yönetimi ve ayrı yönetim yüzeyi (kimlik/erişim katmanlarıyla uyumlu)

Bu bölüm, Modül 17'de "bulgu → öneri → öncelik → doğrulama planı" hattına dönüşür; Modül 12 ile ise "sinyal → tespit mantığı" köprüsünü kurar.

Terimler Sözlüğü

Terim	Açıklama
C2 (Command & Control)	Ele geçirilen/temas edilen uçlarla kontrol iletişimi; operasyonun kontrol düzlemi
Control Plane	“Kim, neyi, ne zaman, hangi yetkiyle yaptı?” bilgisini yöneten katman
Data Plane	Taşınan içerik/çıktı katmanı; kanıtlar ve iş sonuçları burada yer alır
Agent / Implant	Uç sistemde çalışan ve komutları alıp sonuçları ileten bileşen
Listener / Endpoint	Agent’ın bağlandığı iletişim ucu
Team Server	Operasyon yönetimi ve görevlemenin merkez bileşeni
Redirector / Relay	Trafiği araya alıp yönlendiren, ana varlıkları görünürlükten koruyan katman
Tiered Infrastructure	Katmanlı altyapı; riskin dağıtılması ve izolasyon mantığı
Beaconing Behavior	Düzenli/yarı düzenli iletişim ritminin ürettiği davranışsal iz
Jitter	Zamanlama aralıklarına rastgelelik ekleyerek düzenliliği azaltma yaklaşımı
Malleable Profile	Trafik görünüşünü belirli örüntülere benzetmeye yönelik profil yaklaşımı
Short-haul / Long-haul	Kısa menzil (hızlı/etkileşimli) ve uzun menzil (seyrek/süreklilik) kanal mantığı
Infrastructure as Code (IaC)	Altyapıyı manuel değil, kodla tanımlayıp standartlaştırma yaklaşımı
Burned Infrastructure	Tespit edilmiş/engellenmiş ve artık riskli hale gelmiş altyapı göstergeleri
OPSEC	Operasyon güvenliği; iz yönetimi, sınırların korunması, minimum zarar disiplini
Attribution	İlişkilendirilebilirlik/kimliklendirme riski; korelasyon yoluyla iz sürülme ihtimali
Domain Reputation	Alan adı itibarı; kurumsal kontrollerde risk sinyali olarak görülebilir
Deconfliction	Kurum içi ekiplerle çakışmayı önleme; durdurma/koordinasyon kuralları
Egress Control	Dışa doğru ağ çıkışını sınırlama/izleme politikaları
JA3	TLS istemci parmak izi yaklaşımı; şifreli trafikte davranışsal bağlam sinyali olabilir

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir engagement’ta amaç “SOC korelasyon kalitesini ölçmek” olarak tanımlanmış. C2 tasarımında en doğru öncelik hangisidir?

A) Maksimum gizlilik için görünür izleri tamamen ortadan kaldırmak

B) Ölçülebilir sinyaller üreten ve hipotez–gözlem–karşı kanıt döngüsüyle doğrulanabilir bir iletişim yaklaşımı seçmek

C) Gürültüyü artırıp SOC’u “stres testine” sokmak

D) Tüm patikaları tek bir merkezde birleştirip izleri karıştırmak

E) Log kaynaklarını dikkate almadan yalnızca performansa göre karar vermek

Doğru: B
Gerekçe: Ölçüm hedefi, doğrulanabilir sinyal ve kanıt disiplinini gerektirir. A ölçümü zayıflatabilir; C gereksiz operasyonel yük ve etik risk üretir; D izlenebilirliği bozar; E kanıtsız varsayımdır.

2) “Alarm yoktu, demek ki başarılıydık” ifadesi neden ileri seviye raporlama açısından zayıftır?

A) Alarm her zaman çıkar

B) Alarm yokluğu; telemetri eksikliği, yanlış ölçüm tasarımı veya tespit boşluğu gibi çoklu açıklamalara sahiptir

C) SOC her şeyi görür

D) Yalnızca ağ logları önemlidir

E) Alarm yokluğu kanıt yerine geçer

Doğru: B
Gerekçe: Alarm yokluğu tek başına kanıt değildir; karşı kanıt arayışı ve telemetri doğrulaması gerekir. Diğer şıklar genelleme veya yanlış önermedir.

3) Katmanlı (tiered) altyapı yaklaşımının en doğru risk–fayda özeti hangisidir?

A) Her zaman daha güvenlidir ve maliyeti yoktur

B) Ana varlıkların doğrudan görünürlüğünü azaltabilir; ancak yönetim karmaşıklığı ve hata riski artar

C) Sadece maliyet azaltmak için seçilir

D) Sadece raporu uzatır

E) Deconfliction ihtiyacını ortadan kaldırır

Doğru: B
Gerekçe: Katmanlı yapı trade-off içerir. A/E aşırı iddia; C/D amaç dışıdır.

4) Bir Blue Team analisti, “yüzeyde meşruya benzeyen” bir trafiği hangi yaklaşımla daha sağlıklı ayrıştırır?

A) Sadece başlık/format benzerliğine bakarak

B) Bağlam tutarlılığına bakarak: hedefin sahipliği, sertifika/alan adı uyumu ve kurum politikasına uygunluk gibi sabit sinyalleri kontrol ederek

C) Sadece paket boyutuna bakarak

D) Sadece günün saatine bakarak

E) Ayrıştıramaz; benzetme varsa imkânsızdır

Doğru: B
Gerekçe: Kozmetik yüzey taklit edilebilir; bağlam tutarlılığı ve doğrulanabilir sabit sinyaller ayrıştırmada daha güçlüdür. E “kesinlik” içerir ve gerçekçi değildir.

5) “Jitter” eklemenin en doğru trade-off tanımı hangisidir?

A) Gürültü artar, gecikme azalır

B) Düzenlilik azalır (tespit riski bazı senaryolarda düşebilir), ancak komut gecikmesi ve operasyonel kontrol maliyeti artabilir

C) Tespiti garanti eder

D) Sadece maliyet düşürür

E) Hiçbir etkisi yoktur

Doğru: B
Gerekçe: Jitter düzenlilik izini azaltırken gecikme/operasyonel kontrol maliyeti getirebilir. C/E gibi kesin ifadeler yanlıştır.

6) “Infrastructure as Code (IaC)” yaklaşımının OPSEC açısından en güçlü katkısı hangisidir?

A) Gizliliği otomatik garanti etmesi

B) Konfigürasyonları standartlaştırarak insan hatasını azaltması ve denetlenebilir “ne değişti?” izini güçlendirmesi

C) Tespit sistemlerini devre dışı bırakması

D) Telemetriyi ortadan kaldırması

E) Her zaman daha ucuz olması

Doğru: B
Gerekçe: IaC, standardizasyon ve hata azaltma ile OPSEC’i güçlendirir; gizlilik/tespit garantisi vermez.

7) “Aynı altyapıyı farklı müşterilerde tekrar kullanma” kararı neden özellikle risklidir?

A) Çünkü teknik olarak çalışmaz

B) Korelasyon/attribution riskini artırır; bir yerde yanan gösterge (IOC), başka bir yerde savunmanın operasyonu erken engellemesine yol açabilir

C) Çünkü rapor yazmayı zorlaştırır

D) Çünkü sadece maliyet artırır

E) Çünkü kimlik logları buna izin vermez

Doğru: B
Gerekçe: Altyapı tekrar kullanımı, ilişkilendirilebilirlik ve “kirlenme” riskini büyütür. Diğer seçenekler ya ikincil ya da hatalıdır.

8) Bir alan adının “kategorisiz/uncategorized” olması hangi nedenle ölçümü bozabilir?

A) DNS çalışmaz

B) Kurumsal proxy/güvenlik politikaları, kategorisiz alanları varsayılan olarak kısıtlayabilir; bu da erişilebilirliği ve ölçüm sürekliliğini etkiler

C) TLS çalışmaz

D) Sadece performans düşer

E) Hiçbir etkisi olmaz

Doğru: B
Gerekçe: Kurumsal kontroller kategori/itibar sinyallerine dayanabilir. “Hiçbir etkisi olmaz” gibi kesinlikler yanlıştır.

9) “Doğrulama” dilinde en olgun ifade hangisidir?

A) “Bence böyle, çünkü mantıklı.”

B) “Tek kaynaktan gördüm, kesin.”

C) “Hipotez kurdum, gözlemleri topladım, alternatif açıklamalar için karşı kanıt aradım; şu nedenle şu düzeyde eminim ve şu veri gelirse fikrim değişir.”

D) “Alarm yoktu, o yüzden oldu.”

E) “Araç öyle dedi.”

Doğru: C
Gerekçe: Olgun doğrulama; hipotez–gözlem–karşı kanıt–confidence zincirini kurar. Diğerleri kanıt standardını karşılamaz.

10) C2/altyapı bulgularını savunmaya çevirmek için en iyi raporlama çerçevesi hangisidir?

A) Kullanılan araçların listesi

B) Sadece risk puanı

C) Gözlem–yorum ayrımı + etkilenen kontrol hedefi (egress, DNS/proxy görünürlüğü, uç nokta telemetri) + ölçülebilir iyileştirme önerileri

D) Sadece ekran görüntüleri

E) “Ne yaptık” anlatısı

Doğru: C
Gerekçe: Savunma değeri, bulguyu kontrol hedeflerine ve ölçülebilir önerilere bağlamaktır. A/B/D/E tek başına yetersizdir.

Bu Modülde Kazanılan Yetkinlikler

C2'yi "iletişim" değil, kontrol düzlemi olarak modelleme ve bileşenlerin rol/risklerini doğru konumlandırma
Short-haul/long-haul, jitter ve trafik profili gibi kararların trade-off mantığını kurma: hız-gürültü-ölçüm kalitesi dengesi
Katmanlı altyapı ve "burn & build" zihniyetiyle dayanıklılık ve izolasyon düşünme
OPSEC'i görünmezlik değil; iz yönetimi, deconfliction, minimum zarar ve ilişkilendirilebilirlik disiplini olarak ele alma
Doğrulama ve kanıt zinciri dili: hipotez-gözlem-karşı kanıt-confidence yaklaşımını rapora taşımaya hazır hale gelme

MODÜL 12 — EDR/SOC Gerçekliği & Güvenli Evasion Çerçevesi

Modül Teması

Tespit Telemetrisi

ETW, AMSI, EDR sensör mimarisi.

SOC İş Akışı

Alarm, triage, hunt ve eskalasyon.

Etik Evasion

Tespit boşluğunu rapora dönüştürmek.

İleri seviye bir Red Team çalışmasında "başarı", sessiz kalmak ya da hiç alarm üretmemek değildir; kurumun gerçekte neyi gördüğünü, neyi kaçırdığını ve bunun nedenini kanıt standardında ortaya koyabilmektir. Modern savunma mimarileri (EDR/XDR, SIEM, SOC süreçleri) birer "sensör ağı" gibi davranır: bazı şeyleri çok iyi yakalar, bazı şeylerde ise gecikme, kapsam dışı kalma veya bağlam eksikliği nedeniyle kör noktalar üretir. Bu modül, "evasion"ı bir kaçış tarifi olarak değil; görünürlük ve tespit boşluklarını güvenli sınırlar içinde doğrulama, ölçülebilir hale getirme ve Purple Team çıktısına dönüştürme disiplini olarak ele alır.

Bu Modülde Hedeflenen Kazanımlar

EDR/SIEM telemetrisini süreç-ağ-kimlik-dosya ekseninde okuyup "hangi sinyal nerede görünür?" sorusunu modellemek
İmza, davranış ve anomali tabanlı tespit mantıklarını; güçlü/zayıf yanlarını ve noise/FP maliyetiyle birlikte değerlendirmek
"Alarm yok" gibi yüzeysel çıkarımlar yerine hipotez-gözlem-karşı kanıt döngüsüyle doğrulama kası geliştirmek
"Güvenli evasion"ı; RoE, minimum zarar, deconfliction ve ölçülebilirlik sınırlarında tespit haritalama olarak konumlamak
Log/artefakt yönetimini izlenebilirlik, zaman uyumu ve confidence diliyle denetlenebilir bulgu formatına çevirmek
Tespit boşluklarını Purple Team aksiyonlarına dönüştürmek: kontrol boşluğu analizi → backlog → önceliklendirme

1) Telemetriyi "gerçek dünya" gibi okumak: süreç / ağ / kimlik / dosya

EDR ve SIEM tarafında en kritik refleks şudur: "Bu iddiam hangi telemetriyle doğrulanır?" Aynı davranış bir katmanda görünmezken diğerinde iz bırakabilir; ya da log üretilir ama retention kısa olduğu için geriye dönük kanıt üretilemez. İleri seviye ölçüm, "sanırım görünür" varsayımını bırakır; görünürlüğü kanıtlar.

1.1. Süreç telemetrisi: davranışın mekanik izi ve süreç ağacı

Süreç telemetrisi; bir uç noktada hangi işlemlerin hangi bağlamda çalıştığına (ebeveyn-çocuk ilişkileri, bağlamsal alanlar, imza/itibar bilgileri gibi) dair izlerdir. Burada değer, tek bir olayın kendisi değil; olasılık dışı ilişki örüntüleridir.

Örnek: Bir ofis uygulamasının başlattığı alt süreç zinciri kısa sürede ağ bağlantıları açıyorsa, tek bir "bağlantı var" kaydı yerine "hangi süreç ağacı bunu doğurdu?" sorusu çok daha güçlü bir kanıt üretir. Bu tür ilişkiler, savunma tarafında hem tespit kuralı tasarımına hem de triage hızına doğrudan katkı verir.

1.2. Ağ telemetrisi: egress gerçeği, şifreleme ve kaynak çeşitliliği

Ağ tarafı; DNS, proxy, güvenlik duvarı, IDS/IPS, akış (flow) kayıtları ve bazı ortamlarda TLS inceleme gibi kaynaklarla şekillenir. Kritik nüans: ağ kaynağı çoktur ama her kaynak aynı doğrulukta ve aynı bağlamda değildir. Uç nokta ajanları çoğu zaman bağlantının "meta verisini" (hedef, port, hacim gibi) daha iyi görür; içeriğin görünürlüğü ise kurumun ağ mimarisine (proxy/TLS inceleme vb.) bağlıdır.

Örnek: Uydurma bir senaryoda 203.0.113.0/24 bloğunda barındırılan example.net alt alanına düzenli istekler gözleniyor. "Düzenli istek" iddiası, tek bir kaynaktan değil; mümkünse DNS + proxy/egress + uç nokta ağ olayı gibi çapraz doğrulama ile güçlenir. Tek kaynağa yaslanmak, yanlış korelasyon ve yanlış güven düzeyi üretir.

1.3. Kimlik telemetrisi: "kim, ne zaman, hangi koşulla?"

Kimlik telemetrisi; oturum açma kalıpları, token/oturum yaşam döngüsü, koşullu erişim kararları, yetki değişimleri ve servis hesap davranışları gibi izlerdir. İleri seviye ölçümde kimlik sinyali, "şüpheli bir hareket"i iş bağlamına oturtur: rutin bakım mı, rol gereği mi, yoksa sıra dışı bir yükseliş mi?

Örnek: Kısa sürede art arda başarısız oturum açma tek başına "saldırı" demek değildir. Aynı zaman penceresinde cihaz risk sinyali, konum tutarsızlığı, beklenmedik yetki değişimi veya sıra dışı kaynak erişimi var mı sorusu karşı kanıt arayışının parçasıdır.

1.4. Dosya / konfig / değişiklik telemetrisi: "ne değişti"yi kanıtlamak

Dosya, kayıt/konfig ve sistem değişikliği telemetrisi; "ne değişti?" sorusunun kanıtıdır. İleri seviyede amaç "ne kadar iz bıraktım" değil; minimum değişiklikle ölçülebilir sinyal üretmek ve bunu denetlenebilir şekilde paketlemektir. Bu yaklaşım, hem etik-OPSEC sınırlarını korur hem de raporun güvenilirliğini yükseltir.

1.5. Telemetri olgunluğu: kapsama, doğruluk, gecikme, retention

Bir kurum "EDR var" dediğinde bunun "her şeyi görüyor" anlamına gelmediğini varsaymak gerekir. Ölçümün omurgası dört kalite kapısıdır:

Kapsama: Hangi varlıklar izleniyor (uç nokta/sunucu/özel segment/uzak kullanıcı)?
Doğruluk: Kayıtlar bağlam içeriyor mu, yoksa yalnızca özet mi?
Gecikme: Toplama→merkezileştirme→korelasyon hattında gecikme var mı?
Retention: Loglar ne kadar saklanıyor; geriye dönük kanıt üretilebilir mi?

Dikkat: "Alarm yok" gözlemi, tek başına "tespit edilemedik" anlamına gelmez. Alarm yokluğu; telemetri yokluğu, gecikme, yanlış korelasyon kuralı, kapsam dışı varlık, erişim yetkisi kısıtı veya senaryonun yanlış kurgulanması gibi birden fazla açıklama taşır. İleri seviye rapor, bu alternatifleri tek tek eleyerek ilerler.

İpucu: Telemetriyi bir bina güvenlik kamerası gibi düşün. Kamera sayısı fazla olabilir; ama kör nokta varsa "kamera var" cümlesi güvence değildir. Kör noktayı kanıtlamak için "kamera çalışıyor mu, açısı doğru mu, kayıtlar saklanıyor mu, görüntüye erişim var mı?" sorularını sistematik sor.

2) Tespit mantığı: imza, davranış, anomali ve "puanlama" gerçeği

"Tespit hangisiyle daha iyi yapılır?" sorusu bağlamdan bağımsız cevaplanamaz. Doğru soru şudur: "Hangi hedef için, hangi maliyetle, hangi yan etkiyi kabul ederek?" Çünkü tespit mühendisliği bir anlamda bütçe yönetimidir: FP maliyeti SOC'u boğarsa, gerçek olaylar kaçırılabilir.

2.1. İmza tabanlı tespit: kesinlik yüksek, kapsam sınırlı

İmza; bilinen bir örüntüyü yakalar (IOC'ler, bilinen hash/alan adı kalıpları, bilinen sabit parmak izleri vb.). Gücü, düşük belirsizlikle karar verebilmesidir; zayıf yanı, yenilik ve varyasyon karşısında kırılgan kalabilmesidir. İleri seviye ölçümde imza alarmları, "yakalandı/yakalanmadı" tartışmasından çok, kapsam ve sürdürülebilirlik tartışması üretir.

2.2. Davranış tabanlı tespit: bağlamla güçlenir, FP riski taşır

Davranış tespiti tek bir belirteç yerine olaylar arası ilişki kurar (süreç zinciri + ağ olayı + kimlik sinyali gibi). Doğru tasarlanırsa dayanıklıdır; ancak bağlam zayıfsa FP artar ve SOC'un operasyonel yükü büyür. Bu yüzden ileri seviye yaklaşım, "çok kural yazalım" değil; doğru bağlamı ekleyelim yaklaşımıdır.

2.3. Anomali / UEBA: "alışılmadık" sinyali ve açıklanabilirlik sınavı

Anomali yaklaşımları normdan sapmaları arar. Buradaki kalite kapısı "buldu" demek değil; açıklanabilirliktir. Eğer anomali alarmı, analistin doğrulayabileceği kanıtlara bağlanamıyorsa üretim ortamında gürültüye dönüşür.

Örnek: "Olağandışı saat/konum" sinyali tek başına anlamlı değildir. Vardiya, bakım penceresi, rol, cihaz durumu ve aynı pencerede eşlik eden başka sinyaller var mı gibi sorular cevaplanmadan "kesin" dil kullanılmaz.

2.4. Çoklu sinyal ve eşik mantığı: tek olay değil, birikimli risk

Modern sistemlerde "tek bir şüpheli hareket" her zaman alarm üretmez; çoğu ortamda puanlama/threshold benzeri bir yaklaşım vardır: imza + davranış + anomali sinyalleri birlikte değerlendirildiğinde eşik aşılınca alarm üretilir. Bu gerçek, iki önemli sonuç doğurur:

Ölçüm tasarımı "tek sinyal"e değil, sinyal kombinasyonlarına bakmalıdır.
Sonuç analizi "alarm yok" durumunda bile görünürlük var mı, sinyal birikti mi, eşik nerede kaldı sorularını sormalıdır.

İpucu: Her senaryo adımı için küçük bir "sinyal matrisi" çıkar: (i) beklenen telemetri kaynakları, (ii) beklenen korelasyon ilişkileri, (iii) kabul edilebilir gürültü seviyesi, (iv) durdurma koşulları. Bu matris, Modül 11'deki OPSEC disiplinini tespit ölçümüne taşır.

3) "Güvenli evasion" çerçevesi: kaçış değil, tespit haritalama

Bu modül "evasion" kelimesini sahadaki dili yakalamak için kullanır; fakat çerçeve nettir: amaç EDR'ı devre dışı bırakmak veya "bypass tarifi" vermek değildir. Amaç, savunmanın görünürlük boşluklarını (telemetry gaps) ve tespit boşluklarını (detection gaps) kanıt standardında ortaya koymaktır.

3.1. Evasion'ı yeniden tanımlamak: "görünmez olmak" yerine "neye, nasıl yakalanırım?"

Güvenli çerçevede başarı kriteri, alarmın çıkıp çıkmaması değildir. Asıl başarı şu soruların cevaplanabilmesidir:

Hangi telemetri gerçekten vardı, hangisi yoktu?
Alarm çıktıysa hangi sinyale dayandı; çıkmadıysa hangi alternatif açıklamalar mümkün?
Tespit gecikmesi nedir; olay-alarm zaman uyumu tutarlı mı?
Bu değerlendirme kuruma hangi ölçülebilir iyileştirmeyi öneriyor?

Bu yaklaşım Red Team'i "yenmek" oyunundan çıkarıp, kurumu "güçlendirmek" hedefiyle hizalar.

3.2. RoE, minimum zarar ve deconfliction: "yapılabilir" ile "yapılması doğru"yu ayırmak

Modül 1'deki RoE ve Modül 11'deki OPSEC çizgisi burada ölçüm etiğine dönüşür. Güvenli çerçeve, aşağıdaki sınırları doğal kabul eder:

Üretim ortamında gereksiz risk doğuran denemelerden kaçınma
İş sürekliliğini etkileyebilecek davranışlarda net durdurma eşikleri (kill-switch mantığı)
SOC/IR ekipleriyle çakışmayı büyütmeyecek koordinasyon (deconfliction)
Veri minimizasyonu: ölçüm için gereken kadar veri, fazlası değil

Dikkat: "Bir şey daha deneyelim" refleksi ileri seviye değildir. İleri seviye, denemeyi önce ölçülebilir hipoteze çevirir; hipotez ölçülemiyorsa deneme yapılmaz.

3.3. Mimari sınırlar: sensörler nereden veri toplar, nerede zorlanır?

EDR/XDR ürünleri mimari olarak farklılaşır: bazıları kullanıcı modu sensörlerine daha çok yaslanır, bazıları çekirdek seviyesinde bileşenleri daha yoğun kullanır; çoğu karma bir yaklaşım izler. Bu nedenle "EDR şunu görür/görmez" gibi kesin cümleler yerine, şu doğrulama mantığı aranır:

Toplanan sinyal, işletim sisteminin hangi mekanizmalarına dayanıyor?
Yük altında olay düşürme (event dropping) yaşanıyor mu, gecikme artıyor mu?
Aynı davranış farklı telemetry kaynaklarında tutarlı mı?

Bu bölümde sık duyulan teknik kavramlar (ör. ETW, hook'lar, kernel callback benzeri veri toplama yöntemleri) "uygula şunu" düzeyinde değil, görünürlük analizi düzeyinde ele alınmalıdır: savunma, veri toplama katmanlarını çeşitlendirerek kör noktaları azaltır; ölçüm ise bu çeşitliliğin gerçekten çalışıp çalışmadığını doğrular.

3.4. Doğrulama döngüsü: hipotez → gözlem → karşı kanıt → confidence

Güvenli ölçüm, raporlamada en çok değer üreten kası geliştirir: doğrulama.

Hipotez: "Bu davranış süreç + ağ telemetrisi ilişkisi üretecek."
Gözlem: "Şu zaman aralığında, şu varlık sınıfında bu ilişki görüldü/görülmedi."
Karşı kanıt: "Benzer ilişki normal süreçlerde de oluşuyor mu? Bakım/otomasyon var mı? Telemetri akışı kesilmiş olabilir mi?"
Confidence: "Tek kaynağa mı yaslandım, çapraz doğrulama var mı? Hangi veri gelirse fikrim değişir?"

Örnek: Uydurma bir kurumda anomali motoru "olağandışı etkinlik" alarmı üretiyor. Bu alarmı "kesin saldırı" diye yazmak yerine; vardiya/bakım penceresi/rol bağlamı gibi karşı kanıtlar test edilmeden confidence yüksek yazılmaz. Bu disiplin, raporu "yorum"dan arındırıp "denetlenebilir bulgu"ya yaklaştırır.

Hypothesis Validation Loop - Example

PS> Detection-Lab # Alarmı başlangıç hipotezi olarak kaydet
PS> .\validate-alert.ps1 -AlertId ALRT-2026-4421
hypothesis="unusual_activity_may_indicate_compromise"
initial_confidence=low

PS> Detection-Lab # Karşı kanıt: vardiya, bakım penceresi, rol
PS> .\collect-counterevidence.ps1 -Window "2026-04-28T18:00:00Z/2026-04-28T19:00:00Z"
maintenance_window=True
oncall_role=True
device_risk=low

PS> Detection-Lab # Güncellenmiş karar dili
PS> .\update-confidence.ps1 -AlertId ALRT-2026-4421
revised_assessment="suspicious but explainable by maintenance context"
confidence=medium-low
next_data_needed="independent endpoint anomaly outside maintenance window"

4) Görünürlük-tespit ayrımı ve kanıt standardı: log/artefakt yönetimi

Tespit perspektifi raporlama kalitesiyle birleşmediğinde "iyi hikâye" olur ama "denetlenebilir bulgu" olmaz. Bu başlık Modül 17'ye giden hattın temelidir: kanıt zinciri, izlenebilirlik, tekrar üretilebilirlik ve güven düzeyi.

4.1. Görünürlük (visibility) ≠ tespit (detection)

Görünürlük: Ham log/sinyal oluştu mu ve toplanabildi mi?
Tespit: Bu sinyal üzerine kural/analitik çalıştı mı, alarm üretildi mi, doğru sınıflandırıldı mı?

Örnek: Bir olayın Windows güvenlik günlüğünde süreç oluşturma kaydı bulunabilir; aynı olay SIEM'de ham log olarak görülebilir; fakat kural yoksa veya eşik/bağlam zayıfsa alarm oluşmayabilir. Bu durumda "görünürlük var, tespit yok" şeklinde net ayrım yapılır.

4.2. Kaynak-iddia-kanıt ayrımı: aynı cümlede karıştırmamak

Kaynak: EDR olayı, SIEM ham logu, kimlik sağlayıcı kaydı, proxy kaydı, Sysmon gibi uç nokta logları vb.
İddia: "Bu davranış şu katmanda görünür olmalıydı / alarm üretmeliydi."
Kanıt: Kaynağın iddiayı destekleyen, zaman uyumlu ve doğrulanabilir kısmı.

Kanıt zayıfsa confidence düşer; bu dürüstçe yazılır. "Kesin yakalanmadı" demek yerine "mevcut erişim/retention doğrulanamadığı için orta güven düzeyi" demek, daha yayınlanabilir ve daha doğrudur.

4.3 Zaman uyumu ve korelasyon: "aynı olay"ı yanlış bağlamamak

EDR→toplama→SIEM→korelasyon→alarm zincirinde gecikmeler ve saat senkronu sorunları olabilir. Kanıt zinciri, halkaları görünür kılar: olay zamanı, log zamanı, SIEM'e düşüş zamanı, kural çalışması ve alarm açılışı ayrı ayrı değerlendirilir. Böylece rapor "alarm geç geldi" gibi muğlak cümlelerden kurtulur.

4.4 "Kör nokta" ile "kural boşluğu"nu ayırmak

Kontrol boşluğu analizi yaparken iki farklı durum sık karışır:

Telemetri boşluğu: Log yok; sensör yok/kapalı/kapsam dışı/retention yetersiz.
Kural/analitik boşluğu: Log var; ama korelasyon yok, eşikler/bağlam zayıf, triage yanlış sınıflandırmış.

Bu ayrım, Purple Team oturumunda "ne düzeltmeliyiz?" sorusunun cevabını doğrudan belirler.

4.5. Çalışma izleri (artifacts) ve "yakalanma fırsatı"nı tasarlamak

İleri seviye ölçümde hedef, sistemde gereksiz iz bırakmak değildir; fakat hiçbir iz bırakmamak da denetlenebilirliği düşürür. Bu yüzden çalışma, RoE ve minimum zarar ilkesiyle uyumlu şekilde, savunmaya ölçülebilir yakalanma fırsatları sunacak kontrollü senaryoları tercih eder: amaç "yakalanmamak" değil, savunmanın hangi koşulda yakaladığını ve nerede kaçırdığını anlamaktır.

İpucu: Karmaşık zincirler yerine, mümkün olduğunda küçük ve izole "kontrollü doğrulama adımları" tasarla. Böylece hangi adımın görünür, hangisinin görünmez olduğu daha net ayrışır ve Purple Team iyileştirmesi hızlanır.

5) Red Team'den Purple Team'e: tespit boşluğunu aksiyona çevirmek

"Evasion" bir başarı hikâyesi değil, bir iyileştirme girdisi olmalıdır. Bu yüzden her bulgu, Purple Team backlog'una düşecek şekilde paketlenir:

Telemetri boşluğu: izlenmeyen varlık sınıfı / kapalı log kaynağı / retention yetersizliği
Kural boşluğu: sinyal var ama korelasyon yok; eşikler/bağlam eksik
Kalite boşluğu: FP çok yüksek; analist yükü artıyor; sınıflandırma net değil
Süreç boşluğu: triage akışı yavaş; sahiplik belirsiz; erişim/rollendirme sorunlu

Bu yaklaşım, "EDR'yi yendik" gibi kısa ömürlü bir anlatıyı; "kontrol şu kabul kriteriyle güçlendirilmeli" gibi sürdürülebilir bir çıktıya dönüştürür. Burada MITRE gibi taksonomilerin dili yardımcı olabilir: teknikleri adlandırmak değil, savunma kapsamını haritalamak ve "hangi kontrol hangi teknik sınıfını ne kadar kapsıyor?" sorusunu somutlaştırmak.

Terimler Sözlüğü

Terim	Açıklama
EDR	Uç nokta davranışlarını izleyip tespit/yanıt sağlayan güvenlik yeteneği
XDR	Uç nokta + ağ + kimlik gibi farklı katmanlardan sinyal toplayıp birleştiren genişletilmiş tespit/yanıt yaklaşımı
SIEM	Farklı log kaynaklarını toplayıp korelasyon ve alarm üretmeye yarayan platform yaklaşımı
SOC	Güvenlik izleme, triage ve müdahale süreçlerini yürüten operasyon birimi
Telemetry	Sistemlerden toplanan iz/log/sinyal verisi (uç nokta, ağ, kimlik vb.)
Detection Engineering	Tespit kuralı/korelasyon tasarlama, test etme ve iyileştirme disiplini
Correlation	Birden fazla sinyali ilişkilendirerek anlamlı alarm/olay üretme
Signature	Bilinen örüntüye dayalı imza tabanlı tespit yaklaşımı
Behavioral Detection	Bağlamsal davranış ilişkilerine dayalı tespit yaklaşımı
UEBA	Kullanıcı/varlık davranış analizi; anomali temelli yaklaşımlar ailesi
False Positive (FP)	Yanlış pozitif: gerçek olmayan alarm/olay
False Negative (FN)	Yanlış negatif: gerçekleşen olayın tespit edilememesi
Retention	Logların saklanma süresi
Deconfliction	İzinli çalışmada IR/SOC ile çakışmayı yönetme ve güvenli koordinasyon
Kill-switch	Beklenmeyen etki/riskte çalışmayı durdurma prensibi/mekanizması
Confidence	Bulgudaki eminlik düzeyi; kanıt sayısı/kalitesi ve karşı kanıt arayışıyla gerekçelendirilir
Visibility vs Detection	“Log var mı?” ile “alarm var mı?” ayrımı
Telemetry Gap	Veri toplama/görünürlük boşluğu
Detection Gap	Log/sinyal varken kural/analitik/süreç nedeniyle tespit üretilememesi
Threshold/Scoring	Çoklu sinyallerin eşik/puanlama mantığıyla bir arada değerlendirilmesi
IoC / IoA	Statik uzlaşma göstergeleri / davranışsal saldırı göstergeleri (kanıt türleri)
ETW	Windows üzerinde olay/iz verisi üretmeye yarayan yerleşik izleme mekanizması (telemetri kaynaklarından biri)

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir raporda “tespit edilmedi” iddiasını en güçlü hale getiren yaklaşım hangisidir?

A) “Alarm yoktu” ifadesini tek başına kanıt saymak

B) Tek bir ekrandan alınmış kısa görüntüyle yetinmek

C) Telemetri envanteri + retention doğrulaması + çapraz kaynak korelasyonu ile alternatif açıklamaları eleyip confidence düzeyi belirtmek

D) “SOC zayıf” gibi genelleyici yorum yazmak

E) Sadece risk puanı verip teknik kanıtı eklememek

Doğru: C
Kısa gerekçe: C, kaynak–iddia–kanıt ayrımını kurar ve “alarm yok”un alternatif açıklamalarını test eder. A/B/D/E denetlenebilirliği zayıflatır.

2) “Görünürlük var ama tespit yok” ifadesi aşağıdakilerden hangisini en iyi anlatır?

A) Log hiç oluşmadı ve hiçbir yerde yok

B) Log oluştu/toplandı; ancak korelasyon kuralı yok, eşikler/bağlam zayıf veya süreçte sınıflandırma hatası var

C) EDR mutlaka devre dışı bırakılmıştır

D) Bu durum her zaman yanlış pozitiftir

E) Bu durum her zaman başarı göstergesidir

Doğru: B
Kısa gerekçe: B, visibility–detection ayrımını doğru kurar. A telemetri boşluğudur; C/D/E genelleyici ve kanıtsızdır.

3) İmza tabanlı tespitin (signature) en doğru sınır ifadesi hangisidir?

A) Her zaman davranış tespitinden daha dayanıklıdır

B) Yenilik ve varyasyon karşısında kırılgan olabilir; bilinen örüntülerle sınırlıdır

C) Sadece kimlik katmanında çalışır

D) FP üretmez

E) Korelasyona ihtiyaç duymazsa her zaman yeterlidir

Doğru: B
Kısa gerekçe: B, imzanın güçlü (kesinlik) ve zayıf (kapsam/yenilik) yönlerini doğru dengeler. A/C/D/E aşırı genellemedir.

4) Davranış tabanlı tespitlerde FP maliyetini düşürmenin en sağlam yolu hangisidir?

A) Kuralları tamamen kapatmak

B) Eşikleri rastgele yükseltmek

C) Bağlam eklemek: süreç ağacı + varlık sınıfı + kimlik sinyali + zaman penceresi gibi korelasyonu güçlendirmek

D) Sadece imzaya dönmek

E) FP’leri rapora yazmamak

Doğru: C
Kısa gerekçe: C, tespit mantığını “daha az bağlam” yerine “daha iyi bağlam”la güçlendirir. A/B/D kısa vadeli ve kırılgan; E denetlenebilirliği bozar.

5) Anomali/UEBA alarmlarında “açıklanabilirlik” neden kritik bir kalite kapısıdır?

A) Çünkü anomali alarmları her zaman doğrudur

B) Çünkü açıklanamayan alarm triage süresini uzatır, gürültüyü artırır ve gerçek olayları gölgeleyebilir

C) Çünkü anomali yalnızca ağ verisiyle çalışır

D) Çünkü açıklanabilirlik yalnızca yönetici özetinde önemlidir

E) Çünkü açıklanabilirlik teknik bir konu değildir

Doğru: B
Kısa gerekçe: B, SOC operasyon yükünü ve karar kalitesini doğrudan bağlar. A/C/D/E yanlış veya eksik çerçevedir.

6) “Güvenli evasion” çerçevesi bu modül bağlamında en doğru nasıl anlaşılmalıdır?

A) Tespiti atlatmak için uygulanabilir taktikler öğretmek

B) Tespit sistemini devre dışı bırakmaya çalışmak

C) RoE ve minimum zarar sınırlarında, tespit iddialarını ölçülebilir hipotezlerle test edip kontrol boşluğu üretmek

D) Alarm çıkmamasını tek başarı metriği yapmak

E) Sadece altyapıyı değiştirmeye odaklanmak

Doğru: C
Kısa gerekçe: C, “kaçış” değil “ölçüm ve iyileştirme” üretir. A/B güvenlik sınırlarını aşar; D ölçümü anlamsızlaştırır; E dar bir bakıştır.

7) “Alarm yok” gözlemiyle karşılaşıldığında en doğru ilk muhakeme sırası hangisidir?

A) Alarm yok → kesin başarı

B) Alarm yok → SOC yetersiz

C) Alarm yok → telemetri var mı? (kapsam/retention/erişim) → gecikme var mı? → kural/bağlam var mı? → normal davranış karşı kanıtı var mı?

D) Alarm yok → sadece ağ loglarına bakmak yeterli

E) Alarm yok → risk puanını otomatik düşürmek

Doğru: C
Kısa gerekçe: C, alternatif açıklamaları sistematik eleyerek doğrular. A/B/D/E ya erken kesinlik üretir ya da eksik veriyle karar verir.

8) Bir ortamda telemetri “yük altında olay düşürme” eğilimi gösteriyorsa, rapor dili nasıl kurulmalıdır?

A) “Sistem bizi yakalayamadı” gibi kesin cümleler

B) “Her şey çalışıyor” diyerek geçmek

C) “Belirli yük koşullarında telemetri sürekliliği/kalitesi etkilenebilir; bu nedenle tespit sonucu şu güven düzeyindedir” gibi koşula bağlı ve kanıt temelli ifade

D) “Bu önemsiz” demek

E) “Mutlaka saldırı var” demek

Doğru: C
Kısa gerekçe: C, belirsizliği dürüstçe yönetir ve confidence’ı koşula bağlar. A/B/D/E kanıtsız kesinlik üretir.

9) “Exclusions/istisnalar” (ör. performans gerekçeli izleme dışı bırakmalar) neden kontrol boşluğu analizi için önemlidir?

A) Çünkü istisnalar her zaman güvenlidir

B) Çünkü istisnalar, kapsama ve görünürlükte yapısal boşluk üretebilir; bu boşluklar tespit performansını yanıltabilir

C) Çünkü istisnalar yalnızca Linux’ta bulunur

D) Çünkü istisnalar sadece ağ trafiğini etkiler

E) Çünkü istisnalar yalnızca rapor formatıyla ilgilidir

Doğru: B
Kısa gerekçe: B, istisnaları telemetri olgunluğu/kapsama problemi olarak doğru konumlar. A/C/D/E yanlış genellemedir.

10) “Kontrol boşluğu” önerisinin Purple Team backlog’una eylemlenebilir biçimde girmesi için en doğru paketleme hangisidir?

A) “EDR’yi değiştirin” gibi genel öneri

B) “Daha çok log toplayın” gibi ölçümsüz öneri

C) Boşluk türü (telemetri/kural/kalite/süreç) + ölçülebilir kabul kriteri + öncelik gerekçesi (risk ve operasyonel maliyet)

D) Sadece CVSS yazmak

E) “Biz olsak yakalardık” demek

Doğru: C
Kısa gerekçe: C, doğrudan aksiyona dönüşür ve ölçülebilirlik sağlar. A/B/D/E ya muğlak ya da öznel kalır.

Bu Modülde Kazanılan Yetkinlikler

EDR/SIEM görünürlüğünü "var/yok" yerine kapsama-doğruluk-gecikme-retention kalite kapılarıyla değerlendirebilme
İmza/davranış/anomali tespitlerinin maliyetlerini (FP/FN, operasyonel yük) gerçekçi biçimde tartabilme
"Alarm yok" durumunda hipotez-gözlem-karşı kanıt döngüsüyle kanıt standardında sonuca gidebilme
"Güvenli evasion"ı kaçış tarifi olmadan, RoE ve minimum zarar sınırlarında tespit haritalama olarak uygulayabilme
Visibility-detection ayrımını koruyarak kaynak-iddia-kanıt zinciri kurabilme ve confidence dilini doğru yönetebilme
Tespit boşluklarını Purple Team backlog'una dönüştürecek şekilde ölçülebilir ve önceliklendirilebilir hale getirebilme

MODÜL 13 — Exfiltration ve Etki Simülasyonu

Modül Teması

Exfil Kanalları

DNS, HTTPS, cloud storage ve kovert kanallar.

Hız & Stealth

Throttling, parçalama ve trafik karıştırma.

Etki Simülasyonu

İş etkisi, regulator ve iletişim senaryoları.

Saldırı zincirinin son halkası çoğu zaman "teknik sızma"dan "iş riski"ne geçiş anıdır: erişim elde etmek tek başına anlamlı değildir; hangi veri sınıfına hangi koşullarda erişilebildiğini, bunun nerede görünür / nerede görünmez kaldığını ve kurumun bu riski nasıl azaltıp doğrulayabileceğini kanıt standardında gösterebildiğinde operasyon değer üretir. Bu modül, exfiltration ve etki (impact) konularını "hasar verme" perspektifinden değil, güvenli doğrulama + denetlenebilir kanıt + iyileştirme hattı perspektifinden ele alır. Modül 2'deki "crown jewels" hedeflemesiyle çerçeve kurar; Modül 12'deki telemetri/tespit gerçekliğine dayanır; Modül 17'deki raporlama ve Purple Team çıktısına bağlanır.

Bu Modülde Hedeflenen Kazanımlar

Exfiltration'ı "veriyi taşımak" değil, risk modeli ve ölçüm tasarımı olarak kurmak: veri sınıfı → hazırlama (staging) → kanal sınıfları → görünürlük/engelleme olasılığı.
DLP'yi bir ürün/kural listesi gibi değil, organizasyonel veri akışları ve kontrol noktaları üzerinden okuyup kapsama boşluklarını görünür kılmak.
Etki simülasyonunu gerçek ihlal/kesinti yaratmadan, benign (zararsız) ama ikna edici kanıtlarla iş diline çevrilebilir hale getirmek.
"Gördüm" ile "kanıtladım" arasındaki farkı korumak: kaynak-iddia-kanıt ayrımı, karşı kanıt arayışı ve confidence (eminlik) dili.
Yöntem seçiminde etik/OPSEC sınırı, operasyonel yük, gürültü (noise) ve yanlış alarm maliyetini birlikte tartmak; minimum zarar ilkesini somutlaştırmak.
Güvenli kapanışı (cleanup, erişim kaldırma, veri imhası, değişiklik günlüğü) denetlenebilir ve tartışmasız teslim edebilmek.

1) Exfiltration'ı doğru problem olarak tanımlamak

Exfiltration, "kopyaladım ve çıktı" cümlesiyle biten bir eylem değildir. İleri seviyede asıl soru şudur:

Hangi veri sınıfına, hangi yol üzerinden, hangi görünürlük ve engelleme olasılığıyla erişilebildi; bunu neyle kanıtlıyoruz?

Bu soru seni otomatik olarak üç şeye zorlar: (i) veri sınıfı, (ii) hazırlama (staging) ve hareket, (iii) kanal sınıfları ve kontrol yüzeyi. Böylece değerlendirme "heyecanlı bir aksiyon" olmaktan çıkar, "kontrol tasarımının testi" haline gelir.

1.1. Veri sınıfları: "değer" ve "zarar" her zaman aynı şey değildir

Aynı veri bir kurum için önemsiz, başka bir kurum için varoluşsal olabilir. Bu yüzden ileri seviye yaklaşım veri sınıfını sadece "gizli/özel" etiketleriyle bırakmaz; iş etkisi ve uyum/regülasyon boyutuyla ele alır:

Yüksek iş etkisi: strateji dokümanları, fiyatlandırma, kaynak kodu, kritik sözleşmeler.
Uyum riski: kişisel veriler, finansal kayıtlar, sağlık verileri gibi düzenlemeye tabi kümeler.
Operasyonel risk: erişim anahtarları, sertifika/secret, token gibi kimlik materyali.

Örnek: Uydurma bir şirkette "ürün yol haritası" ile "test ortamı logları" karşılaştırılıyor. Yol haritası rekabet etkisi taşır. Test logları düşük değerli gibi görünür; ama içinde kimlik materyali kalıntıları varsa risk sınıfı bir anda yükselir. Bu dönüşüm raporda "varsayım" olarak değil, kanıtlanmış bir risk zinciri olarak yazılmalıdır.

Dikkat: "En değerli veri"yi aramak kadar, "düşük değerli görünen verinin yüksek etkiye dönüşme koşullarını" yakalamak kritiktir. Bu noktada acele kesinlik yerine, karşı kanıt arayan bir dille ilerlemek kalite göstergesidir.

1.2. Staging: aktarım öncesi görünmez risk katmanı

Staging, verinin kurum dışına çıkmadan önce toplandığı/özetlendiği/paketlendiği ara evredir. Bu evreyi önemli yapan şey şudur: pek çok kurumda kontroller "çıkış"a odaklanır; staging ise içeride olup biter ve yanlış güven varsayımlarının olduğu alanlarla çakışabilir (paylaşımlı depolar, senkronizasyon dizinleri, geçici çalışma klasörleri, rapor üretim alanları, CI/CD artefakt depoları gibi).

Bu modülde staging'in "nasıl yapılacağı" anlatılmaz. Anlatılan şey, staging'in neden ölçülmesi gerektiği ve ölçümün minimum zarar prensibiyle nasıl tasarlanacağıdır: "gereksiz veri biriktirmeden", "kurumu riske sokmadan", "kanıt standardını koruyarak".

İpucu: Staging'i bir "teknik aşama" gibi değil, bir "kontrol hipotezi" gibi yaz: "Bu kurumda şu tip ara depolarda görünürlük/retention zayıf olabilir." Sonra hipotezi doğrulamak için hangi telemetriye bakacağını ve hangi bulgunun hipotezi çürüteceğini önceden tanımla.

1.3. Kanal sınıfları: "kolay yol" değil, "ölçülebilir yol" düşüncesi

Kanal seçimi, ileri seviyede "hangi yöntemle çıkılır" sorusu değildir; "hangi kanal sınıfı, hangi kontrol yüzeyiyle test edilebilir" sorusudur. Kanal sınıflarını şu başlıklarda düşünmek işlevseldir:

Uygulama katmanı kanalları: e-posta, dosya paylaşımı, kurumsal iş uygulamaları üzerinden veri akışları.
Ağ katmanı kanalları: egress trafiği, proxy/DNS/TLS gibi noktalarda görünürlük üreten/üretmeyen akışlar.
Bulut/hibrit kanalları: SaaS senkronizasyonu, API tabanlı veri hareketi, tenantlar arası kopyalama riskleri (Modül 14 ile doğal bağ).
Süreç/iş mantığı kanalları: kurumun zaten izin verdiği "meşru veri yolları" (ör. dış bordro sağlayıcısı, dış raporlama süreci) üzerinden doğan riskler.

Burada kritik olan, "teknik bir atlatma"yı tarif etmek değil; iş sürecinin, kontrol kararlarını nasıl şekillendirdiğini görmek. Bazı akışlar "güvenilir hedef" kabul edildiği için içerik denetimi daha gevşek olabilir; bazı akışlarda ise tam tersi, iş sürekliliği için istisnalar tanımlanmıştır. İleri seviye değerlendirme bu istisnaları "suistimal edilebilir" diye yazıp geçmez; neden böyle tasarlandığını ve hangi ek kontrollerle dengelenebileceğini tartışır.

Dikkat: Kanal sınıflarını saymak bulgu değildir. Bulgu, kanal sınıfının bu kurumda hangi log kaynaklarında göründüğünü, hangi kontrollerin devreye girdiğini ve bunun iş riskine nasıl bağlandığını kanıtlayabildiğinde oluşur.

1.4. Doğrulama döngüsü: hipotez-gözlem-karşı kanıt-confidence

"Proxy'de görmedik, demek ki olmadı" veya "DLP alarm verdi, demek ki engelledi" gibi kestirmeler ileri seviyede risklidir. Çünkü hem telemetri hem de kontrol davranışı bağlama bağımlıdır. Bu yüzden exfiltration değerlendirmesi bir doğrulama döngüsüyle yürür:

Hipotez: "Şu veri sınıfı, şu akış sınıfı üzerinden taşınabilir görünür."
Gözlem: "Şu zaman penceresinde, şu kontrol noktalarında şu sinyal görüldü/görülmedi."
Karşı kanıt: "Benzer akış normal iş süreçlerinde var mı? Retention yeterli mi? Başka log kaynağında iz var mı? Kontrol davranışı 'fail-open' olabilir mi?"
Confidence: "Bu iddianın güven düzeyi nedir; hangi ek kanıt gelirse yükselir/düşer?"

2) DLP'yi "kural seti" değil, "karar mekanizması" olarak okumak

DLP'yi ileri seviyede anlamak, "hangi ürün var" değil, "hangi sinyalle karar veriyor" sorusunu sormaktır. DLP'ler kurumdan kuruma değişse de karar mekanizmaları çoğunlukla şu sınıflara ayrılır:

İçerik örüntüsü (pattern) ve regex: belirli veri formatlarını yakalama (ör. kimlik numarası formatları).
Parmak izi / içerik tanıma (fingerprinting): bilinen belge/şablonları benzetimle eşleme.
Metaveri ve bağlam: dosya etiketi/sınıflandırma, kanal, hedef, kullanıcı rolü, zaman, iş süreci gibi sinyaller.

Bu çerçeve, DLP'nin "kör noktalarını" (daha doğrusu kapsama sınırlarını) tartışmayı mümkün kılar-ama amaç "bypass nasıl yapılır" değildir. Amaç, savunma açısından doğru soruyu sormaktır:

İçerik denetimi ne zaman mümkün değil? (ör. içerik okunamaz hale geldiğinde)
Sistem bu durumda fail-closed (engelle) mi davranıyor, yoksa fail-open (izin ver) mı?
İş sürekliliği nedeniyle izin verilen istisnalar, hangi ek kontrollerle dengeleniyor?

İpucu: DLP değerlendirmesini "tek kural" düzeyinde raporlama. Her bulguyu şu üçlüyle paketle: (1) hangi sinyalle karar verildi, (2) bu sinyal hangi koşullarda zayıflıyor, (3) bu zayıflık iş sürecinde hangi veri sınıfını riske sokuyor. Bu format, Modül 17'deki remediation backlog'unu doğrudan besler.

2.1. "Okunamaz içerik" problemi: şifreleme ve denetim sınırı

Bazı akışlarda veri, denetim noktasına geldiğinde içerik olarak görülemez (şifreli arşivler, uçtan uca şifreli kanal vb.). Burada kritik nokta "şifreleme kötü" gibi yüzeysel bir çıkarım değildir; kritik nokta şudur: kontrol mekanizması, içerik okuyamadığında nasıl karar veriyor ve bunun yanlış alarm/iş kesintisi maliyeti nedir?

Eğer her okunamaz içeriği engellersen, iş süreçlerini durdurabilirsin.
Eğer okunamaz içeriğe geniş izin verirsen, DLP'nin kapsama alanını fiilen daraltabilirsin.

İleri seviye rapor, bu dengeyi "ya hep ya hiç" yerine risk eşiği + bağlam + telafi edici kontroller olarak tartışır (ör. hedef/kanal kısıtları, sınıflandırma zorunluluğu, ek izleme/uyarı gibi).

2.2. "Düşük ve yavaş" (low-and-slow) ve eşik mantığı

Kurumsal kontrollerin bir kısmı hacim/ hız eşikleriyle çalışır (ani büyük hareketleri yakalamak kolaydır; küçük parçalı hareketleri yakalamak zordur). Bu noktada bu modül bir teknik uygulama öğretmez; fakat savunma perspektifinden şu soruyu görünür kılar:

Kontrol yalnızca "tek seferde büyük hacim"e mi bakıyor, yoksa zaman içinde biriken küçük hareketleri de korele edebiliyor mu?
Bu korelasyon yapılacaksa bunun SOC üzerindeki gürültü maliyeti nedir?

2.3. "Format değişimi" ve sınıflandırma sürekliliği

Veri, farklı temsil biçimlerine dönüştüğünde kontrollerin bir kısmı bağlamı kaybedebilir. Burada ileri seviye okuryazarlık şu farkı bilir: "veri kaybolmadı; temsil biçimi değişti." Bu nedenle güvenli değerlendirme, sınıflandırmanın ve bağlamın akış boyunca korunup korunmadığını ölçer.

Dikkat: Bu başlıklar "şöyle yaparsan geçersin" listesi değildir. Bu modülün çıktısı, kontrol tasarımını iyileştirmek için hangi zayıf varsayımların bulunduğunu ve bunların iş etkisini kanıt standardında göstermektir.

3) Etki simülasyonu: yıkım üretmeden ikna edici kanıt üretmek

Etki (impact) simülasyonu, "sistemi durdurmak" veya "gerçek veri ihlali yaratmak" değildir. Etki simülasyonu, iş sahibinin anlayacağı biçimde şu soruyu yanıtlar:

Bu yetki seviyesiyle, bu sistem ve süreçlerde hangi zarar gerçekleşebilirdi; bunu zarar vermeden nasıl kanıtlıyoruz?

Bu yaklaşım, özellikle fidye yazılımı riskini (erişilebilirlik ve bütünlük etkisi) güvenli biçimde ölçmek için kritiktir.

3.1. "Yapabilirim" kanıtı: eylemi yapmak yerine kabiliyeti doğrulamak

Erişilebilirlik (availability): hizmeti gerçekten düşürmeden, hizmetin kritik yapılandırma/çalışma bileşenlerinde değişiklik yapabilecek yetkinin varlığını kanıtlamak.
Bütünlük (integrity): veri tahribatı yapmadan, "değiştirebilme" kabiliyetini minimum, geri alınabilir ve izlenebilir bir kanıtla göstermek.
Fidye yazılımı benzeri risk: "dosyalara yazabiliyorum" gibi kabiliyet göstergelerini, gerçek şifreleme/yıkım yapmadan kanıtlamak (benign simulation).

Burada kalite kapısı şudur: kanıt ikna edici olacak; ama kurumda kalıcı değişiklik veya iş kesintisi yaratmayacak.

İpucu: Etki kanıtını tasarlarken önce "geri dönüş planı" yaz: Ne değişirse geri alacağız? Kim onaylayacak? Hangi telemetriyle doğrulayacağız? Bu, Modül 1'deki RoE ve kill-switch mantığını etki simülasyonuna taşır.

3.2. Kanıtın dili: dramatik anlatı yerine ölçülebilir ifade

İleri seviye raporda "felaket olabilirdi" cümlesi tek başına değer taşımaz. Bunun yerine kanıt dili şu üçlüyü korur:

Kapsam: Hangi sistem/veri sınıfı/iş süreci?
Koşul: Hangi yetki seviyesi ve hangi kontrol davranışı altında mümkün?
Doğrulama: Bunu hangi log/sinyal ve hangi karşı kanıt arayışıyla destekliyoruz?

Örnek: Uydurma bir senaryoda kritik bir dosya alanında "yazma yetkisi" kanıtlandıysa, rapor bunu "şifreleyebilirdik" gibi bir iddia cümlesiyle bitirmez; bunun yerine "Bu alanda bütünlük/erişilebilirlik etkisi doğurabilecek kabiliyet doğrulandı; şu kontrollerin görünürlük/engelleme davranışı şu kanıtlarla ölçüldü." şeklinde ölçülebilir yazar.

3.3. Yöntem seçimi ve sınırlar: aynı etkiyi kanıtlamanın birden fazla yolu vardır

Aynı iş etkisini kanıtlamak için farklı yollar olabilir. İleri seviye seçim, şu maliyetleri birlikte tartar:

Üretime etki riski ve geri dönüş zorluğu
Gürültü/yanlış alarm maliyeti (SOC yükü)
Etik/OPSEC sınırı ve RoE uyumu
Tekrar üretilebilirlik ve denetlenebilirlik

4) Güvenli kapanış: "hiç olmamış gibi" değil, "tartışmasız teslim" gibi

Profesyonel kapanışın hedefi, adli izleri yok etmek (anti-forensics) değildir. Hedef, operasyonun ürettiği operasyonel artıkları temizlemek ve mavi takımın test ile gerçeği ayırt edebilmesini sağlayacak değişiklik günlüğünü teslim etmektir.

4.1. Cleanup disiplini: ortamda "çöp" bırakmamak

Kapanışta tipik iş kalemleri (komut/araç tarifi olmadan, prensip düzeyinde):

Test sırasında bırakılmış geçici dosyalar/artefaktlar
Geçici erişimler, test amaçlı açılan istisnalar
Operasyon için oluşturulan kullanıcı/rol/erişim öğeleri
Kanıt paketinde yer almaması gereken ham materyaller

Dikkat: "Temizlik" ile "kanıt yakma"yı karıştırmak en büyük profesyonellik hatalarından biridir. Temizlik, testin bıraktığı operasyonel yükü kaldırır; denetim için gerekli olan kanıtı ortadan kaldırmaz.

4.2. Güvenli silme ve veri minimizasyonu

Standart silme işlemleri her zaman veri geri kazanımını imkânsız kılmaz; bu nedenle kurum politikaları ve RoE'ye uygun şekilde güvenli imha ve veri minimizasyonu yaklaşımı benimsenmelidir. Burada amaç teknik tarif vermek değil, doğru prensibi yerleştirmektir: test için toplanan her şeyin neden toplandığı, nerede saklandığı, ne zaman ve hangi onayla imha edildiği izlenebilir olmalıdır.

4.3. Değişiklik günlüğü: deconfliction'ın somut çıktısı

Mavi takımın test sırasında "hayalet avlamaması" için değişiklik günlüğü kritik bir teslimat kalemidir. Günlük şu soruları yanıtlar:

Hangi sistemlerde, hangi zaman aralığında, hangi test kaynaklı değişiklikler oldu?
Bu değişiklikler hangi amaçla yapıldı ve nasıl geri alındı?
Mavi takım loglarında neyi "test artefaktı" olarak beklemeli?

Bu günlük, Modül 1'deki deconfliction mantığını pratikte mümkün kılar ve Modül 17'deki Purple Team oturumunda ortak gerçeklik zemini oluşturur.

Terimler Sözlüğü

Terim	Açıklama
Exfiltration	Verinin kurum sınırları dışına taşınmasıyla ilgili risk sınıfı; bu modülde ölçüm ve kontrol değerlendirmesi bağlamında ele alınır
Impact	İş etkisi; bütünlük/erişilebilirlik/kayıp gibi sonuçların iş süreçlerine yansıması
Staging	Verinin aktarım öncesi iç ortamda toplanması/özetlenmesi/paketlenmesiyle ilgili ara evre ve risk katmanı
DLP (Data Loss Prevention)	Hassas verinin kurum dışına çıkmasını önlemeye/izlemeye yönelik politika, süreç ve teknik kontroller bütünü
Fingerprinting	İçeriği benzetimle tanıma/parmak izi yaklaşımı; bilinen belge/şablonların tespitinde kullanılan yöntem sınıfı
Metadata	İçeriğin kendisi dışındaki bağlamsal bilgiler (etiket, sınıflandırma, kanal, hedef, kullanıcı rolü vb.)
Telemetry	Uç nokta/ağ/kimlik gibi katmanlardan üretilen log ve sinyal verisi
Visibility vs Detection	“Görünürlük var” ile “alarm/engelleme var” ayrımı
Fail-open	Denetim mümkün değilken izin verme eğilimi; kapsama boşluğu riski doğurabilir
Fail-closed	Denetim mümkün değilken engelleme eğilimi; iş sürekliliği maliyeti doğurabilir
False Positive (FP)	Yanlış pozitif; meşru akışların hatalı şekilde riskli görünmesi
Evidence chain	Kaynak–iddia–kanıt ilişkisinin zaman uyumlu, izlenebilir ve tekrar üretilebilir biçimde paketlenmesi
Confidence	Bulgudaki eminlik düzeyi; kanıt kalitesi ve karşı kanıt arayışıyla gerekçelendirilir
Deconfliction	İzinli çalışmada SOC/IR/IT ile çakışmayı yönetme ve test–gerçek ayrımını güvenli kılma
Benign simulation	Zarar vermeden, kabiliyeti kanıtlayan güvenli etki simülasyonu yaklaşımı
Luhn Algorithm	Bazı numara formatlarında (örn. kart numarası) doğrulama için kullanılan checksum yaklaşımı; sentetik veri tartışmalarında “format gerçekçiliği” bağlamında anılır

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir engagement’ta amaç “SOC korelasyon kalitesini ölçmek” olarak tanımlanmış. C2 tasarımında en doğru öncelik hangisidir?

A) Maksimum gizlilik için görünür izleri tamamen ortadan kaldırmak

B) Ölçülebilir sinyaller üreten ve hipotez–gözlem–karşı kanıt döngüsüyle doğrulanabilir bir iletişim yaklaşımı seçmek

C) Gürültüyü artırıp SOC’u “stres testine” sokmak

D) Tüm patikaları tek bir merkezde birleştirip izleri karıştırmak

E) Log kaynaklarını dikkate almadan yalnızca performansa göre karar vermek

Doğru: B
Gerekçe: Ölçüm hedefi, doğrulanabilir sinyal ve kanıt disiplinini gerektirir. A ölçümü zayıflatabilir; C gereksiz operasyonel yük ve etik risk üretir; D izlenebilirliği bozar; E kanıtsız varsayımdır.

2) “Alarm yoktu, demek ki başarılıydık” ifadesi neden ileri seviye raporlama açısından zayıftır?

A) Alarm her zaman çıkar

B) Alarm yokluğu; telemetri eksikliği, yanlış ölçüm tasarımı veya tespit boşluğu gibi çoklu açıklamalara sahiptir

C) SOC her şeyi görür

D) Yalnızca ağ logları önemlidir

E) Alarm yokluğu kanıt yerine geçer

Doğru: B
Gerekçe: Alarm yokluğu tek başına kanıt değildir; karşı kanıt arayışı ve telemetri doğrulaması gerekir. Diğer şıklar genelleme veya yanlış önermedir.

3) Katmanlı (tiered) altyapı yaklaşımının en doğru risk–fayda özeti hangisidir?

A) Her zaman daha güvenlidir ve maliyeti yoktur

B) Ana varlıkların doğrudan görünürlüğünü azaltabilir; ancak yönetim karmaşıklığı ve hata riski artar

C) Sadece maliyet azaltmak için seçilir

D) Sadece raporu uzatır

E) Deconfliction ihtiyacını ortadan kaldırır

Doğru: B
Gerekçe: Katmanlı yapı trade-off içerir. A/E aşırı iddia; C/D amaç dışıdır.

4) Bir Blue Team analisti, “yüzeyde meşruya benzeyen” bir trafiği hangi yaklaşımla daha sağlıklı ayrıştırır?

A) Sadece başlık/format benzerliğine bakarak

B) Bağlam tutarlılığına bakarak: hedefin sahipliği, sertifika/alan adı uyumu ve kurum politikasına uygunluk gibi sabit sinyalleri kontrol ederek

C) Sadece paket boyutuna bakarak

D) Sadece günün saatine bakarak

E) Ayrıştıramaz; benzetme varsa imkânsızdır

Doğru: B
Gerekçe: Kozmetik yüzey taklit edilebilir; bağlam tutarlılığı ve doğrulanabilir sabit sinyaller ayrıştırmada daha güçlüdür. E “kesinlik” içerir ve gerçekçi değildir.

5) “Jitter” eklemenin en doğru trade-off tanımı hangisidir?

A) Gürültü artar, gecikme azalır

B) Düzenlilik azalır (tespit riski bazı senaryolarda düşebilir), ancak komut gecikmesi ve operasyonel kontrol maliyeti artabilir

C) Tespiti garanti eder

D) Sadece maliyet düşürür

E) Hiçbir etkisi yoktur

Doğru: B
Gerekçe: Jitter düzenlilik izini azaltırken gecikme/operasyonel kontrol maliyeti getirebilir. C/E gibi kesin ifadeler yanlıştır.

6) “Infrastructure as Code (IaC)” yaklaşımının OPSEC açısından en güçlü katkısı hangisidir?

A) Gizliliği otomatik garanti etmesi

B) Konfigürasyonları standartlaştırarak insan hatasını azaltması ve denetlenebilir “ne değişti?” izini güçlendirmesi

C) Tespit sistemlerini devre dışı bırakması

D) Telemetriyi ortadan kaldırması

E) Her zaman daha ucuz olması

Doğru: B
Gerekçe: IaC, standardizasyon ve hata azaltma ile OPSEC’i güçlendirir; gizlilik/tespit garantisi vermez.

7) “Aynı altyapıyı farklı müşterilerde tekrar kullanma” kararı neden özellikle risklidir?

A) Çünkü teknik olarak çalışmaz

B) Korelasyon/attribution riskini artırır; bir yerde yanan gösterge (IOC), başka bir yerde savunmanın operasyonu erken engellemesine yol açabilir

C) Çünkü rapor yazmayı zorlaştırır

D) Çünkü sadece maliyet artırır

E) Çünkü kimlik logları buna izin vermez

Doğru: B
Gerekçe: Altyapı tekrar kullanımı, ilişkilendirilebilirlik ve “kirlenme” riskini büyütür. Diğer seçenekler ya ikincil ya da hatalıdır.

8) Bir alan adının “kategorisiz/uncategorized” olması hangi nedenle ölçümü bozabilir?

A) DNS çalışmaz

B) Kurumsal proxy/güvenlik politikaları, kategorisiz alanları varsayılan olarak kısıtlayabilir; bu da erişilebilirliği ve ölçüm sürekliliğini etkiler

C) TLS çalışmaz

D) Sadece performans düşer

E) Hiçbir etkisi olmaz

Doğru: B
Gerekçe: Kurumsal kontroller kategori/itibar sinyallerine dayanabilir. “Hiçbir etkisi olmaz” gibi kesinlikler yanlıştır.

9) “Doğrulama” dilinde en olgun ifade hangisidir?

A) “Bence böyle, çünkü mantıklı.”

B) “Tek kaynaktan gördüm, kesin.”

C) “Hipotez kurdum, gözlemleri topladım, alternatif açıklamalar için karşı kanıt aradım; şu nedenle şu düzeyde eminim ve şu veri gelirse fikrim değişir.”

D) “Alarm yoktu, o yüzden oldu.”

E) “Araç öyle dedi.”

Doğru: C
Gerekçe: Olgun doğrulama; hipotez–gözlem–karşı kanıt–confidence zincirini kurar. Diğerleri kanıt standardını karşılamaz.

10) C2/altyapı bulgularını savunmaya çevirmek için en iyi raporlama çerçevesi hangisidir?

A) Kullanılan araçların listesi

B) Sadece risk puanı

C) Gözlem–yorum ayrımı + etkilenen kontrol hedefi (egress, DNS/proxy görünürlüğü, uç nokta telemetri) + ölçülebilir iyileştirme önerileri

D) Sadece ekran görüntüleri

E) “Ne yaptık” anlatısı

Doğru: C
Gerekçe: Savunma değeri, bulguyu kontrol hedeflerine ve ölçülebilir önerilere bağlamaktır. A/B/D/E tek başına yetersizdir.

Bu Modülde Kazanılan Yetkinlikler

Exfiltration'ı "kanal" ezberinden çıkarıp veri sınıfı + kontrol yüzeyi + ölçüm tasarımı üçlüsüyle düşünmeyi.
Staging'i, içerideki varsayım ve görünürlük boşluklarını yakalayan kritik bir risk katmanı olarak okumayı.
DLP'yi kural listesi değil, karar mekanizması olarak ele alıp fail-open/fail-closed ve telafi edici kontrol mantığını kurmayı.
Etki simülasyonunu zarar vermeden, benign ama denetlenebilir kanıtlarla iş diline çevirmeyi.
Kaynak-iddia-kanıt ayrımı, karşı kanıt arayışı ve confidence diliyle kanıt standardını yükseltmeyi.
Güvenli kapanışı; cleanup, erişim kaldırma, veri minimizasyonu ve değişiklik günlüğüyle tartışmasız teslim haline getirmeyi.

Modül 14 — Cloud ve Hybrid Red Teaming: Saldırı Patikası Perspektifi

Geleneksel ağ güvenliğinde "kale ve hendek" (segmentasyon, güvenlik duvarı, DMZ) metaforu işe yarar; bulutta ise güven sınırı çoğu zaman kimliktir. Çünkü bulut ortamının gerçek topolojisi, sunucu listesinden çok kimlikler-roller-politikalar-servisler arasındaki ilişki grafıdır. Hibrit yapılarda (on-prem ↔ bulut) bu ilişki grafı iki dünyanın güven varsayımlarını birbirine bağlar; tek bir istisna veya fazla yetki, beklenmedik bir saldırı patikasına dönüşebilir. Bu modül, teknik "sızma" adımlarına girmeden; Control Plane (yönetim düzlemi) ile Data Plane (veri düzlemi) ayrımı, IAM mantık hataları, hibrit kimlik köprüleri ve görünürlük/tespit boşlukları üzerinden saldırı patikası modelleme disiplinini ileri seviyede ele alır.

Bu Modülde Hedeflenen Kazanımlar

Bulutta saldırı yüzeyini "portlar ve sunucular" yerine kimlik, yetki ve API yönetim katmanı üzerinden okuyabilmek.
Control Plane / Data Plane ayrımını kullanarak riskin nerede "stratejik" hale geldiğini gerekçelendirebilmek.
Aşırı yetkilendirme ve yanlış IAM tasarımlarını, tekil hata gibi değil ayrıcalık zinciri olarak modelleyip iş etkisine bağlayabilmek.
Hibrit kimlik köprülerinde (eşitleme/federasyon/servis kimlikleri) "güven ilişkisi kırılması" risklerini sınıflandırıp doğrulama planı kurabilmek.
Bulut loglarını "var/yok" düzeyinden çıkarıp; kör noktaları, gecikmeleri, doğrulama ve karşı kanıt perspektifiyle değerlendirebilmek.
Bulguları kanıt zinciri + belirsizlik (confidence) dili ile paketleyip, yöntem seçimini noise/FP ve operasyonel yük/etik sınırlarla birlikte rapora taşıyabilmek.

1) Bulutta saldırı yüzeyinin yeniden tanımı: Kimlik perimetresi ve API gerçekliği

Bulutta "erişim" çoğu zaman bir makinenin ağına girmekten ziyade, bir kimliğin hangi kaynaklarda hangi eylemleri yapabildiğini anlamaktır. Bu nedenle ileri seviye keşif ve analiz, envanteri "VM/Storage/DB listesi" gibi değil; kimlik grafı gibi okur: kullanıcılar, servis/otomasyon kimlikleri, roller, politikalar, grup üyelikleri, federasyon bağları ve bunların bağlandığı kaynaklar.

1.1. Control Plane ve Data Plane: aynı olayın iki farklı yüzü

Data Plane, verinin kendisiyle ilgili akışları kapsar: uygulama trafiği, dosya/nesne erişimi, sorgular, servis çağrıları gibi.
Control Plane, altyapıyı yöneten yönetim/API katmanıdır: kaynak oluşturma, konfigürasyon değiştirme, yetki atama, güvenlik kuralı güncelleme gibi.

Bu ayrım, saldırı patikası düşüncesini keskinleştirir: Data Plane'deki bir zayıflık bazen yalnızca "yerel" bir etki doğurur; fakat aynı bağlam Control Plane'e temas edebilen bir kimliğe bağlanıyorsa etki, altyapının tamamına yayılabilecek bir risk sınıfına çıkar.

Örnek: Uydurma bir senaryoda, uygulama katmanındaki bir kusur "tek sunucu" etkisi gibi görülür. Ancak bu iş yüküne atanmış yönetilen kimlik/rol, yönetim düzleminde geniş yetkilere sahipse; risk, uygulama verisiyle sınırlı kalmayıp "altyapı değişebilir" sınıfına yükselir. Bu iddiayı kurarken hedef "ne yapılır" anlatmak değil; hangi güven ilişkisi hangi iş varlığına patika açıyor sorusunu kanıt standardında cevaplamaktır.

İpucu: Control Plane riskini anlatırken "bulutu hacklemek" gibi muğlak ifadeler yerine, "hangi kimlik hangi yönetim eylemlerini yapabiliyor; bu eylemler hangi iş varlığına dokunuyor?" çizgisinde somutlaştır. Savunma ekibinin aksiyon alabilmesi için patika, "kimlik → yetki → kaynak → iş etkisi" sırasını net göstermeli.

1.2. İnsan, servis ve otomasyon kimlikleri: aynı yetki, farklı risk

İnsan kimlikleri bağlam kontrollerine (MFA, koşullu erişim, cihaz uyumu, lokasyon/oturum risk skoru vb.) daha çok bağlıdır.
Servis kimlikleri genellikle "sessiz ve sürekli" çalışır; yanlış yetki verilirse risk daha istikrarlı ve çoğu zaman düşük gürültüyle akar.
Otomasyon kimlikleri (CI/CD, IaC, bakım iş akışları) küçük bir yanlışla geniş etki üretebilir; çünkü çoğu otomasyon "yönetim düzlemi"ne dokunur.

Aynı izin seti, kimliğin doğası nedeniyle farklı risk profili üretir. Bu noktada ileri seviye yaklaşım, yalnızca "yetki geniş" demekle yetinmez; bu yetki neden var, gerçekten kullanılıyor mu, kullanılmıyorsa neden hâlâ duruyor, hangi patikayı mümkün kılıyor sorularını doğrulama-karşı kanıt döngüsüyle ele alır.

Dikkat: Bulut ortamında "kanıt üretmek" ile "davranış üretmek" arasındaki çizgi çok incedir. Üretim ortamında geri dönüşü zor değişiklikler, geniş kapsamlı denemeler veya geri alma planı olmayan doğrulamalar, etik ve minimum zarar ilkesiyle çelişir. İleri seviye doğrulama, en düşük etkili sinyallerle başlar; yalnızca gerektiğinde ve kapsamı daraltarak derinleşir.

1.3. "Doğrulama" nasıl görünür olur? İddia-gözlem-karşı kanıt-confidence

Bulutta iddia kurmak kolaydır ("şu rol şunu yapabilir"), ama yayınlanabilir bir rapor için bu iddianın kanıta çevrilmesi gerekir:

İddia: Yetkinin varlığını ve kapsamını açık ifade et.
Gözlem: Rol/policy tanımı, atama/bağlılık (attachment), bağlam şartları, kaynak tarafı kısıtları gibi sinyalleri birleştir.
Karşı kanıt: "Kağıt üstünde var ama pratikte engel var mı?" sorusunu sistematik ele.
Confidence dili: "Ne kadar eminim, hangi veriyle, hangi şartlarda fikrim değişir?"

İpucu: "Policy'de izin var" tek başına "etki var" demek değildir. Kaynak tarafı kısıtlar, koşullu erişim kararları, onay iş akışları ve log/retention sınırları gibi unsurlar, iddiayı zayıflatabilir veya güçlendirebilir. Bu yüzden raporda, iddiayı destekleyen sinyaller kadar karşı kanıt arayışını da görünür kıl.

2) IAM yanlışları ve ayrıcalık zincirleri: Mantık hatasından patikaya

Bulutta kritik risklerin önemli bir bölümü "kod açığı"ndan ziyade yanlış yapılandırma ve yetkilendirme mantığı kaynaklıdır. İleri seviye farkı, bu yanlışları tekil "kötü policy" olarak değil; ayrıcalık zinciri olarak okumaktır: küçük yetkilerin birleşimiyle daha yüksek iş etkisine giden yol.

2.1. Aşırı yetkilendirme (over-permissive) nasıl sınıflanır?

Yetkileri üç pratik sınıfta düşünmek, etkiyi berraklaştırır:

Okuma (Read): gizlilik/uyum ve rekabet etkisi (hangi veri okunuyor?)
Yazma (Write): bütünlük etkisi (yanlış veri, bozulmuş iş akışı, zehirlenmiş çıktı)
Yönetme (Manage): kontrol düzlemi etkisi (başka kimliklerin ve kaynakların kontrolünü etkileyebilir)

Örnek: Uydurma bir ekip "sadece okuma yetkisi var, risk düşüktür" der. Ancak okunan içerik, konfigürasyon/bağlantı parametreleri veya yetki dağıtımına dolaylı kapı aralayan bilgiler içeriyorsa; "okuma" düşük risk varsayımı hızla çöker. İleri seviye rapor, "okuma"yı otomatik düşük risk saymaz; okunan şeyin türü ve bunun iş etkisine bağını kanıtlar.

2.2. Zincir düşünmek: "yetki dağıtım noktaları"nı yakalamak

Ayrıcalık zinciri çoğu zaman "tek büyük izin"den değil; yetki dağıtım noktalarına temas edebilen küçük izin kümelerinden doğar. İleri seviye analiz şu sorularla yürür:

Bu kimlik hangi kaynakları değiştirebilir ve bu değişiklik kimlerin erişimini etkiler?
Bu kimlik, rol/policy/grup üyeliği gibi "yetki üretim" mekanizmalarına temas ediyor mu?
Patika boyunca hangi halkalar görünür, hangileri kör (telemetri/retention/erişim kısıtları) kalır?

İpucu: Zinciri anlatırken "büyük kelimeler" yerine ara halkaları göster: "Bu yetki → şu yönetim eylemine temas → şu iş varlığı üzerinde dolaylı kontrol ihtimali." Savunma tarafı için en değerli çıktı, bu patikanın hangi kontrolle kırılacağıdır (guardrail, onay akışı, least privilege, izleme kuralı vb.).

2.3. Kanıt zinciri: "var" demek yetmez, "bağlı" olduğunu göstermek gerekir

Bir policy'nin geniş olması tek başına kritik bulgu olmayabilir. Kritik soru: Bu yetki kimde? (kullanıcı/rol/grup/servis) ve aktif mi? (bağlılık/atama ve kullanım bağlamı).

"Yetim" (unattached) policy çoğu zaman doğrudan operasyonel risk değildir; ama kurumsal hijyen problemidir ve ileride risk üretmeye adaydır.
"Bağlı ve aktif" bir geniş yetki, daha yüksek confidence ile raporlanabilir; çünkü saldırı patikasını "varsayım" yerine "izlenebilir ilişki" ile kurarsın.

Dikkat: Kanıt kalitesi yükseldikçe, raporun dili de daha dikkatli olmalı: "kesin" ifadeler yalnızca zincirin halkaları bağımsız sinyallerle doğrulandığında kullanılmalı; aksi halde "orta/yüksek olasılık" gibi doğru bir confidence dili tercih edilmelidir.

3) Hibrit kimlik köprüleri: On-prem ↔ bulut güven ilişkisinin anatomisi

Hibritte asıl risk "iki farklı ortam" değil; iki ortam arasındaki güven ilişkisidir. Bu köprüler doğru tasarlanırsa güvenliği artırır, yanlış varsayımlarla işletilirse güven sınırlarını silikleştirir.

3.1. Köprü türleri ve risk sınıfları

Eşitleme (sync) odaklı köprüler: yerel dizin bilgileri buluta taşınır; "kimliğin kaynağı" ve "değişikliklerin yetkisi" kritikleşir.
Federasyon odaklı köprüler: kimlik doğrulama bir tarafta yapılır, bulut tarafı bu karara güvenir; istisnalar ve imza/güven materyali riski büyür.
Servis kimliği/entegrasyon köprüleri: otomasyon bağlantıları; düşük görünürlükle yüksek etki doğurabilir.

Bu noktada isimlerden ziyade şu soru belirleyicidir: Köprü hangi varsayımlarla güvenli sayılıyor? "Her federe oturum MFA'lıdır", "istisnalar dar ve süreli kalır", "senkronizasyon hesabının yetkisi sıkı kontrol edilir", "sertifika/anahtar yönetimi olgundur" gibi varsayımlar; gerçek hayatta en çok sızdıran yerlerdir.

Örnek: Uydurma bir kurum "kurumsal cihaz şartı" koyar; fakat "acil iş" gerekçesiyle istisnalar açılır ve zamanla genişler. İleri seviye rapor, istisnayı sadece belirtmez: kapsamını, gerekçesini, telafi edici kontrolleri (izleme, zaman kısıtı, onay), bu kontrollerin gerçekten çalıştığına dair kanıtları ve belirsizlikleri birlikte yazar.

3.2. "Köprü var" ile "etki var" arasına kanıt koymak

Hibrit bulguların en yaygın hatası, bağlantıyı otomatik etkiye bağlamaktır. Doğru disiplin:

Köprünün varlığını doğrula (teknik ilişki/işletim modeli).
Yetkilendirme kararlarının ve istisna setlerinin bu köprü üzerinden risk üretip üretmediğini kanıtla.
Telemetri ve saklama (retention) sınırlarını açıkça yaz; "görünürlük yok"u "olmadı" diye yorumlama.

İpucu: Hibritte tek bir "ayar düzeltmek" çoğu zaman yetmez; güven ilişkisinin işletimi düzeltilmelidir: istisna yönetimi, periyodik yetki gözden geçirme, log erişimi ve saklama politikası, sahiplik (kim onaylıyor?) ve acil durum süreçleri. Bu yaklaşım, Modül 17'deki aksiyon backlog'unu gerçekçi ve denetlenebilir yapar.

4) Bulut görünürlüğü ve loglama: "Ne loglanır, ne kaçırılır?"

Bulut sağlayıcı "bulutun güvenliği" (altyapı katmanı) tarafında sorumluluk taşırken; müşteri "bulut içindeki güvenlik"ten (konfigürasyon, kimlik, veri ve izleme) sorumludur. Bu paylaşım, görünürlüğün varsayılan olarak "tam" olacağı anlamına gelmez.

4.1. Yönetim olayları ve veri olayları: görünürlük boşluğu nerede doğar?

Yönetim olayları (management-type): kaynak oluşturma/silme, rol/policy değişimleri, konfigürasyon hareketleri.
Veri olayları (data-type): nesne/dosya erişimi, bazı veri düzlemi okumaları/yazmaları ve servis-özel işlemler.

Birçok kurumda veri olaylarının görünürlüğü, maliyet/performans ve operasyonel karmaşıklık nedeniyle sınırlı tutulur. Bu da şu soruyu doğurur: "Bir olay olduysa, iz nerede oluşur; oluşmuyorsa bunu nasıl ve ne kadar confidence ile söyleyebilirim?"

4.2. Görünürlük ≠ tespit ≠ engelleme

Görünürlük: izin/sinyalin bir yerde oluşması
Tespit: sinyalleri bağlamlı korelasyonla anlamlı alarmlara dönüştürmek
Engelleme: guardrail/policy ile riskli eylemi önlemek

Örnek: Uydurma bir ortamda yönetim olayları kayıt altındadır; fakat "yüksek riskli rol ataması" gibi kritik desenler için tespit kuralı yoktur. "Log var" denebilir ama "tespit var" denemez. İleri seviye rapor, "kural yazın" demekle kalmaz; hangi sinyallerle, hangi bağlamda, hangi eşiğin FP/noise maliyetiyle yönetileceğini kabul kriteri şeklinde tarif eder.

Dikkat: "Alarm yok" ifadesi kanıt değildir. Alarm yokluğu; yanlış kural, yanlış eşik, gecikme, retention boşluğu, erişim kısıtı veya gerçekten olay yokluğu gibi birden fazla açıklamaya sahip olabilir. Bu yüzden rapor dili aceleci kesinlikten kaçınmalı; karşı kanıt arama adımı açıkça görünmelidir.

Terimler Sözlüğü

Terim	Açıklama
Amazon Web Services (AWS)	Bulut servis sağlayıcı platform (genel örnek)
Microsoft Azure	Bulut servis sağlayıcı platform (genel örnek)
Google Cloud Platform (GCP)	Bulut servis sağlayıcı platform (genel örnek)
Cloud	Bulut; kaynakların servis olarak sunulduğu işletim modeli
Hybrid	Hibrit; on-prem altyapı ile bulut servislerinin birlikte çalışması
IAM (Identity and Access Management)	Kimlik ve erişim yönetimi; kimliklerin yetkilerle ilişkilendirilmesi
RBAC (Role-Based Access Control)	Rol tabanlı erişim kontrolü; izinlerin roller üzerinden yönetilmesi
Policy	Yetki/politika tanımı; hangi eylemlerin hangi koşullarda yapılabildiği
Over-permissive	Aşırı yetkilendirilmiş; gereğinden geniş izin seti
Least Privilege	Asgari ayrıcalık; yalnızca gerekli yetkilerin verilmesi prensibi
Control Plane	Yönetim/API katmanı; altyapının yönetildiği düzlem
Data Plane	Veri/iş yükü düzlemi; uygulama trafiği ve veriye erişimin geçtiği katman
Identity Perimeter	Kimlik perimetresi; erişim kararlarının ağ konumundan çok kimlik/yetkiyle belirlendiği sınır
Managed Identity / Instance Profile	İş yüküne atanmış yönetilen kimlik; uygulamanın kimlik bilgisi “gömmeden” kaynaklara erişmesini sağlar
Metadata Service	İş yükü kimliği ve konfigürasyonuna dair bilgilerin sunulduğu dahili mekanizma (kavramsal)
Federation	Federasyon; kimlik doğrulamanın harici kimlik sağlayıcıya dayandığı güven modeli
Guardrail	Koruyucu kural/çerçeve; riskli eylemleri sınırlayan politika seti
Telemetry	Telemetri; log/sinyal verileri üzerinden görünürlük üretimi
Retention	Saklama süresi; logların ne kadar süre erişilebilir olduğu
Latency	Gecikme; logların sisteme düşmesindeki zaman farkı
Shadow Cloud IT	Merkezi BT’den bağımsız açılmış/unutulmuş bulut varlıkları; zayıf yönetişim nedeniyle riskli alan

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bulut ortamında “ağ perimetresi güçlü” olsa bile riskin kritik hale gelmesini en doğru açıklayan seçenek hangisidir?

A) Ağ perimetresi güçlü ise bulut otomatik güvenlidir

B) Bulutta erişim kararları çoğunlukla kimlik ve yetkiyle verilir; ağ yalnızca kontrol katmanlarından biridir

C) Bulutta ağ hiç önemli değildir

D) Risk yalnızca depolama servislerindedir

E) Bulutta güvenlik yalnızca şifreleme ile sağlanır

Doğru: B
Kısa gerekçe: Bulutta yönetim ve erişim kararlarını kimlik/yetki belirler. A aşırı genelleme; C yanlış; D/E tek boyutlu.

2) Aşağıdakilerden hangisi Control Plane ile Data Plane ayrımını “saldırı patikası” açısından en doğru kullanır?

A) Data Plane her zaman önemsizdir

B) Control Plane yalnızca loglarla ilgilidir

C) Data Plane’deki bir zafiyet, ona bağlı kimlik/yetki ilişkisi nedeniyle Control Plane’de daha geniş etkiye dönüşebilir

D) Control Plane yalnızca ağ cihazlarından oluşur

E) İkisi arasında pratik bir fark yoktur

Doğru: C
Kısa gerekçe: Ayrım, etki sınıfını ve patikanın “yayılabilirliğini” belirler. Diğer seçenekler kavramı yanlış/eksik yorumlar.

3) “Geniş yetkili bir policy bulundu” bulgusunu yayınlanabilir kanıt standardına taşımak için en kritik ek bilgi hangisidir?

A) Policy isminin “admin” içerip içermediği

B) Policy’nin bağlı olduğu kimlik(ler) ve kullanım bağlamı (atama/attachment + koşullar)

C) Policy’nin yazı tipi ve biçimi

D) Bulut sağlayıcının marka adı

E) Policy’nin ne kadar süredir var olduğu tek başına

Doğru: B
Kısa gerekçe: Risk, “kağıt üstünde izin”den değil, bu iznin kimde ve hangi koşullarda etkin olduğundan doğar. A/C/D alakasız; E tek başına yetersiz.

4) Hibrit kimlik mimarisinde “köprü var → etki var” çıkarımı hangi nedenle hatalı olabilir?

A) Hibrit mimarilerde log tutulmaz

B) Köprü yalnızca dosya paylaşımı içindir

C) Yetkilendirme kararları, istisnalar, kaynak kısıtları ve telemetri sınırları patikayı pratikte engelleyebilir; karşı kanıt aranmalıdır

D) On-prem her zaman güvensizdir

E) Bulut her zaman güvensizdir

Doğru: C
Kısa gerekçe: İleri seviye analiz, teknik ilişkiyi otomatik etkiye çevirmeden önce bağlam ve karşı kanıt arar. Diğer şıklar genelleme/yanlıştır.

5) Aşağıdakilerden hangisi “okuma yetkisi düşük risk” varsayımını ileri seviyede en doğru şekilde çürütür?

A) Okuma yetkisi asla risk değildir

B) Okunan içerik konfigürasyon/bağlantı bilgileri gibi dolaylı kontrol noktalarını açığa çıkarabilir; iş etkisi veri türüne bağlıdır

C) Okuma yetkisi yalnızca log okumaktır

D) Okuma yetkisi yalnızca eğitim ortamlarında olur

E) Okuma yetkisi sadece şifreleme ile giderilir

Doğru: B
Kısa gerekçe: “Read” yetkisinin etkisi, neyin okunduğuna bağlıdır. A/C/D/E aşırı basitleştirir.

6) “Yönetim olayları loglanıyor” ifadesi neden tek başına güçlü bir güvenlik argümanı değildir?

A) Yönetim olayları hiç loglanamaz

B) Yönetim olayları yalnızca manuel işlemleri kapsar

C) Görünürlük tespit değildir; kritik desenler için kural/korelasyon yoksa log varlığı alarm üretmeyebilir

D) Loglar her zaman gerçek zamanlıdır

E) Loglar sadece ücretli planlarda çalışır

Doğru: C
Kısa gerekçe: Log görünürlük sağlar; tespit, bağlamlı kural ve korelasyon ister. A/B/D/E yanlış veya genelleyicidir.

7) Bir kurumda veri düzlemi olaylarını sınırlı logluyor. İleri seviye raporlama için en doğru yaklaşım hangisidir?

A) “Log yoksa olay yoktur” yazmak

B) “Her şey sızdırılabilir” diye kesin hüküm vermek

C) Kapsam ve kör noktaları açıkça tanımlayıp, gecikme/retention/erişim kısıtlarını yazarak confidence düzeyiyle sonuçlandırmak

D) Logları kapatmayı önermek

E) Sadece yönetim olaylarına odaklanmak ve veri düzlemini yok saymak

Doğru: C
Kısa gerekçe: Belirsizliği doğru yönetmek ve kanıt zincirini kurmak gerekir. A/B aşırı kesin; D/E yanlış yönlendirme.

8) Federasyon temelli kimlik mimarilerinde “güven ilişkisi” en çok hangi varlık etrafında kritikleşir?

A) Sunucu CPU sayısı

B) Ağ kablosu kalitesi

C) Güven materyali/anahtar yönetimi ve imza doğrulama zinciri (kavramsal olarak)

D) Kullanıcı masaüstü duvar kâğıdı

E) Veri merkezinin şehir adı

Doğru: C
Kısa gerekçe: Federasyonda güven, imza/anahtar ve doğrulama zinciri etrafında kurulur. Diğer şıklar alakasızdır.

9) “Shadow Cloud IT” neden saldırı patikası açısından önemlidir?

A) Sadece maliyeti artırdığı için

B) Merkezi yönetişim dışındaki varlıklar çoğu zaman MFA/loglama/guardrail gibi kontrollerden yoksun kalır; zayıf halka oluşturur

C) Bulut sağlayıcıları bunu yasakladığı için

D) İnternet hızını düşürdüğü için

E) Veriyi otomatik olarak şifrelediği için

Doğru: B
Kısa gerekçe: Yönetilmeyen varlıklar, güvenlik standardının altına düşer ve giriş noktası oluşturabilir. A/C/D/E yanlış öncelik veya yanlış bilgi.

10) “Yöntem seçimi + sınırlar” açısından, bir bulut bulgusunu doğrularken en doğru strateji hangisidir?

A) En hızlı sonuç için yüksek etkili denemelerle başlamak

B) Önce düşük etkili sinyallerle kimlik/yetki ilişkisini kanıtlamak; gerekli olursa kapsamı dar, geri dönüş planlı ve minimum zarar prensibine uygun doğrulama yapmak

C) Tüm istisnaları geçici olarak kapatmak

D) Log gecikmesini dikkate almadan hemen sonuç yazmak

E) Sadece tek bir sinyale dayanarak “kesin” hüküm vermek

Doğru: B
Kısa gerekçe: İleri seviye tradecraft; OPSEC/etik sınır, operasyonel yük ve kanıt kalitesini birlikte optimize eder. A/C riskli; D/E kanıt standardına aykırı.

Bu Modülde Kazanılan Yetkinlikler

Bulutta saldırı yüzeyini, kimlik ve yetkilendirme ilişkileri üzerinden "graf" gibi okuyabildin.
Control Plane ve Data Plane ayrımını, riskin stratejikleştiği noktaları gerekçelendirmek için kullandın.
IAM yanlışlarını tekil bulgu olarak değil, ayrıcalık zinciri ve iş etkisi patikası olarak modelledin.
Hibrit kimlik köprülerinde varsayımları, istisnaları ve güven ilişkisi kırılmalarını sistematik değerlendirdin.
Loglama/görünürlük konusunu "var/yok" düzeyinden çıkarıp tespit/engelleme ve belirsizlik yönetimi perspektifiyle ele aldın.
Bulguları kanıt zinciriyle paketleyip, confidence dili ve yöntem seçimi maliyetlerini (noise/FP, operasyonel yük, etik sınır) rapora taşıdın.

MODÜL 15 — Container ve Kubernetes Saldırı Yüzeyi

Modül Teması

Container Escape

Capabilities, mount ve runtime kaçışları.

K8s RBAC

Role, ServiceAccount, token ve impersonation.

Supply Chain

Image, registry ve CI/CD zinciri saldırıları.

Container ve Kubernetes ekosisteminde "saldırı yüzeyi", tek tek sunuculardan çok; imaj tedarik zinciri, runtime izolasyonu, orkestrasyon kontrol düzlemi ve kimlik/yetki ilişkilerinin birleşiminden doğar. Özellikle Kubernetes, uygulamaları yönetirken aynı zamanda en kritik güven sınırını-API tabanlı kontrol düzlemi-oluşturur: küçük gibi görünen bir RBAC aşırılığı, fazla yetkili bir servis hesabı veya denetimsiz bir admission akışı, iş etkisine giden patikayı sessizce açabilir. Bu modül, "nasıl suistimal edilir?" ayrıntısına girmeden; saldırı patikası perspektifiyle okuma, iddia-kanıt-karşı kanıt disiplini ve raporlanabilir bulgu üretme standardı kazandırır.

Bu Modülde Hedeflenen Kazanımlar

Container izolasyonunun "küçük VM" olmadığını; paylaşılan kernel + runtime temas noktaları üzerinden doğru çerçeveleyebilmek.
Kubernetes risklerini "tekil ayar" gibi değil; kimlik → yetki → kontrol düzlemi → workload → iş varlığı zinciri olarak modelleyebilmek.
İmaj/registry/CI-CD hattında tedarik zinciri risklerini "genel korku" yerine izlenebilir kanıt ve kalite kapıları ile değerlendirebilmek.
RBAC, servis hesapları, secrets ve ağ politikaları gibi alanlarda doğrulama + karşı kanıt mantığıyla güvenilir bulgu yazabilmek.
Telemetri kısıtlarını (kör noktalar, gecikme, retention) hesaba katarak confidence dili ile "ne kadar eminiz, hangi koşulda fikrimiz değişir?" sorusunu yönetebilmek.
Aynı problemi çözmenin farklı yollarında yöntem seçimi + sınırlar (noise/FP, operasyonel yük, OPSEC/etik, minimum zarar) kararlarını olgunlaştırabilmek.

1) Container tehdit modeli: izolasyon varsayımlarını doğru kurmak

"Container = küçük VM" varsayımı, en pahalı yanlışlardan biridir. Container'lar çoğu zaman aynı host üzerinde aynı kernel'i paylaşan izole süreçlerdir; izolasyon, katmanlı ama "mutlak" değil "tasarımsal"dır. İleri seviyede hedef, bu varsayımları ezberden değil; kanıtlayarak/çürüterek yönetmektir.

1.1. İmaj-runtime-kernel ayrımı: saldırı yüzeyi nerede başlar?

İmaj (image): "Ne çalıştırıyoruz?" sorusunun cevabı. İçerik bütünlüğü ve köken doğrulama burada başlar.
Runtime: İmajın hangi ayrıcalıklarla, hangi izolasyon/bağlantı noktalarıyla çalıştığı katman. Yetkiler, mount'lar, capability'ler, host temasları burada anlam kazanır.
Paylaşılan kernel: Container'ın izolasyon iddiasının sınırını çizen gerçek. Kernel paylaşımı, bazı risklerin "workload içinde" değil "host sınırında" büyümesine yol açar.

Örnek: Uydurma bir kurum, müşteri verisi işleyen servisi "container içinde" çalıştırdığı için güvenli sayıyor. İleri seviye inceleme "container var" diye rahatlamaz; servisin hangi kimlikle çalıştığını, hangi ayrıcalıklarla host'a temas ettiğini, hangi politikaların bunu sınırladığını çıkarır; "izolasyon güçlü" iddiasını destekleyen ve çürüten sinyalleri birlikte listeler.

Dikkat: "Container güvenli değil" gibi genellemeler yayınlanabilir raporda zayıf kalır. Güçlü yaklaşım: hangi kontrol eksikliği hangi patikayı mümkün kılıyor? İzolasyon iddiasını ölçülebilir bulgulara (politika, yetki, konfigürasyon, denetim izi) bağlamadan kesin hüküm verme.

1.2. "Değerli varlıklar" listesi: pod'lardan fazlası

Container/Kubernetes ortamında saldırı patikaları çoğu zaman şu varlıkların çevresinde kurulur:

Registry: Kim imaj yazabilir/çekebilir? Bütünlük/köken doğrulama var mı?
CI/CD ve build altyapısı: "Üretim cluster'ına giden yol" üzerindeki en kritik güven halkası.
Secrets ve kimlik materyali: Uygulamanın iş yapmasını sağlayan anahtarlar, token'lar, sertifikalar.
Kubernetes API / kontrol düzlemi: Değişiklik, yetki ve politika kararlarının merkezi.
Node katmanı: Workload'ların koştuğu zemin; burada güven bozulursa etki büyür.

İpucu: Varlık envanterini "sunucu listesi" gibi değil, kimlik ve yetki akışı gibi düşün: Workload kim, neyi, hangi koşulda yapabiliyor? Bu yaklaşım, Modül 14'teki kimlik-merkezli okuma ile doğal biçimde birleşir.

1.3. Doğrulama döngüsü: iddiayı kanıta çevirmek

İleri seviye doğrulama aynı anda iki iş yapar:

— İddiayı destekleyen kanıtı toplar (konfigürasyon/politika/ilişki).
— Karşı kanıt arar (kısıtlar, guardrail'ler, denetimler, görünürlük).

Bunu "kanıt zinciri" gibi düşün: gözlem → yorum → sonuç ayrımını korursan hem raporun denetlenebilir olur, hem de "fazla kesin" cümlelerin maliyetini düşürürsün.

1.4. Ayrıcalık ve breakout riskini "sınıf" olarak okumak

Container güvenlik modelinde izolasyon; isim alanları (namespaces), kaynak sınırları (cgroups), yetenek setleri (capabilities) ve politika/guardrail'lerle güçlenir. Bazı konfigürasyon sınıfları izolasyon varsayımını zayıflatır:

Host ile temasın artması: Paylaşımlar/mount'lar, host isim alanlarına yakınlık, cihaz erişimi gibi temas noktaları.
Ayrıcalıkların artması: "Gereksiz geniş" yetki ve uzun ömürlü istisnalar.
Denetimin azalması: Politika kapsam dışı alanlar, zayıf istisna yönetimi, yetersiz audit izi.

Örnek: Uydurma bir ekip, "sorunları hızlı çözmek" için geliştirici ekibe geniş ayrıcalıklarla çalışan bir debug bileşeni vermiş. İleri seviye rapor bunu sadece "kötü" diye etiketlemez; iş gerekçesini doğrular, kapsamı ve süreyi inceler, telafi edici kontrolleri sorar ve "kalıcı istisna mı, kontrollü geçici süreç mi?" ayrımını kanıtlarla görünür kılar.

2) Supply chain: imaj bütünlüğü, registry ve CI/CD hattı

Container güvenliği çoğu zaman runtime'dan önce kaybedilir: "ne koşuyoruz?" sorusu net değilse, en iyi runtime kontrolleri bile yetersiz kalabilir.

2.1. Etiket (tag) güveni mi, içerik güveni mi?

Etiketler operasyonda pratik olsa da ileri seviyede "etikete güven" refleksi sorgulanır: etiket değişebilir, içerik drift edebilir. Yayınlanabilir raporda değer yaratan şey:

Köken ve üretici kimliği izlenebilir mi?
Değişiklik onayı ve istisna yönetimi var mı?
Bütünlük ve provenance kontrolleri (kurumun seçtiği yöntemle) işletiliyor mu?

Örnek: "Resmi imaj kullanıyoruz" deniyor. İleri seviye yaklaşım, "resmi" kelimesini ölçülebilir tanıma çevirir: resmi kaynak listesi, onay prosedürü, istisna mekanizması, denetlenebilir kanıt var mı?

Dikkat: Supply chain bulgularında en büyük tuzak "varsayımsal korku" yazmaktır. "İmaj zehirlenebilir" geneldir; asıl değer, kurumun hangi kalite kapılarını uyguladığını/uygulamadığını ve bunun iş etkisine nasıl bağlandığını gösterebilmektir.

2.2. SBOM, zafiyet taraması ve kabul kriterleri: FP/noise maliyeti

Tarama araçları "sinyal üretir"; ama sinyali bulguya çevirmek için:

Kabul kriterleri (hangi sınıf bulgu, hangi şartlarda "bloklayıcı"),
False positive yönetimi,
Zaman uyumu (hangi sürüm ne zaman üretime girdi),
İstisnaların görünürlüğü

gerekir. Burada "mükemmel tarama" değil, işletilebilir doğrulama hedeflenir.

2.3. Registry yetkisi: dağıtım noktasının yönetişimi

Registry, tedarik zincirinin dağıtım boğazıdır. İleri seviye değerlendirme, "registry güvenli" iddiasını şu sorularla test eder:

Yazma/çekme yetkileri kimlerde? (insan + servis kimlikleri)
İmaj imzalama/bütünlük doğrulama akışı var mı?
Üretim ortamına giden imaj akışı üzerinde bağımsız kontrol noktaları var mı?

Minimum zarar ilkesi burada kritiktir: Üretime etki edecek müdahaleler yerine, çoğu zaman yetki ve süreç zayıflığını kanıtlayan izlenebilir delil (politika, audit izi, değişiklik kaydı, onay zinciri) rapor için yeterlidir.

2.4. CI/CD entegrasyonu: "cluster'a giden en kısa yol"

CI/CD sistemleri, üretim deploy yetkileri ve kimlik materyali nedeniyle yüksek değerli varlıktır. İleri seviye rapor, "CI/CD'de erişim var" demekle kalmaz:

Erişimin kapsamını (hangi ortam, hangi namespace/cluster),
Kimlik materyalinin yaşam döngüsünü (rotasyon, saklama, erişim denetimi),
Telafi edici kontrolleri (ayrıcalık azaltma, onay kapıları, izleme) kanıt zincirinde gösterir.

İpucu: Bir kontrolün varlığı kadar işletimi önemlidir. Kâğıt üstünde mükemmel bir onay süreci, pratikte "acil iş" istisnalarıyla deliniyorsa bulgu "kontrol yok" değil, kontrol işletimi zayıf sınıfına girer. Bu ayrım, Modül 17'de aksiyonların gerçekçi yazılmasını sağlar.

3) Kubernetes kontrol düzlemi: kimlik ve yetki zincirinin merkezi

Kubernetes'te kritik hedef çoğu zaman "tek pod" değil; kümeyi yöneten kontrol düzlemi ve onun yetkilendirme mantığıdır. Burada amaç, komut tarif etmek değil; neye bakılır, nasıl doğrulanır, hangi karşı kanıt aranır disiplinini kurmaktır.

3.1. Kimlik doğrulama → RBAC → kapsam: izin kümelerinden patikaya

Kubernetes yetkisi, pratikte şu sorulara cevap verir:

Kim? (kimlik)
Ne yapabilir? (RBAC)
Nerede ve neye? (namespace, kaynak türleri, fiiller)

İleri seviyede risk, çoğu zaman tek bir "çok geniş izin" değil; birleşince anlam kazanan izin kümeleridir. Raporun kalitesi, izinleri listelemekten ziyade şu zinciri kurabilmektir: kimlik → izin kümesi → kontrol düzlemi etkisi → workload etkisi → iş varlığı etkisi.

Örnek: "Bu servis hesabı sadece deploy için geniş erişime sahip; risk yok" deniyor. İleri seviye yaklaşım:

İş gerekçesini doğrular,
Yetkinin gerçek kapsamını ve kullanım şeklini kanıtlar,
Telafi edici kontrolleri (policy, admission, audit, ayrıştırma) değerlendirir,
Sonucu confidence ile yazar: Ne kadar eminiz? Neye dayanıyoruz? Hangi şartlarda fikrimiz değişir?

3.2. Servis hesapları: "sessiz" ve sürekli kimlikler

Workload kimlikleri, insan oturumundan farklıdır: daha sessiz, daha sürekli ve çoğu zaman otomasyonla taşınır. Bu yüzden ileri seviye değerlendirme:

Yetkinin "iş gereksinimi" ile uyumunu,
Gözden geçirme/daraltma disiplinini,
Yetki doğrulama mekanizmalarını (Kubernetes'in kendi yetki değerlendirme akışları) merceğe alır.

Burada yöntem seçimi önemlidir: Bazı doğrulamalar yalnızca dokümantasyon/politika/audit izi ile düşük riskle yapılabilir; bazıları ise operasyonel yük doğurur. Minimum zarar ilkesinden sapmadan kanıt üretmek esastır.

3.3. Admission, policy motorları, CRD/operator ekosistemi: "policy var" yetmez

Kontrol yalnızca RBAC değildir. Admission katmanı, policy-as-code motorları, custom resource'lar ve operator mantığı; cluster'ın "hangi sınıf workload'a izin verdiğini" belirler. İleri seviye kontrol soruları:

Politika hangi risk sınıflarını kapsıyor, hangilerini kapsayamıyor?
İstisnalar nasıl yönetiliyor (süre, kapsam, görünürlük, geri alma)?
Denetim izi üretilebiliyor mu; olay sonrası tekrar üretilebilirlik var mı?

Dikkat: "Policy var" ifadesi tek başına güvenlik kanıtı değildir. Kapsam + istisna yönetimi + denetim izi net değilse, raporda kesinlik yerine doğru kalibre edilmiş belirsizlik gerekir.

3.4. Secrets: encoding ile encryption'ı karıştırmamak

Kubernetes dünyasında secrets çoğu zaman "iş yürüsün" diye büyür. Burada iki kritik ayrımı net tutmak gerekir:

Encoding (Base64): Kubernetes Secret nesnelerindeki veri alanı pratikte base64 ile temsil edilir; bu, gizlilik sağlamaz.
At-rest encryption (etcd/depoda şifreleme): Cluster verisi çoğu dağıtımda etcd'de tutulur; at-rest şifreleme, açıkça yapılandırılan bir kontrol setidir ve yoksa hassas veriler depoda düz metin olarak kalabilir.

Bu başlıkta ileri seviye raporlama, "Secret bulundu" demekle bitmez:

Secret yaşam döngüsü (üretim, dağıtım, rotasyon),
Erişim modeli (hangi kimlikler görebiliyor/kullanabiliyor),
Depo güvenliği ve şifreleme politikası,
Kullanım izleri ve retention

kanıt zincirinde anlatılır.

4) Workload ve runtime yanlışları: küçük konfigürasyon, büyük patika

Workload konfigürasyonları "küçük ayar" gibi görünür; ama patikanın pratik halkaları çoğu zaman burada oluşur.

4.1. Security context ve ayrıcalık ekonomisi

İleri seviye bakış, tek tek ayarlardan çok risk sınıflarını okur:

Host temasını büyüten seçimler,
Gereksiz ayrıcalık genişlemeleri,
Denetimi azaltan kör noktalar.

En güçlü rapor dili: "şu ayar kötü" değil; "bu seçim şu güven varsayımını zayıflatıyor; şu guardrail yoksa iş etkisine giden patika açılıyor" şeklindedir.

4.2. Sidecar modeli: aynı pod, paylaşılan kader

Sidecar deseninde bir pod içinde birden fazla container aynı ağ/volume bağlamını paylaşabilir. Bu, operasyonel fayda sağlarken ek bir saldırı yüzeyi de getirir: yardımcı bileşenin (proxy/log agent vb.) zayıflığı, ana uygulamanın veri/trafik bağlamına temas edebilir. İleri seviye değerlendirme, sidecar'ları "ikincil" saymaz; paylaşılan bağlam üzerinden riskin yayılımını analiz eder.

4.3. Ağ segmentasyonu ve multi-tenancy: teknikten çok yönetişim

Kubernetes'te ağ segmentasyonu "var/yok" gibi konuşulsa da ileri seviye soru şudur:

Segmentasyonun kapsamı nedir, istisnalar nerede birikiyor?
Çoklu ekip/tenant sınırları net mi; kim neyi yönetiyor?
Bu sınırlar denetlenebilir mi?

Özellikle namespace'ler organizasyonel sınırdır; tek başına sert bir güvenlik izolasyonu garantilemez. Multi-tenancy güvenliği için ek kontroller gerekir.

4.4. Cluster → Cloud patikaları: kimlik perimetresi genişler

Modern Kubernetes ortamları çoğu zaman bulut servisleriyle iç içedir. Bu nedenle bir zayıflık cluster içinde başlayıp bulut kimlik/izinlerine temas edebilir. Modül 14'teki yaklaşımı burada tekrar kullanırsın: kimlik perimetresi, kontrol düzlemi, yetki zinciri ve görünürlük birlikte okunur.

5) Telemetri, tespit ve kanıt paketleme: bulguyu savunma değerine çevirmek

İleri seviyede amaç "ilginç zafiyet" bulmak değil; bulguyu denetlenebilir, tekrar üretilebilir ve aksiyonlanabilir hale getirmektir.

5.1. Görünürlük katmanları ve kör noktalar

Container/Kubernetes ortamında telemetri genellikle çok katmanlıdır:

Kontrol düzlemi/audit izleri,
Workload yaşam döngüsü ve değişiklik izleri,
Runtime/host olay izleri,
Merkezi log/SIEM korelasyonları (varsa).

Her katmanda kör noktalar olabilir: gecikme, retention yetersizliği, kapsam dışı alanlar, erişim kısıtları. İleri seviye rapor, bunu "bahane" değil confidence kalibrasyonu olarak kullanır.

5.2. Kanıt standardı: tek ekran değil, izlenebilir zincir

Güçlü bir kanıt paketi şunları içerir:

Kaynak-iddia-kanıt ayrımı (ne gördük / ne yorumladık / ne sonuç çıkardık),
Zaman uyumu (değişiklik sırası),
Çapraz doğrulama (en az iki farklı sinyal tipi),
Belirsizlik yönetimi (erişim/retention sınırları, veri kapsamı).

5.3. Bulgudan aksiyona: kabul kriterleri ve Purple Team hattı

Bir bulguyu "yapılacaklar listesi"ne çevirmek istiyorsan, her bulgu için:

Hangi kontrol/politika eklenecek?
Nasıl doğrulanacak?
FP/noise maliyeti nasıl yönetilecek?

gibi kabul kriterleri yazmak etkiyi artırır. Bu yaklaşım, Modül 12'deki "tespit gerçekliği" ve Modül 17'deki profesyonel raporlama/purple teaming çizgisine doğrudan bağlanır.

Terimler Sözlüğü

Terim	Açıklama
Kubernetes	Container’ları orkestre eden kontrol düzlemi; API ve politika katmanı kritik saldırı yüzeyi oluşturur
Docker	Container imajı ve runtime ekosisteminde yaygın platform; tedarik zinciri ve çalışma bağlamı açısından önemli
Container	İzole süreç çalıştırma yaklaşımı; izolasyon çoğu zaman host kernelini paylaşır
Image (İmaj)	Uygulamanın paketlenmiş/artifact hali; supply chain riskleri burada başlar
Registry	İmajların depolandığı ve dağıtıldığı sistem; kimlik ve bütünlük kontrolleri kritiktir
OCI	Container imaj ve runtime standartları ekosistemi (genel çerçeve)
Supply Chain	Yazılımın üretimden dağıtıma kadar geçtiği zincir; artifact bütünlüğü ve köken doğrulama içerir
CI/CD	Otomatik build ve dağıtım hattı; yetki ve değişiklik kontrol noktaları barındırır
SBOM	Yazılım bileşen envanteri; bağımlılık görünürlüğü sağlar
Control Plane	Yönetim/API katmanı; konfigürasyon ve yetki değişimleri burada gerçekleşir
Data Plane	Uygulama trafiği ve veri işleme katmanı; servis-özel görünürlük sınırlamaları olabilir
Pod	Kubernetes’te workload çalışma birimi; bir veya daha fazla container içerir
Namespace	Mantıksal ayrım alanı; çoklu tenant ve segmentasyon tartışmalarında temel ama tek başına sert güvenlik sınırı değildir
RBAC	Rol tabanlı erişim kontrolü; “kim, neyi, hangi kapsamda yapabilir?” sorusunu belirler
Service Account	Workload kimliği; insan oturumlarından daha “sessiz” ve sürekli olabilir
Secret	Hassas veri (anahtar/parola/sertifika vb.) taşıyan nesne; yaşam döngüsü ve erişim modeli kritiktir
Admission Controller	API’ye gelen istekleri politika/kuralla değerlendiren kontrol katmanı
etcd	Kubernetes durum bilgisinin tutulduğu kritik bileşen (kavramsal)
Multi-tenancy	Aynı altyapıyı birden çok ekip/tenant’in paylaşması; yönetişim ve sınır tanımı kritik
Sidecar	Ana container ile aynı pod içinde çalışan yardımcı container; paylaşılan bağlam nedeniyle ek yüzey oluşturur
Telemetry	Log/sinyal verileri; görünürlük üretir ama tek başına tespit/engelleme değildir
Retention	Logların saklama süresi; kanıt üretiminde confidence’ı doğrudan etkiler
Noise / False Positive	Gürültü/yanlış pozitif; tespit kuralı ve tarama tasarımında operasyonel maliyet unsurudur
Container Breakout	İzolasyon sınırının aşılmasıyla host bağlamına temas edebilme riski (kavramsal)

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir ekip “Container kullanıyoruz, izolasyon sorunumuz yok” diyor. İleri seviye değerlendirmede en doğru ilk karşılık hangisidir?

A) Container izolasyonu her zaman VM seviyesindedir

B) İzolasyon varsayımları kanıtlanmalıdır; runtime temas noktaları ve telafi edici kontroller görülmeden kesin hüküm verilmez

C) İzolasyon yalnızca ağ segmentasyonuyla ilgilidir

D) Container varsa tedarik zinciri riski yoktur

E) Kubernetes varsa izolasyon otomatik olarak tamdır

Doğru: B
Gerekçe: Container izolasyonu katmanlı ve tasarımsaldır; kanıt + karşı kanıt gerekir. A/E aşırı genelleme, C/D eksik çerçevedir.

2) “Resmi imaj kullanıyoruz” ifadesini kanıt standardında rapora taşımak için en kritik ek parça hangisidir?

A) İmajın popülerliği ve yıldız sayısı

B) Etiket adını yazmak (ör. “latest”)

C) Köken/provenance, onay–istisna süreci, izlenebilirlik ve belirsizlik sınırlarının açık yazımı

D) İmaj boyutunun küçük olması

E) İmajın performans testleri

Doğru: C
Gerekçe: “Resmi” iddiası ölçülebilir tanıma dönmeli; süreç ve izlenebilir kanıt gerekir. Diğerleri kanıt kalitesini artırmaz.

3) Kubernetes risklerini “tekil ayar” yerine “saldırı patikası” olarak ele almayı en doğru yansıtan seçenek hangisidir?

A) Bir YAML satırını “kötü” diye işaretlemek

B) Kimlik → RBAC kapsamı → kontrol düzlemi etkisi → workload/iş varlığı etkisi zincirini kurup her halkayı bağımsız sinyallerle doğrulamak

C) Her bulguyu otomatik kritik yazmak

D) Sadece runtime’ı incelemek

E) Sadece uygulama koduna odaklanmak

Doğru: B
Gerekçe: İleri seviye tradecraft ilişki grafı ve doğrulama disipliniyle çalışır; diğerleri tek boyutlu kalır.

4) Bir servis hesabının “deploy için geniş yetkili” olduğu söyleniyor. En doğru ileri seviye yaklaşım hangisidir?

A) İddiayı kabul edip konuyu kapatmak

B) Yetkileri listeleyip yorum yapmamak

C) İş gerekçesini doğrulamak, yetki kapsamını ve kullanım bağlamını kanıtlamak, telafi edici kontrolleri ve karşı kanıtı değerlendirmek; sonucu confidence diliyle yazmak

D) Hemen tüm yetkileri kaldırmayı talep etmek

E) Konuyu kapsam dışı saymak

Doğru: C
Gerekçe: Kanıt standardı + risk-iş dengesi + belirsizlik yönetimi birlikte taşınır. A/B/D/E gerçekçilik ve kaliteyi düşürür.

5) RBAC analizinde “list” türü izinlerin “get” türü izinlerden farklı risk üretmesinin en iyi açıklaması hangisidir?

A) Fark yoktur; ikisi de aynı şeyi yapar

B) “List” keşfi ölçekler: isimleri/boyutu görünür kılar, hedeflemeyi kolaylaştırır; “get” çoğu zaman daha dar bağlam gerektirir

C) “Get” silmeye izin verir; o yüzden daha tehlikelidir

D) “List” sadece sayıyı gösterir, keşif değeri yoktur

E) “Get” otomatik şifre çözer

Doğru: B
Gerekçe: İleri seviye risk okumasında keşif yetkileri patika kurmayı hızlandırır; diğer seçenekler kavramsal olarak hatalıdır.

6) “Policy var” ifadesinin tek başına güçlü güvenlik kanıtı sayılmamasının en doğru nedeni hangisidir?

A) Policy’ler hiçbir zaman işe yaramaz

B) Kapsam, istisna yönetimi ve denetim izi net değilse pratikte güven üretmeyebilir; karşı kanıt aranmalıdır

C) Policy sadece performansı artırır

D) Policy yalnızca eğitim ortamlarında kullanılır

E) Policy sadece ağ trafiğini kontrol eder

Doğru: B
Gerekçe: Kontrolün varlığı değil, işletimi ve denetlenebilirliği güven üretir.

7) Bir raporda “Secrets base64 ile kodlanmış” bulgusu yazılacak. En doğru, yayınlanabilir ve doğruluk riski taşımayan çerçeve hangisidir?

A) “Base64 şifrelemedir; secrets zaten güvende”

B) “Base64 gizlilik sağlamaz; ayrıca depoda şifreleme ve erişim modeli değerlendirilmeden etki kesinleştirilemez”

C) “Secrets gereksizdir; kaldırılmalı”

D) “Secrets yalnızca uygulama içi meseledir; cluster güvenliğini etkilemez”

E) “Base64 varsa veri sızıntısı kesin olmuştur”

Doğru: B
Gerekçe: Encoding ≠ encryption; gerçek risk, erişim modeli + at-rest koruma + audit/görünürlük ile birlikte değerlendirilir.

8) Namespace’lerin çoklu ekip/tenant ortamında tek başına “sert güvenlik sınırı” sayılmamasının en doğru sonucu hangisidir?

A) Namespace’ler işe yaramaz; tamamen kaldırılmalı

B) Ek kontroller (ağ politikaları, RBAC ayrıştırma, policy/admission, audit) olmadan izolasyon varsayımı kurmak risklidir; yönetişim kanıtlanmalıdır

C) Namespace varsa veri otomatik şifrelenir

D) Namespace izolasyonu yalnızca performansla ilgilidir

E) Namespace her koşulda ağ trafiğini engeller

Doğru: B
Gerekçe: Namespace organizasyonel sınırdır; güvenlik izolasyonu için ek mekanizmalar gerekir.

9) “Log var” deniyor; fakat “tespit var” iddiası tartışmalı. En doğru ifade hangisidir?

A) Log varsa engelleme de vardır

B) Alarm yoksa hiçbir şey olmamıştır

C) Görünürlük, tespit ve engelleme farklıdır; tespit için bağlamlı korelasyon ve kabul kriterleri gerekir; gecikme/retention sınırları confidence’ı etkiler

D) Tespit sadece uygulama loglarıyla yapılır

E) Engelleme olmadan görünürlük olmaz

Doğru: C
Gerekçe: İleri seviye raporlama, telemetri kısıtlarını confidence diline çevirir; diğerleri yanlış genellemedir.

10) Bir bulguyu “kanıt standardında” paketlemek ve aynı zamanda SOC’u yormamak için en iyi yaklaşım hangisidir?

A) Maksimum tarama yapıp her şeyi kritik raporlamak

B) Tek bir sinyale dayanıp kesin sonuç yazmak

C) Önce düşük etkili/izlenebilir kanıtla iddiayı güçlendirip, yalnızca gerektiğinde dar kapsamlı doğrulamalara geçmek; zaman uyumu + çapraz doğrulama + belirsizlik yönetimiyle yazmak

D) Denetim izlerini geçici kapatmak

E) Belirsiz kaldığında raporlamamak

Doğru: C
Gerekçe: Yöntem seçimi, operasyonel yük ve kanıt kalitesi birlikte optimize edilir; A/B/D/E ya riskli ya da kalitesizdir.

Bu Modülde Kazanılan Yetkinlikler

Container izolasyonunu "VM gibi" varsaymak yerine, paylaşılan kernel + runtime temas noktaları üzerinden kanıtlayarak değerlendirme disiplini.
Kubernetes risklerini tekil ayarlardan çıkarıp kimlik-RBAC-kontrol düzlemi-workload-iş etkisi zinciriyle modelleme.
Supply chain tarafında "genel korku" yerine izlenebilir süreç, kalite kapıları ve kanıt ile raporlama.
Servis hesapları, secrets ve admission/policy alanlarında doğrulama + karşı kanıt yaklaşımıyla güvenilir bulgu üretme.
Telemetride görünürlük/tespit/engelleme ayrımını netleştirip kör noktaları confidence diliyle yönetme.
Yöntem seçimini noise/FP, operasyonel yük ve minimum zarar sınırlarıyla birlikte yapıp bulguyu aksiyonlanabilir hale getirme.

MODÜL 16 — AI Red Teaming ve LLM Güvenliği

>

Modül Teması

Prompt Injection

Direct/indirect injection ve context poisoning.

Jailbreak & Abuse

Policy bypass, sensitive data ve misuse senaryoları.

LLM App Güvenliği

RAG, agent, tool-use ve veri sızıntısı yüzeyi.

Kurumsal LLM tabanlı çözümler artık "tek bir model" değildir; RAG ile veri kaynaklarına bağlanan, araç/aksiyon katmanıyla sistemlerde işlem başlatabilen, kimlik-yetki zinciriyle ayrıcalık taşıyan ve denetim izi üreten bütünleşik bir sistemdir. Bu modülde AI red teaming'i "jailbreak denemek" gibi dar bir çerçeveden çıkarıp; saldırı patikası mantığıyla iddia → kanıt → karşı kanıt disiplinine oturtacağız. Hedef; uygulanabilir saldırı tarifleri vermeden, riskin nerede doğduğunu, nasıl doğrulanacağını, belirsizliğin nasıl yönetileceğini ve bulgunun savunma tarafında nasıl aksiyona dönüşeceğini ileri düzeyde öğretmektir.

Bu Modülde Hedeflenen Kazanımlar

LLM/agent sistemlerinde saldırı yüzeyini "modelin kendisi" yerine veri + araç + kimlik/yetki + kontrol düzlemi zinciri olarak modellemek.
Prompt injection (doğrudan/dolaylı), hassas bilgi ifşası, yetkisiz eylem, RAG bütünlüğü ve supply chain risklerini kanıt standardında bulguya dönüştürmek.
Olasılıksal (non-deterministic) davranış nedeniyle doğrulamada tekrar üretilebilirlik, izlenebilirlik ve confidence dilini doğru kurmak.
"Guardrail var" gibi iddiaları; kapsam, istisna, kırılma modu, denetim izi ve yetkilendirme ayrımı üzerinden değerlendirmek.
Bulguları OWASP LLM Top 10 gibi taksonomilerle hizalayıp, iş etkisi + risk iştahı bağlamında raporlamak.

1) AI red teaming: "model testi" değil, "sistem testi"

AI red teaming yalnızca modelin "uygunsuz içerik üretip üretmediğini" ölçmez. Asıl kırılma modları; modelin bağlandığı dünya ile (doküman depoları, bilet sistemleri, e-posta, kod depoları, bulut servisleri, iş akışları) kurduğu ilişkide ortaya çıkar. Risk, "model yanlış konuştu"dan çok şu biçimlerde görünür:

yanlış şeye erişti,
yanlış eylemi tetikledi,
hassas veriyi yanlış bağlamda taşıdı,
denetim izini zayıflattı ya da maliyet/iş yükünü kontrolden çıkardı.

Bu yüzden ileri seviye değerlendirme şu sorularla başlar: Sistem hangi varlıklar üzerinde karar veriyor ya da işlem başlatıyor? Bunu hangi kimlikle ve hangi kanıt iziyle yapıyor?

Örnek: Bir kurum iç destek taleplerini özetleyen bir asistan kullanır. "Bilgi tabanını özetleme" ile "bileti kapatma/etiketleme" aynı arayüzde görünse bile güven sınırları farklıdır: ilki bilgi ifşası riskine, ikincisi yetkisiz etki riskine açılır.

İpucu: Modül 2'deki tehdit modelleme yaklaşımını burada yeniden okursun: varlık-aktör-güven sınırı-başarısızlık modu. "Model ne dedi?" sorusu tek başına yetmez; "model neye erişti ve neyi değiştirebildi?" sorusu ölçüttür.

2) Mimari saldırı yüzeyi: veri akışı, güven sınırları ve kontrol düzlemi

Kurumsal LLM çözümlerinde saldırı yüzeyi tek bir "prompt kutusu" değildir. Genellikle aşağıdaki katmanların birleşiminden doğar:

2.1. İstem/orkestrasyon katmanı (prompting & orchestration)

Sistem yönergeleri, politika metinleri, rol ayrımları, şablonlar ve "hangi durumda hangi araca gidileceği" gibi karar mantığı burada şekillenir. Bu katman zayıfsa, aşağı katmanlar doğru olsa bile sistem yanlış işi doğru şekilde yapabilir.

2.2. Bağlam katmanı (context): oturum, geçmiş, bellek ve retrieved parçalar

Kullanıcı girdisi, oturum geçmişi, kalıcı/yarı kalıcı "memory", RAG ile getirilen doküman parçaları aynı "bağlam havuzu"nda buluşur. Bu havuzda kritik soru şudur: Veri ile talimat güvenilir biçimde ayrılıyor mu?

2.3. RAG / konektörler: erişim, kapsam ve "confused deputy"

RAG, modelin kurumsal verilere erişmesini sağlar; fakat en riskli yerlerden biridir. Sık görülen kırılma modu, "kullanıcı yetkisi" ile "servis kimliği" arasındaki uyumsuzluktur:

Arama/çekme işlemi geniş yetkili bir servis hesabıyla yapılır,
Kullanıcıya dönmeden önce kaynak seviyesinde yetkilendirme/filtreleme zayıftır,
Sonuçta model, kullanıcının görmemesi gereken içeriği "yardım" etiketiyle taşıyabilir.

Bu durum, güvenlik literatüründe confused deputy (şaşkın vekil) problemine benzer: sistem, iyi niyetli vekil rolüyle yanlış kişiye yanlış şeyi götürür.

2.4. Araç/aksiyon katmanı (tools, function calling, agent'lar): "çıktı"dan "etki"ye

Agent'lar, LLM'in öneri üretmekten çıkıp eylem başlatabildiği yerdir. Risk zinciri çoğu zaman şöyledir:

model kararı → araç çağrısı → gerçek sistem değişikliği → geri dönüş maliyeti

Bu zincirde "insan onayı var" demek tek başına güvenlik kanıtı değildir; onayın anlamlı olması gerekir (bağlam, beklenen etki, alternatif, geri alma bilgisi, gerekçe izi).

2.5. Kimlik ve yetkilendirme: least privilege, kapsam ve izlenebilirlik

"Model güvenli" iddiası, kimlik-yetki tasarımından bağımsız düşünülemez. Araçlar ve servis kimlikleri least privilege ile tanımlanmadıysa, en iyi guardrail bile yetkilendirme kontrolünün yerini tutmaz.

2.6. Gözlemlenebilirlik: prompt/response logları, tool çağrıları ve saklama süresi

AI güvenliğinde "kanıt standardı" denetim iziyle güçlenir: hangi girdiler/bağlam parçaları kullanıldı, hangi araç çağrıları yapıldı, parametreler neydi, hangi kullanıcı/servis kimliği etkindi, loglar ne kadar süre saklanıyor?

Dikkat: "Model güvenli, çünkü filtre/guardrail var" cümlesi ileri seviye raporda zayıftır. Guardrail çoğu zaman davranış kontrolü sağlar; yetkilendirme ise kimlik ve kaynak seviyesinde doğrulanabilir olmalıdır.

3) Risk sınıfları: OWASP LLM Top 10 ile hizalama ve saldırı patikası okuması

Taksonomiler "liste ezberletmek" için değil; bulguları tutarlı yönetebilmek içindir. OWASP 2025 LLM Top 10, riskleri hem LLM hem uygulama yaşam döngüsü boyunca ele alır. Aşağıda her başlık, red team perspektifinde "neye bakılır, ne kanıt olur, hangi karşı kanıt aranır, sınır nerede başlar" mantığıyla işlenmiştir.

3.1. Prompt injection (doğrudan / dolaylı)

Doğrudan prompt injection, kullanıcı girdisinin sistem politikasını bastırmasıdır. Dolaylı prompt injection ise modelin işlediği dış içeriklerin (doküman, web içeriği, e-posta metni gibi) içine gömülü talimat benzeri metinlerin orkestrasyonu saptırmasıdır.

İleri seviye çıkarım şudur: Bu bir "metin oyunu" değil, güven sınırı hatasıdır. Güvenli tasarım tek bir prompt kuralına yaslanmaz; katmanlı kontroller gerektirir:

veri/talimat ayrımı (bağlam izolasyonu),
tool/aksiyon için allowlist ve onay,
ayrıcalık azaltma (least privilege),
yüksek riskli eylemler için ek doğrulama.

Kanıt standardı: "Modeli kandırdım" ifadesi yerine, hangi güven sınırının ihlal edildiği ve bunun hangi etkileri doğurduğu gösterilir. Karşı kanıt: guardrail kapsamı, istisnalar, log/retention kısıtları, eylem onaylarının anlamlılığı, aynı iddianın farklı varyasyonlarda tutarlılığı.

İpucu: Dolaylı enjeksiyon iddiasında, "model talimatı takip etti" gözlemini tek başına büyütme. Asıl soru: talimat, veri olarak mı taşınmalıydı; yoksa eylem/karar katmanını mı etkiledi? Bu ayrımı, denetim izleri ve yapılandırma parçalarıyla güçlendir.

3.2. Sensitive information disclosure (hassas bilgi ifşası)

Hassas veri ifşası iki katmanda büyür:

Bağlam sızıntısı: oturum geçmişi, sistem yönergeleri, retrieved parçalar, gizli politika metinleri.
Yetkilendirme uyumsuzluğu: kullanıcı adına değil, geniş yetkili servis kimliğiyle erişim.

Kanıt standardı iki aşamalıdır:

— "Hassas veri göründü" (gözlem)
— "Bu veri bu kullanıcı için yetkisiz mi?" (yetki modeli + karşı kanıt)

Karşı kanıt arama: maskeleme/anonimleştirme, erişim politikaları, retrieval filtresi, log kapsamı, veri sınıflandırması ve saklama politikaları.

3.3. Supply chain (model, veri, bağımlılıklar)

LLM güvenliği, klasik yazılım tedarik zinciri risklerini taşır; buna ek olarak model davranışı da sürümle değişebilir. Risk kaynakları:

model/servis sağlayıcı bağımlılığı, sürüm değişimleri,
fine-tuning verisinin güvenilirliği,
orkestrasyon kodu, şablonlar, eklentiler/bağımlılıklar,
değerlendirme setlerinin manipülasyonu (ölçümü "iyi gösterme" riski).

Burada MITRE'ın AI odaklı tehdit çerçeveleri (ör. ATLAS) saldırgan bakışıyla sınıflandırma için referans olabilir.

3.4. Data and model poisoning (özellikle RAG bağlamında)

Kurumsal pratikte en sık görülen senaryo, "modelin eğitim verisini zehirlemek"ten çok, RAG'in beslendiği bilgi tabanını bozmak ve sistemin güvenilirlik varsayımlarını kırmaktır.

Kırılma modları:

Yetkili kaynak ile yetkisiz/rasgele kaynak ayrımının zayıflığı,
versiyon/güncellik yanılsaması (eski dokümanın yeni gibi sunulması),
doküman bütünlüğü (izinsiz değişiklik),
"embedding/veri hattı" üzerinde zayıf kontrol (hangi içerik vektörleşiyor, hangi metadata ile filtreleniyor).

Bu başlık, pratikte "bilgi bütünlüğü" riskini doğrudan besler.

3.5. Improper output handling (çıktının güvensiz işlenmesi)

LLM çıktısı, kaynağı ne olursa olsun güvensiz veri varsayımıyla ele alınmalıdır. Model çıktısı uygulamada uygun doğrulama/sanitize/encode edilmeden işlendiğinde, geleneksel güvenlik zafiyetleri tetiklenebilir (ör. istemci tarafında çalıştırılabilir işaretleme, sunucu tarafında sandbox'sız çalıştırma gibi).

Red team odağı: "model kötü üretti" değil, "uygulama model çıktısını nasıl tüketiyor?" sorusudur. Kanıt standardı: çıktının hangi tüketim noktasında kontrolsüz işlendiği, hangi güvenlik kontrolünün eksik olduğu ve iş etkisi.

3.6. Excessive agency (aşırı ajans / kontrolsüz eylem yetkisi)

Agent'larda risk, "modelin yanlış yazması" değil, yanlış iş başlatmasıdır. Aşırı ajans şu biçimlerde görünür:

gereksiz geniş tool yetkileri,
tek adımda geri döndürülemez eylemler,
zayıf/alışkanlığa bağlı (tıkla-geç) onay tasarımı,
gerekçe/parametre izinin eksikliği.

Savunma değerine çevirmek için, her eylem sınıfı için kabul kriteri yazılır: "Düzeldi" demek için hangi denetim izleri ve negatif test kanıtları gerekir?

3.7. System prompt leakage (sistem talimatı sızıntısı)

Sistem talimatları; politika, rol, kısıtlar ve bazen tool tanımlarına dair ipuçları içerdiği için, sızması "içerik" değil keşif (recon) değeri taşır. Bu, sonraki saldırı patikalarını daha isabetli kurgulama riskini büyütür.

Dikkat: Sistem talimatı sızıntısını "sadece metin" diye küçümsemek sık hatadır. Sızan parçalar, savunmanın tasarım varsayımlarını görünür kılar; bu da riskin dolaylı büyümesine yol açar.

3.8. Vector and embedding weaknesses (vektör/embedding zayıflıkları)

RAG'in kalbi çoğu zaman vektör arama ve embedding'dir. Zayıflıklar genellikle "algoritma bozuldu"dan çok şuralarda çıkar:

yanlış/eksik metadata filtreleme (kapsam ve tenant ayrımı),
benzerlik aramasında güvenilirlik sinyallerinin yokluğu (kaynak önceliklendirme),
embedding/veri hattında bütünlük ve denetim zayıflığı,
sonuçların "tek doğru" gibi sunulması (kaynak gösterimi ve kanıt izi eksikliği).

Bu başlık, hassas bilgi ifşası ve misinformation ile zincirlenebilir.

3.9. Misinformation (halüsinasyonun güvenlik etkisine dönüşmesi)

LLM'lerin "yanlış bilgi üretmesi" tek başına çoğu zaman kalite problemidir. Güvenlik problemine dönüşmesi; yanlış bilginin iş akışı üzerinde etkisi olduğunda başlar (ör. yanlış talimatla yanlış sistem değişikliği önermek, sahte kaynağı gerçek gibi göstermek, güven zincirini bozmak).

Kanıt standardı: yanlış bilginin hangi kontrol noktasını aştığı, hangi iş etkisini doğurduğu ve hangi karşı önlemlerin eksik olduğu.

İpucu: "Model uydurdu" tespitiyle raporu kapatma. Savunma tarafı için değerli olan; uydurmanın hangi koşullarda operasyonel karara dönüştüğü ve bunun nasıl kesileceğidir (kaynak zorunluluğu, onay tasarımı, retrieval kalitesi, gözlemlenebilirlik).

3.10. Unbounded consumption (sınırlandırılmamış tüketim / maliyet ve kaynak riski)

LLM sistemlerinde kaynak tüketimi yalnız CPU/RAM değildir; token maliyeti, gecikme, kuyruk, rate limit ve hatta "iş akışı spam'i" gerçek risktir. Kontrolsüz otomasyon ve geniş kapsamlı testler, istemeden finansal/operasyonel etki yaratabilir.

Bu risk, güvenli değerlendirme çerçevesinde "minimum zarar" ilkesinin bir parçası olarak ele alınmalıdır.

4) Doğrulama disiplini: "oldu" demek yetmez, "neden oldu"yu kanıtla

LLM sistemleri deterministik değildir; aynı girdi farklı çıktılar üretebilir. Bu, bulguyu zayıflatmaz; kanıt paketini disipline eder.

4.1. İddia → kanıt → karşı kanıt

Her bulguda üç parçayı ayrı tut:

İddia: Risk nedir, hangi güven sınırı ihlal ediliyor?
Kanıt: gözlemler, yapılandırma parçaları, log izleri, yetki modeli, tool çağrısı izleri, zaman uyumu.
Karşı kanıt: telafi edici kontroller, istisnalar, log kapsamı/retention sınırları, yeniden üretim denemelerinde başarısız olan varyasyonlar.

Karşı kanıt aramak, bulguyu "yumuşatmak" değil; raporu yayınlanabilir ve savunulabilir yapmaktır.

4.2. Tekrar üretilebilirlik ve belirsizlik yönetimi

"Kesin" ile "muhtemel" arasını doğru kurmak gerekir:

Hangi koşullarda tekrarlandı?
Hangi varyasyonlarda başarısız oldu?
Bu fark hangi tasarım unsuruna işaret ediyor?

Pratikte bu, çoğu zaman başarı oranı ve koşul seti ile raporlanır; tek bir örnek çıktı, tek başına karar için zayıftır.

4.3. Kontrollü değişken yaklaşımı (gürültüyü azalt, nedenselliği güçlendir)

Aynı senaryoda sadece tek parametreyi değiştir (ör. veri kaynağı, yetki seviyesi, tool allowlist, bağlam uzunluğu). Böylece "neden" bağlantısı güçlenir; gürültü ve yanlış pozitif maliyeti azalır.

4.4. Güvenli değerlendirme: minimum zarar ve izlenebilirlik

Üretim benzeri sistemlerde doğrulama, gerçek dünyaya zarar vermeyecek şekilde tasarlanmalıdır:

kapsam daraltma (sınırlı veri, sınırlı yetki, sınırlı eylem),
geri dönüş planı (yanlış eylem olursa nasıl geri alınır?),
denetim izleri ve saklama süresi,
test verisi ile gerçek veriyi ayrıştırma,
riskli eylemleri "temsilî" ve zararsız belirteçlerle kanıtlama.

Bu yaklaşım, NIST AI Risk Management Framework'ün yaşam döngüsü ve yönetişim vurgusuyla uyumludur: riskleri haritalama, ölçme, yönetme ve yönetişim altında ele alma.

5) Test planı ve yöntem seçimi: kapsam, maliyet, etik ve kanıt kalitesi

AI güvenliğinde "tek bir tarayıcı" yoktur; test planı sistem mimarisine göre özelleşir. Yöntem seçimi yaparken aynı anda dört maliyeti birlikte tart:

Noise / false positive: SOC ve ürün ekibini yorma riski
Operasyonel etki: üretimde yanlış aksiyon tetikleme riski
Etik/OPSEC sınırı: hassas veriye temas, kişisel veri riski
Kanıt kalitesi: gösterilebilirlik ve denetlenebilirlik

NCSC'nin LLM güvenliği rehberleri de prompt injection gibi risklerde katmanlı savunma ve güvenli test yaklaşımını vurgular.

Bu modülde "test planı" üç adımda olgunlaşır:

— Keşif ve haritalama: mimari bileşenler, veri akışı, güven sınırları, eylem yüzeyi (modül 2 ile doğrudan bağ).
— Düşük etkili doğrulamalar: konfigürasyon/erişim modeli incelemesi, log ve denetim izi analizi, kaynak/versiyon bütünlüğü kontrolleri.
— Dar kapsamlı senaryo testleri: yalnızca gerekli olduğunda, kontrollü koşullarda, kanıt zincirini güçlendirmek için.

Dikkat: Kontrolsüz otomasyon hem maliyet hem güvenlik riski doğurabilir. "Unbounded consumption" yalnız saldırı değil; kötü tasarlanmış test planının da sonucudur.

6) Bulguyu savunma değerine çevirmek: kontrol hedefi, kontrol noktası, kabul kriteri

AI bulgusu "model şunu dedi" seviyesinde kalırsa savunma tarafında aksiyon doğurmaz. Operasyonel değeri yüksek rapor üç şeyi netleştirir:

— Kontrol hedefi: ne korunuyor? (hassas veri, finansal işlem, üretim değişikliği, müşteri kaydı, marka güveni)
— Kontrol noktası: nerede uygulanmalı? (retrieval öncesi, tool çağrısı öncesi, output sonrası, kimlik katmanı, izleme katmanı)
— Kabul kriteri: "düzeldi" demek için hangi kanıt bekleniyor? (log izleri, negatif testler, istisna mekanizması, geri dönüş planı)

Örnek: "Yetkisiz doküman yanıt içinde göründü" bulgusunun kabul kriteri, yalnız "filtre ekledik" değildir. Savunma tarafında beklenen kanıt paketi; erişim modelinin düzeltildiğini, retrieval sırasında yetki kontrolü izlerinin üretildiğini, temsilî senaryolarda yeniden denendiğinde verinin gelmediğini ve istisna/denetim sürecinin tanımlandığını gösterebilmelidir.

Bu yaklaşım, modül 12'deki "tespit gerçekliği" ile modül 17'deki raporlama/purple teaming hattına doğal köprü kurar: red team bulgusu, savunmanın ölçebileceği sinyallere ve uygulanabilir kabul kriterlerine çevrilir.

Terimler Sözlüğü

Terim	Açıklama
AI Red Teaming	AI/LLM tabanlı sistemleri saldırgan bakışıyla, izinli ve kontrollü biçimde değerlendirip kırılma modlarını ortaya çıkarma yaklaşımı
LLM (Large Language Model)	Büyük dil modeli; olasılıksal üretim yapar, bu yüzden belirsizlik ve tekrar üretilebilirlik yönetimi kritiktir
RAG (Retrieval-Augmented Generation)	Yanıtı desteklemek için dış kaynaklardan içerik çekip bağlama ekleyen mimari
Prompt Injection	Kullanıcı girdisi veya bağlam yoluyla modelin politika/niyetini saptırma riski; güven sınırı problemi gibi ele alınır
Indirect Prompt Injection	Modelin işlediği dış içeriklere gömülü talimat benzeri metinlerle orkestrasyonun saptırılması
Tool / Function Calling	Modelin dış sistemlerde işlem başlatmasını sağlayan araç/aksiyon arayüzü
Agent (Agentic workflow)	LLM’in planlama + araç kullanımıyla çok adımlı iş akışı yürütmesi
Excessive Agency	Agent/araç katmanına gereksiz geniş eylem yetkisi verilmesi nedeniyle kontrolsüz etki riski
Guardrails	Politika, filtre, kural ve denetimlerle davranışı sınırlama katmanı; yetkilendirme kontrolünün yerine geçmez
Least Privilege	Araçların ve servis kimliklerinin yalnız gerekli en az yetkiyle çalıştırılması ilkesi
Confused Deputy	Vekil rolündeki sistemin, yetki bağlamını yanlış taşıyıp hatalı erişim/işlem yapması sınıfı
Sensitive Information Disclosure	Hassas verinin yetkisiz kişiye/sisteme ifşa edilmesi veya yanlış bağlamda taşınması
Improper Output Handling	Model çıktısının uygulamada yeterli doğrulama/sanitize/encode olmadan tüketilmesi
System Prompt Leakage	Sistem talimatlarının sızması; keşif (recon) değeri taşıyarak risk patikalarını güçlendirebilir
Vector / Embedding Weaknesses	Vektör arama/embedding hattında kapsam, bütünlük, filtreleme ve güvenilirlik sinyali zayıflıkları
Misinformation	Yanlış bilginin güvenlik etkisine dönüşmesi (iş akışı/karar/eylem üzerinde etki)
Unbounded Consumption	Token/maliyet/kuyruk/rate limit gibi kaynakların sınırlandırılmaması nedeniyle operasyonel/finansal risk
Canary Token	Güvenli doğrulama için zararsız “belirteç” kullanarak etkiyi kanıtlama yaklaşımı
Confidence	Bulgudaki kesinlik derecesini, hangi koşullarda değişeceğini ve belirsizliği açıkça ifade etme biçimi
Evidence Chain	Gözlem–yorum–sonuç ayrımı, izlenebilirlik ve çapraz doğrulamayla denetlenebilir kanıt paketi

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir ekip “prompt injection bitti, çünkü sistem mesajımız çok güçlü” diyor. İleri seviye değerlendirmede en doğru ilk yaklaşım hangisidir?

A) Güçlü sistem mesajı varsa sorun kalmaz

B) Prompt injection sadece kullanıcı girdisiyle olur; RAG/agent etkisizdir

C) Kontrolün kapsamı, istisnaları, tool/aksiyon yetkileri ve denetim izleri olmadan “bitti” iddiası kanıt standardını karşılamaz; karşı kanıt aranmalıdır

D) Bu tamamen model sağlayıcısının sorunudur

E) “Güçlü mesaj” zaten yetkilendirme kontrolüdür

Doğru: C
Kısa gerekçe: Güçlü sistem mesajı davranış kontrolüdür; RAG/agent/tool ve yetki katmanı devredeyken tek başına yeterli sayılmaz. A/E yetkilendirme–davranış ayrımını karıştırır; B/D aşırı daraltır.

2) LLM sistemlerinde kanıt standardı neden klasik uygulama testlerine göre daha dikkatli kurulmalıdır?

A) Çünkü LLM’ler hiçbir zaman log üretmez

B) Çünkü davranış olasılıksaldır; tekrar üretilebilirlik ve belirsizlik yönetimi gerekir

C) Çünkü LLM’lerde risk yoktur, sadece kalite sorunu vardır

D) Çünkü her bulgu otomatik olarak kritiktir

E) Çünkü guardrail varsa artık kanıt gerekmez

Doğru: B
Kısa gerekçe: Olasılıksallık, tek örnekle kesin hükmü zayıflatır; kontrollü tekrar ve koşul seti gerekir. A/C/D/E genelleme veya yanlış çıkarımdır.

3) RAG tabanlı bir asistanda “hassas veri ifşası” iddiasını kanıt standardına taşımak için en kritik ek bileşen hangisidir?

A) Tek bir ekran görüntüsü

B) Yanıtın çok uzun olması

C) Yetki modeli + retrieval/denetim izleri + en az bir bağımsız çapraz sinyal ile “yetkisiz” koşulunun doğrulanması

D) Modelin sıcaklık ayarını düşürmek

E) Kullanıcıdan yeniden denemesini istemek

Doğru: C
Kısa gerekçe: “Veri göründü” gözlemdir; “yetkisiz” olduğunu yetki modeliyle doğrulamak gerekir. A tek başına zayıf; B/D/E kanıt üretmez.

4) Agent’lı bir sistemde saldırı patikası bakışında en doğru çerçeve hangisidir?

A) Sadece modelin uygunsuz içerik üretmesini ölçmek

B) Model kararı → tool çağrısı → gerçek sistem etkisi → geri dönüş maliyeti zincirini kurup, her adımda yetki ve denetim izlerini doğrulamak

C) Sadece kullanıcı arayüzünü test etmek

D) Model sağlayıcısının güvenlik sayfasını referans almak yeterlidir

E) Her agent aynı risk seviyesindedir

Doğru: B
Kısa gerekçe: Risk “etki” katmanında büyür; yetki ve izlenebilirlik zinciri kurmadan değerlendirme eksik kalır. Diğer şıklar tek boyutludur.

5) “Guardrail var” ifadesinin tek başına güvenlik kanıtı sayılmamasının en doğru nedeni hangisidir?

A) Guardrail’ler hiçbir zaman çalışmaz

B) Guardrail’ler sadece performans içindir

C) Kapsam/istisna/kırılma modları net değilse; özellikle yetkilendirme ve tool çağrısı risklerinde güven üretmeyebilir

D) Guardrail’ler sadece eğitim ortamlarında gerekir

E) Guardrail’ler sadece ağ trafiğini kontrol eder

Doğru: C
Kısa gerekçe: Kontrolün varlığı değil, hangi koşulda neyi kaçırdığı önemlidir. A/B/D/E yanlış veya alakasızdır.

6) “System prompt leakage” bulgusunda red team raporunun en güçlü omurgası hangisidir?

A) Sızıntıyı yalnız “mahrem içerik” diye etiketlemek

B) Sızıntının, sonraki saldırı patikalarında hangi keşif değerini sağladığını; hangi kontrolleri zayıflatabileceğini ve hangi koşullarda tekrarlandığını kanıtlamak

C) Sadece “kapatın” demek

D) İçeriği aynen rapora kopyalamak

E) Konuyu önemsiz saymak

Doğru: B
Kısa gerekçe: Değer, keşif ve zincirleme etkidedir; kanıt ve koşul seti gerekir. D ayrıca gereksiz risk doğurabilir; A/C/E eksik.

7) “Improper output handling” riskini doğru konumlandıran seçenek hangisidir?

A) Problem modelin “kötü niyetli” olmasıdır

B) Problem model çıktısının uygulamada güvenli kabul edilip doğrulama/encode/sanitize olmadan tüketilmesidir

C) Problem yalnızca prompt injection ile oluşur

D) Problem sadece RAG varsa oluşur

E) Problem sadece mobil uygulamalarda görülür

Doğru: B
Kısa gerekçe: Kök neden, çıktının tüketim noktasındaki kontrol zayıflığıdır. Diğer şıklar yanlış genellemedir.

8) “Misinformation” hangi durumda güvenlik problemine dönüşmeye en yakındır?

A) Modelin bir konuda emin konuşması

B) Yanlış bilginin iş akışı/karar/eylem üzerinde kontrol noktalarını aşarak operasyonel etki doğurması

C) Modelin dilbilgisi hatası yapması

D) Yanıtın kısa olması

E) Modelin yaratıcı olması

Doğru: B
Kısa gerekçe: Güvenlik etkisi, yanlış bilginin süreçte aksiyona dönüşmesidir. A/C/D/E kalite/üslup tartışmasıdır.

9) Üretim benzeri bir ortamda “yöntem seçimi + sınırlar” ilkesine göre en doğru doğrulama stratejisi hangisidir?

A) En gürültülü testler her zaman en iyisidir

B) Önce düşük etkili erişim modeli/konfigürasyon doğrulaması ve log incelemesiyle iddiayı güçlendirip; gerekiyorsa dar kapsamlı, geri dönüş planlı senaryoya geçmek

C) Denetim izlerini kapatmak

D) Sonuçları belirsiz bırakmak, çünkü “LLM zaten değişken”

E) Her bulguyu aynı şiddetle raporlamak

Doğru: B
Kısa gerekçe: Minimum zarar ve kanıt kalitesi birlikte optimize edilir. C/D/E riskli ve zayıf; A gereksiz operasyonel yük doğurur.

10) “Unbounded consumption” riskini hem güvenlik hem operasyon açısından en iyi yakalayan rapor yaklaşımı hangisidir?

A) Sadece “maliyet artar” demek

B) Tüketimin hangi tetikleyicilerle büyüdüğünü, hangi limit/koruma noktalarının eksik olduğunu ve kabul kriterlerini (limitler, izleme, geri dönüş) kanıtla yazmak

C) Konuyu yalnız performans ekibine bırakmak

D) “Modeli değiştirin” demek

E) Bu riskin güvenlikle ilgisi yoktur

Doğru: B
Kısa gerekçe: Değer, tetikleyici–kontrol noktası–kabul kriteri zincirindedir. A/C/D/E eksik veya yanlış çerçevedir.

Bu Modülde Kazanılan Yetkinlikler

AI red teaming'in "model" değil, sistem testi olduğunu; riskin veri + araç + kimlik/yetki + denetim izi zinciriyle büyüdüğünü.
Prompt injection'ın (özellikle dolaylı enjeksiyonun) "metin hilesi" değil, güven sınırı ve yetki tasarımı problemi olduğunu.
LLM'lerin olasılıksal doğası nedeniyle bulguların kanıt standardı, tekrar üretilebilirlik ve belirsizlik yönetimiyle raporlanması gerektiğini.
Agent/tool katmanında riskin "çıktı"dan "etki"ye geçtiğini; least privilege, anlamlı onay ve denetim izi olmadan güven üretilemeyeceğini.
RAG ortamlarında yalnız gizliliğin değil; bütünlük, güncellik ve vektör/embedding hattı zayıflıklarının da saldırı patikasıyla ele alınması gerektiğini.
Bulguları savunma değerine çevirmek için kontrol hedefi + kontrol noktası + kabul kriteri yaklaşımının belirleyici olduğunu.

Modül 17 — Profesyonel Raporlama, Görselleştirme, İletişim ve Purple Teaming

Teknik bir operasyon ne kadar başarılı olursa olsun, bulgular karar vericilere doğru aktarılmıyor ve savunma tarafında ölçülebilir bir iyileştirmeye dönüşmüyorsa, gerçek çıktı eksik kalır. İleri seviye Red Team/Pentest dünyasında "ürün", ele geçirilen sistemler değil; kanıt standardında yazılmış rapor, doğru kurgulanmış görsel hikâye ve Blue Team'le birlikte yürütülen Purple Team iyileştirme hattıdır. Bu modül; teknik doğruluğu belirsizlik yönetimiyle birleştirerek "bulgu → karar → iyileştirme" zincirini profesyonel seviyeye taşır.

Bu Modülde Hedeflenen Kazanımlar

Teknik bulguları, farklı paydaş profillerine uygun biçimde (iş dili / teknik dil) çelişmeden aktarabilmek.
"İddia-kanıt-karşı kanıt" mantığıyla denetlenebilir kanıt zinciri kurup, eminlik derecesini (confidence) dürüstçe ifade edebilmek.
Risk derecelendirmesinde CVSS gibi skorları bağlama oturtup iş etkisi ve saldırı patikasıyla gerçekçi önceliklendirme yapabilmek.
Attack path, timeline ve ısı haritası gibi görselleri "gösteriş" değil karar verdiren açıklık için tasarlayabilmek.
Purple Team oturumlarını yönetip bulguları detection engineering, aksiyon backlog'u, kabul kriteri ve kapanış kanıtına çevirebilmek.

1) Raporun "nihai ürün" olduğu yer: çıktı mimarisi ve standart

Rapor tek bir kitleye yazılmaz. Aynı gerçek, iki farklı dünyaya çevrilir: bütçeyi onaylayan yönetim ve problemi çözecek teknik ekip. Bu iki profilin beklentileri doğal olarak çatışır; ileri seviye raporlama, bu çatışmayı formatla çözer.

1.1. İki ana çıktı: iş dili ve teknik kanıt paketi

Yönetici özeti; teknik ayrıntıların değil, kararın hızlandığı yerdir. Burada "nasıl"dan çok "ne oldu / ne kaybedebiliriz / şimdi ne yapıyoruz?" anlatılır. Teknik rapor ise bir mühendisin "bunu doğrulayabilir miyim, düzelttik mi, kapanış kanıtı ne?" sorularına cevap verir.

Örnek:
* Kötü anlatım (karar verdirmez): "Kritik bir zafiyet tespit edildi; uzaktan çalıştırma riski var."
* İyi anlatım (karar verdirir): "Kritik veri sınıfına erişen bir bileşende güncelleme/konfigürasyon uyumsuzluğu nedeniyle, yetki sınırlarının aşılmasına işaret eden güçlü sinyaller görüldü. Etki: veri gizliliği ve uyum riski. Öncelik: ilk 72 saat içinde yamalama/konfigürasyon düzeltmesi ve kapanış doğrulaması."

Dikkat: İş dili "teknik olmayan" demek değildir; sonuç ve etki odaklı demektir. Teknik rapor da "her şeyi dökmek" değildir; denetlenebilir kanıt + kapanış ölçütü demektir.

1.2. Teknik raporda tekrar üretilebilirlik ve denetlenebilirlik

Teknik raporun gücü, iddiayı "inanılır" değil doğrulanabilir yapmasıdır. Bu yüzden:

Kanıt tek bir ekran görüntüsüne indirgenmez; bağlam ve zaman uyumu korunur.
Aynı bulguyu doğrulamak isteyen ekip, rapordan hareketle kontrollü bir doğrulama yapabilmelidir.
"Kopyala/yapıştır çalıştır" tarzı riskli pratiklere bel bağlamadan, doğrulama mantığı ve gerekli kontrol noktaları açık yazılmalıdır.

İpucu: Teknik raporda her bulgu için tek cümlelik "doğrulama kapısı" koy: "Bu bulgu, X log/telemetri ve Y kontrol noktasıyla doğrulanır; Z karşı kanıtı gelirse kapsam daraltılır." Bu cümle, tartışmayı kişisel görüşten çıkarıp kanıta taşır.

1.3. Ekler: raporu şişirmeden kanıtı taşımak

Ekler; ana metni boğmadan kanıt ve ayrıntıları saklar: timeline, görsel şemalar, log özetleri, sınırlamalar, kullanılan çerçeveler. Ana metin "karar yolu"dur; ekler "denetim yolu".

2) Risk derecelendirme: skor değil bağlam

Otomatik araçlar kırmızı görmeyi sever; ileri seviye uzman bağlama bakar. CVSS gibi sistemler teknik ciddiyeti puanlar; fakat "gerçek risk", hedefin bağlamı ve saldırı patikasındaki rolüyle ortaya çıkar.

2.1. CVSS ile gerçek risk arasındaki fark

CVSS; "ne kadar ciddi" sorusuna yaklaşır. "Ne kadar riskli" ise şu sorulara bağlıdır:

Bu bileşen internete açık mı, erişilebilirlik nasıl?
Etkilenen varlık hangi iş sürecine bağlı?
Bu bulgu zincirleme saldırıda (modül 7'deki düşünce gibi) ilk halka mı, yoksa izole bir uç nokta mı?
Telafi edici kontroller (segmentasyon, izleme, doğrulama kapıları) var mı?

Örnek:
* İnternete kapalı, izolasyonu yüksek bir ortamda yüksek teknik skor üreten bir zafiyet, erişim koşulları nedeniyle pratikte daha düşük önceliğe alınabilir.
* İnternete açık bir ödeme bileşeninde "orta" teknik skor üreten bir bilgi sızıntısı, zincirde kritik bir anahtarı açığa çıkarıyorsa iş etkisi nedeniyle daha öne çekilebilir.

2.2. Bağlamsal derecelendirme ve gerekçelendirme

CVSS'in "environmental" yaklaşımı, skorun ortam koşullarına göre uyarlanabileceğini söyler. Buradaki asıl profesyonellik, skoru değiştirmek değil; neden değiştirdiğini yazmaktır. Rapor, "niye yükselttik / niye düşürdük" sorusuna cevap vermelidir.

Bazı ekipler için pratik bir düşünce çerçevesi: Risk = (Tehdit x Zafiyet x Etki) / Kontrol

Bu formül "matematik" iddiası değil; raporda gerekçeyi düzenleyen bir iskelet olarak işe yarar: tehdit ve etki artarken kontrol gücü yükseliyorsa risk düşer.

Dikkat: Yanlış güvenlik algısı (her şeyi test ettik, güvendeyiz) çoğu zaman tek bir zafiyetten daha tehlikelidir. Kapsam sınırlarını ve test edilmemiş alanları açık yazmak, raporun güvenilirliğini artırır.

3) Kanıt standardı ve belirsizlik: iddia-kanıt-karşı kanıt

Bu modülün kalbi "kanıt zinciri"dir. İleri seviye bir bulgu üç parçaya ayrılır:

3.1. İddia: neyi söylüyorsun, nerede kırılıyor?

İddia; "açık var" demek değildir. Şunları taşır:

Hangi güven varsayımı bozuluyor?
Hangi varlık sınıfı etkileniyor?
İş etkisi ve teknik etki birlikte neye dönüşüyor?

3.2. Kanıt: gözlem, bağlam, izlenebilirlik

Kanıt; yalnızca görsel değil, bağlamlı kanıttır:

Gözlemler (sistem davranışı, beklenmeyen yetki kapsamı, güven sınırı geçişi sinyali)
Bağlam (kapsam, rol/kimlik bağlamı, ilgili bileşen)
İzlenebilirlik (hangi telemetri/denetim izi ile ilişkilendirildiği)
Zaman uyumu (olay sırası ve tutarlılık)
Tekrar üretilebilirlik (aynı koşullarda benzer sinyal)

Örnek: "Ekran görüntüsü var" yerine, "şu zaman penceresinde, şu kimlik bağlamında beklenen yetki sınırını aşan erişim sinyali; şu log kaynağıyla tutarlı" demek; iddiayı savunulabilir kılar.

İpucu: Kanıt paketini hazırlarken "en az veri" ilkesini uygula. Amaç; daha fazla veri paylaşmak değil, kararı verdiren minimum ama yeterli kanıtı, gereksiz hassas veri taşımadan sunmaktır.

3.3. Karşı kanıt: raporu güçlendiren şey

Karşı kanıt aramak, bulguyu zayıflatmaz; raporu profesyonel yapar:

Telafi edici kontrol var mı?
Hangi koşulda sinyal kayboluyor (istisnalar)?
Log kapsamı/retention sınırlı mı?
Aynı iddia hangi varyasyonlarda başarısız oluyor?

Bu bölüm, modül 12'deki "tespit perspektifi" ile doğal biçimde birleşir: savunma tarafı için asıl değer, bulgunun nerede güçlü/nerede sınırlı olduğunun açık yazılmasıdır.

3.4. Confidence: ne kadar eminsin, ne değiştirir?

"Yüksek/orta/düşük" gibi etiketler tek başına yetmez. Üç bileşen görünür olmalıdır:

Neyi destekleyen bağımsız sinyaller var?
Hangi koşullarda tekrarlandı/tekrarlanmadı?
Hangi yeni kanıt gelirse değerlendirme değişir?

4) Bulgu yazımı: aksiyonlanabilir ve savunulabilir format

İyi bir bulgu metni, hem "denetlenebilir" hem "çözülebilir" olmalıdır.

4.1. Başlık ve kapsam bağlamı

Tek cümlelik net başlık (ne kırıldı?)
Etkilenen varlık sınıfı (uydurma ve genelleyerek)
Kapsam hatırlatması (modül 1'deki izinli çerçeve ile uyum)

4.2. Saldırı patikası dili: how-to değil, kırılma mantığı

Patikayı anlatırken "uygula şunu" yerine şunu hedefle:

giriş koşulu,
güven sınırı ihlali,
etki alanı,
geri dönüş maliyeti.

Örnek: "Kimlik bağlamı doğru taşınmıyor" yerine "işlem, kullanıcı yetkisiyle sınırlı kalması gerekirken servis kimliği yetkisiyle genişliyor" demek; savunmaya tasarım problemini gösterir, operasyon tarifine dönüşmez.

4.3. Öneri + kabul kriteri: "düzeldi"yi ölç

Öneri; kontrol hedefini ve kontrol noktasını tarif eder. Kabul kriteri; kapanışı kanıtlar.

Kontrol hedefi: neyi koruyoruz?
Kontrol noktası: nerede uyguluyoruz?
Kabul kriteri: hangi kanıtla kapanıyor? (ör. izleme metriği, doğrulama kapısı, yeniden değerlendirme sonuçları)

Dikkat: "Filtre ekleyin / engelleyin" gibi tek cümle öneriler, ileri seviye raporda zayıftır. Asıl değer; "hangi kırılma modunu kapattık ve bunu nasıl doğruluyoruz?" sorusuna net cevap vermektir.

5) Görselleştirme: metnin yapamadığını göstermek

Metin doğrusaldır; saldırı patikaları ise çoğu zaman dallanır. Görselin amacı "şık görünmek" değil; ilişkileri görünür kılıp kararı hızlandırmaktır.

5.1. Ne zaman hangi görsel?

Attack path / attack graph: zincirleme ilişkileri ve kritik kırılma noktalarını göstermek için.

Düğümler: varlıklar/kimlikler; Kenarlar: ilişki/bağımlılık/eylem sınıfları.

Timeline: olayların sırası ve kanıt uyumu için; savunma tarafının kendi loglarıyla karşılaştırabilmesi için.
Isı haritası: bulguları etki/olasılık veya kontrol olgunluğu ekseninde özetlemek için.
Kapsam haritası: test edilen ve edilmeyen alanları netleştirmek için.

Örnek: Yönetici toplantısında ısı haritası "nereden başlamalıyız?" sorusunu hızlandırır; teknik ekipte timeline ve attack graph "nasıl doğrulayacağız ve nerede kapatacağız?" sorusunu hızlandırır.

5.2. Timeline'da zaman uyumu ve doğrulama

Timeline, "dakika dakika operasyon" anlatmak için değil; kanıtların tutarlılığını kurmak için kullanılır. Saat senkronu ve zaman pencereleri özellikle önemlidir; farklı sistemlerde zaman kayması varsa, rapor bunu belirsizlik notu olarak açıkça taşır.

İpucu: "Bir görsel = bir mesaj" kuralını uygula. Aynı görselde aynı anda her şeyi göstermeye çalışmak, mesajı bulanıklaştırır.

6) MITRE ATT&CK haritalama ve coverage gap analizi

Operasyon çıktıları, tekniklerin ve savunma boşluklarının daha görünür olduğu bir çerçeveye oturtulduğunda, rapor stratejik değere ulaşır. ATT&CK haritalama burada "süs" değil; kör noktaları ve kapsama durumunu konuşmanın kısa yoludur.

6.1. Isı haritası mantığı: dürüstlük ve beklenti yönetimi

Bir yaklaşım:

Test edildi ve engellenmedi/tespit edilmedi → "boşluk"
Test edildi ve engellendi/tespit edildi → "kapsandı"
Test edilmedi → "kapsam dışı / bilinmiyor"

Buradaki kritik nokta şudur: Test etmediğin bir tekniğe "güvenli" demek, rapora yanlış kesinlik yükler.

6.2. Gap analizi: "kapatın" değil, "nasıl ölçeceğiz?"

Gap analizi, savunma için ölçülebilir bir öneriye bağlanmalıdır:

Hangi telemetri gerekli? (log kaynağı / sensör görünürlüğü)
Hangi korelasyon mantığı gerekli? (tespit hipotezi)
Yanlış pozitif maliyeti ne? (noise/FP)
Kabul kriteri ne? (kapanış kanıtı)

Bu bölüm, modül 12'nin tespit perspektifiyle ve modül 13'ün "minimum zarar" yaklaşımıyla aynı hatta oturur: amaç "daha sert vurmak" değil, savunmanın ölçülebilir şekilde güçlenmesidir.

7) İletişim: gergin anlarda kanıta dönmek

Raporun okunmadığı kurumlar vardır; ama raporun tartışıldığı toplantılar her zaman belirleyicidir. Profesyonellik, haklı çıkmak değil; doğru sonuca kanıtla yürümektir.

7.1. Kickoff → checkpoint → readout → debrief

Kickoff: kapsam, hassasiyet sınırları, iletişim kanalı, başarı ölçütleri (modül 1 ile uyum).
Checkpoint: erken sinyaller, yanlış anlaşılmaları düzeltme, riskli doğrulamaların sınırlarını teyit.
Readout: bulguların karar odaklı sunumu (öncelik, etki, kabul kriteri, belirsizlik notu).
Debrief: kapanış, açık kalan sorular, aksiyon sahipliği ve zaman planı.

7.2. İtiraz yönetimi: "bence" değil, "hangi kanıt?"

Paydaş "bu gerçek değil" dediğinde ileri seviye yaklaşım:

İddia ve kapsamı net tekrar et,
Kanıtı bağlamıyla göster (gereksiz veri ifşa etmeden),
"Hangi bilgi gelirse bu bulgu kapanır/daralır?" sorusunu sor,
Ortak kabul kriteri yaz.

Bu, tartışmayı kişisel kanaatten çıkarıp denetlenebilirliğe taşır.

8) Purple Teaming: bulguyu iyileştirme hattına çevirmek

Purple Teaming; Red ve Blue'nun aynı masada, bulguyu "yakalamaca" oyunundan çıkarıp "iyileştirme" işine dönüştürmesidir. İleri seviye değer, rapor tesliminde değil; raporun kapanış kanıtına bağlanmasında oluşur.

8.1. Hot-wash: taze iken doğrulama

Operasyonun hemen ardından yapılan teknik değerlendirme oturumunda hedef basittir: "Ne oldu, savunma ne gördü, ne görmedi, neden?" Burada Red Team'in rolü "övünmek" değil; kanıtı doğru formatta getirip, görünürlük boşluğu mu var yoksa kural/korelasyon mu eksik, bunu netleştirmektir.

8.2. Detection engineering ve aksiyon backlog'u

Bulguların her biri için:

tespit hipotezi (hangi davranış sınıfı izlenmeli),
gerekli telemetri (hangi kaynaklar),
kuralın/uyarının başarı ölçütü (noise/FP dengesi),
sahiplik ve termin,
kabul kriteri ve kapanış kanıtı tanımlanır.

Örnek: "Bu davranış sınıfı için görünürlük yok" sonucu çıkarsa, ilk aksiyon "kural yazmak" değil, önce telemetriyi güvenilir hale getirmektir. Telemetri varsa ama kural yoksa, o zaman kural/korelasyon tasarımına geçilir.

Dikkat: Purple Teaming'i "daha fazla test"e çevirmek kolaydır. Asıl hedef, minimum zarar ilkesini koruyarak savunmayı ölçülebilir biçimde geliştirmektir.

8.3. Ölçüm: kapanışın sayısal izleri

Kapanışın olgunlaşması için metrik düşüncesi gerekir:

kritik bulguların kapanma süresi,
alarm kalitesi (noise/FP),
kapsanan patika yüzdesi,
tespit/önleme kapsama haritasındaki değişim.

9) Yayınlanabilirlik, gizlilik ve profesyonel standart

Rapor, internet sitesinde yayınlanabilecek kadar "temiz" olmalı; ama aynı zamanda kuruma zarar verecek kadar detaylı olmamalıdır.

Gereksiz hassas veri yok (kişisel veri, gizli anahtarlar, üretimden ham veri).
Örnekler anonim ve uydurma.
"Operasyonel tarif" veren, uygulanabilir saldırı adımına dönüşen anlatım yok.
Kapsam sınırları ve belirsizlikler açık.

Terimler Sözlüğü

Terim	Açıklama
Executive Summary	Üst yönetime hitap eden, iş riski ve karar odaklı özet bölüm
Stakeholder	Paydaş; raporu tüketen/karar veren taraflar
Readout	Bulguların sunulduğu resmi değerlendirme oturumu
Debrief	Çalışma sonrası kapanış değerlendirmesi ve aksiyon planı oturumu
Evidence Chain	Kanıt zinciri; gözlem–yorum ayrımı ve izlenebilirlik ile denetlenebilir paket
Reproducibility	Tekrar üretilebilirlik; benzer koşullarda benzer sonucun doğrulanabilmesi
Counter-evidence	Karşı kanıt; bulguyu daraltan/çürüten veya sınırlarını belirleyen veriler
Confidence	Eminlik derecesi; hangi kanıtla desteklendiği ve hangi koşulda değişeceği
Acceptance Criteria	Kabul kriteri; “kapanış” için aranacak doğrulama ölçütleri
Root Cause Analysis (RCA)	Kök neden analizi; semptom yerine asıl tasarım/uygulama nedenini bulma
Heatmap	Isı haritası; bulguları etki/olasılık veya kapsama ekseninde özetleyen görsel
Timeline	Zaman çizelgesi; olayların sırası ve kanıt uyumunu gösteren çizelge
Purple Teaming	Red ve Blue ekiplerin birlikte çalışarak tespit ve iyileştirmeyi olgunlaştırdığı süreç
Detection Engineering	Tespit mühendisliği; telemetri ve kural/korelasyon tasarımıyla tespit kapasitesini geliştirme
Risk Appetite	Risk iştahı; kurumun kabul edilebilir risk seviyesi ve önceliklendirme tercihi
CVSS	Zafiyetlerin teknik ciddiyetini puanlamak için kullanılan standart
Environmental Score	Skorun, ortam koşullarına göre uyarlanmış değerlendirmesi
Attack Graph	Saldırı patikasını düğümler (varlık/kimlik) ve kenarlarla (ilişki/bağımlılık) görselleştiren yapı
Gap Analysis	Mevcut savunma duruşu ile hedeflenen durum arasındaki boşluk analizi
Hot-wash	Operasyon/tatbikat sonrası hızlı değerlendirme ve ders çıkarma oturumu
Kill Chain	Saldırı safhalarını düşünmeyi kolaylaştıran aşama yaklaşımı

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Yöneticiye sunulan özet bölümünde aşağıdaki ifadelerden hangisi en doğru yaklaşıma örnektir?

A) “Belirli bir bileşende teknik olarak yüksek skorlu bir zafiyet tespit edildi.”

B) “Açık, şu yöntemle sömürülebilir; adımlar eklerde.”

C) “Kritik veri sınıfına erişen bileşende kontrol zayıflığı sinyali görüldü; etki veri gizliliği ve uyum riskine uzanıyor. İlk 72 saatte düzeltme ve kapanış doğrulaması önerilir.”

D) “Loglarda bazı anomaliler var, emin değiliz.”

E) “Zafiyetin adı popüler, o yüzden kritiktir.”

Doğru: C
Kısa gerekçe: İş dili; etki, karar ve zamanlamayı netleştirir. A belirsiz/aksiyonsuz, B operasyonel tarife yaklaşır, D belirsizliği yönetmiyor, E gerekçesiz.

2) CVSS skoru yüksek olan bir bulgunun önceliği hangi durumda rasyonel biçimde düşürülebilir?

A) Zafiyet eskiyse

B) Ortam erişilebilirliği ve dağılımı düşükse; telafi edici kontroller güçlü ve etki sınırlıysa (gerekçesi raporda açıkça yazılarak)

C) Yönetim raporu sevmiyorsa

D) Bulgu görselleştirilemediyse

E) Teknik ekip yoğun olduğu için

Doğru: B
Kısa gerekçe: Bağlam (erişilebilirlik, dağılım, kontrol) gerçek riski belirler. A/C/D/E bağlamsal risk gerekçesi değildir.

3) “İddia–kanıt–karşı kanıt” ayrımının en önemli faydası aşağıdakilerden hangisidir?

A) Raporu uzatır

B) Tartışmayı kişisel kanaatten çıkarıp denetlenebilirliğe taşır; belirsizliği dürüstçe yönetir

C) Teknik detayı tamamen saklar

D) Her bulguyu otomatik “kritik” yapar

E) Görselleri gereksiz kılar

Doğru: B
Kısa gerekçe: Bu ayrım, kanıt standardını kurar. A/C/D/E hedef dışıdır.

4) Teknik raporda “doğrulama/kapanış ölçütü” yazmanın temel amacı nedir?

A) Kapatma işini red team’in yapması

B) “Düzeldi” kararını ölçülebilir kılmak ve yeniden değerlendirmeyi (re-test) tartışmasız hale getirmek

C) Yönetici özetini daha uzun yapmak

D) Ekleri gereksizleştirmek

E) Belirsizliği gizlemek

Doğru: B
Kısa gerekçe: Kabul kriteri, kapanışın kanıtıdır. A/C/D/E yanlış odak.

5) ATT&CK haritalama/ısı haritasında “test edilmedi” alanlarını açıkça belirtmek neden kritiktir?

A) Harita daha renkli olsun diye

B) Kapsam sınırlarını netleştirip yanlış güvenlik algısını önlemek için

C) Test edilmediği için otomatik güvenli saymak için

D) Yönetimi korkutmak için

E) Teknik ekibi suçlamak için

Doğru: B
Kısa gerekçe: Dürüstlük ve beklenti yönetimi, raporu güvenilir yapar. C tam tersidir; D/E profesyonel değildir.

6) Attack graph görselleştirmesinin en güçlü avantajı hangisidir?

A) Metinden daha kısa olması

B) Zincirleme ilişkilerde kritik kırılma noktalarını (choke point) ve “hangi düzeltme yolu keser?” sorusunu görünür kılması

C) Kanıt ihtiyacını ortadan kaldırması

D) Yalnızca yöneticiler sevdiği için

E) Timeline’ın yerini tamamen alması

Doğru: B
Kısa gerekçe: Attack graph, ilişki ve bağımlılıkları gösterir. C/E yanlış; A/D tali.

7) Bir bulguda “yüksek confidence” demek için en doğru yaklaşım hangisidir?

A) Belirsizlikten hiç bahsetmemek

B) Tek bir sinyale dayanmak

C) Bağımsız sinyaller, tekrar koşulları ve hangi yeni kanıtın değerlendirmeyi değiştireceğini birlikte yazmak

D) “Bence çok kritik” demek

E) Skoru yüksek yazmak

Doğru: C
Kısa gerekçe: Confidence; gerekçe + koşul + değişim eşiğiyle kurulur. A/B/D/E güveni düşürür.

8) Purple Team oturumunun temel çıktısı aşağıdakilerden hangisidir?

A) Red team’in başarısını kutlamak

B) Blue team’i başarısız göstermek

C) Tespit hipotezi + telemetri gereksinimi + noise/FP dengesi + aksiyon sahipliği + kapanış kanıtı ile iyileştirme planı

D) Yalnızca yönetici sunumu

E) Sadece ham logların paylaşılması

Doğru: C
Kısa gerekçe: Purple Teaming, “bulgu → iyileştirme” hattını üretir. A/B/D/E eksik veya yanlış odaklıdır.

9) “En az veri” ilkesi raporlamada neyi ifade eder?

A) Kanıt toplamamak

B) Kanıtı saklamak

C) Gereksiz hassas veri taşımadan, karar için yeterli minimum kanıtı bağlamıyla sunmak

D) Her şeyi eklerde sınırsız paylaşmak

E) Sadece sözlü anlatmak

Doğru: C
Kısa gerekçe: Amaç, kanıt standardını korurken veri ihlali riskini büyütmemektir. A/B/D/E dengesiz.

10) Bir paydaş readout’ta “bu bulgu gerçek değil” dediğinde en profesyonel tepki hangisidir?

A) “Biz biliyoruz” deyip tartışmayı kapatmak

B) Teknik detayları aşırı artırıp karşı tarafı boğmak

C) İddia–kanıt–karşı kanıt çerçevesine dönüp “hangi ek kanıt gelirse kapanır/daralır?” sorusuyla ortak kabul kriteri üretmek

D) Konuyu değiştirmek

E) Paydaşı suçlamak

Doğru: C
Kısa gerekçe: Kanıta dönmek ve kapanış ölçütü üretmek, gerginliği yönetir. A/B/D/E güveni zedeler.

Bu Modülde Kazanılan Yetkinlikler

Raporu "bulgu listesi" değil, karar verdiren ve denetlenebilir bir nihai ürün olarak tasarlama.
Aynı gerçeği farklı hedef kitlelere uygun biçimde (iş dili / teknik dil) tutarlı aktarma.
Kanıt zincirini iddia-kanıt-karşı kanıt mantığıyla kurma; belirsizliği ve confidence'ı profesyonelce yönetme.
CVSS gibi skorları bağlama oturtup iş etkisi, erişilebilirlik ve kontrol gücüyle gerçekçi önceliklendirme yapma.
Görselleri (attack path/graph, timeline, heatmap) karar kalitesini artıran bir anlatı aracı olarak kullanma.
Purple Teaming ile bulguları detection engineering ve aksiyon backlog'una bağlayıp kabul kriteri ve kapanış kanıtı üretme.

MODÜL 18 — Final Tabletop Capstone

Modül Teması

Senaryo Kurgusu

Hedef aktör, kapsam ve başarı kriterleri.

İcra Disiplini

Aksiyon→kanıt→geri çekilme döngüsü.

Rapor & Diyalog

Yönetici özeti, teknik ek ve mavi takım iletişimi.

Bu modül, önceki 17 modülde kurduğun "karar kalitesi + kanıt standardı + sınır disiplini" omurgasını tek bir uçtan uca senaryoda birleştirir. Burada amaç "en yaratıcı teknik hamle" değil; RoE'ye sadık kalan, kanıt zinciri sağlam, belirsizliği dürüst yöneten, risk dilini doğru kuran ve sonunda Blue Team'e ölçülebilir iyileştirme bırakabilen profesyonel çıktılar üretmektir. Format tamamen yazılıdır: gerçek sistem yok, komut yok, istismar talimatı yok; yalnızca tabletop mantığıyla karar verme ve çıktıları yapılandırma vardır.

Bu Modülde Hedeflenen Kazanımlar

Tek bir senaryoda dış yüzey → kimlik → kurumsal dizin → bulut → hedef varlık hattını saldırı patikası düşüncesiyle modelleyebilmek.
RoE ve kapsam disiplinini koruyarak "scope creep" ve operasyonel zarar riskini yazılı kararlarla yönetebilmek.
Bulguları "kaynak-iddia-kanıt-karşı kanıt" ayrımıyla paketleyip confidence dili ile belirsizliği şeffaf yönetebilmek.
Deliverable setini (RoE + operasyon planı, recon brief, kanıt standardında olay anlatımı, ATT&CK eşlemesi, detection gap raporu, remediation roadmap) tutarlı ve yayınlanabilir biçimde üretebilmek.
Purple Team hattına bağlanacak şekilde "kabul kriteri + kapanış kanıtı + metrik" tanımlayarak iyileştirmeyi ölçülebilir kılabilmek.

1) Tabletop Capstone mantığı: "gerçek sistem yok, gerçek disiplin var"

Tabletop, masada yapılan bir "savaş oyunu" değildir; belirsizlik altında doğru karar verme ve bunu denetlenebilir çıktıya dönüştürme egzersizidir. Bu modülün senaryosu; modül 1'deki yönetişim/RoE, modül 2'deki tehdit modelleme ve hedef odaklı senaryo kurgusu, modül 12'deki tespit perspektifi ve modül 17'deki raporlama standardını aynı anda çalıştırır.

1.1. Senaryo paketi: dış yüzey → kimlik → dizin → bulut → hedef varlık

Senaryo paketi, katılımcıya "ham bilgi" vermek yerine hipotez kurduracak sinyaller verir. Her sinyal için:

Ne iddia ediliyor? (hangi güven varsayımı sarsılıyor)
Hangi kanıtlar bunu destekler? (hangi telemetri/iz)
Hangi karşı kanıt aranmadan kesin konuşulamaz? (hangi veri yoksa belirsizlik)
RoE kapsamında doğrulama nasıl güvenli yapılır? (minimum zarar)

Örnek: "Kurumun dış yüzeyinde bir kimlik akışının beklenenden farklı davrandığına dair sinyal var" ifadesi, tek başına "yetkisiz erişim var" demek değildir. Bu sinyal; kimlik yaşam döngüsü (modül 5), yetki sınırı ve log görünürlüğü (modül 12) ile birlikte ele alınır; doğrulama için hangi kayıtların gerektiği ve hangi kayıtlar yoksa eminliğin düşeceği yazılır.

Dikkat: Bu modülün en büyük tuzağı "senaryo akıyor, ben de akayım" refleksidir. RoE ve kapsam çizgisi kayarsa, capstone çıktısı teknik olarak etkileyici görünse bile profesyonel olarak başarısız sayılır.

1.2. Rol seti: kararların farklı gözlerden test edilmesi

Tabletop'ta tek bir kişi konuşmaz; rollere göre bakış açısı ayrışır. En azından şu perspektifler düşünülür (kişi adı değil rol):

Red Team lideri: yöntem seçimi, OPSEC, doğrulama kapıları
Müşteri temsilcisi/ürün sahibi: iş etkisi, risk iştahı, öncelik
SOC/Blue Team: telemetri, tespit hipotezleri, false positive maliyeti
Hukuk/uyum: veri minimizasyonu, rapor dili, kapsam/izin
Operasyon/IT: deconfliction, değişiklik yönetimi, "kill-switch" tetikleyicileri

Bu rolleri yazılı çıktıda "karar gerekçesi" olarak yansıtmak, raporun olgunluğunu artırır: aynı kararın farklı maliyetlerini görünür kılar.

1.3. Inject (senaryoya enjekte edilen gelişmeler): belirsizlik altında tutarlılık

Senaryo ilerledikçe kısa "inject"ler gelir: yeni bir log parçası, yeni bir iş kısıtı, bir sistemin kapsam dışı olduğunun netleşmesi, bir telemetri boşluğu, vb. Bu inject'lerin amacı "daha çok teknik detay" değil; kanıt zinciri ve yöntem seçimi disiplinini sınamaktır.

Örnek:
- Inject: "Bulut tarafında bazı kritik loglar etkin değilmiş; sadece sınırlı bir audit izi var."

Beklenen davranış: "O zaman kesin konuşmayalım" deyip geçmek değil; hangi iddiaların confidence'ının düşeceğini, hangi ek kanıt gelirse yükseleceğini ve öneride telemetri iyileştirmesini kabul kriteriyle yazmaktır.

İpucu: Her inject için küçük bir "değişim günlüğü" tut: "Ne değişti? Hangi iddiayı etkiledi? Hangi yeni karşı kanıt ihtiyacı doğdu? Hangi yöntemi seçmemizi gerektirdi?" Bu günlük, final raporunun omurgasına dönüşür.

2) Deliverable'lar: çıktı seti ve kalite kapıları (18.2)

Bu capstone'da "çıktı" bir PDF gibi düşünülmez; bir karar dosyası seti olarak düşünülür. Setin değeri, parçaların birbirini çelişmeden desteklemesidir.

2.1. RoE + operasyon planı (yazılı, uygulanabilirlik değil denetlenebilirlik)

Bu belge, modül 1'in "ileri seviye olmadan olmaz" dediği temeldir. Şunları netleştirir:

Kapsam / kapsam dışı (varlık sınıfları düzeyinde)
Zaman penceresi ve iletişim kanalları
İzin verilen teknik sınıfları (how-to değil sınıf düzeyi)
Deconfliction: IT/IR ekipleriyle çakışma yönetimi
Kill-switch: acil durdurma koşulları ve tetikleyiciler
Minimum zarar ve veri minimizasyonu: kanıt toplama sınırları

Örnek: "Kişisel veri içeren tablolara dokunulmayacak; iş etkisi kanıtı veri örneğiyle değil, veri sınıfı ve erişim sınırı ihlaliyle gösterilecek" gibi bir madde; hem etik hem de rapor kalitesi açısından doğru bir sınırdır.

2.2. Recon brief + saldırı patikası alternatifleri

Recon brief; modül 3'teki gibi ham OSINT listesi değildir. Şu iki şeyi üretir:

Giriş noktası hipotezleri: "Nereden başlanabilir?" (kanıt gereksinimiyle)
Önceliklendirme: "Hangi patika daha olası ve daha etkili?" (noise/OPSEC maliyetiyle)

Ardından alternatif patikalar gelir: tek bir "ana yol" değil, başarısızlık planları ve karar noktaları.

İpucu: Patika tarifini "adımlar" gibi yazma. Onun yerine "koşul-güven sınırı-etki" üçlüsünü yaz. Bu, hem güvenlik sınırlarına uyar hem de savunmaya tasarım problemlerini net gösterir.

2.3. Kanıt standardında olay anlatımı + zaman uyumu

Buradaki anlatı "ne yaptım" değil, "neyi kanıtladım" anlatısıdır:

İddia (hangi varsayım bozuldu)
Kanıt (hangi sinyaller/izler bunu destekliyor)
Karşı kanıt (hangi veri olsaydı iddia daralır/çürür)
Confidence dili (neden böyle düşünüyoruz, ne değiştirir)
Zaman uyumu (timeline yaklaşımıyla tutarlılık)

Örnek: "Belirli bir kimlik bağlamında yetki sınırı ihlali sinyali görüldü; doğrulama için audit izi X gerekir, ancak retention sınırlı olduğundan bu iddia orta confidence'tadır; eğer Y kaynağından bağımsız bir sinyal gelirse confidence artar" gibi bir cümle; profesyonel belirsizlik yönetimidir.

2.4. ATT&CK eşlemesi: tekniklerin kontrol ailesine bağlanması

Eşleme, "etiketleme" değildir; savunma tarafında şu soruyu cevaplar:

Bu davranış sınıfı için hangi telemetri gerekir?
Hangi kontrol/tespit aileleri devreye girer?
Coverage gap nerede? (test edildi/edilmedi/tespit edildi-edilmedi)

Burada çerçeve olarak MITRE yaklaşımıyla bir "görünürlük ve gap" okuması yapılır; "şu tekniği yaptık" demek yerine "bu sınıf davranışın tespit edilmesi için hangi veri gerekir, yoksa kör nokta nerede oluşur?" denir.

2.5. Detection gap raporu + remediation roadmap

Gap raporu "EDR yakalamadı" diye bitmez. Şunları içerir:

Tespit hipotezi: hangi davranış sınıfı izlenmeli?
Telemetri gereksinimi: hangi kaynaklar, hangi kapsam, hangi kalite?
Noise/FP maliyeti: kuralın operasyonel yükü ne olur?
Kabul kriteri: "düzeldi"yi hangi kanıtla söyleyeceğiz?
Roadmap: hızlı kazanımlar + orta vadeli yapısal iyileştirmeler

Bu kısım, modül 17'deki rapor disiplinini ve modül 12'deki tespit perspektifini capstone'un final çıktısına bağlar.

3) Değerlendirme ölçütleri: rubrik ve başarının tanımı (18.3)

Bu modülde değerlendirme "teknik parlaklık" üzerinden değil, profesyonel standart üzerinden yapılır.

3.1. Tutarlılık ve kapsam disiplini

RoE ile rapor birbiriyle uyumlu mu?
Kapsam dışına taşma girişimleri doğru yönetilmiş mi?
Deconfliction ve kill-switch mantığı gerçekçi mi?

3.2. Kanıt kalitesi ve belirsizlik yönetimi

Kaynak-iddia-kanıt ayrımı korunmuş mu?
Karşı kanıt arama refleksi var mı?
Confidence dili gerekçeli mi, "yüksek/orta/düşük" demekle yetinmiyor mu?
Zaman uyumu ve izlenebilirlik düşünülmüş mü?

3.3. Risk dili ve önceliklendirme

Teknik ciddiyet ile iş etkisi ayrımı doğru mu?
Öncelikler gerekçeli mi? (erişilebilirlik, etki, kontrol gücü)
Roadmap ölçülebilir mi? Kabul kriterleri net mi?

3.4. Uygulanabilir öneri ve Purple Team'e bağlanabilirlik

Öneriler "tek cümle blokla" seviyesinde mi, yoksa kontrol hedefi + kontrol noktası + kabul kriteri içeriyor mu?
Detection engineering hattı kurulmuş mu?
Metrikler ve kapanış kanıtı düşünülmüş mü?

Dikkat: Capstone'un amacı "en yaratıcı saldırı" değildir; en denetlenebilir, en aksiyonlanabilir ve en az zarar ilkesiyle uyumlu çıktı setidir.

Terimler Sözlüğü

Terim	Açıklama
Tabletop	Masa başı senaryo çalışması; gerçek sistem olmadan karar ve çıktı üretme egzersizi
Capstone	Final bütünleyici modül; önceki modüllerin tek senaryoda birleştirilmesi
Scenario Package	Senaryo paketi; sinyaller, kısıtlar ve inject’lerden oluşan yazılı set
Inject	Senaryoya sonradan eklenen gelişme/bilgi; belirsizlik ve karar kalitesini test eder
Deliverable	Teslim çıktısı; rapor/doküman seti
Remediation Roadmap	İyileştirme yol haritası; öncelik, sahiplik, zamanlama ve kabul kriterleriyle plan
Rubric	Değerlendirme rubriği; puanlama ölçütlerinin sistematik çerçevesi
Coverage Gap	Kapsama boşluğu; tespit/önleme görünürlüğündeki kör noktalar
Detection Engineering	Tespit mühendisliği; telemetri ve kural/korelasyon tasarımıyla tespit kapasitesi geliştirme
Kill-switch	Acil durdurma mekanizması; operasyon güvenliği için önceden tanımlı durdurma koşulu

Kendini Değerlendir

Aşağıdaki sorular modül kazanımlarını ölçer. Her soru için en iyi cevabı seç.

1) Bir capstone senaryosunda “kapsam dışı” olduğu sonradan netleşen bir varlığa dair güçlü sinyal geliyor. En profesyonel yaklaşım hangisidir?

A) Sinyal güçlüyse kapsamı görmezden gelip devam etmek

B) Sinyali tamamen yok sayıp rapora hiç koymamak

C) RoE’ye dönüp kapsam dışı olduğunu not ederek, ilgili paydaşla resmi kapsam güncellemesi olmadan doğrulamayı durdurmak; sinyali “risk notu” ve belirsizlik diliyle raporda şeffafça belirtmek

D) Kapsam dışı varlıkta kanıtı güçlendirmek için daha agresif doğrulama yapmak

E) Sinyali “kesin ihlal” diye yazıp yönetime acil alarm vermek

Doğru: C
Gerekçe: RoE disiplini + minimum zarar + belirsizlik yönetimi profesyonel standarttır. A/D etik ve sözleşmesel risk doğurur; B şeffaflık kaybı; E kanıt standardını aşar.

2) Bir iddiayı güçlendirmek için tek bir veri kaynağı yerine “bağımsız sinyaller” aranmasının temel nedeni nedir?

A) Raporu uzatmak

B) İddianın yanlış pozitif olma ihtimalini düşürmek ve confidence’ı gerekçelendirmek

C) Teknik ekibi etkilemek

D) Görselleri daha şık yapmak

E) Hukuk ekibini susturmak

Doğru: B
Gerekçe: Bağımsız doğrulama, kanıt zincirini güçlendirir. A/C/D/E hedef dışı.

3) Aşağıdakilerden hangisi capstone’daki “kanıt standardında olay anlatımı”na en uygundur?

A) “Sistem ele geçirildi, risk çok büyük.”

B) “Şu saldırı adımlarıyla erişim sağlanır.”

C) “Belirli bir güven varsayımını bozan davranış sınıfı sinyali; destekleyen kanıtlar ve sınırlamalarla birlikte, hangi ek kanıt gelirse değerlendirme değişeceği yazılarak sunuldu.”

D) “Bu açık herkesçe bilinir, o yüzden kritiktir.”

E) “Detaya girmiyoruz ama tehlike var.”

Doğru: C
Gerekçe: İddia–kanıt–karşı kanıt + confidence dili. B güvenlik sınırlarını ihlal eder; diğerleri ya boş ya da gerekçesiz.

4) Bir risk önceliği belirlerken teknik skor ile iş etkisi arasında çatışma varsa en doğru yaklaşım hangisidir?

A) Her zaman teknik skoru yüksek olanı öncelemek

B) Her zaman iş etkisi yüksek olanı öncelemek, gerekçe yazmadan

C) Bağlamı (erişilebilirlik, etki, kontrol gücü, zincirdeki rol) yazılı gerekçeyle açıklayıp önceliklendirmek; gerekirse belirsizliği açıkça belirtmek

D) İkisini de “kritik” yazıp bırakmak

E) Önceliklendirmeyi müşteri yapar deyip rapora koymamak

Doğru: C
Gerekçe: Profesyonel risk dili gerekçeli olmalıdır. A/B aşırı genelleme; D karar kalitesini düşürür; E rapor sorumluluğunu boşaltır.

5) Bir “detection gap” bulunduğunda ilk soru aşağıdakilerden hangisi olmalıdır?

A) “Hangi aracı değiştirelim?”

B) “Bu davranış sınıfı için gerekli telemetri var mı; yoksa görünürlük mü eksik?”

C) “Bu olayı hemen kamuya duyuralım mı?”

D) “Red team bunu nasıl daha gizli yapar?”

E) “Raporu daha kısa mı yazsak?”

Doğru: B
Gerekçe: Gap analizi, önce telemetri/görünürlük ve veri kalitesini sorgular. D güvenlik sınırlarına aykırı; diğerleri alakasız.

6) “Kabul kriteri” yazmadan remediation önerisi vermek neden ileri seviye standarda uymaz?

A) Kabul kriteri sadece formalitedir

B) “Düzeldi” kararını denetlenebilir kılmaz; kapanış kanıtını belirsiz bırakır

C) Kabul kriteri raporu uzatır

D) Kabul kriteri yalnızca yönetici özetinde olmalıdır

E) Kabul kriteri sadece pentest’te geçerlidir

Doğru: B
Gerekçe: Kabul kriteri, kapanışın ölçüsüdür. Diğerleri yanlış çıkarımlar.

7) Bir inject, kritik logların etkin olmadığını gösteriyor. Aşağıdaki tepkilerden hangisi en olgun olanıdır?

A) “Log yoksa olay yoktur” deyip iddiayı kapatmak

B) “Log yoksa kesin ihlal var” diye iddiayı yükseltmek

C) Bu sınırlamayı rapora açıkça yazıp confidence’ı düşürmek; telemetri iyileştirmesini roadmap’e kabul kriteriyle eklemek

D) Logları açmak için kapsam dışı değişiklik talimatı yazmak

E) Konuyu görmezden gelmek

Doğru: C
Gerekçe: Belirsizlik yönetimi + ölçülebilir iyileştirme. A/B hatalı kesinlik; D güvenlik/etik sınır; E şeffaflık kaybı.

8) Capstone deliverable setinde “recon brief”in en doğru çıktısı hangisidir?

A) Tüm OSINT linklerinin ham listesi

B) Birkaç teknik terim ve genel tehdit söylemi

C) Giriş noktası hipotezleri ve önceliklendirme; her hipotez için kanıt gereksinimi ve yöntem maliyeti notları

D) Saldırı adımlarının ayrıntılı planı

E) Sadece görsellerden oluşan sunum

Doğru: C
Gerekçe: Recon, hipotez + öncelik üretmelidir. D güvenlik sınırlarını aşar; diğerleri eksik.

9) Capstone değerlendirmesinde “tutarlılık” en çok neyi ifade eder?

A) Metnin uzun olmasını

B) RoE, senaryo, kanıt zinciri, risk dili ve önerilerin birbirini çelişmeden desteklemesini

C) Çok sayıda teknik bulgu olmasını

D) Her şeyi %100 kesin yazmayı

E) Görsellerin çok olmasını

Doğru: B
Gerekçe: Tutarlılık, karar dosyasının omurgasıdır. A/C/E nicelik odaklı; D yanlış kesinlik.

10) “Minimum zarar” ilkesi, capstone’da en doğru nasıl görünür hale getirilir?

A) Kanıt toplamamak

B) Tüm detayları saklamak

C) RoE’de veri minimizasyonu ve doğrulama sınırlarını yazmak; raporda kanıtı amaç için yeterli minimumla sunmak ve kapanışta veri imhası/erişim kaldırma gibi güvenli kapanış adımlarını prensip düzeyinde belirtmek

D) Daha agresif doğrulama yapmak

E) Belirsizliği gizleyip hızlıca raporu bitirmek

Doğru: C
Gerekçe: Minimum zarar; sınırları yazılı hale getirir ve kanıtı gereksiz hassas veri taşımadan sunar. A/B dengesiz; D/E profesyonel değil.

Bu Modülde Kazanılan Yetkinlikler

Tek bir uçtan uca senaryoda, dış yüzeyden hedef varlığa uzanan hattı patika düşüncesi ile modellemeyi ve alternatif yolları gerekçelendirmeyi.
RoE/kapsam disiplininin, capstone'un gerçek "ileri seviye" ölçütü olduğunu; kapsam kayarsa başarının teknik görünse bile profesyonel sayılmayacağını.
"Kaynak-iddia-kanıt-karşı kanıt" yapısıyla kanıt zinciri kurmayı; belirsizliği confidence diliyle dürüstçe yönetmeyi ve hangi kanıtla fikrin değişeceğini yazmayı.
Risk derecelendirmesinde skor ezberinden çıkıp bağlam, iş etkisi, erişilebilirlik ve kontrol gücüyle gerekçeli öncelik üretmeyi.
Detection gap'leri "yakalamadı" seviyesinde bırakmayıp telemetri gereksinimi, noise/FP maliyeti, kabul kriteri ve kapanış kanıtıyla remediation roadmap'e dönüştürmeyi.
Capstone'un başarısını "yaratıcılık" değil denetlenebilirlik + aksiyonlanabilirlik + minimum zarar üçlüsünün belirlediğini.